I think that there's a general principle at work in MSITE-600, so I
wonder whether anyone else agrees.
Quick summary:
Pom 1 has a distributionManagement/site/url element and a
modules/module element.
Pom 2 has a parent that indicates pom 1, with a relativePath. it also
has a distribution/site/ur
I have to correct my own email. The behavior here is independent of
relativePath and the presence or absence of modules. As things are
now, a pom like the global asf or maven pom dare not have a site
declared, or it will interact with poms that use it as a parent, even
if those poms fully specify t
I'll assume that this is fine and no one objects. I'll announce this on the
user list later today.
On Jul 27, 2011, at 10:48 AM, Jason van Zyl wrote:
> Maven PMC,
>
> Benjamin and I would like to make a distribution available that addresses
> several issues with the Apache Maven 3.0.3 release.
I'm trying to think about the questions of what might go into pom5,
and I realized that I am confused about the current design.
M3 deprecated 'reporting' but not 'scm'. I don't see the logic.
I propose to divide all POM content into two categories: things read
by the core of maven, and things rea
Larry-
try loading both dependencies in your local repository and running offline with
mvn -o (at least your dependencies will be found)
did you check cobertura for errors?
mvn -e -X cobertura:cobertura -Dquiet=true
take junit out of the mix and run testng as solo Test dependency then chec
mom jason.
Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists
in lots of DSCMs. Will do this in the next week.
LieGrue,
strub
--- On Thu, 7/28/11, Jason van Zyl wrote:
> From: Jason van Zyl
> Subject: Re: Apache Maven distribution with fixes
> To: "Maven Develope
On Thu, Jul 28, 2011 at 8:25 AM, Mark Struberg wrote:
> mom jason.
>
> Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists
> in lots of DSCMs. Will do this in the next week.
Unless there are a lot of pmc members hiding under a rock who aren't
voting +1, 3.0.4 can't inco
On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote:
> mom jason.
>
> Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists
> in lots of DSCMs. Will do this in the next week.
>
You probably have 6-7 weeks before an official 3.0.4 release would be made so
you have plenty
On 28/07/2011, at 10:32 PM, Jason van Zyl wrote:
> On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote:
>
>> mom jason.
>>
>> Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which
>> exists in lots of DSCMs. Will do this in the next week.
>>
>
> You probably have 6-7 weeks bef
On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote:
> I'll assume that this is fine and no one objects. I'll announce this on the
> user list later today.
*THAT* I have a problem with.I don't consider these any different than our
nightly snapshots or a different commercial "build" of a
Humm, guess there are only 3 options left in this case
1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take
more)
2.) You ship an ALv2 licensed version of Aether and Sisu which we can
incorporate into an upcoming maven-3.0.4.
3.) We fork the last ALv2 licensed Aether ve
On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote:
> On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote:
>> I'll assume that this is fine and no one objects. I'll announce this on the
>> user list later today.
>
> *THAT* I have a problem with.I don't consider these any different than
>
Mark,
No we cannot fork back. It is too large of a body of code to absorb
without a grant, AL or no AL.
I'm always happy to be proved stupid by consultation with legal. Until
then, however, the policy seems perfectly clear to me. Only small
amounts of code can be absorbed without a grant.
--bens
Benson, you are wrong.
The answer to this question is really not clear and depends on a much more then
just the pure amount of code. There are lots of discussions around that lately
on legal and we have lots of detailed if/whens. If we have the history, then we
can do the check. Gladly github p
On Thursday, July 28, 2011 8:59:09 AM Jason van Zyl wrote:
> On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote:
> > On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote:
> >> I'll assume that this is fine and no one objects. I'll announce this
> >> on the user list later today.
> >
> > *THAT* I
On Thu, Jul 28, 2011 at 9:10 AM, Mark Struberg wrote:
> Benson, you are wrong.
> The answer to this question is really not clear and depends on a much more
> then just the pure amount of code. There are lots of discussions around that
> lately on legal and we have lots of detailed if/whens. If w
On Jul 28, 2011, at 8:52 AM, Mark Struberg wrote:
> Humm, guess there are only 3 options left in this case
>
>
> 1.) We wait 7 weeks or whatever time it takes (most probably it _will_ take
> more)
>
Not likely, it will probably be shorter as I was being conservative. The
scheduling at Eclip
Correct me if I'm wrong, but it's not okay to even call the binary
maven-XXX or apache-maven-XXX (unless it's a snapshot) at all without
getting a PMC vote. I thought there were rules in our ASF release
protocols about that.
On 7/28/11 9:18 AM, Daniel Kulp wrote:
On Thursday, July 28, 2011 8:
On Jul 28, 2011, at 9:18 AM, Daniel Kulp wrote:
> On Thursday, July 28, 2011 8:59:09 AM Jason van Zyl wrote:
>> On Jul 28, 2011, at 8:49 AM, Daniel Kulp wrote:
>>> On Thursday, July 28, 2011 7:41:16 AM Jason van Zyl wrote:
I'll assume that this is fine and no one objects. I'll announce this
We will rebuild it and call it whatever you guys want. I don't know what the
rules are because they always seem to change, or what code has to be in a build
to be called this or that.
In this case we are just like anyone else in the community making a build to
fix problems because there is not
On Thursday, July 28, 2011 9:32:07 AM John Casey wrote:
> Correct me if I'm wrong, but it's not okay to even call the binary
> maven-XXX or apache-maven-XXX (unless it's a snapshot) at all without
> getting a PMC vote. I thought there were rules in our ASF release
> protocols about that.
That's ac
On Jul 28, 2011, at 9:18 AM, Daniel Kulp wrote:
>
> At the end of the day, if you really cared about the Maven users, you'd help
> us get an official Apache version of 3.0.4 out. The fact that you are
> unwilling to do what is necessary to make that happen is very frustrating to
> me.
>
The reason why no one committed to Aether beside yourself is partly that it
requires to sign some CLA which only unilaterally grants rights (as we can
certainly see now!).
Which is another reason why I consider a fork to apache-extras a good idea. And
don't come me with the argument that the Ma
Since it is a rather nasty bug due to a typo on my behalf, do we push a
release (2.2.1) now to include the fix and push all the unfixed issues back
to 2.3 (where they currently live)
-Stephen
If you are volunteering on the build, then +1 :)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connolly wrote:
> From: Stephen Connolly
> Subject: Do we want to push a Maven Release Plugin 2.2.1 to include
> MRELEASE-697?
> To: "Maven Developers List"
> Date: Thursday, July 28, 2011, 2:21 PM
>
>From my POV it could be a good thing for users to at least push a 3.0.4
release with what Benj fixed.
If Mark is sure to be able to fix next week the bug he mentioned let's wait
him.
For Aether/Sisu and additional fixes and required dependencies I let others
active dev/pmcs decide what they want.
well it was my typo in the first place, so yeah I'm willing to RM it... feck
it... i'll do it
On 28 July 2011 15:26, Mark Struberg wrote:
> If you are volunteering on the build, then +1 :)
>
> LieGrue,
> strub
>
> --- On Thu, 7/28/11, Stephen Connolly
> wrote:
>
> > From: Stephen Connolly
> >
perfectly fine with me.
LieGrue,
strub
--- On Thu, 7/28/11, Arnaud Héritier wrote:
> From: Arnaud Héritier
> Subject: Re: Apache Maven distribution with fixes
> To: "Maven Developers List"
> Date: Thursday, July 28, 2011, 2:27 PM
> From my POV it could be a good thing
> for users to at least
I think apache-extras would be the appropriate place, too. I understand
that there are concerns about code grants, etc. but at the same time
there are reasons to believe there would be practical limitations
preventing us from maintaining the fixes we might need in aether or
sisu...even leaving
+1
Can bentmann's fixes be applied without adopting the updated version of
Aether?
On 7/28/11 10:27 AM, Arnaud Héritier wrote:
From my POV it could be a good thing for users to at least push a 3.0.4
release with what Benj fixed.
If Mark is sure to be able to fix next week the bug he mentione
On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote:
> The reason why no one committed to Aether beside yourself is partly that it
> requires to sign some CLA which only unilaterally grants rights (as we can
> certainly see now!).
Have you read the Sonatype CLA? The contributor keeps retains co
+1 for a 2.2.1
Thanks
- Mail original -
> De : Stephen Connolly
> À : Maven Developers List
> Cc :
> Envoyé le : Jeudi 28 Juillet 2011 16h28
> Objet : Re: Do we want to push a Maven Release Plugin 2.2.1 to include
> MRELEASE-697?
>
> well it was my typo in the first place, so yeah
Hi,
This is a patch release to fix a particularly nasty regression:
http://jira.codehaus.org/browse/MRELEASE-697
We solved 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144&styleName=Html&version=17502
Staging repo:
https://repository.apache.org/content/repositories/mave
On 7/28/11 10:43 AM, Jason van Zyl wrote:
On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote:
The reason why no one committed to Aether beside yourself is partly that it
requires to sign some CLA which only unilaterally grants rights (as we can
certainly see now!).
Have you read the Sonat
+1
On 7/28/11 10:56 AM, Stephen Connolly wrote:
Hi,
This is a patch release to fix a particularly nasty regression:
http://jira.codehaus.org/browse/MRELEASE-697
We solved 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144&styleName=Html&version=17502
Staging repo:
http
On 7/28/11 7:43 AM, Benson Margulies wrote:
I'm trying to think about the questions of what might go into pom5,
and I realized that I am confused about the current design.
M3 deprecated 'reporting' but not 'scm'. I don't see the logic.
I propose to divide all POM content into two categories: t
On 28 July 2011 16:03, John Casey wrote:
>
>
> On 7/28/11 10:43 AM, Jason van Zyl wrote:
>>
>> On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote:
>>
>>> The reason why no one committed to Aether beside yourself is partly that
>>> it requires to sign some CLA which only unilaterally grants rights (
+1
source looks ok, signing looks ok, did a quick run on my test project - also ok.
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connolly wrote:
> From: Stephen Connolly
> Subject: [VOTE] Release Maven Release plugin version 2.2.1
> To: "Maven Developers List"
> Date: Thursday, July 28, 2011,
On Thu, Jul 28, 2011 at 5:11 PM, Stephen Connolly
wrote:
> On 28 July 2011 16:03, John Casey wrote:
>>
>>
>> On 7/28/11 10:43 AM, Jason van Zyl wrote:
>>>
>>> On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote:
>>>
The reason why no one committed to Aether beside yourself is partly that
Not sure what version you're reading but we specifically changed so that said
author retains copyright and Sonatype is granted a perpetual license. Changed
specifically when Brett brought it up, we brought it in line with what Apache
and Eclipse do.
On Jul 28, 2011, at 11:11 AM, Stephen Connoll
On Jul 28, 2011, at 11:03 AM, John Casey wrote:
>
>
> On 7/28/11 10:43 AM, Jason van Zyl wrote:
>>
>> On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote:
>>
>>> The reason why no one committed to Aether beside yourself is partly that it
>>> requires to sign some CLA which only unilaterally gr
On 28 July 2011 16:18, Milos Kleint wrote:
> On Thu, Jul 28, 2011 at 5:11 PM, Stephen Connolly
> wrote:
>> On 28 July 2011 16:03, John Casey wrote:
>>>
>>>
>>> On 7/28/11 10:43 AM, Jason van Zyl wrote:
On Jul 28, 2011, at 10:23 AM, Mark Struberg wrote:
> The reason why no one
Hi!
problem description
---
SCM URLs currently automatically get extended for child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child module 'frontend' will result in getting a SCM URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and CVS, but b
I'm not trying to argue to murder and friends, just to
understand how we got here.
I am now going to go to the wiki page and add some more thinking about
the use of extensible (e.g. property-set) XML for things like scm.
On Thu, Jul 28, 2011 at 11:10 AM, John Casey wrote:
>
> On 7/28/11 7:43 AM
On 7/28/11 12:51 PM, Benson Margulies wrote:
I'm not trying to argue to murder and friends, just to
understand how we got here.
"murder" nice. :-)
I am now going to go to the wiki page and add some more thinking about
the use of extensible (e.g. property-set) XML for things like scm.
wh
>>
>> I am now going to go to the wiki page and add some more thinking about
>> the use of extensible (e.g. property-set) XML for things like scm.
>
> what about existing xml tools for this: namespaces, URNs, etc.?
Let me do some thinking and writing on the wiki.
-
+1
Le 28 juil. 2011 à 16:49, Julien HENRY a écrit :
> +1 for a 2.2.1
>
> Thanks
>
>
>
> - Mail original -
>> De : Stephen Connolly
>> À : Maven Developers List
>> Cc :
>> Envoyé le : Jeudi 28 Juillet 2011 16h28
>> Objet : Re: Do we want to push a Maven Release Plugin 2.2.1 to include
Would it be better to have a syntax to mark a URL as literal, not to be
calculated or used as the basis of calculation?
That way, we don't have to worry about adjusting to new SCMs or other
places where we want to use it...new SCMs could be added via build
extension, IIRC, so this is particula
On Thu, Jul 28, 2011 at 2:59 PM, John Casey wrote:
> Would it be better to have a syntax to mark a URL as literal, not to be
> calculated or used as the basis of calculation?
>
Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it
broke lots of stuff that depended upon that behav
Hi John, Brian
Just to make sure I did understand that correctly:
you propose to use a special URL prefix to tell the maven DefaultProjectBuilder
to treat those urls as static. An example:
staticscm:git:ssh://myserver:/.. wrote:
> From: Brian Fox
> Subject: Re: [DISCUSS] SCM child-project
On 7/28/11 3:37 PM, Mark Struberg wrote:
Hi John, Brian
Just to make sure I did understand that correctly:
you propose to use a special URL prefix to tell the maven DefaultProjectBuilder
to treat those urls as static. An example:
staticscm:git:ssh://myserver:/..
I think that's an accep
he he. vote already in progress ;-)
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 28 Jul 2011 18:41, "Arnaud Héritier" wrote:
> +1
>
> Le 28 juil. 2011 à 16:49, Julien HE
not crazy about the syntax, but generally yes i think that makes sense.
I've long maintained that we need something similar for properties to
balance between "resolve at build time" and "resolve at fetch from
repo" type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg wrote:
> Hi John,
I keep thinking that I read about a convention that used the presence
or absence of a trailing '/' on the URL to control this. Does anyone
else recall this?
On Thu, Jul 28, 2011 at 5:32 PM, Brian Fox wrote:
> not crazy about the syntax, but generally yes i think that makes sense.
>
> I've long ma
Hi!
A small update:
Benjamin mentioned that this might also be useful for site URLs if a user like
to define the effective URLs of the sub-module site via
${project.version}/${project.artifactId} or similar.
So we just came up with "static:" as prefix.
More soon via Jira.
LieGrue,
strub
---
Is static: really superior to scm2: and then more colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg wrote:
> Hi!
>
> A small update:
>
> Benjamin mentioned that this might also be useful for site URLs if a user
> like to define the effective URLs of th
+1 Non Binding
On 29/07/2011, at 2:56 AM, Stephen Connolly wrote:
> Hi,
>
> This is a patch release to fix a particularly nasty regression:
> http://jira.codehaus.org/browse/MRELEASE-697
-
To unsubscribe, e-mail: dev-unsubscr.
On 7/28/11 5:43 PM, Benson Margulies wrote:
I keep thinking that I read about a convention that used the presence
or absence of a trailing '/' on the URL to control this. Does anyone
else recall this?
You mean overloading an explicit URL referencing a directory? Seems a
tad confusing and may
yup something like
static:scm:git:https://...
And the trailing / is rather unhandy. Some scms just crash if you don't use the
correct trailing ;)
LieGrue,
strub
--- On Thu, 7/28/11, Benson Margulies wrote:
> From: Benson Margulies
> Subject: Re: [DISCUSS] SCM child-project URL compositio
using scm2: you're not able to apply the solution to website urls, etc.
which have a similar inheritance/calculation problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
Is static: really superior to scm2: and then more colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5
Something what was denounced in the past was the mix of delivery
informations (identity, dependencies, ...) and project informations (build
configuration, build environment, team, )
delivery informations are immutable whereas for project informations it
depends. Build configuration used to crea
As well I know from MSITE-600. However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url, since those are naked urls.
The proposal above is not scm:static:, it's static:scm:. are you
suggesting putting static:http: in
/project/distributionManagem
Hi and txs 4 looking through the proposal!
is a neat idea but sadly requires us to change the pom-4.0
schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which parses the content of the urls
manually. It's not guaranteed what it contains, and we already apply _lots_ of
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
is a neat idea but sadly requires us to change the pom-4.0
schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which parses the content of the urls
manually. It's not guaranteed wh
attributes are special in XML schema. I plan to check and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Casey wrote:
>
>
> On 7/28/11 6:12 PM, Mark Struberg wrote:
>> Hi and txs 4 looking through the proposal!
>>
>> is a neat idea but sadly requires
i think modelleo allows any random attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only looking at
dependencies... a garden problem alright)
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nons
will try that too
yup, just fine too with mvn-3.0.3 and mvn-2.2.1.
So we now have either
A.)
scm:git:https://...
or
B.)
absolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connolly wrote:
> From: Stephen Connolly
> Subject: Re: [DISCUSS] SCM
Since the attributes work, let's go with that. It's cleaner than a
mangled URL, IMO. That's my vote, anyway.
-john
On 7/28/11 6:59 PM, Mark Struberg wrote:
will try that too
yup, just fine too with mvn-3.0.3 and mvn-2.2.1.
So we now have either
A.)
scm:git:https://...
or
B.)
absolute:s
Hi all,
I'm looking to use the maven-checkstyle-plugin with checkstyle 5.3, but it
only supports 5.0 as of the 2.6 release of the plugin.
Looking at trunk it seems to already have been upgraded to 5.3 but there
haven't been commits for a couple of months.
I'm using a few rules which are not avai
well the questions we need to ask then are:
does modelleo now support attributes so we can read it out
does this make a precident
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
scr
we already have the plugin config inheritance attributes in modello.
On Jul 28, 2011, at 7:27 PM, Stephen Connolly
wrote:
> well the questions we need to ask then are:
>
> does modelleo now support attributes so we can read it out
>
> does this make a precident
>
> - Stephen
>
> ---
> Sent from
I would also propose
C) A small bit of Java code in the form of a component for each SCM type and
inject those into the inheritance assembler to deal with the URLs. Then no need
is required in the POM, and we can also look at the version of Maven if we want
to mimic historic behavior. We could
Of course, not having to touch the POMs is a good thing.
But I don't get the 'historic behaviour' part. Even if you would have
components in the scm-providers (which all need to be changed), this solution
would not work with older maven version because they will simply not get
injected somewhe
On Jul 28, 2011, at 8:31 PM, Mark Struberg wrote:
> Of course, not having to touch the POMs is a good thing.
>
> But I don't get the 'historic behaviour' part. Even if you would have
> components in the scm-providers (which all need to be changed), this solution
> would not work with older ma
> Is it as simple as that for all SCMs?
Yes it is.
Remember the old days: this is only a fix for a 'fix'. Originally the SCM URLs
haven't been changed for child modules. This 'feature' only got introduce later
to make life easier for SVN and CVS users (the vast majority of projects back
then).
I have some perhaps minor bad news about attributes.
Attributes on the element won't validate against the current
schema. I had hoped to discover otherwise, but no such luck.
The combine.children trick passes because it is inside of the 'any'
inside the plugin configuration.
I claim that the fo
This was exactly the fix I applied back in 2.0.6 ish times and broke
too much stuff. Because the currently impl doesn't care about the
trailing /, too many poms have it set incorrectly.
On Thu, Jul 28, 2011 at 5:49 PM, John Casey wrote:
>
>
> On 7/28/11 5:43 PM, Benson Margulies wrote:
>>
>> I ke
Issue Subscription
Filter: Design & Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
https://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
Le vendredi 29 juillet 2011, Mark Struberg a écrit :
> > Is it as simple as that for all SCMs?
>
> Yes it is.
> Remember the old days: this is only a fix for a 'fix'. Originally the SCM
> URLs haven't been changed for child modules. This 'feature' only got
> introduce later to make life easier for
+1
Regards,
Hervé
Le jeudi 28 juillet 2011, Brett Porter a écrit :
> On 28/07/2011, at 10:32 PM, Jason van Zyl wrote:
> > On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote:
> >> mom jason.
> >>
> >> Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which
> >> exists in lots of DSC
+1
-Lukas
On 07/28/2011 04:56 PM, Stephen Connolly wrote:
Hi,
This is a patch release to fix a particularly nasty regression:
http://jira.codehaus.org/browse/MRELEASE-697
We solved 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144&styleName=Html&version=17502
Stagi
81 matches
Mail list logo
