[jira] Commented: (GUMP-158) Manage API changes in dependencies better
[ http://issues.apache.org/jira/browse/GUMP-158?page=comments#action_12359151 ] David Eric Pugh commented on GUMP-158: -- GUMP-105 is pretty much how I was thinking as well for #1. It would really help the robustness of Gump go up. Is the version of gump running at http://vmgump.apache.org/gump/public based on the 3.0 version? I was thinking about #2, and it would be relatively harder for Gump to figure out which dependency had the issue with the API. In the case of Turbine-2, it would have to figure out from a compile error that commons-logging api had changed. So, for that case, i think having it defined as a fall back would be key. Manage API changes in dependencies better - Key: GUMP-158 URL: http://issues.apache.org/jira/browse/GUMP-158 Project: Gump Type: New Feature Reporter: David Eric Pugh I really appreciate how Gump helps a system like Turbine validate all it's dependencies. Turbine has many many dependencies, and Gump makes it simple to make sure they all work together. However, with so many dependencies, actually trying to get a clean build is very difficult. Not so much because of the Turbine code being incompatible, but because of the dependency tree. Turbine fails to build most commonly due to: 1) A low level dependency like Ant failing 2) An API change between a released project and it's CVS HEAD When #1 occurs, it knocks out the Gump build for hundreads of projects. If it is low enough, it may sit and not be fixed for a couple days, meaning that when it does get fixed, the next build takes in both that change, and all the other changes that occurred during the intervening period, increasing the chance of a build failure. When #2 occurs, the build just fails and fails until a released version comes out, and then Turbine updates to that version and everything is well. However, with lots of dependencies, #2 can occur frequently, and for long periods of time. An example is the API change between Commons Logging 1.0.4 and 1.1-dev. Turbine will fail until 1.1 is released. Both of these issues I think could be managed by preserving the build artifacts of previous builds, and using them when CVS HEAD fails. The CVS HEAD build failing is great information, especially for the producers of components that are reused. But for consumers of components, it doesn't help them much. So, I'd like to see Gump do a build with CVS HEAD. Then, if that fails, I'd like to see it rollback to older versions of the artifacts that had previously worked for a project. Alternatively, give me the option of specifing that in the metadata. This would help especially for #2. I know commons-logging will fail until it is released, so let me specify that if the build fails, try again, but fall back to commons-logging-1.0.4. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-158) Manage API changes in dependencies better
Manage API changes in dependencies better - Key: GUMP-158 URL: http://issues.apache.org/jira/browse/GUMP-158 Project: Gump Type: New Feature Reporter: David Eric Pugh I really appreciate how Gump helps a system like Turbine validate all it's dependencies. Turbine has many many dependencies, and Gump makes it simple to make sure they all work together. However, with so many dependencies, actually trying to get a clean build is very difficult. Not so much because of the Turbine code being incompatible, but because of the dependency tree. Turbine fails to build most commonly due to: 1) A low level dependency like Ant failing 2) An API change between a released project and it's CVS HEAD When #1 occurs, it knocks out the Gump build for hundreads of projects. If it is low enough, it may sit and not be fixed for a couple days, meaning that when it does get fixed, the next build takes in both that change, and all the other changes that occurred during the intervening period, increasing the chance of a build failure. When #2 occurs, the build just fails and fails until a released version comes out, and then Turbine updates to that version and everything is well. However, with lots of dependencies, #2 can occur frequently, and for long periods of time. An example is the API change between Commons Logging 1.0.4 and 1.1-dev. Turbine will fail until 1.1 is released. Both of these issues I think could be managed by preserving the build artifacts of previous builds, and using them when CVS HEAD fails. The CVS HEAD build failing is great information, especially for the producers of components that are reused. But for consumers of components, it doesn't help them much. So, I'd like to see Gump do a build with CVS HEAD. Then, if that fails, I'd like to see it rollback to older versions of the artifacts that had previously worked for a project. Alternatively, give me the option of specifing that in the metadata. This would help especially for #2. I know commons-logging will fail until it is released, so let me specify that if the build fails, try again, but fall back to commons-logging-1.0.4. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Turbine 2 Gump has weird prereq
On Nov 29, 2005, at 10:51 PM, Bill Barker wrote: Eric Pugh [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all, I have just finished untangling the circular dependency between Turbine and Fulcrum Intake. So, I expected the build to run perfectly... I just checked the Turbine page: http://vmgump.apache.org/gump/public/jakarta-turbine-2/jakarta- turbine-2/index.html and it says that it failed: This project failed due to: Project: struts-action Now, what I can't figure out is how struts-action is being included as a prereq for the Turbine build.. I check the jakarta- turbine-2.xml file, and it doesn't mention struts-action or *struts* anywhere! This one is from : struts-action - jakarta-turbine-jcs - db-torque - fulcrum-security-adapter-turbine Okay, this chain makes sense for why fulcrum-security-adapter-turbine is failing. However, the main jakarta-turbine-2 project doesn't include fulcrum-security-adapter-turbine as a dependency: http:// vmgump.apache.org/gump/public/jakarta-turbine-2/jakarta-turbine-2/ details.html. However, it does include db-torque as a dependency, which does seem to require struts-action. And, after a bit of digging around, I realized that db-torque was an old dependency that is no longer required! So that should sort out the jakarta-turbine-2 project. Now, insofar as why fulcrum-quartz is failing, I see the chain of logic. I couldn't figure out why Quartz would depend on struts, but I forgot they added a webapp for Quartz, which uses struts, which is now failing. So, I guess there is nothing I can do right now... Argh. At any rate, hopefully jakarta-turbine-2 will now build cleanly, and thanks for all your help! Eric Maybe related is the fact that the previously failing Turbine Fulcrum components now pass, except for Fulcrum Quartz: http://vmgump.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum- quartz/index.html who is failing due to the same struts-action prerequisite! This is failing because: struts-action - quartz So close to a good build, yet still not there! Eric - 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]
Turbine 2 Gump has weird prereq
Hi all, I have just finished untangling the circular dependency between Turbine and Fulcrum Intake. So, I expected the build to run perfectly... I just checked the Turbine page: http://vmgump.apache.org/gump/public/jakarta-turbine-2/jakarta- turbine-2/index.html and it says that it failed: This project failed due to: Project: struts-action Now, what I can't figure out is how struts-action is being included as a prereq for the Turbine build.. I check the jakarta- turbine-2.xml file, and it doesn't mention struts-action or *struts* anywhere! Maybe related is the fact that the previously failing Turbine Fulcrum components now pass, except for Fulcrum Quartz: http://vmgump.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum- quartz/index.html who is failing due to the same struts-action prerequisite! So close to a good build, yet still not there! Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Updating Gump Build logs
Hi all, I wanted to clean up some of the build information related to the Turbine-* projects. I noticed under failure stories some references, and wanted to remove Turbine 3, as well as some other Turbine projects that are dormant and not maintained. Also, I wanted to fix an issue with common-email. I dug around, and can't find on the gump website the new SVN location for storing the metadata. A page discussing how to actually update the Gump metadata would be great! Thanks... Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is fulcrum-crypto missing a dependency on javamail in project.xml?
Stefan, I am getting back into Gump land, may take me a day or two to get up to speed again. As far as this one, for some reason the dependency was removed. So Gump was properly failing! I have added the dependency back into the source, so hopefully Gump will compile properly now! Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 23, 2005 10:03 AM To: general@gump.apache.org Subject: Is fulcrum-crypto missing a dependency on javamail in project.xml? javamail is there on the CLASSPATH, but I think Maven ignores it since fulcrum-crypto's project.xml doesn't talk about it. Does fulcrum-crypto compile outside of Gump? Stefan - 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: [revelation!!] circular dependencies do NOT exist!
Isn't the fallback idea for artifacts that is already in Gump something like the time travel? If project A depends on B, and A.today can't build with B.today, then try with B.yesterday. If that fails, then try B.daybeforeyesterday. If that fails, then try B.daybeforedaybeforeyesterday! I agree that the visualization would be hard, makes me think of all the various tools (like FishEye) that attempt to visualize the branching of code in CVS. (Sorry for the crypto timestamp notation!) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RT] Gump 3.0 - Database Model
Just catching up on my email after being gone for a week. One thing that strikes me about the project id's is that this seems to continue the same discussion we have had in the past about maven generated project id's versus the gump project id's... Do the project id's have to have meaning? While it's nice to look at a project id and pick out some data, like the version and the timestamp or what not, eventually gump will run into another project where the id's mean something different and are generated differently. I don't mind a project id like 787234 that I then look up and find out is what ever specific meaning it has. Like version, or host, or whatnot. I think that when we establish project naming conventions we'll run into conflicts with how other projects name themselves I would welcome project IDs of the form http://www.apache.org/projects/cocoon and then http://www.apache.org/projects/cocoon#v1.0 for a particular released version, or http://www.apache.org/projects/cocoon#20041210 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hello Gump
The behavior is as you specified, if the build fails the first time due to a prereq you get a notice, after that you don't until the build passes. However, when a basic prereq like commons-lang or ant or xml parser failes, and then fixes, it causes a storm of spam messages. On the turbine dev list, if this happens we get 20 emails, one per fulcurm component. Which is very annoying and causes people just to filter gump messages. At least in the fulcurm case, we don't care if a prereq failed and then successed.. We do care ONLY when we succeed/fail. -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Saturday, December 04, 2004 10:22 PM To: Gump code and data Subject: Re: Hello Gump When a project is not built because one of the dependencies didn't build and then gets build again because the dependency solved its problems, the project receives an email that is has no longer a problem. We have concensus to feel that this is annoying and the projects should be made aware of their change in status *only* when they fix their own problems, not when people down the road does. Either we solve this, or we stop sending email until we figure out a better way because this is harming our ability to make gump appear useful. WDYT? I think it'd bug me too. ;-) That said, I thought this code would've taken care of that. In actor/notify/logic.py we have: elif entity.isSuccess(): # # Notify on first success, after a failure. # if (stats.sequenceInState == 1): if not STATE_PREREQ_FAILED == stats.previousState: if stats.getTotalRuns() 1: notification=gump.actor.notify.notification.SuccessNotification(se lf.run,ent ity) So -- I'm missing something. If they failed to build due to pre-requisite failure they ought not get the notification. Maybe I broke something when I hacked in attempting to build from repository (previously built artifacts). I'll look into is ASAP. BTW: We really need your historical database, so we can query not hack. :-) regards, Adam - 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: change of module names or repositories
It still looks like jakarta-velocity is building the CVS head of Log4j.. It is supposed to be building with the log4j 1.2 version. ERic -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 9:09 AM To: [EMAIL PROTECTED] Subject: change of module names or repositories Hi all, if you change the name of a CVS module or some code base switches from CVS to SVN or any other change like this happens, we need to remove the existing working copy from brutus. In velocity's case we had: svn --quiet update --non-interactive jakarta-velocity svn: 'jakarta-velocity' is not a working copy since Gump saw the jakarta-velocity dir and thus tried an update instead of a checkout. Since not everybody has access to brutus, please make a lot of noise if you make any change like this. Cheers Stefan - 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: Picking up the ball from Niclas (ugh!) on Velocity
I think what he means is that we can't expect people to make changes just to make Gump happy. But, we can *attempt* to influence them to help. And I think that is where we are going wrong. For instance, Fulcrum components didn't build very well until I got involved (and got lots of help!).. You need a committer from the project being gumped to keep things running well. As far as I know, there are no log4j committers actively involved in keeping gump working. Hence, they made a backwards incompatible change, and the fact that gump keeled over doesn't bother then. Now, partly that may be a communication thing.. If Log4j fails, they get emailed. If log4j breaks every body else, they don't... Without active involvement by a group, the prospect of keeping things working becomes a thankless task (witness Niclas's frustration). I thought hey, I'll try and help and ran into, in an hour, the same frustration Niclas sees.. I am not a committer (or even involved beyond the occasional email) with Log4j or Velocity, so who do I got to prod for action? Geir's email highlights a very clear issue with the whole deprecation/version cycle. He can't switch to log4j until it releases. They don't want to keep deprecated code around for forever. I'll argue that neither party is at fault. It's just an icky sore spot that will be worked out at somepoint, and gump is just bringing up the incompatiblity sooner. I'd like Gump to now just say Yes, log4j HEAD fails on Velocity, lets step back to the last successful build with Velocity and use that, or, we work around it by building in Gump the older version (logging_log4j_12) and use that. I don't specifically think it is a tooling issue.. This stuff is hard, and while some rote stuff could be made simpler with better tooling, we are always going to have odd situations to deal with. So, I'll again argue about the benefit of packages/custom branches.. We need to build up mindshare the gump is this great build tool/continous integration tool. But we certainly can't wait a couple years, and I think that certain components that break frequently need to be packaged to provide some stability, as well as pruning some leaves that never build. Anything that hasn't built in the last 300 cycles for instance should be canned! At least, until we get some stability in gump... Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 6:36 AM To: Gump code and data Subject: Re: Picking up the ball from Niclas (ugh!) on Velocity On Tuesday 30 November 2004 07:45, Stefano Mazzocchi wrote: Gump is about establishing communication channels between development communities. On the other hand, if you are interested in creating a social engineering support tool and you are willing to get your hands dirty in python and prepare to have a huge ton of patience to convert a few hundreds people to a very difficult concept, The rule should be to start fixing gump and fix the communication channels rather than fixing the metadata to route around the problems. Cool, but then you told me Don't change people we should work around them [projects not willing to co-operate]... I would call that mixed signals... ;o) Cheers Niclas P.S. Let me know when you figured out that Java is a better tool after all :o) so I can help more actively. -- +--//---+ / http://www.dpml.net / / 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: Fwd: failure notice
I actually checked in a change to the gump build to do this.. However, today xerces fell over, so now nobodies running at all.. When it runs again, hopefully we'll see it work. Of course, I may not have done it properly ;-) Eric -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 2:33 PM To: Geir Magnusson Jr Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Fwd: failure notice At 03:39 AM 11/30/2004, Geir Magnusson Jr wrote: some lists choose to moderate... Hello Geir, We currently don't but may switch back to moderated list. Sorry about the hassle. anyway, the interesting thing is the problem I have fixing Velocity so Gump is happy ... Niclas Hedhman informed us of this problem. There was a conscious choice to remove the old RollingAppender and replace with something better. To help you solve this problem there several routes exists. First and more philosophically, there is more to software development than keeping gump happy. Having said that, you can keep gump happy by either switching to FileAppender or keep your own version of RollingFileAppender. Perhaps the easiest alternative is to have velocity explicitly tell gump that velocity depends on log4j 1.2.x and not log4j head. Actually this would be he action I would recommended. I hope this helps, Begin forwarded message: From: [EMAIL PROTECTED] Date: November 29, 2004 9:29:02 PM EST To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Sorry, only subscribers may post. If you are a subscriber, please forward this message to [EMAIL PROTECTED] to get your new address included (#5.7.2) --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 13066 invoked by uid 99); 30 Nov 2004 02:29:02 - X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from chi.mobile-health-diary.com (HELO chi.mobile-health-diary.com) (128.241.244.71) by apache.org (qpsmtpd/0.28) with SMTP; Mon, 29 Nov 2004 18:29:02 -0800 Received: (qmail 11965 invoked from network); 30 Nov 2004 02:29:00 - Received: from ool-43560634.dyn.optonline.net (HELO ?10.0.1.2?) ([EMAIL PROTECTED]) by b014.internal.mobile-health-diary.com with SMTP; 30 Nov 2004 02:29:00 - In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: [EMAIL PROTECTED] Content-Transfer-Encoding: quoted-printable Cc: Gump code and data [EMAIL PROTECTED], Log4J Developers List [EMAIL PROTECTED] From: Geir Magnusson Jr [EMAIL PROTECTED] Subject: Re: Gump reporting Date: Mon, 29 Nov 2004 21:28:57 -0500 To: Velocity Developers List [EMAIL PROTECTED] X-Mailer: Apple Mail (2.619) X-Virus-Checked: Checked Why isn't this backwards compatible? I'm trying to fix this, but I can't. There is no released version of =20= log4j that has this change, and I won't have vel based on whatever we =20= can build from head-du-jour. Is there a way to make this backwards compatible? Like deprecate =20 o.a.l.RFA, release so we can switch to o.a.l.rolling.RFA? geir On Nov 28, 2004, at 2:38 PM, Paulo Gaspar wrote: But how do you constrain the use of disk space with the FileAppender? With the RollingFileAppender, that is a simple matter of = configuration. Regards, Paulo Gaspar Ceki G=FClc=FC wrote: Hi Niclas, The change is not not a backward compatible. My suggestion would be =20= use a simple FileAppender instead of RollingFileAppender. At 02:13 PM 11/26/2004, Niclas Hedhman wrote: Hi, http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-=20 velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html Jakarta Velocity is somehow using the RollingFileAppender in code, =20= and I wonder if you guys have moved it from org.apache.log4j.RollingFileAppender to org.apache.log4j.rolling.RollingFileAppender and whether this constitutes a compatible change or not, as I think =20= if this is the case, it will also break a lot of configuration files out there. Thanks for any feedback. Cheers Niclas -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe,
RE: [vote] turning off nagging until we feel gump is solid enough for that
I think that it's more complex then just turning it on or off.. I'm in favor of turning it off for now if thats the only option. What I prefer is that if a prereq doesn't build/builds finally, I don't get nagged. That is what generates (typically) the flood of emails... I only care if my project doesn't build/builds... Eric -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 8:43 PM To: Gump code and data Subject: Re: [vote] turning off nagging until we feel gump is solid enough for that +1. Our probes are getting more done than nagging right now. On Nov 30, 2004, at 11:39 AM, Stefano Mazzocchi wrote: I think gump's nagging is currently making more noise than signal and this is hurting our ability to come across as helpful instead of annoying. I propose to turn off nagging until we fix this, we are the only one making changes to the metadata anyway, so there is no much point in that. WDYT? -- Stefano. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Standing back (for a while?)...
Niclas (and Gang), I can understand how you feel, and I think that part of the issue is that building from the latest and greatest all the way up and down the tree is somewhat of an impossible task. I know for example that until commons-configuration does another release, fulcrum-configuration won't build due to API changes. Right now, everybody is failing because Velocity hasn't kept up with Log4j. And, on a certain level, expecting a component to keep up with CVS head of another component isn't realisitic. The things that I think would help are: 1) Identifiable people for each component. If there ISN'T an Apache owner for a component, it should be a library. We need someone who will get the fix in ASAP when the build fails. Jakarta-velocity has been broken for 33 runs, leading to either 150 or 165 projects to not attempt to build. Who will fix it? 2) Need the fallback! With jakarta-velocity failing, Gump apparently tries but fails to fallback to the previously built version. The fallback is crucial to prevent the small errors from creeping in. 3) Don't email me when a dependency starts building and therefore I build. I don't care if I build successfully because a dependency built. I only care when I fail. When something with a lot of dependencies builds, I get spammed a million times by Gump, which leads to the Gump being ignored syndrome. My 2 cents, and I hope after a breather you rejoin! You've personally done a lot to help me learn Gump, and get the fulcrum components to build happily. Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 8:36 AM To: [EMAIL PROTECTED] Subject: Standing back (for a while?)... Gang, I have decided to step away from Gump for a while, and the main reason is that I find it depressing to work with... Increments of overall success is slow, and decrements of overall success is fast. And during the period of big showstoppers, entropy sets in in all non-building projects so that when the big showstopper is resolved, a lot of small cases are back. I find that there must be something fundamentally wrong with Gump, if it self-deteriorate so quickly. Personally I think the solution is that the Gump group needs to work more intimately with the Ant/Maven and other build system groups, to put in the continous integration support directly into those tools, instead of the manual labour of bolting it on externally. I might be back later, but for now I wish you all Good Luck. Cheers Niclas -- +--//---+ / http://www.dpml.net / / 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]
Picking up the ball from Niclas (ugh!) on Velocity
So, I thought I would just submit a patch to Velocity to fix the velocity/log4j problem and everything would be fine. Wrong.. The issue is the non backwards compatible API change to log4j. And, I saw Niclas email about it as well. So, I dug some more and according to this email: http:[EMAIL PROTECTED]/2004-11/msg00271.html there is a binary version. So I thought hey, use that.. Only to discover that Gump can check out a tagged branch of code! And that there is a project called logging-log4j-12.xml already building that most dependees of log4j use. So, I made the change, and that should fix Velocity... Of course, it basically is like dynamically building a package.. Fulcrum Configuration relies on the older version of commons-configuration. I am going to apply the same trick there. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BATCH: All dressed up, with nowhere to go...
Hi all, I am a bit confused by this.. Is this message saying that the module level work, which I guess is checking out from CVS, worked properly, but then the build failed? I followed the link provided and everything says Success. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 8:42 PM To: [EMAIL PROTECTED] Subject: BATCH: All dressed up, with nowhere to go... Dear Gumpmeisters, The following 2 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module dumbster success [EMAIL PROTECTED]: Project dumbster (in module dumbster) failed *** G U M P [EMAIL PROTECTED]: Module dumbster success To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module dumbster *no longer* has an issue. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/dumbster/index.html That said, some information snippets are provided here. The following work was performed: http://brutus.apache.org/gump/public/dumbster/gump_work/update_dum bster.html Work Name: update_dumbster (Type: Update) Work ended in a state of : Success Elapsed: 2 secs Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/cvsroot/dumbster update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/dumbster] - No output - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/dumbster/rss.xml - Atom: http://brutus.apache.org/gump/public/dumbster/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 19000925112004, brutus:brutus-public:19000925112004 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project dumbster (in module dumbster) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project dumbster has an issue affecting its community integration. This issue affects 2 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package - dumbster : The Dumbster is a very simple fake SMTP server designed for ... Full details are available at: http://brutus.apache.org/gump/public/dumbster/dumbster/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [dumbster.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/dumbster/dumbster/gump_work/b uild_dumbster_dumbster.html Work Name: build_dumbster_dumbster (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/jav a/build/xercesImpl.jar:/usr/local/gump/public/work space/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only world [Working Directory: /usr/local/gump/public/workspace/dumbster] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/dumbste r/build/classes:/usr/local/gump/public/workspace/dumbster/build/te st:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar :/usr/local/gump/public/workspace/ant/dist/lib/ant -jmf.jar:/usr/local/gump /public/workspace/ant/dist/lib/ant-swing.j ar:/usr/local/gump/public/workspace/ant/dist/lib/a nt-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-juni t.jar:/usr/local/gump/public/workspace/ant/dist/li b/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/a nt-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.ja r:/usr/local/gump/packages/jaf-1.0.1/activation.jar:/usr/local/gum p/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/j avamail-1.3.2/mail.jar:/usr/local/gump/packages/javamail-1.3.2/lib /mailapi.jar - Buildfile: build.xml init: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/dumbster/build/classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/dumbster/build/test
RE: cvs commit: gump/project jakarta-turbine-2.xml
I am going to start looking into this... I bet there is stuff we can remove. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Thursday, November 18, 2004 11:19 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: gump/project jakarta-turbine-2.xml On 18 Nov 2004, [EMAIL PROTECTED] wrote: removed unknown deps. will only lead to Maven complaining about missing jars. Maybe we should fake those with dummy projects? Has there ever been a avalon-activation-spi project? Stefan - 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: Missing Class for Fulcrum DVSL
I have just added jaxen as an explicit maven dependency for DVSL, so hopefully this will solve the issue. We'll see in the next run! I know that fixing the classloaders for plugins will break stuff, but I believe it will be forward compatible right? If I fix a project that was unintentionally depending on the single classloader for all plugins, then it will still run under maven 1.0, as well as maven 1.1? When you get to the point of committing the code, it may be good to put another instance of gump up with a maven 1.1 Release Candidate so we can see who breaks and start fixing them before the official release of 1.1. Again, another good reason for Gump! Eric -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 09, 2004 10:50 PM To: Gump code and data Subject: Re: Missing Class for Fulcrum DVSL Just to confirm some things here: - test honours jar overrides as it uses maven.dependency.classpath - Maven does not introduce any jaxen dependencies normally. However, if you are using any plugin:* latka:* pmd:* release:* goals it will be introduced. This is an unfortunate side-effect of not having plugin classloaders separate - something we desparately want to implement, but would break a significant number of builds that have come to depend (no pun intended!) on it. If you run maven with -X you will see what maven.dependency.classpath is and whether jaxen has found its way onto there. I think Maven 1.1 is going to have to take the backwards compat hit and separate the classloaders. I've already done the work but not committed it. - Brett On Tue, 9 Nov 2004 18:55:24 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Not quite sure where this dependency is coming from. I don't believe Maven is introducing for me the Jaxen dependency. As the test runs perfectly without it. Could it be the version of dom4j being used? My component is just a wrapper around velocity-dvsl, so it may be somewhere in there... I'll try and spill out the classpath in the test.. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 09, 2004 5:39 PM To: [EMAIL PROTECTED] Subject: Re: Missing Class for Fulcrum DVSL On Tue, 09 Nov 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 9 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: I have inlined the text of the error. The issue is something missing on Jaxen. However, I have in my Gump descriptor (but not in Maven) a dependency on Jaxen. So how do you compile your code with Maven if you don't specify the dependency at all? Is the version of Jaxen used Maven helping out? should read Is the version of Jaxen used by Maven helping out? Stefan - 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] - 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: Missing Class for Fulcrum DVSL
Problem solved! Thank you Gump for finding a missing dependency! -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, November 11, 2004 11:20 AM To: Gump code and data Subject: RE: Missing Class for Fulcrum DVSL I have just added jaxen as an explicit maven dependency for DVSL, so hopefully this will solve the issue. We'll see in the next run! I know that fixing the classloaders for plugins will break stuff, but I believe it will be forward compatible right? If I fix a project that was unintentionally depending on the single classloader for all plugins, then it will still run under maven 1.0, as well as maven 1.1? When you get to the point of committing the code, it may be good to put another instance of gump up with a maven 1.1 Release Candidate so we can see who breaks and start fixing them before the official release of 1.1. Again, another good reason for Gump! Eric -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 09, 2004 10:50 PM To: Gump code and data Subject: Re: Missing Class for Fulcrum DVSL Just to confirm some things here: - test honours jar overrides as it uses maven.dependency.classpath - Maven does not introduce any jaxen dependencies normally. However, if you are using any plugin:* latka:* pmd:* release:* goals it will be introduced. This is an unfortunate side-effect of not having plugin classloaders separate - something we desparately want to implement, but would break a significant number of builds that have come to depend (no pun intended!) on it. If you run maven with -X you will see what maven.dependency.classpath is and whether jaxen has found its way onto there. I think Maven 1.1 is going to have to take the backwards compat hit and separate the classloaders. I've already done the work but not committed it. - Brett On Tue, 9 Nov 2004 18:55:24 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Not quite sure where this dependency is coming from. I don't believe Maven is introducing for me the Jaxen dependency. As the test runs perfectly without it. Could it be the version of dom4j being used? My component is just a wrapper around velocity-dvsl, so it may be somewhere in there... I'll try and spill out the classpath in the test.. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 09, 2004 5:39 PM To: [EMAIL PROTECTED] Subject: Re: Missing Class for Fulcrum DVSL On Tue, 09 Nov 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 9 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: I have inlined the text of the error. The issue is something missing on Jaxen. However, I have in my Gump descriptor (but not in Maven) a dependency on Jaxen. So how do you compile your code with Maven if you don't specify the dependency at all? Is the version of Jaxen used Maven helping out? should read Is the version of Jaxen used by Maven helping out? Stefan - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Missing Class for Fulcrum DVSL
Well, The second to last build issue for Fulcrum concerns Fulcrum DVSL Impl. Everything builds nicely, but the unit test is failing: http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-dvsl-im pl/gump_work/build_jakarta-turbine-fulcrum_fulcrum-dvsl-impl.html I have inlined the text of the error. The issue is something missing on Jaxen. However, I have in my Gump descriptor (but not in Maven) a dependency on Jaxen. I notice in the jaxen.xml project file there are two different ones. A packaged with dom4j and a standalone. Do I maybe want the packaged with dom4j? I went and checked, and org.jaxen.JaxenException is still part of CVS HEAD for jaxen... ERic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Missing Class for Fulcrum DVSL
Not quite sure where this dependency is coming from. I don't believe Maven is introducing for me the Jaxen dependency. As the test runs perfectly without it. Could it be the version of dom4j being used? My component is just a wrapper around velocity-dvsl, so it may be somewhere in there... I'll try and spill out the classpath in the test.. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 09, 2004 5:39 PM To: [EMAIL PROTECTED] Subject: Re: Missing Class for Fulcrum DVSL On Tue, 09 Nov 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 9 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: I have inlined the text of the error. The issue is something missing on Jaxen. However, I have in my Gump descriptor (but not in Maven) a dependency on Jaxen. So how do you compile your code with Maven if you don't specify the dependency at all? Is the version of Jaxen used Maven helping out? should read Is the version of Jaxen used by Maven helping out? Stefan - 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: Re; cvs commit: gump/project jakarta-turbine-fulcrum.xml
Sorry about that.. I am flailing a bit.. I think I get it.. The project is called commons-beanutils. So, that is the dependency in gump I need. But, the jar is called commons-beanutils-core.jar, so that is the dependency I need in Maven. And, the maven.commons-beanutils-core.jar will map between the two, correct? -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Friday, November 05, 2004 10:41 AM To: [EMAIL PROTECTED] Subject: Re; cvs commit: gump/project jakarta-turbine-fulcrum.xml On Friday 05 November 2004 17:00, [EMAIL PROTECTED] wrote: -depend project=commons-beanutils-core/ +depend project=commons-beanutils/ Keep changing this poor dependency back and forth doesn't help... Next run you will get that commons-beanutils-core can not be found in the Maven build. I am too busy to fix this, but I think the property maven.commons-beanutils-core.jar needs to be set to the Jar in question. 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: Seeing results of Maven unit tests?
I just finished adding the propery to the Gump descriptor file if you get a chance to check it out. I have the output of the unit tests coming in the log, so we can look for the property to verify it being picked up. Eric -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 11:45 AM To: Gump code and data Subject: RE: Seeing results of Maven unit tests? Great.. and I can pull that up in Java using System.getProperty! cool.. -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 10:43 AM To: Gump code and data Subject: Re: Seeing results of Maven unit tests? On Wednesday 03 November 2004 17:13, Eric Pugh wrote: Unfortunantly they are all work arounds to the fact that I can't see the unit test results. But also, it is because in fulcrum cache we have two unit tests. One is a quick is it working and another is a longer running test the cache for 2 minutes test. Ok. If you want a property to be set, just set it; maven property name=gump.isRunning value=true / /maven should work. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Seeing results of Maven unit tests?
These are all very good suggestions.. Unfortunantly they are all work arounds to the fact that I can't see the unit test results. But also, it is because in fulcrum cache we have two unit tests. One is a quick is it working and another is a longer running test the cache for 2 minutes test. I can imagine that there are lots of situations where you wouldn't wan to run certain tests under gump... Things that might put undue strain on the hardware for example. Being able to pick up some sort of system property would be perfect. I still want Gump to fail my cache code if the quick easy test fails.. But not to even run the more comprehensive test... I'll definitly play with the unit test failure ignores setting... Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 6:20 PM To: Gump code and data Subject: Re: Seeing results of Maven unit tests? On Wednesday 03 November 2004 01:08, Eric Pugh wrote: I've seen this error periodically, and to be honest, I don't like this test.. I don't really want to run it except on demand.. Is there any environment variable that tells me I am running in Gump that I can get? Anything like: if (System.getProperty(gump)==true) ignore test... Would setting the goal attribute in the maven element to something like jar work?? I think that you can also tell Maven not to report testcase failures as errors with a property. Then the question is if that property can be fed through the Maven element, and I think so. 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: Seeing results of Maven unit tests?
Great.. and I can pull that up in Java using System.getProperty! cool.. -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 10:43 AM To: Gump code and data Subject: Re: Seeing results of Maven unit tests? On Wednesday 03 November 2004 17:13, Eric Pugh wrote: Unfortunantly they are all work arounds to the fact that I can't see the unit test results. But also, it is because in fulcrum cache we have two unit tests. One is a quick is it working and another is a longer running test the cache for 2 minutes test. Ok. If you want a property to be set, just set it; maven property name=gump.isRunning value=true / /maven should work. 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: What do we do with beanutils?
Brett, It seems like #2 is the cleanest way regardless of how the details of it are implemented. If the POM change is too much, we could just add the various alias names to project.properties. Or, alternatively, say tough luck, you changed your name, Maven can't generate the Gump descriptor. #3 seems like if we are to do that, then the gump plugin should really move to gump CVS so that gump people can maintain this plugin. Or, at least, dynamically pull in the mapping file from Gump's website/cvs. I'd argue that tracking that kind of thing is a useful beyond just Gump anyway and should be in the POM. I have a versions plugin that checks if you have the latest and greatest of an artifact. But, if the artifact changes names, there is no repo for that data. Eric -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 2:58 AM To: Gump code and data Subject: Re: What do we do with beanutils? Ok, we need a solution for when a project changes names. There have been suggestions in the past, let's round them up: - gump has a dummy project beanutils that depends just on beanutils-core. I don't think this works with Maven though. - projects declare any aliases in their gump descriptor (and Maven allows that in the POM so it can generate the descriptor for them). So beanutils-core has an alias of beanutils - we don't do any gump solutions, and we maintain the big mapping file in the maven gump plugin, so it can change the dependencies when converting the gump descriptor. We look to store that mapping file in gump, instead. - we don't do anything. When a project changes name, they accept they are going to break projects and they have to catch up. Possibly, the previous version keeps the name so that projects keep building? (others have more passionate feelings about how gump should behave in this way I think, so I'll leave that to them). Thoughts? (2) seems the best if possible on the gump end. Both (2) and (3) are easy from the maven end. Cheers, Brett On Mon, 01 Nov 2004 20:29:32 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: we call it beanutils-core and maven calls it beanutils. Should I go ahead and unify the two or anybody has a better idea? -- Stefano. - 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: [proposal] removing non-ASF leaves from the workspace
I've removed it. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 9:42 AM To: [EMAIL PROTECTED] Subject: Re: [proposal] removing non-ASF leaves from the workspace On Mon, 1 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: Please see my thread about removing commons-xo [1] for an example of one project that we can get rid of. I may be nitpicking, but commons-xo builds fine in Gump if you use Ant instead of Maven. The main problem is that XO declares dependencies in its project.xml it doesn't need (like beanutils). The effect certainly is the same. If nobody wants to fix the project.xml, it obviously is in an unmaintained state. Stefan - 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]
Seeing results of Maven unit tests?
Hi all, I notice that gump links in a lot of files that it generates, like the project.properties etc. However, the output from running unit tests is not available. Is there anyway to find this? A couple of the Fulcrum projects are failing on their tests... http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-cache/i ndex.html I wondered if I could see them by pulling up a directory like: http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-cache/g ump_file/target/test-reports but no joy... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Seeing results of Maven unit tests?
Cool, it is GUMP-87. So, the files output by gump are not located someplace that I can browse via HTTP then huh.. Anyway I could get permissions to logon to the box and see? ERic -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 3:16 PM To: Gump code and data Subject: Re: Seeing results of Maven unit tests? Eric Pugh wrote: Hi all, I notice that gump links in a lot of files that it generates, like the project.properties etc. However, the output from running unit tests is not available. Is there anyway to find this? A couple of the Fulcrum projects are failing on their tests... http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcr um-cache/i ndex.html I wondered if I could see them by pulling up a directory like: http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-cache/g ump_file/target/test-reports but no joy... add it as a feature request in the issue tracking system otherwise it will be los. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Seeing results of Maven unit tests?
I've seen this error periodically, and to be honest, I don't like this test.. I don't really want to run it except on demand.. Is there any environment variable that tells me I am running in Gump that I can get? Anything like: if (System.getProperty(gump)==true) ignore test... Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 5:19 PM To: Gump code and data Subject: Re: Seeing results of Maven unit tests? On Tuesday 02 November 2004 23:18, Eric Pugh wrote: Cool, it is GUMP-87. So, the files output by gump are not located someplace that I can browse via HTTP then huh.. Anyway I could get permissions to logon to the box and see? It is not for me to grant, so meanwhile here is the relevant (I hope) section of the TEST-org.apache.fulcrum.cache.CacheTest.txt [DEBUG] Starting container... [DEBUG] Loading the service container class org.apache.fulcrum.yaafi.framework.container.ServiceContainerImpl [DEBUG] Instantiating the service container class org.apache.fulcrum.yaafi.framework.container.ServiceContainerImpl [DEBUG] Setting applicationRootDir to /home/gump/workspaces2/public/workspace/jakarta-turbine-fulcrum/cache [DEBUG] Service Framework is starting up [DEBUG] Using the following applicationRootDir : /home/gump/workspaces2/public/workspace/jakarta-turbine-fulcrum/cache [DEBUG] Using the following tempRootDir : /tmp [DEBUG] Looking for src/test/TestComponentConfig.xml in the application directory [DEBUG] Successfully located src/test/TestComponentConfig.xml [DEBUG] Looking for src/test/TestRoleConfig.xml in the application directory [DEBUG] Successfully located src/test/TestRoleConfig.xml [DEBUG] Looking for /parameters.properties as absolute file location [DEBUG] Looking for /parameters.properties using the class loader [WARNING] Unable to locate /parameters.properties [DEBUG] Loading the implementation class for cache [DEBUG] Instantiating the implementation class for cache [DEBUG] Incarnating the service cache [DEBUG] LogEnabled.enableLogging() for cache [DEBUG] Configurable.configure() for cache [DEBUG] Initializable.initialize() for cache [DEBUG] Service Framework is up and running [INFO] YaffiContainer ready. [DEBUG] Disposing of container... [INFO] Disposing all services [DEBUG] All services are disposed [INFO] YaffiContainer has been disposed. - --- Testcase: testRefreshableTimeToLive(org.apache.fulcrum.cache.CacheTest): FAILED Received unexpected ObjectExpiredException exception when retrieving refreshable object after ( 6001 millis) junit.framework.AssertionFailedError: Received unexpected ObjectExpiredException exception when retrieving refreshable object after ( 6001 millis) at org.apache.fulcrum.cache.CacheTest.testRefreshableTimeToLive(Cache Test.java:476) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm pl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc cessorImpl.java:25) -- +--//---+ / 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: [proposal] removing non-ASF leaves from the workspace
The cost of having to build each dependency in Gump drives home that I may be using some weird dependency that no else is using, and is therefore not already in Gump. However, as long as the code remains buildable, it won't be an issue. In the long run, in 5 years when some libarary I am using is no longer maintained, then this will become key information. Sometimes I just want to build against version XX of a dependency. But this is mostly me being lazy. Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 12:58 PM To: Gump code and data Subject: Re: [proposal] removing non-ASF leaves from the workspace On Monday 01 November 2004 19:29, Eric Pugh wrote: Related to this, I am starting to think about dependencies not just in a is it a good dependency to have but in a what challenges will having this dependency give me in Gump land, which isn't a great thing... Hmmm... I wonder if such thought is a sign of Gump creating problem for you, or if Gump amplifies future trouble with external dependencies?? 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: [proposal] removing non-ASF leaves from the workspace
I agree. Please see my thread about removing commons-xo [1] for an example of one project that we can get rid of. I think other jakarta-commons-sandbox may be removed as well if they are stagnant... Eric [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg51295.html -Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 5:06 PM To: Gump code and data Subject: Re: [proposal] removing non-ASF leaves from the workspace Stefano Mazzocchi wrote: If a project: 1) is not an ASF project 2) no ASF project depend on it 3) has been broken for a while and shows no sign of activity (gump-wise) +1 to that one. In the case of has been broken for a LONG time with no sign of activity gump-wise I would even support the above for ASF projects. At least until the tree is cleaned up. - LSD - 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: excalibur-configuration
Niclas, Looks like you got fulcrum-crypto-impl to build! Congratulations, that was one of the bugaboo projects because of the Javamail dependency. Thanks for fixing up all those other dependencies as well! Eric -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 6:14 AM To: Gump code and data Subject: Re: excalibur-configuration Niclas Hedhman wrote: Excalibur gang, Jakarta Turbine Fulcrum has a couple of projects that depends on the excalibur-configuration project, which doesn't exist anymore. What is the migration path for this artifact? project name=excalibur-legacy jar name=excalibur-compatibility-1.1.jar id=compatibility/ jar name=excalibur-i18n-1.1.jar id=i18n/ jar name=excalibur-configuration-1.2.jar id=configuration/ /project found in module project/excalibur-legacy. Grep is your friend :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-configuration
I am not sure how we depend on it.. It seems like things just fail if we don't have it... -Original Message- From: peter royal [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 4:47 AM To: Excalibur Developers List Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: excalibur-configuration On Oct 26, 2004, at 10:18 PM, Niclas Hedhman wrote: Excalibur gang, Jakarta Turbine Fulcrum has a couple of projects that depends on the excalibur-configuration project, which doesn't exist anymore. What is the migration path for this artifact? What aspects do they depend on? if they are the only dependees, might sense for them to pull the code into their codebase? -pete - 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
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: How to refer to ws-xmlrpc as xmlrpc?
Hi Niclas.. I think the fix isn't working.. Not sure what is going on.. also, on a related note, I switched to javamail-1.3, but it doesn't seem to pick it up as well... Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 10:17 AM To: Gump code and data Subject: Re: How to refer to ws-xmlrpc as xmlrpc? On Thursday 21 October 2004 16:57, Eric Pugh wrote: So, I add this: property name=maven.jar.bsf project=jakarta-bsf id=bsf.jar / property name=maven.jar.xmlrpc project=ws-xmlrpc id=xmlrpc.jar No, the id refers to the declared id in the jar of the project (and I am not sure what that defaults to, btu I suspect not what you wrote). The two projects you are referring to, are both declaring only one jar, in which case the id= above not necessary. I have committed that change. 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: How to refer to ws-xmlrpc as xmlrpc?
Humm.. Okay.. But.. I am slowly getting it.. So, I ran into the same issue with the bsf.jar.. I call it bsf, but the project is jakarta-bsf. So, I add this: maven basedir=bsf goal=jar property name=maven.jar.bsf project=jakarta-bsf id=bsf.jar / /maven And, based on what you said, for the xmlrpc, I am adding this: maven basedir=xmlrpc goal=jar property name=maven.jar.xmlrpc project=ws-xmlrpc id=xmlrpc.jar / /maven Hopefully this will work! There is a light at the end of the project, more of the fulcrum projects properly gumped last night! Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 7:13 AM To: Gump code and data Subject: Re: How to refer to ws-xmlrpc as xmlrpc? On Thursday 21 October 2004 05:56, Eric Pugh wrote: Okay.. Sorry for being dense but.. Where do I put this: maven.jar.artifactID = path to Jar For all normal cases; You don't. It is done in the maven.py script. I am not even sure it will work for non-normal cases, and if a proper classpath can be picked up at all, but I think IF it doesn, it would be something like; maven goal=jar basedir=whatever property name=maven.jar.abc project=abc-project id=IdOfAJar / /maven But I am not sure... 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: How to refer to ws-xmlrpc as xmlrpc?
So.. From looking at the third reference, and then looking at some examples, what I want is this: depend property=xmlrpc.jar project=ws-xmlrpc/ And then when Maven runs, it will look for xmlrpc.jar. So, something is telling Maven that it is NOT looking for xmlrpc-1.1.jar (which is what is defined in project.xml) but instead to look for xmlrpc.jar. And the depend property=xmlrpc.jar project=ws-xmlrpc/ says go look at this project for what you need.. Is this correct? Eric -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 4:17 PM To: Gump code and data Subject: Re: How to refer to ws-xmlrpc as xmlrpc? For this project: http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcr um-xmlrpc/ gump_work/build_jakarta-turbine-fulcrum_fulcrum-xmlrpc.html Maven is failing looking for xmlrpc as a dependency. Unfortunantly, in Gump, xmlrpc is called ws-xmlrpc. I already have the dependency: It doesn't matter (so much) that Gump and Maven call the project something different, although (over time) it might be nice to standardize. [It matters only for the Maven Gump goal automatically generating the Gump descriptor.] For now --- all that matters is that the Gump jar id matches the Maven artifactId. depend project=ws-xmlrpc/ From the docs, doing this isn't what I want: depend project=ws-xmlrpc ids=xmlrpc/, what about doing this: depend project=ws-xmlrpc id=xmlrpc/? Stefano and I were just discussing this. The depend element is confusing, and incompletely documented. Looking at this, we have the simple case: http://gump.apache.org/metadata/project.html#depend There is a more complex case (barely mentioned in this part): http://gump.apache.org/metadata/project.html#project I believe the logic here (when a depend is inside ant or maven or whatever) is that one sets attributes that are (1) a property name and (2) an id (singular), and one effectively gets both a depend and a property. Hmm, hold on I found this documentation: http://gump.apache.org/metadata/builder.html#depend regards Adam - 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: Please install javamail-1.3.1.jar into Gump
Why yes there is a search engine: http://maven.ozacc.com/. However, that doesn't help because mail.jar isn't a redistributable package. However, there is a maven issue open at: http://jira.codehaus.org/browse/MAVEN-1472 that has some suggested names. I think that is as good a place as any to look. Once we pick something it should spread from there. While you are at it.. Can you install activation-1.0.2 as well? It also has the same issue with no specific naming convention. Eric -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 4:44 PM To: Gump code and data Subject: Re: Please install javamail-1.3.1.jar into Gump Niclas Hedhman wrote: On Wednesday 20 October 2004 17:31, Eric Pugh wrote: Hi, Quite a few of the Jakarta Turbine Fulcrum components use the javamail-1.3.1.jar version of JavaMail. Currently Gump has javamail-1.3 installed. Can we have this dependency upgraded? This will remove the last obstacle to our components compiling under Gump. This is not about 1.3 vs 1.3.1, never was... Please proceed and change to whatever version you like. Now, the problem is about the 'exposure' of the Jar's from their names on the Brutus filesystem, vs the name expected in your projects. Stefano gave me heads up earlier that he is tackling this in a generic fashion, since it won't scale if we go in and ask for changes in each project. That means that we will be able to declare in the Gump descriptor that abc.jar is used for an def-x.y.z.jar by Maven (and others), so that in the overrides file, maven.jar.override = on maven.jar.abc = /usr/local/./javamail/mail.jar is generated. This will solve all projects with a similar situation and allowing all the existing ant-wrappers for Maven projects to go away. So, just hang in tight, and the problem will be solved at Gump's end. I just discussed this with Adam and he suggested that rather than introducing further complexity in the metadata, we change the exposed jar ID so that they match maven's. What is the maven ID for the mail.jar package? Is there a search engine for maven artifacts? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to refer to ws-xmlrpc as xmlrpc?
Okay.. Sorry for being dense but.. Where do I put this: maven.jar.artifactID = path to Jar ? Is this something that goes in project.properties? Or does this go in the jakarta-turbine-fulcrum.xml file someplace? Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 7:19 PM To: Gump code and data Subject: Re: How to refer to ws-xmlrpc as xmlrpc? On Wednesday 20 October 2004 23:55, Eric Pugh wrote: So.. From looking at the third reference, and then looking at some examples, what I want is this: depend property=xmlrpc.jar project=ws-xmlrpc/ And then when Maven runs, it will look for xmlrpc.jar. So, something is telling Maven that it is NOT looking for xmlrpc-1.1.jar (which is what is defined in project.xml) but instead to look for xmlrpc.jar. And the depend property=xmlrpc.jar project=ws-xmlrpc/ says go look at this project for what you need.. Is this correct? I don't think so. AFAIK, the only properties that Maven cares about are of the format; maven.jar.artifactID = path to Jar Cheers Niclas - 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: gump/maven plugins dependencies are broken
I may just take the simplifying approach of avoiding requireing a plugin at build time. There are a number of issues with Maven 1.0 and plugins being download and installed. Especially with multiple versions of a plugin. Additionally, the biggest thing I want is compilation verification which can be done easily via Ant.. For Fulcrum components the path of least resistence may be to just to switch to Ant for now.. Eric -Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 10:53 PM To: [EMAIL PROTECTED] Subject: gump/maven plugins dependencies are broken Have been trying to sort out an issue concerning dependency logic related to maven plugins during gump runs. If we take a look at the Fulcrum MimeType Impl project it declares a dependency (inside the maven project.xml) to the avalon-meta-plugin. Normally maven will load the plugin at buildtime (which involves the creation of a plugin classloader which in the case of the avalon-meta-plugin involves loading about 6 or 7 other jar files that are declared in the plugin's project.xml (embedded in the plugin jar file). However - something very strange is going on. Maven appears to be loading the version of the plugin declared in the project.xml and NOT the version of the plugin supplied by gump. This means that the wrong dependencies get pulled in - demonstrated by the fact that maven is complaining about a missing dependency excalibur-configuration. Please note that excalibur-configuration is *not* a dependency with the plugin supplied by gump - but it is a dependency in the version of the plugin declared in the project.xml file. Here is the build result referencing the invalid missing excalibur-configuration dependency. http://marc.theaimsgroup.com/?l=turbine-devr=1b=200410w=4 My conclusion is that the gump builder for maven is expanding dependencies based on the project.xml versioned plugin declaration via a remote repository instead of expanding the project.xml of the latest version of the plugin. The thing here is that there is no information available to the gump for maven builder to tell it where to find the plugin's project.xml. A possible solution here is to provide additional information to the builder - possibly a gump.properties file that would tell the gump builder where to find the definitive project.xml for the plugin. My currently feeling is that this issue is likely to block the majority of builds in the Fulcrum repository. Any suggestions? Stephen. - 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: Please put in gump repo the tagishauth-1.0.3.jar
Humm.. OSUser isn't listed on the homepage, but does exist as a CVS repo. I'll dig deeper and get back to you. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 2:31 PM To: [EMAIL PROTECTED] Subject: Re: Please put in gump repo the tagishauth-1.0.3.jar On Tue, 19 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: On Tuesday 19 October 2004 19:42, Stefan Bodewig wrote: The jars you list come from four different Opensymphony projects. I can't find OSUser on opensymphony.org at all, BTW. We might want to build all of them from source one day, so they should be separate Gump projects instead of one big one. This is my fault. I recommended the four Jars in one project, simply due to I thought it was more convenient with 1 dir with 4 Jars instead of 4 dirs with 1 jar each... Either way can do, no technical obstacles. OK, I've added osworkflow, oscore and propertyset - using the latest downloads from Opensymphony. I didn't add OSUser since I can't seem to find it there. Stefan - 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]
Please put in Gump Repo some OpenSymphony jars
Hi all, For the Fulcrum Security NT component, we need a tagishauth-1.0.3.jar that don't have CVS access to. I have committed /projects/tagish.xml and commented out the jar in the file. Can somone add them to the gump repo and uncommment out the section in tagish.xml? Thanks, ERic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please put in gump repo the tagishauth-1.0.3.jar (was)RE: Please put in Gump Repo some OpenSymphony jars
Sorry, this was a cut and paste error. Over the weekend I added opensymphony.xml and tagish.xml projects. These require a couple jars if someone could be kind enough to install them. The jar's and locations are in the project .xml files. Sincerely, Eric -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 12:44 PM To: gump Subject: Please put in Gump Repo some OpenSymphony jars Hi all, For the Fulcrum Security NT component, we need a tagishauth-1.0.3.jar that don't have CVS access to. I have committed /projects/tagish.xml and commented out the jar in the file. Can somone add them to the gump repo and uncommment out the section in tagish.xml? Thanks, ERic - 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: Fulcrum updates
Thanks.. I'll be watching today as well! -Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: Saturday, October 16, 2004 10:26 AM To: [EMAIL PROTECTED] Subject: Fulcrum updates Based on the last Gump run I've gone through and updated all of the Fulcrum projects - changing the home and jar path values. Seems that the outputs generated my maven and the outputs in the gump defs were out of sync. Steve. - 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]
Please put in Gump Repo some OpenSymphony jars
Hi all, For some fulcrum components, we need some OpenSymphony project jars. I have committed /projects/opensymphony.xml and commented out the individual jars in the file. Can somone add them to the gump repo and uncommment out the section in opensymphony.xml? Thanks, ERic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Some progress on Fulcrum Component Builds!
I am a little confused.. Why is the behavior of avalon-merlin-unit
special/more difficult then any other dependency?
Just as an FYI, my attempt to get fulcrum-crypto-api to build by changing
the dependency from avalon-merlin-unit to merlin-unit failed. I guess that
was reasonable enough. So I have changed it back. However, I saw this
usage (taken from avalon-trunk.xml):
depend project=avalon-merlin-unitnoclasspath//depend
So, I added that into my fulcrum-crypto-api section.
At any rate, now all the plugins seem to be installed for Maven and those
errors are gone.
Eric
-Original Message-
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Sent: Friday, October 15, 2004 12:02 PM
To: 'Gump code and data'
Subject: RE: Some progress on Fulcrum Component Builds!
-Original Message-
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
Sent: 15 October 2004 07:06
To: Gump code and data
Subject: 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.
Can we just put a symlink in place that links merlin-unit to
avalon-merlin-unit?.
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Some progress on Fulcrum Component Builds!
Great news! Last question (well probably not...) In the latest jakarta-turbine-fulcrum, all the jars are now versioned: jar name=fulcrum-pool-api-1.0.2.jar/ Is this due to some sort of issue with how the projects depend on each other? In the future, if I bump a version in my project.xml, should I also fix it here as well? Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 12:37 PM To: Gump code and data Subject: Re: Some progress on Fulcrum Component Builds! Hi, Solution acquired. You keep merlin-unit in your Maven descriptors. I have created a new merlin-unit project in Gump, which inherits the Jar from avalon-merlin-unit. Everyone happy :o) Niclas On Friday 15 October 2004 19:29, Eric Pugh wrote: I see! This makes sense! Never thought about the impact on name changes on consumers of your code.. At least not in the way Gump is a consumer. So, because I use a specific version of merlin-unit, I am fine in my project. I can't change it to avalon-merlin-unit until the next version comes out. However, because of the name change, and Gump using the latest and greatest, my project doesn't know about the new version. So, in these types of situations, should I just somehow setup a package that I depend on, which would be the merlin-unit-3.3.0.jar version? Alternatively, should Gump's record for avalon-merlin-unit be annotated with all the prior names, so that at the end of the run it produces avalon-merlin-unit-@@DATE@@.jar as well as merlin-unit-@@DATE@@.jar? Or lastly, Could we just make another project record and just copy everything it does and change the last line to this: project name=avalon-merlin-unit license name=central/system/license/LICENSE.TXT/ ant basedir=runtime/merlin/unit !-- for magic -- property name=build.sysclasspath value=last/ property name=magic.home reference=home project=magic/ property name=gump.signature value=@@DATE@@/ SNIP/ !-- end for -- home nested=runtime/merlin/unit/target/deliverables/ jar name=jars/merlin-unit-@@DATE@@.jar/ nag to=[EMAIL PROTECTED] from=Magic Integration lt;[EMAIL PROTECTED]gt;/ /project Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 12:15 PM To: Gump code and data Subject: Re: Some progress on Fulcrum Component Builds! On Friday 15 October 2004 19:10, Eric Pugh wrote: I am a little confused.. Why is the behavior of avalon-merlin-unit special/more difficult then any other dependency? That is due to a name change. merlin-unit is needed in your Maven descriptor since that has been released before. avalon-merlin-unit is the new name, and that is the Gump descriptor generated. So, when you add depend project=avalon-merlin-unit/ you will not get the proper override for the Maven descriptor, and Maven will report that merlin-unit-x-x.jar can not be found. 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] -- +--//---+ / 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: 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: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml
Hi, I think my last email came late into the process. Let me know what I can do to help. I noticed that for the fulcrum-naming component, I was able to remove the xerces implementation and xmlparserapi's from the project.xml and have everything work. When making these types of changes, do I need to then update the jakarta-turbine-fulcrum.xml file? I know that maven automatically adds them if they are missing. ERic -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml On Tue, 12 Oct 2004, Stephen McConnell [EMAIL PROTECTED] wrote: -Original Message- From: Stefan Bodewig There is no jakarta-turbine-fulcrum project (anymore?), There sure is. They have a bunch of projects producing a swag of components. There is a jakarta-turbine-fulcrum /module/, no /project/. Nothing you could use in a single depend. Stefan - 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: Gump descriptors for Fulcrum components.
Okay.. Starting to get it! So, I noticed that I got another batch of errors. However, they still are freaking out about the xml-xerces2 dependency. However, I just checked the jakarta-turbine-fulcrum.xml and those entities where recently removed. How long do I have to wait till the next run? I see details on when it ran, but not when it will run again. Also, fulcrum-security-nt requires on a jar called tagishauth.jar. Should I create in /gump/project/tagishauth.xml file simiilar to the javamail.xml file? However, I don't quite see where the jar would download from.. One of the standard repositories? Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 12:46 PM To: Gump code and data; Turbine Developers List Subject: Re: Gump descriptors for Fulcrum components. On Tuesday 12 October 2004 18:40, Stefan Bodewig wrote: I have no idea what you'd have to do to make it work with Maven. I don't believe there's been a release of beanutils that would reflect this change, yet. The general rule is; The project name in the depend element of the Gump descriptor must have the same literal characters as the artifactId or id (recommended to change to artifactId element) in the project.xml. When that is NOT possible, i.e. not possible to change the Gump descriptor to match the Maven artifactId, then one have to resort to manual Jar overrides in Maven, using depend property=something project=abc/ constructs. See Maven manual about Jar Overrides. 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: Gump descriptors for Fulcrum components.
One more thing... Scarab (scarab.tigris.org) uses an older branched version of jakarta-turbine-fulcrum. This produced a single large jar called fulcrum.jar. However, Fulcrum head, and the current item to integrate is a series of seperate components. So, I believe this means that we need to create some sort of project dependency, similar to how projects depend on mail.jar. I don't think there is any real need to build this branched version of Fulcrum as only jakarta-turbine-3 and scarab rely on it. and turbine 3 is a dead end development spike and Scarab is moving away from the branched to the CVS HEAD version of fulcrum. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 12:40 PM To: [EMAIL PROTECTED]; Turbine Developers List Subject: Re: Gump descriptors for Fulcrum components. On Tue, 12 Oct 2004, Eric Pugh [EMAIL PROTECTED] wrote: And what does this error mean? I notice in the gump config file that there is a dependency on commons-beanutils-core. I changed it after the build failure. commons-beanutils has been split into *-core and *-beanutils-collections. For most projects replacing commons-beanutils with commons-beanutils-core just worked. I have no idea what you'd have to do to make it work with Maven. I don't believe there's been a release of beanutils that would reflect this change, yet. Does that mean I should be depending on that somehow in my project.xml? Probably. Or, should I update the dependency in the gump file to commons-beanutils from commons-beanutils-core. There is no commons-beanutils in Gump anymore. Stefan - 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]
Process for removing Gumped projects?
Hi all, Since we seem to be doing the spring cleaning process for Turbine and Fulcrum, I wanted to find out the process for removing gumped projects. I assume just delete the file from /gump/project/. I am thinking of removing jakarta-turbine-jyve jakarta-turbine-origami jakarta-turbine-flux These are old projects no longer maintained. While I haven't yet called for a vote, I wanted to make sure the process. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Gump descriptors for Fulcrum components.
well, it looks like it was removed, so the next gump run shouldn't fail on the xml-xerces2 dependency. I am off to lunch, hopefully it'll be done when we get back! Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 2:11 PM To: [EMAIL PROTECTED] Subject: Re: Gump descriptors for Fulcrum components. On Tue, 12 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: a. The Xerces stuff I don't understand either... Adam? xml-xerces is Xerces-J 2 in Gump. xml-xerces2 doesn't exist. There is xml-xerces1, if you really want that. Stefan - 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: Gump descriptors for Fulcrum components.
Can you supply some information on what we should change them to? To be honest, I've kinda quit watching the Avalon related mailing lists for the past while. But I guess, if we are going to participate in Gump builds (which is a *good* thing) then we need to start pacing the latest and greatest changes. I am working through the issues, and a couple have come up! Fulcrum-Configuration-Impl[1] seems to be dying because of a commons-beanutils dependency error. I just updated the project.xml formatting, and some references. Do I need to do anything to get Gump to pick up these changes? And what does this error mean? I notice in the gump config file that there is a dependency on commons-beanutils-core. Does that mean I should be depending on that somehow in my project.xml? Or, should I update the dependency in the gump file to commons-beanutils from commons-beanutils-core. Also, looking for example at crypto-api [2] it looks like some dependencies are missing. Is this because they need to be built by the plugin? Eric [1] http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-configu ration-impl/index.html [2] http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-crypto- api/gump_work/build_jakarta-turbine-fulcrum_fulcrum-crypto-api.html -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, October 11, 2004 8:35 PM To: [EMAIL PROTECTED] Cc: Gump code and data Subject: Gump descriptors for Fulcrum components. Hi, I am working on pulling more projects in under the Gump umbrella, and just asked Maven to generate all the Gump descriptors for the Fulcrum components. These are now being added to the gump/project/jakarta-turbine-fulcrum.xml module in Gump, which you all committers can modify. Any help to get this in order is greatly appreciated. Looking at it, I can see that there are cause for you to upgrade your POM artifactIds, for instance for Avalon, Merlin and Logkit, which are no longer accurate. Anyway, this will take a while to get right, so don't fall off the chair when Gump will hammer you with Nags. 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: Remove jakarta-turbine-tdk from Gump?
Okay, I believe I took care of it. If I broke gump, will I recieve some sort of notification. This is my first time through the process, and it was remarkably easy! Eric -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 6:35 PM To: Gump code and data Subject: Re: Remove jakarta-turbine-tdk from Gump? So if you check out Gump (now in SVN) and go to the 'project/' directory, you will find heaps of XML files in there. You probably find the TDK project inside a turbine xml file. Just to clarify, Gump code is in SVN, Gump metadata is still in CVS. Before doing so, please check that there are NO OTHER dependencees, which can be checked on the Gump Output website (found in the mail). Good point. Checking it, I don't see any. Eric, please remove the module descriptor file for this (project/jakarta-turbine-tdk.xml), and the reference to it in the gump profile (profile/gump.xml). regards Adam - 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]
Remove jakarta-turbine-tdk from Gump?
Hi all, I'm a committer on the jakarta turbine project. For a while now we have been getting failure reports for jakarta-turbine-tdk, which is good, as we like to know when turbine projects fail. However, at this point in time, the TDK is being phased out in favor of a different approach to getting people up and running with Turbine. Therefore the gump processing isn't required. Would it be possible to remove jakarta-turbine-tdk from the list of projects to process? is this something I can do? Or something on the gump side of things..? PS, the from message on joining says: I'm working for my owner, who can be reached at [EMAIL PROTECTED] Acknowledgment: I have added the address [EMAIL PROTECTED] to the general mailing list. Welcome to [EMAIL PROTECTED] -- almost sent the first message to the wrong list. Thanks a bunch, Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove jakarta-turbine-tdk from Gump?
Great! I'll tackle it and see how I go.. Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 5:40 PM To: Gump code and data Subject: Re: Remove jakarta-turbine-tdk from Gump? On Monday 09 August 2004 23:25, Eric Pugh wrote: Would it be possible to remove jakarta-turbine-tdk from the list of projects to process? is this something I can do? Or something on the gump side of things..? All Apache committers automatically have access to Gump's project files (other files?). So if you check out Gump (now in SVN) and go to the 'project/' directory, you will find heaps of XML files in there. You probably find the TDK project inside a turbine xml file. Before doing so, please check that there are NO OTHER dependencees, which can be checked on the Gump Output website (found in the mail). 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: commons-compress - Gump/Maven issues?
I don't know what extent you want to push back on the projects that gump builds, but it seems to me that they are either doing something that pushes maven beyond it's limits, or the decriptor might be out of date. I checked out jakarta-commons-sandbox/compress to investigate furthur, but I don't see this descriptor property you are talking about.. Could you enlightenme on this? Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, June 21, 2004 5:30 PM To: Gump code and data Subject: Re: commons-compress - Gump/Maven issues? On Monday 21 June 2004 22:47, Stefan Bodewig wrote: (1) The descriptor of commons-compress sets a property named component.version and hopes to get this into the jar name, which obviously doesn't work that way. Maven still uses /project/currentVersion from the POM. If no Maven guys are around... My wild guess would b to try to set pom.currentVersion property instead. Then it is a question if Maven overwrites it or not... (2) The work entry inside the descriptor pointed to nowhere and there is no work entry for the generated test classes, still the test goal manages to load the freshly compiled test classes. This means that we are not getting the effect of build.sysclasspath=only in Maven builds. The jar overrides will catch the artifacts Gump knows about but Maven will happily let the goals (plugins, tasks, I don't know the correct terms) add more stuff to the classpath itself. Sorry, this is beyond my knowledge, but hardly surprises me. For things like work directories for compiled classes this probably is good, but it may also lead to situations where Gump doesn't manage to substitute a jar from CVS with a freshly compiled one. Generally, Maven will happily download the required Jars from remote repositories, which normally can be disabled by running off-line mode (-o). However, what it builds today will be available in the local repository for use tomorrow, so I guess you are missing to nuke the local repository ( normally in $HOME/.maven/repository) 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: Existence of a database?
I find that depending on an external database makes the unit tests very brittle.. Unless you are specifically testing something that requires a specific type of database, I find that using hsqldb or axion works fine.. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: Re: Existence of a database? On Sat, 15 May 2004, Ceki Gülc [EMAIL PROTECTED] wrote: Could we assume that gump machines have a database that these test cases can connect to? You can savely assume that hsqldb is around[1] but not installed in any way. I.e. you could make your tests depend on hsqldb and they'd work in Gump. Even if some Gump machine may use some kind of DB in the future (to gather historical data or whatever else we come up with), there'll be no guarantee that all machines have one. Stefan Footnotes: [1] http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html - 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]
