Stefan Bodewig wrote:
On Tue, 26 Oct 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> 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.
smime.p7s
Description: S/MIME Cryptographic Signature
