Sure.
Done see http://jira.codehaus.org/browse/HAUS-2047
2011/1/30 Benjamin Bentmann :
> Olivier Lamy wrote:
>
>> As asked by Benson, it's probably better to move MPOM from codehaus
>> jira to ASF jira.
>
> It might make sense to also delete the MPOM project at Codehaus or disable
> at least the s
Olivier Lamy wrote:
As asked by Benson, it's probably better to move MPOM from codehaus
jira to ASF jira.
It might make sense to also delete the MPOM project at Codehaus or
disable at least the submission of new issues.
Benjamin
I tried :-)
It's not working.
Some users don't exist
On Fri, Jan 28, 2011 at 3:34 PM, Brian Fox wrote:
> aheritier
> baerrach
> bentmann
> brett
> brianf
> carlos
> dennisl
> dfabulich
> dkulp
> evenisse
> hboutemy
> jdcasey
> kenney
> krosenvold
> ltheussl
> mkleint
> oching
> olamy
> pgier
> r
aheritier
baerrach
bentmann
brett
brianf
carlos
dennisl
dfabulich
dkulp
evenisse
hboutemy
jdcasey
kenney
krosenvold
ltheussl
mkleint
oching
olamy
pgier
rgoers
snicoll
stephenc
vmassol
vsiveton
wfay
2011/1/28 Arnaud Héritier :
> ok,
> It's annoying to not have a mapping between LDAP/SVN groups and
ok,
It's annoying to not have a mapping between LDAP/SVN groups and Jira.
It could be easier to manage
On Fri, Jan 28, 2011 at 2:53 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> I've added you. We should get a full list of the PMC's apache jira
> user id's and then any/all of t
I've added you. We should get a full list of the PMC's apache jira
user id's and then any/all of the three of us can add the PMC to the
project role
2011/1/28 Arnaud Héritier :
> you can add me olivier (aheritier)
>
> On Fri, Jan 28, 2011 at 12:41 PM, Olivier Lamy wrote:
>
>> Hello,
>> I have cha
you can add me olivier (aheritier)
On Fri, Jan 28, 2011 at 12:41 PM, Olivier Lamy wrote:
> Hello,
> I have changed the subject.
> As asked by Benson, it's probably better to move MPOM from codehaus
> jira to ASF jira.
>
> So I have created a jira entry :
> https://issues.apache.org/jira/browse/I
Hello,
I have changed the subject.
As asked by Benson, it's probably better to move MPOM from codehaus
jira to ASF jira.
So I have created a jira entry :
https://issues.apache.org/jira/browse/INFRA-3397
I'd like maven dev give me or add in the jira entry their id.
Thanks !
--
Olivier Lamy
http:
2011/1/28 John Casey :
>
>
> On 1/27/11 4:22 PM, Benson Margulies wrote:
>>
>> I want to just put a bit of emphasis on the global impact of this POM.
>> This POM gets advertised as the appropriate parent for \any/ Apache
>> project building with Maven. As such, I submit to you, it should
>> supply
On 1/27/11 4:22 PM, Benson Margulies wrote:
I want to just put a bit of emphasis on the global impact of this POM.
This POM gets advertised as the appropriate parent for \any/ Apache
project building with Maven. As such, I submit to you, it should
supply all of the necessary settings (e.g. repo
On Thu, Jan 27, 2011 at 5:01 PM, Brian Fox wrote:
> I don't understand, running the full build on prepare is the default
> Maven behavior. This is to make sure that after flipping all the
> versions around, that the build works before tagging it.
I think I'm mushing a number of ideas together. Le
I don't understand, running the full build on prepare is the default
Maven behavior. This is to make sure that after flipping all the
versions around, that the build works before tagging it.
On Thu, Jan 27, 2011 at 4:22 PM, Benson Margulies wrote:
> I want to just put a bit of emphasis on the glo
I want to just put a bit of emphasis on the global impact of this POM.
This POM gets advertised as the appropriate parent for \any/ Apache
project building with Maven. As such, I submit to you, it should
supply all of the necessary settings (e.g. repository locations,
deployment) and no surprising
Brian Fox wrote:
FWIW, if the code-signing step fails due to some POM misconfiguration, and
only runs in the perform step, then you've got to rollback the release and
try it again...either that, or muck around with manually shifting the tag in
the SCM, which is probably as ugly.
I'm not as co
>
> FWIW, if the code-signing step fails due to some POM misconfiguration, and
> only runs in the perform step, then you've got to rollback the release and
> try it again...either that, or muck around with manually shifting the tag in
> the SCM, which is probably as ugly.
>
> I'm not as concerned a
On 1/27/11 11:52 AM, Benson Margulies wrote:
On Thu, Jan 27, 2011 at 11:44 AM, Olivier Lamy wrote:
I don't follow you here.
AFAIK : mvn release:prepare release:perform wil generate only two
builds (or I have missed something)
Olivier,
I spent many happy hours debugging and reading the code
On 1/27/11 11:10 AM, Olivier Lamy wrote:
I see your point.
If we do this the prepare won't be anymore a "repetition" of the real
perform goal (sources, sources bundle, javadoc).
Sure not a big deal but that means folks have some risks to found
issue too late.
So I'm +1.
btw we can add this ar
On Thu, Jan 27, 2011 at 11:44 AM, Olivier Lamy wrote:
> I don't follow you here.
> AFAIK : mvn release:prepare release:perform wil generate only two
> builds (or I have missed something)
Olivier,
I spent many happy hours debugging and reading the code to figure this out.
When you do 'mvn releas
I don't follow you here.
AFAIK : mvn release:prepare release:perform wil generate only two
builds (or I have missed something)
And in our case all mojo binds tru the profile apache-release won't be
executed in the prepare if we remove the stuff.
So it won't be possible to detect possible errors w
Remember that there are three runs of maven here.
The outer run.
The forked execution for prepare.
The forked execution for perform.
The first of these is still a full build, and can catch errors.
The last is as full as people choose to make it.
There's an additional problem that there is not
I see your point.
If we do this the prepare won't be anymore a "repetition" of the real
perform goal (sources, sources bundle, javadoc).
Sure not a big deal but that means folks have some risks to found
issue too late.
So I'm +1.
btw we can add this arguments again in the maven parent pom.
Other
On the compat front, can you think of a reason why removing this from
prepare would bust anything for anyone?
On Thu, Jan 27, 2011 at 10:40 AM, Benson Margulies
wrote:
> The problem is the use of rather than .
> The later only applies to 'perform'. the former also applies to
> prepare.
>
> So, g
The problem is the use of rather than .
The later only applies to 'perform'. the former also applies to
prepare.
So, gpg is turned on for prepare, which takes a long time and requires
keys to be present. If you just used releaseProfiles and
useReleaseProfiles it would be fine with me.
On Thu, Ja
I don't follow you here.
The goal of this profile activation is to generate a set of standard
ASF materials.
As it has been added, removing will means breaking backward comp.
IMHO it's easier to have it here when folks wants to cut a release.
BTW you can override this in your pom if you don't want
to 4.2.
>
> LieGrue,
> strub
>
> --- On Thu, 1/27/11, Benson Margulies wrote:
>
>> From: Benson Margulies
>> Subject: Re: ASF pom release
>> To: "Maven Developers List"
>> Date: Thursday, January 27, 2011, 2:59 PM
>> MPOM-2. The fact
I hope we can migrate over all the Maven JIRA issues from codehaus to
apache.org as soon as the ASF jira instance got upgraded to 4.2.
LieGrue,
strub
--- On Thu, 1/27/11, Benson Margulies wrote:
> From: Benson Margulies
> Subject: Re: ASF pom release
> To: "Maven Developers
MPOM-2. The fact that the Codehaus jira is the home of issues with the
ASF shared POM strikes me as something else that needs fixing.
On Thu, Jan 27, 2011 at 9:31 AM, Olivier Lamy wrote:
> Hello,
>
> The profile apache-release sounds good for adding various release materials.
> Can you explain wh
Yup I wanted this to.
Done.
2011/1/27 Igor Fedorenko :
> Is there a chance to update resources-plugin version to 2.4.3 for better
> m2e compatibility?
>
> --
> Regards,
> Igor
>
> On 11-01-27 04:30 AM, Olivier Lamy wrote:
>>
>> Hello Folks,
>>
>> I'd like to release the ASF parent pom [1].
>> In
Is there a chance to update resources-plugin version to 2.4.3 for better
m2e compatibility?
--
Regards,
Igor
On 11-01-27 04:30 AM, Olivier Lamy wrote:
Hello Folks,
I'd like to release the ASF parent pom [1].
In the maven parent pom [2], we have setup a maven-3 profile for the
site plugin.
No o
Hello,
The profile apache-release sounds good for adding various release materials.
Can you explain what's wrong or give the jira id ?
Thanks
2011/1/27 Benson Margulies :
> I note that -Papache-release is still in there.
>
> I filed a JIRA about the surprising and unpleasant effects of this. I
I note that -Papache-release is still in there.
I filed a JIRA about the surprising and unpleasant effects of this. I
don't own a -1, but it seems to me that it would be reasonable to ask
you to either remove this or close my JIRA explaining why I'm wrong.
On Thu, Jan 27, 2011 at 4:30 AM, Olivi
Sounds good.
BTW, I added the "useAgent" flag in there for the GPG plugin. I tested it with
and without an agent here, and can't see any downside - but someone using GPG
on other platforms might like to double check it doesn't mess anything up for
them.
- Brett
On 27/01/2011, at 8:30 PM, Oliv
Hello Folks,
I'd like to release the ASF parent pom [1].
In the maven parent pom [2], we have setup a maven-3 profile for the
site plugin.
No objections I move this profile to the ASF parent ?
Current diff :
$ svn diff http://svn.apache.org/repos/asf/maven/pom/tags/apache-8/pom.xml
http://svn.ap
33 matches
Mail list logo
