Re: building Forrest (Was: [RT] fixing gump)
Niclas Hedhman wrote: David Crossley wrote: It seems that Gump is still using the old descriptor in our SVN. How do i get Gump to switch? The profile/gump.xml looks okay, but the last time that it was built was two days ago using the old descriptor. It doesn't look Ok in my checked out copy. Have you perhaps forgotten to commit it? Anyway, I have committed the change I think is necessary... Ah i see. Stefano moved Forrest and Lenya descriptors but disabled Forrest. I am beginning to understand the configuration. Thanks everyone. -- David Crossley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Magic generated Gump descriptor for magic-xdoc-plugin needs tweak
On Wed, 13 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Hi, the Gump project that used to be called saxon now is saxon7, so wherever you maintain the mapping, please adjust it and regenerate the descriptor. no, it's called saxon6 now. saxon7 already existed. OK, I got confused, thanks for the correction. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependence on mysql jdbc driver bogus?
-Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: 14 October 2004 05:44 To: Gump code and data Subject: Re: dependence on mysql jdbc driver bogus? On Thursday 14 October 2004 11:37, Stefano Mazzocchi wrote: excalibur-datasource fails to build because it depends on mm-mysql but doing a grep -r mysql . in that directory doesn't yield anything. I suspect it's a bogus dependency in their POM. Thoughts? Yes, and I have sent them a patch for its removal. And is been applied. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. Just create a project for it inside xdoclet's descriptor. Name it xdoclet-pretty or something. No need to turn it into a full installed package (which would require access to Brutus to update) IMHO. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BATCH: All dressed up, with nowhere to go...
-Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: 14 October 2004 06:59 To: Gump code and data Subject: Re: BATCH: All dressed up, with nowhere to go... On Thursday 14 October 2004 12:33, Niclas Hedhman wrote: I would suggest we mavenize xdoclet and remove jrefactory and friends since they are clearly not enough friends of gump to live in the house with him. I will start on it straight away... IIUIC, Xdoclet is not yet Mavenized. They use Ant as the build system, and call upon Maven for the documentation generation. Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. WDYT? Yep. /Steve. 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: BATCH: All dressed up, with nowhere to go...
On Thursday 14 October 2004 14:38, Stefan Bodewig wrote: On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. Just create a project for it inside xdoclet's descriptor. Name it xdoclet-pretty or something. No need to turn it into a full installed package (which would require access to Brutus to update) IMHO. Done. But not entirely sure if it will work. Review appreciated. + project name=xdoclet-prettyprinter +jar name=lib/prettyprinter.jar/ + /project -depend project=jrefactory-pretty/ +depend project=xdoclet-prettyprinter/ Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
Yesterday on IRC stefanom (who I guess is Stefan Bodewig) helped me get That's probably Stefano Mazzocchi. I need someone to install into the gump users plugin directory the avalon-meta plugin by typing: maven plugin:download -DgroupId=avalon-meta -DartifactId=avalon-meta-plugin -Dvers ion=1.4.0 Gumps all about building them from scratch. So what we really need is an avalon-meta-plugin project. Once built, the plugin dependency will take care of it. This should have been what happened with the other 3, right? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Thursday 14 October 2004 17:37, Eric Pugh wrote: merlin-unit-3.3.0.jar avalon-meta-plugin-1.4.0.jar For Maven builds; groupIdavalon/avalon-meta/groupId artifactIdavalon-meta-plugin/artifactId groupIdavalon/merlin/groupId artifactIdmerlin-unit/artifactId respectively, AND requires http://www.apache.org/dist/ as a Maven repository. I am not sure why it doesn't synchronize to ibiblio.org/maven. I thought that was automatic. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Thursday 14 October 2004 17:37, Eric Pugh wrote: As far as the error on merlin-unit, I think that in the jakarta-turbine-fulcrum.xml file we depend on avalon-merlin-unit however, in the avalon.xml file it is defined as merlin-unit, so I think I should change that to merlin-unit: depend project=avalon-merlin-unit/ to depend project=merlin-unit/ :o) No, the project here refers to the name within Gump, but I think that the following is needed; depend property=maven.jar.merlin-unit project=avalon-merlin-unit/ Brett, do you have any insight in this?? Steve? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
groupIdavalon/avalon-meta/groupId artifactIdavalon-meta-plugin/artifactId groupIdavalon/merlin/groupId artifactIdmerlin-unit/artifactId why isn't this just avalon-meta and merlin for the group? If it is so you can leverage dist/, that's not correct (see below). respectively, AND requires http://www.apache.org/dist/ as a Maven repository. I am not sure why it doesn't synchronize to ibiblio.org/maven. I thought that was automatic. /dist/java-repository/ syncs to ibiblio, which contains: http://www.apache.org/dist/java-repository/avalon-meta/plugins/avalon-meta-plugin-1.4.0.jar http://www.apache.org/dist/java-repository/merlin/jars/merlin-unit-3.3.0.jar However, I assume this is just for building with Maven regularly, as under gump it is all offline. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Thu, 14 Oct 2004, Eric Pugh [EMAIL PROTECTED] wrote: Yesterday on IRC stefanom (who I guess is Stefan Bodewig Must have been Stefano Mazzocchi ) helped me get some of the Maven plugins for building the Fulcrum components installed. So, for the fulcrum-crypto-api component( http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-crypto- api/gump_work/build_jakarta-turbine-fulcrum_fulcrum-crypto-api.html ), the good news is that last night one of them was found, Whoohoo! Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Thursday 14 October 2004 18:14, Brett Porter wrote: groupIdavalon/avalon-meta/groupId artifactIdavalon-meta-plugin/artifactId groupIdavalon/merlin/groupId artifactIdmerlin-unit/artifactId why isn't this just avalon-meta and merlin for the group? If it is so you can leverage dist/, that's not correct (see below). /dist/java-repository/ syncs to ibiblio, which contains: http://www.apache.org/dist/java-repository/avalon-meta/plugins/avalon-meta- plugin-1.4.0.jar http://www.apache.org/dist/java-repository/merlin/jars/merlin-unit-3.3.0.ja r Ok. I was WRONG. Somewhere there is a misconception... However, I assume this is just for building with Maven regularly, as under gump it is all offline. Well, Eric is having problem with his local build, so we are trying to solve two issues at the same time. Thanks for the rectification. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Standardizing on Maven names
On Wed, 13 Oct 2004, Brett Porter [EMAIL PROTECTED] wrote: I'll get rid of it and cut a new version of the plugin. Thanks. Are there any still needing mapping that need be kept? I don't know. We usually have something like tpl-project for Apache projects, so log4j went from jakarta-log4j to logging-log4j. I assume for Maven it would be just log4j. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Standardizing on Maven names
On Wed, 13 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I think, personally, that Gump and Maven should start talking about creating a more serious infrastructure and joining forces from the POM point of view. I think we are already doing that with Brett helping out a lot 8-) In the end we'll find situations where we are unable to map project names one-to-one to Maven and then we will need to not only declare the arifact but also the group on the jar individually. Until then, we should try to get as close to each other as possible - and if the naming will map to whatever the repository effort comes up with, even better. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Some progress on Fulcrum Component Builds!
I think I sorted out my local build issues.. It was an aspect of bad network connectivity causing the merlin-unit unit testing to not download all the resources it needed. At this point, I have been able to successfully build ALL the fulcrum components. Now, I believe for the gump builds, maven plugins must already be built, they aren't dynamically built yet, correct? Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 11:47 AM To: Gump code and data Subject: Re: Some progress on Fulcrum Component Builds! On Thursday 14 October 2004 18:14, Brett Porter wrote: groupIdavalon/avalon-meta/groupId artifactIdavalon-meta-plugin/artifactId groupIdavalon/merlin/groupId artifactIdmerlin-unit/artifactId why isn't this just avalon-meta and merlin for the group? If it is so you can leverage dist/, that's not correct (see below). /dist/java-repository/ syncs to ibiblio, which contains: http://www.apache.org/dist/java-repository/avalon-meta/plugins/ava lon-meta- plugin-1.4.0.jar http://www.apache.org/dist/java-repository/merlin/jars/merlin-unit -3.3.0.ja r Ok. I was WRONG. Somewhere there is a misconception... However, I assume this is just for building with Maven regularly, as under gump it is all offline. Well, Eric is having problem with his local build, so we are trying to solve two issues at the same time. Thanks for the rectification. 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: dependence on mysql jdbc driver bogus?
Stefano Mazzocchi wrote: excalibur-datasource fails to build because it depends on mm-mysql but doing a grep -r mysql . in that directory doesn't yield anything. I suspect it's a bogus dependency in their POM. Thoughts? Niclas discovered the same thing. I think he committed the change, or at least has a patch ready. I got his message something like 5 minutes ago. -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependence on mysql jdbc driver bogus?
On Thursday 14 October 2004 22:00, Berin Loritsch wrote: Stefano Mazzocchi wrote: excalibur-datasource fails to build because it depends on mm-mysql but doing a grep -r mysql . in that directory doesn't yield anything. I suspect it's a bogus dependency in their POM. Thoughts? Niclas discovered the same thing. I think he committed the change, or at least has a patch ready. I got his message something like 5 minutes ago. Steve committed it. I don't have commit rights in Excalibur. I am just trying to get Excalibur work with Gump, since noone else is interested enough... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Niclas Hedhman wrote: On Thursday 14 October 2004 12:33, Niclas Hedhman wrote: I would suggest we mavenize xdoclet and remove jrefactory and friends since they are clearly not enough friends of gump to live in the house with him. I will start on it straight away... IIUIC, Xdoclet is not yet Mavenized. They use Ant as the build system, and call upon Maven for the documentation generation. Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. +1! -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: building Forrest (Was: [RT] fixing gump)
David Crossley wrote: David Crossley wrote: Stefano Mazzocchi wrote: first of all, I think forrest should really transfer control of their descriptor to the gump project. Well, i said that we would sometime soon. I also said not now because we have an imminent release of Forrest. Our attention is going there and we are in code freeze. However if you want to take our descriptor into Gump CVS now, then please do. We can catch up later and disentangle it from our build process. Stefano, thanks. I went to do this today and see that you have already made a new projects/forrest.xml It seems that Gump is still using the old descriptor in our SVN. How do i get Gump to switch? The profile/gump.xml looks okay, but the last time that it was built was two days ago using the old descriptor. that's weird. it shouldn't do that! how do you know it used the old descriptor? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: BATCH: All dressed up, with nowhere to go...
Stefan Bodewig wrote: On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. Just create a project for it inside xdoclet's descriptor. Name it xdoclet-pretty or something. No need to turn it into a full installed package (which would require access to Brutus to update) IMHO. right! even better! -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Some progress on Fulcrum Component Builds!
Eric Pugh wrote: Hi all, Yesterday on IRC stefanom (who I guess is Stefan Bodewig) helped me get some of the Maven plugins for building the Fulcrum components installed. ehm, that was me ;-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
[warning] Brutus is out of disk!
Gump is currently stalled due to the fact that there is no disk space left on the second disk of Brutus. This is because every different gump run uses a different workspace, this doesn't need to be. I'll work on solving the issue right away. Sorry for the inconvenience. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [warning] Brutus is out of disk!
On Thursday 14 October 2004 23:28, Stefano Mazzocchi wrote: Gump is currently stalled due to the fact that there is no disk space left on the second disk of Brutus. Good gracious!!! This is because every different gump run uses a different workspace, this doesn't need to be. I'll work on solving the issue right away. Sorry for the inconvenience. Splendid!!! Can't wait to fix the remaining projects. It feels real close now to a 99% success rate (will it ever be 100%?) and your equilibrium... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [warning] Brutus is out of disk!
On Thu, 14 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: This is because every different gump run uses a different workspace, this doesn't need to be. Well, they can share installed packages (which they allready do IIUC) and the checked out sources. This won't help in the long run, I'm afraid. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [warning] Brutus is out of disk!
This is because every different gump run uses a different workspace, this doesn't need to be. Not sure this is accurate, unless they run at non-overlapping times or something. What is your thinking? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [warning] Brutus is out of disk!
This is because every different gump run uses a different workspace, this doesn't need to be. Not sure this is accurate, unless they run at non-overlapping times or something. What is your thinking? A few thoughts that come to mind: 1) We can have the infrequent Gumps [JDK1.5/Kaffe], that might not care about detecting changes, do clean-ups of their working areas after they are done. Right now we leave everything lying around, and perhaps even copy it. 2) We can have these same Gumps not generate (publish) artefacts. 3) We can see if we can not have a separate CVS (download) area than working area. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven gump goal (was Re: [RT] Standardizing on Maven names)
I'll get rid of it and cut a new version of the plugin. Are there any still needing mapping that need be kept? BTW: If you are making tweaks, would you mind moving the nag element out if projects and up onto the module? That way if we get a CVS|SVN error folks would be notified. If this isn't right (although I think a POM only has one project) then perhaps add something to the module, and also override (or duplicate) on the project, whatever is easier. Hmm ... I know what I ought be doing, a JIRA entry. Ok, done. This is minor, no pressure. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [warning] Brutus is out of disk!
Adam R. B. Jack wrote:
This is because every different gump run uses a different workspace,
this doesn't need to be.
Not sure this is accurate, unless they run at non-overlapping times or
something. What is your thinking?
I thought about it again and there is one way to do things better, but
I'm not sure it works.
if your build.xml file is well designed, the build directory is not
fixed by it's something like ${build}. My thinking is: since every gump
run on brutus shares the same profile, they could well share the same
sourcespace and each one have a different workspace that is
basically injected into the build.xml files.
This might not be easy, though, since this is not something that ant
enforces but it's just a best practice (here, I suspect that mavenized
projects would be a lot easier to deal with)
Anyway, for now, I'll just move the kaffe run somewhere else.
I'm on #asfgump if you need me.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
[jira] Created: (GUMP-86) Install/use Jikes with Kaffe, not their default compiler.
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/GUMP-86 Here is an overview of the issue: - Key: GUMP-86 Summary: Install/use Jikes with Kaffe, not their default compiler. Type: Task Status: Open Priority: Major Project: Gump Components: configuration of live servers Assignee: Stefano Mazzocchi Reporter: Adam Jack Created: Thu, 14 Oct 2004 3:33 PM Updated: Thu, 14 Oct 2004 3:33 PM Description: Per dalibor and jpick on IRC, this is the best compiler to use with Kaffe. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
depend project=avalon-merlin-unit/ to depend project=merlin-unit/
:o)
No, the project here refers to the name within Gump, but I think that the
following is needed;
depend property=maven.jar.merlin-unit project=avalon-merlin-unit/
Brett, do you have any insight in this?? Steve?
AFAIK property is not needed. The gump plugin just generates:
depend project=${dependency} /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Friday 15 October 2004 07:45, Brett Porter wrote:
depend project=avalon-merlin-unit/ to depend
project=merlin-unit/
:o)
No, the project here refers to the name within Gump, but I think that the
following is needed;
depend property=maven.jar.merlin-unit project=avalon-merlin-unit/
Brett, do you have any insight in this?? Steve?
AFAIK property is not needed. The gump plugin just generates:
depend project=${dependency} /
Yes, but the Gump ID and the Maven ArtifactID must correspond, and they don't
in this case.
Niclas
--
+--//---+
/ http://www.bali.ac/
/ http://niclas.hedhman.org /
+--//---+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
