[xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
13 May
2012
13 May
'12
12:17 p.m.
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
14 May
14 May
8:56 a.m.
New subject: [xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
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
9:29 a.m.
New subject: [xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
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:
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 ;)
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. 
10:07 a.m.
On Mon, May 14, 2012 at 10:29 AM, Vincent Massol <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:26 a.m.
New subject: [xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
On Mon, May 14, 2012 at 10:29 AM, Vincent Massol
<vincent(a)massol.net> wrote:
-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
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:27 a.m.
New subject: [xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
On May 14, 2012, at 10:26 AM, Vincent Massol wrote:
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
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
On Mon, May 14, 2012 at 10:29 AM, Vincent Massol
<vincent(a)massol.net> wrote:
-0 to put that in the release script :) 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. 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 ;)
4:58 p.m.
On 05/14/2012 04:27 AM, Vincent Massol wrote:
On May 14, 2012, at 10:26 AM, Vincent Massol wrote:
What do you mean by that? The script calls maven intensively, so it is
almost as standard as maven is.
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
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.
On Mon, May 14, 2012 at 10:29 AM, Vincent
Massol<vincent(a)massol.net> wrote:
-0 to put that in the release script :) 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
-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/
5:12 p.m.
New subject: [xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
On May 14, 2012, at 4:58 PM, Sergiu Dumitriu wrote:
On 05/14/2012 04:27 AM, Vincent Massol wrote:
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
On May 14, 2012, at 10:26 AM, Vincent Massol wrote:
What do you mean by that? The script calls maven intensively, so it is almost as standard
as maven is.
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
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.
On Mon, May 14, 2012 at 10:29 AM, Vincent
Massol<vincent(a)massol.net> 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 :)
> 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 ;)
5:38 p.m.
On 05/14/2012 11:12 AM, Vincent Massol wrote:
On May 14, 2012, at 4:58 PM, Sergiu Dumitriu wrote:
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...
On 05/14/2012 04:27 AM, Vincent Massol wrote:
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.
On May 14, 2012, at 10:26 AM, Vincent Massol wrote:
What do you mean by that? The script calls maven intensively, so it is almost as standard
as maven is.
On May 14, 2012, at 10:07 AM, Marius Dumitru Florea wrote:
> On Mon, May 14, 2012 at 10:29 AM, Vincent Massol<vincent(a)massol.net> 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
>
>> 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/
9:40 a.m.
On 05/14/2012 02:56 AM, Vincent Massol wrote:
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
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
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5 p.m.
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
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/
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
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 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.
5:17 p.m.
New subject: [xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
On May 14, 2012, at 5:00 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
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 02:56 AM, Vincent Massol wrote:
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. Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
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 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.
5:35 p.m.
On 05/14/2012 11:17 AM, Vincent Massol wrote:
On May 14, 2012, at 5:00 PM, Sergiu Dumitriu wrote:
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 05/14/2012 03:40 AM, Caleb James DeLisle
wrote:
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.
On 05/14/2012 02:56 AM, Vincent Massol wrote:
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. 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
5:47 p.m.
New subject: [xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
On May 14, 2012, at 5:35 PM, Sergiu Dumitriu wrote:
On 05/14/2012 11:17 AM, Vincent Massol wrote:
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 May 14, 2012, at 5:00 PM, Sergiu Dumitriu wrote:
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. On 05/14/2012 03:40 AM, Caleb James DeLisle
wrote:
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.
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.
5:49 p.m.
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
On 05/14/2012 02:56 AM, Vincent Massol wrote:
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/
Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
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 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.
6:07 p.m.
New subject: [xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
On May 14, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
On 05/14/2012 03:40 AM, Caleb James DeLisle wrote:
It has. It's a parameter called "stagingRepository" (see
http://maven.apache.org/plugins/maven-release-plugin/usage.html).
On 05/14/2012 02:56 AM, Vincent Massol wrote:
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 Hi Caleb,
On May 13, 2012, at 12:17 PM, Caleb James DeLisle wrote:
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 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. , 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
6:41 p.m.
On 05/14/2012 12:07 PM, Vincent Massol wrote:
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 May 14, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
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.
On 05/14/2012 03:40 AM, Caleb James DeLisle
wrote:
It has. It's a parameter called "stagingRepository" (see
http://maven.apache.org/plugins/maven-release-plugin/usage.html).
On 05/14/2012 02:56 AM, Vincent Massol wrote:
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 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 , 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…
8:26 p.m.
On 05/14/2012 12:41 PM, Sergiu Dumitriu wrote:
On 05/14/2012 12:07 PM, Vincent Massol wrote:
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 5:49 PM, Sergiu Dumitriu wrote:
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.
On 05/14/2012 03:40 AM, Caleb James DeLisle
wrote:
It has. It's a parameter called "stagingRepository" (see
http://maven.apache.org/plugins/maven-release-plugin/usage.html).
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".
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…
15 May
15 May
12:42 a.m.
New subject: [xwiki-devs] [proposal] Change the release repository to nexus so all releases will be staged by default.
On May 14, 2012, at 8:26 PM, Caleb James DeLisle wrote:
On 05/14/2012 12:41 PM, Sergiu Dumitriu wrote:
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 12:07 PM, Vincent Massol wrote:
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.
On May 14, 2012, at 5:49 PM, Sergiu Dumitriu wrote:
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.
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…
3:52 a.m.
On 05/14/2012 06:42 PM, Vincent Massol wrote:
On May 14, 2012, at 8:26 PM, Caleb James DeLisle wrote:
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
On 05/14/2012 12:41 PM, Sergiu Dumitriu wrote:
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 12:07 PM, Vincent Massol wrote:
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.
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:16 a.m.
On 05/14/2012 09:52 PM, Caleb James DeLisle wrote:
On 05/14/2012 06:42 PM, Vincent Massol wrote:
Talked on irc, dropping the staged release.
Caleb
On May 14, 2012, at 8:26 PM, Caleb James DeLisle wrote:
Reverted the commit. The question now is must the release be dropped since it was
released with settings which we do not agree upon?
On 05/14/2012 12:41 PM, Sergiu Dumitriu wrote:
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 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4560
days inactive
4562
days old
20 comments
4 participants
participants (4)
-
Caleb James DeLisle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol