On 8/1/11 12:21 PM, Dennis Lundberg wrote: > On 2011-08-01 20:19, Phil Steitz wrote: >> On 8/1/11 10:16 AM, Ralph Goers wrote: >>> On Aug 1, 2011, at 10:03 AM, Luc Maisonobe wrote: >>> >>>> Le 01/08/2011 18:41, Phil Steitz a écrit : >>>>> On 8/1/11 9:25 AM, Emmanuel Bourg wrote: >>>>>> Le 01/08/2011 17:57, Ralph Goers a écrit : >>>>>>> These will just be new SNAPSHOTs so deploying a new one every >>>>>>> evening regardless of whether it has changed should be no big >>>>>>> deal. SNAPSHOTs without a timestamp overwrite a previous one >>>>>>> while timestamped SNAPSHOTs should be cleaned up automatically by >>>>>>> Nexus. >>>>>> What's the preferred strategy? Timestamped snapshots or not? >>>>> I think its better to have a timestamp and to create full nightlies >>>>> - not just snapshot jars, but full timestamted source and binary >>>>> tarballs as we used to. FWIW, I think it is better not to push >>>>> snaps into maven repos, but rather to place tarballs in a location >>>>> where the sources and jars can be downloaded and unpacked. This is >>>>> to emphasize that the reason we are providing them is for developers >>>>> to look at the sources and test with the jars, rather than to >>>>> encourage "snapshot dependencies." If the machine account problem >>>>> has been solved from vmbuild to p.a.o, this should be pretty easy to >>>>> automate. I may have old scripts around somewhere that worked >>>>> modulo this problem. >>>> I am really on the fence with nightly builds. >>>> I fear people will start to use them as official Apache blessed releases. >>>> They are not releases, they will change every day (or every night). We >>>> should have prominent warnings that they represent instant state and >>>> *cannot* be relied upon. >>>> >>>> IMHO, when people are brave enough to test development version, they >>>> should compile them by themselves. It is a way to filter out users that >>>> would not even care fixing an obvious typo that make a test fail. With >>>> nightly builds, we may end up answering many requests for more stability >>>> even in the nightly versions. >>>> >>>> For what purpose do we need nightly builds ? Who are the people who need >>>> nightly builds and cannot build them by themselves ? >>> This is exactly why I am OK with SNAPSHOTs in a snapshot repository and >>> nothing more. This makes it convenient for users to test the latest code >>> without requiring that they build it but since it isn't tagged most people >>> who use Maven understand it shouldn't be relied on. >> I agree with Luc that we need to be careful with this. I also think >> that the world does not revolve around maven. Therefore, I think it >> is a better compromise to publish nightlies in a location that is >> clearly labelled and forces users to a) download and b) install the >> jar or build the sources. This is also a more friendly solution for >> people who do not use maven. It worked for us for years until we >> hit the machine auth problem around the same time the ASF got >> collectively squeamish about nightlies for the reasons that Luc >> gives above. I think with clear labeling we can safely do this. >> Ant [1] handles this fairly well. Unfortunately, I don't think you >> can link directly to the Continuum-generated artifacts as Jenkins >> seems to be able to do. > Phil, I have to respectfully disagree here. > > What you are saying, and I'm paraphrasing here, is that we need to make > it as difficult as possible for our users to get hold of and use the > latest non-stable version of commons components.
No, just that they need to know what they are doing - i.e., have it very clear that they are downloading unreleased artifacts. Also the source for whatever they are downloading needs to be immediately available. Phil > We should be making it > as easy as possible for our users to test our latest non-stable > versions, without the user thinking that it is a release. > > Putting SNAPSHOT versions of our JARs into a Maven repository doesn't > mean that only Maven can consume them. It's called a Maven repository > because the repository layout was "invented" by the Maven project. That > layout has since been adopted by a whole boatload of other build tools. > There's Ivy and Maven Ant Tasks that users of Ant can use to consume > artifacts from a Maven repository. Gradle supports Maven repositories, > just to name a few. > > The SNAPSHOT repository that we have at the ASF is a separate repository > from the releases repository. You can't just add > commons-foo:1.1-SNAPSHOT to a build and expect it to be downloaded. You > as the builder need to actively add the ASF SNAPSHOT repository to be > able to consume our SNAPSHOT artifacts. > > The generated artifacts shouldn't be published in Continuum or Jenkins, > those are just services that build the artifacts. When they are built > they need to be deployed to a repository, from where they can then be > consumed. For this we have a Nexus instance at the ASF. > > Adding this deploy-to-repository step is as easy as checking a check > box and giving the URL of the repository, in Jenkins. I imagine that > it's equally trivial in Continuum. > > If you need help setting up stuff in Jenkins I can help out. > >> Phil >>> Ralph >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
