On Sun, 19 Dec 2004 13:13:03 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> 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.
OK, I see what you mean. My way around this is to not attempt to get
anything that isn't gettable automatically. ;-) The only thing I've
hit so far is the JDBC 2.0 Ext jar, which, IIUC, is only required when
building with JDK 1.3.
BTW, I haven't decided whether or not to try to download a Cactus
distro as part of this, or whether to assume that the user has one
somewhere. I am assuming that Tomcat would already be installed prior
to running Cactus tests. Comments?
> > 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
Great!
> ... 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.
That's the default behaviour, yes. However, if you define 'libdir' in
your ${user.home}/build.properties file, it will download to there and
not blow that away as part of 'clean'.
I actually have pretty much the same setup in what I'm doing for
Struts, where the default value of 'local.repo.dir' is
'target/repository'. This is for the simple reason that the default
needs to be on a path that the build system knows exists (or can
exist). However, it just occurred to me that I could make the default
value be '${user.home}/struts-repository' (or something along those
lines) instead. Comments on this?
--
Martin Cooper
> >
> > --
> > Martin Cooper
> >
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
