Re: [platform-ant-dev] Heads up: Eclipse Ant Support will be changing

[Rodrigo_Peretti@xxxxxxx]

Hi Peter,

Thanks for the heads up. We were not aware of the problems you're 
mentioning. We have considered on forking a JVM to run Ant but it would 
make it almost impossible for tasks relying on Eclipse-specific objects to 
run (e.g. refreshLocal). Now it seems we should reconsider it and probably 
make it optional for the user: run scripts on a separate JVM and lose 
Eclipse-specific tasks or run it on the same JVM and lose these tasks you 
mention.

Thanks again,
Rodrigo






Peter Donald <peter@xxxxxxxxxx>
Sent by: platform-ant-dev-admin@xxxxxxxxxxx
04/03/02 02:46 PM
Please respond to platform-ant-dev

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

Hi,

Just as a heads up. There is no way you can currently maintain 100% 
compatability with the commandline invocation of ant if you don't start a 
new 
JVM. Some tasks/classes rely on being loaded from the system ClassLoader. 
At 
one stage we tried to change the ant runtime so that it would be easy to 
allow embedding in another ClassLoader but unfortunately it broke too much 

stuff. So we ended up being forced to go back to our old method for 
backwards 
compatability.

We are trying to address these issues in ant2 but that wont be out for a 
time 
yet. 

I would recomend that you start a new JVM (possibly with a custom launcher 

that registers your particular librarys) to do ant compiles if you want 
100% 
compatability.

On Thu, 4 Apr 2002 01:38, Rodrigo_Peretti@xxxxxxx wrote:
> 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.
>
> _______________________________________________
> platform-ant-dev mailing list
> platform-ant-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-ant-dev

-- 
Cheers,

Pete

Frank Zappa observed: "It's not getting any smarter out
                       there.You have to come to terms with
                       stupidity, and make it work for you."
_______________________________________________
platform-ant-dev mailing list
platform-ant-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ant-dev