On Sun, 19 Dec 2004 12:54:38 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <[EMAIL PROTECTED]> > wrote: > > On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <[EMAIL PROTECTED]> wrote: > > > At worst case, it seems we could add a task to do the downloads of > > > those binaries that are redistrutable. I think most folks would > > > rather invoke an Ant task than have to chase down dependencies. It > > > wouldn't even have to be tied to a compile. > > > > > > > Absolutely agree that there needs to be a way to point at local copies > > instead. The challenge for Mavenized projects that want to also be > > Ant-friendly is the way that the Ant plugin generates its build.xml > > files -- it does generate "get" tasks for pulling the dependencies, > > but uses hard coded paths from the project.xml file. It would be much > > better if the generated tasks used an Ant property for the "src" > > attribute, so that one could override and point at your local copy. I > > would like to see us do that in our Struts build.xml files (that are > > manually maintained) if we start using get tasks ourselves. > > Perhaps I'm misunderstanding what you're saying, but the > Maven-generated Ant build files work just fine if you're disconnected, > as long as you have previously downloaded the dependencies. All you > have to do is set the 'noget' property, and the attempts to <get> the > files will be skipped. The dependencies will then be picked up from > your local repo.
The standard Maven generated build.xml for Commons Email, for example, creates hard coded get URLs for the JavaMail and JAF jars, based on the values in project.xml (which in turn point at the Sun web page where you have to click through the license to perform the downoads). It would not do any good to change where these URLs point to some "local" repository, because there is no canonical URL that would work for all users. > > The scheme I'm working on still defines all of the 'foo.jar' > properties we use today, but internally to the build. It uses a very > similar scheme to Maven to go get the dependencies and put them in > 'local.repo.dir' unless the 'noget' property is set, and then builds > against what is in that directory. If someone really wants to put the > dependencies elsewhere, they can still define 'foo.jar' to do that. > The versions of each dependency can also be overridden if necessary. > > Will that work for you? That sounds like it would work for me ... it would also fix another annoying quirk with the way that Maven-generated build.xml files work now. The get tasks all copy JARs into a directory that is blown away by the "clean" target, so running "ant clean dist" (which the nightly build does for each package) redownloads all the dependencies every time. > > -- > Martin Cooper > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
