Ceki Gülcü wrote:
>
> This jjar stuff seems pretty spiffy. How much does it cost? Can I have it painted in
>metallic-blue and leather seats? :-)
It's just as pricy as that exceptional logger you push on all of us :)
The leather comes standard, and you can have metallic if you really want
it...
geir
>
> 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
--
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
