dev@maven.apache.org Archives http://mail-archives.apache.org/mod_mbox/maven-dev/ 2009-12-07T16:29:40Z Re: Local Repository Optimizations should be removed Arnaud HERITIER <aheritier@gmail.com> urn:uuid:%3c262c6c680912070705v67ac38b8t9d98ee9492fd5eea@mail-gmail-com%3e 2009-12-07T15:05:33Z 
I agree to fix the behavior like you propose Paul.
It will reduce probably a little bit current performances but if it solves
the case explained by Tamas, why not ...


On Mon, Dec 7, 2009 at 4:01 PM, Paul Gier <pgier@redhat.com> wrote:

> It seems that the copyFileIfModified implementation should be changed.
>  Since currently it only checks if the source timestamp is newer.  Maybe
> this should be changed to check for the timestamps not equal (and maybe size
> not equal also) instead of just a newer timestamp.  That would allow the
> optimization, but also handle the use case described in the jira issue.
>
>
> Tamás Cservenák wrote:
>
>> Well, how about a "feature branch" (short lived branches)? Or you modify
>> all
>> the modules to have different GAV upon branch? This is kinda nonsense to
>> me,
>> since I branch it to do some feature that I know will get back into trunk.
>> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in this
>> case, IMHO.
>>
>> But even then, I dislike very much the idea that Maven "optimizes" this,
>> and
>> does less then I tell it to do ;)
>>
>> ~t~
>>
>> On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER <aheritier@gmail.com>
>> wrote:
>>
>>  You have the same version in 2 branches in a project ?
>>> For me it is a bad practice
>>> Each branch has it own version to avoid those sort of conflict.
>>>
>>>
>>> Arnaud Héritier
>>> Software Factory Manager
>>> eXo platform - http://www.exoplatform.com
>>> ---
>>> http://www.aheritier.net
>>>
>>>
>>> 2009/12/7 Tamás Cservenák <tamas@cservenak.net>
>>>
>>>  Hi there,
>>>>
>>>> this is mainly about this issue:
>>>> http://jira.codehaus.org/browse/MNG-4368
>>>>
>>>> It caused a lot of grief (and lost hours) to me, until I figured what
>>>> happens on me.
>>>>
>>>> IMHO, no "optimization" like this should be done against local
>>>>
>>> repository.
>>>
>>>> Please undo it.
>>>>
>>>>
>>>> Thanks,
>>>> ~t~
>>>>
>>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Local Repository Optimizations should be removed Arnaud HERITIER <aheritier@gmail.com> urn:uuid:%3c262c6c680912070702q3dd5f43csb88a2caf326194f6@mail-gmail-com%3e 2009-12-07T15:02:07Z 
ok. I don't know enough GIT and DSCMs.
I understand that many people want to work on various branches but I find
that dangerous if you kkep the same version.
What happens if you deploy SNAPSHOTs binairies in a repository to do
continuous integration ?

About your problem of optimization, I could understand we need to add a
switch to deactivate it in cases like yours. But I'm not in favor to remove
it. Your usecase (switching between several branches with the same "maven
version") isn't "common" and the gain given by the optimization is
important. I think that we need more optimizations like that to redo the
minimal number of things (like we did many many years ago with make).



Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net


2009/12/7 Tamás Cservenák <tamas@cservenak.net>

> Okay, let's put it this way:
>
> are you saying that all the different GIT reposes out there containing
> "project A" mirrors should have different versions? Who will coordinate
> those?
>
> It's somehow incompatible with Git (and probably any other distributed SCM)
> in very fundamental way....
>
> ~t~
>
> On Mon, Dec 7, 2009 at 3:30 PM, Arnaud HERITIER <aheritier@gmail.com>
> wrote:
>
> > ...
> > "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in
> this
> > case, IMHO.
> > ...
> > mvn versions:set -DnewVersion=A.B.C-optim-SNAPSHOT
> >
> > And it's done ?
> >
> >
> > Arnaud Héritier
> > Software Factory Manager
> > eXo platform - http://www.exoplatform.com
> > ---
> > http://www.aheritier.net
> >
> >
> > 2009/12/7 Tamás Cservenák <tamas@cservenak.net>
> >
> > > Well, how about a "feature branch" (short lived branches)? Or you
> modify
> > > all
> > > the modules to have different GAV upon branch? This is kinda nonsense
> to
> > > me,
> > > since I branch it to do some feature that I know will get back into
> > trunk.
> > > "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in
> > this
> > > case, IMHO.
> > >
> > > But even then, I dislike very much the idea that Maven "optimizes"
> this,
> > > and
> > > does less then I tell it to do ;)
> > >
> > > ~t~
> > >
> > > On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER <aheritier@gmail.com>
> > > wrote:
> > >
> > > > You have the same version in 2 branches in a project ?
> > > > For me it is a bad practice
> > > > Each branch has it own version to avoid those sort of conflict.
> > > >
> > > >
> > > > Arnaud Héritier
> > > > Software Factory Manager
> > > > eXo platform - http://www.exoplatform.com
> > > > ---
> > > > http://www.aheritier.net
> > > >
> > > >
> > > > 2009/12/7 Tamás Cservenák <tamas@cservenak.net>
> > > >
> > > > > Hi there,
> > > > >
> > > > > this is mainly about this issue:
> > > > > http://jira.codehaus.org/browse/MNG-4368
> > > > >
> > > > > It caused a lot of grief (and lost hours) to me, until I figured
> what
> > > > > happens on me.
> > > > >
> > > > > IMHO, no "optimization" like this should be done against local
> > > > repository.
> > > > >
> > > > > Please undo it.
> > > > >
> > > > >
> > > > > Thanks,
> > > > > ~t~
> > > > >
> > > >
> > >
> >
>
Re: Local Repository Optimizations should be removed Paul Gier <pgier@redhat.com> urn:uuid:%3c4B1D18AF-8010109@redhat-com%3e 2009-12-07T15:01:03Z 
It seems that the copyFileIfModified implementation should be changed.  Since 
currently it only checks if the source timestamp is newer.  Maybe this should be 
changed to check for the timestamps not equal (and maybe size not equal also) 
instead of just a newer timestamp.  That would allow the optimization, but also 
handle the use case described in the jira issue.

Tamás Cservenák wrote:
> Well, how about a "feature branch" (short lived branches)? Or you modify all
> the modules to have different GAV upon branch? This is kinda nonsense to me,
> since I branch it to do some feature that I know will get back into trunk.
> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in this
> case, IMHO.
> 
> But even then, I dislike very much the idea that Maven "optimizes" this, and
> does less then I tell it to do ;)
> 
> ~t~
> 
> On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER <aheritier@gmail.com> wrote:
> 
>> You have the same version in 2 branches in a project ?
>> For me it is a bad practice
>> Each branch has it own version to avoid those sort of conflict.
>>
>>
>> Arnaud HĂ©ritier
>> Software Factory Manager
>> eXo platform - http://www.exoplatform.com
>> ---
>> http://www.aheritier.net
>>
>>
>> 2009/12/7 Tamás Cservenák <tamas@cservenak.net>
>>
>>> Hi there,
>>>
>>> this is mainly about this issue:
>>> http://jira.codehaus.org/browse/MNG-4368
>>>
>>> It caused a lot of grief (and lost hours) to me, until I figured what
>>> happens on me.
>>>
>>> IMHO, no "optimization" like this should be done against local
>> repository.
>>> Please undo it.
>>>
>>>
>>> Thanks,
>>> ~t~
>>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed =?UTF-8?B?VGFtw6FzIENzZXJ2ZW7DoWs=?= <tamas@cservenak.net> urn:uuid:%3c53d6e7830912070645o4fb93266sd2b0e899a33292e5@mail-gmail-com%3e 2009-12-07T14:45:25Z 
Okay, let's put it this way:

are you saying that all the different GIT reposes out there containing
"project A" mirrors should have different versions? Who will coordinate
those?

It's somehow incompatible with Git (and probably any other distributed SCM)
in very fundamental way....

~t~

On Mon, Dec 7, 2009 at 3:30 PM, Arnaud HERITIER <aheritier@gmail.com> wrote:

> ...
> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in this
> case, IMHO.
> ...
> mvn versions:set -DnewVersion=A.B.C-optim-SNAPSHOT
>
> And it's done ?
>
>
> Arnaud HĂ©ritier
> Software Factory Manager
> eXo platform - http://www.exoplatform.com
> ---
> http://www.aheritier.net
>
>
> 2009/12/7 Tamás Cservenák <tamas@cservenak.net>
>
> > Well, how about a "feature branch" (short lived branches)? Or you modify
> > all
> > the modules to have different GAV upon branch? This is kinda nonsense to
> > me,
> > since I branch it to do some feature that I know will get back into
> trunk.
> > "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in
> this
> > case, IMHO.
> >
> > But even then, I dislike very much the idea that Maven "optimizes" this,
> > and
> > does less then I tell it to do ;)
> >
> > ~t~
> >
> > On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER <aheritier@gmail.com>
> > wrote:
> >
> > > You have the same version in 2 branches in a project ?
> > > For me it is a bad practice
> > > Each branch has it own version to avoid those sort of conflict.
> > >
> > >
> > > Arnaud HĂ©ritier
> > > Software Factory Manager
> > > eXo platform - http://www.exoplatform.com
> > > ---
> > > http://www.aheritier.net
> > >
> > >
> > > 2009/12/7 Tamás Cservenák <tamas@cservenak.net>
> > >
> > > > Hi there,
> > > >
> > > > this is mainly about this issue:
> > > > http://jira.codehaus.org/browse/MNG-4368
> > > >
> > > > It caused a lot of grief (and lost hours) to me, until I figured what
> > > > happens on me.
> > > >
> > > > IMHO, no "optimization" like this should be done against local
> > > repository.
> > > >
> > > > Please undo it.
> > > >
> > > >
> > > > Thanks,
> > > > ~t~
> > > >
> > >
> >
>
Re: Local Repository Optimizations should be removed Arnaud HERITIER <aheritier@gmail.com> urn:uuid:%3c262c6c680912070630p679ec27dj772d80af68f52a30@mail-gmail-com%3e 2009-12-07T14:30:35Z 
...
"Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in this
case, IMHO.
...
mvn versions:set -DnewVersion=A.B.C-optim-SNAPSHOT

And it's done ?


Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net


2009/12/7 Tamás Cservenák <tamas@cservenak.net>

> Well, how about a "feature branch" (short lived branches)? Or you modify
> all
> the modules to have different GAV upon branch? This is kinda nonsense to
> me,
> since I branch it to do some feature that I know will get back into trunk.
> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in this
> case, IMHO.
>
> But even then, I dislike very much the idea that Maven "optimizes" this,
> and
> does less then I tell it to do ;)
>
> ~t~
>
> On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER <aheritier@gmail.com>
> wrote:
>
> > You have the same version in 2 branches in a project ?
> > For me it is a bad practice
> > Each branch has it own version to avoid those sort of conflict.
> >
> >
> > Arnaud Héritier
> > Software Factory Manager
> > eXo platform - http://www.exoplatform.com
> > ---
> > http://www.aheritier.net
> >
> >
> > 2009/12/7 Tamás Cservenák <tamas@cservenak.net>
> >
> > > Hi there,
> > >
> > > this is mainly about this issue:
> > > http://jira.codehaus.org/browse/MNG-4368
> > >
> > > It caused a lot of grief (and lost hours) to me, until I figured what
> > > happens on me.
> > >
> > > IMHO, no "optimization" like this should be done against local
> > repository.
> > >
> > > Please undo it.
> > >
> > >
> > > Thanks,
> > > ~t~
> > >
> >
>
Re: Maven 3.0-alpha-5 and maven-archetype packaging =?UTF-8?Q?Stevo_Slavi=C4=87?= <sslavic@gmail.com> urn:uuid:%3c7459404c0912070626n4d4a6a3cpce4916c259ba780c@mail-gmail-com%3e 2009-12-07T14:26:06Z 
Thanks, fixed, build passes in both maven 2 and 3.

Regards,
Stevo.

On Mon, Dec 7, 2009 at 2:36 PM, Benjamin Bentmann <benjamin.bentmann@udo.edu
> wrote:

> Stevo Slavić wrote:
>
>  It seems 3.0-alpha-5 is not compatible with current 2.0-alpha-4 version of
>> maven-archetype-plugin - archetype:create-from-project mojo creates
>> archetype project with packaging maven-archetype, but that packaging seems
>> not to be supported by / valid for 3.0-alpha-5
>>
>
> Try running "mvn install" on your example project with Maven 2.x and you'll
> get
>
> [INFO] Cannot find lifecycle mapping for packaging: 'maven-archetype'.
>
> i.e. the project itself is broken, this has nothing to do with Maven 3.
>
> If you want to use a custom packaging like "maven-archetype", you have to
> declare the extension that provides this packaging, none of your POMs in the
> example project does.
>
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Local Repository Optimizations should be removed =?UTF-8?B?VGFtw6FzIENzZXJ2ZW7DoWs=?= <tamas@cservenak.net> urn:uuid:%3c53d6e7830912070625m55ca3880h21e9685646300948@mail-gmail-com%3e 2009-12-07T14:25:34Z 
Well, how about a "feature branch" (short lived branches)? Or you modify all
the modules to have different GAV upon branch? This is kinda nonsense to me,
since I branch it to do some feature that I know will get back into trunk.
"Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in this
case, IMHO.

But even then, I dislike very much the idea that Maven "optimizes" this, and
does less then I tell it to do ;)

~t~

On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER <aheritier@gmail.com> wrote:

> You have the same version in 2 branches in a project ?
> For me it is a bad practice
> Each branch has it own version to avoid those sort of conflict.
>
>
> Arnaud HĂ©ritier
> Software Factory Manager
> eXo platform - http://www.exoplatform.com
> ---
> http://www.aheritier.net
>
>
> 2009/12/7 Tamás Cservenák <tamas@cservenak.net>
>
> > Hi there,
> >
> > this is mainly about this issue:
> > http://jira.codehaus.org/browse/MNG-4368
> >
> > It caused a lot of grief (and lost hours) to me, until I figured what
> > happens on me.
> >
> > IMHO, no "optimization" like this should be done against local
> repository.
> >
> > Please undo it.
> >
> >
> > Thanks,
> > ~t~
> >
>
Re: Local Repository Optimizations should be removed Arnaud HERITIER <aheritier@gmail.com> urn:uuid:%3c262c6c680912070618k36d90d50q443ae88746557e5d@mail-gmail-com%3e 2009-12-07T14:18:56Z 
You have the same version in 2 branches in a project ?
For me it is a bad practice
Each branch has it own version to avoid those sort of conflict.


Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net


2009/12/7 Tamás Cservenák <tamas@cservenak.net>

> Hi there,
>
> this is mainly about this issue:
> http://jira.codehaus.org/browse/MNG-4368
>
> It caused a lot of grief (and lost hours) to me, until I figured what
> happens on me.
>
> IMHO, no "optimization" like this should be done against local repository.
>
> Please undo it.
>
>
> Thanks,
> ~t~
>
Local Repository Optimizations should be removed =?UTF-8?B?VGFtw6FzIENzZXJ2ZW7DoWs=?= <tamas@cservenak.net> urn:uuid:%3c53d6e7830912070606s18e09f45q7635883ee9c09c2@mail-gmail-com%3e 2009-12-07T14:06:28Z 
Hi there,

this is mainly about this issue:
http://jira.codehaus.org/browse/MNG-4368

It caused a lot of grief (and lost hours) to me, until I figured what
happens on me.

IMHO, no "optimization" like this should be done against local repository.

Please undo it.


Thanks,
~t~
Re: Maven 3.0-alpha-5 and maven-archetype packaging Benjamin Bentmann <benjamin.bentmann@udo.edu> urn:uuid:%3c4B1D04E8-1080404@udo-edu%3e 2009-12-07T13:36:40Z 
Stevo Slavić wrote:

> It seems 3.0-alpha-5 is not compatible with current 2.0-alpha-4 version of
> maven-archetype-plugin - archetype:create-from-project mojo creates
> archetype project with packaging maven-archetype, but that packaging seems
> not to be supported by / valid for 3.0-alpha-5

Try running "mvn install" on your example project with Maven 2.x and 
you'll get

[INFO] Cannot find lifecycle mapping for packaging: 'maven-archetype'.

i.e. the project itself is broken, this has nothing to do with Maven 3.

If you want to use a custom packaging like "maven-archetype", you have 
to declare the extension that provides this packaging, none of your POMs 
in the example project does.



Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Maven 3.0-alpha-5 and maven-archetype packaging =?UTF-8?Q?Stevo_Slavi=C4=87?= <sslavic@gmail.com> urn:uuid:%3c7459404c0912070516w2c6309fflcb35084126987906@mail-gmail-com%3e 2009-12-07T13:16:48Z 
Hello Maven developers,

It seems 3.0-alpha-5 is not compatible with current 2.0-alpha-4 version of
maven-archetype-plugin - archetype:create-from-project mojo creates
archetype project with packaging maven-archetype, but that packaging seems
not to be supported by / valid for 3.0-alpha-5 (see
this<https://issues.sonatype.org/browse/MNGECLIPSE-1920?focusedCommentId=107179&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_107179>Igor
Fedorenko's comment to a m2eclipse issue, showing error 3.0-alpha-5
prints when building projects with maven-archetype packaging). Question is
whether this behavior is intentional for maven3. If yes it would be good to
have this listed in maven3 compatibility
notes<http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html>,
otherwise ticket should be opened.

Regards,
Stevo.
Re: [VOTE] Release Maven Assembly Plugin 2.2-beta-5 =?UTF-8?B?R3J6ZWdvcnogU8WCb3dpa293c2tp?= <gslowikowski@gmail.com> urn:uuid:%3c4B1CC14A-7090709@gmail-com%3e 2009-12-07T08:48:10Z 
See my comment
http://jira.codehaus.org/browse/MASSEMBLY-416?focusedCommentId=201500&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_201500

Greetings

Grzegorz Slowikowski

Benjamin Bentmann wrote:
> Hi,
>
> We solved 7 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&version=15324 
>
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11126&status=1

>
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-041/
>
> Staging site (sync pending):
> http://maven.apache.org/plugins/maven-assembly-plugin-2.2-beta-5/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> +1 from me
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Resolving transitive dependencies in a mojo =?iso-8859-9?Q?Bar=FD=FE_Erdemir?= <Baris.Erdemir@yapikredi.com.tr> urn:uuid:%3c6B7BEE9733ADE248A5450A16DBB1F7F91E2FCD8F3E@ADRASAN-kfs-local%3e 2009-12-07T08:10:01Z 
Hello,
I am trying to resolve transitive dependencies of my project. I need a list of all dependencies.

I am using :

                /**
                * @parameter expression="${dependencies}" default-value="${project.dependencies}"
                */
                private ArrayList dependencies;

dependencies parameter and it gives some of the dependencies.
Is it possible to resolve all dependencies including its transitive dependencies?
If yes how can I resolve them?

Thanks in advance
Baris
Re: Release plugin documentation request David Jencks <david_jencks@yahoo.com> urn:uuid:%3c94D5EB6C-F1E3-432A-9BB3-647658DFD028@yahoo-com%3e 2009-12-07T07:09:06Z 
Hi Dennis,

Thanks for pointing out those pages.  They indeed have the information  
I was asking for for those three goals.  Might I suggest that these  
three pages are very clearly not examples but the basic usage guide  
for these three goals and would be much more visible linked from the  
usage page or better yet included in the goal explanation pages?

thanks
david jencks


On Dec 6, 2009, at 1:23 PM, Dennis Lundberg wrote:

> Hi David
>
> Great to get some feedback on the docs. I think we have "prepare",
> "perform" and "branch" covered pretty well with these pages:
>
> http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html
> http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html
> http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html
>
> So I guess we'd need two more covering "rollback" and "clean".
>
>
> David Jencks wrote:
>> I find that the release plugin docs don't give me an adequate idea of
>> what to expect to happen in svn when I run
>>
>> release:prepare
>> release:rollback
>> release:perform
>> release:branch
>>
>> After some experimentation I think I know what happens for some of  
>> these:
>>
>> release:prepare makes 3 svn commits
>> - update current project to release version
>> - create tag  (from what? I have no idea)
>> - update current project to next development version
>>
>> release:rollback, in an indeterminate number of commits, undoes  
>> anything
>> committed since release:prepare was run for the first time in this
>> release attempt.  In particular if you tried to commit build fixes  
>> that
>> only became evident during release:prepare, they will get undone.
>>
>> release:perform makes no svn changes
>>
>> release:branch I have no idea about.
>>
>> I suspect it would take about 15 minutes for one of the authors to
>> update the docs with some accurate info along these lines and I  
>> doubt I
>> would be the only one appreciating the effort.
>>
>> thanks
>> david jencks
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> -- 
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Maven Doxia and Maven Doxia Site Tools version 1.1.2 Vincent Siveton <vsiveton@apache.org> urn:uuid:%3c9ae367340912061731n77cc31bbs6bf6683516254286@mail-gmail-com%3e 2009-12-07T01:31:41Z 
The vote has passed with the following result:
Lukas, Olivier, Emmanuel, Hervé, Benjamin, Dennis, Paul, Vincent

I will promote the artifacts to the central repository and continue
with the release.

Cheers,

Vincent

2009/11/30 Vincent Siveton <vsiveton@apache.org>:
> Hi,
>
> Following Dennis to get Maven Site Plugin 2.1 (we hope for Xmas), here
> is the release of Doxia 1.1.2.
>
> We solved around 20 issues for both:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780&styleName=Html&version=15517
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624&styleName=Html&version=15518
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10780&status=1
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11624&status=1
>
> Staging repos:
> https://repository.apache.org/content/repositories/maven-027/
>
> Staging sites (need to sync):
> http://maven.apache.org/doxia/doxia-1.1.2
> http://maven.apache.org/doxia/doxia-sitetools-1.1.2
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin documentation request Dennis Lundberg <dennisl@apache.org> urn:uuid:%3c4B1C20EC-5010405@apache-org%3e 2009-12-06T21:23:56Z 
Hi David

Great to get some feedback on the docs. I think we have "prepare",
"perform" and "branch" covered pretty well with these pages:

http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html
http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html
http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html

So I guess we'd need two more covering "rollback" and "clean".


David Jencks wrote:
> I find that the release plugin docs don't give me an adequate idea of
> what to expect to happen in svn when I run
> 
> release:prepare
> release:rollback
> release:perform
> release:branch
> 
> After some experimentation I think I know what happens for some of these:
> 
> release:prepare makes 3 svn commits
> - update current project to release version
> - create tag  (from what? I have no idea)
> - update current project to next development version
> 
> release:rollback, in an indeterminate number of commits, undoes anything
> committed since release:prepare was run for the first time in this
> release attempt.  In particular if you tried to commit build fixes that
> only became evident during release:prepare, they will get undone.
> 
> release:perform makes no svn changes
> 
> release:branch I have no idea about.
> 
> I suspect it would take about 15 minutes for one of the authors to
> update the docs with some accurate info along these lines and I doubt I
> would be the only one appreciating the effort.
> 
> thanks
> david jencks
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[VOTE] Release Maven Changes Plugin version 2.3 (take 2) Dennis Lundberg <dennisl@apache.org> urn:uuid:%3c4B1C1F64-103@apache-org%3e 2009-12-06T21:17:24Z 
Hi,

This time I'm building with Maven 2.0.10, so the signatures should be
OK. I did not re-stage the site, since there were no changes to it.


This vote comes soon after the 2.2 release, but I'd like to get a quick
release out to fix http://jira.codehaus.org/browse/MCHANGES-186 which is
a regression from the 2.1 version.

We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11212&version=15999

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11212&status=1

Staging repo:
https://repository.apache.org/content/repositories/maven-042/

Staging site:
http://maven.apache.org/plugins/maven-changes-plugin-2.3/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[Canceled] [VOTE] Release Maven Changes Plugin version 2.3 Dennis Lundberg <dennisl@apache.org> urn:uuid:%3c4B1C1A17-8030609@apache-org%3e 2009-12-06T20:54:47Z 
Benjamin Bentmann wrote:
> Dennis Lundberg wrote:
> 
>> This vote comes soon after the 2.2 release
> 
> No need to apologize ;-)
> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-036/
> 
> The .pom.asc seems not to match the plugin POM [0]. Looking at the POM,
> it seems as if it was deployed using Maven 2.1.0 and suffers from
> MNG-4167/MGPG-14.

I'll redo the build with the correct Maven version.

> 
> 
> Benjamin
> 
> 
> [0]
> https://repository.apache.org/content/repositories/maven-036/org/apache/maven/plugins/maven-changes-plugin/2.3/maven-changes-plugin-2.3.pom
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[VOTE] Release Maven Assembly Plugin 2.2-beta-5 Benjamin Bentmann <benjamin.bentmann@udo.edu> urn:uuid:%3c4B1C0141-6090005@udo-edu%3e 2009-12-06T19:08:49Z 
Hi,

We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&version=15324

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11126&status=1

Staging repo:
https://repository.apache.org/content/repositories/maven-041/

Staging site (sync pending):
http://maven.apache.org/plugins/maven-assembly-plugin-2.2-beta-5/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

+1 from me


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Upload Apache Pivot artifacts to central repository? Greg Brown <gkbrown@mac.com> urn:uuid:%3cCFB1FB9C-B093-475D-9326-CB8E99217304@mac-com%3e 2009-12-06T12:59:49Z 
Thanks Brian. I just took a look at the JIRA ticket - I'll follow the steps you suggested and
post any additional questions/comments there.
Greg

On Dec 5, 2009, at 11:01 PM, Brian Fox wrote:

> Greg, I created the issue and setup the project. See my comments here
> regarding the bundles:
> https://issues.apache.org/jira/browse/INFRA-2364
> 
> On Fri, Dec 4, 2009 at 5:37 PM, Brian Fox <brianf@infinity.nu> wrote:
>> Hi Greg, yes I'll take a look. Since it's an apache project, we should
>> use http://repository.apache.org for this. We have support to stage
>> bundles in the latest version so let me get the pivot project setup
>> and then I'll give some docs on this. Can you file a jira
>> here:https://issues.apache.org/jira/browse/INFRA-1896 ?
>> 
>> On Fri, Dec 4, 2009 at 5:24 PM, Greg Brown <gkbrown@mac.com> wrote:
>>> Hi Brian,
>>> 
>>> I managed to install the Pivot artifacts in a local Maven repository and successfully
built a sample project that lists them as dependencies. So, I am optimistic that the POMs
are structured correctly.
>>> 
>>> Next, I attempted to package the artifacts for manual upload as described on
this page:
>>> 
>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>> 
>>> The results are in this zip file, which contains one JAR per Pivot artifact:
>>> 
>>> http://ixnay.biz/pivot-bundles.zip
>>> 
>>> Would it be possible for you to take a quick look and verify that they are in
the correct format for manual upload?
>>> 
>>> If so, what would be the next steps to get them into the central repository?
Is there still a way for Apache projects to do this without needing to go through the 4-week
process described on the upload page? If not, that's OK - I'm just wondering.
>>> 
>>> (Note that the artifacts themselves are not actually ready for upload - I am
just trying to get the process worked out in anticipation of Pivot's graduation. The final
artifacts for Pivot 1.4 probably won't be ready for another few weeks.)
>>> 
>>> Thanks again for your help,
>>> Greg
>>> 
>>> 
>>> On Dec 3, 2009, at 11:27 AM, Brian Fox wrote:
>>> 
>>>> Hi Greg, I'll take a look later today and ping back on the pivot dev
>>>> list with what I find.
>>>> 
>>>> On Thu, Dec 3, 2009 at 6:44 AM, Greg Brown <gkbrown@mac.com> wrote:
>>>>> Forwarding this message to dev@maven.apache.org in case users@maven.apache.org
wasn't the right place. Also, since sending the original message, I have heard that the document
I had been referring to might be outdated.
>>>>> 
>>>>> Can anyone help?
>>>>> 
>>>>> Thanks!
>>>>> Greg
>>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>>> From: Greg Brown <gkbrown@mac.com>
>>>>>> Date: December 2, 2009 12:38:13 PM EST
>>>>>> To: users@maven.apache.org
>>>>>> Cc: pivot-dev@incubator.apache.org
>>>>>> Subject: Upload Apache Pivot artifacts to central repository
>>>>>> Reply-To: pivot-dev@incubator.apache.org
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> Apache Pivot is preparing for graduation, and we would like to upload
our next set of release artifacts to the central Maven repository. We don't currently use
Maven as a build tool, so I have been trying to follow the manual upload instructions listed
here:
>>>>>> 
>>>>>> http://www.apache.org/dev/release-publishing.html#maven-repo
>>>>>> 
>>>>>> There is a section at the bottom that is meant to explain how to
create an appropriate POM file, but it does not appear to be complete:
>>>>>> 
>>>>>> http://www.apache.org/dev/release-publishing.html#repository-descriptor
>>>>>> 
>>>>>> I have created some POMs that I think should work, but it would be
very helpful if someone with a knowledgeable eye could take a quick look to make sure that
they contain the correct information, are structured properly, etc. There is a root POM in
the trunk, and a POM in each project-specific subdirectory that we plan to publish to the
repository (note that these files refer to the anticipated future name and location of the
project, as opposed to its current Incubator name and location):
>>>>>> 
>>>>>> http://svn.apache.org/repos/asf/incubator/pivot/trunk/
>>>>>> 
>>>>>> Based on the documentation I have read thus far, I assume that we'll
want to place our compiled JARs in a pivot/jars directory, and structure our POMs as follows:
>>>>>> 
>>>>>> pivot/poms
>>>>>>    pom.xml
>>>>>>    /core/pom.xml
>>>>>>    /web/pom.xml
>>>>>>    /wtk/pom.xml
>>>>>>    /wtk-terra/pom.xml
>>>>>> 
>>>>>> I don't think we'll need to use the distributions directory, and
I assume that the licenses directory should simply contain a copy of our main LICENSE file.
Is this all correct?
>>>>>> 
>>>>>> Also, one of our mentors, Martijn Dashorst, suggested that there
might be a top-level ASF POM that the root Pivot POM could extend (rather than duplicating
the ASF info). If so, could you point us to it?
>>>>>> 
>>>>>> Thanks - your assistance is very much appreciated!
>>>>>> 
>>>>>> Greg Brown
>>>>>> Apache Pivot
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Upload Apache Pivot artifacts to central repository? Brian Fox <brianf@infinity.nu> urn:uuid:%3ceb0f802d0912052001p7cc2ab5dmaafa4d1870033da7@mail-gmail-com%3e 2009-12-06T04:01:24Z 
Greg, I created the issue and setup the project. See my comments here
regarding the bundles:
https://issues.apache.org/jira/browse/INFRA-2364

On Fri, Dec 4, 2009 at 5:37 PM, Brian Fox <brianf@infinity.nu> wrote:
> Hi Greg, yes I'll take a look. Since it's an apache project, we should
> use http://repository.apache.org for this. We have support to stage
> bundles in the latest version so let me get the pivot project setup
> and then I'll give some docs on this. Can you file a jira
> here:https://issues.apache.org/jira/browse/INFRA-1896 ?
>
> On Fri, Dec 4, 2009 at 5:24 PM, Greg Brown <gkbrown@mac.com> wrote:
>> Hi Brian,
>>
>> I managed to install the Pivot artifacts in a local Maven repository and successfully
built a sample project that lists them as dependencies. So, I am optimistic that the POMs
are structured correctly.
>>
>> Next, I attempted to package the artifacts for manual upload as described on this
page:
>>
>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>
>> The results are in this zip file, which contains one JAR per Pivot artifact:
>>
>> http://ixnay.biz/pivot-bundles.zip
>>
>> Would it be possible for you to take a quick look and verify that they are in the
correct format for manual upload?
>>
>> If so, what would be the next steps to get them into the central repository? Is there
still a way for Apache projects to do this without needing to go through the 4-week process
described on the upload page? If not, that's OK - I'm just wondering.
>>
>> (Note that the artifacts themselves are not actually ready for upload - I am just
trying to get the process worked out in anticipation of Pivot's graduation. The final artifacts
for Pivot 1.4 probably won't be ready for another few weeks.)
>>
>> Thanks again for your help,
>> Greg
>>
>>
>> On Dec 3, 2009, at 11:27 AM, Brian Fox wrote:
>>
>>> Hi Greg, I'll take a look later today and ping back on the pivot dev
>>> list with what I find.
>>>
>>> On Thu, Dec 3, 2009 at 6:44 AM, Greg Brown <gkbrown@mac.com> wrote:
>>>> Forwarding this message to dev@maven.apache.org in case users@maven.apache.org
wasn't the right place. Also, since sending the original message, I have heard that the document
I had been referring to might be outdated.
>>>>
>>>> Can anyone help?
>>>>
>>>> Thanks!
>>>> Greg
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Greg Brown <gkbrown@mac.com>
>>>>> Date: December 2, 2009 12:38:13 PM EST
>>>>> To: users@maven.apache.org
>>>>> Cc: pivot-dev@incubator.apache.org
>>>>> Subject: Upload Apache Pivot artifacts to central repository
>>>>> Reply-To: pivot-dev@incubator.apache.org
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Apache Pivot is preparing for graduation, and we would like to upload
our next set of release artifacts to the central Maven repository. We don't currently use
Maven as a build tool, so I have been trying to follow the manual upload instructions listed
here:
>>>>>
>>>>> http://www.apache.org/dev/release-publishing.html#maven-repo
>>>>>
>>>>> There is a section at the bottom that is meant to explain how to create
an appropriate POM file, but it does not appear to be complete:
>>>>>
>>>>> http://www.apache.org/dev/release-publishing.html#repository-descriptor
>>>>>
>>>>> I have created some POMs that I think should work, but it would be very
helpful if someone with a knowledgeable eye could take a quick look to make sure that they
contain the correct information, are structured properly, etc. There is a root POM in the
trunk, and a POM in each project-specific subdirectory that we plan to publish to the repository
(note that these files refer to the anticipated future name and location of the project, as
opposed to its current Incubator name and location):
>>>>>
>>>>> http://svn.apache.org/repos/asf/incubator/pivot/trunk/
>>>>>
>>>>> Based on the documentation I have read thus far, I assume that we'll
want to place our compiled JARs in a pivot/jars directory, and structure our POMs as follows:
>>>>>
>>>>> pivot/poms
>>>>>    pom.xml
>>>>>    /core/pom.xml
>>>>>    /web/pom.xml
>>>>>    /wtk/pom.xml
>>>>>    /wtk-terra/pom.xml
>>>>>
>>>>> I don't think we'll need to use the distributions directory, and I assume
that the licenses directory should simply contain a copy of our main LICENSE file. Is this
all correct?
>>>>>
>>>>> Also, one of our mentors, Martijn Dashorst, suggested that there might
be a top-level ASF POM that the root Pivot POM could extend (rather than duplicating the ASF
info). If so, could you point us to it?
>>>>>
>>>>> Thanks - your assistance is very much appreciated!
>>>>>
>>>>> Greg Brown
>>>>> Apache Pivot
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PMC] Maven Ant Tasks 2.1.0 need adding to the board report Benjamin Bentmann <benjamin.bentmann@udo.edu> urn:uuid:%3c4B1AA4D5-6040805@udo-edu%3e 2009-12-05T18:22:13Z 
Paul Gier wrote:

> The Maven Ant Tasks 2.1.0 have been released.
> Can this be added to the next board report please?

Done.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[PMC] Maven Ant Tasks 2.1.0 need adding to the board report Paul Gier <pgier@apache.org> urn:uuid:%3c4B1AA3D8-4000603@apache-org%3e 2009-12-05T18:18:00Z 
The Maven Ant Tasks 2.1.0 have been released.
Can this be added to the next board report please?

Thanks!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[RESULT] [VOTE] Release Maven Ant Tasks version 2.1.0 Paul Gier <pgier@redhat.com> urn:uuid:%3c4B1AA2CC-5080108@redhat-com%3e 2009-12-05T18:13:32Z 
CC to the PMC list.

Paul Gier wrote:
> Hi,
> 
> The vote has passed with the following result:
> 
> +1 (binding): Benjamin Bentmann, Jason van Zyl, Hervé Boutemy
> 
> +1 (non-binding): Paul Gier, Stephen Connolly
> 
> I will promote the artifacts to the central repository and continue with 
> the release.
> 
> 
> 
> Paul Gier wrote:
>> Hi,
>>
>> I believe it's time for the next release of the Maven Ant Tasks.  This 
>> release has several enhancements and bug fixes and the dependencies on 
>> the core maven libraries have been updated to version 2.2.1.
>>
>> I also created a download page as part of the Ant tasks site.  This 
>> will allow the Ant task download links to be removed from the main 
>> Maven download page.
>>
>> We solved 12 issues:
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533&version=13522

>>
>>
>> There are still a couple of issues left in JIRA:
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+MANTTASKS+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide

>>
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-033/
>>
>> Staging site (need to sync):
>> http://maven.apache.org/ant-tasks-2.1.0/
>>
>> SCM Tag:
>> https://svn.apache.org/repos/asf/maven/ant-tasks/tags/maven-ant-tasks-2.1.0 
>>
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[ANN] Maven Ant Tasks 2.1.0 Released Paul Gier <pgier@apache.org> urn:uuid:%3c4B1AA1C1-1020809@apache-org%3e 2009-12-05T18:09:05Z 

The Maven team is pleased to announce the release of the Maven Ant Tasks,
version 2.1.0

The Maven Ant Tasks allow several features of Maven to be used in an Ant build. 
  This includes dependency management, reading and writing pom files, and 
deployment to a Maven repository.  More information is available at the project 
site.

http://maven.apache.org/ant-tasks

The current version of the Maven Ant Tasks can be downloaded from the project 
downloads page.

http://maven.apache.org/ant-tasks/download.html


Release Notes - Maven Ant Tasks - Version 2.1.0

** Bug
     * [MANTTASKS-4] - System scope not working properly in Maven Antlib
     * [MANTTASKS-152] - Mvn task omit localRepository param
     * [MANTTASKS-153] - Properties defined in Ant are not passed to Maven
     * [MANTTASKS-155] - Dependency fileset should set the current ant project
     * [MANTTASKS-159] - Wrong credentials used for mirrored repositories
     * [MANTTASKS-160] - Wrong metadata files created for mirrored remote 
repositories
     * [MANTTASKS-167] - Generated ant build file should save version list for 
version mapper

** Improvement
     * [MANTTASKS-117] - Setting Maven user-properties not possible
     * [MANTTASKS-169] - Dependencies "verbose" option should be deprecated in 
favor of standard ant verbose option

** New Feature
     * [MANTTASKS-151] - Support for artfacts that are 'classified' from birth
     * [MANTTASKS-156] - Add feature to dependencies task to write file paths to 
a file.
     * [MANTTASKS-168] - New task to write a pom file


Enjoy,

-The Maven team



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-3004/MNG-2802 - Achieving massive parallelity ? Jason van Zyl <jason@maven.org> urn:uuid:%3cD23C4BCB-4EDE-4312-BF1D-ED571386540F@sonatype-com%3e 2009-12-05T02:58:21Z 
I'm just starting to take a look now.

Have you buy chance run what you've built against the integration tests?

http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/

If not, happy to help, or we can pull it into the grid and try it out there.

On 2009-12-03, at 1:05 AM, Kristian Rosenvold wrote:

> It's getting close enough, as long as you satisfy the
> following constraints:
> 
> - Make sure your build works with "regular" maven3 snapshots first ;)
> - You're not too reliant on snapshot artifacts (MNG-2802 is next on my
> TODO list now)
> - You're not generating source code in generate-sources 
> - Running aggregating tasks (javadoc etc) is largely untested as of yet.
> 
> The last two should be easily fixable but I've been concentrating on
> the main concurrency concerns (safe publication, deadlock avoidance etc)
> until now, but this seems to be rock solid with my build as of now. This
> is really also the stuff I need input on, since this is usually quite
> timing sensitive. (I have 2 different builds I run on C2D, i7 and dual
> xenons without hiccups right now)
> 
> Get the install from 
> 
> http://cloud.github.com/downloads/krosenvold/maven3/apache-maven-3.0-SNAPSHOT-bin.tar.gz
> 
> 
> mvn -e -Dmaven.threads.experimental=6 clean install
> 
> On my build, 1 thread per core gives best results. Maybe "3" for Core 2
> duo.
> 
> This version is up-to-date with maven3 trunk as of Thu Dec 3 09:01:44
> 2009 +0100. If you run without the -Dmaven.threads.experimental=6
> option, you should basically by running regular maven3 trunk.
> 
> 
> Kristian
> 
> 
> 
> 
> On Thu, 2009-12-03 at 09:21 +0100, Jorg Heymans wrote:
>> On Tue, Dec 1, 2009 at 9:49 PM, Kristian Rosenvold
>> <kristian.rosenvold@gmail.com> wrote:
>>> I am pleased to announce that the "weave" mode now does a
>>> "mvn clean install" of a fairly regular project with any number of
>>> threads, and at great speed improvement - 2-4x is not uncommon.
>>> 
>>> There are still issues to be sorted out, and I'd be really grateful
>>> for any reports of problems.
>>> 
>>> See http://github.com/krosenvold/maven3 for a *lot* more details
>>> on problems & issues and how to test this out on your builds.
>> 
>> Looks incredibly promising !
>> 
>> I would be more than happy to give you test feedback if you could
>> supply a binary dist with this feature. Or is it not yet ready to be
>> tested by the 'masses' ?
>> 
>> Jorg
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Upload Apache Pivot artifacts to central repository? Brian Fox <brianf@infinity.nu> urn:uuid:%3ceb0f802d0912041537j1a1d044fu42b0be453aaebc3a@mail-gmail-com%3e 2009-12-04T23:37:09Z 
Hi Greg, yes I'll take a look. Since it's an apache project, we should
use http://repository.apache.org for this. We have support to stage
bundles in the latest version so let me get the pivot project setup
and then I'll give some docs on this. Can you file a jira
here:https://issues.apache.org/jira/browse/INFRA-1896 ?

On Fri, Dec 4, 2009 at 5:24 PM, Greg Brown <gkbrown@mac.com> wrote:
> Hi Brian,
>
> I managed to install the Pivot artifacts in a local Maven repository and successfully
built a sample project that lists them as dependencies. So, I am optimistic that the POMs
are structured correctly.
>
> Next, I attempted to package the artifacts for manual upload as described on this page:
>
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>
> The results are in this zip file, which contains one JAR per Pivot artifact:
>
> http://ixnay.biz/pivot-bundles.zip
>
> Would it be possible for you to take a quick look and verify that they are in the correct
format for manual upload?
>
> If so, what would be the next steps to get them into the central repository? Is there
still a way for Apache projects to do this without needing to go through the 4-week process
described on the upload page? If not, that's OK - I'm just wondering.
>
> (Note that the artifacts themselves are not actually ready for upload - I am just trying
to get the process worked out in anticipation of Pivot's graduation. The final artifacts for
Pivot 1.4 probably won't be ready for another few weeks.)
>
> Thanks again for your help,
> Greg
>
>
> On Dec 3, 2009, at 11:27 AM, Brian Fox wrote:
>
>> Hi Greg, I'll take a look later today and ping back on the pivot dev
>> list with what I find.
>>
>> On Thu, Dec 3, 2009 at 6:44 AM, Greg Brown <gkbrown@mac.com> wrote:
>>> Forwarding this message to dev@maven.apache.org in case users@maven.apache.org
wasn't the right place. Also, since sending the original message, I have heard that the document
I had been referring to might be outdated.
>>>
>>> Can anyone help?
>>>
>>> Thanks!
>>> Greg
>>>
>>> Begin forwarded message:
>>>
>>>> From: Greg Brown <gkbrown@mac.com>
>>>> Date: December 2, 2009 12:38:13 PM EST
>>>> To: users@maven.apache.org
>>>> Cc: pivot-dev@incubator.apache.org
>>>> Subject: Upload Apache Pivot artifacts to central repository
>>>> Reply-To: pivot-dev@incubator.apache.org
>>>>
>>>> Hi all,
>>>>
>>>> Apache Pivot is preparing for graduation, and we would like to upload our
next set of release artifacts to the central Maven repository. We don't currently use Maven
as a build tool, so I have been trying to follow the manual upload instructions listed here:
>>>>
>>>> http://www.apache.org/dev/release-publishing.html#maven-repo
>>>>
>>>> There is a section at the bottom that is meant to explain how to create an
appropriate POM file, but it does not appear to be complete:
>>>>
>>>> http://www.apache.org/dev/release-publishing.html#repository-descriptor
>>>>
>>>> I have created some POMs that I think should work, but it would be very helpful
if someone with a knowledgeable eye could take a quick look to make sure that they contain
the correct information, are structured properly, etc. There is a root POM in the trunk, and
a POM in each project-specific subdirectory that we plan to publish to the repository (note
that these files refer to the anticipated future name and location of the project, as opposed
to its current Incubator name and location):
>>>>
>>>> http://svn.apache.org/repos/asf/incubator/pivot/trunk/
>>>>
>>>> Based on the documentation I have read thus far, I assume that we'll want
to place our compiled JARs in a pivot/jars directory, and structure our POMs as follows:
>>>>
>>>> pivot/poms
>>>>    pom.xml
>>>>    /core/pom.xml
>>>>    /web/pom.xml
>>>>    /wtk/pom.xml
>>>>    /wtk-terra/pom.xml
>>>>
>>>> I don't think we'll need to use the distributions directory, and I assume
that the licenses directory should simply contain a copy of our main LICENSE file. Is this
all correct?
>>>>
>>>> Also, one of our mentors, Martijn Dashorst, suggested that there might be
a top-level ASF POM that the root Pivot POM could extend (rather than duplicating the ASF
info). If so, could you point us to it?
>>>>
>>>> Thanks - your assistance is very much appreciated!
>>>>
>>>> Greg Brown
>>>> Apache Pivot
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Upload Apache Pivot artifacts to central repository? Greg Brown <gkbrown@mac.com> urn:uuid:%3cEA0DB0D4-B4B7-4337-B570-441AB8715AF1@mac-com%3e 2009-12-04T23:24:40Z 
Hi Brian,

I managed to install the Pivot artifacts in a local Maven repository and successfully built
a sample project that lists them as dependencies. So, I am optimistic that the POMs are structured
correctly.

Next, I attempted to package the artifacts for manual upload as described on this page:

http://maven.apache.org/guides/mini/guide-central-repository-upload.html

The results are in this zip file, which contains one JAR per Pivot artifact:

http://ixnay.biz/pivot-bundles.zip

Would it be possible for you to take a quick look and verify that they are in the correct
format for manual upload?

If so, what would be the next steps to get them into the central repository? Is there still
a way for Apache projects to do this without needing to go through the 4-week process described
on the upload page? If not, that's OK - I'm just wondering.

(Note that the artifacts themselves are not actually ready for upload - I am just trying to
get the process worked out in anticipation of Pivot's graduation. The final artifacts for
Pivot 1.4 probably won't be ready for another few weeks.)

Thanks again for your help,
Greg


On Dec 3, 2009, at 11:27 AM, Brian Fox wrote:

> Hi Greg, I'll take a look later today and ping back on the pivot dev
> list with what I find.
> 
> On Thu, Dec 3, 2009 at 6:44 AM, Greg Brown <gkbrown@mac.com> wrote:
>> Forwarding this message to dev@maven.apache.org in case users@maven.apache.org wasn't
the right place. Also, since sending the original message, I have heard that the document
I had been referring to might be outdated.
>> 
>> Can anyone help?
>> 
>> Thanks!
>> Greg
>> 
>> Begin forwarded message:
>> 
>>> From: Greg Brown <gkbrown@mac.com>
>>> Date: December 2, 2009 12:38:13 PM EST
>>> To: users@maven.apache.org
>>> Cc: pivot-dev@incubator.apache.org
>>> Subject: Upload Apache Pivot artifacts to central repository
>>> Reply-To: pivot-dev@incubator.apache.org
>>> 
>>> Hi all,
>>> 
>>> Apache Pivot is preparing for graduation, and we would like to upload our next
set of release artifacts to the central Maven repository. We don't currently use Maven as
a build tool, so I have been trying to follow the manual upload instructions listed here:
>>> 
>>> http://www.apache.org/dev/release-publishing.html#maven-repo
>>> 
>>> There is a section at the bottom that is meant to explain how to create an appropriate
POM file, but it does not appear to be complete:
>>> 
>>> http://www.apache.org/dev/release-publishing.html#repository-descriptor
>>> 
>>> I have created some POMs that I think should work, but it would be very helpful
if someone with a knowledgeable eye could take a quick look to make sure that they contain
the correct information, are structured properly, etc. There is a root POM in the trunk, and
a POM in each project-specific subdirectory that we plan to publish to the repository (note
that these files refer to the anticipated future name and location of the project, as opposed
to its current Incubator name and location):
>>> 
>>> http://svn.apache.org/repos/asf/incubator/pivot/trunk/
>>> 
>>> Based on the documentation I have read thus far, I assume that we'll want to
place our compiled JARs in a pivot/jars directory, and structure our POMs as follows:
>>> 
>>> pivot/poms
>>>    pom.xml
>>>    /core/pom.xml
>>>    /web/pom.xml
>>>    /wtk/pom.xml
>>>    /wtk-terra/pom.xml
>>> 
>>> I don't think we'll need to use the distributions directory, and I assume that
the licenses directory should simply contain a copy of our main LICENSE file. Is this all
correct?
>>> 
>>> Also, one of our mentors, Martijn Dashorst, suggested that there might be a top-level
ASF POM that the root Pivot POM could extend (rather than duplicating the ASF info). If so,
could you point us to it?
>>> 
>>> Thanks - your assistance is very much appreciated!
>>> 
>>> Greg Brown
>>> Apache Pivot
>>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5 Brian Fox <brianf@infinity.nu> urn:uuid:%3ceb0f802d0912041508u6fff13adxee705721a3f9ee2e@mail-gmail-com%3e 2009-12-04T23:08:23Z 
On Fri, Dec 4, 2009 at 2:16 AM, Jorg Heymans <jorg.heymans@gmail.com> wrote:
> On Thu, Dec 3, 2009 at 7:44 PM, Brian Fox <brianf@infinity.nu> wrote:
>> Something like duplicate dependencies likely means you have a real
>> problem you didn't know about in your poms. I think failing is
>> appropriate in this case.
>
> I fail to grok what you just said there. So if i have in my pom
>
>    <dependency>
>      <groupId>javax.persistence</groupId>
>      <artifactId>persistence-api</artifactId>
>      <version>1.0</version>
>    </dependency>
>
> and then 25 other dependencies and then again the one above (due to a
> copy-paste oversight let's say) then I have a real problem in my build
> you say. How is it different from unused and declared dependencies, or
> used and undeclared ?

Yes that is a problem because if you later go to upgrade to 1.2,
you're most likely going to find the first instance and change it, but
you're still going to get 1.0 because last time I checked, it was last
wins. This is a hidden cancer in your pom that will bite you later.

How is it different than undeclared dependencies? It's slightly worse
because you have a false sense of security by having it specified.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Maven Changes Plugin version 2.3 Brett Porter <brett@apache.org> urn:uuid:%3c24FB8860-71D9-4A2A-BC8C-6DD0EE03B1F5@apache-org%3e 2009-12-04T22:22:10Z 
2.2.1 is recommended in the release guide now (mostly because the wagon upgrade is necessary
to work with scp).

I think we should solve the concern about building with JDK 1.4 a different way (toolchains,
and/or animal sniffer).

Cheers,
Brett

On 05/12/2009, at 7:13 AM, Dennis Lundberg wrote:

> Benjamin Bentmann wrote:
>> Dennis Lundberg wrote:
>> 
>>> This vote comes soon after the 2.2 release
>> 
>> No need to apologize ;-)
>> 
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-036/
>> 
>> The .pom.asc seems not to match the plugin POM [0]. Looking at the POM,
>> it seems as if it was deployed using Maven 2.1.0 and suffers from
>> MNG-4167/MGPG-14.
> 
> Darn, you're probably right. I must have switched to 2.1 too soon. Is
> there one recommended version of Maven that works for both for the
> deployment of artifacts and the site deployment? I'd like to stay on
> Java 1.4 when doing plugin releases.
> 
> What's the best approach to fixing the signatures? Is it possible to
> re-sign the artifacts and just upload the new signatures? If so, what
> steps would I need to take.
> 
>> 
>> 
>> Benjamin
>> 
>> 
>> [0]
>> https://repository.apache.org/content/repositories/maven-036/org/apache/maven/plugins/maven-changes-plugin/2.3/maven-changes-plugin-2.3.pom
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 
> 
> 
> -- 
> Dennis Lundberg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Maven Ant Tasks version 2.1.0 Paul Gier <pgier@redhat.com> urn:uuid:%3c4B197AF6-9070705@redhat-com%3e 2009-12-04T21:11:18Z 
Hi,

The vote has passed with the following result:

+1 (binding): Benjamin Bentmann, Jason van Zyl, Hervé Boutemy

+1 (non-binding): Paul Gier, Stephen Connolly

I will promote the artifacts to the central repository and continue with the 
release.



Paul Gier wrote:
> Hi,
> 
> I believe it's time for the next release of the Maven Ant Tasks.  This 
> release has several enhancements and bug fixes and the dependencies on 
> the core maven libraries have been updated to version 2.2.1.
> 
> I also created a download page as part of the Ant tasks site.  This will 
> allow the Ant task download links to be removed from the main Maven 
> download page.
> 
> We solved 12 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533&version=13522 
> 
> 
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+MANTTASKS+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide

> 
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-033/
> 
> Staging site (need to sync):
> http://maven.apache.org/ant-tasks-2.1.0/
> 
> SCM Tag:
> https://svn.apache.org/repos/asf/maven/ant-tasks/tags/maven-ant-tasks-2.1.0
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Maven Changes Plugin version 2.3 Lukas Theussl <ltheussl@gmail.com> urn:uuid:%3cef0f7e6d0912041225j4dd05beco84e8da5e9963d4d7@mail-gmail-com%3e 2009-12-04T20:25:06Z 
On Fri, Dec 4, 2009 at 9:13 PM, Dennis Lundberg <dennisl@apache.org> wrote:

> Benjamin Bentmann wrote:
> > Dennis Lundberg wrote:
> >
> >> This vote comes soon after the 2.2 release
> >
> > No need to apologize ;-)
> >
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-036/
> >
> > The .pom.asc seems not to match the plugin POM [0]. Looking at the POM,
> > it seems as if it was deployed using Maven 2.1.0 and suffers from
> > MNG-4167/MGPG-14.
>
> Darn, you're probably right. I must have switched to 2.1 too soon. Is
> there one recommended version of Maven that works for both for the
> deployment of artifacts and the site deployment? I'd like to stay on
> Java 1.4 when doing plugin releases.
>
> What's the best approach to fixing the signatures? Is it possible to
> re-sign the artifacts and just upload the new signatures? If so, what
> steps would I need to take.
>

I had exactly the same problem with the release of doxia 1.1.1 (
http://www.mail-archive.com/dev@maven.apache.org/msg81138.html), I sent the
correct signatures to Brian who was so nice to replace them on the staging
repo. So it is possible... :)

-Lukas



>
> >
> >
> > Benjamin
> >
> >
> > [0]
> >
> https://repository.apache.org/content/repositories/maven-036/org/apache/maven/plugins/maven-changes-plugin/2.3/maven-changes-plugin-2.3.pom
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [VOTE] Release Maven Changes Plugin version 2.3 Dennis Lundberg <dennisl@apache.org> urn:uuid:%3c4B196D70-1000304@apache-org%3e 2009-12-04T20:13:36Z 
Benjamin Bentmann wrote:
> Dennis Lundberg wrote:
> 
>> This vote comes soon after the 2.2 release
> 
> No need to apologize ;-)
> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-036/
> 
> The .pom.asc seems not to match the plugin POM [0]. Looking at the POM,
> it seems as if it was deployed using Maven 2.1.0 and suffers from
> MNG-4167/MGPG-14.

Darn, you're probably right. I must have switched to 2.1 too soon. Is
there one recommended version of Maven that works for both for the
deployment of artifacts and the site deployment? I'd like to stay on
Java 1.4 when doing plugin releases.

What's the best approach to fixing the signatures? Is it possible to
re-sign the artifacts and just upload the new signatures? If so, what
steps would I need to take.

> 
> 
> Benjamin
> 
> 
> [0]
> https://repository.apache.org/content/repositories/maven-036/org/apache/maven/plugins/maven-changes-plugin/2.3/maven-changes-plugin-2.3.pom
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
MNG-4479 updated with reproducible test case Laird Nelson <ljnelson@gmail.com> urn:uuid:%3c2c0ebf0c0912040932y1854117fn6fcc4f59916cb306@mail-gmail-com%3e 2009-12-04T17:32:46Z 
Hello; a quick note to say that I've updated
http://jira.codehaus.org/browse/MNG-4479 with a set of projects that
reliably reproduce the (IMHO major) issue.

Best,
Laird
Re: [VOTE] Release Apache Maven 3.0-alpha-5 Jorg Heymans <jorg.heymans@gmail.com> urn:uuid:%3c132770720912040016od319fd9v736c6c5d9c705f64@mail-gmail-com%3e 2009-12-04T08:16:07Z 
On Thu, Dec 3, 2009 at 7:44 PM, Brian Fox <brianf@infinity.nu> wrote:
> Something like duplicate dependencies likely means you have a real
> problem you didn't know about in your poms. I think failing is
> appropriate in this case.

I fail to grok what you just said there. So if i have in my pom

    <dependency>
      <groupId>javax.persistence</groupId>
      <artifactId>persistence-api</artifactId>
      <version>1.0</version>
    </dependency>

and then 25 other dependencies and then again the one above (due to a
copy-paste oversight let's say) then I have a real problem in my build
you say. How is it different from unused and declared dependencies, or
used and undeclared ? For me these all fit in the same boat ie
'potential build optimizations'

Jorg

PS how about a dependency:scan-duplicates then ?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Subscription: Design & Best Practices jira@codehaus.org urn:uuid:%3c19575561-26064-1259898115285-JavaMail-haus-jira@codehaus01-managed-contegix-com%3e 2009-12-04T03:41:55Z 
Issue Subscription
Filter: Design & Best Practices (28 issues)
Subscriber: mavendevlist
        
Key         Summary
MNG-2184    Possible problem with @aggregator and forked lifecycles
            http://jira.codehaus.org/browse/MNG-2184
MNG-612     implement conflict resolution techniques
            http://jira.codehaus.org/browse/MNG-612
MNG-2584    Rebuild on pom change
            http://jira.codehaus.org/browse/MNG-2584
MNG-139     server definitions should be reusable - review use of repository IDs
            http://jira.codehaus.org/browse/MNG-139
MNG-2125    [doc] when and how to define plugins in a pom
            http://jira.codehaus.org/browse/MNG-2125
MNG-474     performance improvement for forked lifecycles
            http://jira.codehaus.org/browse/MNG-474
MNG-1381    best practices: testing strategies
            http://jira.codehaus.org/browse/MNG-1381
MNG-1563    how to write integration tests
            http://jira.codehaus.org/browse/MNG-1563
MNG-2381    improved control over the repositories in the POM
            http://jira.codehaus.org/browse/MNG-2381
MNG-1950    Ability to introduce new lifecycles phases
            http://jira.codehaus.org/browse/MNG-1950
MNG-1931    add a reportingManagement section
            http://jira.codehaus.org/browse/MNG-1931
MNG-1468    best practices: version management in multi project builds
            http://jira.codehaus.org/browse/MNG-1468
MNG-1885    Uniquely identify modules by module name and version number
            http://jira.codehaus.org/browse/MNG-1885
MNG-647     Allow Maven 2 to be monitored using JMX.
            http://jira.codehaus.org/browse/MNG-647
MNG-416     best practices:  multiple profile deployments
            http://jira.codehaus.org/browse/MNG-416
MNG-367     best practices: multi-user installation
            http://jira.codehaus.org/browse/MNG-367
MNG-125     guarded mojo execution
            http://jira.codehaus.org/browse/MNG-125
MNG-1569    Make build process info read-only to mojos, and provide mechanism for explicit
out-params for mojos to declare
            http://jira.codehaus.org/browse/MNG-1569
MNG-41      best practices: site management
            http://jira.codehaus.org/browse/MNG-41
MNG-657     possible chicken and egg problem with extensions
            http://jira.codehaus.org/browse/MNG-657
MNG-1867    deprecate system scope, analyse other use cases
            http://jira.codehaus.org/browse/MNG-1867
MNG-1441    Starting thinking about a proper distributed repository mechanism a la CPAN
            http://jira.codehaus.org/browse/MNG-1441
MNG-868     Use uniform format for <properties> and other tags
            http://jira.codehaus.org/browse/MNG-868
MNG-1423    best practices: setting up multi-module build
            http://jira.codehaus.org/browse/MNG-1423
MNG-1439    Organization Object Model (OOM) 
            http://jira.codehaus.org/browse/MNG-1439
MNG-1440    Developer Object Model (DOM)
            http://jira.codehaus.org/browse/MNG-1440
MNG-1463    best practices: plugin inheritance for a multi project build
            http://jira.codehaus.org/browse/MNG-1463
MNG-1425    best practices: the location of configuration files vs resources
            http://jira.codehaus.org/browse/MNG-1425

You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Maven Changes Plugin version 2.3 Benjamin Bentmann <benjamin.bentmann@udo.edu> urn:uuid:%3c4B183A41-8020406@udo-edu%3e 2009-12-03T22:22:57Z 
Dennis Lundberg wrote:

> This vote comes soon after the 2.2 release

No need to apologize ;-)

> Staging repo:
> https://repository.apache.org/content/repositories/maven-036/

The .pom.asc seems not to match the plugin POM [0]. Looking at the POM, 
it seems as if it was deployed using Maven 2.1.0 and suffers from 
MNG-4167/MGPG-14.


Benjamin


[0] 
https://repository.apache.org/content/repositories/maven-036/org/apache/maven/plugins/maven-changes-plugin/2.3/maven-changes-plugin-2.3.pom

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Upload Apache Pivot artifacts to central repository? Greg Brown <gkbrown@mac.com> urn:uuid:%3cC481968F-AEB5-4044-BBCF-4019CD053D25@mac-com%3e 2009-12-03T21:43:34Z 
Great, thanks!

On Dec 3, 2009, at 11:27 AM, Brian Fox wrote:

> Hi Greg, I'll take a look later today and ping back on the pivot dev
> list with what I find.
> 
> On Thu, Dec 3, 2009 at 6:44 AM, Greg Brown <gkbrown@mac.com> wrote:
>> Forwarding this message to dev@maven.apache.org in case users@maven.apache.org wasn't
the right place. Also, since sending the original message, I have heard that the document
I had been referring to might be outdated.
>> 
>> Can anyone help?
>> 
>> Thanks!
>> Greg
>> 
>> Begin forwarded message:
>> 
>>> From: Greg Brown <gkbrown@mac.com>
>>> Date: December 2, 2009 12:38:13 PM EST
>>> To: users@maven.apache.org
>>> Cc: pivot-dev@incubator.apache.org
>>> Subject: Upload Apache Pivot artifacts to central repository
>>> Reply-To: pivot-dev@incubator.apache.org
>>> 
>>> Hi all,
>>> 
>>> Apache Pivot is preparing for graduation, and we would like to upload our next
set of release artifacts to the central Maven repository. We don't currently use Maven as
a build tool, so I have been trying to follow the manual upload instructions listed here:
>>> 
>>> http://www.apache.org/dev/release-publishing.html#maven-repo
>>> 
>>> There is a section at the bottom that is meant to explain how to create an appropriate
POM file, but it does not appear to be complete:
>>> 
>>> http://www.apache.org/dev/release-publishing.html#repository-descriptor
>>> 
>>> I have created some POMs that I think should work, but it would be very helpful
if someone with a knowledgeable eye could take a quick look to make sure that they contain
the correct information, are structured properly, etc. There is a root POM in the trunk, and
a POM in each project-specific subdirectory that we plan to publish to the repository (note
that these files refer to the anticipated future name and location of the project, as opposed
to its current Incubator name and location):
>>> 
>>> http://svn.apache.org/repos/asf/incubator/pivot/trunk/
>>> 
>>> Based on the documentation I have read thus far, I assume that we'll want to
place our compiled JARs in a pivot/jars directory, and structure our POMs as follows:
>>> 
>>> pivot/poms
>>>    pom.xml
>>>    /core/pom.xml
>>>    /web/pom.xml
>>>    /wtk/pom.xml
>>>    /wtk-terra/pom.xml
>>> 
>>> I don't think we'll need to use the distributions directory, and I assume that
the licenses directory should simply contain a copy of our main LICENSE file. Is this all
correct?
>>> 
>>> Also, one of our mentors, Martijn Dashorst, suggested that there might be a top-level
ASF POM that the root Pivot POM could extend (rather than duplicating the ASF info). If so,
could you point us to it?
>>> 
>>> Thanks - your assistance is very much appreciated!
>>> 
>>> Greg Brown
>>> Apache Pivot
>>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Maven Doxia and Maven Doxia Site Tools version 1.1.2 Paul Benedict <pbenedict@apache.org> urn:uuid:%3cb9e663070912031109w4db66f12o9a272f82f1f5a9a0@mail-gmail-com%3e 2009-12-03T19:09:44Z 
+1 looks good.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Release Maven Doxia and Maven Doxia Site Tools version 1.1.2 Dennis Lundberg <dennisl@apache.org> urn:uuid:%3c4B180C7D-4040602@apache-org%3e 2009-12-03T19:07:41Z 
+1

Vincent Siveton wrote:
> Hi,
> 
> Following Dennis to get Maven Site Plugin 2.1 (we hope for Xmas), here
> is the release of Doxia 1.1.2.
> 
> We solved around 20 issues for both:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780&styleName=Html&version=15517
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624&styleName=Html&version=15518
> 
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10780&status=1
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11624&status=1
> 
> Staging repos:
> https://repository.apache.org/content/repositories/maven-027/
> 
> Staging sites (need to sync):
> http://maven.apache.org/doxia/doxia-1.1.2
> http://maven.apache.org/doxia/doxia-sitetools-1.1.2
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org