I will respond to some of jason's comments as well as Vincent's in one
message...
Vincent Massol wrote:
>
> ----- Original Message -----
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 08, 2001 4:57 PM
> Subject: Central Repository for JARs
>
> > Hi,
> >
> > I am trying to create a build system using JJAR and Ant that will allow
> the
> > use of a central repository of JARs on a local system so that JARs don't
> > have to be stored in CVS but the build process for a developer will be
> just
> > as easy.
> >
> > I was originally using a single directory with a series of JARs contained
> > within, than Vincent suggested using a directory structure.
> >
> > But I think it boils down to a project specifying a dependency on a
> > particular version of a JAR. Ideally it would be good if the latest
> version
> > would work but this is not going to be the case in practice.
> >
> > Right now I have something like the following:
> >
> > build.properties
> > ----------------
> > velocity.jar = ${lib.repo}/velocity-1.2.jar
> >
> > build.xml
> > ---------
> > <path id="classpath">
> > <pathelement location="${velocity.jar}"/>
> > </path>
> >
A solution to this (the problem being the version #) is to do a project
by project repository which will avoid any name collision at the cost of
duplicate jars (which functionally don't matter because ant is specific
about loading from that projects repo...)
The cost is diskspace.
I think that getting the version numbers out of the build.xml is a good
thing to shoot for.
> > And if we used a directory structure we might have something like
> > the following
> >
> > build.properties
> > ----------------
> > velocity.jar = ${lib.repo}/velocity/1.2/velocity.jar
> >
> > I think at some point the project has to state a dependency on a
> particular
> > version so I was wondering what people thought?
> >
> > I think using JJAR and Ant a build system could be constructured so that
> all
> > java projects could use it to make building very easy while not having to
> > store JARs in multiple places. With the definition of ${lib.repo} in your
> > ~/build.properties file the whole thing could work. I have been trying to
> > get this to work with the turbine projects so there is a working example
> and
> > geir has been help me so hopefully there will be something to show
> shortly.
> >
> > 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). 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. But only once - put it with ant if you are using ant. JJAR also
includes a boostrap loader that goes and gets ant, but you still need to
have jjar. Can't beat that until we make it a part of the JRE :)
> * 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 ? It would need to handle
> the case where I am not connected to the internet and do nothing.
One approach is to make it a separate build target, so it doesn't fire
off every time. You might want it to fire off only when you do a CVS
update, for example, because that is the only time it could possibly
change.
That would also solve the not-connected issue as well.
> * 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.
That already works :)
> 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. 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 ?
Yep. I wouldn't do it in init - maybe add a 'source update' target that
does a CVS refresh and a jjar....
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb
