[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]
Re: svn commit: r328073 - /gump/metadata/project/jakarta-turbine-3.xml
Hi, Scarab is hot on the trail of moving to T2, which is the mainline branch. Honestly, unless someone has a real bee in their bonnet to fix T3, I wouldn't worry about it. Also, even if we got T3 to build, there are a ton of other dependencies that Scarab has that would prevent it from building. I lean towards just removing it (didn't want to do it quite yet), and putting it back once we get Scarab properly on T2. We are working on some steps to deal with circular dependency on Intake, and hope to have that fixed next week. Eric Pugh On Oct 24, 2005, at 11:29 PM, Stefan Bodewig wrote: On Mon, 24 Oct 2005, <[EMAIL PROTECTED]> wrote: URL: http://svn.apache.org/viewcvs?rev=328073&view=rev Log: Jakarta-Turbine-3 is a dead end project. Turbine 2.4 is the current mainline brach, and 3 has been mothballed. No reason to maintain it in Gump. Except that Scarab depends on it. What shall we do? Remove scarab or re-introduce turbine-3, which is closer to be building in Gumo than turbine-2 (there is a circular dependency between turbine-2 und fulcrum-intake) BTW. 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]
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: [vote] turning off nagging until we feel gump is solid enough for that
I'm glad to see that Ceki is looking for the same thing I am looking for.. Notification of when my dependee's break due to my code change. I *think* that is MUCH more important then notification of when my dependency breaks. But, it all depends on the projects orientation. The needs of project with LOTS of dependees like Ant or Log4j are quite different from the needs of a project with very few dependee's but lots of dependencies like Scarab or Turbine. Out of curiosity, could these types of notifications be made as options? With some sort of sane defaults? Is there a feeling that attempting to build with previous versions that passed isn't a good idea? If project A depends on B, and then A fails due to incompatiblities with B, is it possible to try and build with the last version of B that was used when A actually built? Not sure how to express this in mathematical terms. This would allow for more things to build, but would require clear notification that project A can't build with the latest of B, but is okay with an older version. That is basically what projects are doing with the logging-log4j-12 branch, but in a manual fashion. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] turning off nagging until we feel gump is solid enough for that
You are right about the patch.. :-) Should scratch my own itches! Unfortunantly I know zip about python, but maybe it's time to learn. > -Original Message- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 01, 2004 3:44 PM > To: Gump code and data > Subject: Re: [vote] turning off nagging until we feel gump is solid > enough for that > > > Eric Pugh wrote: > > 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... > > Feel free to submit a patch. :-D > > No, seriously, gump is not really up to the task of keeping up with a > community of users that see it as a pain in the ass (myself included). > > I think it's better if we start to nag ourselves first and see how we > can increase the signal/noise ratio before we go back public. > > -- > 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: 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: [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: 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
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]
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: 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]
RE: BATCH: All dressed up, with nowhere to go...
Okay, I pinged the developer, and he was happy to be added to the nag as well. Eric > -Original Message- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Friday, November 26, 2004 11:30 AM > To: [EMAIL PROTECTED] > Subject: Re: BATCH: All dressed up, with nowhere to go... > > > On Fri, 26 Nov 2004, Eric Pugh <[EMAIL PROTECTED]> > wrote: > > > Hi all, I am a bit confused by this.. > > You are not alone. > > > 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 think this is what it should say 8-) > > > I followed the link provided and everything says Success. > > <http://brutus.apache.org/gump/public/dumbster/dumbster/gump_work/ build_dumbster_dumbster.html> A debug statement in a test misspelt Received and obviously nobody tried to compile the class before it went into CVS. 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: 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/workspac
RE: cvs commit: gump/project dumbster.xml
Looks like dumbster ran! Thanks for your help on this. It looks like commons-email was moved too. Can't wait for the next run! Eric > -Original Message- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 25, 2004 10:27 AM > To: [EMAIL PROTECTED] > Subject: Re: cvs commit: gump/project dumbster.xml > > > On 25 Nov 2004, <[EMAIL PROTECTED]> wrote: > > > Attempt to build dumbster from source now that it is available > > on SF.net > > We'll also need to remove the packaged information from the > profile, I will do in a few seconds. > > 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: cvs commit: gump/project jakarta-turbine-fulcrum.xml
That would be easier.. In the long and winding road of getting fulcrum to build that was originally setup and then removed. Back then my gump skills where so bad I didn't inquire furthur... It would be worth testing on one of the builds... > -Original Message- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 25, 2004 10:25 AM > To: [EMAIL PROTECTED] > Subject: Re: cvs commit: gump/project jakarta-turbine-fulcrum.xml > > > On 25 Nov 2004, <[EMAIL PROTECTED]> wrote: > > > Update jar names for released fulcrum components. > > Wouldn't it be easier to provide a property passed in by Gump to set > the version to a specific text instead of changing the Gump descriptor > every time. I think there is something like maven.final.name or > similar that we could use as > > > > > > 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: 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
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]
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
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]
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: 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: > > > - > > + > > 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; > > > > > > > > > > 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]
Last steps for Fulcrum?
I am down to 5 components not building for Fulcrum under Gump. I have listed each one and added my question/plea for help: fulcrum-bsf Maven is not finding bsf-2.3.0.jar, and there is an interesting error: Unhandled Property: maven.jar.bsf on: Maven on Project:fulcrum-bsf fulcrum-configuration-impl Nothing to fix, waiting for commons-configuration to release.. We have an API incompatiblity and there isn't anything we can do about it... May release a snapshot of commons-configuration to get around this.. fulcrum-security-nt Can someone send me the error logs? I have set this property: maven.junit.usefile=false so the junit output will show up in the build log, but I'm impatient.. I wish all the output of /target was copied to the website.. fulcrum-template Maven is looking for a jar called velocity-1.4.jar, however the gump descriptor is specifing jakarta-velocity. I looked through the other mavenized projects and amazingly could not find another one that specifies jakarta-velocity! fulcrum-xmlrpc Unit test failure.. I am doing the maven.junit.usefile=false trick again, but getting the logs would be nice! I am guessing that the error is related to starting up an XMLRPC server at this url: http://localhost:12345/RPC2 and something in Gump is preventing it. Maybe shouldn't be run in Gump anyway? I could use the property trick to pass in a "running in gump, skip test" signifier. Thanks again to everyone who's helped! - 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; > > > > > 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: 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 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?
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: 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]
[jira] Created: (GUMP-87) Be able to view unit tests (and other files) generated by Maven builds
Be able to view unit tests (and other files) generated by Maven builds -- Key: GUMP-87 URL: http://nagoya.apache.org/jira/browse/GUMP-87 Project: Gump Type: New Feature Reporter: Eric Pugh 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [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]
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 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]
Cleanup of jakarta-turbine-fulcrum dependencies
Hi all, I just recently changed the various Fulcrum components to use an integrated container. This means I am trying to remove all the Excaliber and Merlin references which should make Gump run smoother. Eric - 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 think it comes down to maintence. If projects have active committers who are trying to fix them when they break, then great, lets keep them. Regardless of where they come from. But, if projects are in the system that don't have active committers trying to fix them/deal with the issues, then lets remove them. I wish that we tracked who the "goto" person was versus just mailing list for various projects. Maybe set up a more flexible approach like 'after 10 failures' we contact the goto person to remind them. After '30 failures' then we remove any leaf projects. Part of the complexity of Gump is that so many things can go wrong. And when things start going wrong, the rate really speeds up and then everything goes wrong. And fixing it can seem like a mountain to climb. To help with the number of projects, have we thought about more aggressive use of installed packages? I know that goes against the current spirit of gump. But really, I don't care about the OpenSymphony dependencies I am using, I just want my ASF projects that depend on OpenSymphony code to build under gump! Maybe someday, when everything is rocksolid, then I'll start paring out the number of packages that I am using. 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... Eric > -Original Message- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: Monday, November 01, 2004 10:40 AM > To: Gump code and data > Subject: Re: [proposal] removing non-ASF leaves from the workspace > > > On Monday 01 November 2004 17:00, Leo Simons wrote: > > Kaffe is very much a leaf not a dependency (I know no ASF project > > that can only be built using Kaffe), yet using it for experimental > > runs doubles the amount of cpu and disk space used. > > For the record, there are 8 attempts at starting a Gump build every day. > 1 is Kaffe, 1 is JDK1.5, 1 is 'test' and the others are the > official build. > So, it is not completely accurate to say that the Kaffe build > instance doubles > CPU/disk resources. > > > While I appreciate the goal of being able to have a truly free java > > stack and how using Kaffe to build ASF projects helps towards attaining > > that goal, we're also doing "public service" towards the GNU people in > > this way. > > Looking at the fact that a Kaffe developer (dalibor) has taken > interest in > Gump, installed his own instance and trying hard to get things > going, is IMHO > a good testament to the appreciation of Gump. > > > If you have a figure showing this saves significant cpu/disk space that > > we need for other stuff, you'll get (grudgingly) a +1. > > CPU/disk is basically a financial issue. If it is constrained > today, we can > take temporary measures to exclude projects to make room. > > Some external dependee projects don't build, and is 'annoying' in > the reports. > We can either remove them, or choose a better snapshot from their CVS. > > Those are short-term issues, and I think that removal of > non-fixed dependee > projects are adequate in the short-term. > What we should start discussing is, how do we scale Gump 'real big'? > If company A, can take part of a massive Gump build, provided > that they make > server(s) available for a massively parallelized builds, then I > think *many* > would like to be part of the Gump service, and therefor ASF will > have access > to 'unlimited' CPU/disk resources for those builds (i.e. each > participants > will make available more resource than their part will consume). > > IMHO, this is a tangible, highly interesting and highly valuable > challenge, > and not beyond reach. > > 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: excalibur-configuration
I think I tried it and broke the gump build.. Niclas had to go put it back in. At any rate, once gump is back to 100% on fulcurm components, then I'll start experimenting with removing dependencies. > -Original Message- > From: peter royal [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 28, 2004 5:31 AM > To: Excalibur Developers List > Cc: Gump code and data; [EMAIL PROTECTED] > Subject: Re: excalibur-configuration > > > On Oct 27, 2004, at 3:34 AM, Eric Pugh wrote: > > I am not sure how we depend on it.. It seems like things just fail if > > we > > don't have it... > > sounds like the easy solution is to remove the dependency and see what > happens :) > -pete > > > > >> -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] > > Apache Excalibur Project -- URL: http://excalibur.apache.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: 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: 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? > > > > > > > > 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: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
I guess that would help. However, a challenge for me is that everytime I add a dependency to my project.xml I also need to inform gump. As I have gotton more and more used to Maven, I don't even think about dependencies beyond manipulating project.xml. However, you are right that the module reference being able to point to external source repositories addresses the access issue. Eric > -Original Message- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 26, 2004 11:19 AM > To: Gump code and data > Subject: Re: project version changes and Maven WAS: cvs commit: > gump/project jakarta-commons.xml > > > On Tuesday 26 October 2004 16:34, Eric Pugh wrote: > > > From my perspective, I see it as a major issue that the only > way to create > > the gump descriptor is to have CVS access to gump. Which is > fine for ASF > > folks, but raises the bar for other outside to participate. I > can see, at > > least for the Maven POM projects, that building the gump descriptor at > > runtime would lower the barrier to participation. > > I don't think this changes anything. > You would still need to instruct Gump to use Maven POM somewhere, > which must > be done by ASF committers. And today, you can put in a module > reference in > the profile/gump.xml that points to external source repositories, > i.e. let > outside folks handle it. > > Cheers > Niclas > -- >+--//---+ > / http://www.bali.ac/ > / http://niclas.hedhman.org / > +--//---+ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
I am wholeheartedly in favor of generating the gump descriptors. Question.. Would this be something that the project would have to do and then check into CVS? Or would gump perform this step? >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. Eric > -Original Message- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 26, 2004 12:16 AM > To: Gump code and data > Subject: Re: project version changes and Maven WAS: cvs commit: > gump/project jakarta-commons.xml > > > Brett Porter wrote: > > > I had to get some background from Eric on IRC about this, as I > > couldn't find the original message. I hope I'm on the right track. > > I'll first discuss the general problem I see here and solutions, but > > there is a fix for this specific issue at the end I think. > > > > As I understand it, the general problem here is that the project.xml > > changes, and the gump descriptor is not updated. > > Well, the problem is that the way gump works is based on the fact that > ant properties can be "injected" into the build system, therefore gump > can overload the internal properties with external ones, for example, > with the "version" property. > > > The version is just a > > reflection of this, and it probably changes the most. Is this correct? > > The projects know what version they are working on, but gump doesn't > care and discards that versioning information and just build using dates > as versions. > > > I'd really like to go down the track of having gump effectively run > > "maven gump" for a project, then use the generated descriptor instead. > > This might help, yes. > > > What is involved in that from the gump end? I assume since it happened > > for magic, it must be possible. > > I'm ready to help out to make this possible. > > > I realise there are customisations people make, and there are two > > possible solutions - preferably to come up with a way to describe them > > elsewhere so the descriptor can continue to be generated, or for the > > descriptor generation to intelligently update one that already exists > > without removing the customisations. > > > > There may also be some builds doing funny things such that generation > > won't work - and they should be allowed to generate a descriptor in > > this case. They just need to take responsibility to keep it up to > > date. This shouldn't happen if they are following the Maven guidelines > > for a project set up. > > I'm totally in favor of using a straight out-of-the-box maven project > descriptor as an input for gump. > > > As much as I'd like to get the correct solution, you can probably > > overcome this now by specifying > > maven.final.name=expected_jar_name > > in gump's generated build.properties, which will result in > > target/expected_jar_name.jar > > This takes the version out of the equation. It may not work for all > > situations, but should be a good start. Anyone doing funny things in > > generating artifacts are going to have to take responsibility for the > > gump descriptor. > > I will apply this fix for now, thanks much, but I'm with you that we > should make it possible to mount a POM file instead of gump project > descriptor, if your project wishes to do so. > > What do others think? > > -- > Stefano. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to refer to ws-xmlrpc as xmlrpc?
Thank you! We are getting closer. But, if the challenges are insurmountable for the maven version, what do you think of using ant instead for the specific projects that have the javamail, xmlrpc,bsh, etc mismatching maven dependencies? I'd prefer maven, but, I really just want to make Gump happy! > -Original Message- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 24, 2004 2:05 PM > To: Gump code and data > Subject: Re: How to refer to ws-xmlrpc as xmlrpc? > > > On Sunday 24 October 2004 19:52, Eric Pugh wrote: > > 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... > > The version doesn't matter. > What matters is the match between the Maven artifactID and the JAR ID of > javamail. > I will spend some time on it and see what I can dig up. > > 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: > >id="bsf.jar" /> > >id="xmlrpc.jar" > > No, the id refers to the declared id in the 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 , 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: And, based on what you said, for the xmlrpc, I am adding this: 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. = > > 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; > > > > > > 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: 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-dev&r=1&b=200410&w=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: How to refer to ws-xmlrpc as xmlrpc?
Okay.. Sorry for being dense but.. Where do I put this: maven.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: > > > > > > > > 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 > > 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. = > > 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: 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?
So.. From looking at the third reference, and then looking at some examples, what I want is this: 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 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 > > >From the docs, doing this isn't what I want: ids="xmlrpc"/>, what about doing this: id="xmlrpc"/>? Stefano and I were just discussing this. The 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 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
Just to reconfirm.. This is a fix in progress.. Nothing I can do/need to do. For now, since javamail-1.3 is installed, I can swap to that, with the understanding that soon I can use javamail-1.3.1 and the override will work, right? Thanks! Erci > -Original Message- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 20, 2004 10:51 AM > To: Gump code and data > Cc: Turbine Dev > Subject: Re: Please install javamail-1.3.1.jar into Gump > > > 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. > > > 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]
How to refer to ws-xmlrpc as xmlrpc?
Hi, For this project: http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-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: >From the docs, doing this isn't what I want: , what about doing this: ? Thanks, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please install javamail-1.3.1.jar into Gump
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. Sincerely, Eric Pugh - 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]
RE: [RT] Selling Gump...
Niclas, Where do you see Gump fitting in compared to a tool like DamageControl or CruiseControl? From my perspective, I see Gump being a sort of uber-Continous Integration environment because of it's "build against the latest" ability, plus is "run any script" means that I can run my unit tests via Gump. I think that while building against the latest and greatest is a really good idea, especially for open source projects, that isn't everybodies opinion. A lot of users are happy to say "Use version X to work with my code" and are not interested in the latest and greatest options. Especially when things change names and this causes heartburn. But, if you tilt this as also running all my unit tests, then I am more interested! Run my tests? Maybe build my site and deploy it nightly? Wow! What a great service! I want to use it and help maintain it! Secondly, I think that the focus on building everything from scratch is a bit too strict. I added some unit tests to commons-email, but now I need to integrate a jar called "dumbster". Which means that I either have to get that to build as well, or get it installed. And the process of adding an installed package is too hard. I've got at least two requests out right now, and could send in more. I think that you should give me the option of either using an installed package or using the latest and greatest. If I want to build against commons-lang-1.0.1, then let me! I'll move to 2.0 when I'm ready. Right now, I have to use 2.0, and that is a bar to my using Gump. To sum up.. Better marketing of Gump and easier use of a specific version of a Jar would really help Gump's acceptance and percieved value. ERic > -Original Message- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: Monday, October 18, 2004 11:35 PM > To: [EMAIL PROTECTED] > Subject: [RT] Selling Gump... > > > > I think we need a major re-think about what Gump is and how it is > perceived > among our peers. > > Gump - The Apache Continous Integration Service. > > Keyword; "Service". > > We need to get rid of the "nags" in their current form. They are > probably too > intrusive and irritating. Instead of providing value to the projects, it > creates at best an 'ignorance' of those messages. I think any > project that > are somewhat downstream, is no longer bothering about the Gump messages. > > I am not entirely sure what should be done, since the best solution I can > think of is probably not applicable, and that is that whenever a > commit is > made, the project and all dependees are built, and if it fails, the > 'notification' goes to the committer. > We don't have enough CPU resources for such a brute approach. > > But I think we need to somehow tie the 'commits' into the build > loop, so what > when a regression occurs, a list of commits that may have > affected that build > can be reviewed easily. > > And secondly, let the Gump folks redirect the notifications > manually, to where > we believe them to belong. > > WDYT? > > 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]
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]
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 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: 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 and 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]
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: 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: > > > > > > > > > > > > > > > > > > > > > > > > > > > > >from="Magic Integration <[EMAIL PROTECTED]>"/> > > > > > > > > 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 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 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: 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 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]
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): 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: > > > > > to > > > > project="merlin-unit"/> > > > > > > > > > :o) > > > > > > > > No, the project here refers to the name within Gump, but I think > that > > the > > > > following is needed; > > > > > > > > > > > > > > > > Brett, do you have any insight in this?? Steve? > > > > > > AFAIK property is not needed. The gump plugin just generates: > > > > > > > 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!
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: > > > avalon/avalon-meta > > > avalon-meta-plugin > > > > > > avalon/merlin > > > merlin-unit > > > > 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]
Some progress on Fulcrum Component Builds!
Hi all, Yesterday on IRC "stefanom" (who I guess is Stefan Bodewig) helped me get some of the Maven plugins for building the Fulcrum components installed. So, for the fulcrum-crypto-api component( http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-crypto- api/gump_work/build_jakarta-turbine-fulcrum_fulcrum-crypto-api.html ), the good news is that last night one of them was found, the bad news is the other is missing: | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 The build cannot continue because of the following unsatisfied dependencies: merlin-unit-3.3.0.jar avalon-meta-plugin-1.4.0.jar (try downloading from http://avalon.apache.org) Total time: 2 seconds Finished at: Wed Oct 13 17:48:57 PDT 2004 I need someone to install into the "gump" users plugin directory the avalon-meta plugin by typing: maven plugin:download -DgroupId=avalon-meta -DartifactId=avalon-meta-plugin -Dvers ion=1.4.0 As far as the error on merlin-unit, I think that in the jakarta-turbine-fulcrum.xml file we depend on "avalon-merlin-unit" however, in the avalon.xml file it is defined as "merlin-unit", so I think I should change that to "merlin-unit": to ? Thanks all! 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]
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.
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]
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 element of the Gump descriptor > must have > the same literal characters as the or (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 > 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: 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 . > > 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]
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]
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: 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 entry inside the descriptor pointed to nowhere and > > there is no 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 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]
Maven Integration Status
Hi all, I joined the gump list because turbine dev list was getting lots of errors about the jakarta-turbine-tdk and jakarta-turbine-statum projects failing (and other jakarta-turbine-* projects). At this point, I haven't been recieving errors, and I checked, and this is due to commons-logging failing, which I have seen threads about. At this point, since the projects I'm responsible are all Maven built, should I be trying to use the Maven integration, or is that still very much a work in progress? Otherwise, should I be trying to patch the Ant versions of the builds to make Gump happy? Lastly, do I test my gump config by checking it in and just letting it run? I guess I'm trying to judge if I should dive into learning gump, or just let it ride for now? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
