Re: FW: Managing versions of Apache Jakarta software

[dion]

Thanks guys, I recently added this to Maven, so that anyone using maven 
can fill in their project descriptor and do:

ant maven:jar

and it will automatically create the appropriate manifest for you from the 
descriptor.

"Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote on 10/04/2002 12:23:26 
AM:

> From: "Glenn Nielsen" <[EMAIL PROTECTED]>
> 
> > FYI, I recently added package versioning to Jakarta-Taglibs.
> > The jakarta-taglibs ant build uses an XSL Stylesheet to
> > create the manifiest. :-)
> 
> Another possibility: on Jakarta POI we are using a dev version of 
Centipede.
> The jar is done like this:
> 
>  value="${package-version}-${DSTAMP}"/>
> 
>  
jarfile="${xlayout.build.dir}/${package-name}-${package-name-suffix}.jar">
>   
> 
>   
>   
> 
> 
>/>
>value="${package-short.version}" />
>value="${xgump.module.vendor}" />
>/>
>value="${package-version}" />
>value="${xgump.module.vendor}" />
> 
>   
> 
> 
> --
> Nicola Ken Barozzi   [EMAIL PROTECTED]
> - verba volant, scripta manent -
>(discussions get forgotten, just code remains)
--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FW: Managing versions of Apache Jakarta software

[Nicola Ken Barozzi]

From: "Glenn Nielsen" <[EMAIL PROTECTED]>

> FYI, I recently added package versioning to Jakarta-Taglibs.
> The jakarta-taglibs ant build uses an XSL Stylesheet to
> create the manifiest. :-)

Another possibility: on Jakarta POI we are using a dev version of Centipede.
The jar is done like this:




  

  
  


  
  
  
  
  
  

  


--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FW: Managing versions of Apache Jakarta software

[Glenn Nielsen]

FYI, I recently added package versioning to Jakarta-Taglibs.
The jakarta-taglibs ant build uses an XSL Stylesheet to
create the manifiest. :-)

Glenn

Ted Husted wrote:
> 
> There was already a versioning page, so I made this packageversioning
> instead.
> 
> http://jakarta.apache.org/site/packageversioning.html
> 
> It's not linked into the rest of the site yet, except for the Guides
> outline, which is also in draft form
> 
> http://jakarta.apache.org/site/guides.html
> 
> (at the Release Manager's Guide). But it is now under CVS for discussion
> purposes.
> 
> The best thing is to submit XML, like the other source pages for
> Jakarta-site2, and run the build to be sure it renders
> 
> http://jakarta.apache.org/site/jakarta-site2.html
> 
> Thank you for your contibution.
> 
> -Ted.
> 
> ajack wrote:
> >
> > Here is it sent again, w/ versioning.html converted to versioning.html.txt.
> >
> > regards
> >
> > Adam
> > -Original Message-
> > From: ajack [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, March 31, 2002 6:49 PM
> > To: 'Jakarta General List'
> > Subject: RE: Managing versions of Apache Jakarta software
> >
> > Danny Angus wrote:
> >
> > Perhaps if you were to submit an idea for a simple manual/ant automated
> > process someone might add it to the website for further discussion.. I
> > believe someone was looking at writing  guidlines for release managment but
> > don't know what happened there. That might be a suitable place for it.
> >
> > How about  this: versioning.html -- with a couple of add ons: build.xml and
> > manifest.template.
> >
> > regards
> >
> > Adam
> >
> >   
> > Name: build.xml
> >build.xmlType: XML Document (text/xml)
> > Encoding: 7bit
> >
> > Name: manifest.template
> >manifest.templateType: unspecified type (application/octet-stream)
> > Encoding: 7bit
> >
> >   Name: versioning.html.txt
> >versioning.html.txtType: Plain Text (text/plain)
> >   Encoding: quoted-printable
> >
> >   
> > --
> > To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

-- 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Managing versions of Apache Jakarta software

[Stefan Bodewig]

On Thu, 28 Mar 2002, <[EMAIL PROTECTED]> wrote:

> Now, it occurred to me that ANT would be the best tool to use for
> keeping manifest files in synchronization with code/releases, but I
> found [not that there may not exist] no easy way to do this with
> built in commands.

Ant 1.4.1 supports manifest generation inside , but unfortunately
did not include documentation for it 8-(.  From Ant's own build file:


  

  
  
  
  
  
  

  
...


This is from current CVS but it works for 1.4.1 as well.

Stefan

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: FW: Managing versions of Apache Jakarta software

[Ted Husted]

There was already a versioning page, so I made this packageversioning
instead.

http://jakarta.apache.org/site/packageversioning.html

It's not linked into the rest of the site yet, except for the Guides
outline, which is also in draft form 

http://jakarta.apache.org/site/guides.html

(at the Release Manager's Guide). But it is now under CVS for discussion
purposes. 

The best thing is to submit XML, like the other source pages for
Jakarta-site2, and run the build to be sure it renders

http://jakarta.apache.org/site/jakarta-site2.html

Thank you for your contibution. 

-Ted.


ajack wrote:
> 
> Here is it sent again, w/ versioning.html converted to versioning.html.txt.
> 
> regards
> 
> Adam
> -Original Message-
> From: ajack [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, March 31, 2002 6:49 PM
> To: 'Jakarta General List'
> Subject: RE: Managing versions of Apache Jakarta software
> 
> Danny Angus wrote:
> 
> Perhaps if you were to submit an idea for a simple manual/ant automated
> process someone might add it to the website for further discussion.. I
> believe someone was looking at writing  guidlines for release managment but
> don't know what happened there. That might be a suitable place for it.
> 
> How about  this: versioning.html -- with a couple of add ons: build.xml and
> manifest.template.
> 
> regards
> 
> Adam
> 
>   
> Name: build.xml
>build.xmlType: XML Document (text/xml)
> Encoding: 7bit
> 
> Name: manifest.template
>manifest.templateType: unspecified type (application/octet-stream)
> Encoding: 7bit
> 
>   Name: versioning.html.txt
>versioning.html.txtType: Plain Text (text/plain)
>   Encoding: quoted-printable
> 
>   
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

FW: Managing versions of Apache Jakarta software

[ajack]

Here is it sent again, w/ versioning.html converted to versioning.html.txt.

regards

Adam
-Original Message-
From: ajack [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 31, 2002 6:49 PM
To: 'Jakarta General List'
Subject: RE: Managing versions of Apache Jakarta software


Danny Angus wrote:

Perhaps if you were to submit an idea for a simple manual/ant automated
process someone might add it to the website for further discussion.. I
believe someone was looking at writing  guidlines for release managment but
don't know what happened there. That might be a suitable place for it.

How about  this: versioning.html -- with a couple of add ons: build.xml and
manifest.template.

regards

Adam






	

  	
		 
		 
  	


	





manifest.template
Description: Binary data


JAR/Package Versioning

Package Versioning

The Java™
 Product Versioning Specification allows users to identify the exact version 
information of a package within a JAR. This is particularly useful when users have a 
number of packages, with version interdependences, from various distributions. 


These four simple steps use ANT to maintain and insert the versioning information, so 
all JARs shipped are correctly versioned. Note: This is just one method, and in 
future releases ANT may have built in mechanisms for this task.

Step 1: Manually create a template manifest file.
Java versioning is implemented by attributes set within the manifest of the JAR.

See Javasoft's documentation on: JAR
 Manifest Format




Manifest-version: 1.0

Name: org/apache/{Apache Package}/
Implementation-Title: {Apache Package}
Implementation-Version: @version@
Implementation-Vendor: "Apache Software Foundation"





Save this with your build.xml as a file called manifest.template.


Note: The {Apacke Package} ought be manually replaced by the 
package name, e.g. "log4j" or "Axis"
Note: The @version@ is a specific keyword used later in ANT 
filtering, and will be dynamically updated.

Step 2: Maintain the version in your ANT build script

Set and maintain the ${version} property.



<property name="version" value="1-1-1" 
/>


Step 3: Create the manifest, filtering the version

This replaces @version@ in manifest.template with 1-1-1 in 
manifest.mf.




<target name="manifest">
<filter token="version" value="${version}" /> 
<copyfile="manifest.template"
tofile="manifest.mf" 
overwrite="true"
filtering="true" /> 
</target>


Step 4: Create your JAR, setting the manifest attribute

This sets the META-INF/Manifest.mf in the JAR file.




<target name="distribution" depends="... manifest ...">
<jar jarfile=...
manifest="manifest.mf"/>






Sample Files:   manifest.template, build.xml





--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Managing versions of Apache Jakarta software

[ajack]

Danny Angus wrote:

Perhaps if you were to submit an idea for a simple manual/ant automated
process someone might add it to the website for further discussion.. I
believe someone was looking at writing  guidlines for release managment but
don't know what happened there. That might be a suitable place for it.

How about  this: versioning.html -- with a couple of add ons: build.xml and
manifest.template.

regards

Adam






	

  	
		 
		 
  	


	





manifest.template
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing versions of Apache Jakarta software

[Andrew C. Oliver]

On Thu, 2002-03-28 at 16:06, Peter Donald wrote:
> On Fri, 29 Mar 2002 07:49, Andrew C. Oliver wrote:
> > *gets the feeling that the project marketing campaign for Maven has
> > begun and wonders if he bought into a time share and singed up for a
> > free seminar by accident*
> 
> The funny thing is that some of the people marketing maven haven't even 
> downloaded or used it yet :)
> 

Is that not the usual order of things?  Do those responsible for
marketing...usually actually use the thing they are marketing?  :-)

> -- 
> Cheers,
> 
> Pete
> 
> 
>  These aren't the droids you're 
>  looking for. Move along. 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com
http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
Document 
format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Jeff Prickett]

On Fri, 29 Mar 2002, Danny Angus wrote:

> Morning,
> 
> I wrote:
> > > I'm not qualified to put forward any suggestions
>

That doesnt stop most people, including myself from replying ;)
 
> Sam replied:
> > I respectfully disagree.
> 
> Thanks Sam, I'll now bore you with my own opinion, and see if you change
> your mind.. ;-)
> 
> I believe that there are two conflicting forces at work within Jakarta
> regarding cross sub-project dependancies,
> 
> The first is the desire of individual sub-projects to provide their general
> users (the people who make the sub-projects' existence worthwhile) with a
> single distributable file from which a full working install can be made.
> James and Turbine(which has a version including tomcat) are examples of
> this. This gets positive feedback from users who want a shallow learning
> curve and a fast track to deploying the application.
>

We are going to try to aim for the single distributable file for 
periodicity, which should have a 0.0.1 release soon. For projects like 
turbine and James where you can literally lose users in five minutes if 
they get too frustrated this makes sense.

 
> The second is the worthy and intelligent notion (exemplified by GUMP) that
> no cross project dependancies should be satisfied by an individual
> sub-project.
> This is based on the notion that to do so will inevitably lead people who
> are installing more than one sub-project to have to maintain duplicates of
> some API's that are depended upon (is there a word for that?) by more than
> one sub-project, logging and ant for instance. Tomcat source distributions
> are an (admittedly poor) example of this in that they don't distribute ant,
> but the build depends upon it, there may be better examples.
>

I think that there 
is a growing trend among some projects to have test suites using JUnit. 
Perhaps there will come a day when Gump could automatically build every 
project AND run all the tests associated with every project. This could be 
done by having components that support tests defining a well-known Test 
that would call all tests for that component. Kind of like knowing http is 
port 80. Gump could run the well-known junit test automatically. If 
enough Apache projects used JUnit tests then Gump would not only be able to 
tell us if a build is broke but also if functionality has been affected...

I know I am a dreamer, but it could happen. The only thing for developers 
in all the sub-projects to do is agree on the name of the well-known 
test and implement a JUnit test suite with that name and we would all be 
one step closer to ending jar hell...
 
> I don't know how this helps to clarify the situation, but I expect a
> "Jakarta registry" is probably required, and the ability for sub-projects to
> define their classpaths as part of their installation procedure. In which
> case a manifest reading ant task could ensure dependancies are satisfied
> without sub-projects having to bundle them.
> 



Thanks Jeff Prickett


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Danny Angus]

Hi,
(if this is getting too OT tell me to sling my hook)

I just printed and read the jdk 1.3 optional packages versioning document
(again) then found this ..
http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/extensions.ht
ml the section on "Java Extensions Installation" made interesting reading.

What is anyones opinion of the issues raised by installing Jakarta
components in this way (into lib/ext), rather than as bundled jars in the
application classpath?

I understand that it raises security questions, but am on shaky ground about
the impact of these, what other concerns are there?
(what is the Jakarta policy on signing jars, is there a jakarta certificate
or certification authority, if not should there be?)

I also wonder how this method would work in practice where applications have
their own classloader, for instance I put my JDBC drivers into tomcats
"common" directory for use by all my servlet applications.
If I installed them (complete with acceptable manifest) as extensions would
my servlet application find them correctly, and find the correct versions?
If so why don't I know about this already..(don't answer that!)

Furthermore.. if I have a singleton which is placed in tomcats common
directory only one instance will be created across all webapps, if it is in
the WEB-INF/lib a new one will be created for each app. What is the
implication of generalising the scope by installing it in the /lib/ext/ of
my JVM?
I assume there will still be one instantiated for each running instance of
the JVM, but am I wrong in this assumption?

It seems to me that we have here a mechanism with plenty of potential to
reduce the duplication of jars, and what needs to be done is to create an
installation manager which can check dependancies and install jars as
required. Particularly as both the implementation and specification version
manifest attributes can be used to precisely define dependancies, and
compatibility.

Perhaps there should be a jakarta "environment" project (tied in some way to
GUMP?) oh no we've been here already haven't we.. ah well, at least I caught
up eventually. :-)

Ho hum, time I stopped doing this and spent some quality time with my
family..

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing versions of Apache Jakarta software

[Andrus Adamchik]

I hear you. And I think I understand pretty well ;-). Therefore I was 
looking at your project as an example how this should be done in Java 
world.


Guillaume Rousse wrote:
> 
> Curiously in java world, packager work is generaly is at best 
> misunderstood, often ignored, or even seen with some hostility from 
> developpers.


> 
> But the result is here: jpackage project covers today more than a hundred of 
> different java projects. See http://jpackage.sourceforge.net for complete 
> list.
> 


-- 
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
- Andrei (a.k.a. Andrus) Adamchik
Home of Cayenne - O/R Persistence Framework
http://objectstyle.org/cayenne/
email: andrus-jk at objectstyle dot org


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing versions of Apache Jakarta software

[Guillaume Rousse]

Ainsi parlait Andrus Adamchik :
[..]
> Task of a package creator is harder. (Here is a link with detailed
> information : http://www.rpm.org/max-rpm/ ). In short (in reality it is
> rather hard) package creators need to get sources, convert
> "configure-make-make install" into a special RPM spec for a target
> platform, build it into RPM.

And also keep track of dependency developpers didn't explicitly provided, 
discard binary files and look for sources everywhere on the net, find a 
global coherency among hundreds of different practices, adapt to 
platform-specific standards, deal with license nightmare, cope with crazy 
archive formats, etc...

Curiously in java world, packager work is generaly is at best 
misunderstood, often ignored, or even seen with some hostility from 
developpers.

But the result is here: jpackage project covers today more than a hundred of 
different java projects. See http://jpackage.sourceforge.net for complete 
list.

-- 
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Danny Angus]

> Task of a package creator is harder. (Here is a link with detailed
> information : http://www.rpm.org/max-rpm/ )

Thanks thats interesting..

> I've been holding this idea for a while since you won't find volunteers
> to help unless you lead such an effort and get it at least to beta, and
> I am very busy with Cayenne as it is right now. But I would happily
> participate as a developer, provided someone would take a lead.

I'd be interested in hearing more of your idea, off this list if you like,
because this issue affects us at work as well, where we have a number of
interdependant packages upon which our products depend, and development work
can occur sporadically to any one of them.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Danny Angus]

> It would be a real shame for the lack of an total automated
> solution to lead
> to the lack of a simple manual solution. If administrators can manually
> check the explicit version of a JAR, rather than comparing
> sizes/datestamps,
> that would be a major improvement over today. Correctly version stamping
> JARs (using ANT today, or ANT future) would make operational
> configuration a
> lot less "throw a pile of JARs together and pray..."

I think the problem here is that we (obssessive Jakarta people)  can't see
the woods for the trees, it tends not to be such a problem to people who
have a good working knowledge of the projects and their progress, if not
their actual contents. Additionally this has been discussed before but no
one made any concrete proposals (I don't think)

Perhaps if you were to submit an idea for a simple manual/ant automated
process someone might add it to the website for further discussion.. I
believe someone was looking at writing  guidlines for release managment but
don't know what happened there. That might be a suitable place for it.

At the end of the day it would, of course, be up to individual sub-projects
whether or not to implement it, but you stand the best chance of this if you
can present a clearly documented simple system for release managers and
build script writers to follow. After all if it takes ten minutes to
implement and doesn't conflict with anything else what is there to lose?

Dont forget the principle of Apache, that changes often get submitted
because users get so hacked off waiting for someone else that they submit
them themselves.
:-)

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing versions of Apache Jakarta software

[Andrus Adamchik]

Danny Angus wrote:
>>There was a discussion about an enterprise distribution of jakarta and
>>other open-source java technologies some time back on this list that
>>resulted in starting "oed" project on SourceForge [which is pretty much
>>dead at the moment :-( ].
> 
> 
> Which may suggest that there's more to solving this problem than meets the
> eye..

You got it, this is one of the main reasons.

> I'm nervous about tackling it because I think that it would take a massive
> effort to gain the kind of acceptance it would need to be worthwhile..
> on the other hand.. how does RPM work? Personally I'm the impatient
> "configure-make-make install"  guy mentioned in the README files ;-)

RPM is neat and extremly clean and easy way to maintain software. This 
is what you get for all the tremendous work done by package creators. It 
maintains a central repository of packages installed and their 
dependencies. Unlike Windows registry it doesn't allow arbitrary garbage 
written to repository (AFAIK), it just uses it for package tracking. All 
you need to know as a user is a few switches to the RPM command:

rpm -i (install)
rpm -e (erase)
rpm -U (update)
rpm -V (verify)

Task of a package creator is harder. (Here is a link with detailed 
information : http://www.rpm.org/max-rpm/ ). In short (in reality it is 
rather hard) package creators need to get sources, convert 
"configure-make-make install" into a special RPM spec for a target 
platform, build it into RPM.

Implementing the same thing in Java should be easier.  As with RPM there 
are same 3 roles involved that need to be supported (user, developer, 
packager). The goal is to make "user" tasks as easy as with RPM, while 
making "packager" task much easier, bringing it down to creating a 
simple XML spec. It helps that in Java, you don't need to compile 
sources for different platforms. Getting a distribution that includes 
JARs is enough. Also, I am pretty sure there is lots of sinergy with 
Ant, so many things do not need to be implemented from scratch.

I've been holding this idea for a while since you won't find volunteers 
to help unless you lead such an effort and get it at least to beta, and 
I am very busy with Cayenne as it is right now. But I would happily 
participate as a developer, provided someone would take a lead.


-- 
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
- Andrei (a.k.a. Andrus) Adamchik
Home of Cayenne - O/R Persistence Framework
http://objectstyle.org/cayenne/
email: andrus-jk at objectstyle dot org


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[ajack]

> There was a discussion about an enterprise distribution of jakarta and
> other open-source java technologies some time back on this list that
> resulted in starting "oed" project on SourceForge [which is pretty much
> dead at the moment :-( ].

Which may suggest that there's more to solving this problem than meets the
eye..

I'm nervous about tackling it because I think that it would take a massive
effort to gain the kind of acceptance it would need to be worthwhile..


It would be a real shame for the lack of an total automated solution to lead
to the lack of a simple manual solution. If administrators can manually
check the explicit version of a JAR, rather than comparing sizes/datestamps,
that would be a major improvement over today. Correctly version stamping
JARs (using ANT today, or ANT future) would make operational configuration a
lot less "throw a pile of JARs together and pray..."

I still believe a simple Version bean would be very powerful, and easy to
adopt, but since nobody's taken up what I've written then I guess I'm not
proposing anything original/compelling, and that perhaps this is a road
already travelled w/o end success. If there is a forum where folk feel a
complete proposal [for just a version/version dependency class, nothing
more] might be worthwhile please let me know, otherwise I'll go back to
lurking. Thanks in advance.

regards,

Adam


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Danny Angus]

> There was a discussion about an enterprise distribution of jakarta and
> other open-source java technologies some time back on this list that
> resulted in starting "oed" project on SourceForge [which is pretty much
> dead at the moment :-( ].

Which may suggest that there's more to solving this problem than meets the
eye..

I'm nervous about tackling it because I think that it would take a massive
effort to gain the kind of acceptance it would need to be worthwhile..
on the other hand.. how does RPM work? Personally I'm the impatient
"configure-make-make install"  guy mentioned in the README files ;-)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing versions of Apache Jakarta software

[Andrus Adamchik]

Danny Angus wrote:
> Should, perhaps, Jakarta be using our hard fought success with JSPA to propose a JSR 
>defining an installation API that would address dependancy management in a cohesive 
>way?
> 
> It seems to me that dependancy handling in Java as a whole, not just here, has been 
>left to fate rather than engineering, I have installed, on this machine, JDK 1.3 and 
>1.4 from Sun other developers will also have IBM's JVM installed as well, yet when I 
>install JBuilder it installs its own JDK as well, and there are other products that 
>do likewise. To me this is an indication that the extent of dependancy management 
>problems is so great that sellers of commercial products cannot even reliably assume 
>compatibility between minor versions of the JDK, let alone third party components. I 
>would have thought that ought to concern anyone who's livelihood depends upon Java.
> Its all very well Java being "platform independant" but it really ought to provide a 
>framework for dependacy management too, after all it is in effect an operating system 
>(albeit more of an emulator) and library management should be a service provided by 
>the os (IMO), and as producers of a range of interdependant products Jakarta is in 
>dire need of this (again IMHO).
> 

This is so true that Java needs a real dependency management standard. 
While I agree that work on a JSR is maybe the way to go on a long run, I 
think the actual implementation should start regardless of JSR existence.

There was a discussion about an enterprise distribution of jakarta and 
other open-source java technologies some time back on this list that 
resulted in starting "oed" project on SourceForge [which is pretty much 
dead at the moment :-( ]. Doing some preliminary research in this 
direction led me to the same conclusion - Java is an "OS-like" creature 
and therefore needs a package manager (registry, whatever).

I was thinking more along the lines of an RPM-like system. It can still 
be ant-driven, but main effort should be put into dependency tracking 
framework. As far as JAR versioning goes, 
http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html can 
be used, but there is much more. For instance you may want to install 
documentation or sample applications, etc. together with a package. So 
just dropping right version of  .jar in .../lib/ext may not solve all 
the problems. I was thinking about packaging similar to what folks at 
http://www.jpackage.org/ do, but making it in Java. This is a fairly big 
effort, but AFAIK this is the biggest piece currently missing from the 
"Java puzzle".

-- 
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
- Andrei (a.k.a. Andrus) Adamchik
Home of Cayenne - O/R Persistence Framework
http://objectstyle.org/cayenne/
email: andrus-jk at objectstyle dot org


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Danny Angus]

So where does that leave us?

Do you (Pete) believe that the work you're going to put into Ant2 and java versioning 
can address this satisfactorily in a generic way?
What participation would it require from sub-projects wanting to adopt it?

Should, perhaps, Jakarta be using our hard fought success with JSPA to propose a JSR 
defining an installation API that would address dependancy management in a cohesive 
way?

It seems to me that dependancy handling in Java as a whole, not just here, has been 
left to fate rather than engineering, I have installed, on this machine, JDK 1.3 and 
1.4 from Sun other developers will also have IBM's JVM installed as well, yet when I 
install JBuilder it installs its own JDK as well, and there are other products that do 
likewise. To me this is an indication that the extent of dependancy management 
problems is so great that sellers of commercial products cannot even reliably assume 
compatibility between minor versions of the JDK, let alone third party components. I 
would have thought that ought to concern anyone who's livelihood depends upon Java.
Its all very well Java being "platform independant" but it really ought to provide a 
framework for dependacy management too, after all it is in effect an operating system 
(albeit more of an emulator) and library management should be a service provided by 
the os (IMO), and as producers of a range of interdependant products Jakarta is in 
dire need of this (again IMHO).

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing versions of Apache Jakarta software

[Peter Donald]

On Fri, 29 Mar 2002 22:08, Danny Angus wrote:
> This raises a couple of issues though..
>
> a) it implies that there be an ant based installer for each application
> participating in the scheme

Maybe not an ant based installer. However what it does need is something that 
is equivelent to unixes ld.so. For those who are not aware ld.so is basically 
the linker for unix apps and it maintaines a cache of library data as stored 
in well known places (like /usr/lib, /usr/local/lib, /opt/lib etc).

I have already written most of this about a year ago and plan to revive it 
for work on Ant2.

> b) it also implies that dependacy information and version compatibilities
> can be written and read in a useful way

There is a java standard for this namely

http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html.

for a simple explanation see dependencies on

http://jakarta.apache.org/ant/myrmidon/librarys.html

> I think I'm going down the road of a kind of binary GUMP, where
> dependancies are satisfied not by building from cvs, but by downloading
> binaries.

cjan and jjar in commons started out trying to do that but I am not sure 
where they got. I believe they opted not to use the java standard versioning 
/ optional package /extension scheme which makes them even less likely to be 
adopted unless there is much more widespread noise of them :)

-- 
Cheers,

Pete

--
"An intellectual is someone who has been educated 
beyond their intelligence."
--

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[dion]

Even less valuable opinions inline :)

"Danny Angus" <[EMAIL PROTECTED]> wrote on 29/03/2002 10:08:45 PM:

> I don't know how this helps to clarify the situation, but I expect a
> "Jakarta registry" is probably required, and the ability for 
sub-projects to
> define their classpaths as part of their installation procedure. In 
which
> case a manifest reading ant task could ensure dependancies are satisfied
> without sub-projects having to bundle them.

See Maven's update-jars target.

> This raises a couple of issues though..
> 
> a) it implies that there be an ant based installer for each application
> participating in the scheme
Maven creates an 'install-jar' as part of it's build process.

> b) it also implies that dependacy information and version 
compatibilities
> can be written and read in a useful way
See the project descriptors for Gump & Maven.

> c) it may also require a seperate "jakarta_lib" to store common("shared" 
not
> "popular") jars, to remove them from individual project directory trees.
lib.repo, as defined in maven's properties.

> d) smooth operation may also need a coherent jar version naming scheme, 
and
> download directory structure to be adopted by all participating
> sub-projects, so that ant can find the ones it needs to download.
I wish.

> I think I'm going down the road of a kind of binary GUMP, where 
dependancies
> are satisfied not by building from cvs, but by downloading binaries.
See maven's update-jars target.

> If I lose my job I know what to do..

I know I've mentioned maven a lot here lately, but after checking out 
other stuff, and coming across it, it solves a ton of these problems, and 
is being developed here as well.

The guys developing it are also open to feedback/criticism/junk.
--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Danny Angus]

Morning,

I wrote:
> > I'm not qualified to put forward any suggestions

Sam replied:
> I respectfully disagree.

Thanks Sam, I'll now bore you with my own opinion, and see if you change
your mind.. ;-)

I believe that there are two conflicting forces at work within Jakarta
regarding cross sub-project dependancies,

The first is the desire of individual sub-projects to provide their general
users (the people who make the sub-projects' existence worthwhile) with a
single distributable file from which a full working install can be made.
James and Turbine(which has a version including tomcat) are examples of
this. This gets positive feedback from users who want a shallow learning
curve and a fast track to deploying the application.

The second is the worthy and intelligent notion (exemplified by GUMP) that
no cross project dependancies should be satisfied by an individual
sub-project.
This is based on the notion that to do so will inevitably lead people who
are installing more than one sub-project to have to maintain duplicates of
some API's that are depended upon (is there a word for that?) by more than
one sub-project, logging and ant for instance. Tomcat source distributions
are an (admittedly poor) example of this in that they don't distribute ant,
but the build depends upon it, there may be better examples.

I don't know how this helps to clarify the situation, but I expect a
"Jakarta registry" is probably required, and the ability for sub-projects to
define their classpaths as part of their installation procedure. In which
case a manifest reading ant task could ensure dependancies are satisfied
without sub-projects having to bundle them.

This raises a couple of issues though..

a) it implies that there be an ant based installer for each application
participating in the scheme
b) it also implies that dependacy information and version compatibilities
can be written and read in a useful way
c) it may also require a seperate "jakarta_lib" to store common("shared" not
"popular") jars, to remove them from individual project directory trees.
d) smooth operation may also need a coherent jar version naming scheme, and
download directory structure to be adopted by all participating
sub-projects, so that ant can find the ones it needs to download.

I think I'm going down the road of a kind of binary GUMP, where dependancies
are satisfied not by building from cvs, but by downloading binaries.

If I lose my job I know what to do..

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[ajack]

Sam Ruby [mailto:[EMAIL PROTECTED]] wrote:

I very much like xml-commons-which.

http://cvs.apache.org/viewcvs.cgi/xml-commons/java/src/org/apache/env/


It seems very useful, and I've only view it briefly [so I am no expert] but
wouldn't it be better if classes/packages known or unknown to this tool
would just return some "standard" Version object? This tool seems to use
adhoc per component version mechanisms, or infers version information based
upon subtleties known of the per component implementation/interface. It
doesn't seem like this would scale well.

For example, if a convention could be created [like XXXBeanInfo, I guess]
where a class {package}Version.class [e.g. org.apache.axis.Version] were
expected to exist for each Package, and this were a bean that returned
name/major/minor/dependencies [and/or the Java Package attributes], could
not an amazing Which tool be written?

regards,

Adam


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Sam Ruby]

Danny Angus wrote:
>
> I'm not qualified to put forward any suggestions

I respectfully disagree.

> but I bet Pete and Sam have Views and Opinions..

I very much like xml-commons-which.

http://cvs.apache.org/viewcvs.cgi/xml-commons/java/src/org/apache/env/

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Danny Angus]

Pete Donald wrote:

> Anyways if there is a demand for this I can get it into the 
> ant1.5 codebase 
> earlier.

I think what there ought to be a demand for is a Jakarta wide code of practice for 
declaring versions and dependancies, even if its only in documentation. I guess this 
just adds a twist to the "jars in cvs" debate..

I was a little surprised when I started to discover that there aren't explicit version 
naming conventions, or at least guidelines, for the whole of Jakarta. Therefore I 
wasn't surprised to discover that version interdependance isn't really addressed in a 
coherent way.

I'm not qualified to put forward any suggestions but I bet Pete and Sam have Views and 
Opinions..

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing versions of Apache Jakarta software

[Sam Ruby]

Peter Donald wrote:
>On Fri, 29 Mar 2002 07:49, Andrew C. Oliver wrote:
>> *gets the feeling that the project marketing campaign for Maven has
>> begun and wonders if he bought into a time share and singed up for a
>> free seminar by accident*
>
>The funny thing is that some of the people marketing maven haven't even
>downloaded or used it yet :)


   It also has never been built successfully with the public gump, so it
   truly is all hype at this point.  Nudge.  Nudge.


- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing versions of Apache Jakarta software

[Peter Donald]

Just as a heads up. There will be something that helps you manage version 
information in jars in the next release (1.5). It semi-automates declaration 
of library name and version and it also allows the jar to declare 
dependencies on other libraries. It does this according the following spec.

http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html.

This is used because it is the spec the EJB/Servlet/Service containers all 
seem to be adopting for library management. For a simplified explanation you 
may want to look at the section titled "dependencies" in 

http://jakarta.apache.org/ant/myrmidon/librarys.html

Anyways if there is a demand for this I can get it into the ant1.5 codebase 
earlier.

On Fri, 29 Mar 2002 07:58, ajack wrote:
> I guess you folk have seen so many adhoc suggestions that you tend to
> attempt to form a consistent guideline out of them. I'm not convinced this
> particular approach has sufficient merit, or that there aren't better ones,
> it was just an idea I threw out based on initial findings. I am game to
> contribute what I can, but is this the forum? Do I become some owner of
> this, or what? I guess I need Jakarta contributions 101 before I go much
> further...
>
> That said, I am not sure a guideline is the place to go, and if I am asked
> to contributed, I guess I'd have to do it based upon my own beliefs. I feel
> that document (or manifest) based version management is too passive. When I
> found Javasoft's versioning mechanism was in JAR files it seemed clear why
> it has so little adoption [hell, I thought nothing exists, and I'm sure
> most folk think that.] Personally I feel investment would be better served
> in a "commons-versioning" [just made that up, hope I didn't upset some
> "version4j folk"] with some "active" classes (including dependency
> checking, start-up logging of version numbers, etc).
>
> I wish Java had a java.lang.Version class, 'cos their java.lang.Package
> class [from a few hours of poking at it & class loader] doesn't seem to cut
> it. That said, if it doesn't, perhaps a commons-logging type package could
> be formed, that filled the gap (and perhaps eventually showed Javasoft the
> need for one.)
>
> regards,
>
> Adam
> -----Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 28, 2002 1:33 PM
> To: Jakarta General List
> Subject: Re: Managing versions of Apache Jakarta software
>
>
> Well, at this point Adam, we don't so much has have a written guideline
> for creating a Jakarta release, so adding versioning to a non-existent
> guidelines poses something of a challenge :O)
>
> I have started some notes for a Release Manager's guide at
>
> http://jakarta.apache.org/site/guides.html
>
> What would be most helpful is that if you rolled your notes and
> experiences into a HOW-TO that the Release Managers might easily follow.
> As a deployment manager using several Jakarta products, you sound like
> just the person to write it.
>
> It is really not possible for use to create a standard release mechanism
> by fiat. So the next best thing is to make the "right" way the easy way,
> but giving people some simple instructions to follow. We're all
> interested in versioning, and run into the same problems you have; it's
> really a matter of documenting a procedure people can follow, and that
> we can point to if missed.
>
> -Ted.
>
> ajack wrote:
> > All,
> >
> > I've been lucky enough to have benefited from a lot of the excellent
> > packages put out be this community, e.g.
>
> ANT/XERCES/LOG4J/XALAN/SOAP2.2/AXIS
>
> > etc etc, and I thank you all for that. Recently however my utilization of
>
> a
>
> > lot of Apache software has bitten me (commons-logging in AXIS in this
>
> case),
>
> > and it all comes down to "JAR version hell" & conflicts between various
> > versions delivered with various components.
> >
> > Upon investigation I see that some Jakarta projects distribute JARs with
> > version information inside (notably log4j, XALAN) and some do not
> > (notable AXIS and commons-logging, which is sad since they are newer and
> > changing,
>
> so
>
> > need it badly.)
> >
> > Please please please make it a standard that all Jakarta JARs are
> > distributed with correct version information in them. This will not
>
> resolve
>
> > the JAR hell of conflicts, but it will allow folk to be able to document
> > what exact versions they use of libraries & track down environmental
>
> issues.
>
> > Just to attempt to help, here

Re: Managing versions of Apache Jakarta software

[Peter Donald]

On Fri, 29 Mar 2002 07:49, Andrew C. Oliver wrote:
> *gets the feeling that the project marketing campaign for Maven has
> begun and wonders if he bought into a time share and singed up for a
> free seminar by accident*

The funny thing is that some of the people marketing maven haven't even 
downloaded or used it yet :)

-- 
Cheers,

Pete


 These aren't the droids you're 
 looking for. Move along. 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Leo Simons]

and to think I haven't even downloaded it yet! :D

> *gets the feeling that the project marketing campaign for Maven has 
> begun and wonders if he bought into a time share and singed up for a 
> free seminar by accident*
> 
> Leo Simons wrote:
> 
> >It would also be very nice if this were rolled into Maven :)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[ajack]

I guess you folk have seen so many adhoc suggestions that you tend to
attempt to form a consistent guideline out of them. I'm not convinced this
particular approach has sufficient merit, or that there aren't better ones,
it was just an idea I threw out based on initial findings. I am game to
contribute what I can, but is this the forum? Do I become some owner of
this, or what? I guess I need Jakarta contributions 101 before I go much
further...

That said, I am not sure a guideline is the place to go, and if I am asked
to contributed, I guess I'd have to do it based upon my own beliefs. I feel
that document (or manifest) based version management is too passive. When I
found Javasoft's versioning mechanism was in JAR files it seemed clear why
it has so little adoption [hell, I thought nothing exists, and I'm sure most
folk think that.] Personally I feel investment would be better served in a
"commons-versioning" [just made that up, hope I didn't upset some "version4j
folk"] with some "active" classes (including dependency checking, start-up
logging of version numbers, etc).

I wish Java had a java.lang.Version class, 'cos their java.lang.Package
class [from a few hours of poking at it & class loader] doesn't seem to cut
it. That said, if it doesn't, perhaps a commons-logging type package could
be formed, that filled the gap (and perhaps eventually showed Javasoft the
need for one.)

regards,

Adam
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 28, 2002 1:33 PM
To: Jakarta General List
Subject: Re: Managing versions of Apache Jakarta software


Well, at this point Adam, we don't so much has have a written guideline
for creating a Jakarta release, so adding versioning to a non-existent
guidelines poses something of a challenge :O)

I have started some notes for a Release Manager's guide at

http://jakarta.apache.org/site/guides.html

What would be most helpful is that if you rolled your notes and
experiences into a HOW-TO that the Release Managers might easily follow.
As a deployment manager using several Jakarta products, you sound like
just the person to write it.

It is really not possible for use to create a standard release mechanism
by fiat. So the next best thing is to make the "right" way the easy way,
but giving people some simple instructions to follow. We're all
interested in versioning, and run into the same problems you have; it's
really a matter of documenting a procedure people can follow, and that
we can point to if missed.

-Ted.


ajack wrote:
>
> All,
>
> I've been lucky enough to have benefited from a lot of the excellent
> packages put out be this community, e.g.
ANT/XERCES/LOG4J/XALAN/SOAP2.2/AXIS
> etc etc, and I thank you all for that. Recently however my utilization of
a
> lot of Apache software has bitten me (commons-logging in AXIS in this
case),
> and it all comes down to "JAR version hell" & conflicts between various
> versions delivered with various components.
>
> Upon investigation I see that some Jakarta projects distribute JARs with
> version information inside (notably log4j, XALAN) and some do not (notable
> AXIS and commons-logging, which is sad since they are newer and changing,
so
> need it badly.)
>
> Please please please make it a standard that all Jakarta JARs are
> distributed with correct version information in them. This will not
resolve
> the JAR hell of conflicts, but it will allow folk to be able to document
> what exact versions they use of libraries & track down environmental
issues.
>
> Just to attempt to help, here are some things I have found:
>
> Javasoft did provide a JAR versioning, albeit [unfortunately] in a
manifest
> file, not in the code [so not great for keeping in synch, IMHO].
>
>
http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecificat
> ion.html
> http://java.sun.com/products/jdk/1.2/docs/guide/versioning/
> http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html
>
> Here is a sample manifest from LOG4J:
>
> Manifest-version: 1.0
>
> Name: org/apache/log4j/
> Implementation-Title: log4j
> Implementation-Version: 1.1.3
> Implementation-Vendor: "Apache Software Foundation"
>
> Now, it occurred to me that ANT would be the best tool to use for keeping
> manifest files in synchronization with code/releases, but I found [not
that
> there may not exist] no easy way to do this with built in commands.
>
> That said I saw a couple of ways of managing the manifest within apache
ant
> scripts, the simplest in log4j that does a search and replace in a
template
> jar to set the version string:
>
>   
> 
> 
>filt

Re: Managing versions of Apache Jakarta software

[Andrew C. Oliver]

*gets the feeling that the project marketing campaign for Maven has 
begun and wonders if he bought into a time share and singed up for a 
free seminar by accident*

Leo Simons wrote:

>It would also be very nice if this were rolled into Maven :)
>
>cheers,
>
>- Leo
>
>>Well, at this point Adam, we don't so much has have a written guideline
>>for creating a Jakarta release, so adding versioning to a non-existent
>>guidelines poses something of a challenge :O)
>>
>
>>>Please please please make it a standard that all Jakarta JARs are
>>>distributed with correct version information in them.
>>>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing versions of Apache Jakarta software

[Leo Simons]

It would also be very nice if this were rolled into Maven :)

cheers,

- Leo

> Well, at this point Adam, we don't so much has have a written guideline
> for creating a Jakarta release, so adding versioning to a non-existent
> guidelines poses something of a challenge :O)

> > Please please please make it a standard that all Jakarta JARs are
> > distributed with correct version information in them.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Managing versions of Apache Jakarta software

[Ted Husted]

Well, at this point Adam, we don't so much has have a written guideline
for creating a Jakarta release, so adding versioning to a non-existent
guidelines poses something of a challenge :O)

I have started some notes for a Release Manager's guide at 

http://jakarta.apache.org/site/guides.html

What would be most helpful is that if you rolled your notes and
experiences into a HOW-TO that the Release Managers might easily follow.
As a deployment manager using several Jakarta products, you sound like
just the person to write it. 

It is really not possible for use to create a standard release mechanism
by fiat. So the next best thing is to make the "right" way the easy way,
but giving people some simple instructions to follow. We're all
interested in versioning, and run into the same problems you have; it's
really a matter of documenting a procedure people can follow, and that
we can point to if missed.

-Ted.


ajack wrote:
> 
> All,
> 
> I've been lucky enough to have benefited from a lot of the excellent
> packages put out be this community, e.g. ANT/XERCES/LOG4J/XALAN/SOAP2.2/AXIS
> etc etc, and I thank you all for that. Recently however my utilization of a
> lot of Apache software has bitten me (commons-logging in AXIS in this case),
> and it all comes down to "JAR version hell" & conflicts between various
> versions delivered with various components.
> 
> Upon investigation I see that some Jakarta projects distribute JARs with
> version information inside (notably log4j, XALAN) and some do not (notable
> AXIS and commons-logging, which is sad since they are newer and changing, so
> need it badly.)
> 
> Please please please make it a standard that all Jakarta JARs are
> distributed with correct version information in them. This will not resolve
> the JAR hell of conflicts, but it will allow folk to be able to document
> what exact versions they use of libraries & track down environmental issues.
> 
> Just to attempt to help, here are some things I have found:
> 
> Javasoft did provide a JAR versioning, albeit [unfortunately] in a manifest
> file, not in the code [so not great for keeping in synch, IMHO].
> 
> http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecificat
> ion.html
> http://java.sun.com/products/jdk/1.2/docs/guide/versioning/
> http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html
> 
> Here is a sample manifest from LOG4J:
> 
> Manifest-version: 1.0
> 
> Name: org/apache/log4j/
> Implementation-Title: log4j
> Implementation-Version: 1.1.3
> Implementation-Vendor: "Apache Software Foundation"
> 
> Now, it occurred to me that ANT would be the best tool to use for keeping
> manifest files in synchronization with code/releases, but I found [not that
> there may not exist] no easy way to do this with built in commands.
> 
> That said I saw a couple of ways of managing the manifest within apache ant
> scripts, the simplest in log4j that does a search and replace in a template
> jar to set the version string:
> 
>   
> 
> 
>filtering="true"/>
>   
> 
> and then later used the manifest attribute on the jar task:
> 
>  ...
> manifest="${jar.dest}/manifest.mf"
> />
> 
> Please look at Jakarta projects to see if versioning is missing, and please
> look at adding it. As I manage a deployment of a number of machines/domains
> of jakarta software the easier I can determine versions the better for
> resolving issues. I would believe this would help other users also.
> 
> Thanks in advance of any consideration.
> 
> regards,
> 
> Adam
> --
> Open Business Interchange: 
> The Revolutionary B2Bi Web Service ...
> 
> 
> 
> Here is the XALAN manifest:
> 
> Manifest-Version: 1.0
> Main-Class: org.apache.xalan.xslt.Process
> Created-By: 1.2.2 (Sun Microsystems Inc.)
> Class-Path: jaxp.jar xerces.jar crimson.jar xml-apis.jar
> 
> Name: org/apache/xml
> Implementation-Vendor: Apache Software Foundation
> Implementation-URL: http://xml.apache.org/xalan-j/dist/
> Implementation-Version: 2.2.D14
> Implementation-Title: org.apache.xml
> Comment: DTM implementation and utilities
> 
> Name: org/apache/xpath
> Implementation-Vendor: Apache Software Foundation
> Implementation-URL: http://xml.apache.org/xalan-j/dist/
> Implementation-Version: 2.2.D14
> Implementation-Title: org.apache.xpath
> Comment: XPath engine
> 
> Name: org/apache/xalan
> Specification-Title: Java API for XML Processing
> Specification-Vendor: Sun Microsystems Inc.
> Implementation-Vendor: Apache Software Foundation
> Implementation-URL: http://xml.apache.org/xalan-j/dist/
> Specification-Version: 1.1
> Implementation-Version: 2.2.D14
> Implementation-Title: org.apache.xalan
> Comment: Main Xalan engine implementing TrAX/JAXP
> 
> --
> To unsubscribe, e-mail:   

Managing versions of Apache Jakarta software

[ajack]

All,

I've been lucky enough to have benefited from a lot of the excellent
packages put out be this community, e.g. ANT/XERCES/LOG4J/XALAN/SOAP2.2/AXIS
etc etc, and I thank you all for that. Recently however my utilization of a
lot of Apache software has bitten me (commons-logging in AXIS in this case),
and it all comes down to "JAR version hell" & conflicts between various
versions delivered with various components.

Upon investigation I see that some Jakarta projects distribute JARs with
version information inside (notably log4j, XALAN) and some do not (notable
AXIS and commons-logging, which is sad since they are newer and changing, so
need it badly.)

Please please please make it a standard that all Jakarta JARs are
distributed with correct version information in them. This will not resolve
the JAR hell of conflicts, but it will allow folk to be able to document
what exact versions they use of libraries & track down environmental issues.

Just to attempt to help, here are some things I have found:

Javasoft did provide a JAR versioning, albeit [unfortunately] in a manifest
file, not in the code [so not great for keeping in synch, IMHO].


http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecificat
ion.html
http://java.sun.com/products/jdk/1.2/docs/guide/versioning/
http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html

Here is a sample manifest from LOG4J:

Manifest-version: 1.0

Name: org/apache/log4j/
Implementation-Title: log4j
Implementation-Version: 1.1.3
Implementation-Vendor: "Apache Software Foundation"

Now, it occurred to me that ANT would be the best tool to use for keeping
manifest files in synchronization with code/releases, but I found [not that
there may not exist] no easy way to do this with built in commands.

That said I saw a couple of ways of managing the manifest within apache ant
scripts, the simplest in log4j that does a search and replace in a template
jar to set the version string:

  



  

and then later used the manifest attribute on the jar task:



Please look at Jakarta projects to see if versioning is missing, and please
look at adding it. As I manage a deployment of a number of machines/domains
of jakarta software the easier I can determine versions the better for
resolving issues. I would believe this would help other users also.

Thanks in advance of any consideration.

regards,

Adam
--
Open Business Interchange: 
The Revolutionary B2Bi Web Service ...




Here is the XALAN manifest:

Manifest-Version: 1.0
Main-Class: org.apache.xalan.xslt.Process
Created-By: 1.2.2 (Sun Microsystems Inc.)
Class-Path: jaxp.jar xerces.jar crimson.jar xml-apis.jar

Name: org/apache/xml
Implementation-Vendor: Apache Software Foundation
Implementation-URL: http://xml.apache.org/xalan-j/dist/
Implementation-Version: 2.2.D14
Implementation-Title: org.apache.xml
Comment: DTM implementation and utilities

Name: org/apache/xpath
Implementation-Vendor: Apache Software Foundation
Implementation-URL: http://xml.apache.org/xalan-j/dist/
Implementation-Version: 2.2.D14
Implementation-Title: org.apache.xpath
Comment: XPath engine

Name: org/apache/xalan
Specification-Title: Java API for XML Processing
Specification-Vendor: Sun Microsystems Inc.
Implementation-Vendor: Apache Software Foundation
Implementation-URL: http://xml.apache.org/xalan-j/dist/
Specification-Version: 1.1
Implementation-Version: 2.2.D14
Implementation-Title: org.apache.xalan
Comment: Main Xalan engine implementing TrAX/JAXP


--
To unsubscribe, e-mail:   
For additional commands, e-mail: