Re: [all] simplifying releases: dist vs. maven repo
Am 15.12.2013 22:29, schrieb Phil Steitz: On 12/14/13, 12:01 PM, Oliver Heger wrote: Am 14.12.2013 05:20, schrieb Phil Steitz: On 12/13/13, 12:34 PM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz phil.ste...@gmail.com wrote: On 12/13/13, 11:34 AM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz phil.ste...@gmail.com wrote: On 12/12/13, 6:50 PM, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? The releases need to be mirrored. That's what dist is for. How is this not the same thing that happens with the Maven repo, which is mirrored all over as well? Please educate/correct me. See Mark's comments. We need to either say we are not directly providing artifacts to users (not acceptable, IMO), We are, for example: https://repository.apache.org/content/repositories/releases/ We should not be pointing users at that URL for download, because it is not a mirror reference (Mark or some infra@-knowledgeable person can correct me if I am wrong here). The mirrors exist in part to prevent ASF servers getting hammered by end-users trying to download artifacts. Pointing end-users to repo.a.o is pointing them directly at ASF infra, which is a no-no (because it does not take advantage of the load-distribution advantage of the mirroring system). As I said above, if we want to go this way, we will have to point them at maven central, which runs afoul of the requirement that Sebb references. or direct users to mirrors. Which could point to Maven Central and the like. The way dist and the various download cgis work is that users are directed to download the artifacts from mirrors near them, not directly from ASF servers. I guess we could in theory direct them to maven central, but that makes me a little twitchy as we don't really control or monitor the process of mirroring there. As noted above, we control https://repository.apache.org/content/repositories/releases/ Right, but we can't point end-users there, per comments above. Phil Gary So if we are going to distribute directly, we should continue to do it from dist. Mark also makes a good point about archives. https://repository.apache.org/content/repositories/releases/ behaves like an archive since it keeps old versions. Gary Phil Thank you, Gary Phil Thoughts? Moving artifacts from the dist/dev location to the release location was indeed one of the problematic actions when doing the last [beanutils] release - a whole bunch of commands had to be typed in, and for me it did not work in the way it was described. However, I think that this step could easily be scripted in some way. If there was an easy and automated method for dealing with dist, there would not be much point in searching for an alternative. You are talking about step 1 in [1], right? I am about to cut my first release in a while and I will see if I can verify / simplify this. Did this not work for you? What exactly failed? Looks like it should work to me, though I would probably do the mvs separately locally, then verify directory contents and then commit. Yes, the moves of the distribution artifacts. I followed the svnmucc approach and entered a command with the following structure svnmucc -U baseURL mv srcDir/srcFile dstDir/ ... as described on the page. This always failed with the error message dstDir already exists. I could only get it to work by changing the command structure to mv srcDir/srcFile dstDir/srcFile i.e. the file name had to be repeated. This was indeed strange, I also would have expected the original command to work. Nevertheless, it should not be a major problem to write a small script which generates exactly the correct command based on some file naming conventions. Oliver Phil [1] http://commons.apache.org/releases/release.html Oliver Gary - 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
Re: [all] simplifying releases: dist vs. maven repo
On 12/14/13, 12:01 PM, Oliver Heger wrote: Am 14.12.2013 05:20, schrieb Phil Steitz: On 12/13/13, 12:34 PM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz phil.ste...@gmail.com wrote: On 12/13/13, 11:34 AM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz phil.ste...@gmail.com wrote: On 12/12/13, 6:50 PM, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? The releases need to be mirrored. That's what dist is for. How is this not the same thing that happens with the Maven repo, which is mirrored all over as well? Please educate/correct me. See Mark's comments. We need to either say we are not directly providing artifacts to users (not acceptable, IMO), We are, for example: https://repository.apache.org/content/repositories/releases/ We should not be pointing users at that URL for download, because it is not a mirror reference (Mark or some infra@-knowledgeable person can correct me if I am wrong here). The mirrors exist in part to prevent ASF servers getting hammered by end-users trying to download artifacts. Pointing end-users to repo.a.o is pointing them directly at ASF infra, which is a no-no (because it does not take advantage of the load-distribution advantage of the mirroring system). As I said above, if we want to go this way, we will have to point them at maven central, which runs afoul of the requirement that Sebb references. or direct users to mirrors. Which could point to Maven Central and the like. The way dist and the various download cgis work is that users are directed to download the artifacts from mirrors near them, not directly from ASF servers. I guess we could in theory direct them to maven central, but that makes me a little twitchy as we don't really control or monitor the process of mirroring there. As noted above, we control https://repository.apache.org/content/repositories/releases/ Right, but we can't point end-users there, per comments above. Phil Gary So if we are going to distribute directly, we should continue to do it from dist. Mark also makes a good point about archives. https://repository.apache.org/content/repositories/releases/ behaves like an archive since it keeps old versions. Gary Phil Thank you, Gary Phil Thoughts? Moving artifacts from the dist/dev location to the release location was indeed one of the problematic actions when doing the last [beanutils] release - a whole bunch of commands had to be typed in, and for me it did not work in the way it was described. However, I think that this step could easily be scripted in some way. If there was an easy and automated method for dealing with dist, there would not be much point in searching for an alternative. You are talking about step 1 in [1], right? I am about to cut my first release in a while and I will see if I can verify / simplify this. Did this not work for you? What exactly failed? Looks like it should work to me, though I would probably do the mvs separately locally, then verify directory contents and then commit. Phil [1] http://commons.apache.org/releases/release.html Oliver Gary - 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 - 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
Re: [all] simplifying releases: dist vs. maven repo
Am 14.12.2013 05:20, schrieb Phil Steitz: On 12/13/13, 12:34 PM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz phil.ste...@gmail.com wrote: On 12/13/13, 11:34 AM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz phil.ste...@gmail.com wrote: On 12/12/13, 6:50 PM, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? The releases need to be mirrored. That's what dist is for. How is this not the same thing that happens with the Maven repo, which is mirrored all over as well? Please educate/correct me. See Mark's comments. We need to either say we are not directly providing artifacts to users (not acceptable, IMO), We are, for example: https://repository.apache.org/content/repositories/releases/ We should not be pointing users at that URL for download, because it is not a mirror reference (Mark or some infra@-knowledgeable person can correct me if I am wrong here). The mirrors exist in part to prevent ASF servers getting hammered by end-users trying to download artifacts. Pointing end-users to repo.a.o is pointing them directly at ASF infra, which is a no-no (because it does not take advantage of the load-distribution advantage of the mirroring system). As I said above, if we want to go this way, we will have to point them at maven central, which runs afoul of the requirement that Sebb references. or direct users to mirrors. Which could point to Maven Central and the like. The way dist and the various download cgis work is that users are directed to download the artifacts from mirrors near them, not directly from ASF servers. I guess we could in theory direct them to maven central, but that makes me a little twitchy as we don't really control or monitor the process of mirroring there. As noted above, we control https://repository.apache.org/content/repositories/releases/ Right, but we can't point end-users there, per comments above. Phil Gary So if we are going to distribute directly, we should continue to do it from dist. Mark also makes a good point about archives. https://repository.apache.org/content/repositories/releases/ behaves like an archive since it keeps old versions. Gary Phil Thank you, Gary Phil Thoughts? Moving artifacts from the dist/dev location to the release location was indeed one of the problematic actions when doing the last [beanutils] release - a whole bunch of commands had to be typed in, and for me it did not work in the way it was described. However, I think that this step could easily be scripted in some way. If there was an easy and automated method for dealing with dist, there would not be much point in searching for an alternative. Oliver Gary - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Am 13.12.2013, 07:29 Uhr, schrieb Emmanuel Bourg ebo...@apache.org: I don't think the -src and -bin files should be in Maven, that's not its purpose. I find it very usefull when the IDE will automatically download javadocs and sources for a given dependency so I can browse into. For this to work -src and -javadoc have to be in the repo. Gruss Bernd -- http://www.zusammenkunft.net - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Le 13/12/2013 10:58, Bernd Eckenfels a écrit : I find it very usefull when the IDE will automatically download javadocs and sources for a given dependency so I can browse into. For this to work -src and -javadoc have to be in the repo. I agree, but that's the -sources artifact, not the -src one. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
On 13/12/2013 02:50, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. It does seem to be an abuse of what the Maven repo is meant to be for but lots of projects do it. When Tomcat had an explicit request for this (and the .exe installer as well) I took a look at what was in the Maven repo. Quite a few projects have been doing this for a while. My conclusion was that given that: a) Maven central don't object to it b) it is easy to do c) (some of) our users want it then we should do it. The fact that folks are using something in a way that wasn't originally intended is - to me - far less important. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? We do need to keep the files on dist for so: a) the mirrors can pick them up b) they get automatically copied to archive.a.o Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz phil.ste...@gmail.com wrote: On 12/12/13, 6:50 PM, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? The releases need to be mirrored. That's what dist is for. How is this not the same thing that happens with the Maven repo, which is mirrored all over as well? Please educate/correct me. Thank you, Gary Phil Thoughts? Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [all] simplifying releases: dist vs. maven repo
On 12/13/13, 11:34 AM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz phil.ste...@gmail.com wrote: On 12/12/13, 6:50 PM, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? The releases need to be mirrored. That's what dist is for. How is this not the same thing that happens with the Maven repo, which is mirrored all over as well? Please educate/correct me. See Mark's comments. We need to either say we are not directly providing artifacts to users (not acceptable, IMO), or direct users to mirrors. The way dist and the various download cgis work is that users are directed to download the artifacts from mirrors near them, not directly from ASF servers. I guess we could in theory direct them to maven central, but that makes me a little twitchy as we don't really control or monitor the process of mirroring there. So if we are going to distribute directly, we should continue to do it from dist. Mark also makes a good point about archives. Phil Thank you, Gary Phil Thoughts? Gary - 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
Re: [all] simplifying releases: dist vs. maven repo
On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz phil.ste...@gmail.com wrote: On 12/13/13, 11:34 AM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz phil.ste...@gmail.com wrote: On 12/12/13, 6:50 PM, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? The releases need to be mirrored. That's what dist is for. How is this not the same thing that happens with the Maven repo, which is mirrored all over as well? Please educate/correct me. See Mark's comments. We need to either say we are not directly providing artifacts to users (not acceptable, IMO), We are, for example: https://repository.apache.org/content/repositories/releases/ or direct users to mirrors. Which could point to Maven Central and the like. The way dist and the various download cgis work is that users are directed to download the artifacts from mirrors near them, not directly from ASF servers. I guess we could in theory direct them to maven central, but that makes me a little twitchy as we don't really control or monitor the process of mirroring there. As noted above, we control https://repository.apache.org/content/repositories/releases/ Gary So if we are going to distribute directly, we should continue to do it from dist. Mark also makes a good point about archives. https://repository.apache.org/content/repositories/releases/ behaves like an archive since it keeps old versions. Gary Phil Thank you, Gary Phil Thoughts? Gary - 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 -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [all] simplifying releases: dist vs. maven repo
On 13 December 2013 20:34, Gary Gregory garydgreg...@gmail.com wrote: On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz phil.ste...@gmail.com wrote: On 12/13/13, 11:34 AM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz phil.ste...@gmail.com wrote: On 12/12/13, 6:50 PM, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? The releases need to be mirrored. That's what dist is for. How is this not the same thing that happens with the Maven repo, which is mirrored all over as well? Please educate/correct me. See Mark's comments. We need to either say we are not directly providing artifacts to users (not acceptable, IMO), We are, for example: https://repository.apache.org/content/repositories/releases/ or direct users to mirrors. Which could point to Maven Central and the like. The way dist and the various download cgis work is that users are directed to download the artifacts from mirrors near them, not directly from ASF servers. I guess we could in theory direct them to maven central, but that makes me a little twitchy as we don't really control or monitor the process of mirroring there. As noted above, we control https://repository.apache.org/content/repositories/releases/ Control is *not* the issue here. The ASF releases source, which MUST be made available via the ASF mirror system [1] If you want to change that requirement, AIUI you will have to get agreement from the board. [1] http://www.apache.org/dev/release.html#host-GA Gary So if we are going to distribute directly, we should continue to do it from dist. Mark also makes a good point about archives. https://repository.apache.org/content/repositories/releases/ behaves like an archive since it keeps old versions. Gary Phil Thank you, Gary Phil Thoughts? Gary - 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 -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
On 12/13/13, 12:34 PM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 3:29 PM, Phil Steitz phil.ste...@gmail.com wrote: On 12/13/13, 11:34 AM, Gary Gregory wrote: On Fri, Dec 13, 2013 at 12:57 AM, Phil Steitz phil.ste...@gmail.com wrote: On 12/12/13, 6:50 PM, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? The releases need to be mirrored. That's what dist is for. How is this not the same thing that happens with the Maven repo, which is mirrored all over as well? Please educate/correct me. See Mark's comments. We need to either say we are not directly providing artifacts to users (not acceptable, IMO), We are, for example: https://repository.apache.org/content/repositories/releases/ We should not be pointing users at that URL for download, because it is not a mirror reference (Mark or some infra@-knowledgeable person can correct me if I am wrong here). The mirrors exist in part to prevent ASF servers getting hammered by end-users trying to download artifacts. Pointing end-users to repo.a.o is pointing them directly at ASF infra, which is a no-no (because it does not take advantage of the load-distribution advantage of the mirroring system). As I said above, if we want to go this way, we will have to point them at maven central, which runs afoul of the requirement that Sebb references. or direct users to mirrors. Which could point to Maven Central and the like. The way dist and the various download cgis work is that users are directed to download the artifacts from mirrors near them, not directly from ASF servers. I guess we could in theory direct them to maven central, but that makes me a little twitchy as we don't really control or monitor the process of mirroring there. As noted above, we control https://repository.apache.org/content/repositories/releases/ Right, but we can't point end-users there, per comments above. Phil Gary So if we are going to distribute directly, we should continue to do it from dist. Mark also makes a good point about archives. https://repository.apache.org/content/repositories/releases/ behaves like an archive since it keeps old versions. Gary Phil Thank you, Gary Phil Thoughts? Gary - 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
[all] simplifying releases: dist vs. maven repo
Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? Thoughts? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [all] simplifying releases: dist vs. maven repo
On 12/12/13, 6:50 PM, Gary Gregory wrote: Hi All: We talk on and off as to how painful it is to release components. One of these pains is that we distribute to multiple places: An Apache dist folder and the Apache Maven repository. Clearly, Maven is here to stay. So why not deploy the -src and -bin files to Maven and forget about dist. A URL is a URL, what do users care is the URL points deep into dist or our Maven repo. I for one, need the -bin zips for certain Apache projects (JMeter, ActiveMQ) so my Ant Ivy builds can download and install them. I know we have some legal requirements to host at least the sources and that we provide binaries as a courtesy but does it matter _where_ the files are on Apache servers? The releases need to be mirrored. That's what dist is for. Phil Thoughts? Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] simplifying releases: dist vs. maven repo
Le 13/12/2013 03:50, Gary Gregory a écrit : Thoughts? I don't think the -src and -bin files should be in Maven, that's not its purpose. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
