[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-ant-dev] Heads up: Eclipse Ant Support will be changing
|
It's not a bug but a very usefull feature to be added.
Will help many of us to use their build files from Eclipse ;)
With such features, I could try to build some jakarta projects
like tomcats 3.3/4.x and tomcat connectors
Regards
-
Henri Gomez ___[_]____
EMAIL : hgomez@xxxxxxx (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-----Original Message-----
>From: Rodrigo_Peretti@xxxxxxx [mailto:Rodrigo_Peretti@xxxxxxx]
>Sent: Thursday, April 04, 2002 3:58 PM
>To: platform-ant-dev@xxxxxxxxxxx
>Subject: RE: [platform-ant-dev] Heads up: Eclipse Ant Support will be
>changing
>
>
>
>There is already a bug report on that. I have added your
>message to that.
>
>Rodrigo
>
>
>
>
>
>
> "GOMEZ Henri"
>
> <hgomez@xxxxxxx> To:
><platform-ant-dev@xxxxxxxxxxx>
> Sent by: cc:
>
> platform-ant-dev-admin@ Subject:
>RE: [platform-ant-dev] Heads up: Eclipse Ant Support will be
> eclipse.org changing
>
>
>
>
>
> 04/04/2002 02:04 AM
>
> Please respond to
>
> platform-ant-dev
>
>
>
>
>
>
>
>
>While the works in on, could we have the IDE vars (CLASSPATH Variables)
>exported and also information on the current project, ie it's
>path, it's
>name.
>
>Should just be provided as if they were passed to ant with -D
>
>ie :
>
>ant -DJRE_LIB=/usr/bin/jdk1.3.1/jre -DJSSE_LIB=/usr/share/java/jsse.jar
>.....
>
>
>-
>Henri Gomez ___[_]____
>EMAIL : hgomez@xxxxxxx (. .)
>PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
>PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>
>
>>-----Original Message-----
>>From: Rodrigo_Peretti@xxxxxxx [mailto:Rodrigo_Peretti@xxxxxxx]
>>Sent: Wednesday, April 03, 2002 5:39 PM
>>To: platform-ant-dev@xxxxxxxxxxx; eclipse-dev@xxxxxxxxxxx
>>Subject: [platform-ant-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.
>>
>>_______________________________________________
>>platform-ant-dev mailing list
>>platform-ant-dev@xxxxxxxxxxx
>>http://dev.eclipse.org/mailman/listinfo/platform-ant-dev
>>
>_______________________________________________
>platform-ant-dev mailing list
>platform-ant-dev@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/platform-ant-dev
>
>
>
>
>_______________________________________________
>platform-ant-dev mailing list
>platform-ant-dev@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/platform-ant-dev
>
