Gump Repository (was [collections] new snapshot to ibiblio)
Definity seeing the contents of this would help me make more informed recommendations concerning the repository structure. I can live without the MD5's at the moment Actually, I find it was configured to be not public (i.e. not under the HTTP path). I've done a find -print to here: http://brutus.apache.org/gump/public/repolist.txt Right now (without metadata changes for Gump, but I know they are going to be needed) we have projectName (not moduleName) = groupId, jar ID = artefactId. This works ok for many, I believe. FWIIW: This is modelled more after Maven-style than ASF style right now. Also, we are (here) respecting redistributable (so things are not present). http://gump.apache.org/metadata/project.html#redistributable My intention/hope is to use a tool (e.g. Depot) to publish these to an ASF-style repository, with MD5s, and have a complete list (even if somehow private/locked-down from redistribution). regards, Adam - 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: [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. Gump currently invokes Maven providing it with jar overrides from Gump produced jars (it also sets it 'offiline', to ensure control). So, for me, the question becomes -- what jars does Gump use (see below). 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. We've been discussing cases where we try to pick 'the very latest that works', in cases where CVS HEAD doesn't work. (Trying to get 600 or so projects all to work correctly at one point (allowing for real world API shifts, aka progess/clean-up) is like star alignment ... not seen in many folks lifetimes. ;-) As such, I could (personally) see a dated snapshot available to be used. 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. I differ slightly from Stefan here, although I think we agree in principle. I think that Gump ought maintain an ASF-format repository (probably closed only to Gump, or those who know it is Gumped) so that it can go and gather 'the very latest that works'. I could see that we could try to automate this, and/or we could cooperate with humans (via metadata) to give a hint. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
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. From experience, I can tell you that I welcome the new ability to fix certain dependencies. For example, the Avalon Project has made API changes that break compatibility with existing code. James ships with an earlier version of Avalon because of the incompatibility. Eventually, James will make the necessary changes, but that will happen on James' schedule, not Avalon's. But James also ships with Jakarta Commons DBCP, and will be using other Jakarta Commons packages. If James were forced to track the HEAD of all components, even when some of them are known to be incompatible, there would be no point in using GUMP, since failure can be assumed. However, with the new ability, James could fix the Avalon dependencies to the particular version(s) used, and still track HEAD for other dependencies. Actually, we need to correct/clarify something for the record. Gump has some of this already. It can use a CVS tag (or SVN branch) of some module to allow this. We used it yesterday because we are waiting for Commons Logging to become compatible with log4j CVS HEAD (to be known as 1.3). For CVS HEAD: http://lsd.student.utwente.nl/gump/logging-log4j/index.html http://lsd.student.utwente.nl/gump/logging-log4j/index.html#Definition And for log4j 1.2: http://lsd.student.utwente.nl/gump/logging-log4j-12/index.html http://lsd.student.utwente.nl/gump/logging-log4j-12/index.html#Definition See: module name=logging-log4j-12 tag=v1_2-branch We set C-L's dependency to logging-log4j-12 from logging-log4j. Adding the ability to get a dated/frozen build of a project [from a repository/store] allows further granularity (e.g. we coped with 1.3 up until X and would like to keep 'closer to' 1.3 than 1.2). Clearly the combinatorials are theoretically enormous, but (like tags) in practice they can be made to work. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] new snapshot to ibiblio
Gump has some of this already. It can use a CVS tag (or SVN branch) of some module to allow this. Which would work really well if Avalon had tagged their stuff prior to complaints about why tagging is sort of vital, but all that we have are the current jars. Not even the Avalon folks who later tried were able to reproduce the contents. Not that you need to support that problem. :-) And, yes, moving to a reproducible version of Avalon is on the agenda, right after we ship the next Release of James. And I would love to have James (both branch_2_1_fcs and MAIN) building with GUMP. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Noel J. Bergman wrote: Gump has some of this already. It can use a CVS tag (or SVN branch) of some module to allow this. Which would work really well if Avalon had tagged their stuff prior to complaints about why tagging is sort of vital, but all that we have are the current jars. Not even the Avalon folks who later tried were able to reproduce the contents. Not that you need to support that problem. :-) Just a point of clarification - James is released and running against an early unreleased version of Avalon content (the cornerstone.jar). The released (and tagged) version was made available about a year ago (and tested against James head prior to release). And, yes, moving to a reproducible version of Avalon is on the agenda, If you mean moving to a released version of Avalon then sure - that's highly recommended. right after we ship the next Release of James. And I would love to have James (both branch_2_1_fcs and MAIN) building with GUMP. One way to get a lot more value back from Gump for the James project would be to separate build descriptions for the different components that the James project is based on. * james core * dns * remote * pop3 * smtp * mail-store * user-store * spool * nntp-repository * nntp-server * fetchpop From here you would be able to get consistent feedback without the overhead of the relatively expensive dependency chain that exists in the current james server gump definition (23 direct, 203 implied). From this basis you could then worry about container strategies and put together a separate gump descriptor(s) that enables testing and packaging. If the above is *too* fine-grain, then why not simply break out your james server build from the container build? The Avalon project has already gone though the process of separating out the different subsystem that james is dependent (tagged in cvs and published under specific versions). Cheers, Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Repository (was [collections] new snapshot to ibiblio)
Adam R. B. Jack wrote: Stephen McConnell [EMAIL PROTECTED] wrote: http://brutus.apache.org/gump/public/repolist.txt Right now (without metadata changes for Gump, but I know they are going to be needed) we have projectName (not moduleName) = groupId, jar ID = artefactId. This works ok for many, I believe. Of the 97 Avalon related projects i9n Gump almost all produce artifacts where the current projectName != groupId. The jar ID and artifactId are however largely consistent. Thanks for the review, I kinda expected to have to add a groupId to the metadata, probably at the module level (that can be overridden at the project level, if needed). I haven't thought about it enough to propose anything yet though (and was kinda hoping to combine it with jar repository information, for the product, to kill a few birds at once. I've done some work to match a jar repository like a CVS or SVN one.) BTW: Would moduleName have been a better match for groupId than projectName? I could default the above to one of these two. Within the avalon projects we generally have: gump-project-name == maven-artifact-id But its not 100% consistent. Modules could be repackaged to match maven-group-id, but keep in mind that this would result in a large number of groups - for example, this would generate separate groups for avalon-framework, avalon-logging, avalon-repository, avalon-meta, avalon-util, merlin, etc., etc. But yes - module name is probably a better bet. The ability to declare the module under a gump project definition would be easy to incorporate. Some work would still be needed to breakout gump projects with multiple artifacts into one gump project per artifact and an aggregating project where necessary (e.g. avalon-framework should be separated into avalon-framework-api, avalon-framework-impl and avalon-framework recast as an aggregation of the two). Cheers, Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
