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.
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.
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?
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 *
*-----------------------------------------------------*
