This jjar stuff seems pretty spiffy. How much does it cost? Can I have it painted in
metallic-blue and leather seats? :-)
At 16:27 08.08.2001 -0400, Geir Magnusson Jr. wrote:
>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
--
Ceki Gülcü - http://qos.ch
