Peter Donald wrote:
>
> Hi,
>
> I was having a look at this and there is two things that jumped into my mind;
> labeling and the descriptor.
>
> How do we want to assign namespaces to libraries. There is three ways that I
> can think of off the top of my head;
> 1. arbitrary names with no order (ie jakarta-commons-jjar)
> 2. use internal package names or by DNS name separation (ie org.apache.jjar)
> 3. semantic categorization (ie system-software/updaters/jjar)
>
> (1) will mean could easily get collisions
> (2) means less chance of collision and matches java standards but does not
> add any semantics
> (3) while best for the user can be difficult to standardize. ie some people
> may use desktop/productivity/jword while others may use
> productivity/suite/jword etc.
The problem is that we ("JJAR admins") don't know the
libraries/packages, so it's really up to the owners of the packages,
modulo collisions. If we administer the central repository(ies), then
we can ensure that it doesn't happen.
I do like the semantic categorization, but that is more for directory
purposes than identification purposes, I think.
>
> Now with descriptors. Quite a few specs are evolving to mandate use of jdk1.3
> Extensions spec. Maybe jjar should use an enhanced version of that?? ie Use
> all the fields it defines and an extra one, say "JJar-Category" which lists
> category described above.
Sure.
>
> Because that descriptor is a bit ... err ... light on value, it may be best
> to supplement it with another descriptor that is shoved in META-INF/jjar.xml
> that has complete data you want. This would include things like description,
> maybe author and licensing details etc.
>
> Thoughts?
Sure. I like that. Re the 'light on value', the real need for this
info in the jar is simply for identification purposes, so JJAR can
figure out if a given jar (or any jar in the classpath) matches a given
package-version duple. It could just as easily be an assigned
identifier, with the mother ship holding the map, but for the cases
where people are offline, having the real info in the jar is necessary.
> On Wed, 22 Aug 2001 09:21, Geir Magnusson Jr. wrote:
> > Latest in JJAR-land, in the order I remember it :
> >
> > 1) Repository is now hosted on jakarta.apache.org (as promised many
> > times... sorry bout that) This should make life easier for Peter :)
> >
> > 2) I did a bit of documentation so people can see what this is about,
> > and I can remember what is going on. You can find it at
> >
> > http://jakarta.apache.org/commons/jjar.html
> >
> > it is also the index page on http://jakarta.apache.org/jjar/ but the
> > links are broken, and I don't care. It's a sandbox toy project :) (Is
> > there a way to *not* have that project.xml dependency so we can just use
> > the styling to render content?)
> >
> > The documentation is not complete - I will work on more this weekend,
> > trying to get as much of a mind-dump as I can into it.
> >
> > 3) Added support in the ant task to also setup a classpath with the jars
> > that get downloaded, so build.xml authors don't have to know the full
> > dependency list of something their project depends on :
> >
> > ex, in a compile target...
> >
> > <jjar package="veltag"
> > onlydependencies="true"
> > verifyignore="true"
> > localrepository="${local.repository}"
> > pathrefid="jjarclasspath" >
> > </jjar>
> >
> > <javac srcdir="${source.home}/java"
> > destdir="${build.home}/classes"
> > debug="${compile.debug}"
> > deprecation="${compile.deprecation}"
> > optimize="${compile.optimize}">
> > <classpath refid="jjarclasspath"/>
> > </javac>
> >
> > So this gets the dependencies for veltag, and adds them to the
> > classpath. The javac then uses that classpath when compiling. When the
> > dependencies change, nothing changes in the build.xml.
> >
> > The cool part (I think) is demonstrated by the veltag contrib in
> > Velocity. It has an entry in the central repository, and that entry
> > points to a repository.xml in the veltag CVS. So the Veltag build uses
> > JJAR to get it's own dependencies, download the jars, and put those jars
> > in the classpath. Ok, I think it's cool.
> >
> > The result is that we should be able to start taking explicit dependency
> > references out of build.xml files. I have a few more things I want to
> > play with as I want this as flexible as possible, as there is no One
> > True Way for build files. :)
> >
> > geir
>
> --
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> * "Faced with the choice between changing one's mind, *
> * and proving that there is no need to do so - almost *
> * everyone gets busy on the proof." *
> * - John Kenneth Galbraith *
> *-----------------------------------------------------*
--
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
