Vincent Massol wrote:
>
> ----- Original Message -----
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: "Vincent Massol" <[EMAIL PROTECTED]>
> Sent: Wednesday, August 08, 2001 7:24 PM
> Subject: Re: Central Repository for JARs
>
> [snip]
> > Ah, do you use .ant.properties? I consider what's in build.properties to
> be
> > ant properties.
>
> yes, me too :)
>
> [snip]
> > > why don't you do it as I have proposed ? It looks fine and simple to me.
> >
> > I actually don't understand what you're saying.
>
> I am proposing :
>
> * JJAR be an Ant taks. This is agreed, it seems. So you just have to drop it
> in $ANT_HOME/lib (or even better if it is included in optional.jar but not
> necessary for a first release),
it is an ant task... (or has one...)
> * I define in my build.properties (for example) the location of the
> repository directory (lib.repo property)
Yep
> * I point my jars to this in build.properties. For example, in Cactus I need
> the servlet 2.2 API jar, so I would write :
>
> lib.repo = c:/tmp/repo
> servlet22.jar = c:/tmp/repo/XXX/servlet.jar
The problems here is that it doens't take advantage of what jjar really
has to offer.
Try this :
- you define, for your project, the dependencies for that project in a
local (or central) descriptor
- then jjar takes care of making sure that the jars and their
dependencies (and their dependencies...) are in the local repository
- then you do it by blind faith :) that you can include all the jars in
the repo in the classpath, something like
<!-- Build classpath -->
<path id="classpath">
<fileset dir="./repository">
<include name="**/*.jar"/>
</fileset>
</path>
What you get out of this is that you only define the dependencies in
*one place* the project decription in the repository.
Keeps maintenance to a minimum.
> Question: How do you standardize XXX ? In other words how do you define the
> location of a given jar in the repository (server side). I believe, this is
> actually what Sam was saying and GUMP has defined a way to define it.
How do you define it?
Here's how it's done in the current repository descriptor for ant
<package name="ant" default="1.3" latest="1.3">
<info>
<desc>The amazing Jakarta build tool.</desc>
<href>http://jakarta.apache.org/ant/</href>
</info>
<versionset>
<version version="1.3">
<note> current production version</note>
<jar>ant-1.3.jar</jar>
<dependencies>
<dep package="jaxp" version="1.0"/>
</dependencies>
</version>
</versionset>
</package>
Note that the repository has a name for the jar, ant-1.3.jar. This will
be unique in the repository. (It's up to the repository maintainer to
ensure this. Can't be that hard. You could keep it in a subdir if that
lit your lucky...
What I indended is for this whole filename issue to disappear because
its really a human factor. We could easily call them 1.jar 2.jar 3.jar
4.jar etc (but it would be a drag to try and figure out what is what...)
because the whole process is automatic. But for human-friendlyness,
ant-1.3.jar is ok...
Remember, the version information about a jar in the local repository
comes from *inside* the jar, not the filename. JJAR looks at each jar
in the repository, and gets the JJAR package name ('ant') and version
from within. Again, part of the maintenance of the repository -
hopefully it can be pushed to be automatically done in the build process
of the jars by the projects themselves..
>
> * Somewhere in my build.xml, I call the jjar task to update my local jars. A
> good place would be my init target for instance. That would be something
> like:
>
> <jjar repo="${lib.repo}" config="<config file>"/>
Yes. You could have the repository descriptor as part of the source
tree...
> I think we need a jjar config file that defines the needed jars and their
> versions. We might also need profiles, like
>
> <config file>:
>
> <dependencies>
>
> <profile name="latest">
> <jar name="servlet.api"> <!-- by default when no version is defined, use
> latest -->
> ...
> </profile>
>
> <profile name="stable">
> <jar name="velocity" version="1.1"/>
> ...
> </profile>
>
> </dependencies
>
> Although profiles would be refinement that is not needed for the first
> release.
> But I do think we need a file to describe the dependencies.
It already does that. <sigh>
For a project, you only define the projects that you need, and the
version. JJAR already can take care of the rest...
> * The jjar behaviour would be :
> - if no internet connection, does nothing,
> - if newest jars download them in lib.repo otherwise do nothing.
sort of.
> [snip]
> > >> 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! :)
> >
> > How would you know that velocity-1.2 is the latest for sure?
>
> I don't know that. That's my question ! I'm just saying that we need a
> mechanism (like the one proposed above) to be able to manage latest
> versions.
That's handled by the central repository. if your project uses
Velocity/latest, then you will get whatever is defined to be the latest
version of Velocity when you refresh...
> Note: It's funny because I have a sense of 'deja-vu' .... I remember
> discussin all this on this same mailing list about 4 months ago ... :)
> -Vincent
Yes, and it was done then :)
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
