Re: Gump integration with Maven
Adam R. B. Jack wrote: Agreed. I think the real challenge is at the project level, projects need to establish naming consistent with their Umbrella group, this is a real growing pain at this point, I suspect eventually the entire Jakarta Commons will need to migrate to jakarta-commons/jakarta-commons-foo-x.x.ext from commons-foo/foo-x.x.ext sometime in the near future. But it would probably be good to have the system consistent before that point and keep such transitions separate. Could either of you elaborate, please? Are we having uniqueness problems? If not, what is the issue? regards Adam Its not really a concern at this time, just a groupId naming inconsistency in the Jakarta Commons that will eventually need resolution. Each Jakarta Commons project is defining its own groupId (commons-collections, commons-math, commons-lang) instead of using a global one (jakarta-commons) , this makes each subproject a totally separate project as opposed to just an Artifact of Jakarta-Commons. So currently in the Maven Repository we get /repo/commons-math/jars/commons-math.x.x.jar /repo/commons-collections/jars/commons-collections.x.x.jar /repo/commons-lang/jars/commons-lang.x.x.jar I think the Commons, we would rather eventually see: /repo/jakarta-commons/jars/jakarta-commons-math.x.x.jar /repo/jakarta-commons/jars/jakarta-commons-collections.x.x.jar /repo/jakarta-commons/jars/jakarta-commons-lang.x.x.jar But this is a Commons issue, not a Gump one. However, if you saw a major beneit in this we could use it as ammunition to push forward a change. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump integration with Maven
Brett Porter wrote: Yup, I think we need ASF-wide artefact ids (within group ids). I'd like to think the community and/or communities can come to agreement on what the values are, and if that means defaulting to what Maven/Ibiblio already have, then so be it. Consistency is the key more than anything else. Sounds like a sensible approach. I think the real challenge is at the project level, projects need to establish naming consistent with their Umbrella group, this is a real growing pain at this point, I suspect eventually the entire Jakarta Commons will need to migrate to jakarta-commons/jakarta-commons-foo-x.x.ext from commons-foo/foo-x.x.ext sometime in the near future. But it would probably be good to have the system consistent before that point and keep such transitions separate. -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
At this point I'm not sure what is correct. I only know that the efforts up to this point are to enable gump to use maven to accomplish a nightly build of a mavenized project, in which case you have an opportunity to control some of the dependencies when your project is integrated via the same mechanisms Maven is providing to you on the command line. I'm not 100% sure of this so I'm cross posting to the gump list to see if they agree with me on this subject. They may disagree entirely, in which case I am in error. Also, I'm not sure why you would want to fix your dependency to a specific snapshot release date when you the latest snapshot may be available to you via Gump/Maven. If you needed to rely on a specific version of a dependency, it would in my opinion, be a major release of that jar and not a dated snapshot. What I am saying is that you either base your development on the bleeding edge (SNAPSHOT) or a stable release (x.x), not on a possibly outdated and unstable dated or nightly build. This is what we are trying to break away from by getting the nightlies off of ibiblio and into a separate Repository. -Mark Mario Ivankovits wrote: Mark R. Diggory wrote: Ideally, the gump nightly build would also be of the dependency in the Apache case. If this was impossible, you could place the jar somewhere local for the gump build and point the project.properties to it using the jar override mechanism in Maven. http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies I thought i have understood GUMP - it seems not. My impression was, GUMP always use the cvs-head to build the dependencies - and fixing the dependency to a given release is not the intention of GUMP. The best i can do is to build a snapshot of the required dependency and put it to the apache repository and let GUMP automatically use the nightlies. Isnt it correct that way? -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump integration with Maven
I would suspect that the commons logging ant build.xml file has either been customized beyond the capabilities of maven, or was never actually generated from maven. If I think about this with my Maven hat on, a discrepancy arises. groupId: commons-logging artifactId: commons-logging artifactId: commons-logging-api As such these would/should be two separate projects within the commons-logging group. Each having a separate project.xml with the same groupId and different artifactId's. The source would be in separate directories and commons-logging would be dependent on commons-logging-api -Mark Stefan Bodewig wrote: On Fri, 14 May 2004, Brett Porter [EMAIL PROTECTED] wrote: Sorry... I didn't realise that gump had a notion of a project that produces multiple artifacts. Hmm, commons-logging is built by Maven. Its Ant build file produces two jars, commons-logging.jar and commons-logging-api.jar - how does Maven deal with this? Are these two separate projects? Or a group of two artifacts? This is the case we need to get mapped when running 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: Jakarta Commons Gumpification
Adam R. B. Jack wrote: Hey Bubba, ;-) So I've been reviewing the project.xml files in the Jakarta Commons and I see the gumpRepositoryId tag in them. In some its the projects name in others its just jakarta. Should this be set to something specific? It seems wierd to have multiple project.xml's with the same gump repository id in them? I don't know POM, but from a Gump point of view, I believe the name ought reference one of these: http://lsd.student.utwente.nl/gump/repositories.html Yes, it looks like these entries should all be jakarta for projects in the Jakarta Commons then. I think the contents of the Gump portions of the POMs might be stale. Folks generate the GOM (using maven gump) but then often edit by hand, instead of regenerating. I just sent you a message on commons-dev. Hopefully we'll see you back here. Yep, theres lots to discuss about this. We could use any pointers you can supply, I notice we already have a few commons projects getting run by gump. http://lsd.student.utwente.nl/gump/gump_repo/gump_work/update_jakarta-commons.html -Mark 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] which OS for new gump machine?
On Sun, 2004-03-21 at 21:43, Sam Ruby wrote: Leo Simons wrote: The new IBM boxen arrived, and infrastructure@ will be installing them this week. There's been quite a bit of talk about which OS to run on the machine. From the looks of it, we're probably getting Red Hat Enterprise Linux v3 (RHEL3). This is a quick vote to be sure we're in agreement that's a sane choice. Please place your votes: [] Linux [] RHEL [] Debian [] FreeBSD (probably 5.2.x) My vote is for Debian. I initially switched to Debian for my own personal use when Red Hat end of lifed the non-Enterprise version of the OS, but I quickly fell in love with apt-get. If any help is needed administering this box, count me in. I have some prior experience in configuring Gump boxes, and would like to become reacquainted with the Python branch. ;-) - Sam Ruby Hmm, I went to Fedora after the EOL on Redhat 9 was announced, which supports just about everything that was going on with the old Redhat series. I think of it as Redhat 9.1. I'm quite happy with yum, up2date and with the JPackage efforts, I can easily manage via rpm's the installation of Java and many Apache Java projects with little to no effort. -Mark -- Mark R. Diggory Software Developer - VDC Project Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
