----- Original Message -----
From: "Jason van Zyl" <[EMAIL PROTECTED]>
To: "Vincent Massol" <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 6:53 PM
Subject: Re: Central Repository for JARs
> On 8/8/01 1:29 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
>
> >
> > ----- Original Message -----
> > From: "Jason van Zyl" <[EMAIL PROTECTED]>
> > To: "Vincent Massol" <[EMAIL PROTECTED]>
> > Sent: Wednesday, August 08, 2001 5:54 PM
> > Subject: Re: Central Repository for JARs
> >
> >
> >> On 8/8/01 12:24 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>>
> >>>> I thought I would solicit opinions and see if anyone else would
> > actually
> >>> use
> >>>> this system if made.
> >>>
> >>> +1 for the idea. I'm not sure how it would integrate with Cactus let's
> > say :
> >>> * certainly I will need to put a jjar.jar file somewhere (chicken and
> > egg
> >>> pb).
> >>
> >> To start with I would probably ask the Ant fellows if they would make a
> >> binary dist with jjar task in the optional package so that it would be
> > easy
> >
> > +1
> >
> >> for people to get started. I was chatting with Geir how to make this as
> > easy
> >> as possible: possibly webstart or something like it that allows you to
get
> >> started as fast as possible. So it might down load Ant for you and
> >
> > -0, I think it can wait and looks too complex for the time being. Having
to
> > install Ant is fine for the time being !
> >
> >>
> >> 1) Ask where you want to store your JARs (${lib.repo})
> >> 2) Create ${lib.repo} for you
> >> 3) Add lib.repo = /jar-repository to your ~/build.properties
> >
> > no, I prefer to control this myself! Also, how I might not use a
> > build.properties file, you won't know where it is located, ...
>
> I would like to make this standard so that all projects work the same so
> that once you've dealt with one project working with any other project is
> simple. I am making it so that a project needs a build.properties, I don't
> see this as a draw back. Let me finish the example first :-)
>
Yes, don't try to do too much at the same time and don't assume everyone
will use build.properties (for example GUMP doesn't !!). Only Ant properties
matter.
> >>
> >> After this any project could hook into this property and have JARs
> >> downloaded into the specified ${lib.repo} directory and if build files
> > were
> >> adjusted to take advantage of this than I think building would become
> >> greatly simplified and you wouldn't have to store JARs in CVS.
> >>
> >>> However if I understand correctly JJAR will be used as an Ant task, so
> >>> the jjar.jar file will not be linked to Cactus but rather will be put
in
> >>> $ANT_HOME/lib so that it will be in than Ant classpath when I type
'ant
> > xxx'
> >>
> >> Yes, JJAR would be used as an Ant task in the build files but JJAR
might
> >> also be used to pull down the initial version of Ant too. Maybe use
JJAR
> >> like an installer if possible.
> >>
> >>> ?
> >>> * then where would it fit in my build.xml file ? As part of my init
> > target
> >>> so that it will check for dependencies and download the needed jars of
> >>> internet and put them in the specified directory ?
> >>
> >> Your build files would have to be adjusted to take advantage of the
> >> ${lib.repo} strategy. I am trying to use Torque as an example so you
have
> >> something to look at. I will probably make some more tasks for checking
> >> dependencies because what I currently have is very cumbersome. If you
want
> >> to see what I have so far look in the jakarta-turbine-torque
repository.
> >> It's not in maintainable for yet by any means but it's a start.
> >>
> >>> It would need to handle
> >>> the case where I am not connected to the internet and do nothing.
> >>
> >> Yes, definitely. If JARs are stored in CVS you are dead in the water
> > anyway.
> >
> > yes, but I may be at the office, download them and then work offline
when I
> > go home for example
>
> If you already have the jars than it won't be a problem.
I was actually just asking if this was already managed in jjar ?
>
> >>
> >>> * I would like to be able not to specify any version in my
> > jjar.properties
> >>> (where the dependencies are defined) so that the JJAR task will
download
> > the
> >>> latest version if there is newer one than the current one in my
> > repository.
> >>
> >> The project would specify the version of a package it is bound to,
right
> > now
> >> for torque I state the deps in the project build.properties file.
> >
> > Don't focus on build.properties itself. It just need to be Ant
properties
> > that's all.
>
> I use build.properties for everything
>
> ~/build.properties
> <project>/build.properties
good for you ... :)
but again don't assume everyone uses them ... focus on Ant properties
instead. Your properties in build.properties are ant properties in the end
...
>
> There is an order in which the properties files are loaded that must be
> followed in order for things to work correctly. Again I need to finish the
> example so people have something to look at.
why don't you do it as I have proposed ? It looks fine and simple to me.
>
> >>
> >>> In other words, I would still keep the Cactus build.properties but the
> > paths
> >>> within it will point to the JJAR repository directory instead and I'll
> > just
> >>> have to add a call to the JJAR task in my init target.
> >>
> >> You would have something like:
> >>
> >> velocity.jar = ${lib.repo}/velocity-1.2.jar
> >
> > this is what I don't like. How do I specify the latest version of the
> > velocity jar ?
>
> We could get gump to build velocity-latest.jar and put that into the
> repository as well though I think it will always be the case that a
project
> binds to a version.
nope ... velocity-latest is the same as velocity-1.2, it contains version
information in the name! :)
>
> >>
> >> The ${lib.repo} property should be setup, and hopefully can be done
> >> automatically at some stage.
> >
> > no, manual is fine.
>
> Manual is not fine for an automated build system. It won't work if people
> have to stop and edit things. That's what I don't want. Just grab a
project
> from CVS and build.
No you don't understand what I mean. What I mean is that choosing wheer
lib.repo is located is part of Ant configuration (and thus up to the build
writer), not of jjar !
>
> >>
> >>> And everyone building
> >>> Cactus will need to ensure that the JJAR task is in Ant (it should be
> >>> possible to test for it and not do anything if not in the classapath,
> >>> though). Is that right ?
> >>
> >> Yes, hopefully taking care of having ant with JJAR can be handled
> >> automatically. I would like to make the process as transparent,
seemless
> > and
> >> easy as possible.
> >>
> > -Vincent
-Vincent
