gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
Date Tue, 26 Oct 2004 15:43:12 GMT
Stefan Bodewig wrote:

> On Tue, 26 Oct 2004, Stefano Mazzocchi <stefano@apache.org> wrote:
> 
>>Niclas Hedhman wrote:
> 
> 
>>>Ant projects are treated according to a template of classpath
>>>injection, BUT some projects do their own downloads, and I wonder
>>>if there are some that actually bypasses the Gump intentions.
>>
>>Yes, this is where I think Maven surpasses Ant in design, in respect
>>to Gump integrability: ant is a lot less declarative. which means
>>it's much easier for people to do things that we don't have control
>>over from the outside.
>>
>>Stefan, thoughts?
> 
> 
> I trust build.sysclasspath a lot 8-)
> 
> Seriously, in all built-in Ant tasks you'll have a very hard time to
> defeat Gump's intentions.  And custom tasks will have to explicitly
> avoid Ant's own infrastructure (like AntClassLoader) for that.
> 
> We have a bunch of project pulling down dependencies from all over the
> place and the result is just ignored by Ant in Gump.
> 
> The main exception is the manifest's Class-Path attribute, but as long
> as you use URLClassLoader (and why would you want to rewrite that)
> there is nothing much you can do.
> 
> This is not a comment on whether Ant or Maven is better designed for
> any purpose.  I just want to say that it is really hard to bypass
> Gump's control of the classpath using Ant.

Very well, thanks. that solves my concerns.

> I'm not sure how mandatory/optional support for jar overrides in Maven
> is.

Well, I'm sure that we can work with them to find out a way to achieve 
the same external control, in case it's required.

>>>Perhaps it could be tested by setting a security policy for Ant
>>>which disallowed network connections.
>>
>>Wouldn't that make projects fail?
> 
> 
> Certainly.  We've seen this a couple of times.
> 
> Many <javadoc> tasks will fail, for example, since the <link> to Sun
> javadoc sites and the javadoc executable tries to download the package
> index files from there.  Cactus and Axis need network access (at least
> to localhost) for tests ...

right, but as you state above, we don't need to go down this path.

-- 
Stefano.


Mime
View raw message