Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Heads up: Eclipse Ant Support will be changing


Sorry folks... did not mean to reply to this.

John Kellerman
Product Manager, WebSphere Studio Workbench
OTI - Research Triangle Park, NC
kellrman@xxxxxxxxxx
919 254 4194, fax: 919 254 4183



John Kellerman/Raleigh/IBM@IBMUS
Sent by: eclipse-dev-admin@xxxxxxxxxxx

04/03/2002 10:57 AM
Please respond to eclipse-dev

       
        To:        eclipse-dev@xxxxxxxxxxx
        cc:        
        Subject:        Re: [eclipse-dev] Heads up: Eclipse Ant Support will be changing

       




Marie, we're going to want to talk about this too tomorrow...

John Kellerman
Product Manager, WebSphere Studio Workbench
OTI - Research Triangle Park, NC
kellrman@xxxxxxxxxx
919 254 4194, fax: 919 254 4183
 


Rodrigo_Peretti@xxxxxxx
Sent by: eclipse-dev-admin@xxxxxxxxxxx

04/03/2002 10:38 AM
Please respond to eclipse-dev
       
        To:        platform-ant-dev@xxxxxxxxxxx, eclipse-dev@xxxxxxxxxxx
        cc:        
        Subject:        [eclipse-dev] Heads up: Eclipse Ant Support will be changing

       



We are planning to make a significant change to the way Ant works inside
Eclipse. This note explains the problem we want to solve, outlines the
solution, and explains the impact of these changes on existing clients and
users of Ant in Eclipse.
 
The problem is simple enough to explain: running Ant scripts inside Eclipse
is different from running Ant scripts outside Eclipse.
- Some Ant tasks that work fine outside Eclipse do not work inside Eclipse
(e.g., the classic javac task)
- It is difficult to access specialized Ant tasks from inside Eclipse,
because
there is no simple way to include extra JARs on classpath when Ant is
launched.
- Inside Eclipse, there is no way to choose a different version of Ant.
 
For the 2.0 release, we want to change this so that running Ant inside
Eclipse
offers the same degrees of flexibility as running it outside. We want to
ensure
that preexisting specialized Ant tasks can be used. And we still want it to
be possible to define and use Eclipse-specific Ant tasks that communicate
directly with the running Eclipse platform.
 
What's the problem? Why not just allow the user to specify extra JARs for
the
classpath used to look up Ant task classes while running Ant scripts.
Include
tools.jar so that javac can be found. And give the user a preference for
setting the entry for ant.jar so that it's now easy to point to a different
version of Ant. That should do the trick.
 
Although this is indeed the basic outline of the solution we're proposing,
there are some obstacles to making this happen. These obstacles are called
classloaders.
 
In order to run Ant, we need to poof up a suitable classloader and give
it a classpath to search when loading code. This classpath would include
tools.jar and a user-specified list of JARs containing code for specialized
Ant tasks. Eclipse-specific Ant tasks reference classes in Eclipse
plug-ins;
this means that the Ant classloader will have appeal to the Eclipse
platform plug-in classloaders in order to find these classes. What about
ant.jar itself? (Here's where things get ugly.)
 
If we put ant.jar as a library inside a plug-in (in 1.0, ant.jar is defined
as
a library for the org.eclipse.ant.core plug-in), then a plug-in classloader
has
the honor of loading the Ant code. When Ant itself uses Class.forName to
lookup
a class mentioned in a task definition, the plug-in classloader will not be
looking in the user-specified JARs and, consequently, will be unable to
find any
tasks other than the built-in ones. (This explains the limitations we see
in
Eclipse 1.0.)
 
If, on the other hand, we put ant.jar as a JAR entry on the classpath, the
code
will be loaded directly by our Ant classloader. Ant Class.forName lookups
will
be able to find classes in any of the user-specified JARs, and in any
plug-ins
that it is collaborating with. In this arrangement, however, none of the
Ant
classes are visible to the Eclipse plug-in classloaders, making it
impossible
to run an Eclipse-specific Ant task loaded by a plug-in classloader!
Fortunately, there is no such problem with Eclipse-specific Ant tasks
defined
in JARs (i.e., like other Ant tasks) loaded directly by the Ant
classloader.
 
Because of these properties of Java classloaders, the only way to gain the
flexibility of being able to include additional JARs on the classpath is to
move to the latter scheme: ant.jar as a JAR entry on the classpath along
with JARs containing additional Ant tasks.
 
These changes will impact clients that define their own Eclipse-specific
Ant
tasks, Ant types, Ant objects. (It does not impact regular users of Ant.)
The main change is that library plug-in JARs cannot contain Ant tasks.
Ant tasks need to be put in separate JARs that will be included on the
Ant classpath so that it can be loaded directly by the Ant classloader.
We suggest developing Ant tasks in a project separate from projects used
to develop the code for plug-ins. In order to compile code against the
org.apache.ant API, this project will need to include an ant.jar as a
library on its build classpath. (Note also that the
org.eclipse.ant.core plug-in will no longer provide ant.jar as a
plug-in library.)
 
Eclipse-specific Ant tasks (etc.) can still be made known to Eclipse via an
extension point. The XML markup includes an additional library attribute
that
specifies the JAR in which to find the code for task (the path is relative
to
the base of the plug-in). Example:
 
Old XML element for contributing an Ant task:
<extension point="org.eclipse.ant.core.antTasks">
<antTask name="myTask" class="com.examples.MyTask"/>
</extension>
 
New XML element:
<extension point="org.eclipse.ant.core.antTasks">
<antTask name="myTask" class="com.examples.MyTask"
library="lib/myjar.jar"/>
</extension>
 
The contributions to these extension points are used to automatically
include
these library JARs on the Ant classpath, and to fabricate appropriate Ant
taskdefs. And any plug-in that contributes to these extension points is
automatically included on the classpath as a collaborating class loader.
 
Using this mechanism is not mandatory. The alternative, and fully-manual,
way is to include a JAR containing one or more Ant tasks on the classpath
and
write explicit Ant taskdefs in the Ant script file. This is useful when you
already have a JAR of specialized Ant tasks that you just want to include
on the Ant classpath.
 
These following changes to the Ant UI expose the changes to Ant core:
 
+ When running Eclipse with a JDK (as opposed to a JRE), tools.jar will be
automatically included on the Ant classpath.
 
+ New UI to allow users to specify extra JARs to include on the Ant
classpath.
 
+ New UI to allow users to specify new Ant tasks and types that will be
available when running Ant scripts (so that you don't need to write
taskdefs).
 
+ New UI to allow users to locate the ant.jar for the version of Ant used
to
to run their Ant scripts. The default will be the version of ant.jar that
ships with Eclipse in the org.apache.ant plug-in.
 
Please send any comments and questions to the platform-ant-dev@xxxxxxxxxxx
developer mailing list.
 
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/eclipse-dev




Back to the top