Re: [collections] new snapshot to ibiblio
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 -Mark Mario Ivankovits wrote: Noel J. Bergman wrote: Why use snapshots? If you want to track *current* status, you really want to turn that over to GUMP GUMP could solve it too - and i like the idea to know ASAP about api-changes of dependencies, but if i commit my changes to the apache-cvs without pointing to the needet dependency-snapshot, their nightly builds will fail. This seems bad to me. It looks like (for now) we have to go both ways. -- 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
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]
Re: [collections] new snapshot to ibiblio
On Fri, 14 May 2004, Mario Ivankovits [EMAIL PROTECTED] wrote: but if i commit my changes to the apache-cvs without pointing to the needet dependency-snapshot, their nightly builds will fail. their != Gump I suppose. Since Gump would completely ignore the stated dependency version. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
On Fri, 14 May 2004, Mark R. Diggory [EMAIL PROTECTED] 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. This is the route Brett and Adam are taking for Gump IIUC. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
There is a convergence between the Gump Integration and this unstable repository which I hope is occurring, eventually, we hope that Gump will be used to produce a nightly build repository for projects, and that most projects will start taking advantage of this Continuous Integration for their development. I have been watching (lurking?) the Gump folks diligently working on this and I think its coming along. It is, but it'd happen a lot faster if you'd cease and decist lurking and start discussing. ;-) [I've had to stop myself sending you P2P mail asking for help more than once. Not having you involved has meant I've not focused on this. :-(] The Gump/Maven integration is raising good group/artefact issues, and the repository aspect is right next. Please come champion this cause it'll get a lot more focus. If you like, I can write up a proposal to the gump list to give you some context of the help I'd like, but mainly I just want your thoguhts/insights.] regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
On Fri, 14 May 2004, Mario Ivankovits [EMAIL PROTECTED] wrote: 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. Correct. 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. Gump won't use any repository at all, it will only use the things it has built itself. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Adam R. B. Jack wrote: There is a convergence between the Gump Integration and this unstable repository which I hope is occurring, eventually, we hope that Gump will be used to produce a nightly build repository for projects, and that most projects will start taking advantage of this Continuous Integration for their development. I have been watching (lurking?) the Gump folks diligently working on this and I think its coming along. It is, but it'd happen a lot faster if you'd cease and decist lurking and start discussing. ;-) I will, from this point on, cease and desist lurking! Scouts Honor! [I've had to stop myself sending you P2P mail asking for help more than once. Not having you involved has meant I've not focused on this. :-(] The Gump/Maven integration is raising good group/artefact issues, and the repository aspect is right next. I will review and comment on the subject. My concern would be to produce a comparable groupId/artifactId structure to that of the Apache Repository. Please come champion this cause it'll get a lot more focus. If you like, I can write up a proposal to the gump list to give you some context of the help I'd like, but mainly I just want your thoguhts/insights.] Please do, in the meantime I will review and comment on the discussion concerning Artifact Id's. -Mark -- 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. --- Noel - 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
On Fri, 14 May 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I differ slightly from Stefan here, although I think we agree in principle. Actually we don't differ at all. Once we have support for last good builds or something similar in Gump, they can certainly live in a ASF-format repository. And if pushing the created jars into repository structure helps with anything we do, then go for it. My Gump doesn't use any repository means right now. Stefan - 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
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. :-) Now I didn't follow that exactly (except to commiserate ;-) but there are also two other possibities that I'm not sure if they help you, or not. We could add a 'packaged project' a fixed set of jars we don't (including can't) build, for project XYZ-version see: http://brutus.apache.org/gump/public/packages.html Alternatively, you could add/reference the jars in your CVS, and add you own XYZ-version, kinda like james-server.xml does for dnsjava right now. And I would love to have James (both branch_2_1_fcs and MAIN) building with GUMP. If this means adding two modules, james-server and james-server-2_1_fcs, then go for it. If you need help, let us know. As you know (if you read the thread on [EMAIL PROTECTED] about freezing phoenix) we can't (todate) ensure that no unfrozen components somewhere within both dependency trees won't throw a spanner into the works. We can consider that if/when it occurs though. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Actually we don't differ at all. Once we have support for last good builds or something similar in Gump, they can certainly live in a ASF-format repository. And if pushing the created jars into repository structure helps with anything we do, then go for it. Actually, it does it today although somehow I dorked it up with directory synchronization for Forrest pages. The jars are written to a repository (not guaranteed ASF-format yet, and with no .MD5s yet) but then the run 'tidies' that up (deleting it). I'll fix that, and made the repository available for review. My Gump doesn't use any repository means right now. Ah, ok, understood. Thanks. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Adam, 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 Adam R. B. Jack wrote: Actually we don't differ at all. Once we have support for last good builds or something similar in Gump, they can certainly live in a ASF-format repository. And if pushing the created jars into repository structure helps with anything we do, then go for it. Actually, it does it today although somehow I dorked it up with directory synchronization for Forrest pages. The jars are written to a repository (not guaranteed ASF-format yet, and with no .MD5s yet) but then the run 'tidies' that up (deleting it). I'll fix that, and made the repository available for review. My Gump doesn't use any repository means right now. Ah, ok, understood. Thanks. 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: [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: [collections] new snapshot to ibiblio
On May 13, 2004, at 8:39 PM, Mark R. Diggory wrote: There is a convergence between the Gump Integration and this unstable repository which I hope is occurring, eventually, we hope that Gump will be used to produce a nightly build repository for projects, and that most projects will start taking advantage of this Continuous Integration for their development. I have been watching (lurking?) the Gump folks diligently working on this and I think its coming along. I think that implying that Gump will be used by every project is a bit ivory tower. The reality is some projects simply don't want or need continuous integration. Also, Gump is not the only continuous integration system in opensource. I am very concerned that about linking access to SNAPSHOTs to the use of a continuous integration system. Until this is complete, the unstable repository is available for those who need to release unstable builds. Because it is on cvs.apache.org, it is not mirrored, nor does it endup at ibiblio. This unstable repository should not be utilized by non-apache developers, eventually, we may consider some form of security to restrict access to it. This is a no go for geronimo. There are 3 other projects outside of apache that use geronimo snapshots and geronimo in return imports the snapshots from these other projects in to the final assembly. If snapshot access were turned off, our entire build system would stop to work. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] new snapshot to ibiblio
We could add a 'packaged project' a fixed set of jars we don't (including can't) build, for project XYZ-version see: http://brutus.apache.org/gump/public/packages.html Alternatively, you could add/reference the jars in your CVS, and add you own XYZ-version, kinda like james-server.xml does for dnsjava right now. I'll give those a look. In Dain's case, it sounds as if Geronimo needs to add cvs.apache.org repository to geronimo for any snapshots they are using. As you know (if you read the thread on [EMAIL PROTECTED] about freezing phoenix) we can't (todate) ensure that no unfrozen components somewhere within both dependency trees won't throw a spanner into the works. Nope, I haven't read it. Anything more we want to say about James should be on [EMAIL PROTECTED], not on Jakarta Commons. :-) I'm not going to respond to Stephen's message on jcdev, since it is exclusively about James. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Dain Sundstrom wrote: On May 13, 2004, at 8:39 PM, Mark R. Diggory wrote: There is a convergence between the Gump Integration and this unstable repository which I hope is occurring, eventually, we hope that Gump will be used to produce a nightly build repository for projects, and that most projects will start taking advantage of this Continuous Integration for their development. I have been watching (lurking?) the Gump folks diligently working on this and I think its coming along. I think that implying that Gump will be used by every project is a bit ivory tower. The reality is some projects simply don't want or need continuous integration. Also, Gump is not the only continuous integration system in opensource. I am very concerned that about linking access to SNAPSHOTs to the use of a continuous integration system. Until this is complete, the unstable repository is available for those who need to release unstable builds. Because it is on cvs.apache.org, it is not mirrored, nor does it endup at ibiblio. This unstable repository should not be utilized by non-apache developers, eventually, we may consider some form of security to restrict access to it. This is a no go for geronimo. There are 3 other projects outside of apache that use geronimo snapshots and geronimo in return imports the snapshots from these other projects in to the final assembly. If snapshot access were turned off, our entire build system would stop to work. -dain I'm just curious, what are those projects? My statement may sound a little too much like an ultimatum. The goal is to have both Apache and External projects releasing against Official Versioned Apache Artifacts as Dependencies not Unstable Versions. Of course, anyone interested in Developing against an Unstable version could utilize the Unstable Repository. If usage of the Repository became an issue in terms of server load, that would probibly be addressed at such a time. Also, Lets be clear here because I think there's a mixup in terminology which people are encountering: *SNAPSHOT* A link in the repository to the latest version of the artifact Examples: http://www.apache.org/dist/java-repository/commons-collections/jars/commons-collections-SNAPSHOT.jar commons-collections-SNAPSHOT.jar -- commons-collections-3.0.jar http://cvs.apache.org/repository/commons-math/jars/commons-math-SNAPSHOT.jar commons-math-SNAPSHOT.jar -- commons-math-20040313.204326.jar *Dated or Nightly Build* An unofficial release for developerment or integration testing purposes, it is an artifact in the repository identified by a date-version number instead of a full release version number. Example: http://cvs.apache.org/repository/commons-math/jars/commons-math-20040313.204326.jar *Offical Versioned Release* An offically voted on release of a projects artifact. http://www.apache.org/dist/java-repository/commons-collections/jars/commons-collections-3.0.jar SNAPSHOTS exist in both repository locations Unstable Repository http://cvs.apache.org/repository/ Official Apache Repository: http://www.apache.org/dist/java-repository/ In the unstable repository SNAPSHOTS point at Dated Builds, in the Apache Repository SNAPSHOTS point at Official Verisoned Releases. Remember the old Open Source Moto: Release Often, Release Early. Attempting to get the Unstable Repository contents built nightly via Gump is something we would like to try because its already building these artifacts, we're just trying to get the contents into the proper format and location. The automation makes it possible to build and test your project against the latest development build of its dependencies. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
On Fri, May 14, 2004 at 03:32:59PM -0400, Mark R. Diggory wrote: I'm just curious, what are those projects? OpenEJB is one of them. Tranql and ActiveMQ also. The list will grow as we integrate more projects. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] new snapshot to ibiblio
I use the LRUMap in the vfs project and need the new feature scanUntilRemoveable. Before i can commit the new class i also need a new snapshot of collections on ibiblio. Is this something i am allowed to do? (create a upload-bundle for ibiblio and request the upload) Or should this be done by an collections-project-committer only? -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
I am opposed to adding snapshots to ibiblio, as I have seen it create isues. IMHO ibiblio should be released/stable code only. I suggest that you use a local snapshot at the moment. v3.1 shouldn't be too far away... Stephen From: Mario Ivankovits [EMAIL PROTECTED] I use the LRUMap in the vfs project and need the new feature scanUntilRemoveable. Before i can commit the new class i also need a new snapshot of collections on ibiblio. Is this something i am allowed to do? (create a upload-bundle for ibiblio and request the upload) Or should this be done by an collections-project-committer only? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Ok, one of the beneifts of our new Apache Repository strategy is that dated snapshots do have a home. You can feel free to add them here for testing/development purposes internal to Apache. http://cvs.apache.org/repository corresponding directory structure is /www/cvs.apache.org/repository theres already some collection snapshots located there. Please read the directions at the above url for how to structure your contents. I'll eventually get the deployment scripts from Jason for deployment of upload-bundles. -Mark Stephen Colebourne wrote: I am opposed to adding snapshots to ibiblio, as I have seen it create isues. IMHO ibiblio should be released/stable code only. I suggest that you use a local snapshot at the moment. v3.1 shouldn't be too far away... Stephen From: Mario Ivankovits [EMAIL PROTECTED] I use the LRUMap in the vfs project and need the new feature scanUntilRemoveable. Before i can commit the new class i also need a new snapshot of collections on ibiblio. Is this something i am allowed to do? (create a upload-bundle for ibiblio and request the upload) Or should this be done by an collections-project-committer only? - 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: [collections] new snapshot to ibiblio
Stephen Colebourne wrote: I suggest that you use a local snapshot at the moment. v3.1 shouldn't be too far away... But then, i cant commit my changes as they depend on the latest api change - and i fell not very comfortable having a bunch of changed sources lie around here. But i definitely understand ibiblio should only hold released/stable code. I will have a look at Marks proposal and take a look at http://cvs.apache.org/repository. -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
On May 13, 2004, at 2:23 PM, Stephen Colebourne wrote: I am opposed to adding snapshots to ibiblio, as I have seen it create isues. IMHO ibiblio should be released/stable code only. Can you be more clear? I think ibiblio snapshots are great and would hate to see them go away. Think of all the projects out there that are using apache snapshots that would have to add the apache repo to their project. Not only is this a lot of traffic to apache, I think it also sets a bad precedent for other projects. Think of a project using a lot of snapshots and they have to add every small project's repo to the repo list (which may also add to the apache traffic as maven has no idea which repo may have the snapshot, so it tries them all in order) Anyway I'm rambling now I am curious about the issues this creates. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Dain Sundstrom wrote: On May 13, 2004, at 2:23 PM, Stephen Colebourne wrote: I am opposed to adding snapshots to ibiblio, as I have seen it create isues. IMHO ibiblio should be released/stable code only. Can you be more clear? I think ibiblio snapshots are great and would hate to see them go away. Think of all the projects out there that are using apache snapshots that would have to add the apache repo to their project. Not only is this a lot of traffic to apache, I think it also sets a bad precedent for other projects. Think of a project using a lot of snapshots and they have to add every small project's repo to the repo list (which may also add to the apache traffic as maven has no idea which repo may have the snapshot, so it tries them all in order) Anyway I'm rambling now I am curious about the issues this creates. Part of the problem was a bottleneck in getting new and updated Apache projects onto ibiblio. There also is a certain degree of snapshot clutter on ibiblio. Especially since ibiblio is only accessible to certain people, I think it makes sense for it only to contain releases, and to have the snapshots at Apache. The traffic issues could probably be handled by the mirrors, if it isn't already. I also don't see adding the Apache repo to a properties file as a big deal -- especially when compared with the chaotic and sluggish nature of the Apache-ibiblio situation, which seems to have been improved greatly with this new system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] new snapshot to ibiblio
Think of all the projects out there that are using apache snapshots that would have to add the apache repo to their project. Not only is this a lot of traffic to apache, I think it also sets a bad precedent for other projects. One question is whether or not we want people to be using snapshot builds on a regular basis. There is a case for saying that we want to encourage people to be using stable Release builds, and that if developers want to be using snapshot builds, they should have to consciously make that happen. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] new snapshot to ibiblio
I understand the desire to not having projects use snapshots, but the reality is you just sometimes need to build against head. The geronimo team tries to limit snapshots to projects that do instep releases with geronimo but that is still about 30 modules spread across 4 projects. Why use snapshots? If you want to track *current* status, you really want to turn that over to GUMP, which will pull source for every project you depend upon, and build Geronimo and all dependents from source. GUMP is the ASF's Continous Integration project, and will be adding (AIUI) testing, as well as the ability to freeze a given dependent to a released JAR. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
- Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, May 13, 2004 4:44 PM Subject: RE: [collections] new snapshot to ibiblio I understand the desire to not having projects use snapshots, but the reality is you just sometimes need to build against head. The geronimo team tries to limit snapshots to projects that do instep releases with geronimo but that is still about 30 modules spread across 4 projects. Why use snapshots? If you want to track *current* status, you really want to turn that over to GUMP, which will pull source for every project you depend upon, and build Geronimo and all dependents from source. GUMP is the ASF's Continous Integration project, and will be adding (AIUI) testing, as well as the ability to freeze a given dependent to a released JAR. Testing (via ant running junit tests) has been they for a long time. Build/Testing (via Maven) is pretty close, and we have a geronimo project in place (although it is still a work in progress): http://lsd.student.utwente.nl/gump/incubator-geronimo/incubator-geronimo/index.html Let us know what you need/want, and we'll see if we can help you: [EMAIL PROTECTED] regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
I have recently had to ask for a rogue collections snapshot to be changed to point at the 3.0 release. This had been creating a negative impression of collections. Consider this just my opinion, that it would be nice to have snapshots clearly separate from releases (two directories in the repository for example). In this particular case, I am happy for Mario to put a collections snapshot in the Apache repository, but hopefully collections 3.1 will be along soon anyway. Stephen From: Dain Sundstrom [EMAIL PROTECTED] On May 13, 2004, at 2:23 PM, Stephen Colebourne wrote: I am opposed to adding snapshots to ibiblio, as I have seen it create isues. IMHO ibiblio should be released/stable code only. Can you be more clear? I think ibiblio snapshots are great and would hate to see them go away. Think of all the projects out there that are using apache snapshots that would have to add the apache repo to their project. Not only is this a lot of traffic to apache, I think it also sets a bad precedent for other projects. Think of a project using a lot of snapshots and they have to add every small project's repo to the repo list (which may also add to the apache traffic as maven has no idea which repo may have the snapshot, so it tries them all in order) Anyway I'm rambling now I am curious about the issues this creates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
On May 13, 2004, at 5:44 PM, Noel J. Bergman wrote: I understand the desire to not having projects use snapshots, but the reality is you just sometimes need to build against head. The geronimo team tries to limit snapshots to projects that do instep releases with geronimo but that is still about 30 modules spread across 4 projects. Why use snapshots? If you want to track *current* status, you really want to turn that over to GUMP, which will pull source for every project you depend upon, and build Geronimo and all dependents from source. GUMP is the ASF's Continous Integration project, and will be adding (AIUI) testing, as well as the ability to freeze a given dependent to a released JAR. Again I understand the desire, but I think it is unreasonable to assume everyone will be using GUMP or more generally be using a continuous integration system. In the case of Geronimo, I personally build Geronimo, OpenEJB and TranQL on my machine, so I can do cross project refactoring. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
