On Sun, 19 Dec 2004 19:06:56 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> Intermixed.
>
> On Sun, 19 Dec 2004 18:36:41 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > 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.
>
> I thought Commons Chain used to have some other dependencies; I'm sure
> Commons Resources does.
Chain no longer depends on anything that isn't available from ibiblio,
now that it's building against the MyFaces version of the JSF API.
Resources does depend on Hibernate, as well as some other things I've
never heard of. I'm not sure that any of those things need to be
available for building Struts or running the tests, but I could easily
be wrong on that. I guess we'll see when we switch over to using
Resources in Struts.
> > 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?
>
> If we're going to be complete, we might as well be complete ... the
> only thing we should really assume the user has is a JDK. That would
> really mean downloading Tomcat as well. But isn't that the whole
> point, that running "ant download" or whatever will get *everything*
> you need?
I suppose. The question I was asking myself was "download everything
for what?". That is, downloading everything to just build, or
downloading everything to build and test. The latter would imply
downloading multiple versions of Tomcat, since we currently support 3
different versions (although the 5.5 tests don't pass yet).
If we want to be able to download everything, then we might want to
have 2 separate tasks - one to download everything to build, and one
to download the additional requirements for unit testing.
>
> >
> > > > 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'.
> >
>
> Hmm ... have to play with that one. One rough edge is that you need a
> separate libdir directory for each project, because the generated
> scripts add all the jars in the libdir directory to the classpath for
> that project. Oh well, at least that's something I can set up once
> per project and forget about it.
>
> > 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?
>
> I take it you don't want to assume the use of Maven? If so, I might
> recommend something like "${user.home}/.ant/repository/struts"
> (sort-of like what Maven does in "${user.home}/.maven" to start
> getting people used to this approach. I'm gonna try this sort of
> thing on my machine for the nightly builds of all the commons
> packages, which take much longer than they should due to the repeated
> downloads.
Since this is an Ant build, no, I don't want to assume that the user
uses Maven or even knows what it is. It would be confusing to use the
.maven directory for someone who didn't know what that is.
I like your recommendation of putting the repo under .ant, though.
I'll switch the default to that. :-)
--
Martin Cooper
> >
> > --
> > Martin Cooper
> >
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
