Re: Managing versions of Apache Jakarta software
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 jar, but unfortunately
did not include documentation for it 8-(. From Ant's own build file:
jar ...
manifest
section name=${ant.package}
attribute name=Specification-Title
value=Apache Ant /
attribute name=Specification-Version
value=${version} /
attribute name=Specification-Vendor
value=Apache Software Foundation /
attribute name=Implementation-Title
value=org.apache.tools.ant /
attribute name=Implementation-Version
value=${version} ${TODAY} /
attribute name=Implementation-Vendor
value=Apache Software Foundation /
/section
/manifest
...
/jar
This is from current CVS but it works for 1.4.1 as well.
Stefan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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. snip Thanks Jeff Prickett -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
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. ignomious self-publicity 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. /ignomious self-publicity -- Guillaume Rousse [EMAIL PROTECTED] GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
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. /ignomious self-publicity -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
*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: 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]
RE: Managing versions of Apache Jakarta software
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:
target name=prejar depends=build
mkdir dir=${jar.dest}/
filter token=version value=${version} /
copy file=${manifest.src} tofile=${jar.dest}/manifest.mf
filtering=true/
/target
and then later used the manifest attribute on the jar task:
jar jarfile=${jar.dest}/log4j-core.jar basedir=${javac.dest}
...
manifest
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Managing versions of Apache Jakarta software
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 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/VersioningSpecifica t 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
Re: Managing versions of Apache Jakarta software
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 :) kidding It also has never been built successfully with the public gump, so it truly is all hype at this point. Nudge. Nudge. /kidding - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
