ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: FW: [maven2] Anything Groovy in Maven2?
Date Tue, 04 May 2004 08:27:41 GMT


> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: 04 May 2004 09:20
> To: dev@ant.apache.org
> Subject: Re: FW: [maven2] Anything Groovy in Maven2?
> 
> On Tue, 4 May 2004, Vincent Massol <vmassol@pivolis.com> wrote:
> 
> > There's some discussion raging in Maven land for Maven2 as whether
> > we could/should reuse Ant tasks in embedded mode from within Maven
> > plugins written in java.
> 
> Well, whether you should is beyond our opinion 8-)

:-)

> 
> "could", I'd say yes.  If you realize that you can't that probably
> means that Ant tasks aren't as embeddable/reusable as we'd like them
> to be.  And then we should probably fix that.

cool

> 
> Tomcat's Jasper embeds Ant's javac task without using Ant's runtime
> environment IIRC, so at least for this task, embedding seems to work.
> I must admit that I don't know how many hoops the Jasper folks had to
> jump through, though.
> 
> > The contentious point is that it that some believe it won't be
> > possible to due to the strong tie of Ant tasks to the AntClassloader
> 
> Maybe.  If so it probably is because of oversight/lack of thought when
> it comes to embeddabilty (is this a word after all?).  If the only
> embedder of Ant tasks you know is Ant, it is hard to see that you are
> creating a problem for other embedders.

True. But you could easily create a sample project in Ant CVS that would
use Ant task in embedded mode. It would serve as a functional test bed.
I do this in Cactus land and it has worked very well for us.

> 
> > More specifically, I'd like to know why the JUnit task in Ant 1.6
> > has now lots of dependencies on the Ant classloader.
> 
> I cannot see that much difference between JUnitTask in CVS HEAD and
> the version in 1.5.4.  Both create an AntClassLoader if and only if
> the user has specified a classpath (as attribute or nested element).
> Just the creation of the classloader has moved into a separate method.
> 
> Ant 1.6 has added the reloading attribute.  While 1.5.x creates a
> fresh classloader instance of AntClassLoader for each test, Ant 1.6
> can be instructed to use a single instance for all tests.

You're right. Sorry. I was misled by the refactoring that happened in
Ant 1.6 and the introduction of the new createClassLoader() method.

However, the code is:

    private int executeInVM(JUnitTest arg) throws BuildException {
[...]
        try {
            log("Using System properties " + System.getProperties(),
                Project.MSG_VERBOSE);
            createClassLoader();
            if (classLoader != null) {
                classLoader.setThreadContextLoader();
            }

Thus the AntClassloader is created in all cases. However, I've not
pushed the investigation further and maybe that it is created but not
used.

> 
> > How can we now reuse it in embedded mode?
> 
> Unless there is a bug that I didn't see on first glance,
> AntClassLoader shouldn't get used at all unless you specify a
> classpath to the task.
> 
> What exactly is the problem you see.  Are classes loaded from the
> wrong classloader?  Is the task or test-runner missing classes that
> should be there?

Yes, I need to gather more details... Our conversation may end here for
now for lack of information. I have asked Jason if he could provide the
code that is not working for him. We'll see...

In any case, thanks for your feedback. I'll start using Ant tasks to
write maven2 plugins soon. If I have problems, I'll contact the list
again.

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message