RE: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
I guess that would help. However, a challenge for me is that everytime I add a dependency to my project.xml I also need to inform gump. As I have gotton more and more used to Maven, I don't even think about dependencies beyond manipulating project.xml. However, you are right that the module reference being able to point to external source repositories addresses the access issue. Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 11:19 AM To: Gump code and data Subject: Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml On Tuesday 26 October 2004 16:34, Eric Pugh wrote: From my perspective, I see it as a major issue that the only way to create the gump descriptor is to have CVS access to gump. Which is fine for ASF folks, but raises the bar for other outside to participate. I can see, at least for the Maven POM projects, that building the gump descriptor at runtime would lower the barrier to participation. I don't think this changes anything. You would still need to instruct Gump to use Maven POM somewhere, which must be done by ASF committers. And today, you can put in a module reference in the profile/gump.xml that points to external source repositories, i.e. let outside folks handle it. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
On Tue, 26 Oct 2004, Brett Porter [EMAIL PROTECTED] wrote: As I understand it, the general problem here is that the project.xml changes, and the gump descriptor is not updated. The version is just a reflection of this, and it probably changes the most. Is this correct? Yes, and I agree with the long term goal to use project.xml directly. This certainly clashes with Stefano's quest to move all metadata into Gump's own repo 8-) I'd really like to go down the track of having gump effectively run maven gump for a project, then use the generated descriptor instead. What is involved in that from the gump end? I assume since it happened for magic, it must be possible. It doesn't happen for Magic. The projects using Magic do the equivalent of maven gump and add the generated descriptor to Gump's metadata set IIUC. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
On Tuesday 26 October 2004 17:39, Eric Pugh wrote: I guess that would help. However, a challenge for me is that everytime I add a dependency to my project.xml I also need to inform gump. As I have gotton more and more used to Maven, I don't even think about dependencies beyond manipulating project.xml. I agree with you on this point, and... However, you are right that the module reference being able to point to external source repositories addresses the access issue. ... this was the only thing I was commenting on. Sorry if that wasn't clear. I think we all want to minimize the synchronization between a project's dependency resolution system and Gump's resolution system. Magic has a solution, since Gump support was built-in from the beginning. OTOH, Magic is only used in Avalon, and that is being shut down, so even though it is a highly capable build system, its relevance here is diminishing rapidly. Maven is shakey, i.e. automatic generation doesn't work, mostly because it doesn't have explicit Gump treatment in the POM. If Maven is not going to change the POM DTD to accommodate for Gump (== unlikely, since it would also require the projects to use that feature), then to achieve completely automated generation of Gump descriptors from the Maven Gump goal, we need to ensure that projects are name-synced with Maven artifact IDs, or have an artifactId attribute for each of the projects. Ant projects are treated according to a template of classpath injection, BUT some projects do their own downloads, and I wonder if there are some that actually bypasses the Gump intentions. This is IMHO a grayish area, which I would like to investigate further. Perhaps it could be tested by setting a security policy for Ant which disallowed network connections. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
On Tuesday 26 October 2004 17:50, Stefan Bodewig wrote: I'd really like to go down the track of having gump effectively run maven gump for a project, then use the generated descriptor instead. What is involved in that from the gump end? I assume since it happened for magic, it must be possible. It doesn't happen for Magic. The projects using Magic do the equivalent of maven gump and add the generated descriptor to Gump's metadata set IIUC. Yes, that is correct. If we had some better SVN support in Ant, the Gump descriptor would be generated and committed automatically with every build. Alternatively, Steve wanted Gump to ask Magic to generate the Gump descriptor before executing, i.e. before building the project models. An alternative to that, was we discussed to have a servlet generating it upon the http:// request, but that never took off either. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
Stefan Bodewig wrote: On Tue, 26 Oct 2004, Brett Porter [EMAIL PROTECTED] wrote: As I understand it, the general problem here is that the project.xml changes, and the gump descriptor is not updated. The version is just a reflection of this, and it probably changes the most. Is this correct? Yes, and I agree with the long term goal to use project.xml directly. This certainly clashes with Stefano's quest to move all metadata into Gump's own repo 8-) Not necessarely. The idea to move the data in-house is to allow us to reach equilibrium faster. The long term goal is exactly what Eric describes: you should name your dependencies only once and gump should do the work for you. I'd really like to go down the track of having gump effectively run maven gump for a project, then use the generated descriptor instead. What is involved in that from the gump end? I assume since it happened for magic, it must be possible. It doesn't happen for Magic. The projects using Magic do the equivalent of maven gump and add the generated descriptor to Gump's metadata set IIUC. which, IMO, is a pretty broken design. Gump should be able to digest any metadata format that is required to build stuff. But obviously, that implies that people stop being allergic to python. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
Niclas Hedhman wrote: On Tuesday 26 October 2004 17:39, Eric Pugh wrote: I guess that would help. However, a challenge for me is that everytime I add a dependency to my project.xml I also need to inform gump. As I have gotton more and more used to Maven, I don't even think about dependencies beyond manipulating project.xml. I agree with you on this point, and... However, you are right that the module reference being able to point to external source repositories addresses the access issue. ... this was the only thing I was commenting on. Sorry if that wasn't clear. I think we all want to minimize the synchronization between a project's dependency resolution system and Gump's resolution system. Magic has a solution, since Gump support was built-in from the beginning. I'm sorry but that solution is just broken. It should be gump transforming data, not projects. OTOH, Magic is only used in Avalon, and that is being shut down, so even though it is a highly capable build system, its relevance here is diminishing rapidly. Very true. Maven is shakey, i.e. automatic generation doesn't work, mostly because it doesn't have explicit Gump treatment in the POM. If Maven is not going to change the POM DTD to accommodate for Gump (== unlikely, since it would also require the projects to use that feature), then to achieve completely automated generation of Gump descriptors from the Maven Gump goal, we need to ensure that projects are name-synced with Maven artifact IDs, or have an artifactId attribute for each of the projects. Or we can just adopt Maven POM as our metadata format. Ant projects are treated according to a template of classpath injection, BUT some projects do their own downloads, and I wonder if there are some that actually bypasses the Gump intentions. Yes, this is where I think Maven surpasses Ant in design, in respect to Gump integrability: ant is a lot less declarative. which means it's much easier for people to do things that we don't have control over from the outside. Stefan, thoughts? This is IMHO a grayish area, which I would like to investigate further. Perhaps it could be tested by setting a security policy for Ant which disallowed network connections. Wouldn't that make projects fail? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
On Tue, 26 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Niclas Hedhman wrote: Ant projects are treated according to a template of classpath injection, BUT some projects do their own downloads, and I wonder if there are some that actually bypasses the Gump intentions. Yes, this is where I think Maven surpasses Ant in design, in respect to Gump integrability: ant is a lot less declarative. which means it's much easier for people to do things that we don't have control over from the outside. Stefan, thoughts? I trust build.sysclasspath a lot 8-) Seriously, in all built-in Ant tasks you'll have a very hard time to defeat Gump's intentions. And custom tasks will have to explicitly avoid Ant's own infrastructure (like AntClassLoader) for that. We have a bunch of project pulling down dependencies from all over the place and the result is just ignored by Ant in Gump. The main exception is the manifest's Class-Path attribute, but as long as you use URLClassLoader (and why would you want to rewrite that) there is nothing much you can do. This is not a comment on whether Ant or Maven is better designed for any purpose. I just want to say that it is really hard to bypass Gump's control of the classpath using Ant. I'm not sure how mandatory/optional support for jar overrides in Maven is. Perhaps it could be tested by setting a security policy for Ant which disallowed network connections. Wouldn't that make projects fail? Certainly. We've seen this a couple of times. Many javadoc tasks will fail, for example, since the link to Sun javadoc sites and the javadoc executable tries to download the package index files from there. Cactus and Axis need network access (at least to localhost) for tests ... Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jakarta-commons.xml
On Monday 25 October 2004 15:04, [EMAIL PROTECTED] wrote:
Now, is there a way to 'inject' the version into maven? otherwise we'll
have to continue updating these names as they projects change versions
One can access the POM as properties, such as ${pom.artifactId}, so there is a
small chance that setting pom.currentVersion would work, but I suspect that
the last-takes-precendence principle often used in Maven will prevail.
Cheers
Niclas
--
+--//---+
/ http://www.bali.ac/
/ http://niclas.hedhman.org /
+--//---+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
I had to get some background from Eric on IRC about this, as I
couldn't find the original message. I hope I'm on the right track.
I'll first discuss the general problem I see here and solutions, but
there is a fix for this specific issue at the end I think.
As I understand it, the general problem here is that the project.xml
changes, and the gump descriptor is not updated. The version is just a
reflection of this, and it probably changes the most. Is this correct?
I'd really like to go down the track of having gump effectively run
maven gump for a project, then use the generated descriptor instead.
What is involved in that from the gump end? I assume since it happened
for magic, it must be possible.
I realise there are customisations people make, and there are two
possible solutions - preferably to come up with a way to describe them
elsewhere so the descriptor can continue to be generated, or for the
descriptor generation to intelligently update one that already exists
without removing the customisations.
There may also be some builds doing funny things such that generation
won't work - and they should be allowed to generate a descriptor in
this case. They just need to take responsibility to keep it up to
date. This shouldn't happen if they are following the Maven guidelines
for a project set up.
As much as I'd like to get the correct solution, you can probably
overcome this now by specifying
maven.final.name=expected_jar_name
in gump's generated build.properties, which will result in
target/expected_jar_name.jar
This takes the version out of the equation. It may not work for all
situations, but should be a good start. Anyone doing funny things in
generating artifacts are going to have to take responsibility for the
gump descriptor.
Cheers,
Brett
On Mon, 25 Oct 2004 11:01:09 -0400, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Niclas Hedhman wrote:
On Monday 25 October 2004 15:04, [EMAIL PROTECTED] wrote:
Now, is there a way to 'inject' the version into maven? otherwise we'll
have to continue updating these names as they projects change versions
One can access the POM as properties, such as ${pom.artifactId}, so there is a
small chance that setting pom.currentVersion would work, but I suspect that
the last-takes-precendence principle often used in Maven will prevail.
Hmmm, that is a very serious problem.
Brett (or any other maven knowledgeable person around here), is there
any way to take precedence over the maven POM from the outside?
--
Stefano.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
Brett Porter wrote: I had to get some background from Eric on IRC about this, as I couldn't find the original message. I hope I'm on the right track. I'll first discuss the general problem I see here and solutions, but there is a fix for this specific issue at the end I think. As I understand it, the general problem here is that the project.xml changes, and the gump descriptor is not updated. Well, the problem is that the way gump works is based on the fact that ant properties can be injected into the build system, therefore gump can overload the internal properties with external ones, for example, with the version property. The version is just a reflection of this, and it probably changes the most. Is this correct? The projects know what version they are working on, but gump doesn't care and discards that versioning information and just build using dates as versions. I'd really like to go down the track of having gump effectively run maven gump for a project, then use the generated descriptor instead. This might help, yes. What is involved in that from the gump end? I assume since it happened for magic, it must be possible. I'm ready to help out to make this possible. I realise there are customisations people make, and there are two possible solutions - preferably to come up with a way to describe them elsewhere so the descriptor can continue to be generated, or for the descriptor generation to intelligently update one that already exists without removing the customisations. There may also be some builds doing funny things such that generation won't work - and they should be allowed to generate a descriptor in this case. They just need to take responsibility to keep it up to date. This shouldn't happen if they are following the Maven guidelines for a project set up. I'm totally in favor of using a straight out-of-the-box maven project descriptor as an input for gump. As much as I'd like to get the correct solution, you can probably overcome this now by specifying maven.final.name=expected_jar_name in gump's generated build.properties, which will result in target/expected_jar_name.jar This takes the version out of the equation. It may not work for all situations, but should be a good start. Anyone doing funny things in generating artifacts are going to have to take responsibility for the gump descriptor. I will apply this fix for now, thanks much, but I'm with you that we should make it possible to mount a POM file instead of gump project descriptor, if your project wishes to do so. What do others think? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
cvs commit: gump/project jakarta-commons.xml
bodewig 2004/09/12 23:40:57 Modified:project jakarta-commons.xml Log: Jelly seems to need commons-lang now Revision ChangesPath 1.143 +1 -0 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.142 retrieving revision 1.143 diff -u -r1.142 -r1.143 --- jakarta-commons.xml 11 Sep 2004 16:01:15 - 1.142 +++ jakarta-commons.xml 13 Sep 2004 06:40:57 - 1.143 @@ -392,6 +392,7 @@ depend project=commons-beanutils-core runtime=true/ depend project=commons-collections runtime=true/ depend project=commons-jexl/ +depend project=commons-lang runtime=true/ depend project=commons-logging runtime=true/ depend project=packaged-dom4j/ depend project=junit/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
bodewig 2004/09/12 23:43:19 Modified:project jakarta-commons.xml Log: commons-configuration seems to need beanutils-core now Revision ChangesPath 1.144 +1 -0 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.143 retrieving revision 1.144 diff -u -r1.143 -r1.144 --- jakarta-commons.xml 13 Sep 2004 06:40:57 - 1.143 +++ jakarta-commons.xml 13 Sep 2004 06:43:19 - 1.144 @@ -651,6 +651,7 @@ depend project=ant inherit=runtime/ depend project=xml-xerces/ +depend project=commons-beanutils-core/ depend project=commons-collections/ depend project=commons-digester/ depend project=commons-lang/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
leosutic2004/09/11 09:01:15 Modified:project jakarta-commons.xml Log: Modified dependencies for Commons Attributes. Revision ChangesPath 1.142 +1 -5 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.141 retrieving revision 1.142 diff -u -r1.141 -r1.142 --- jakarta-commons.xml 7 Sep 2004 12:15:32 - 1.141 +++ jakarta-commons.xml 11 Sep 2004 16:01:15 - 1.142 @@ -33,9 +33,7 @@ value=commons-attributes-compiler-@@DATE@@/ /ant depend project=ant inherit=runtime/ -depend project=xml-xerces/ -depend project=commons-logging/ -depend project=xjavadoc runtime=true/ +depend project=qdox runtime=true/ depend project=junit/ work nested=attributes/target/classes/ @@ -394,7 +392,6 @@ depend project=commons-beanutils-core runtime=true/ depend project=commons-collections runtime=true/ depend project=commons-jexl/ -depend project=commons-lang runtime=true/ depend project=commons-logging runtime=true/ depend project=packaged-dom4j/ depend project=junit/ @@ -654,7 +651,6 @@ depend project=xml-xerces/ depend project=commons-collections/ -depend project=commons-beanutils-core/ depend project=commons-digester/ depend project=commons-lang/ depend project=commons-logging/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
bodewig 2004/09/07 05:15:32 Modified:project jakarta-commons.xml Log: Jelly needs commons-lang Revision ChangesPath 1.141 +1 -0 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.140 retrieving revision 1.141 diff -u -r1.140 -r1.141 --- jakarta-commons.xml 14 Aug 2004 16:45:59 - 1.140 +++ jakarta-commons.xml 7 Sep 2004 12:15:32 - 1.141 @@ -394,6 +394,7 @@ depend project=commons-beanutils-core runtime=true/ depend project=commons-collections runtime=true/ depend project=commons-jexl/ +depend project=commons-lang runtime=true/ depend project=commons-logging runtime=true/ depend project=packaged-dom4j/ depend project=junit/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
ajack 2004/08/14 09:45:59 Modified:project jakarta-commons.xml Log: Build failures indicate that commons-config now uses commons-beanutils, let's hope this one (core) is enough. Revision ChangesPath 1.140 +1 -0 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.139 retrieving revision 1.140 diff -u -r1.139 -r1.140 --- jakarta-commons.xml 12 Jul 2004 19:23:32 - 1.139 +++ jakarta-commons.xml 14 Aug 2004 16:45:59 - 1.140 @@ -653,6 +653,7 @@ depend project=xml-xerces/ depend project=commons-collections/ +depend project=commons-beanutils-core/ depend project=commons-digester/ depend project=commons-lang/ depend project=commons-logging/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
bodewig 2004/07/05 00:57:27 Modified:project jakarta-commons.xml Log: JXPath needs commons-logging when running the tests since beanutils requires it Revision ChangesPath 1.135 +2 -2 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.134 retrieving revision 1.135 diff -u -r1.134 -r1.135 --- jakarta-commons.xml 30 Jun 2004 08:22:48 - 1.134 +++ jakarta-commons.xml 5 Jul 2004 07:57:27 - 1.135 @@ -32,7 +32,7 @@ /ant depend project=ant inherit=runtime/ depend project=xml-xerces/ -depend project=commons-logging/ +depend project=commons-logging runtime=true/ depend project=junit/ home nested=beanutils/dist/ work nested=beanutils/target/classes/ @@ -410,7 +410,7 @@ /ant depend project=ant inherit=runtime/ depend project=jakarta-site2 inherit=all/ -depend project=commons-beanutils-core runtime=true/ +depend project=commons-beanutils-core runtime=true inherit=runtime/ work nested=jxpath/target/classes/ work nested=jxpath/target/test-classes/ home nested=jxpath/dist/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
bodewig 2004/06/30 01:22:48 Modified:project jakarta-commons.xml Log: Throw in some work entries for jxpath to make tests compile and maybe even run Revision ChangesPath 1.134 +2 -0 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.133 retrieving revision 1.134 diff -u -r1.133 -r1.134 --- jakarta-commons.xml 25 May 2004 21:19:33 - 1.133 +++ jakarta-commons.xml 30 Jun 2004 08:22:48 - 1.134 @@ -411,6 +411,8 @@ depend project=ant inherit=runtime/ depend project=jakarta-site2 inherit=all/ depend project=commons-beanutils-core runtime=true/ +work nested=jxpath/target/classes/ +work nested=jxpath/target/test-classes/ home nested=jxpath/dist/ jar name=commons-jxpath.jar/ javadoc nested=jxpath/dist/docs/api/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
rdonkin 2004/05/25 14:19:33 Modified:project jakarta-commons.xml Log: Fixed bad path Revision ChangesPath 1.133 +3 -3 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.132 retrieving revision 1.133 diff -u -r1.132 -r1.133 --- jakarta-commons.xml 25 May 2004 21:18:20 - 1.132 +++ jakarta-commons.xml 25 May 2004 21:19:33 - 1.133 @@ -48,7 +48,7 @@ packageorg.apache.commons.beanutils/package descriptionBean Utilities (Bean Collections)/description url href=http://jakarta.apache.org/commons/beanutils.html/ -ant basedir=beanutils/optional/beancollections target=jar +ant basedir=beanutils/optional/bean-collections target=jar property name=junit.home reference=home project=junit/ /ant depend project=ant inherit=runtime/ @@ -57,8 +57,8 @@ depend project=commons-beanutils-core/ depend project=commons-collections/ depend project=junit/ -home nested=beanutils/optional/beancollections/dist/ -work nested=beanutils/optional/beancollections/target/classes/ +home nested=beanutils/optional/bean-collections/dist/ +work nested=beanutils/optional/bean-collections/target/classes/ jar name=commons-beanutils-bean-collections.jar/ license name=LICENSE/ javadoc nested=beanutils/dist/docs/api/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-beanutils - commons-beanutils-core (was Re: cvs commit: gump/project jakarta-commons.xml)
I see a few projects affected by the beanutils split. If beanutil-core is likely what folks want for beanutils we could make transition smoother using an alias technique (like the one used when ant went TLP): project name=jakarta-ant depend project=ant inherit=jars/ /project project name=ant ... Either that or we just keep working through config fixes a little longer. regards, Adam - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 3:19 PM Subject: cvs commit: gump/project jakarta-commons.xml rdonkin 2004/05/25 14:19:33 Modified:project jakarta-commons.xml Log: Fixed bad path Revision ChangesPath 1.133 +3 -3 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.132 retrieving revision 1.133 diff -u -r1.132 -r1.133 --- jakarta-commons.xml 25 May 2004 21:18:20 - 1.132 +++ jakarta-commons.xml 25 May 2004 21:19:33 - 1.133 @@ -48,7 +48,7 @@ packageorg.apache.commons.beanutils/package descriptionBean Utilities (Bean Collections)/description url href=http://jakarta.apache.org/commons/beanutils.html/ -ant basedir=beanutils/optional/beancollections target=jar +ant basedir=beanutils/optional/bean-collections target=jar property name=junit.home reference=home project=junit/ /ant depend project=ant inherit=runtime/ @@ -57,8 +57,8 @@ depend project=commons-beanutils-core/ depend project=commons-collections/ depend project=junit/ -home nested=beanutils/optional/beancollections/dist/ -work nested=beanutils/optional/beancollections/target/classes/ +home nested=beanutils/optional/bean-collections/dist/ +work nested=beanutils/optional/bean-collections/target/classes/ jar name=commons-beanutils-bean-collections.jar/ license name=LICENSE/ javadoc nested=beanutils/dist/docs/api/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
rdonkin 2004/05/24 13:03:14 Modified:project jakarta-commons.xml Log: Added build for digester-rss Revision ChangesPath 1.130 +20 -0 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.129 retrieving revision 1.130 diff -u -r1.129 -r1.130 --- jakarta-commons.xml 17 May 2004 19:17:39 - 1.129 +++ jakarta-commons.xml 24 May 2004 20:03:14 - 1.130 @@ -219,6 +219,26 @@ from=Ted Husted lt;[EMAIL PROTECTED]gt;/ /project + project name=commons-digester-rss +packageorg.apache.commons.digester.rss/package +descriptionDigester RSS Example/description +url href=http://jakarta.apache.org/commons/digester.html/ +ant basedir=digester/src/examples/rss target=dist/ +depend project=ant inherit=runtime/ +depend project=xml-xerces/ +depend project=junit/ +depend project=commons-beanutils/ +depend project=commons-digester/ +depend project=commons-collections/ +depend project=commons-logging/ +home nested=digester/src/examples/rss/dist/ +jar name=commons-digester-rss.jar/ +javadoc nested=digester/src/examples/rss/dist/docs/api/ + +nag to=[EMAIL PROTECTED] + from=Robert Burrell Donkin lt;[EMAIL PROTECTED]gt;/ + /project + project name=commons-el packageorg.apache.commons.el/package descriptionExpression Language/description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
ajack 2004/05/17 07:46:21 Modified:project jakarta-commons.xml Log: BeanUtils appears to have t he class it is failing on, so chances are it needs a work directory. It might also need a mkdir, but we'll see. Revision ChangesPath 1.128 +2 -1 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.127 retrieving revision 1.128 diff -u -r1.127 -r1.128 --- jakarta-commons.xml 13 May 2004 22:30:47 - 1.127 +++ jakarta-commons.xml 17 May 2004 14:46:21 - 1.128 @@ -35,7 +35,8 @@ depend project=commons-collections/ depend project=commons-logging/ depend project=junit/ -home nested=beanutils/dist/ +home nested=beanutils/dist/ +work nested=beanutils/target/classes/ jar name=commons-beanutils.jar/ license name=LICENSE/ javadoc nested=beanutils/dist/docs/api/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
ajack 2004/05/13 15:30:47 Modified:project jakarta-commons.xml Log: Temporarily set C-L to work off log4j 1.2 (not CVS HEAD) Revision ChangesPath 1.127 +2 -1 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.126 retrieving revision 1.127 diff -u -r1.126 -r1.127 --- jakarta-commons.xml 10 May 2004 17:25:24 - 1.126 +++ jakarta-commons.xml 13 May 2004 22:30:47 - 1.127 @@ -444,7 +444,8 @@ ant basedir=logging target=dist/ depend project=ant inherit=runtime/ depend project=xml-xerces/ -option project=logging-log4j/ +!-- :TODO: Temporarily avoiding log4j 'CVS HEAD' -- +option project=logging-log4j-12/ option project=avalon-logkit/ home nested=logging/dist/ jar name=commons-logging.jar id=commons-logging / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
ajack 2004/05/10 10:25:24 Modified:project jakarta-commons.xml Log: Experimental change, to help commons-id Revision ChangesPath 1.126 +2 -2 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.125 retrieving revision 1.126 diff -u -r1.125 -r1.126 --- jakarta-commons.xml 4 May 2004 10:57:47 - 1.125 +++ jakarta-commons.xml 10 May 2004 17:25:24 - 1.126 @@ -447,8 +447,8 @@ option project=logging-log4j/ option project=avalon-logkit/ home nested=logging/dist/ -jar name=commons-logging.jar id=all / -jar name=commons-logging-api.jar id=api / +jar name=commons-logging.jar id=commons-logging / +jar name=commons-logging-api.jar id=commons-logging-api / javadoc nested=logging/dist/docs/api/ nag to=[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
bodewig 2004/05/04 03:57:48 Modified:project jakarta-commons.xml Log: Try to fix hermes build of commons-net in autopilot mode Revision ChangesPath 1.125 +1 -0 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.124 retrieving revision 1.125 diff -u -r1.124 -r1.125 --- jakarta-commons.xml 29 Apr 2004 07:16:12 - 1.124 +++ jakarta-commons.xml 4 May 2004 10:57:47 - 1.125 @@ -481,6 +481,7 @@ descriptionCommons Net/description ant basedir=net target=dist property name=final.name value=commons-net-@@DATE@@ / + sysproperty name=build.clonevm value=true/ /ant depend project=ant inherit=runtime/ depend project=xml-xerces/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml ws-axis.xml
bodewig 2004/04/29 00:16:12 Modified:project jakarta-commons.xml ws-axis.xml Log: clone forked VM in order to pick up system properties Revision ChangesPath 1.124 +1 -0 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.123 retrieving revision 1.124 diff -u -r1.123 -r1.124 --- jakarta-commons.xml 27 Apr 2004 18:02:30 - 1.123 +++ jakarta-commons.xml 29 Apr 2004 07:16:12 - 1.124 @@ -55,6 +55,7 @@ ant basedir=betwixt target=jar property name=final.name value=commons-betwixt-@@DATE@@/ property name=resourcedir path=betwixt/ + sysproperty name=build.clonevm value=true/ /ant !-- All Maven projects need Ant and Xerces to build. -- 1.20 +1 -0 gump/project/ws-axis.xml Index: ws-axis.xml === RCS file: /home/cvs/gump/project/ws-axis.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- ws-axis.xml 27 Feb 2004 13:33:56 - 1.19 +++ ws-axis.xml 29 Apr 2004 07:16:12 - 1.20 @@ -42,6 +42,7 @@ depend property=xalan.jar project=xml-xalan2 id=transformer/ depend property=xercesImpl.jar project=xml-xerces id=parser/ depend property=xmlParserAPIs.jar project=xml-xerces id=parser/ + sysproperty name=build.clonevm value=true/ /ant depend project=xml-xerces inherit=runtime runtime=true/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons.xml
ajack 2004/04/27 11:02:30 Modified:project jakarta-commons.xml Log: Looking at the build script, these appear to be optional, and (for a trimmed down profile) it is helpful if they are marked so. Revision ChangesPath 1.123 +2 -2 gump/project/jakarta-commons.xml Index: jakarta-commons.xml === RCS file: /home/cvs/gump/project/jakarta-commons.xml,v retrieving revision 1.122 retrieving revision 1.123 diff -u -r1.122 -r1.123 --- jakarta-commons.xml 2 Mar 2004 07:44:28 - 1.122 +++ jakarta-commons.xml 27 Apr 2004 18:02:30 - 1.123 @@ -443,8 +443,8 @@ ant basedir=logging target=dist/ depend project=ant inherit=runtime/ depend project=xml-xerces/ -depend project=logging-log4j/ -depend project=avalon-logkit/ +option project=logging-log4j/ +option project=avalon-logkit/ home nested=logging/dist/ jar name=commons-logging.jar id=all / jar name=commons-logging-api.jar id=api / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
