[xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
Hi, I'd like to change the <repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work. WDYT? Caleb
Hi Caleb, On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the <repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage. Thanks -Vincent
Hi, On May 14, 2012, at 8:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the <repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
There's one reason we might not want to use mvn release:stage though: safety. It means RM could run mvn release:perform by error instead of mvn release:stage and I don't think maven will refuse to run mvn release:perform even when there's a staging repo defined… (strange design BTW). Thus I'm changing to +1 to replace the target repo by the staging one to reduce likelihood of mistakes. Thanks -Vincent PS: Also +1 to upgrade to Release plugin 2.3: http://jira.xwiki.org/jira/browse/XCOMMONS-168 ;)
On Mon, May 14, 2012 at 10:29 AM, Vincent Massol <[email protected]> wrote:
Hi,
On May 14, 2012, at 8:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the <repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
There's one reason we might not want to use mvn release:stage though: safety. It means RM could run mvn release:perform by error instead of mvn release:stage and I don't think maven will refuse to run mvn release:perform even when there's a staging repo defined… (strange design BTW).
It shouldn't be a problem if the release script uses release:stage .
Thus I'm changing to +1 to replace the target repo by the staging one to reduce likelihood of mistakes.
-0. The commons root POM is inherited by projects that are released independently, e.g. from contrib, and I don't think they should be forced to go through staging. I'm fine with staging but I think it should be put in the release script, not in the POM. Thanks, Marius
Thanks -Vincent
PS: Also +1 to upgrade to Release plugin 2.3: http://jira.xwiki.org/jira/browse/XCOMMONS-168 ;)
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
On Mon, May 14, 2012 at 10:29 AM, Vincent Massol <[email protected]> wrote:
Hi,
On May 14, 2012, at 8:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the <repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
There's one reason we might not want to use mvn release:stage though: safety. It means RM could run mvn release:perform by error instead of mvn release:stage and I don't think maven will refuse to run mvn release:perform even when there's a staging repo defined… (strange design BTW).
It shouldn't be a problem if the release script uses release:stage .
Thus I'm changing to +1 to replace the target repo by the staging one to reduce likelihood of mistakes.
-0. The commons root POM is inherited by projects that are released independently, e.g. from contrib, and I don't think they should be forced to go through staging. I'm fine with staging but I think it should be put in the release script, not in the POM.
-0 to put that in the release script :) This POM is NOT made to be inherited by projects other than the XWiki Dev Team projects. What we could do is create a pom that can be inherited by contrib projects but this is really a different issue than the one at hand since even right now it's not ok for contrib projects. Thanks -Vincent
Thanks, Marius
Thanks -Vincent
PS: Also +1 to upgrade to Release plugin 2.3: http://jira.xwiki.org/jira/browse/XCOMMONS-168 ;)
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On May 14, 2012, at 10:26 AM, Vincent Massol wrote:
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
On Mon, May 14, 2012 at 10:29 AM, Vincent Massol <[email protected]> wrote:
Hi,
On May 14, 2012, at 8:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the <repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
There's one reason we might not want to use mvn release:stage though: safety. It means RM could run mvn release:perform by error instead of mvn release:stage and I don't think maven will refuse to run mvn release:perform even when there's a staging repo defined… (strange design BTW).
It shouldn't be a problem if the release script uses release:stage .
Thus I'm changing to +1 to replace the target repo by the staging one to reduce likelihood of mistakes.
-0. The commons root POM is inherited by projects that are released independently, e.g. from contrib, and I don't think they should be forced to go through staging. I'm fine with staging but I think it should be put in the release script, not in the POM.
-0 to put that in the release script :)
The reason is that this release script shouldn't even exist and we need to keep it minimal and use the Maven standard best practices. This script has nothing standard. Thanks -Vincent
This POM is NOT made to be inherited by projects other than the XWiki Dev Team projects.
What we could do is create a pom that can be inherited by contrib projects but this is really a different issue than the one at hand since even right now it's not ok for contrib projects. Thanks -Vincent
Thanks, Marius
Thanks -Vincent
PS: Also +1 to upgrade to Release plugin 2.3: http://jira.xwiki.org/jira/browse/XCOMMONS-168 ;)
On 05/14/2012 04:27 AM, Vincent Massol wrote:
On May 14, 2012, at 10:26 AM, Vincent Massol wrote:
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
On Mon, May 14, 2012 at 10:29 AM, Vincent Massol<[email protected]> wrote:
Hi,
On May 14, 2012, at 8:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
There's one reason we might not want to use mvn release:stage though: safety. It means RM could run mvn release:perform by error instead of mvn release:stage and I don't think maven will refuse to run mvn release:perform even when there's a staging repo defined… (strange design BTW).
It shouldn't be a problem if the release script uses release:stage .
Thus I'm changing to +1 to replace the target repo by the staging one to reduce likelihood of mistakes.
-0. The commons root POM is inherited by projects that are released independently, e.g. from contrib, and I don't think they should be forced to go through staging. I'm fine with staging but I think it should be put in the release script, not in the POM.
-0 to put that in the release script :)
The reason is that this release script shouldn't even exist and we need to keep it minimal and use the Maven standard best practices. This script has nothing standard.
What do you mean by that? The script calls maven intensively, so it is almost as standard as maven is.
Thanks -Vincent
This POM is NOT made to be inherited by projects other than the XWiki Dev Team projects.
What we could do is create a pom that can be inherited by contrib projects but this is really a different issue than the one at hand since even right now it's not ok for contrib projects. Thanks -Vincent
Thanks, Marius
Thanks -Vincent
PS: Also +1 to upgrade to Release plugin 2.3: http://jira.xwiki.org/jira/browse/XCOMMONS-168 ;)
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On May 14, 2012, at 4:58 PM, Sergiu Dumitriu wrote:
On 05/14/2012 04:27 AM, Vincent Massol wrote:
On May 14, 2012, at 10:26 AM, Vincent Massol wrote:
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
On Mon, May 14, 2012 at 10:29 AM, Vincent Massol<[email protected]> wrote:
Hi,
On May 14, 2012, at 8:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
> Hi, > > I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. > Agent1 already has an account in the staging repository from my last release so this should just work. > > WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
There's one reason we might not want to use mvn release:stage though: safety. It means RM could run mvn release:perform by error instead of mvn release:stage and I don't think maven will refuse to run mvn release:perform even when there's a staging repo defined… (strange design BTW).
It shouldn't be a problem if the release script uses release:stage .
Thus I'm changing to +1 to replace the target repo by the staging one to reduce likelihood of mistakes.
-0. The commons root POM is inherited by projects that are released independently, e.g. from contrib, and I don't think they should be forced to go through staging. I'm fine with staging but I think it should be put in the release script, not in the POM.
-0 to put that in the release script :)
The reason is that this release script shouldn't even exist and we need to keep it minimal and use the Maven standard best practices. This script has nothing standard.
What do you mean by that? The script calls maven intensively, so it is almost as standard as maven is.
Maven is a standard. This script isn't and is only there to add stuff that Maven cannot or will not do. So all I'm saying is that we must put the maximum of stuff in our Maven setup and the minimum in this script. And if Maven improves in the future and adds stuff that are done by our custom script we should move those outside of the script in our Maven setup. More precisely here, Maven supports defining release repositories and we should use that. It's a standard, documented feature. Thanks -Vincent
Thanks -Vincent
This POM is NOT made to be inherited by projects other than the XWiki Dev Team projects.
What we could do is create a pom that can be inherited by contrib projects but this is really a different issue than the one at hand since even right now it's not ok for contrib projects. Thanks -Vincent
Thanks, Marius
Thanks -Vincent
PS: Also +1 to upgrade to Release plugin 2.3: http://jira.xwiki.org/jira/browse/XCOMMONS-168 ;)
On 05/14/2012 11:12 AM, Vincent Massol wrote:
On May 14, 2012, at 4:58 PM, Sergiu Dumitriu wrote:
On 05/14/2012 04:27 AM, Vincent Massol wrote:
On May 14, 2012, at 10:26 AM, Vincent Massol wrote:
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
On Mon, May 14, 2012 at 10:29 AM, Vincent Massol<[email protected]> wrote:
Hi,
On May 14, 2012, at 8:56 AM, Vincent Massol wrote:
> Hi Caleb, > > On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote: > >> Hi, >> >> I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. >> Agent1 already has an account in the staging repository from my last release so this should just work. >> >> WDYT? > > +1 for using staging but not to change the target repo. We need to be able to go from staging to target. > The canonical way is to use mvn release:stage.
There's one reason we might not want to use mvn release:stage though: safety. It means RM could run mvn release:perform by error instead of mvn release:stage and I don't think maven will refuse to run mvn release:perform even when there's a staging repo defined… (strange design BTW).
It shouldn't be a problem if the release script uses release:stage .
Thus I'm changing to +1 to replace the target repo by the staging one to reduce likelihood of mistakes.
-0. The commons root POM is inherited by projects that are released independently, e.g. from contrib, and I don't think they should be forced to go through staging. I'm fine with staging but I think it should be put in the release script, not in the POM.
-0 to put that in the release script :)
The reason is that this release script shouldn't even exist and we need to keep it minimal and use the Maven standard best practices. This script has nothing standard.
What do you mean by that? The script calls maven intensively, so it is almost as standard as maven is.
Maven is a standard. This script isn't and is only there to add stuff that Maven cannot or will not do.
So all I'm saying is that we must put the maximum of stuff in our Maven setup and the minimum in this script.
And if Maven improves in the future and adds stuff that are done by our custom script we should move those outside of the script in our Maven setup.
More precisely here, Maven supports defining release repositories and we should use that. It's a standard, documented feature.
OK, I see, you meant "standard" as in "standard for other projects as well", not as in "doing dodgy stuff and undocumented tricks that might break at any moment". I agree that we should use maven as much as possible, and I tried to do that. There are a few things that aren't yet possible, and for which I had to rely on external tools like sed, xsltproc, grep...
Thanks -Vincent
Thanks -Vincent
This POM is NOT made to be inherited by projects other than the XWiki Dev Team projects.
What we could do is create a pom that can be inherited by contrib projects but this is really a different issue than the one at hand since even right now it's not ok for contrib projects. Thanks -Vincent
Thanks, Marius
Thanks -Vincent
PS: Also +1 to upgrade to Release plugin 2.3: http://jira.xwiki.org/jira/browse/XCOMMONS-168 ;)
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the <repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury. My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is. Caleb
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
Well, re-releasing will take care of the "bad" artifacts, since as long as they have the same version, uploading will override the older ones with the new ones. The only risk is people downloading the bad artifacts between release attempts. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On May 14, 2012, at 5:00 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
Well, re-releasing will take care of the "bad" artifacts, since as long as they have the same version, uploading will override the older ones with the new ones. The only risk is people downloading the bad artifacts between release attempts.
This is not fully correct. In the meantime any number of users could have use that remote repo and have the artifacts locally. Then they may report errors in our jira saying they're using that version of XE and we wouldn't be able to understand nor reproduce the issue for example. It's very bad andit should not be allowed (except under very special circumstances) to re-release in a remote repository. It's completely forbidden for ex in the Maven Central repo. So a big -1 to re-release in our remote repo as a rule. Which is why I agree with Caleb about staging. Thanks -Vincent
On 05/14/2012 11:17 AM, Vincent Massol wrote:
On May 14, 2012, at 5:00 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
Well, re-releasing will take care of the "bad" artifacts, since as long as they have the same version, uploading will override the older ones with the new ones. The only risk is people downloading the bad artifacts between release attempts.
This is not fully correct. In the meantime any number of users could have use that remote repo and have the artifacts locally. Then they may report errors in our jira saying they're using that version of XE and we wouldn't be able to understand nor reproduce the issue for example.
It's very bad andit should not be allowed (except under very special circumstances) to re-release in a remote repository. It's completely forbidden for ex in the Maven Central repo.
So a big -1 to re-release in our remote repo as a rule. Which is why I agree with Caleb about staging.
I agree. To be clear, I wasn't proposing to skip staging, I was just arguing that it's not very hard to clean up a bad release. Still, a public staging repo can have the same effect: much too eager people could just download from the staging repo instead of the release repo. It's the user's decision to download an unannounced release. Our official downloads are from OW2, the maven repositories are supposed to be used only by developers. That's not true in general, though, and a good counter-example is the maven central repo which for some projects is the only download location, and which some users (and tools) check directly for new versions instead of checking the project's website. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On May 14, 2012, at 5:35 PM, Sergiu Dumitriu wrote:
On 05/14/2012 11:17 AM, Vincent Massol wrote:
On May 14, 2012, at 5:00 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
Well, re-releasing will take care of the "bad" artifacts, since as long as they have the same version, uploading will override the older ones with the new ones. The only risk is people downloading the bad artifacts between release attempts.
This is not fully correct. In the meantime any number of users could have use that remote repo and have the artifacts locally. Then they may report errors in our jira saying they're using that version of XE and we wouldn't be able to understand nor reproduce the issue for example.
It's very bad andit should not be allowed (except under very special circumstances) to re-release in a remote repository. It's completely forbidden for ex in the Maven Central repo.
So a big -1 to re-release in our remote repo as a rule. Which is why I agree with Caleb about staging.
I agree. To be clear, I wasn't proposing to skip staging, I was just arguing that it's not very hard to clean up a bad release.
Still, a public staging repo can have the same effect: much too eager people could just download from the staging repo instead of the release repo. It's the user's decision to download an unannounced release. Our official downloads are from OW2, the maven repositories are supposed to be used only by developers. That's not true in general, though, and a good counter-example is the maven central repo which for some projects is the only download location, and which some users (and tools) check directly for new versions instead of checking the project's website.
It's not true for extensions too. And that's going to be pretty heavily used with the EM usage growing up. Thanks -Vincent
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
I think that the POMs shouldn't know about staging repositories, since those aren't supposed to be "public". Personally I'd go for changing the release script so that it uses release:stage -DstagingRepository=http://nexus.xwiki.org... Plus, the POM doesn't have support for specifying staging repositories, just releases and snapshots, and it would be wrong to change the pom so that the "releases" repository, which most of the time is supposed to be used as a read-only location from which dependencies can be downloaded, would point to an upload-only URL that will fail when trying to download dependencies from it. The <repository> element is "a place to collect and store artifacts". -- Sergiu Dumitriu http://purl.org/net/sergiu/
On May 14, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
I think that the POMs shouldn't know about staging repositories, since those aren't supposed to be "public". Personally I'd go for changing the release script so that it uses release:stage -DstagingRepository=http://nexus.xwiki.org...
Plus, the POM doesn't have support for specifying staging repositories
It has. It's a parameter called "stagingRepository" (see http://maven.apache.org/plugins/maven-release-plugin/usage.html).
, just releases and snapshots, and it would be wrong to change the pom so that the "releases" repository, which most of the time is supposed to be used as a read-only location from which dependencies can be downloaded, would point to an upload-only URL that will fail when trying to download dependencies from it. The <repository> element is "a place to collect and store artifacts".
Yes that's true, good point: External tools could read that info from our released pom.xml and it should point to the final location, I agree… Thanks -Vincent
On 05/14/2012 12:07 PM, Vincent Massol wrote:
On May 14, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
I think that the POMs shouldn't know about staging repositories, since those aren't supposed to be "public". Personally I'd go for changing the release script so that it uses release:stage -DstagingRepository=http://nexus.xwiki.org...
Plus, the POM doesn't have support for specifying staging repositories
It has. It's a parameter called "stagingRepository" (see http://maven.apache.org/plugins/maven-release-plugin/usage.html).
I meant inside the <repositories> element, as a kind of repository besides "releases" and "snapshots". The "stagingRepository" is a parameter used only by the release:stage goal. Caleb was proposing to change the URL of the repositories as they are configured in the POM.
, just releases and snapshots, and it would be wrong to change the pom so that the "releases" repository, which most of the time is supposed to be used as a read-only location from which dependencies can be downloaded, would point to an upload-only URL that will fail when trying to download dependencies from it. The<repository> element is "a place to collect and store artifacts".
Yes that's true, good point: External tools could read that info from our released pom.xml and it should point to the final location, I agree…
I think the root pom is broken now, since the releases repository is supposed to be readable, while the current repository URL (http://nexus.xwiki.org/nexus/service/local/staging/deploy/maven2/) requires authentication, and even when logged in it will display an error when trying to read it. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On 05/14/2012 12:41 PM, Sergiu Dumitriu wrote:
On 05/14/2012 12:07 PM, Vincent Massol wrote:
On May 14, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
Hi,
I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. Agent1 already has an account in the staging repository from my last release so this should just work.
WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
I think that the POMs shouldn't know about staging repositories, since those aren't supposed to be "public". Personally I'd go for changing the release script so that it uses release:stage -DstagingRepository=http://nexus.xwiki.org...
Plus, the POM doesn't have support for specifying staging repositories
It has. It's a parameter called "stagingRepository" (see http://maven.apache.org/plugins/maven-release-plugin/usage.html).
I meant inside the <repositories> element, as a kind of repository besides "releases" and "snapshots". The "stagingRepository" is a parameter used only by the release:stage goal. Caleb was proposing to change the URL of the repositories as they are configured in the POM.
, just releases and snapshots, and it would be wrong to change the pom so that the "releases" repository, which most of the time is supposed to be used as a read-only location from which dependencies can be downloaded, would point to an upload-only URL that will fail when trying to download dependencies from it. The<repository> element is "a place to collect and store artifacts".
Yes that's true, good point: External tools could read that info from our released pom.xml and it should point to the final location, I agree…
I think the root pom is broken now, since the releases repository is supposed to be readable, while the current repository URL (http://nexus.xwiki.org/nexus/service/local/staging/deploy/maven2/) requires authentication, and even when logged in it will display an error when trying to read it.
How about making it http rather than scp so that it is read only? I just want to make sure maven will fail rather than trash a live repo, even if it is easy to fix. Caleb
On May 14, 2012, at 8:26 PM, Caleb James DeLisle wrote:
On 05/14/2012 12:41 PM, Sergiu Dumitriu wrote:
On 05/14/2012 12:07 PM, Vincent Massol wrote:
On May 14, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
> Hi, > > I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. > Agent1 already has an account in the staging repository from my last release so this should just work. > > WDYT?
+1 for using staging but not to change the target repo. We need to be able to go from staging to target. The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
I think that the POMs shouldn't know about staging repositories, since those aren't supposed to be "public". Personally I'd go for changing the release script so that it uses release:stage -DstagingRepository=http://nexus.xwiki.org...
Plus, the POM doesn't have support for specifying staging repositories
It has. It's a parameter called "stagingRepository" (see http://maven.apache.org/plugins/maven-release-plugin/usage.html).
I meant inside the <repositories> element, as a kind of repository besides "releases" and "snapshots". The "stagingRepository" is a parameter used only by the release:stage goal. Caleb was proposing to change the URL of the repositories as they are configured in the POM.
, just releases and snapshots, and it would be wrong to change the pom so that the "releases" repository, which most of the time is supposed to be used as a read-only location from which dependencies can be downloaded, would point to an upload-only URL that will fail when trying to download dependencies from it. The<repository> element is "a place to collect and store artifacts".
Yes that's true, good point: External tools could read that info from our released pom.xml and it should point to the final location, I agree…
I think the root pom is broken now, since the releases repository is supposed to be readable, while the current repository URL (http://nexus.xwiki.org/nexus/service/local/staging/deploy/maven2/) requires authentication, and even when logged in it will display an error when trying to read it.
How about making it http rather than scp so that it is read only? I just want to make sure maven will fail rather than trash a live repo, even if it is easy to fix.
Sergiu is right, see my previous reply. We need the pom to represent real data since external tools can read it. Thanks -Vincent
On 05/14/2012 06:42 PM, Vincent Massol wrote:
On May 14, 2012, at 8:26 PM, Caleb James DeLisle wrote:
On 05/14/2012 12:41 PM, Sergiu Dumitriu wrote:
On 05/14/2012 12:07 PM, Vincent Massol wrote:
On May 14, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote: > Hi Caleb, > > On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote: > >> Hi, >> >> I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. >> Agent1 already has an account in the staging repository from my last release so this should just work. >> >> WDYT? > > +1 for using staging but not to change the target repo. We need to be able to go from staging to target. > The canonical way is to use mvn release:stage.
I don't know if it's as much canonical as it is the way that maven offers. Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. I think maven's release:stage was designed with the assumption that most people don't have this luxury.
My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is.
Caleb
I think that the POMs shouldn't know about staging repositories, since those aren't supposed to be "public". Personally I'd go for changing the release script so that it uses release:stage -DstagingRepository=http://nexus.xwiki.org...
Plus, the POM doesn't have support for specifying staging repositories
It has. It's a parameter called "stagingRepository" (see http://maven.apache.org/plugins/maven-release-plugin/usage.html).
I meant inside the <repositories> element, as a kind of repository besides "releases" and "snapshots". The "stagingRepository" is a parameter used only by the release:stage goal. Caleb was proposing to change the URL of the repositories as they are configured in the POM.
, just releases and snapshots, and it would be wrong to change the pom so that the "releases" repository, which most of the time is supposed to be used as a read-only location from which dependencies can be downloaded, would point to an upload-only URL that will fail when trying to download dependencies from it. The<repository> element is "a place to collect and store artifacts".
Yes that's true, good point: External tools could read that info from our released pom.xml and it should point to the final location, I agree…
I think the root pom is broken now, since the releases repository is supposed to be readable, while the current repository URL (http://nexus.xwiki.org/nexus/service/local/staging/deploy/maven2/) requires authentication, and even when logged in it will display an error when trying to read it.
How about making it http rather than scp so that it is read only? I just want to make sure maven will fail rather than trash a live repo, even if it is easy to fix.
Sergiu is right, see my previous reply. We need the pom to represent real data since external tools can read it.
Thanks -Vincent
Reverted the commit. The question now is must the release be dropped since it was released with settings which we do not agree upon? Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 05/14/2012 09:52 PM, Caleb James DeLisle wrote:
On 05/14/2012 06:42 PM, Vincent Massol wrote:
On May 14, 2012, at 8:26 PM, Caleb James DeLisle wrote:
On 05/14/2012 12:41 PM, Sergiu Dumitriu wrote:
On 05/14/2012 12:07 PM, Vincent Massol wrote:
On May 14, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote: > > > On 05/14/2012 02:56 AM, Vincent Massol wrote: >> Hi Caleb, >> >> On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote: >> >>> Hi, >>> >>> I'd like to change the<repository> in each top level pom to nexus so that on release, all releases will go directly to staging by default. >>> Agent1 already has an account in the staging repository from my last release so this should just work. >>> >>> WDYT? >> >> +1 for using staging but not to change the target repo. We need to be able to go from staging to target. >> The canonical way is to use mvn release:stage. > > I don't know if it's as much canonical as it is the way that maven offers. > Nexus has a user interface which allows you to promote a release out of staging with just a few clicks. > I think maven's release:stage was designed with the assumption that most people don't have this luxury. > > My concern with leaving a live repository in the pom file is that it seems to be just asking for an accident > where everything gets pushed to the live server and has to be weeded out manually. I would like to avoid this if at all possible. > I want to minimize the risk and the best way I know to do that is to not let maven know where scp://maven.xwiki is. > > Caleb
I think that the POMs shouldn't know about staging repositories, since those aren't supposed to be "public". Personally I'd go for changing the release script so that it uses release:stage -DstagingRepository=http://nexus.xwiki.org...
Plus, the POM doesn't have support for specifying staging repositories
It has. It's a parameter called "stagingRepository" (see http://maven.apache.org/plugins/maven-release-plugin/usage.html).
I meant inside the <repositories> element, as a kind of repository besides "releases" and "snapshots". The "stagingRepository" is a parameter used only by the release:stage goal. Caleb was proposing to change the URL of the repositories as they are configured in the POM.
, just releases and snapshots, and it would be wrong to change the pom so that the "releases" repository, which most of the time is supposed to be used as a read-only location from which dependencies can be downloaded, would point to an upload-only URL that will fail when trying to download dependencies from it. The<repository> element is "a place to collect and store artifacts".
Yes that's true, good point: External tools could read that info from our released pom.xml and it should point to the final location, I agree…
I think the root pom is broken now, since the releases repository is supposed to be readable, while the current repository URL (http://nexus.xwiki.org/nexus/service/local/staging/deploy/maven2/) requires authentication, and even when logged in it will display an error when trying to read it.
How about making it http rather than scp so that it is read only? I just want to make sure maven will fail rather than trash a live repo, even if it is easy to fix.
Sergiu is right, see my previous reply. We need the pom to represent real data since external tools can read it.
Thanks -Vincent
Reverted the commit. The question now is must the release be dropped since it was released with settings which we do not agree upon?
Talked on irc, dropping the staged release. Caleb
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Caleb James DeLisle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol