Re: [DISCUSS] Automatically format and sort imports

[Jeff Jensen]

I think reformatting files during every build is less desirable and adds
risk.  I prefer the build to *enforce* the desired results, failing as
needed, and configuring the IDEs to auto-format the files on save.  Both
Eclipse and IntelliJ have many configurable "save actions" for file format
and cleanup options (e.g. organize imports, remove unused imports, remove
trailing spaces, add 'final' where possible, convert loops, etc.).

This approach formats files earliest possible (at save time), the developer
sees the formatting before commit, prevents the build from changing
non-generated source files (risk), eliminates a build step, and eliminates
a "new commit of non-developer changed files" issue.

The challenge is still everyone using the same formatter settings and
everyone configuring "save actions"...  Improving the "code style enforcing
rules" (e.g. Checkstyle) and failing the build will "encourage" developers
to setup their IDE well for this.


On Thu, Oct 13, 2022 at 5:50 AM Olivier Lamy  wrote:

> On Thu, 13 Oct 2022 at 17:47, Tamás Cservenák  wrote:
> >
> > Howdy,
> >
> > to not get lost in implementation details, it is really unimportant
> > (spotless, this or that...)
> >
> > What IS important is that we agree to implement "IDE agnostic source
> > formatting", that happens during build
> > (by maven plugin). This means _everyone_ will end up with 100% the same
> > result.
> >
> > The only thing that comes to my mind is "sloppy committer" who does not
> > build but pushes
>
> not sure to understand. You mean formatting sources will be bind to a
> phase and be executed automatically?
>
> Wouldn’t it be better to still have a check as today (checkstyle:check
> or the used foo-bar-formatter-plugin:check) which checks the sources
> at validate phase.
> Then in case of failure, the committer can just run
> foo-bar-formatted-plugin:format.
> So committer can apply some manual changes as well.
> this will detect "sloppy" committer as today by simply failing without
> adding another plugin running some scm command during the build.
>
> > Is there some option to have a profile (activated on CI) that detects
> there
> > are "uncommitted changes" post build?
> > As that would mean that sourcetree contains sources NOT formatted, and
> that
> > CI build did reformat them...
> >
> > But even without this step mitigation is simple: someone just rebuilds
> HEAD
> > and commits...
> >
> > Thanks
> > T
> >
> > On Thu, Oct 13, 2022 at 8:41 AM Tamás Cservenák 
> wrote:
> >
> > > Formatting happens during build, so once merged all we need is to merge
> > > master into PR branches...
> > >
> > > T
> > >
> > > On Thu, Oct 13, 2022 at 8:40 AM Sylwester Lachiewicz <
> > > slachiew...@gmail.com> wrote:
> > >
> > >> What about already open PR with some features or bug fixes.
> > >> Don't we should review and merge it before reformatting code -
> otherwise
> > >> we
> > >> will have lots of merge conflicts and over time no one will have
> energy to
> > >> review it?
> > >>
> > >> Sylwester
> > >>
> > >> śr., 12 paź 2022, 18:23 użytkownik Guillaume Nodet  >
> > >> napisał:
> > >>
> > >> > I'd like to propose merging the following PRs:
> > >> >  * https://github.com/apache/maven-shared-resources/pull/1
> > >> >  * https://github.com/apache/maven-site/pull/329
> > >> >  * https://github.com/apache/maven/pull/824
> > >> >  * https://github.com/apache/maven-resolver/pull/147
> > >> > ... and more to come
> > >> >
> > >> > The idea is to use plugins to automatically reformat the source
> code and
> > >> > sort imports to obey the maven coding style.
> > >> > The first PR adds the necessary resources to maven-shared-resources
> : a
> > >> new
> > >> > header file, as there's a requirement to put the header at the very
> > >> > beginning for the import sorter plugin to work correctly (else it
> > >> considers
> > >> > the license comment to be part of comment headers and screws the
> > >> > formatting), and the eclipse xml formatter plugin.
> > >> > The second PR updates the web site to point to that file which
> would be
> > >> in
> > >> > git instead of on the maven web site, and also updates the
> instruction
> > >> for
> > >> > IDEA since it has been supporting the eclipse xml config for years
> now).
> > >> > The third and fourth PRs are updates on maven and maven-resolver to
> > >> apply
> > >> > those two plugins.
> > >> >
> > >> > Those plugins have been used on mvnd and maven-build-cache-extension
> > >> > already, although they are not using a single shared resource that
> > >> would be
> > >> > added by the first PR.  Hence mvnd is still using its previous
> coding
> > >> > style.
> > >> >
> > >> > Another point is that those plugins are fast and only do not process
> > >> files
> > >> > if they have been already processed and untouched since the last
> > >> build.  So
> > >> > from a daily development pov, this is transparent and does not
> incur any
> > >> > additional processing time during the build (or not much 

Re: Maven Release Plugin 3.0.0-M6

[Jeff Jensen]

M is for Milestone, an incremental release towards the eventual final
release considered early production ready but incomplete for full planned
features and implementation.


On Tue, Apr 26, 2022 at 2:10 PM Gary Gregory  wrote:

> Can someone explain the M release meaning? Is it an alpha release? A beta
> version? Is it production ready? Does it depend on the plugin (please say
> no)?
>
> Gary
>
> On Tue, Apr 26, 2022, 07:49 Samuel Le Berrigaud 
> wrote:
>
> > Hello devs,
> >
> > I'd just like to get an idea of when a potential 3.0.0-M6 of the
> > maven-release-plugin might happen.
> >
> > I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
> > quick PR & merge. And now, obviously, I would love to be able to use a
> > regular build of the plugin.
> >
> > Thanks for your help,
> > SaM
> >
> > (1) https://issues.apache.org/jira/browse/MRELEASE-1022
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSS] Move maven caching to an external repository

[Jeff Jensen]

I've split git repos before and using filter-branch is the key to keep the
desired and purge the rest.

>From my notes, these two posts helped me:
*
https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository
*
https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in-two/

These are my shortcut notes for doing so, hope they are clear enough for
you and help. In a new repo, locally convert a current source subdirectory
to the root directory and purge everything else; then push to remote and
locally cleanup:

   1.

   Make directory for new repo from current repo:

git clone current-repo to-new-directory

   1.

   Disconnect from current remote immediately to prevent catastrophe and
   verify none set

git remote rm origin

git remote -v

   1.

   Keep desired dir and move it to top level, remove the rest
   1.

  FOLDER-NAME: which one to keep and move to top level
  2.

  BRANCH-NAME: which branch to do this on (must exist, e.g. master)

git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
BRANCH-NAME

   1.

   Setup remote repo and verify set

git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git


git remote -v

   1.

   Push to new repo

git push -u origin BRANCH-NAME

   1.

   Further cleanup: delete all tags (locally only (Powershell))

git tag | foreach-object -process { git tag -d $_ }

   1.

   Further cleanup: remove local unreachable/recyclable commits (remnants
   of prior)

git reflog expire --expire-unreachable=now --all

git gc --prune=now


On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY  wrote:

> nice work done
> I published the result to https://maven.apache.org/ref/caching-LATEST/
>
> now, on moving source to a separate Git repository, I did a basic test
> pushing
> to a new repository:
> https://github.com/hboutemy/maven-build-cache-extension
>
> this leads to getting quite a lot of Maven history
>
> I'm not a Git wizard: is there a way to cut down the history to keep only
> the
> interesting part when the build cache code donation was done?
>
> Regards,
>
> Hervé
>
> Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY  a
> écrit :
> > > we have most plugins that are simple with only 1 mono-module build
> > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > see https://maven.apache.org/components/plugins/ for full list
> > >
> > > we have a few components that have a plugin as part of a larger
> > > multi-module
> > > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > > release, and
> > > soon wrapper
> > >
> > > And from experience, it makes documentation harder because there is
> always
> > > the
> > > question of what to write in the plugin pages and what to write in
> other
> > > modules. Not talking of navigation from /plugins/maven-xxx-plugin to
> /xxx/
> > > maven-xxx-plugin (we have a trick for redirecting...)
> > >
> > > In caching case, I see that there is only one submodule, that is done
> for
> > > ITs
> > > with Surefire: is it necessary? isn't maven-invoker-plugin usable, like
> > > for
> > > plugins?
> >
> > Yes, that's actually a good point.  I thought about that when I read
> Tamás
> > answer.  I'll double check if the integration tests can be merged into a
> > single module.
> >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > > I think the repository name should not contain 'extension', similar
> to
> > > > surefire which provides a plugin, but it a bit more complex
> > > > The fact that it is provided as an extension is a technicality in
> this
> > >
> > > case
> > >
> > > > imho.
> > > > No big deal though...
> > > >
> > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák  a
> > >
> > > écrit :
> > > > > Howdy,
> > > > >
> > > > > I'd rather group ASF extensions (are there any existing ones aside
> of
> > > > > caching?),
> > > > > to be clear... so GH repo could be something like
> > > > > apache/maven-caching-extension
> > > > > apache/maven-foobar-extension
> > > > > etc?
> > > > >
> > > > > T
> > > > >
> > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet 
> > >
> > > wrote:
> > > > > > Following the recent work done to integrate the maven caching /
> > > > >
> > > > > incremental
> > > > >
> > > > > > build system into maven, I think it's now time to discuss where
> we
> > >
> > > want
> > >
> > > > > its
> > > > >
> > > > > > long-term location to be.
> > > > > >
> > > > > > This extension was donated a few months ago and provides local
> and
> > > > > > remote
> > > > > > caching of maven project's output, based on computed hashes of
> the
> > > > >
> > > > > inputs.
> > > > >
> > > > > > It's defined as a maven extension and can be used as a core or
> build
> > > > > > extension.  This avoids building the project and speeds up
> builds a
> > >
> > > lot
> > 

Re: Speed of Maven build

[Jeff Jensen]

In case this helps, Jason Dillon has a "Maven Shell" that does what you
seek for CLI - launches a Maven instance and runs interactive commands with
it, saving the startup time.
https://github.com/jdillon/mvnsh


On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach 
wrote:

> > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > I suppose that community would be happy to get such contributions.
> >
> > -Bertrand
>
> You are right, Bertrand. Why not ask!
>
> Hello Maven guys,
> we had a discussion on the NetBeans mailing list recently and here is a
> summary:
> * Apache NetBeans IDE is delegating most of its work directly to Maven
> * Users however complain that the speed isn't great
> * One of the ideas was to launch a "zombie" instance of Maven in advance
> * then actions like build, exec or test would be faster
>
> Have you thought about something like this already? Any advices?
>
> Best regards.
> Jaroslav Tulach
> NetBeans Platform Architect
>
> ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
> jaroslav.tul...@gmail.com>
> napsal:
>
> > > I agree with others, Ant is much faster day to day. But the pom.xml has
> > > become the universal project file for Java,
> >
> > Thank you all for sharing your thoughts. I know Maven start is slower,
> but
> > I
> > learned to live with it. It is interesting to hear that some of you
> > maintain a
> > dual Ant based copy of your project metadata. Once we were trying a
> > different
> > approach:
> >
> > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > XML &
> > co. files and stop it. As soon as we need to build/run/test, wake up this
> > zombie Maven process, tell it what to do and let it continue. If the XML
> > files
> > are modified, throw the process away and initialize it again. Tomáš
> Stupka
> > implemented a prototype of this and there were no issues, as far as I
> know
> > (nobody tested it thoroughly however).
> >
> > Maybe the support is even in and there is a property to turn it on. If
> the
> > Maven startup is the biggest problem for you guys, we shall investigate
> > how to
> > turn Tomáš's work on...
> >
> > -jt
> >
> >
> >
> >
> >
> >
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.20.1

[Jeff Jensen]

 Thanks for the link Tibor (didn't know there was an open infra issue you
were working on).  Based on that JIRA comment, they have done what I was
suggesting for Windows line lengths.

> The error message is Caused by: java.io.IOException: CreateProcess
error=5, Access is denied
Yes, need to find the "Access is denied" cause.  I looked at the log and
posted a couple of initial thoughts on the ticket.


On Sat, Mar 17, 2018 at 12:48 PM, Tibor Digana <tibordig...@apache.org>
wrote:

> Hi Jeff,
>
> The entire problem is when trying to run a forked sub-process via
> ProcessBuilder.start().
> The error message is
> Caused by: java.io.IOException: CreateProcess error=5, Access is denied
>
> I found a sort of similar issue reported for Java 9 as well:
> https://bugs.openjdk.java.net/browse/JDK-8168275
>
> Cheers
> Tibor
>
> On Sat, Mar 17, 2018 at 6:12 PM, Tibor Digana <tibordig...@apache.org>
> wrote:
>
>> Hi Jeff,
>>
>> I am not an expert for Windows internals. Here is the statement [1] given
>> by our INFRA team. Do you think they performed same setting you have
>> proposed?
>> If it is different, you can maybe reply on JIRA and give them the hint.
>> [1]:
>> https://issues.apache.org/jira/browse/INFRA-16191?focusedCom
>> mentId=16402016=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-16402016
>>
>> We do not have long paths in Git repo hopefully. The situation is that we
>> copy some sources to a newly created folder in runtime:
>> surefire-its/target//src/main/java/...
>>
>> Then this exceeds the length. The copy is done by Java process JDK 1.8.
>>
>> Cheers
>> Tibor
>>
>>
>>
>>
>>
>> On Sat, Mar 17, 2018 at 5:52 PM, Jeff Jensen <
>> jeffjen...@upstairstechnology.com> wrote:
>>
>>> Hi Tibor,
>>>
>>> > I should maybe write some limitations regarding length of IT
>>> class/method/package and length of Git branch name in README.md due to
>>> problems with Windows paths length.
>>>
>>> In case this helps: instead of shortening names for the Windows path
>>> length
>>> limitation, we can configure Windows and Git:
>>>
>>> 1. For recent Windows versions, set this to 1 (0 is
>>> disabled): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSyst
>>> em
>>> -> LongPathsEnabled
>>>
>>> 2.  git config --global core.longpaths true
>>>   Caveat per git doc and mitigated with step 1:
>>>
>>> Enable long path (> 260) support for builtin commands in Git for Windows.
>>> This is disabled by default, as long paths are not supported by Windows
>>> Explorer, cmd.exe and the Git for Windows tool chain (msys, bash, tcl,
>>> perl…​). Only enable this if you know what you’re doing and are prepared
>>> to
>>> live with a few quirks.
>>>
>>> On Sat, Mar 17, 2018 at 11:12 AM, Tibor Digana <tibordig...@apache.org>
>>> wrote:
>>>
>>> > I will push the Jira 1490 first.
>>> > Sorry it took some time. Last days we solved issues INFRA-16168 and
>>> > INFRA-16191.
>>> > I should maybe write some limitations regarding length of IT
>>> > class/method/package and length of Git branch name in README.md due to
>>> > problems with Windows paths length.
>>> >
>>> > On Fri, Mar 9, 2018 at 11:12 AM, Enrico Olivelli <eolive...@gmail.com>
>>> > wrote:
>>> >
>>> > > 2018-03-09 9:55 GMT+01:00 Tibor Digana <tibordig...@apache.org>:
>>> > >
>>> > > > Hi Enrico, Karl, Herve,
>>> > > >
>>> > > > We reported the issues [1] found during the Vote. They are fixed in
>>> > > > branches [2] and CI builds [3].
>>> > > > We can make a code review.
>>> > > > Additionally, we fixed SUREFIRE-1490 which was in progress but we
>>> did
>>> > not
>>> > > > have spare time to include it in the Release 2.21.0. Now it is
>>> fixed in
>>> > > [4].
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > > Thank you Tibor,
>>> > > I did not have time to create issues yet and you already have
>>> resolved
>>> > them
>>> > > !!
>>> > >
>>> > > I can confirm that I am now using 2.21.0 and I am really happy with
>>> it.
>>> > >
>>> > > I have r

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.20.1

[Jeff Jensen]

Hi Tibor,

> I should maybe write some limitations regarding length of IT
class/method/package and length of Git branch name in README.md due to
problems with Windows paths length.

In case this helps: instead of shortening names for the Windows path length
limitation, we can configure Windows and Git:

1. For recent Windows versions, set this to 1 (0 is
disabled): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
-> LongPathsEnabled

2.  git config --global core.longpaths true
  Caveat per git doc and mitigated with step 1:

Enable long path (> 260) support for builtin commands in Git for Windows.
This is disabled by default, as long paths are not supported by Windows
Explorer, cmd.exe and the Git for Windows tool chain (msys, bash, tcl,
perl…​). Only enable this if you know what you’re doing and are prepared to
live with a few quirks.

On Sat, Mar 17, 2018 at 11:12 AM, Tibor Digana 
wrote:

> I will push the Jira 1490 first.
> Sorry it took some time. Last days we solved issues INFRA-16168 and
> INFRA-16191.
> I should maybe write some limitations regarding length of IT
> class/method/package and length of Git branch name in README.md due to
> problems with Windows paths length.
>
> On Fri, Mar 9, 2018 at 11:12 AM, Enrico Olivelli 
> wrote:
>
> > 2018-03-09 9:55 GMT+01:00 Tibor Digana :
> >
> > > Hi Enrico, Karl, Herve,
> > >
> > > We reported the issues [1] found during the Vote. They are fixed in
> > > branches [2] and CI builds [3].
> > > We can make a code review.
> > > Additionally, we fixed SUREFIRE-1490 which was in progress but we did
> not
> > > have spare time to include it in the Release 2.21.0. Now it is fixed in
> > [4].
> > >
> >
> >
> >
> > Thank you Tibor,
> > I did not have time to create issues yet and you already have resolved
> them
> > !!
> >
> > I can confirm that I am now using 2.21.0 and I am really happy with it.
> >
> > I have reviewed your commits and they looks good to me,
> > today I do not have time to test your fixes on my "real" projects but
> > surely I will do it next week, I guess we will not release 3.0.0M1
> > immediately
> >
> > Cheers
> > Enrico
> >
> >
> >
> > >
> > > [1]:
> > > https://issues.apache.org/jira/browse/SUREFIRE-1495
> > > https://issues.apache.org/jira/browse/SUREFIRE-1498
> > >
> > > [2]:
> > > https://git1-us-west.apache.org/repos/asf?p=maven-
> > surefire.git;a=commit;h=
> > > c496ebf3b4518c25787d5eac9f54b2a220a59447
> > > https://git1-us-west.apache.org/repos/asf?p=maven-
> > surefire.git;a=commit;h=
> > > af7ae9ef933873a038b2817d6430859f2a5bd1c7
> > >
> > > [3]:
> > > https://builds.apache.org/job/maven-wip/job/maven-surefire/
> > > job/SUREFIRE-1495/4/
> > > https://builds.apache.org/job/maven-wip/job/maven-surefire/
> > > job/SUREFIRE-1498/1/
> > >
> > > [4]:
> > > https://issues.apache.org/jira/browse/SUREFIRE-1490
> > > https://git1-us-west.apache.org/repos/asf?p=maven-
> > surefire.git;a=commit;h=
> > > 6174be76f52ffc2873a18a5215f60767843d7479
> > > https://builds.apache.org/job/maven-wip/job/maven-surefire/
> > > job/SUREFIRE-1490/2/
> > >
> > > Cheers
> > > Tibor
> > >
> > >
> > > On Tue, Mar 6, 2018 at 5:33 PM, Tibor Digana 
> > > wrote:
> > >
> > >> Hello Gary, yes but my typo was corrected in the second e-mail.
> > >>
> > >> On Tue, Mar 6, 2018 at 5:16 PM, Gary Gregory 
> > >> wrote:
> > >>
> > >>> This thread has the wrong VERSION in its subject.
> > >>>
> > >>> Gary
> > >>>
> > >>> On Sat, Mar 3, 2018 at 4:42 AM, Tibor Digana  >
> > >>> wrote:
> > >>>
> > >>> > Hi,
> > >>> >
> > >>> > We solved 33 issues:
> > >>> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > >>> > projectId=12317927=12341630
> > >>> >
> > >>> > There are still a couple of issues left in JIRA:
> > >>> > https://issues.apache.org/jira/i#issues/?jql=project+%
> > >>> > 3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
> > >>> >
> > >>> > Staging repo:
> > >>> > https://repository.apache.org/content/repositories/maven-1402/
> > >>> > https://repository.apache.org/content/repositories/maven-
> > >>> > 1402/org/apache/maven/surefire/surefire/2.21.0/
> > surefire-2.21.0-source-
> > >>> > release.zip
> > >>> >
> > >>> > Source release checksum(s):
> > >>> > surefire-2.21.0-source-release.zip sha1:
> > >>> > 6927024eefa0b8c80dee70efa014f1f421d7844b
> > >>> >
> > >>> > Staging site:
> > >>> > http://maven.apache.org/surefire-archives/surefire-LATEST/
> > >>> >
> > >>> > Guide to testing staged releases:
> > >>> > http://maven.apache.org/guides/development/guide-
> > testing-releases.html
> > >>> >
> > >>> > Vote open for 72 hours.
> > >>> >
> > >>> > [ ] +1
> > >>> > [ ] +0
> > >>> > [ ] -1
> > >>> >
> > >>> > Cheers
> > >>> > Tibor
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Jeff Jensen]

> The date of the commit is not the date it got committed to master, but the
date it got committed to some branch, no longer existing after the commit.
If this is the way GIT works, so be it. I just don't like it. It could not
be more confusing.

A couple of thoughts in case they help you.

1. Git has "author date" and "commit date" for each commit.
* author date is the original date of the first commit, never changes.
* commit date is the last time the commit was modified (e.g. amended,
committed to a branch).
Each date is useful, depending on the situation investigating.

To help with the date displays, which git client(s) do you use?
  * For SourceTree (free git UI client from Atlassian), it has a "Display
author date instead of commit date in log" config option.  It will also
show both dates in the commit details.

  * For CLI, use the log command's "pretty formatter" (use "git help log"
for lots of details in the "pretty formats" section).  e.g. "git log
--pretty=fuller" shows both author and commit dates (and authors).

2. DeepGit is a free tool that helps with tracing commits.  You may
appreciate it: http://www.syntevo.com/deepgit/
The same company also creates the git UI client "SmartGit", which is free
for non-commercial use.  You may appreciate using it or SourceTree.


Please ask for more git help if you like.  Many people on the list know it
well, and happy to help your productivity.
(I appreciate the issues you find and fix!)


On Mon, Mar 13, 2017 at 6:49 PM, Christian Schulte  wrote:

> Am 03/11/17 um 22:56 schrieb Stephen Connolly:
> > Hi all,
> >
> > I think it is a good thing if we take stock of where we are and how we
> are
> > doing. I would really appreciate if everyone could take a few minutes to
> > respond with their top three of two areas:
> >
> > * What is working well
>
> The Jenkins support has improved greatly. For me it's very cool to have
> the ITs run on Java 7+8 - Linux+Windows. Too few operating systems.
> Solaris is a must have. OS X would be nice to have. FreeBSD or OpenBSD
> also nice to have.
>
> > * What is not working well
>
> Turns out I just will never become a GIT fan. What works best for me has
> been Subversion on the server and GIT locally using git-svn. Very clean
> history on the Subversion server side because you can clean up commits
> locally (squash, reword, etc.) before committing to the Subversion
> repository. I find it quite hard to follow the commit history in GIT.
> The date of the commit is not the date it got committed to master, but
> the date it got committed to some branch, no longer existing after the
> commit. If this is the way GIT works, so be it. I just don't like it. It
> could not be more confusing.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Jeff Jensen]

> This is not something that the user should be able to control directly

Makes sense, since this only affects plugins, to not expect or enable user
control of this feature.
Thank you for explaining.

(I also do not prefer a CLI switch for this due to the "reproducible
builds" issue, and prefer a source controlled setting, which a pom change
is a solution; I also agree we don't want that requirement nor is it needed
to allow users to change it.)


On Mon, Dec 26, 2016 at 2:07 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Well a command line switch is useless imho.
>
> Suppose I have a multi-module reactor and one module uses version A of
> plugin X and another module uses version B.
>
> Now A was built against Maven 3.3.3 and the classpath was "fixed" with
> tweaks and hacks to ensure the transitive dependencies worked out correctly
> (yes they should have filed a bug rather than work around, but life)
>
> B was built against Maven 3.4.0 and all the hacks were removed.
>
> How can we build that reactor with a command line switch? We cannot. The
> CLI switch would force with A or B to be wrong.
>
> We need something that works the way users expect *without* requiring that
> they change their poms
>
> (If we have no solution available other than "you have to change your poms"
> then we need to do that, but first priority is not to force users to change
> their poms)
>
> So prerequisites comes into play because it defines the minimum version of
> Maven that the plugin works with.
>
> I am presuming that Maven 2.x did not have this issue. I suspect, perhaps
> Maven 3.0.x did not have it either... it would be good to get some history
> if the behaviour. (If it turns out that maven 2.x behaves the same as 3.3.9
> in this regard then really the bug is the Java docs)
>
> If you are a plugin developer, and you mark your plugin as compatible with
> Maven 2.2.1+ (which is what 'prerequisites' does... you do know that field
> is *only* applicable to plugins!) we have to assume you tested on Maven
> 2.2.1, and you should thus have git a 2.2.1 classpath. If that is not the
> same as a 3.3.9 classpath... boom that is a bug in 3.3.9 and it is
> perfectly legitimate for 3.4.0 to provide the plugin with the classpath it
> would get with Maven 2.2.1 (which may even be different from 3.4.0)
>
> This is not something that the user should be able to control directly
> IMHO. Adding knobs to tweak the behaviour just complicates things for
> users.
>
> We should look at the prerequisites of the plugin and give it the correct
> classpath for that Maven version (and eg this could include adding in Maven
> compat for anything pre-3.4.0, aether shims, sonatype shims, etc, mapping
> plexus utils etc)
>
> If the user finds bugs they can either upgrade/roll back the plugin or
> upgrade/roll back Maven and we update our mapping layer for the 3.4.1
> release and move forward.
>
> Adding 1000 command line options is not the right answer.
>
> It seems we got lucky here with it only affecting plugins... so we can use
> our luck as a get out of jail free card and use the plugins advertised
> minimum Maven version requirement to control the resolution strategy for
> each plugin.
> On Mon 26 Dec 2016 at 18:54, Jeff Jensen <jjen...@apache.org> wrote:
>
> > I find the prerequisites idea very intriguing.  However, does that mean
> >
> > it's automatic behavior and no way for user to control it?
> >
> > (For user to control it, in addition to normal docs, I expect release
> notes
> >
> > describing the issue (e.g. links to JIRA) and how to enable/disable the
> new
> >
> > breaking feature or breaking fix (e.g. POM element or property)).
> >
> >
> >
> >
> >
> > BTW Christian, I admire your work and tenacity on this fix.  While I
> >
> > understand the "main line development" pattern and what you intended, I
> >
> > also think it should have been on a branch with some commits squashed
> (and
> >
> > full tests run before pushing).
> >
> >
> >
> >
> >
> > On Mon, Dec 26, 2016 at 12:29 PM, Stephen Connolly <
> >
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >
> >
> > > Rather than a CLI switch can we use the plugin prerequisites to control
> > the
> >
> > > behaviour?
> >
> > >
> >
> > > If prerequisites is < 3.0 or >= 3.4 then apply the fix otherwise
> > replicate
> >
> > > the bug.
> >
> > >
> >
> > > That way if the plugin was built and te

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Jeff Jensen]

I find the prerequisites idea very intriguing.  However, does that mean
it's automatic behavior and no way for user to control it?
(For user to control it, in addition to normal docs, I expect release notes
describing the issue (e.g. links to JIRA) and how to enable/disable the new
breaking feature or breaking fix (e.g. POM element or property)).


BTW Christian, I admire your work and tenacity on this fix.  While I
understand the "main line development" pattern and what you intended, I
also think it should have been on a branch with some commits squashed (and
full tests run before pushing).


On Mon, Dec 26, 2016 at 12:29 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Rather than a CLI switch can we use the plugin prerequisites to control the
> behaviour?
>
> If prerequisites is < 3.0 or >= 3.4 then apply the fix otherwise replicate
> the bug.
>
> That way if the plugin was built and tested against 2.x (which presumably
> doesn't have the bug) or against 3.4+ you get the. Ore than behaviour.
> Plugins that were developed and tested against 3.0-3.3 should get the
> behaviour they were tested against
>
> Wdyt
> On Mon 26 Dec 2016 at 16:07, Christian Schulte  wrote:
>
> > Am 12/26/16 um 11:36 schrieb Robert Scholte:
> >
> > > This is becoming a bug versus feature discussion.
> >
> >
> >
> > It shouldn't.
> >
> >
> >
> > > Up until now you've made
> >
> > > changes which might change the resolution because you've marked them
> as a
> >
> > > bug which must be fixed. However, what is 'the truth': the
> documentation
> >
> > > or the code? The answer is: in the end it is the code. And if you want
> to
> >
> > > have them in sync, you sometimes need to adjust the documentation
> instead
> >
> > > of the code, because the code has a behavior one is used to.
> >
> >
> >
> > Have you read the Javadoc and the code? If you would have done that, you
> >
> > would notice that everything behaves consistently and as documented
> >
> > *but* one class which is fixed now. If it would be *all* classes, there
> >
> > would be no question the code is behaving the way it should.
> >
> >
> >
> > MRESOLVER-8
> >
> >
> >
> > This *only* affects plugin and extension resolution by stopping to
> >
> > discard any test and provided *direct* dependencies of a plugin the same
> >
> > way optional *direct* dependencies are not discarded and the same way
> >
> > the dependency manager is not managing *direct* dependencies. It does
> >
> > not affect project resolution in any way. That's what we are really
> >
> > lucky about. If we don't want Maven to behave that way (with plugin and
> >
> > extension resolution fixed) it's the Maven codebase to adjust - not the
> >
> > resolver. That's just an API used by Maven and should just be consistent
> >
> > and correct. The original author really could have left a few unit tests
> >
> > in that area. We would not discuss anything, if he would have done that.
> >
> > He would have noticed things himself or would have left a comment at
> >
> > least. The issue above together with
> >
> >
> >
> > MRESOLVER-9
> >
> > MRESOLVER-10
> >
> >
> >
> > is really "just" bugfixes. What we learn from that is that we should
> >
> > "commit" any resolution result during deployment so that bugs like these
> >
> > can be fixed without influencing the resolution performed for a deployed
> >
> > project. That's the PDT file we are going to deploy in Maven X.
> >
> >
> >
> > > Since we're talking about changes in resolution, I also expose this
> > topic.
> >
> > > To me it is not a bug nor a feature, but it is a design flaw. And the
> >
> > > issue is often not exposed, because the dependencies used for testing
> are
> >
> > > not conflicting the compile dependencies. As long as the compilations
> >
> > > works and all the tests run, users often don't look in detail at the
> >
> > > dependency.
> >
> > > The fact right now is that if I add/change a test-scoped dependency, it
> >
> > > could happen that the project won't run due to a missing transitive
> >
> > > dependency.
> >
> > > We are very, very lucky this doesn't happen that often.
> >
> >
> >
> > This is what would stop if we would just fix those bugs. We are running
> >
> > into those bugs ourselves. Take a look at the PMD plugin POM again. What
> >
> > would you have done, if the test dependencies I moved to compile scope
> >
> > would be required for compilation of that project? This is already
> >
> > yelling for an enforcer rule or something like that. "Are all classes
> >
> > used by the classes on the compilation classpath available during
> >
> > compilation?" Currently it's a result of trial and error. Really. If we
> >
> > let this go on, we need to be even more lucky in a few years. If we say
> >
> > plugins and extensions just are not resolved the same way as projects
> >
> > (how it has been for a long time), this will make the following IT start
> >
> > to fail, when done consistently.
> >
> >
> >
> > <
> > 

Re: Why no mvn daemon?

[Jeff Jensen]

Thanks!  It's running just fine.  :-)  It's very cool.  Really nice
directory traversal and completion, colors, and commands/features I don't
know yet!

Very interesting timing diffs (for each casual test, I ran the command for
each multiple times to seed infra caches):
 * on some asciidoc gen with "mvn generate-resources", it was about the
same duration as CLI but after running each about 10 times, mvnshell saved
about 20% consistently (possibly due to JIT? besides directory traversal,
this was the first things I did).  This was my key use case for wanting a
"mvn server" - handling situations like this with repeated runs (asciidoc,
site, etc.).

 * on a simple "mvn clean", mvnshell was about 2x faster than CLI.

 * on a small module build, "mvn install" was about 20% faster over CLI
(after a mvn clean for each).

I look forward to trying more things.

Nice to have, thank you Jason!


On Wed, Mar 9, 2016 at 4:17 PM, Jason Dillon  wrote:

> Jason, if you have a built version, do you mind adding it as a download to
>
> the release files?
>
> I can make a binary of this, though I do plan on fixing it up so that
> folks can build it in the near future.
>
> Build up here for the moment:
>
> https://www.dropbox.com/sh/yvt1g43r2pr2scj/AADqM__VhJaFf_x57OiUEZXva?dl=0
>
> gshell:master should be buildable with just central now, dangling ref to
> older version of jline for classifer=tests which was unused and polluting
> the build dependencies.
>
> —jason
>
>
>

Re: Why no mvn daemon?

[Jeff Jensen]

On Wed, Mar 9, 2016 at 3:59 PM, Jason Dillon <jason.dil...@gmail.com> wrote:

> On March 8, 2016 at 7:45:53 AM, Jeff Jensen (
> jeffjen...@upstairstechnology.com) wrote:
>
> FYI Just cloned and tried build but Jansi 1.2 is not in Central: "Could not
>
> find artifact org.fusesource.jansi:jansi:jar:1.2".
>
> http://search.maven.org/#search|gav|1|g%3A%22org.fusesource.jansi%22%20AND%20a%3A%22jansi%22
> <http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.fusesource.jansi%22%20AND%20a%3A%22jansi%22>
>
>
> I noted the issue tracker no longer exists so replying here to start.
>
> jansi is not declared in the POMs, so assuming transitive. Found it is
> only referenced by
>
> "mvnsh-commands/mvnsh-maven/src/main/java/org/sonatype/maven/shell/commands/maven/ColorizingStream.java"
>
> in mvnsh-commands/mvnsh-maven.
> I'm out of time to look further at the moment.
>
> I’m aware of this.  I took a brief look at upgrading to the latest jline
> but its a bit more work.  There is another sonatype version of jline that
> may work better in the short-term until moving to the official jline2 stuff
> can be done.
>
>
> Jason, if you have a built version, do you mind adding it as a download to
>
> the release files?
>
> I can make a binary of this, though I do plan on fixing it up so that
> folks can build it in the near future.
>
Thanks, it's nice to simply use vs build, from my "user perspective" :-)



> Do you have interest in supporting further or prefer not to continue with
> it?
>
> I’ve recently put in a bit more effort to bring this stuff up to speed
> w/changes to maven.  I’m not sure I’ll be spending a ton of effort around
> it but I’m not sure how much effort is required.  Certainly though if folks
> are actually using this then I’ll do what I can to support its continued
> use.
>
Thanks - my curiosity was around if this was "abandon-ware" or you may make
it buildable again and do a few updates over the years... if not, then I
would keep looking for one!


There is another maven shell which may have more legs in terms of longer
> term community support, but I’m not yet sure where that is in terms of
> public availability.
>

Interesting, is it an internal Sonatype one or from somewhere else?

Re: Why no mvn daemon?

[Jeff Jensen]

FYI Just cloned and tried build but Jansi 1.2 is not in Central: "Could not
find artifact org.fusesource.jansi:jansi:jar:1.2".
http://search.maven.org/#search|gav|1|g%3A%22org.fusesource.jansi%22%20AND%20a%3A%22jansi%22

I noted the issue tracker no longer exists so replying here to start.

jansi is not declared in the POMs, so assuming transitive.  Found it is
only referenced by
"mvnsh-commands/mvnsh-maven/src/main/java/org/sonatype/maven/shell/commands/maven/ColorizingStream.java"
in mvnsh-commands/mvnsh-maven.
I'm out of time to look further at the moment.

Jason, if you have a built version, do you mind adding it as a download to
the release files?
Do you have interest in supporting further or prefer not to continue with
it?


On Sat, Mar 5, 2016 at 10:40 PM, Jeff Jensen <
jeffjen...@upstairstechnology.com> wrote:

> Some months ago I was looking for something like this.  Due to this
> thread, I will soon set it up and try it.  (Thanks for sharing Tamás!)
>
>
> On Sat, Mar 5, 2016 at 10:31 PM, Jason Dillon <jason.dil...@gmail.com>
> wrote:
>
>> On March 3, 2016 at 5:42:56 AM, Tamás Cservenák (ta...@cservenak.net)
>> wrote:
>> Maven Shell?
>>
>> https://github.com/jdillon/mvnsh
>>
>> Does anyone actually use this?
>>
>> —jason
>>
>>
>

Re: Why no mvn daemon?

[Jeff Jensen]

Some months ago I was looking for something like this.  Due to this thread,
I will soon set it up and try it.  (Thanks for sharing Tamás!)


On Sat, Mar 5, 2016 at 10:31 PM, Jason Dillon 
wrote:

> On March 3, 2016 at 5:42:56 AM, Tamás Cservenák (ta...@cservenak.net)
> wrote:
> Maven Shell?
>
> https://github.com/jdillon/mvnsh
>
> Does anyone actually use this?
>
> —jason
>
>

Re: What happened to Maven Eclipse Plugin?

[Jeff Jensen]

>
> Do those of you who are Eclipse users find m2e adequate?


I've successfully used m2e for many years on many different systems
(different customers).  I suggest asking about any issues on the m2e users
list.


On Fri, Dec 25, 2015 at 2:37 PM, Gary Gregory 
wrote:

> I'm still surprised that no one wants to maintain this. Do those of you who
> are Eclipse users find m2e adequate? I don't. Unless I do not know how to
> set it up. For example, importing the log4j2 projects creates some projects
> with errors.
>
> Gary
> On Dec 24, 2015 2:44 PM, "Michael Osipov" <1983-01...@gmx.net> wrote:
>
> > Hi Robert,
> >
> > back in October the result of the retirement vote [1] was positive.
> > The plugin is still online without notice, issues are still open in JIRA
> > and no repo is at GitHub.
> >
> > Did you simply forget that?
> >
> > Michael
> >
> > [1] https://www.mail-archive.com/dev%40maven.apache.org/msg107104.html
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Jsr305, Take 2

[Jeff Jensen]

On Tue, Sep 23, 2014 at 11:05 PM, Hervé BOUTEMY 
wrote:

> Le lundi 22 septembre 2014 18:14:52 Kristian Rosenvold a écrit :
> >  
> >   com.google.code.findbugs
> >   jsr305
> >   3.0.0
> >   provided
> > 
> >
> > The reason for this is that the findbugs project has been evolving
> > these annotations at a pace, and I would now also like to use
> > @CheckForNull, @CheckReturnValue, @OverridingMethodsMustInvokeSuper,
> > @WillClose and @WillNotClose.
> >
> > (CheckReturnValue makes it an error NOT to check the return value,
> > which is good for immutable classes...)
> >
> > I think these annotations are particularly valuable in shared code
> > (maven-shared and all of plexus).
> +1
>
> and with provided scope, I don't see any drawback
> version 1.3.7 was LGPL (as stated in the POM), but version 3.0.0 is AL, so
> I
> don't see any problem
>
> Regards,
>
> Hervé
>
> >
> > Kristian
> >
> > 2014-09-22 18:10 GMT+02:00 Kristian Rosenvold
> :
> > > Some time ago, we discussed using the JSR305 annotations. At the time
> we
> > > discussed @Nonnull and @Nullable, and it turned out that those two
> > > annotations are "named based" in most analysis-tools; you can make your
> > > own
> > > org.apache.maven.annotations.Nonnull/Nullable and have a reasonable
> chance
> > > of having tools pick them up. Both findbugs and IntelliJ support this
> > > approach. We sort-of concluded that this would be the optimal approach,
> > > and
> > > since then we promptly did nothing about it :)
> > >
> > > I'm very happy that we didn't do anything about it, since I'd now like
> to
> > > re-propose that we actually use
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Add Manfred Moser as committer

[Jeff Jensen]

+1

On Wed, May 13, 2015 at 4:17 AM, Martin Gainty mgai...@hotmail.com wrote:

 +1

 Martin


  Date: Wed, 13 May 2015 09:16:19 +0100
  Subject: Re: [VOTE] Add Manfred Moser as committer
  From: stephen.alan.conno...@gmail.com
  To: dev@maven.apache.org
 
  +1
 
  On 13 May 2015 at 08:36, Kristian Rosenvold 
 kristian.rosenv...@zenior.no
  wrote:
 
   +1
   13. mai 2015 8.55 a.m. skrev Hervé BOUTEMY herve.bout...@free.fr:
  
Hi,
   
I'd like to introduce Manfred Moser as committer for the Apache
 Maven
project.
   
He's working on Android Maven plugin for years, has great discussions
   both
on
users and dev MLs, has a great attitude.
And he's just told he wants to improve the site and work on Maven:
 having
him
make pull requests is just a waste of energy for both Manfred and
 whoever
will
accept the PRs: I'm confident that he'll know when to do changes by
himself and
when some discussion is necessary before doing the job.
   
Vote open for 72H
   
[+1]
[0]
[-1]
   
And here's my +1.
   
Hervé
   
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
   
   
  

Re: Feedback wanted on Checktyle plugin ruleset docs

[Jeff Jensen]

I suggest alternative 2 as 1 doesn't scale well with new versions and 3 is
more confusing than 2.


On Sat, May 2, 2015 at 4:11 PM, Christopher ctubb...@apache.org wrote:

 Of the choices, alternative 1 seems the easiest for me.

 On Sat, May 2, 2015, 16:10 Dennis Lundberg denn...@apache.org wrote:

  Hi,
 
  I'm trying to visualize which version of the Checkstyle plugin
  includes which predefined rulesets. There's are 3 alternatives for you
  to look at here:
 
 
 https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/config/index.html
 
  Please let me know which alternative you think is the most easy to
  understand.
 
  --
  Dennis Lundberg
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 

Re: [IMPORTANT NOTICE] Jira migration from Codehaus to Apache on April 4th

[Jeff Jensen]

And please add me as well.
id is jeffjensen
Thank you.


On Fri, Apr 10, 2015 at 4:23 PM, Dan Tran dant...@gmail.com wrote:

 Hi

 Please add me as well

 Thanks

 -D

 On Fri, Apr 10, 2015 at 1:59 PM, Hervé BOUTEMY herve.bout...@free.fr
 wrote:

  I added you to the last request for maven-developers group
 
  https://issues.apache.org/jira/browse/INFRA-9422
 
  Regards,
 
  Hervé
 
  Le vendredi 10 avril 2015 22:20:30 Mirko Friedenhagen a écrit :
   Hello,
  
   now I tried to assign
   https://issues.apache.org/jira/browse/MRELEASE-901 to myself and was
   unable to do so. However I was allowed to resolve the issue (and could
   close it as well).
   When going to my profile
   (https://issues.apache.org/jira/secure/ViewProfile.jspa) I see that I
   am only in the group jira-users and not in any other group (so is
   Robert Scholte btw, but he has assigned issues).
  
   Regards Mirko
   --
   http://illegalstateexception.blogspot.com/
   https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
   https://bitbucket.org/mfriedenhagen/
  
  
   On Tue, Apr 7, 2015 at 7:43 AM, Kristian Rosenvold
  
   kristian.rosenv...@gmail.com wrote:
The user name mapping seems to be ok, but I seem to be missing
permissions to do anything sensible at all ?
   
(krosenvold)
   
Kristian
   
2015-04-06 23:58 GMT+02:00 Mirko Friedenhagen 
 mfriedenha...@gmail.com
  :
A big thank you from my side as well, I logged in to
https://issues.apache.org/jira/ and was easily able to see all my
reported issues and am allowed to edit the open ones.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen
 )
https://bitbucket.org/mfriedenhagen/
   
On Mon, Apr 6, 2015 at 2:29 PM, Jason van Zyl ja...@takari.io
  wrote:
The mapping did not work for my user as all issues that were
  assigned to
jason on the Codehaus side are now mapping to Jason Lane. I also
  can
no longer even log into issues.apache.org  to comment on
 INFRA-9389.
   
My codehaus user is jason, and my Apache user is jvanzyl.
   
I lined up all my email addresses but only did so 3 hours before
 the
migration so maybe that is the issue. But I've lost all access to
 the
Apache JIRA instance all together and all my issues are assigned to
someone else completely.
On Apr 6, 2015, at 6:26 AM, Hervé BOUTEMY herve.bout...@free.fr
  wrote:
there were a lot of manual tasks that took hours, really many
 hours
(the night was shorter than expected), even more for Mark than for
  me:
it's great to see that the result is positive = you can continue
 to
work on the issues
   
but everything didn't go as expected regarding accounts: please
  report
any
problem to INFRA-9389 [1] with precise info regarding usernames at
Codehaus
and at ASF
   
Thank you Ben for all the Codehaus support, and big big big thank
  you
to Mark at ASF infra for the huge work on import.
   
Regards,
   
Hervé
   
[1] https://issues.apache.org/jira/browse/INFRA-9389
   
Le lundi 6 avril 2015 11:55:01 Robert Scholte a écrit :
I would like to take this chance to give huge kudo's to all
  involved
parties.
   
My first impression is that the migration went very well, since I
  can
continue my work at https://issues.apache.org/jira as I was used
  to.
The preparations already showed that it was more than a simple
  copy.
It was a huge move and not everything could be automated (e.g.
  making
all
60+ Jira projects read-only at Codehaus) but the end result is
  great.
   
Thanks a lot Hervé, ASF Infra and Codehaus Support!
   
   
Op Sat, 04 Apr 2015 23:10:55 +0200 schreef Hervé BOUTEMY
   
herve.bout...@free.fr:
Hi,
   
Codehaus was put read-only during migration, when we started by
  doing
a
dump
of the content.
Import at ASF is not one yet: should be done tomorrow.
   
You just have to way for 24 hours that the migration is done :)
   
Regards,
   
Hervé
   
Le samedi 4 avril 2015 14:03:43 Tibor Digana a écrit :
Hello guys,
   
I am not able to find
  https://issues.apache.org/jira/browse/SUREFIRE
I am not able to manage the issues at Codehaus either ASF.
What can we do about that?
   
Cheers
Tibor
   
   
   
--
View this message in context:
   
  http://maven.40175.n5.nabble.com/IMPORTANT-NOTICE-Jira-migration-fro
m-Cod
eh
aus-to-Apache-on-April-4th-tp5830262p5831520.html Sent from the
Maven
Developers mailing list archive at Nabble.com.
   
   
  
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
   
   
  -
To unsubscribe, e-mail: 

Re: Jekyll experiment

[Jeff Jensen]

+1 asciidoctor


On Thu, Mar 19, 2015 at 4:56 AM, Martijn Dashorst 
martijn.dasho...@gmail.com wrote:

 While I use jekyll for lots of stuff (blogs and wicket website), I'd
 urge to use asciidoc[tor] as the markup format. Markdown is great, but
 rather limited for technical documentation. There is some asciidoctor
 integration for jekyll available [1], but I haven't used it in anger.

 Just my 2 cts.

 Martijn

 [1] https://google.com/search?q=jekyll%20asciidoctor


 On Thu, Mar 19, 2015 at 4:32 AM, Jason van Zyl ja...@takari.io wrote:
  Anyone interested in trying a Jekyll experiment for our website? Extract
 the useful documentation we believe there is and try to make working on the
 site a pleasurable experience that is easy for users to contribute to?
 
  I'd like to try this because after this last release I'm frankly tired
 of looking at our pretty awful website. It's ugly, noisy, unmaintained,
 hard to navigate and personally just makes me not want to write anything. I
 would like to like writing documentation again and I think a more standard
 tool like Jekyll will help. I honestly dislike doing core releases because
 I have to use the site plugin. I created it, I can hate it and I do hate it.
 
  Even if no one answers I'll try this experiment because I think there's
 only 10-15 useful documents in the whole site so it likely won't take long.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder, Takari and Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  There's no sense in being precise when you don't even know what you're
 talking about.
 
   -- John von Neumann
 
 
 
 
 
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com

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

Re: Jekyll experiment

[Jeff Jensen]

I agree Fred... the reports are very helpful.  I've always thought of it as
handling two needs: reports and docs; reports basically working OOTB
and docs as the team decides to hand-create.


On Wed, Mar 18, 2015 at 10:43 PM, Fred Cooke fred.co...@gmail.com wrote:

 Well, if you created it, then a personal thank you from me for that. I
 would never use it for normal web stuff, but for the autogenerated stuff
 like PMD, checkstyle, findbugs, cross ref code, javadocs, etc etc it's
 GREAT at release time to give you a reference of what was. Or during dev,
 when one feels like it, to create a comprehensive detailed view of the
 state of the code that can be casually navigated through using a browser.
 It has some SVNness in it, which I hate, so I invite you to continue the
 hate for your own reasons :-D

 On Thu, Mar 19, 2015 at 4:32 PM, Jason van Zyl ja...@takari.io wrote:

  Anyone interested in trying a Jekyll experiment for our website? Extract
  the useful documentation we believe there is and try to make working on
 the
  site a pleasurable experience that is easy for users to contribute to?
 
  I'd like to try this because after this last release I'm frankly tired of
  looking at our pretty awful website. It's ugly, noisy, unmaintained, hard
  to navigate and personally just makes me not want to write anything. I
  would like to like writing documentation again and I think a more
 standard
  tool like Jekyll will help. I honestly dislike doing core releases
 because
  I have to use the site plugin. I created it, I can hate it and I do hate
 it.
 
  Even if no one answers I'll try this experiment because I think there's
  only 10-15 useful documents in the whole site so it likely won't take
 long.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder, Takari and Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  There's no sense in being precise when you don't even know what you're
  talking about.
 
   -- John von Neumann
 
 
 
 
 
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 

Re: Preview release: Plexus Archiver multithreaded Zip edition

[Jeff Jensen]

Sounds like an awesome improvement!  Will we see speed improvement on war
file creation with many megs of jars in the lib dir or only with
compressing of files into the archive (ignoring the web files for this
question)?


On Sat, Jan 10, 2015 at 7:43 AM, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:

 I had 950% CPU usage on my 6 core + HT machine here the other day.

 Kristian


 2015-01-10 14:42 GMT+01:00 Kristian Rosenvold 
 kristian.rosenv...@gmail.com:
  It's faster; a lot faster -  and it scales beautifully.  But then
  again you probably need war/ear/zip heavy builds to really get max
  effect. The average jar plugin does not usually consume that large a
  percentage the average build.
 
  I'll try to make some nice graphs and a blog post some time this weekend.
 
  It's a new api in commons-compress, the existing api did translate
  well to multithreading. You can look at plexus-archiver changes if you
  want to see how it's used. I've also written some docs in
  commons-compress itself.
 
  K
 
 
  2015-01-10 14:34 GMT+01:00 Jason van Zyl ja...@takari.io:
  Do you have any metrics? I use compress-compress directly so I can
 certainly try it on some large archives. Anything special need to be done?
 Or do the same code paths still work they just use the cores available with
 the new version?
 
  On Jan 10, 2015, at 7:23 AM, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
  I just released plexus-archiver version 2.10-beta-1 to maven central.
 
  This is a technology preview of the multithreaded Zip feature I have
  been adding to commons-compress for the last few weeks, and will
  basically use all available CPU cores when compressing the archive.
 
  To test/use this feature, you can add the following clause some
 plugins:
 
  plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-assembly-plugin/artifactId
   version2.5.3/version
   dependencies
 dependency
   groupIdorg.codehaus.plexus/groupId
   artifactIdplexus-archiver/artifactId
   version2.10-beta-1/version
 /dependency
 dependency
   groupIdorg.codehaus.plexus/groupId
   artifactIdplexus-io/artifactId
   version2.4.1/version
 /dependency
   /dependencies
  /plugin
 
  This applies to maven-war-plugin, maven-jar-plugin, maven-ear-plugin,
  maven-assembly-plugin, maven-dependency-plugin and probably a few
  others too.
 
  The feature is basically done. commons-compress 1.10 has not yet
  been released, and the moment this happens there will be a non-beta
  version of plexus-archiver. This version contains a shaded-snapshot
  version of commons-compress.
 
  Please note that if your project basically produces a 30K jar file,
  there is not much to be expected from this upgrade. The larger your
  zip/jar/ear/war files, the more you can expect. And, of course, you
  can use this as an argument towards your boss to get a 6 core CPU.
 
  Feedback appreciated !
 
  In other news, the java 1.6 version 3.0 was also released today,
  which contains snappy compression. 3.0 does not yet contain the
  parallel feature.
 
 
  Kristian
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
 
 
 
 
 
 
 
 
 

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

Re: [VOTE] Maven 3.2.4 Release

[Jeff Jensen]

While I agree with your assessment Paul, the problem with upgrading
non-sequential release numbers that I encounter with some of my customers
(the larger organizations or ones with regulated products [think medical])
is it usually causes some confusion (we're on version n.2 and I see n.8
but nothing in between, anyone know what happened?  Is this a large jump -
will we have problems?) and extra work (digging into it multiple times by
multiple people as each team approaches upgrading tools).  The larger the
gap, the more hassle it may cause for them.

In a build pipeline, I'm very happy to burn through release numbers.

In the Maven release case, since it was never released (only staged for
review before release), I don't consider it a problem to re-stage/respin
with the same number.  And my favorite perspective to evaluate from is my
customer's, and some of them would appreciate no version gaps!


On Sat, Dec 13, 2014 at 4:46 PM, Paul Benedict pbened...@apache.org wrote:

 I can see your point. However, I don't think it's all that unusual for
 people to see skipped versions during upgrading anymore. For example, when
 a security issue is found in a GA product, the affected version is
 instantly pulled from distribution sites and a new version is published.
 Whether a bum internal build or retroactively taking GA from a release, if
 you aren't upgrading frequently, I think skipping versions is not shocking.
 That's my experience anyway. I see you have a different experience but glad
 you shared it.


 Cheers,
 Paul

 On Sat, Dec 13, 2014 at 4:32 PM, Jason van Zyl ja...@takari.io wrote:
 
  Sure, I never wanted to do it which is why I forgot and will likely
  continue to forget so I'll change the docs because I always have to look
 at
  them to figure out how to publish the site. I still think it's a
  inconsistent practice for the few it would inconvenience in a minor way.
 
  On Dec 13, 2014, at 5:27 PM, Paul Benedict pbened...@apache.org wrote:
 
   When the 3.2.0 build had a regression, we jumped to 3.2.1:
  
 
 http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3cdf2f7f9e-9334-43d9-aa01-03733604b...@takari.io%3E
  
   Sorry I didn't provide this thread up front. It took a while to find
 it.
   However, I am pretty sure we did this again with 3.2.3, but I could be
   wrong on that fact -- I just remember we did this twice so far.
  
  
   Cheers,
   Paul
  
   On Sat, Dec 13, 2014 at 4:24 PM, Jason van Zyl ja...@takari.io
 wrote:
  
   I don't because it's inconsistent for external users who will be
  confused
   about where a release has gone. To date I have never skipped versions,
  for
   consistency I don't want to start now. I consider the staged releases
  not
   contributing to the public version pool.
  
   For your case I think you're probably the only person in the world who
   integrates a staged release of Maven. For normal testers, running
 Maven
   3.2.4 doesn't download Maven 3.2.4 related binaries in your local
 repo.
  
   But even if you weren't the only person is it that hard to cleanup the
   punched release locally? I see the reuse of versions as being
   problematically negligible while the confusion for users being high.
  
   On Dec 13, 2014, at 4:42 PM, Igor Fedorenko i...@ifedorenko.com
  wrote:
  
   Why? How will we tell the original broken binaries from the new ones?
  
   On December 13, 2014 4:01:31 PM EST, Jason van Zyl ja...@takari.io
   wrote:
   No, it will be 3.2.4.
  
   On Dec 13, 2014, at 3:52 PM, Stephen Connolly
   stephen.alan.conno...@gmail.com wrote:
  
   Iirc we said not reusing version numbers after a .0 so this will be
   3.2.5,
   yes?
  
   On Saturday, December 13, 2014, Jason van Zyl ja...@takari.io
   wrote:
  
   The fixes have been made, I'll recut the release.
  
   On Dec 13, 2014, at 9:44 AM, Igor Fedorenko i...@ifedorenko.com
   javascript:; wrote:
  
   I've already reintroduced DefaultJavaToolChain and Tycho is happy
   now
   [1].
  
   Tycho needs access to DefaultJavaToolChain#getJavaHome() which,
 to
   the
   best of my knowledge, is not available from any other API, is not
   available through ToolchainManager.
  
   I don't believe Tycho references JavaToolChain interface. As a
 side
   note, in the future we should avoid case-only renames like
   JavaToolChain-JavaToolchain, these cause problems on
   case-insensitive
   filesystems, like the ones used by Windows and OSX.
  
   We don't distinguish between public and internal classes in
 Maven,
   at
   least not generally. There are few classes that are explicitly
   marked as
   @provisional, like ArtifactDescriptorReaderDelegate for example,
   but
   this is not enforced and majority of classes are not marked in
 any
   way.
   I agree we need to have a mechanism to distinguish between public
   and
   internal classes and I have few ideas to do this, but I don't
 think
   we
   can do this retroactively. We have to keep most/all existing
   classes and
   treat them 

Re: Proposal: Ease the usage of Failsafe

[Jeff Jensen]

 Integrating Failsafe in the same way as Surefire would be great for a lot
 of people I think.


I agree!


Personally, I wonder why we don't merge them.


I've wondered the same thing... is there a technical reason why it won't
or is difficult to make work?


On Tue, Oct 28, 2014 at 11:54 AM, Benson Margulies bimargul...@gmail.com
wrote:

 Personally, I wonder why we don't merge them.

 Failsafe adds some lifestyle phase bindings and then changes some
 defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to
 have the extra executions with shifted defaults for things like test
 class names?


 On Tue, Oct 28, 2014 at 11:50 AM, Oliver B. Fischer
 mails...@swe-blog.net wrote:
  @Paul: Yes I think so or we find a way more convenient in this moment.
 
  @all: I think this shows perfectly why Failsafe should be integrated as
  Surefire already is.
 
  Oliver
 
  Am 28.10.14 16:02, schrieb Paul Benedict:
 
  Thanks. Now I know when to use this. For my situation, which is
  integration
  testing against an existing database, I don't need to setup an
  environment;
  this explains why I never needed to use the plugin. There are other
 cases
  the plugin will be valuable, but I wonder if this is why most others
 stick
  with surefire. I guess programmers don't scratch unless there's an itch.
 
 
  Cheers,
  Paul
 
  On Tue, Oct 28, 2014 at 9:21 AM, Anders Hammar and...@hammar.net
 wrote:
 
  The answer is on the index page of the failsafe plugin [1].
  If you use the Surefire Plugin for running tests...
 
  /Anders
 
  [1] http://maven.apache.org/surefire/maven-failsafe-plugin/
 
  On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict pbened...@apache.org
  wrote:
 
  (to
  mails...@swe-blog.net
  https://bitbucket.org/obfischer/bugreport-maven-failsafe.git
  lot
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 

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

Re: PlexusTestCase ?

[Jeff Jensen]

...and even though dbUnit has a base test class for extension, you can use
composition of it instead.  Same for Spring Test - can configure it with
annotations and use a test runner.  No base class needed in either case.

On Thu, Oct 16, 2014 at 3:19 PM, Lennart Jörelid lennart.jore...@gmail.com
wrote:

 Well ... trying to make the case that you cannot use jUnit 4 because your
 testcase extends another is simply not correct.
 It might be more modern to implement a runner in true jUnit 4 style -
 implying I agree with the sentiment of PLX-446 - but it is an overstatement
 to claim it cannot be used with jUnit 4.

 2014-10-16 21:11 GMT+02:00 Robert Scholte rfscho...@apache.org:

  More links? Okay:
  https://jira.codehaus.org/browse/PLX-446
 
  I've been in situations where I needed the combination of 2 TestCase
  extension (I think it was springtest + dbunit)
  Since you can only extend one class, you'll run into a huge challenge.
  You really want to avoid such situations, so if there's a need
  rewrite/move PlexusTestCase, let's do it good so we won't block other
  testing extensions.
  Things like Mockito and PowerMock are very easy to include when using
  JUnit4 Annotations.
 
  Robert
 
  Op Thu, 16 Oct 2014 00:28:38 +0200 schreef Barrie Treloar 
  baerr...@gmail.com:
 
 
   On 16 October 2014 03:49, Robert Scholte rfscho...@apache.org wrote:
 
   TestCase is so 20th century...
 
  *If* you want to do it, please make a TestRule of it.
  See also https://jira.codehaus.org/browse/MPLUGINTESTING-28
 
 
 
  Alright, I'll bite.
  Send me more links on why this is better?
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 


 --

 --
 +==+
 | Bästa hälsningar,
 | [sw. Best regards]
 |
 | Lennart Jörelid
 | EAI Architect  Integrator
 |
 | jGuru Europe AB
 | Mölnlycke - Kista
 |
 | Email: l...@jguru.se
 | URL:   www.jguru.se
 | Phone
 | (skype):jgurueurope
 | (intl): +46 708 507 603
 | (domestic): 0708 - 507 603
 +==+

Re: Maven Developer Hangout Summary (2014-07-31)

[Jeff Jensen]

Awesome!  Thank you very much for the summary.


On Fri, Aug 1, 2014 at 7:56 AM, Jason van Zyl ja...@takari.io wrote:

 Here's a short summary of yesterdays discussion:

 ---

 Manfred Moser

 1) Alternative verifier use in maven-android-plugin for testing. Igor
 created an alternative verifier for use inside of M2E for integration
 testing that allows an integration test to be run from within Eclipse
 without having to install the plugin. The alternative verifier also allows
 multiple invocations with different versions of Maven. So if you want to
 test a plugin against 3.1.1 and 3.2.1, for example, this would be possible.
 This code will be released in the next few weeks. Manfred is attempting to
 remove the use of the maven-testing-harness in the maven-android-plugin
 with this new technique for integration testing.

 2) New repository populator that takes a set of dependency coordinates,
 calculates the transitive hull and publishes them to a remote repository.
 This is a tool that uses Aether. Not sure what Manfreds plans are for
 releasing this or if it's already available. Manfred can speak to this as
 he wishes.

 Hervé Boutemy

 1) Continued work on the Checkstyle setup for Maven projects. A nice way
 is being developed that doesn't force conformance to all rules at once.
 Rules can be selectively turned off so that adherence to the rules can be
 met over time without a huge disruption. Hervé is continuing to test the
 setup with various Maven projects and the current plan is to release this
 new setup in about a month.

 Mark Derricutt

 1) Tiles plugin work is progressing and a release is planned shortly after
 some repository cleanup work. The Tiles plugin is a prototype version of a
 type of mixin for Maven. Some work needs to be done to sort out the proper
 merging of the models, and there may be other things Mark wants to explain
 but we'll likely see something soon.

 Jason van Zyl

 1) Work on the JSR330 branch has 4 ITs failing, but this is due to some
 movement of deprecated code that I will have to revert. While doing the
 JSR330 work some investigation was done on removing maven-compat and there
 are some issues that need to be resolved. Trying to fully remove Plexus
 with JSR330 and get rid of maven-compat is an attempt at something that
 will resemble Maven 4. To make this work quite a bit of refactoring will be
 required and staged releases of plugins in order not to break users. A
 proposal will be sent next week on how we might proceed, but essentially
 involves finding efficient ways to find use of deprecated code and provide
 alternatives to the deprecated code that we are willing to support forever
 more.

 Thanks,

 Jason

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

 the course of true love never did run smooth ...

  -- Shakespeare

Re: git commit: Deprecate unused version of the project dependencies resovler in the core

[Jeff Jensen]

Jason, for:

 1) Include a since statement indicating at point the API was deprecated

You didn't mention if you are against doing so or not.  Do you find it of
value for yourself and others?


 2) include a statement pointing to the replacement API (or non-replacement
 and reason for same).

Do you find it possible and useful to add a comment with the @Deprecated
denoting just no replacement?  e.g. With no direct replacement.  Correct
approach is . (not sure there is always a correct approach to
mention if the context is too vague).  I'm thinking since the hindsight is
it never should have been exposed, leave suggestion(s) for follow up work
as to where to go next, capturing the context change in mind at the point
of deprecation.
Or is it premature to do so with your in-progress work and will do so when
complete?


I like your plan Jason.  I also like abstracting to eventually
evolve/remove like that.


PS I'm thankful you are back with a vengeance improving Maven core.


On Sat, Jul 5, 2014 at 1:34 PM, Jason van Zyl ja...@takari.io wrote:

 Generally when I use @Deprecate alone it means there is no replacement.
 But I marked this change with that sentiment.

 Right now I consider Maven to be and end user tool. The jumble of
 components we have let leak to confuse most integrators I would not
 consider much of an API or SPI. With 4.0.0 I'm pretty much going to shut
 most things down and be very careful about what gets opened up again. I
 imagine 4.0.0 will be stable from a functionality perspective but take a
 while to reach a final 4.0.0. I plan to do the work in the 3.x line where I
 carefully collect everything that's deprecated and document what's going to
 be removed. The new APIs will collect in the 3.x line and I will use a tool
 to remove all the deprecated code to see the affect. Effectively branching
 by abstraction which is a technique I prefer. I can also see what APIs
 every plugin in Maven Central uses so that will give me some idea about
 what to instruct plugin developers to do in order to update.

 On Jul 5, 2014, at 8:44 AM, William Ferguson 
 william.fergu...@xandar.com.au wrote:

  The original Java deprecation guidelines were to
  1) Include a since statement indicating at point the API was deprecated
  2) include a statement pointing to the replacement API (or
 non-replacement
  and reason for same).
 
 
  On Sat, Jul 5, 2014 at 10:34 PM, Robert Scholte rfscho...@apache.org
  wrote:
 
  +1, I often hit deprecated code without knowing what to use instead. A
  hint would certainly help.
 
  Robert
 
  Op Sat, 05 Jul 2014 14:32:14 +0200 schreef Hervé BOUTEMY 
  herve.bout...@free.fr:
 
 
  when we deprecate somthing like this, we should add a hint on what to do
  instead: we have a bunch of deprecated things without any idea on what
 to
  do
  I don't know how we can fix the existing deprecations, but at least I'd
  like to
  avoid adding more such dead-end deprecations
 
  Regards,
 
  Hervé
 
  Le samedi 5 juillet 2014 12:19:01 jvan...@apache.org a écrit :
 
  Repository: maven
  Updated Branches:
   refs/heads/master 963373726 - 9cc2caeb9
 
 
  Deprecate unused version of the project dependencies resovler in the
 core
 
 
  Project: http://git-wip-us.apache.org/repos/asf/maven/repo
  Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/9cc2caeb
  Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/9cc2caeb
  Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/9cc2caeb
 
  Branch: refs/heads/master
  Commit: 9cc2caeb9f54e44587e7642bb43592de7e177f4f
  Parents: 9633737
  Author: Jason van Zyl ja...@tesla.io
  Authored: Sat Jul 5 08:18:38 2014 -0400
  Committer: Jason van Zyl ja...@tesla.io
  Committed: Sat Jul 5 08:18:38 2014 -0400
 
  --
  .../java/org/apache/maven/DefaultProjectDependenciesResolver.java   |
  1 +
  .../src/main/java/org/apache/maven/ProjectDependenciesResolver.java |
  1 +
  2 files changed, 2 insertions(+)
  --
 
 
  http://git-wip-us.apache.org/repos/asf/maven/blob/9cc2caeb/
  maven-core/src/ma
  in/java/org/apache/maven/DefaultProjectDependenciesResolver.java
  --
  diff
  --git
  a/maven-core/src/main/java/org/apache/maven/
  DefaultProjectDependenciesResol
  ver.java
  b/maven-core/src/main/java/org/apache/maven/
  DefaultProjectDependenciesResol
  ver.java index d511d1d..3511d90 100644
  ---
  a/maven-core/src/main/java/org/apache/maven/
  DefaultProjectDependenciesResol
  ver.java +++
  b/maven-core/src/main/java/org/apache/maven/
  DefaultProjectDependenciesResol
  ver.java @@ -42,6 +42,7 @@ import
  org.apache.maven.repository.RepositorySystem; import
  org.codehaus.plexus.component.annotations.Component;
  import org.codehaus.plexus.component.annotations.Requirement;
 
  +@Deprecated
  @Component( role = ProjectDependenciesResolver.class 

Re: Anyone else having issues reaching https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 ?

[Jeff Jensen]

I just successfully viewed the page, so no problems reaching it.



On Fri, May 23, 2014 at 7:30 AM, Jason van Zyl ja...@takari.io wrote:

 For the last few days the instance seems to be in distress. Anyone else
 having issues?

 Thanks,

 Jason

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

Re: svn commit: r1595491 - in /maven/shared/trunk/maven-dependency-tree: ./ src/it/multi-module-plugin/ src/it/multi-module-plugin/resources/ src/it/multi-module-plugin/resources/META-INF/ src/it/mult

[Jeff Jensen]

+1
In my circles, changing method params is a bad practice.

Enforcement of rules is key - I do the same thing Manfred, fail the build
on a set of FindBugs, PMD, and CheckStyle violations.  Really makes coders
adhere!


On Fri, May 23, 2014 at 10:15 PM, Manfred Moser manf...@mosabuam.comwrote:

 I totally agree with William here. I also think that any standard that is
 not enforced easily is pointless. Thats why I implemented the checkstyle
 verification to be part of the default build in the android maven plugin
 (and other projects). I find this tremendously helpful. It removes any
 doubts on the potentially committer side. Its gotta build..

 manfred

 William Ferguson wrote on 23.05.2014 18:10:

 
  parameters and local variables are not considered final: there is
 nothing
  wrong
 
  with modifying their value, and nothing good to get by forcing them to be
  final
 
 
  But there *is* value is defining them to be final.
 
  If you as the programmer know that a value should never change, then by
  denoting it as final you can enforce that it is not inadvertently
 modified
  by someone else. If they deem that the restriction needs to be loosened
  because requirements have changed then they can do so.
 
  It is just like specifying an assertion. It is about code correctness and
  less failures.
 


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

Re: Why is dependency:unpack evil

[Jeff Jensen]

Agreed, we put the WSDL and related schemas in a domain module and its
build generates these domain classes in its build.  Then other modules use
the domain jar...

The only place we currently use dependency:unpack is in an AT (acceptance
test) module that retrieves the war and unpacks it to an exploded war dir
for then starting embedded Tomcat for the tests.


On Sun, Apr 13, 2014 at 9:57 AM, Jason van Zyl ja...@takari.io wrote:

 Sure, if you have odd cases like that it comes in handy.

 Seems counter productive to put the WSDL in a WAR, deploy/install it only
 to retrieve the WAR again and pull out the WSDL to generate your client
 code.

 On Apr 13, 2014, at 9:43 AM, Dominik Bartholdi d...@fortysix.ch wrote:

  We use the dependency:unpack to get hold on a couple of WSDL files
 packaged within a WAR (or jar, zip).
  These WSDLs the are the input to generate the client site code with
 jaxws-m-p - coping these files into our repo is definitely nothing we want
 to do and accessing these files nine via http is not an option either.
  Domi
 
 
  On 12.04.2014, at 18:38, Jason van Zyl ja...@takari.io wrote:
 
  On Apr 12, 2014, at 11:32 AM, Benson Margulies bimargul...@gmail.com
 wrote:
 
 
  I'm much more here. For example, I might have 250,000 words of text
  annotated for training a statistical model. I have a maven build that
  needs to grab unpack that pile into some location, run a plugin that
  performs some data normalization, and then feed the location into a
  maven plugin of mine that trains the model.
 
  This definitively seems like the wrong place to do this, in the build
 system. This is not a build time activity, it seems like part of an ETL
 flow of a data acquisition application.
 
  I guess I could model this
  as dependencies, if the scope system allowed me to manage all of this
  at a safe distance from the classpath, but as it is it works fine as
  'putting together a bunch of files.'
 
  The question is why would you model something like this at all in
 Maven. Just because you might be able to doesn't mean you should. You can,
 but your specific use case doesn't seem appropriate for a build system.
 
 
 
 
  I think that Hervé is trying to help me by suggesting that I
 shouldn't
  need the dependency: that just calling out the coordinates to
  something like :unpack should result in resolution via injection.
 
  Then what changes?
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  To think is easy. To act is hard. But the hardest thing in the world
 is to act in accordance with your thinking.
 
  -- Johann von Goethe
 
 
 
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  Our achievements speak for themselves. What we have to keep track
  of are our failures, discouragements and doubts. We tend to forget
  the past difficulties, the many false starts, and the painful
  groping. We see our past achievements as the end result of a
  clean forward thrust, and our present difficulties as
  signs of decline and decay.
 
  -- Eric Hoffer, Reflections on the Human Condition
 

 Thanks,

 Jason

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

 You are never dedicated to something you have complete confidence in.
 No one is fanatically shouting that the sun is going to rise tomorrow.
 They know it is going to rise tomorrow. When people are fanatically
 dedicated to political or religious faiths or any other kind of
 dogmas or goals, it's always because these dogmas or
 goals are in doubt.

   -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

Re: Why is dependency:unpack evil

[Jeff Jensen]

The app loads all resources from the classpath.

IIRC, Tomcat requires the exploded WAR.  I think the Tomcat plugin also
requires file system files for config, e.g. /warSourceDirectory,
/warDirectory, and /contextFile.




On Sun, Apr 13, 2014 at 10:19 AM, Jason van Zyl ja...@takari.io wrote:

 On Apr 13, 2014, at 11:14 AM, Jeff Jensen 
 jeffjen...@upstairstechnology.com wrote:

  Agreed, we put the WSDL and related schemas in a domain module and its
  build generates these domain classes in its build.  Then other modules
 use
  the domain jar...
 
  The only place we currently use dependency:unpack is in an AT (acceptance
  test) module that retrieves the war and unpacks it to an exploded war dir
  for then starting embedded Tomcat for the tests.
 

 Is this only because the WAR needs to be exploded to work? In that you
 expect resources to be in the file system vs the classpath?

 
  On Sun, Apr 13, 2014 at 9:57 AM, Jason van Zyl ja...@takari.io wrote:
 
  Sure, if you have odd cases like that it comes in handy.
 
  Seems counter productive to put the WSDL in a WAR, deploy/install it
 only
  to retrieve the WAR again and pull out the WSDL to generate your client
  code.
 
  On Apr 13, 2014, at 9:43 AM, Dominik Bartholdi d...@fortysix.ch
 wrote:
 
  We use the dependency:unpack to get hold on a couple of WSDL files
  packaged within a WAR (or jar, zip).
  These WSDLs the are the input to generate the client site code with
  jaxws-m-p - coping these files into our repo is definitely nothing we
 want
  to do and accessing these files nine via http is not an option either.
  Domi
 
 
  On 12.04.2014, at 18:38, Jason van Zyl ja...@takari.io wrote:
 
  On Apr 12, 2014, at 11:32 AM, Benson Margulies bimargul...@gmail.com
 
  wrote:
 
 
  I'm much more here. For example, I might have 250,000 words of text
  annotated for training a statistical model. I have a maven build that
  needs to grab unpack that pile into some location, run a plugin that
  performs some data normalization, and then feed the location into a
  maven plugin of mine that trains the model.
 
  This definitively seems like the wrong place to do this, in the build
  system. This is not a build time activity, it seems like part of an ETL
  flow of a data acquisition application.
 
  I guess I could model this
  as dependencies, if the scope system allowed me to manage all of this
  at a safe distance from the classpath, but as it is it works fine as
  'putting together a bunch of files.'
 
  The question is why would you model something like this at all in
  Maven. Just because you might be able to doesn't mean you should. You
 can,
  but your specific use case doesn't seem appropriate for a build system.
 
 
 
 
  I think that Hervé is trying to help me by suggesting that I
  shouldn't
  need the dependency: that just calling out the coordinates to
  something like :unpack should result in resolution via injection.
 
  Then what changes?
 
 
 -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  To think is easy. To act is hard. But the hardest thing in the world
  is to act in accordance with your thinking.
 
  -- Johann von Goethe
 
 
 
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  Our achievements speak for themselves. What we have to keep track
  of are our failures, discouragements and doubts. We tend to forget
  the past difficulties, the many false starts, and the painful
  groping. We see our past achievements as the end result of a
  clean forward thrust, and our present difficulties as
  signs of decline and decay.
 
  -- Eric Hoffer, Reflections on the Human Condition
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  You are never dedicated to something you have complete confidence in.
  No one is fanatically shouting that the sun is going to rise tomorrow.
  They know it is going to rise tomorrow. When people are fanatically
  dedicated to political or religious faiths or any other kind of
  dogmas or goals, it's always because these dogmas

Re: Why is dependency:unpack evil

[Jeff Jensen]

I'm not sure but seems like it could work.  They both pull artifacts from
repo but unpack processes only the named ones and unpack-dependencies does
the listed deps.  Would need to use one of the /include* elements to
limit it to the war artifact only.  However, the war module is not
currently a dep.

Some more notes on the AT module setup:
- It only has the tests and the test infrastructure.

- Its build starts a few things, including embedded Tomcat.  The tests run
against the Tomcat instance (which is running the war).

- Its deps are only those required for the tests - other modules and 3rd
party.  The WAR module is not in the list of deps.



On Sun, Apr 13, 2014 at 10:49 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On Sunday, 13 April 2014, Jeff Jensen jeffjen...@upstairstechnology.com
 wrote:

  Agreed, we put the WSDL and related schemas in a domain module and its
  build generates these domain classes in its build.  Then other modules
 use
  the domain jar...
 
  The only place we currently use dependency:unpack is in an AT (acceptance
  test) module that retrieves the war and unpacks it to an exploded war dir
  for then starting embedded Tomcat for the tests.


 Could you replace that usage with dependency:unpack-dependencies (assuming
 you had a scopeprocessing/scope that kept it off the classpath... Not
 that WARs go on the classpath - Except for executable ones like Jenkins -
 but more to be explicit)?


 
  On Sun, Apr 13, 2014 at 9:57 AM, Jason van Zyl ja...@takari.io wrote:
 
   Sure, if you have odd cases like that it comes in handy.
  
   Seems counter productive to put the WSDL in a WAR, deploy/install it
 only
   to retrieve the WAR again and pull out the WSDL to generate your client
   code.
  
   On Apr 13, 2014, at 9:43 AM, Dominik Bartholdi d...@fortysix.ch
 wrote:
  
We use the dependency:unpack to get hold on a couple of WSDL files
   packaged within a WAR (or jar, zip).
These WSDLs the are the input to generate the client site code with
   jaxws-m-p - coping these files into our repo is definitely nothing we
  want
   to do and accessing these files nine via http is not an option either.
Domi
   
   
On 12.04.2014, at 18:38, Jason van Zyl ja...@takari.io wrote:
   
On Apr 12, 2014, at 11:32 AM, Benson Margulies 
 bimargul...@gmail.com
  
   wrote:
   
   
I'm much more here. For example, I might have 250,000 words of text
annotated for training a statistical model. I have a maven build
 that
needs to grab unpack that pile into some location, run a plugin
 that
performs some data normalization, and then feed the location into a
maven plugin of mine that trains the model.
   
This definitively seems like the wrong place to do this, in the
 build
   system. This is not a build time activity, it seems like part of an ETL
   flow of a data acquisition application.
   
I guess I could model this
as dependencies, if the scope system allowed me to manage all of
 this
at a safe distance from the classpath, but as it is it works fine
 as
'putting together a bunch of files.'
   
The question is why would you model something like this at all in
   Maven. Just because you might be able to doesn't mean you should. You
  can,
   but your specific use case doesn't seem appropriate for a build system.
   
   
   
   
I think that Hervé is trying to help me by suggesting that I
   shouldn't
need the dependency: that just calling out the coordinates to
something like :unpack should result in resolution via injection.
   
Then what changes?
   
   
  -
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
   
   
Thanks,
   
Jason
   
--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
   
To think is easy. To act is hard. But the hardest thing in the
 world
   is to act in accordance with your thinking.
   
-- Johann von Goethe
   
   
   
   
   
   
   
   
   
   
   
 -
To unsubscri



 --
 Sent from my phone

Re: New logo?

[Jeff Jensen]

Looks good.  I like the left nav better tho!
I don't think the Maven logo in the upper right corner looks bad/out of
place, however, a new logo is fun to have!



On Mon, Dec 16, 2013 at 6:17 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:


 https://www.dropbox.com/s/w5eblhl4q0fzc6p/Screen%20Shot%202013-12-16%20at%2022.32.03.png


 On 17 December 2013 00:16, Stephen Connolly 
 stephen.alan.conno...@gmail.com
  wrote:

  bollix gmail
 
 
  On 17 December 2013 00:11, Olivier Lamy ol...@apache.org wrote:
 
  Maybe only me but I cannot see the image :-)
 
 
  On 17 December 2013 09:35, Stephen Connolly 
  stephen.alan.conno...@gmail.com
   wrote:
 
   I have been playing with reworking our front page...[image: Inline
  images
   1]
  
   I think the fluido skin is a big improvement, I would like to switch
 to
   that...
  
   Only problem I see is that our current logo(s) are very tied to the
 old
   look and feel...
  
   So do we want to see about launching a logo competition. TomEE had
 good
   success with theirs.
  
   Also I'm looking at going with the top-menu version of fluido skin
  rather
   than the left menu... I have a solution to the hidden nature... but
   you'll just have to wait until I sync up with Hervé to find a way to
  get it
   pushed to staging from a branch without blowing up the production site
  to
   see my trickery!
  
   -Stephen
  
 
 
 
  --
  Olivier Lamy
  Ecetera: http://ecetera.com.au
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 
 

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

[Jeff Jensen]

That message indicates you need to git pull first.  Even though you
may already have done so and no one else has pushed since, this usually
happens when modifying a commit that has been pushed/shared.

On Sat, Jul 27, 2013 at 8:08 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
 the last 2 commits are to be amended: lst one for MNG-5499, previous one for
 MNG-5495

 I tried git commit --amend -m [MNG-5499]... for the last one, but when I git
 push, I get

 To https://git-wip-us.apache.org/repos/asf/maven.git
  ! [rejected]master - master (non-fast-forward)
 error: failed to push some refs to 
 'https://git-wip-us.apache.org/repos/asf/maven.git'
 hint: Updates were rejected because the tip of your current branch is behind
 hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
 hint: before pushing again.
 hint: See the 'Note about fast-forwards' in 'git push --help' for details.


 Did I do something wrong? Or git repo at ASF is configured to avoid such
 things?

 Regards,

 Hervé

 Le samedi 27 juillet 2013 13:37:12 Fred Cooke a écrit :
 Of course, if anyone is working down stream of this, they will hate you,
 and it should be left as is.

 On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke fred.co...@gmail.com wrote:
  Yes, easily, if it's the HEAD just do a --amend on it and update it
  yourself, Jason's name will be retained. If it's not HEAD then do rebase
  -i
  previous hash to the one of interest then mark the one of interest for
  comment edit and proceed.
 
  On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY
 herve.bout...@free.frwrote:
  IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
 
  I'm not a git blackbelt: can the comment be updated to add the classical
  [MNG-5499]?
  (and next time not be forgotten from initial comment :) )
 
  I'm adding a reference to the commit in the Jira issue
 
  Regards,
 
  Hervé
 
  Le samedi 27 juillet 2013 01:45:44 jvan...@apache.org a écrit :
   o change the scope of org.eclipse.sisu to test in the
 
  maven-aether-provider
 
   to prevent it from leaking out to clients.
  
  
   Project: http://git-wip-us.apache.org/repos/asf/maven/repo
   Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/e084ff3b
   Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e084ff3b
   Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e084ff3b
  
   Branch: refs/heads/master
   Commit: e084ff3b8c04bdfdac62a28a1bef8ec87762d4dc
   Parents: 0609504
   Author: Jason van Zyl ja...@tesla.io
   Authored: Fri Jul 26 21:09:50 2013 -0400
   Committer: Jason van Zyl ja...@tesla.io
   Committed: Fri Jul 26 21:09:50 2013 -0400
  
   --
  
maven-aether-provider/pom.xml | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
  
   --
 
  http://git-wip-us.apache.org/repos/asf/maven/blob/e084ff3b/maven-aether-p
  rov
   ider/pom.xml
   --
 
  diff
 
   --git a/maven-aether-provider/pom.xml b/maven-aether-provider/pom.xml
 
  index
 
   910fab6..9235f1c 100644
   --- a/maven-aether-provider/pom.xml
   +++ b/maven-aether-provider/pom.xml
   @@ -63,20 +63,6 @@ under the License.
  
  artifactIdaether-impl/artifactId
  
/dependency
dependency
  
   -  groupIdorg.eclipse.aether/groupId
   -  artifactIdaether-connector-wagon/artifactId
   -  scopetest/scope
   -/dependency
   -dependency
   -  groupIdorg.apache.maven.wagon/groupId
   -  artifactIdwagon-file/artifactId
   -  scopetest/scope
   -/dependency
   -dependency
   -  groupIdorg.eclipse.sisu/groupId
   -  artifactIdorg.eclipse.sisu.plexus/artifactId
   -/dependency
   -dependency
  
  groupIdorg.codehaus.plexus/groupId
  artifactIdplexus-component-annotations/artifactId
  
/dependency
  
   @@ -96,6 +82,22 @@ under the License.
  
/exclusion
  
  /exclusions
  
/dependency
  
   +!-- Testing --
   +dependency
   +  groupIdorg.eclipse.aether/groupId
   +  artifactIdaether-connector-wagon/artifactId
   +  scopetest/scope
   +/dependency
   +dependency
   +  groupIdorg.apache.maven.wagon/groupId
   +  artifactIdwagon-file/artifactId
   +  scopetest/scope
   +/dependency
   +dependency
   +  groupIdorg.eclipse.sisu/groupId
   +  artifactIdorg.eclipse.sisu.plexus/artifactId
   +  scopetest/scope
   +/dependency
  
  /dependencies
  
  build
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

[Jeff Jensen]

On Sat, Jul 27, 2013 at 8:38 AM, Fred Cooke fred.co...@gmail.com wrote:
 On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier aherit...@gmail.comwrote:

 At Apache it is forbidden to rewrite the history of the master branch.
 Which isn't so bad.


 Ahh, this is a very sound policy! Someone is switched on! :-)

Yes, very good!


 -
 Arnaud

 Le 27 juil. 2013 à 15:19, Jeff Jensen
 jeffjen...@upstairstechnology.com a écrit :

  That message indicates you need to git pull first.  Even though you
  may already have done so and no one else has pushed since, this usually
  happens when modifying a commit that has been pushed/shared.
 
  On Sat, Jul 27, 2013 at 8:08 AM, Hervé BOUTEMY herve.bout...@free.fr
 wrote:
  the last 2 commits are to be amended: lst one for MNG-5499, previous
 one for
  MNG-5495
 
  I tried git commit --amend -m [MNG-5499]... for the last one, but
 when I git
  push, I get
 
  To https://git-wip-us.apache.org/repos/asf/maven.git
  ! [rejected]master - master (non-fast-forward)
  error: failed to push some refs to '
 https://git-wip-us.apache.org/repos/asf/maven.git'
  hint: Updates were rejected because the tip of your current branch is
 behind
  hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
  hint: before pushing again.
  hint: See the 'Note about fast-forwards' in 'git push --help' for
 details.
 
 
  Did I do something wrong? Or git repo at ASF is configured to avoid such
  things?
 
  Regards,
 
  Hervé
 
  Le samedi 27 juillet 2013 13:37:12 Fred Cooke a écrit :
  Of course, if anyone is working down stream of this, they will hate
 you,
  and it should be left as is.
 
  On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke fred.co...@gmail.com
 wrote:
  Yes, easily, if it's the HEAD just do a --amend on it and update it
  yourself, Jason's name will be retained. If it's not HEAD then do
 rebase
  -i
  previous hash to the one of interest then mark the one of interest
 for
  comment edit and proceed.
 
  On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY
  herve.bout...@free.frwrote:
  IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
 
  I'm not a git blackbelt: can the comment be updated to add the
 classical
  [MNG-5499]?
  (and next time not be forgotten from initial comment :) )
 
  I'm adding a reference to the commit in the Jira issue
 
  Regards,
 
  Hervé
 
  Le samedi 27 juillet 2013 01:45:44 jvan...@apache.org a écrit :
  o change the scope of org.eclipse.sisu to test in the
 
  maven-aether-provider
 
  to prevent it from leaking out to clients.
 
 
  Project: http://git-wip-us.apache.org/repos/asf/maven/repo
  Commit:
 http://git-wip-us.apache.org/repos/asf/maven/commit/e084ff3b
  Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e084ff3b
  Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e084ff3b
 
  Branch: refs/heads/master
  Commit: e084ff3b8c04bdfdac62a28a1bef8ec87762d4dc
  Parents: 0609504
  Author: Jason van Zyl ja...@tesla.io
  Authored: Fri Jul 26 21:09:50 2013 -0400
  Committer: Jason van Zyl ja...@tesla.io
  Committed: Fri Jul 26 21:09:50 2013 -0400
 
 
 --
 
  maven-aether-provider/pom.xml | 30 --
  1 file changed, 16 insertions(+), 14 deletions(-)
 
 
 --
 
 
 http://git-wip-us.apache.org/repos/asf/maven/blob/e084ff3b/maven-aether-p
  rov
  ider/pom.xml
 
 --
 
  diff
 
  --git a/maven-aether-provider/pom.xml
 b/maven-aether-provider/pom.xml
 
  index
 
  910fab6..9235f1c 100644
  --- a/maven-aether-provider/pom.xml
  +++ b/maven-aether-provider/pom.xml
  @@ -63,20 +63,6 @@ under the License.
 
artifactIdaether-impl/artifactId
 
  /dependency
  dependency
 
  -  groupIdorg.eclipse.aether/groupId
  -  artifactIdaether-connector-wagon/artifactId
  -  scopetest/scope
  -/dependency
  -dependency
  -  groupIdorg.apache.maven.wagon/groupId
  -  artifactIdwagon-file/artifactId
  -  scopetest/scope
  -/dependency
  -dependency
  -  groupIdorg.eclipse.sisu/groupId
  -  artifactIdorg.eclipse.sisu.plexus/artifactId
  -/dependency
  -dependency
 
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-component-annotations/artifactId
 
  /dependency
 
  @@ -96,6 +82,22 @@ under the License.
 
  /exclusion
 
/exclusions
 
  /dependency
 
  +!-- Testing --
  +dependency
  +  groupIdorg.eclipse.aether/groupId
  +  artifactIdaether-connector-wagon/artifactId
  +  scopetest/scope
  +/dependency
  +dependency
  +  groupIdorg.apache.maven.wagon/groupId
  +  artifactIdwagon-file/artifactId
  +  scopetest/scope
  +/dependency
  +dependency
  +  groupIdorg.eclipse.sisu/groupId
  +  artifactIdorg.eclipse.sisu.plexus/artifactId

Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

[Jeff Jensen]

+1 (non-binding)

On Tue, Jul 23, 2013 at 8:59 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 This vote is to cover the minimum required version of Java for Maven Core.

 Maven Plugins produced by the Apache Maven Project that are flagged as
 compatible with older versions of Maven Core as their baseline will still
 require to stick to the minimum Java requirements of that Maven Core
 version. In other words, if for example maven-compiler-plugin advertises
 compatibility with Maven Core 2.0.11+ then that will still need to be
 compiled targeting Java 1.4 and only using dependencies that are aligned
 with that runtime requirement.

 Additionally patch releases to existing releases of Maven Core will not be
 subject to this requirement.

 For example [example]*if* this vote passes and *if* on Sep 29th we release
 Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2, Maven
 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security
 issue that affected all versions of Maven) then only Maven 3.3.0 would be
 require Java 6 as a minimum runtime requirement, the 2.0.12 release would
 still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions would
 all still require Java 1.5.[/example]

 This is not a requirement that 3rd party plugins need use Java 6 as a
 minimum. Third party plugins are free to require any Java version = the
 corresponding Maven minimum requirement, though obviously from a users
 perspective it is best if plugins try to adhere to our contracts for
 corresponding versions of Maven Core.

 Justification for the cut-off date:

 * Oracle has gone end of life on Java 6 Feb 2013 (note that there is still
 extended and sustaining support for existing Oracle customers using Java 5)
 * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are
 still with support, but there are other Java vendors for other platforms)
 * Apple no longer supports any hardware that does not have at least an
 Apple Java 6 version available.
 * Red Hat is providing support for OpenJDK 6
 * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available.

 As I see it, that essentially ensures that for the vast majority of
 platforms there is a very strong likelihood of a Java 6 compatible version
 of Java available for that platform. Toolchains support or forking of the
 compiler and surefire can provide support for users who still need to build
 with older versions of Java (e.g., as was the case for Java 1.4.2 with
 Maven 2.2.1). Additionally users who are forced to use a java version older
 than Java 6 also are likely unable to upgrade their version of Maven, so
 this change will not affect them

 This vote is open for 72 hours. A minimum of three +1 binding votes (i.e.
 from the PMC) and the majority of votes cast from committers will be
 required to pass this vote.

 +1000: Yes, and when can we have the vote to go for Java 7 as a minimum?
 (This option is equivalent to +1 but provides people the ability to
 indicate an additional preference while not contributing to the inevitible
 noise)
 +1: Yes
 0: No opinion
 -1: No

 -Stephen

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

Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?

[Jeff Jensen]

It seems that most people care about X.Y and X.Y.Z numbers of the
versioning scheme, not X.Y.Z.N.  To spin through version numbers without
concern during release candidates, perhaps using the 4th position, N, would
then allow continued use of the familiar X.Y and X.Y.Z references?
 Major.Minor.Point/bug.RC.  It's arbitrary precision, but maintains the
X.Y.Z format, and Z doesn't have skipped numbers.




On Wed, May 29, 2013 at 6:31 AM, Gary Gregory garydgreg...@gmail.comwrote:

 On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  Moving discussion off the vote thread
 
  The issue with that is when using the Maven Release Plugin, you will not
 be
  voting on the released artifacts if you call it x.y.z-RCn, so you would
  need a whole new vote for x.y.z.
 

 The /[vote]/ and the /SVN tag/ are called x.y.z-RCn, the artifacts in the
 Nexus staging repo are marked x.y.z.

 Gary

 
  We could go all Eclipse nutjob and force the timestamp into every
 release,
  e.g.
 
  3.1.0.v20130529
 
  But that way madness lies in my view... In any case, we will see where
 the
  vote goes... and if there is a non-definitive answer, e.g. (-3  ∑
 binding
  votes  3) then we can see what alternatives fall out of the mix.
 
 
  On 29 May 2013 12:10, Gary Gregory garydgreg...@gmail.com wrote:
 
   FWIW, over in Apache Commons land this is how we handle things.
  
   When we prepare and tag a release for version x.y.z, it is tagged as
   .../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. If
  the
   [vote] fails, the tag stays as a record of what happened and the email
   archives tell the story of why the vote failed. The next attempt is
  tagged
   as
   .../x.y.z-RC2, and so on.
  
   Some of this is detailed here
   https://wiki.apache.org/commons/UsingNexusand here
   https://commons.apache.org/releases/prepare.html
  
   Gary
  
  
   On Wed, May 29, 2013 at 6:01 AM, Stephen Connolly 
   stephen.alan.conno...@gmail.com wrote:
  
We have been using a policy of only making releases without skipping
version numbers, e.g.
   
3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
   
Whereby if there is something wrong with the artifacts staged for
   release,
we drop the staging repo, delete the tag, roll back the version, and
  run
again.
   
This vote is to change the policy to:
   
drop the staging repo, document the release as not released, and run
  with
the next version.
   
Under this new proposal, if the staged artifacts for 3.1.0 fail to
 meet
   the
release criteria, then the artifacts would be dropped from the
 staging
repository and never see the light of day. The tag would remain in
 SCM,
   and
we would document (somewhere) that the release was cancelled. The
   respin
would have version number 3.1.1 and there would never be a 3.1.0.
   
This change could mean that the first actual release of 3.1.x might
 end
   up
being 3.1.67 (though I personally view that as unlikely, and in the
   context
of 3.1.x I think we are very nearly there)
   
Please Note:
   
   
  
 
 http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
not actually specify what it means by the process will need to be
restarted so this vote will effect a change either outcome
   
+1: Never respin with the same version number, always increment the
   version
for a respin
0: Don't care
-1: Always respin with the same version number until that version
  number
gets released
   
This vote will be open for 72 hours. A Majority of PMC votes greater
   that 3
will be deemed as decisive in either direction (i.e. if the sum is 
 -3
   or
 +3 then there is a documented result)
   
For any releases in progress at this point in time, it is up to the
   release
manager to decide what to do if they need to do a respin.
   
-Stephen
   
  
  
  
   --
   E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
   Java Persistence with Hibernate, Second Edition
   http://www.manning.com/bauer3/
   JUnit in Action, Second Edition http://www.manning.com/tahchiev/
   Spring Batch in Action http://www.manning.com/templier/
   Blog: http://garygregory.wordpress.com
   Home: http://garygregory.com/
   Tweet! http://twitter.com/GaryGregory
  
 



 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: Multi-project releases

[Jeff Jensen]

-N
Same for other operations to not recurse into children/modules.


On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin 
andrei.pozolo...@gmail.com wrote:

 *Robert*

 unrelated question, may be you can clarify: in the current
 maven-release-plugin
 what is the way to release parent w/o releasing its modules?

 Thank you,

 Andrei

  Original Message 
 Subject: Re: Multi-project releases
 From: Robert Scholte rfscho...@apache.org
 To: Maven Developers List dev@maven.apache.org, Andrei Pozolotin
 andrei.pozolo...@gmail.com
 Cc: Stephen Connolly stephen.alan.conno...@gmail.com
 Date: Sun 24 Mar 2013 11:36:04 AM CDT
  Andrei,
 
  First of all I'm only talking about the definition of root project,
  not about release stuff yet, because this has already consequences for
  other plugins as well.
  Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
  should see that it does match your start-from-any-module.
  If this will be the component for plugins (and maybe other projects)
  which contains the actual definitions and transformations, we have a
  good place to document it and to refer to.
 
  Robert
 
  [1]
 
 http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup#l39
 
 
  Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
  andrei.pozolo...@gmail.com:
 
  Robert, Stephen:
 
  1) from my experience release root /  top-to-bottom / monolithic  is a
  wrong approach.
  please consider instead start-from-any-module / from-bottom-up /
  incremental approach, as implemented here:
  https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
 
  2) it would be good to have some wiki page somewhere to flesh out all
  assumptions that currently go into release
  as well as to list the use cases people really need. here is one of my
  use cases:
 
 https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
 
 
  Andrei
 
   Original Message 
  Subject: Re: Multi-project releases
  From: Robert Scholte rfscho...@apache.org
  To: Maven Developers List dev@maven.apache.org
  Date: Sun 24 Mar 2013 09:42:27 AM CDT
  Hi Stephen,
 
  I've just checked your code.
  Most interesting is our difference of the definition releaseRoot (or
  in my case rootProject, I think we mean the same thing with it).
  If I'm correct you base it on the existence of the scm-section and
  if it has ever been released (assuming a specific scm comment).
  MRELEASE-814[1] is probably a good example for which this strategy
  won't work.
  I try to base it on the parent/module relationship.
 
  Although this looks close related to MRELEASE-516[2] it is actually a
  complete other issue.
  The problem I have with MRELEASE-516 is that it's not the
  plug-and-play behavior you'd like to have,
  which means that the developer is responsible for checking out
  separate projects in the right structure.
 
  Robert
 
  [1] https://jira.codehaus.org/browse/MRELEASE-814
  [2] https://jira.codehaus.org/browse/MRELEASE-516
 
 
  Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly
  stephen.alan.conno...@gmail.com:
 
  Hey one and all,
 
  So we all know how multiple projects with multiple release roots are a
  pain...
 
  Here's some experiments I've been playing with...
 
  Not yet brave enough to have it fire up release:prepare
  release:perform on
  each release root, nor fire up versions:set on the downstream
  projects with
  explicit dependencies, nor lather rinse repeat until there is nothing
  needing a release...
 
  But even the simple report should be useful, and if anyone has
  suggestions
  to help improve its recommendations towards getting confidence that
  the
  automated stuff could work... please give me pull requests.
 
  If this proves useful, I will probably roll it into the release
  plugin...
  but for now I'll keep it in a holding pattern on github (where it is
  not in
  a default plugin groupId and hence relocation is less of an issue if
  I do
  happen to make any releases into central)
 
  $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots
 
  from an aggregator pom should identify all the release roots and
  whether
  they might need a release
 
  -Stephen
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 

Re: Multi-project releases

[Jeff Jensen]

Yes, good point to know of in case that causes a problem.


On Sun, Mar 24, 2013 at 2:30 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 That's still going to result in all the children being part of the tag
 though

 On Sunday, 24 March 2013, Jeff Jensen wrote:

  -N
  Same for other operations to not recurse into children/modules.
 
 
  On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin 
  andrei.pozolo...@gmail.com javascript:; wrote:
 
   *Robert*
  
   unrelated question, may be you can clarify: in the current
   maven-release-plugin
   what is the way to release parent w/o releasing its modules?
  
   Thank you,
  
   Andrei
  
    Original Message 
   Subject: Re: Multi-project releases
   From: Robert Scholte rfscho...@apache.org
   To: Maven Developers List dev@maven.apache.org, Andrei Pozolotin
   andrei.pozolo...@gmail.com
   Cc: Stephen Connolly stephen.alan.conno...@gmail.com
   Date: Sun 24 Mar 2013 11:36:04 AM CDT
Andrei,
   
First of all I'm only talking about the definition of root project,
not about release stuff yet, because this has already consequences
 for
other plugins as well.
Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
should see that it does match your start-from-any-module.
If this will be the component for plugins (and maybe other projects)
which contains the actual definitions and transformations, we have a
good place to document it and to refer to.
   
Robert
   
[1]
   
  
 
 http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup#l39
   
   
Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
andrei.pozolo...@gmail.com:
   
Robert, Stephen:
   
1) from my experience release root /  top-to-bottom / monolithic 
  is a
wrong approach.
please consider instead start-from-any-module / from-bottom-up /
incremental approach, as implemented here:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
   
2) it would be good to have some wiki page somewhere to flesh out
 all
assumptions that currently go into release
as well as to list the use cases people really need. here is one of
 my
use cases:
   
  
 
 https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
   
   
Andrei
   
 Original Message 
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 09:42:27 AM CDT
Hi Stephen,
   
I've just checked your code.
Most interesting is our difference of the definition releaseRoot
  (or
in my case rootProject, I think we mean the same thing with it).
If I'm correct you base it on the existence of the scm-section
 and
if it has ever been released (assuming a specific scm comment).
MRELEASE-814[1] is probably a good example for which this strategy
won't work.
I try to base it on the parent/module relationship.
   
Although this looks close related to MRELEASE-516[2] it is
 actually a
complete other issue.
The problem I have with MRELEASE-516 is that it's not the
plug-and-play



 --
 Sent from my phone

Re: Multi-project releases

[Jeff Jensen]

I am not aware of a Maven feature to fully ignore them other than -N with
the tag caveat.  When I've done what you asked, I did not miss a Maven
feature to do so.  You could temporarily move the module dirs or release
the parent in a new location without the modules (-N is still your friend
to accomplish that so Maven does not try to process the listed modules).
 Depending how you release (e.g. manually, via CI job), having a release
area separate from the dev area is a good idea anyway to prevent hassles
with your dev work (while release plugin prevents releasing with
uncommitted work, it's nice to not have to worry about *anything* by
performing release in a clean area - a release CI job or separate local
checkout).



On Sun, Mar 24, 2013 at 3:24 PM, Andrei Pozolotin 
andrei.pozolo...@gmail.com wrote:

 I do not mind - children being part of the tag .

 so what is the way to release a parent w/o its modules?

  Original Message 
 Subject: Re: Multi-project releases
 From: Stephen Connolly stephen.alan.conno...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Date: Sun 24 Mar 2013 02:30:10 PM CDT
  That's still going to result in all the children being part of the tag
  though
 
  On Sunday, 24 March 2013, Jeff Jensen wrote:
 
  -N
  Same for other operations to not recurse into children/modules.
 
 
  On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin 
  andrei.pozolo...@gmail.com javascript:; wrote:
 
  *Robert*
 
  unrelated question, may be you can clarify: in the current
  maven-release-plugin
  what is the way to release parent w/o releasing its modules?
 
  Thank you,
 
  Andrei
 
   Original Message 
  Subject: Re: Multi-project releases
  From: Robert Scholte rfscho...@apache.org
  To: Maven Developers List dev@maven.apache.org, Andrei Pozolotin
  andrei.pozolo...@gmail.com
  Cc: Stephen Connolly stephen.alan.conno...@gmail.com
  Date: Sun 24 Mar 2013 11:36:04 AM CDT
  Andrei,
 
  First of all I'm only talking about the definition of root project,
  not about release stuff yet, because this has already consequences for
  other plugins as well.
  Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
  should see that it does match your start-from-any-module.
  If this will be the component for plugins (and maybe other projects)
  which contains the actual definitions and transformations, we have a
  good place to document it and to refer to.
 
  Robert
 
  [1]
 
 
 http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup#l39
 
  Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
  andrei.pozolo...@gmail.com:
 
  Robert, Stephen:
 
  1) from my experience release root /  top-to-bottom / monolithic 
  is a
  wrong approach.
  please consider instead start-from-any-module / from-bottom-up /
  incremental approach, as implemented here:
  https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
 
  2) it would be good to have some wiki page somewhere to flesh out all
  assumptions that currently go into release
  as well as to list the use cases people really need. here is one of
 my
  use cases:
 
 
 https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
 
  Andrei
 
   Original Message 
  Subject: Re: Multi-project releases
  From: Robert Scholte rfscho...@apache.org
  To: Maven Developers List dev@maven.apache.org
  Date: Sun 24 Mar 2013 09:42:27 AM CDT
  Hi Stephen,
 
  I've just checked your code.
  Most interesting is our difference of the definition releaseRoot
  (or
  in my case rootProject, I think we mean the same thing with it).
  If I'm correct you base it on the existence of the scm-section and
  if it has ever been released (assuming a specific scm comment).
  MRELEASE-814[1] is probably a good example for which this strategy
  won't work.
  I try to base it on the parent/module relationship.
 
  Although this looks close related to MRELEASE-516[2] it is actually
 a
  complete other issue.
  The problem I have with MRELEASE-516 is that it's not the
  plug-and-play
 
 

Re: Logging

[Jeff Jensen]

On Sun, Dec 9, 2012 at 6:51 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On Sunday, 9 December 2012, Kristian Rosenvold wrote:

  2012/12/9 Olivier Lamy ol...@apache.org javascript:;:
   Perso I'm fine using log4j2.
   I use the branch I pushed for some weeks now and I'm happy.
   Log4j2 has quickly added a feature I needed and release it.
   Furthermore I'm fine working with an Apache community in case of any
   issue we could have.
 
  I'm not entirely sure I follow where this discussion is actually
  going,  but I'm firmly opposed
  to including a brand new logging framework as default in m3.
 
 
 +1


+1
I also prefer Logback if sfl4j-simple doesn't have enough features.

Re: 3.1.0 decision making

[Jeff Jensen]

Milestones are great idea, and there has already been a few (just named the
same! :-).

+1 for 3.1.0

Nice infra improvements including SLF4J.  Appreciating you patiently RM'ing
this Jason...
(and +1 for Logback; haven't used Log4j in 4 years).


On Sat, Dec 1, 2012 at 2:29 PM, Jason van Zyl ja...@tesla.io wrote:

 I will cut the release :-)

 But I don't think the milestones are a bad idea. It's a clear indicator of
 what it is and we have already seen one case where something is not going
 to work. Maybe during the milestones we can figure out how not to break
 Sonar which would be nice. It might give us a chance to see if the logging
 changes punch anyone else in the face which is also not a bad thing.

 But the release is coming, fear not.

 On Dec 1, 2012, at 12:22 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  -1 for 3.1.0-m1
 
  +1 for 3.1.0
 
  Let's just stop faffing about and get cutting releases already
 
  -Stephen
 
 
  On 1 December 2012 20:17, Robert Scholte rfscho...@apache.org wrote:
 
  +1 for 3.1.0-m1
 
  Robert
 
  Op Sat, 01 Dec 2012 19:32:35 +0100 schreef Benson Margulies 
  bimargul...@gmail.com:
 
 
  And +1 to Mark for noting that we don't veto releases, which is
  something I'd meant to add in as a reminder.
 
 
 
  On Sat, Dec 1, 2012 at 1:08 PM, Mark Struberg strub...@yahoo.de
 wrote:
 
  +1 for 3.1.0-m1
 
 
  LieGrue,
  strub
 
 
 
  - Original Message -
 
  From: Hervé BOUTEMY herve.bout...@free.fr
  To: Maven Developers List dev@maven.apache.org
  Cc:
  Sent: Saturday, December 1, 2012 7:03 PM
  Subject: Re: 3.1.0 decision making
 
  Le samedi 1 décembre 2012 18:52:51 Dennis Lundberg a écrit :
 
  I would -1 any suggestion to start using the beta moniker
 
  again, at
 
  least for the changes made this far.
 
  I completely agree
  would it be more a milestone, to show the stable but work in
  progress state?
  3.1.0-m1?
 
  --**--**
  -
  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org
 dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  --**--**
  -
  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org
 dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 --**--**-
  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org
 dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 --**--**-
  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org
 dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 

 Thanks,

 Jason

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

 A man enjoys his work when he understands the whole and when he
 is responsible for the quality of the whole

  -- Christopher Alexander, A Pattern Language

Re: Re-spinning 3.1.0

[Jeff Jensen]

On Sat, Dec 1, 2012 at 2:39 PM, Olivier Lamy ol...@apache.org wrote:

 Hi,

 Why do we have to force our users to a specific logging implementation
 than we choose ?


Doesn't the product have to establish a default?  Isn't that the one
forced on the users?

Substitution of the default for alternate implementation is a feature.

I think first establish a solid default and then consider a feature that
enables changing by the user.

The default has not been decided yet, as far as I can discern.  Call for a
vote on the default logger implementation.


We can propose variants and at least one as a workaround to maybe fix
 sonar issue.

 So what I do in the branch called dynamic-logging-impl is a dynamic
 way of loading the implementation users prefers (default is log4j2).
 It's just a matter of modifying MAVEN_OPTS=-Dmaven.logger.impl=log4j2
 or slf4-simple or logback (and thanks to our home made osgi
 classworld :-) )

 Note: with this implementation is possible to use any other slf4j impl
 you want (IMHO good enhancement for ci servers which want to route
 logs somewhere)
 It's just a matter of adding a realm in m2.conf

 [thegreat-new-a-la-mode-slf4j-impl]
 load   path to my great new slf4j impl/*.jar

 Then
 MAVEN_OPTS=-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl

 Anyway just tested with sonar and
 [ERROR] Failed to execute goal
 org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
 project hello-world: Can not execute Sonar:
 ch.qos.logback.classic.LoggerContext cannot be cast to
 ch.qos.logback.classic.LoggerContext
 I always love such classloader message :-)

 So I need to investigate a little bit more but not so far from having
 that for sonar
 BTW works fine for classic use case.

 If you want to test that a build is available here:
 http://people.apache.org/~olamy/maven/dynamic-logging-impl/

 2012/12/1 Jason van Zyl ja...@tesla.io:
 
  On Dec 1, 2012, at 12:17 AM, Arnaud Héritier aherit...@gmail.com
 wrote:
 
  Hi Jason,
 
   Couldn't we have a look at olamy's log4j2 branch to see if we could
  sanitize / merge it to propose at least one change for the end user
  and demonstrate the interest of the change about logs : a colorized
  console.
 
  Not without discussion about the implementation. To me the obvious
 choice is Logback and using Log4J2 makes no sense. Olivier disagrees so
 there will be a discussion. I've been working on the release but I plan to
 make a branch using Logback so we have a basis for discussion.
 
 
   I remember you did that in mvnsh/teslashell a long time ago (as an
  extension ?) and perhaps it could be easy to add properly this feature
  in 3.1.0 (otherwise it won't be before a 3.2.0).
 
   Myself I'm using a 3.1.0 fork with this patch and I' m really
  satisfied (it's so good to quickly see highlighted warning and errors
  ). I merged it back in the last 3.1.0 tag you did without issue
 
   Wdyt?
 
  Just as easy with Logback, the only difference being Logback is a mature
 solution. So I'm sure there's going to be a discussion.
 
 
  -
  Arnaud
 
  Le 1 déc. 2012 à 00:20, Jason van Zyl ja...@tesla.io a écrit :
 
  I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
 
  Anyone want to add anything or discuss anything before I spin this?
 I'm not in any rush so if folks want to talk about logging we can. But
 given the fact once SLF4J initializes it can't change the implementation
 plugins integrating with Maven need to use the implementation we choose.
 This is how everything else in the world that integrates SLF4J has to
 operate so I don't really see us being any different.
 
  I'll wait until tomorrow to re-spin.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  Simplex sigillum veri. (Simplicity is the seal of truth.)
 
 
 
 
 

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

Re: fixing transfer listener in trunk

[Jeff Jensen]

On Sun, Nov 11, 2012 at 7:59 AM, Jesse McConnell
jesse.mcconn...@gmail.com wrote:
 On Sun, Nov 11, 2012 at 6:35 AM, Anders Hammar and...@hammar.net wrote:
 Here's my suggestion:

 We keep the current state where we have the new logging API (slf4j) and the
 System.out style implementation. Then we (Olivier?) create a JIRA ticket
 for moving to a different logging implementation using a more flexible
 logging framework. Then we discuss the benefits of doing that move. We
 could even ask the users if it is something that people even want.


 +1 that sounds reasonable and is akin to what we do in jetty, though
 our stdout impl has even less brains and only gets its brains when
 slf4j-api is detected in classpath

 cheers,
 jesse

+1
Good plan.
And having used it similarly, slf4j-simple is a good, small, default
logger choice.

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

Re: [VOTE] Use aether 1.13 and sisu 2.3.0 as dependencies of Apache Maven

[Jeff Jensen]

+1 (non-binding)


On Thu, Nov 10, 2011 at 9:53 AM, Olivier Lamy ol...@apache.org wrote:
 Hello,

 Since last vote things have changed:
 * aether is in incubation process @eclipse
 * sisu is in incubation process @eclipse

 Due to the fact that those process can be long before having an
 official release from eclipse namespace, some new features are
 blocked.

 I propose to upgrade to:
 * aether 1.13
 * sisu 2.3.0

 Note: when a release will be available @eclipse, we will upgrade to
 this release. The technical details can be discussed later especially
 if we need to do some package changes.

 [+1] I'm in favor of this upgrade and the other upgrade when release
 will be available under eclipse.org governance
 [+0] I don't care, do what you want.
 [-1] I'm against because  (please explain)

 The vote open is open for 6 days as we are near week end (with maybe
 bank holidays in some countries) and some people have too much beer in
 ApacheCon :-).

 Here my +1

 Thanks,
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

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



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

Re: Is Maven Site Plugin 3.0-beta-4 ready for release?

[Jeff Jensen]

We've been running the beta for (I don't know how many) months, and
works better than it ever has.  I agree with Lukas; release it.


On Thu, Jul 7, 2011 at 2:26 AM, Lukas Theussl ltheu...@apache.org wrote:


 Hervé BOUTEMY wrote:

 the rationale behind not going directly to 3.0 was that site plugin is
 hard to
 test, particularly now that it is both compatible with Maven 2 and Maven
 3,
 which is something really new and probably tested by only a few of us

 I don't quite agree with this rationale. Ease of testing is not a criterion
 for version naming IMO. The main criterion is how many *known* bugs and
 missing features there are left. So what are the open issues that we are
 aware about? If there are none or only a few, then let's call it final. If
 the people who are working on the release feel that the stuff is stable
 (which I do) then why not release it as such?


 sure, 3.0-beta-4 should at least be 3.0-RC-1, but perhaps not 3.0
 immediately:
 I'm pretty sure we'll find some important problems when a lot of people
 try it
 seriously

 The most efficient way to get people to test something, is to release it! :)


 There are real important factors to test, which makes a lot of
 combinations:
 - Maven version: 2.2.x, 3.x
 - OS
 - phases: site, site-deploy, site:stage-deploy (run? jar?)

 should all be covered by our ITs:

 https://builds.apache.org/job/maven-site-plugin-2.x/
 https://builds.apache.org/job/maven-site-plugin-3.x/
 https://builds.apache.org/job/maven-site-plugin-3.x-m2/

 I am aware that there are some important differences though, (some ITs are
 skipped with m3, or executed with different parameters), which would be
 important to review and document I guess.

 - deploy protocol: scp, webdav

 not really a site-plugin concern, rather wagon

 - report plugins used: I don't know how to describe without being a
 mess...

 We (devs) cannot test everything, even the more important it is to get user
 feedback.

 But at least, with maven-site-plugin 2.3 being out and almost equivalent
 (particularly when it comes to Doxia and Doxia Site Tools), we have a
 clear
 line to check if a problem with 3.0 is a regression from 2.3 or not

 so this would rather be an argument in favour of 3.0...?

 Then I'd better be for 3.0-RC-1 for the moment.

 I will support whatever the release manager decides, but I would prefer
 3.0-final with a number of bug fix releases following, rather than an open
 interval of [RC-1, RC-2,...). More people will test the final release and
 there will be more pressure on us to push for bug-fix versions (which is
 good! :) ).

 -Lukas


 Such a discussion happened a lot of time in the past: 3.0 and 3.0-RC-1 are
 good choices, but not 3.0-beta-4
 The release manager can choose and I'll be with him.
 But IMHO we need to ask for people to tell what conditions they tested.

 Regards,

 Hervé

 Le mercredi 6 juillet 2011, Olivier Lamy a écrit :

 No objections from me.
 beta cycle has started long time ago.

 2011/7/6 Lukas Theusslltheu...@apache.org:

 Any objections to making this 3.0-final? AFAICT the plugin is
 functionally (almost) equivalent to the 2.x trunk version (only
 exception is MSITE-484?), so why keep the beta?

 -Lukas

 Dennis Lundberg wrote:

 Hi

 What's the status on this? I know Hervé worked on extracting a shared
 component (maven-reporting-exec) for the Maven 3 specific parts of the
 plugin. Did you finish with that?

 I would like to push for a release of Site Plugin 3 shortly. The only
 issue left according to JIRA is this one:

 http://jira.codehaus.org/browse/MSITE-560

 There are a lot stuff fixed already, and we need to get this out so
 that
 Maven 3 users can benefit from them. Do we want/need to add anything
 more before the release?

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


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


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




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

PMC change explanation?

[Jeff Jensen]

Is there a forthcoming explanation for a seemingly Maven PMC shakeup?
I find it odd that consistently excellent contributors such as Lukas,
Brian, et al are suddenly not on the Maven PMC.  This is concerning as
these are people who have drastically improved and moved Maven
forward.  It's very concerning that a heavy committer such as Benjamin
is no longer committing as he has done very useful, fantastic work.
These events are very concerning for the forward progress of Maven.
The strong temptations for competitive products, a la Gradle, do not
allow Maven progress to stop; particularly the best progress to date
of the past year.  These events are detrimental.  For us uninformed,
what happened, why is it good, what is the plan forward behind this?

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

Re: org.codehaus.plexus.util.CollectionUtils.intersection

[Jeff Jensen]

With what JUnit version?  I just tested is() and hasItems() and the
failure reporting message is 99% the same as assertEquals() with JUnit
4.8.2.  They both display toString()s of the expected and actuals,
just prefixed with different names/words.  What am I missing?


On Sun, Jun 12, 2011 at 2:52 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 At the very leaset

 assertThat(actual, is(expected));

 gives better diagnostics

 then there is

 assertThat(actual, not(is(unexpected));

 nice ones are

 assertThat(actual, hasItems(expectedContents));

 On 12 June 2011 20:43, Benson Margulies bimargul...@gmail.com wrote:
 Next class. I haven't learned that one yet.

 On Sun, Jun 12, 2011 at 3:39 PM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
 On 12 June 2011 20:23, Benson Margulies bimargul...@gmail.com wrote:
 I think I've written a unit test for the contract of this function as
 written in the javadoc, but it fails. The intersection function
 returns an empty collection when the inputs most definitely have a
 non-null intersection. What am I missing?

    @SuppressWarnings( rawtypes )
    @Test
    public void testIntersection() throws Exception {
        CollectionString c1 = new ArrayListString();
        CollectionString c2 = new ArrayListString();
        /*
         * An exhaustive black box test here
         * would involve generating a great deal of data,
         * perhaps even different sizes and collection classes.
         */

        c1.add(red);
        c1.add(blue);
        c1.add(green);
        c1.add(socialist);
        c1.add(red);
        c1.add(purple);
        c1.add(porpoise);
        c1.add(green);
        c1.add(blue);
        c1.add(gray);

        c1.add(blue);
        c1.add(12);
        c1.add(15);
        c1.add(blue);
        c1.add(porpoise);
        c1.add(33.3);
        c1.add(jabberwock);

        MultisetString correct = HashMultiset.create();
        correct.add( blue );
        correct.add( blue );
        correct.add(  porpoise );

        @SuppressWarnings( unchecked )
        CollectionString res = CollectionUtils.intersection( c1, c2 );
        MultisetString actual = HashMultiset.create();
        actual.addAll(res);
        assertEquals( correct, actual );

 I hate the bog standard assertEquals on collections... if you'd used
 the new style assertThat( actual, ... ) with the appropriate matcher
 you'd have better debug info ;-)


    }

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



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



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



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




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

Re: svn commit: r1077924 - in /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site: AbstractDeployMojo.java SiteDeployMojo.java SiteStageDeployMojo.java

[Jeff Jensen]

Works great again... thank you Lukas! :-)


On Wed, Mar 9, 2011 at 2:04 PM, Lukas Theussl ltheu...@apache.org wrote:

 snapshots are deployed by now, let me know if it helps...

 -Lukas


 Jeff Jensen wrote:

 Thanks Lukas!  Sorry - haven't had a moment to get source and build it
 (finishing features for prospect demo).  If you can get it deployed,
 it will test itself though! :-)


 On Tue, Mar 8, 2011 at 3:15 PM, Lukas Theusslltheu...@apache.org  wrote:

 can you check if my last commits fixed it? However, you have to build it
 yourself as I'm getting a 500 when trying to deploy to apache right now,
 so
 no snaps are deployed yet.

 HTH,
 -Lukas


 Jeff Jensen wrote:

 Yes, :-)  3.0-beta-4-SNAPSHOT.  The fixes over the past months have
 been very helpful, so I'm using the snapshot.

 Sorry for my wrong word choice; you correctly suggest the deploy part,
 not site gen part.  I have a Hudson job that runs mvn site-deploy
 -e, so I accidentally combined the two phases as one site gen.

 Stack trace from Hudson log:

 08:23:15  [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:deploy
 (default-deploy) on project yyy-parent: Missing site information in
 the distribution management of the project Parent Maven POM
 (com.xxx:xxx-maven-parent:1.0.0-SNAPSHOT) -    [Help 1]
 08:23:15  org.apache.maven.lifecycle.LifecycleExecutionException:
 Failed to execute goal
 org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:deploy
 (default-deploy) on project yyy-parent: Missing site information in
 the distribution management of the project Parent Maven POM
 (com.xxx:xxx-maven-parent:1.0.0-SNAPSHOT)
 08:23:15        at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
 08:23:15        at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 08:23:15        at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 08:23:15        at

 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
 08:23:15        at

 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
 08:23:15        at

 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
 08:23:15        at

 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
 08:23:15        at
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
 08:23:15        at
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
 08:23:15        at
 org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
 08:23:15        at
 org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
 08:23:15        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
 08:23:15        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
 08:23:15        at

 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 08:23:15        at

 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 08:23:15        at java.lang.reflect.Method.invoke(Method.java:597)
 08:23:15        at

 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
 08:23:15        at

 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
 08:23:15        at

 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
 08:23:15        at

 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 08:23:15  Caused by: org.apache.maven.plugin.MojoExecutionException:
 Missing site information in the distribution management of the project
 Parent Maven POM (com.xxx:xxx-maven-parent:1.0.0-SNAPSHOT)
 08:23:15        at

 org.apache.maven.plugins.site.AbstractDeployMojo.getSite(AbstractDeployMojo.java:701)
 08:23:15        at

 org.apache.maven.plugins.site.SiteDeployMojo.getDeployRepositoryID(SiteDeployMojo.java:52)
 08:23:15        at

 org.apache.maven.plugins.site.AbstractDeployMojo.execute(AbstractDeployMojo.java:155)
 08:23:15        at

 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
 08:23:15        at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
 08:23:15        ... 19 more


 On Tue, Mar 8, 2011 at 1:18 PM, Lukas Theusslltheu...@apache.org
  wrote:

 Hi Jeff,

 I deduce you are testing my current development version...?  ;)

 I don't see how this particular commit could have broken site
 generation
 as
 it only concerns the DeployMojo. However, I see that it could break
 site:stage-deploy, is this what you are seeing?

 I don't exclude that I broke something somewhere else, but I need more
 info
 to track it down, a stack trace or better a test project would help.

 Cheers,
 -Lukas


 Jeff Jensen wrote:

 Hi Lukas!

 I have a question on this commit

Re: svn commit: r1077924 - in /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site: AbstractDeployMojo.java SiteDeployMojo.java SiteStageDeployMojo.java

[Jeff Jensen]

Thanks Lukas!  Sorry - haven't had a moment to get source and build it
(finishing features for prospect demo).  If you can get it deployed,
it will test itself though! :-)


On Tue, Mar 8, 2011 at 3:15 PM, Lukas Theussl ltheu...@apache.org wrote:

 can you check if my last commits fixed it? However, you have to build it
 yourself as I'm getting a 500 when trying to deploy to apache right now, so
 no snaps are deployed yet.

 HTH,
 -Lukas


 Jeff Jensen wrote:

 Yes, :-)  3.0-beta-4-SNAPSHOT.  The fixes over the past months have
 been very helpful, so I'm using the snapshot.

 Sorry for my wrong word choice; you correctly suggest the deploy part,
 not site gen part.  I have a Hudson job that runs mvn site-deploy
 -e, so I accidentally combined the two phases as one site gen.

 Stack trace from Hudson log:

 08:23:15  [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:deploy
 (default-deploy) on project yyy-parent: Missing site information in
 the distribution management of the project Parent Maven POM
 (com.xxx:xxx-maven-parent:1.0.0-SNAPSHOT) -  [Help 1]
 08:23:15  org.apache.maven.lifecycle.LifecycleExecutionException:
 Failed to execute goal
 org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:deploy
 (default-deploy) on project yyy-parent: Missing site information in
 the distribution management of the project Parent Maven POM
 (com.xxx:xxx-maven-parent:1.0.0-SNAPSHOT)
 08:23:15        at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
 08:23:15        at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 08:23:15        at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 08:23:15        at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
 08:23:15        at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
 08:23:15        at
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
 08:23:15        at
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
 08:23:15        at
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
 08:23:15        at
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
 08:23:15        at
 org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
 08:23:15        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
 08:23:15        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
 08:23:15        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method)
 08:23:15        at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 08:23:15        at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 08:23:15        at java.lang.reflect.Method.invoke(Method.java:597)
 08:23:15        at
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
 08:23:15        at
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
 08:23:15        at
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
 08:23:15        at
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 08:23:15  Caused by: org.apache.maven.plugin.MojoExecutionException:
 Missing site information in the distribution management of the project
 Parent Maven POM (com.xxx:xxx-maven-parent:1.0.0-SNAPSHOT)
 08:23:15        at
 org.apache.maven.plugins.site.AbstractDeployMojo.getSite(AbstractDeployMojo.java:701)
 08:23:15        at
 org.apache.maven.plugins.site.SiteDeployMojo.getDeployRepositoryID(SiteDeployMojo.java:52)
 08:23:15        at
 org.apache.maven.plugins.site.AbstractDeployMojo.execute(AbstractDeployMojo.java:155)
 08:23:15        at
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
 08:23:15        at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
 08:23:15        ... 19 more


 On Tue, Mar 8, 2011 at 1:18 PM, Lukas Theusslltheu...@apache.org  wrote:

 Hi Jeff,

 I deduce you are testing my current development version...?  ;)

 I don't see how this particular commit could have broken site generation
 as
 it only concerns the DeployMojo. However, I see that it could break
 site:stage-deploy, is this what you are seeing?

 I don't exclude that I broke something somewhere else, but I need more
 info
 to track it down, a stack trace or better a test project would help.

 Cheers,
 -Lukas


 Jeff Jensen wrote:

 Hi Lukas!

 I have a question on this commit, as it causes our site gen to now fail.

 With the following change:

 +        if ( site == null )
 +        {
 +            throw new MojoExecutionException(
 +                Missing site information in the distribution
 management

Re: svn commit: r1077924 - in /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site: AbstractDeployMojo.java SiteDeployMojo.java SiteStageDeployMojo.java

[Jeff Jensen]

Hi Lukas!

I have a question on this commit, as it causes our site gen to now fail.

With the following change:

 +if ( site == null )
 +{
 +throw new MojoExecutionException(
 +Missing site information in the distribution management of 
 the project  + name );
 +}

the following use case configuration encounters the above exception:
 - a project parent pom has a distributionManagementsite element
(modules of course inherit it)
 - a corporate parent pom does not have a distributionManagementsite element

We never run site gen for the corporate parent pom, so any
distributionManagementsite element added will make it work but is
unneeded/fake.

So wondering if this configuration use case was considered and the
correct answer is to add a fake site element to the corporate
parent or possibly this check for site definition needs tweaking (can
it consider the effective one?)?


On Fri, Mar 4, 2011 at 6:58 AM,  ltheu...@apache.org wrote:
 Author: ltheussl
 Date: Fri Mar  4 12:58:01 2011
 New Revision: 1077924

 URL: http://svn.apache.org/viewvc?rev=1077924view=rev
 Log:
 refactor: re-use getSite() so we properly catch null values also in 
 stage-deploy

 Modified:
    
 maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractDeployMojo.java
    
 maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteDeployMojo.java
    
 maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteStageDeployMojo.java

 Modified: 
 maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractDeployMojo.java
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractDeployMojo.java?rev=1077924r1=1077923r2=1077924view=diff
 ==
 --- 
 maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractDeployMojo.java
  (original)
 +++ 
 maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractDeployMojo.java
  Fri Mar  4 12:58:01 2011
 @@ -26,6 +26,8 @@ import java.util.Locale;

  import org.apache.maven.artifact.manager.WagonConfigurationException;
  import org.apache.maven.artifact.manager.WagonManager;
 +import org.apache.maven.model.DistributionManagement;
 +import org.apache.maven.model.Site;
  import org.apache.maven.plugin.MojoExecutionException;
  import org.apache.maven.plugin.logging.Log;
  import org.apache.maven.project.MavenProject;
 @@ -552,4 +554,43 @@ public abstract class AbstractDeployMojo

         return parent;
     }
 +
 +    /**
 +     * Extract the distributionManagment site from the given MavenProject.
 +     *
 +     * @param project the MavenProject. Not null.
 +     *
 +     * @return the project site. Not null.
 +     *      Also site.getUrl() and site.getId() are guaranteed to be not 
 null.
 +     *
 +     * @throws MojoExecutionException if any of the site info is missing.
 +     */
 +    protected static Site getSite( final MavenProject project )
 +        throws MojoExecutionException
 +    {
 +        final String name = project.getName() +  (
 +            + project.getGroupId() + : + project.getArtifactId() + : + 
 project.getVersion() + );
 +
 +        final DistributionManagement distributionManagement = 
 project.getDistributionManagement();
 +
 +        if ( distributionManagement == null )
 +        {
 +            throw new MojoExecutionException( Missing distribution 
 management in project  + name );
 +        }
 +
 +        final Site site = distributionManagement.getSite();
 +
 +        if ( site == null )
 +        {
 +            throw new MojoExecutionException(
 +                Missing site information in the distribution management of 
 the project  + name );
 +        }
 +
 +        if ( site.getUrl() == null || site.getId() == null )
 +        {
 +            throw new MojoExecutionException( Missing site data: specify 
 url and id for project  + name );
 +        }
 +
 +        return site;
 +    }
  }

 Modified: 
 maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteDeployMojo.java
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteDeployMojo.java?rev=1077924r1=1077923r2=1077924view=diff
 ==
 --- 
 maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteDeployMojo.java
  (original)
 +++ 
 maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteDeployMojo.java
  Fri Mar  4 12:58:01 2011
 @@ -19,10 +19,8 @@ package org.apache.maven.plugins.site;
  * under the License.
  */

 -import org.apache.maven.model.DistributionManagement;
  import org.apache.maven.model.Site;
  import 

Re: svn commit: r1077924 - in /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site: AbstractDeployMojo.java SiteDeployMojo.java SiteStageDeployMojo.java

[Jeff Jensen]

Yes, :-)  3.0-beta-4-SNAPSHOT.  The fixes over the past months have
been very helpful, so I'm using the snapshot.

Sorry for my wrong word choice; you correctly suggest the deploy part,
not site gen part.  I have a Hudson job that runs mvn site-deploy
-e, so I accidentally combined the two phases as one site gen.

Stack trace from Hudson log:

08:23:15  [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:deploy
(default-deploy) on project yyy-parent: Missing site information in
the distribution management of the project Parent Maven POM
(com.xxx:xxx-maven-parent:1.0.0-SNAPSHOT) - [Help 1]
08:23:15  org.apache.maven.lifecycle.LifecycleExecutionException:
Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-4-SNAPSHOT:deploy
(default-deploy) on project yyy-parent: Missing site information in
the distribution management of the project Parent Maven POM
(com.xxx:xxx-maven-parent:1.0.0-SNAPSHOT)
08:23:15at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
08:23:15at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
08:23:15at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
08:23:15at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
08:23:15at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
08:23:15at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
08:23:15at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
08:23:15at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
08:23:15at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
08:23:15at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
08:23:15at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
08:23:15at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
08:23:15at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
08:23:15at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
08:23:15at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
08:23:15at java.lang.reflect.Method.invoke(Method.java:597)
08:23:15at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
08:23:15at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
08:23:15at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
08:23:15at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
08:23:15  Caused by: org.apache.maven.plugin.MojoExecutionException:
Missing site information in the distribution management of the project
Parent Maven POM (com.xxx:xxx-maven-parent:1.0.0-SNAPSHOT)
08:23:15at 
org.apache.maven.plugins.site.AbstractDeployMojo.getSite(AbstractDeployMojo.java:701)
08:23:15at 
org.apache.maven.plugins.site.SiteDeployMojo.getDeployRepositoryID(SiteDeployMojo.java:52)
08:23:15at 
org.apache.maven.plugins.site.AbstractDeployMojo.execute(AbstractDeployMojo.java:155)
08:23:15at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
08:23:15at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
08:23:15... 19 more


On Tue, Mar 8, 2011 at 1:18 PM, Lukas Theussl ltheu...@apache.org wrote:

 Hi Jeff,

 I deduce you are testing my current development version...?  ;)

 I don't see how this particular commit could have broken site generation as
 it only concerns the DeployMojo. However, I see that it could break
 site:stage-deploy, is this what you are seeing?

 I don't exclude that I broke something somewhere else, but I need more info
 to track it down, a stack trace or better a test project would help.

 Cheers,
 -Lukas


 Jeff Jensen wrote:

 Hi Lukas!

 I have a question on this commit, as it causes our site gen to now fail.

 With the following change:

 +        if ( site == null )
 +        {
 +            throw new MojoExecutionException(
 +                Missing site information in the distribution management
 of the project  + name );
 +        }

 the following use case configuration encounters the above exception:
  - a project parent pom has adistributionManagementsite  element
 (modules of course inherit it)
  - a corporate parent pom does not have adistributionManagementsite
  element

 We never run site gen for the corporate parent pom, so any
 distributionManagementsite  element added will make it work but is
 unneeded/fake.

 So wondering if this configuration use case was considered and the
 correct answer is to add

Re: [VOTE] Release Maven Surefire Plugin version 2.7.1

[Jeff Jensen]

+1 (non-binding)


On Thu, Dec 23, 2010 at 2:40 AM, Lukas Theussl ltheu...@apache.org wrote:

 +1

 -Lukas


 Kristian Rosenvold wrote:

 Hi,

 We solved 10 issues:

 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=17014

 There are still a couple of issues left in JIRA:

 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC

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

 Staging site: (Sync pending)
 http://maven.apache.org/plugins/maven-surefire-plugin-2.7.1/
 http://maven.apache.org/plugins/maven-failsafe-plugin-2.7.1/
 http://maven.apache.org/plugins/maven-surefire-report-plugin-2.7.1/
 http://maven.apache.org/surefire/staging/

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

 Vote open for 72 hours.

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

 And here's my +1


 Kristian

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


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




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

Re: [VOTE] Release Maven Surefire Plugin version 2.7, Take 2

[Jeff Jensen]

+1 (non-binding)

This one works great too!


On Thu, Dec 16, 2010 at 5:38 AM, chemit che...@codelutin.com wrote:
 On Thu, 16 Dec 2010 11:46:40 +0100
 Kristian Rosenvold kristian.rosenv...@gmail.com wrote:

 +1 (non binding)



 --
 Tony Chemit
 
 tél: +33 (0) 2 40 50 29 28
 email: che...@codelutin.com
 http://www.codelutin.com

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




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

Re: [VOTE] Release Maven Surefire Plugin version 2.7

[Jeff Jensen]

Which clearly explains why, if we reduced the logging output level
from DEBUG to WARN, the OOM did not occur with smaller values of -Xmx.
 That was baffling at the time...  Wonderful fix.  Thanks!  :-)  (this
problem was the worst for release via parent pom; not happy to
-DskipTests on release or ignore uncommitted local changes!)


On Wed, Dec 15, 2010 at 8:21 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
 Sorry for chatting on the vote thread here, but fixing the TeeStream
 memory leak probably also has a noticeable performance impact for users
 with large numbers of tests and/or lots of console output;

 It turned out for test number N, any stdout/stderr output would be
 duplicated into N tee-streams, and they were'nt going away.
 That's a lot of memory going nowhere.

 Kristian

 on., 15.12.2010 kl. 08.g08 -0600, skrev Jeff Jensen:
 +1 (non-binding)

 We can finally run a full build with tests from the parent with this
 version (would OOM unless -Xmx was set to nearly 2G!).  :-)


 On Wed, Dec 15, 2010 at 2:01 AM, chemit che...@codelutin.com wrote:
  On Wed, 15 Dec 2010 00:21:49 +0100
  Kristian Rosenvold kristian.rosenv...@gmail.com wrote:
 
  +1 (none binding)
 
  Works fine on our project.
 
  Thanks!
 
  Highlights of the release:
  * Pluggable providers are now supported, as well as manual provider
  selection
  * 2.7 is significantly smaller and lighter than earlier 2.x versions
  (Only 30% of the download size)
  * A large chunk of the highest voted issues have been fixed.
  * Some performance optimizations for forkMode=always
  * Significant cleanup/simplification of the code-base
 
 
  We solved 22 issues:
  http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=16691
 
  There are still a couple of issues left in JIRA:
  http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-023/
 
  Staging site: (Sync pending)
  http://maven.apache.org/plugins/maven-surefire-plugin-2.7/
  http://maven.apache.org/plugins/maven-failsafe-plugin-2.7/
  http://maven.apache.org/plugins/maven-surefire-report-plugin-2.7/
  http://maven.apache.org/surefire/staging/
 
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  And here's my +1
 
  Kristian
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 
  --
  Tony Chemit
  
  tél: +33 (0) 2 40 50 29 28
  email: che...@codelutin.com
  http://www.codelutin.com
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 

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




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




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

RE: [VOTE] Release Apache Maven 3.0-beta-3 (take 2)

[Jeff Jensen]

+1 (non-binding)
better, stronger, faster :-)


-Original Message-
From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu] 
Sent: Monday, August 30, 2010 8:09 AM
To: Maven Developers List
Subject: [VOTE] Release Apache Maven 3.0-beta-3 (take 2)

Hi,

what's a better start for a week than a new fresh release :-) ? So here 
we go!

Apart from another few regression fixes, this release includes Guice and 
Aether [0] and shall help to get some more community testing on these 
new components.

Overall, we solved 19 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=166
81

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500sta
tus=1

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

Staged source and binary distros:
https://repository.apache.org/content/repositories/maven-157/org/apache/mave
n/apache-maven/3.0-beta-3/

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


[0] http://github.com/sonatype/sonatype-aether

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



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

RE: Maven 3 versions of the plugins

[Jeff Jensen]

+1
It's clear, it allows me to continue if I want to try it anyway, and I think 
there was plenty of prior discussion of it on the list.


-Original Message-
From: Kristian Rosenvold [mailto:kristian.rosenv...@gmail.com] 
Sent: Tuesday, May 18, 2010 2:57 PM
To: Maven Developers List
Subject: Re: Maven 3 versions of the plugins

The intention of the warning was to make it pretty clear that you're
running with some risk. We have already agreed that the entire
parallel feature is to be marked as experimental (although with the
explicit adding of @threadSafe to the mojos I personally think regular
parallel is good for prime time).

Fortunately most threading-related failures that happen within plugins
are quite clear-cut. When I started out with this stuff I was expecting
a lot of subtle memory model violations and stuff like that, but there
has been almost none of that. In fact, after we fixed a couple of key
problems in plexus most of the failing plugins fail fairly quickly and
on a reasonably regular basis.

The only *real* nasty I've seen so far is modello-plugin, which in its
non-thread-safe form produces errors straight out of h*ll
(generated-sources is created under random modules - sometimes
switching midway in the source generation process, making it appear to
be  compiling the wrong module). All the others I've seen as of now are
fairly mild stuff that usually fail with (some kind of) error message.

Also note that most of the corruption issues being fixed related to
http://jira.codehaus.org/browse/MSHARED-148 (which is part of JAR/EAR
vote as of yesterday) actually can occur in today's 2.2.1. The fixes
related to MSHARED-148 contain only 1 issue that is clearly parallel
only.

We want users to try this feature. Hopefully also create some pressure
in the community to make plugins @threadSafe. By the time 3.0 releases,
most of the (non-deprecated) core plugins will be @threadSafe

I'm not really heavily invested in the current solution, but if we were
to fail the build with non-threadsafe plugins I'd want an option to do
it anyway.

Isn't the current solution noisy enough ? I'm probably coming through 
as a bleeding-heart liberal here, I don't like forcing users. I think
it's mostly about controlling expectations and directing users to the
proper places...?

Kristian


ti., 18.05.2010 kl. 13.32 -0500, skrev Paul Benedict:
 Why would Maven allow parallel builds that are not thread-safe?
 Granted, it's the developer's choice to take the chance, but I just
 don't see why it's beneficial to allow builds being potentially
 corrupted unbeknownst to the builder.
 
 2010/5/17 Arnaud Héritier aherit...@gmail.com:
  In m3 if you activate the // mode and you have a plugin which isn't marked 
  as compatible you'll have a warning like that :
 
  [WARNING] *
  [WARNING] * Your build is requesting parallel execution, but project  *
  [WARNING] * contains the following plugin(s) that are not marked as   *
  [WARNING] * @threadSafe to support parallel building. *
  [WARNING] * While this /may/ work fine, please look for plugin updates*
  [WARNING] * and/or request plugins be made thread-safe.   *
  [WARNING] * If reporting an issue, report it against the plugin in*
  [WARNING] * question, not against maven-core  *
  [WARNING] *
  [WARNING] The following plugins are not marked @threadSafe in Maven Model:
  [WARNING] org.apache.maven.plugins:maven-resources-plugin:2.4.2
  [WARNING] org.apache.maven.plugins:maven-clean-plugin:2.3
  [WARNING] org.apache.maven.plugins:maven-compiler-plugin:2.0.2
  [WARNING] org.apache.maven.plugins:maven-install-plugin:2.2
  [WARNING] org.apache.maven.plugins:maven-surefire-plugin:2.4.3
  [WARNING] org.apache.maven.plugins:maven-jar-plugin:2.2
  [WARNING] org.apache.maven.plugins:maven-remote-resources-plugin:1.1
  [WARNING] org.codehaus.modello:modello-maven-plugin:1.3
 
 
  Arnaud
 
  On May 17, 2010, at 11:42 PM, Paul Benedict wrote:
 
  Lots of plugins are up for vote to be @threadSafe with Maven 3. Does
  Maven 3 have any mechanism to reject plugins prior to the versions
  being released? What happens if someone uses a Maven 2 version?
 
  Paul
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

RE: [VOTE] Release Maven PMD plugin version 2.5

[Jeff Jensen]

+1


-Original Message-
From: Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Sent: Saturday, May 01, 2010 9:35 AM
To: Maven Developers List
Subject: [VOTE] Release Maven PMD plugin version 2.5

Hi,

We solved 24 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=H
tmlversion=14419

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=proj
ect+%3D+MPMD+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide

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

Staging site:
http://maven.apache.org/plugins/maven-pmd-plugin-2.5/

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

Vote open for 72 hours.

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

Here is my +1

Regards,

Hervé

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



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

RE: [VOTE] Commit access for Kristian Rosenvold

[Jeff Jensen]

+1

-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org] 
Sent: Monday, January 04, 2010 3:47 AM
To: Maven Developers List
Subject: Re: [VOTE] Commit access for Kristian Rosenvold

+1

--
Olivier

2010/1/4 Jason van Zyl ja...@sonatype.com:
 Hi,

 I have reviewed the patches for the parallel build support and I think
they are great.

 I think we should just give Kristian access to work with Dan and other
developers who want to support this work.

 +1

 Thanks,

 Jason

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


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





-- 
Olivier

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



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

RE: [vote] Invite Stephen Connolly to join Maven committers

[Jeff Jensen]

+1


-Original Message-
From: aherit...@gmail.com [mailto:aherit...@gmail.com] On Behalf Of Arnaud
HERITIER
Sent: Sunday, September 06, 2009 6:25 PM
To: Maven Developers List
Cc: Stephen Connolly
Subject: [vote] Invite Stephen Connolly to join Maven committers

Hi all,
  I'd like to propose giving commit access to Stephen Connolly.
  He is already a committer @ Mojo for many monthes and did a great work on
several plugins.
  He is the author of the very useful versions plugin. He is working on
several others plugins like animal-sniffer.
  He's doing a job of quality (with unit and integration tests) and follows
our best practices.
  He's participating on our mailing lists for a least 2 years.
  I helped him several time to apply some patches on our plugins and shared
components.
  Now he would like to help on toolchains and adding its support in
enforcer.

  I think we need more people as involved as Stephen has been.

  Please vote. 72h +1/+0/-1

  Here is my +1.

Cheers,

Arnaud

# Arnaud Héritier
# Software Factory Manager
# eXo Platform
# http://www.exoplatform.com
# http://blog.aheritier.net


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

RE: What's block maven-toolchains-plugin getting *any* release at all?

[Jeff Jensen]

+1

-Original Message-
From: Arnaud HERITIER [mailto:aherit...@gmail.com] 
Sent: Friday, September 04, 2009 8:20 AM
To: Maven Developers List
Subject: Re: What's block maven-toolchains-plugin getting *any* release at
all?

+1 to propose you to join us as committer :-)
Arnaud

On Fri, Sep 4, 2009 at 3:08 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 +1 for Arnaud being leader

 2009/9/4 Arnaud HERITIER aherit...@gmail.com

  A leader ?
 
  On Fri, Sep 4, 2009 at 10:32 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
   Any king of release whatsoever... as long as it's not -SNAPSHOT
  
   -Stephen
  
 



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

RE: automation question

[Jeff Jensen]

Perhaps setup CI (Hudson/CruiseControl/Continuum) locally and manually invoke 
builds when desired.  Using build dependencies, you can have subsequent builds 
kick off from you manually invoking the first.  Then manually commit or 
automate?


-Original Message-
From: Oleg Gusakov [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 21, 2008 7:41 PM
To: Maven Developers List
Subject: automation question

Guys,

I find myself doing commits over and again in the following sequence:

* mvn clean install on the main reactor project to make sure all UTs 
work and install binaries
* cd to IT project, mvn clean deploy there - to run and deploy IT binaries
* cd back to the project, mvn deploy there to deploy snapshots
* svn commit -m 'blah...' to finally commit changes

Does anyone know a plugin to automate such a sequence, or I'd rather 
write one?

Thanks,
Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Could anyone give me some idea what is the difference bwteen ant and maven?

[Jeff Jensen]

I like your analogy Brian.

Additionally, I think the Sonatype Maven book has a nice comparison:
http://www.sonatype.com/book/reference/introduction.html#sect-compare-ant-maven

(and I think this is a User-list question, not a Developer-list one?)


-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Sunday, October 26, 2008 8:21 PM
To: Maven Developers List
Cc: [EMAIL PROTECTED]
Subject: RE: Could anyone give me some idea what is the difference bwteen ant 
and maven?

Na, ant is the hammer and the wrench where you fix it yourself. Maven is the 
contractor you hire and tell him what to build.

-Original Message-
From: Oleg Gusakov [mailto:[EMAIL PROTECTED] 
Sent: Sunday, October 26, 2008 9:03 PM
To: Maven Developers List
Cc: [EMAIL PROTECTED]
Subject: Re: Could anyone give me some idea what is the difference bwteen ant 
and maven?

I hope we are both on the same page that assembler, like ant, is a 
procedural language, while both Maven and SQL could be characterized as 
non-procedural, a.k.a. declarative.

Ant is a good OS-independent shell, while Maven is code comprehension 
tool, that also happens to be a superior build system. They are 
different is this respect: one can use a wrench on the nails, but hammer 
is a way more efficient. I argue that Maven is that hammer :)

Bob Aiello wrote:
 um er - I don't agree with the characterization that Ant is 
 Assembler-like.
 The term procedural might be a better choice, but I would prefer to not
 get into a religious debate. I had shared a few of my experiences with
 Ant and Maven in a couple of my articles on CM Crossroads 
 (www.cmcrossroads.com).
 Here is one where I try to draw a distinction between Ant and Maven.
 http://www.cmcrossroads.com/content/view/10027/174/

 I am looking for a few writers to submit articles for CM Basics next
 week. Writing about your practical experiences is an amazing way to
 share best practices. (I will help you with the editing so don't worry
 if you are new to writing :-)

 Bob Aiello
 Editor in Chief
 CM Crossroads
 email raiello [at] acm.org
 http://www.linkedin.com/in/BobAiello

 - Original Message - From: Oleg Gusakov 
 [EMAIL PROTECTED]
 To: Maven Developers List dev@maven.apache.org
 Sent: Friday, October 24, 2008 3:01 PM
 Subject: Re: Could anyone give me some idea what is the difference 
 bwteen ant and maven?


 Daniel,

 The difference if that with Ant you write an Assembler-like program: 
 you can do a lot, but maintainability is like current economy - very 
 low. And here you always have to write what to do and how to do it, 
 like for javac/ you have to tell it where the sources are, where 
 the output should go.

 With Maven - you write a SQL statement: you don't tell it how to do 
 things, just say what needs to be done, and maven will figure out the 
 way to do it. If you compile java classes - you don't even have to 
 mention the compiler - Maven defalts will take care of that.

 For examples - you can check the book: http://www.sonatype.com/book

 I think that if there is more that one person working on a project - 
 Ant is a dead end for a build system.

 Overall - please ask these kind of questions on the user list, this 
 one is mainly for developing maven itself.

 dr2238 wrote:
   I have knowledge on ant, but doesn't have any 
 knowledge on
 maven.   I heard other say ant is kind of procedural language , 
 while maven
 is an objected oriented language.

 Is that true?   Could anyone explain it to me a little bit?It 
 would be
 great if you can show me some small examples to let me understand 
 what is
 the difference between them.


 thanks a lot for your help


 Daniel



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JIRA for Maven 1.x?

[Jeff Jensen]

Possibly there are some to close (won't fix/won't do the enhancement), but
what is the reasoning for a bulk close of all of them?

If consolidating all to one JIRA is of some benefit, then why not just bulk
move those not closed to the new one (after processing them per the
above)?

And consolidating to one - I'd like to see arguments on it.  So far, the 3
of you are easily for doing it, but I am not sure of the real benefit.  I
have some thoughts on the pros, but some cons too!  :-) 


-Original Message-
From: Lukas Theussl [mailto:[EMAIL PROTECTED] 
Sent: Sunday, February 17, 2008 3:39 PM
To: Maven Developers List
Subject: Re: JIRA for Maven 1.x?


I thought maintenance mode also meant that people can still submit 
patches to existing issues and we'll consider them.

However, given the small expected impact I think it would be most 
practical to just close all open issues (plugins and core) as won't fix, 
and install a consolidated jira where people can still report new or 
re-open old issues if they want them fixed.

Cheers,
-Lukas


Brett Porter wrote:
 what does maintenance mode mean?
 
 IMO, it would be that new issues can be reported, and are either fixed  
 or closed as won't fix because they are new work or non-critical. In  
 which case I would say:
 - consolidate the projects (I'm not sure what this means in  
 practicality - I think you need to keep a project open but remove  *all* 
 of it's permissions for the old issue links to redirect to their  new
home)
 - close out any open issues that aren't going to be fixed
 - leave permissions as is for the consolidated project.
 
 Cheers,
 Brett
 
 On 18/02/2008, at 8:12 AM, Lukas Theussl wrote:
 
 I wanted to propose that too, but what to do with the issues that  are 
 open? As long as m1 is in maintenance mode, I think we should  keep 
 reported issues visible. We could remove the 'create new issue'  
 option from all projects though and update the description to point  
 to the new jira to use.

 -Lukas


 Brian E. Fox wrote:

 What if all the maven 1.x jira projects where collapsed into one?
 -Original Message-
 From: Lukas Theussl [mailto:[EMAIL PROTECTED] Sent: Sunday,  
 February 17, 2008 3:34 PM
 To: Maven Developers List
 Subject: Re: JIRA for Maven 1.x?
 If I'm not mistaken we didn't get a single critical bug report  after 
 1.1
 was released. But that's not surprising, after all, it's a perfect  
 product... :)
 I am not sure about closing the JIRAs, after all, maintenance mode  
 means
 that we still do accept bug reports, right? If anyone would submit  a 
 patch or report something critical, I would still be willing to  
 apply/fix it and do a release. But given the late activity, this is  
 not likely to happen.
 I'd agree to close the sandbox plugins, I wanted to do that myself  
 already a long time ago.
 -Lukas
 Brett Porter wrote:

 Hi,

 Some questions for the guys that wrapped up Maven 1.1 :)

 Since Maven 1.x is in maintenance mode, should most of the  current  
 JIRAs that reflect things that won't be fixed be closed  out?

 At what point will we stop accepting new bugs?

 And how does this affect the plugins - are they in the same state?

 Thanks!

 Cheers,
 Brett

 -- 
 Brett Porter
 [EMAIL PROTECTED]
 http://blogs.exist.com/bporter/


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 
 -- 
 Brett Porter
 [EMAIL PROTECTED]
 http://blogs.exist.com/bporter/
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [m1] PMD plugin dependencies

[Jeff Jensen]

Ugh!!  :-(

Thanks for the help Arnaud, Xavier, and Lukas...


 -Original Message-
 From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
 Sent: Saturday, December 01, 2007 4:33 PM
 To: Maven Developers List
 Subject: Re: [m1] PMD plugin dependencies
 
 Hi Xavier,
 
   Thanks a lot for your feedback !
   Jeff, you know what to do if you want to use the new version of pmd in
 maven 1 land.
 
 Arnaud
 
 On Nov 30, 2007 7:49 PM, Xavier Le Vourch [EMAIL PROTECTED]
 wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hi,
 
 
  Arnaud HERITIER wrote:
 I hope that 1.1.1 is compatible with 1.1-beta-9. Depending of the
part
  of
   jaxen which is used by pmd it's possible that it works fine with the
old
   version.
 
 
  First, let me give you some general info: I'm an admin for the pmd
  project and I just released pmd 4.1 and submitted the upload request for
  it.
 
  I've also submitted a few patches for the pmd plugin update as well
  yesterday and earlier today.
 
  Now that you know where I'm coming from, pmd 4.1 does require jaxen
  1.1.1 to work correctly as it includes a critical bug fix.
 
  Without it, at least one rule (AddEmptyString in optimizations.xml) will
  fail. The regression tests for the rule fail when jaxen 1.1 is used.
 
  The expression checked by that rule is pretty common so if the rule is
  included, most likely pmd will fail parsing regular code.
 
 
  Sorry for the bad news...
 
 
  Xavier
 
  - --
  Xavier Le Vourch
  Brittany Software, Inc.
  [EMAIL PROTECTED]
 
  PGP Key (ID 0x896C5947): http://brittanysoftware.com/gpg_key.asc
  Key fingerprint: 73B3 6370 B8C5 4325 F2D8  4115 0372 5805 896C 5947
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.5 (GNU/Linux)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
  iD8DBQFHUFtWA3JYBYlsWUcRApPxAJ4+h0CTItxNFPpcYVelVm73yKtCZwCeNzrr
  zzhReGde2FM/31OHEuU1IfE=
  =0NAY
  -END PGP SIGNATURE-
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 --
 ..
 Arnaud HERITIER
 ..
 OCTO Technology - aheritier AT octo DOT com
 www.octo.com | blog.octo.com
 ..
 ASF - aheritier AT apache DOT org
 www.apache.org | maven.apache.org
 ...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [m1] PMD plugin dependencies

[Jeff Jensen]

I'm open to it.  I can complete the plugin upg and test with the existing
dep versions as well.  If it fails, then we are dead-ended without doing
those upgrades; if it does not fail, then we have options ;-)


 -Original Message-
 From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 30, 2007 1:34 AM
 To: Maven Developers List
 Subject: Re: [m1] PMD plugin dependencies
 
 yes if you want. we can produce minor updates by upgrading some
dependencies
 if it helps to improve plugins.
 
 Arnaud
 
 On Nov 30, 2007 7:52 AM, Lukas Theussl [EMAIL PROTECTED] wrote:
 
  Bad news: jaxen is used in the core [1]
  Good news: Arnaud had already upgraded a lot of deps and attached
  patches (MAVEN-1797 - 1805), among them for jaxen [2]
 
  Should we work on m1.1.1 with only upgraded deps?
 
  :)
  -Lukas
 
  [1] http://maven.apache.org/maven-1.x/dependencies.html
  [2] http://jira.codehaus.org/browse/MAVEN-1797
 
 
  Arnaud HERITIER wrote:
   Hi jeff,
  
 What you have to check, it is if jaxen is loaded by the core. If
  that's
   the case, the version in the core is always used.
 If not, it is the version of jaxen used by the first plugin loaded
  which
   use it.
 That's why we tried for the 1.1 release of maven to align
dependencies
  to
   have less side effects.
 I hope that 1.1.1 is compatible with 1.1-beta-9. Depending of the
part
  of
   jaxen which is used by pmd it's possible that it works fine with the
old
   version.
 If it's not the case you'll have to try to upgrade jaxen
everywhere...
  
   Arnaud
  
   On Nov 30, 2007 2:05 AM, Jeff Jensen
[EMAIL PROTECTED]
   wrote:
  
  
  Hi Arnaud,
  PMD 4.1 has updated its deps (e.g. asm and jaxen), and I am concerned
on
  upgrading the plugin.  I know you (and possibly others) spent
  considerable
  time aligning the dependencies amongst core and many other plugins.  I
  know
  Jaxen was one of them.
  
  Do you have concerns/suggestions on updating the plugin deps in this
  manner
  (e.g. jaxen from 1.1-beta-9 to 1.1.1)?
  
  
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 --
 ..
 Arnaud HERITIER
 ..
 OCTO Technology - aheritier AT octo DOT com
 www.octo.com | blog.octo.com
 ..
 ASF - aheritier AT apache DOT org
 www.apache.org | maven.apache.org
 ...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [m1] PMD plugin dependencies

[Jeff Jensen]

I'm open to it.  I can complete the plugin upg and test with the existing
dep versions as well.  If it fails, then we are dead-ended without doing
those upgrades; if it does not fail, then we have options ;-)


 -Original Message-
 From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 30, 2007 1:34 AM
 To: Maven Developers List
 Subject: Re: [m1] PMD plugin dependencies
 
 yes if you want. we can produce minor updates by upgrading some
dependencies
 if it helps to improve plugins.
 
 Arnaud
 
 On Nov 30, 2007 7:52 AM, Lukas Theussl [EMAIL PROTECTED] wrote:
 
  Bad news: jaxen is used in the core [1]
  Good news: Arnaud had already upgraded a lot of deps and attached
  patches (MAVEN-1797 - 1805), among them for jaxen [2]
 
  Should we work on m1.1.1 with only upgraded deps?
 
  :)
  -Lukas
 
  [1] http://maven.apache.org/maven-1.x/dependencies.html
  [2] http://jira.codehaus.org/browse/MAVEN-1797
 
 
  Arnaud HERITIER wrote:
   Hi jeff,
  
 What you have to check, it is if jaxen is loaded by the core. If
  that's
   the case, the version in the core is always used.
 If not, it is the version of jaxen used by the first plugin loaded
  which
   use it.
 That's why we tried for the 1.1 release of maven to align
dependencies
  to
   have less side effects.
 I hope that 1.1.1 is compatible with 1.1-beta-9. Depending of the
part
  of
   jaxen which is used by pmd it's possible that it works fine with the
old
   version.
 If it's not the case you'll have to try to upgrade jaxen
everywhere...
  
   Arnaud
  
   On Nov 30, 2007 2:05 AM, Jeff Jensen
[EMAIL PROTECTED]
   wrote:
  
  
  Hi Arnaud,
  PMD 4.1 has updated its deps (e.g. asm and jaxen), and I am concerned
on
  upgrading the plugin.  I know you (and possibly others) spent
  considerable
  time aligning the dependencies amongst core and many other plugins.  I
  know
  Jaxen was one of them.
  
  Do you have concerns/suggestions on updating the plugin deps in this
  manner
  (e.g. jaxen from 1.1-beta-9 to 1.1.1)?
  
  
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 --
 ..
 Arnaud HERITIER
 ..
 OCTO Technology - aheritier AT octo DOT com
 www.octo.com | blog.octo.com
 ..
 ASF - aheritier AT apache DOT org
 www.apache.org | maven.apache.org
 ...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[m1] PMD plugin dependencies

[Jeff Jensen]

Hi Arnaud,
PMD 4.1 has updated its deps (e.g. asm and jaxen), and I am concerned on
upgrading the plugin.  I know you (and possibly others) spent considerable
time aligning the dependencies amongst core and many other plugins.  I know
Jaxen was one of them.

Do you have concerns/suggestions on updating the plugin deps in this manner
(e.g. jaxen from 1.1-beta-9 to 1.1.1)?




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] Nicolas de Loof as a committer

[Jeff Jensen]

+1
Great work on the JS plugin too!


 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 21, 2007 3:08 AM
 To: Maven Developers List
 Subject: [vote] Nicolas de Loof as a committer
 
 I'd like to call a vote for Nicolas de Loof as a committer, based
 primarily on his work for Archiva, but also from being active in the
 general Maven community for quite some time. He has been relentlessly
 testing and identifying issues and providing patches recently.
 
 +1 from me
 
 - Brett
 
 --
 Brett Porter - [EMAIL PROTECTED]
 Blog: http://www.devzuz.org/blogs/bporter/




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [poll] Requiring users to specify plugin versions in Maven 2.1 or later

[Jeff Jensen]

I think this might be the most practical solution.
Yes, perhaps the functionality belongs with some type of pom/release/build/CM 
topic'd plugin, but that is a secondary issue!

Tools like the archetypes can create them/have them created in the pom too, 
e.g. if genAllDeps=true.


 -Original Message-
 From: Arik Kfir [mailto:[EMAIL PROTECTED]
 Sent: Sunday, September 02, 2007 1:34 PM
 To: Maven Developers List
 Subject: Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or
 later
 
 Hi,
 
 As a heavy Maven **user**, what would be best for us is having some plugin
 (could be the enforcer, or another) automatically generate this
 configuration for us into the POM. Something along the lines of:
 
 mvn enforcer:lock-plugins
 
 This command will find the most appropriate version of relevant plugins and
 modify my POM(s) to explicitly specify them. Later on, I can either manually
 modify my POM when I want to upgrade a plugin, or run another command, e.g:
 
 mvn enforcer:update-all-plugins
 
 or:
 
 mvn enforcer:update-plugin
 -DgroupId=org.apache.maven.plugins-DartifactId=maven-jar-plugin
 -Dversion=latest/2.9.9.9
 
 Current behavior should remain, if only not to upset the many non-enterprise
 users which use Maven more lightly.
 
 HTH,
 Arik.
 
 On 9/2/07, Dan Tran [EMAIL PROTECTED] wrote:
 
  B
 
  Totally agree with Wayne here.
 
  -D
 
  On 9/2/07, Wayne Fay [EMAIL PROTECTED] wrote:
[X] (B) Retain the current behaviour, but make using the enforcer a
best practice to do the above, or some other control mechanism such
as having the repository manager handle the available plugins
  
   I am thinking about the new user experience and winning more converts.
  As such, I think the current behavior is best. Once they get using Maven
  more seriously (and in corporate environments that know what they're doing),
  I think adding the Enforcer configuration and locking versions down will
  come naturally. But *requiring* it seems excessive -- unless we're doing
  that ourselves somewhere, with plugin packs or similar, then I feel better
  about it.
  
   Wayne
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] Release Maven 1.1 Final

[Jeff Jensen]

An emphatic +1 :-)


-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 20, 2007 12:46 PM
To: Maven Developers List
Subject: [vote] Release Maven 1.1 Final

Hi team,

  It's with pleasure that I want to launch the vote to release the final
version of maven 1.1.

  We published, one month ago, a first release candidate for maven 1.1 and
we had few issues opened (certainly because this release is perfect, and not
because we lost our last users ;-) ).
  Since the RC1, we fixed some minors issues :
  - We upgraded the artifact plugin to solve MPARTIFACT-76 (artifact:deploy
always asks for passphrase)
  - We upgraded the test plugin to solve  MPTEST-63 (Memory leak) and
MPTEST-64 (test-plugin-1.8 is way slower than 1.7)
  - We included a distribution of sources

  Binaries and sources are available here :

http://people.apache.org/repo/m1-snapshot-repository/maven/distributions/200
70619/

  Staging site is here :
  http://people.apache.org/~aheritier/staging-sites/m1-core/maven-1.x/

  Please review the site (release note, ..), the sources distrib, and test
our binaries if possible.

  Vote closes in 72 hours. I'll do the release (if the vote passes) this WE.

[ ] +1 - I have tested it and say go for it
[ ] +0 - I haven't tested it but say go for it
[ ] -1 - I found a bug in testing/have a reason to wait

+1 from me...

  Cheers,

Arnaud.

Personal note : I would like to thank all of those who actively contributed
for a long time on maven 1.1, particularly Lukas who made the major part of
the work, and Jeff who helped us a lot to test our developments. This for
me, my last real contribution on maven 1.x. I consider that we finished what
we began a long long time ago and I'll now focus my efforts on maven 2 and
related (archiva, ...). If in the future I need to fix/release something for
my job, I'll do it, but do not consider me as the release manager for maven
1.X. I give back my hat...

..
Arnaud HERITIER
..
OCTO Technology - [EMAIL PROTECTED]
www.octo.com | blog.octo.com
..
ASF - [EMAIL PROTECTED]
www.apache.org | maven.apache.org
...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [proposal] Change project names for M1 plugins in JIRA

[Jeff Jensen]

+1


-Original Message-
From: Dennis Lundberg [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 30, 2007 10:27 AM
To: dev@maven.apache.org
Subject: [proposal] Change project names for M1 plugins in JIRA

Hi

We get some JIRA issues for the M1 plugins that really belongs to the M2 
plugins. To help get these issues into the correct JIRA project from the 
start, I propose that we change the names of the JIRA projects for M1 
plugins. From maven-idea-plugin to Maven 1.x IDEA Plugin.

Note: for the M2 plugins we use names like Maven 2.x IDEA Plugin.

I am willing to do the actual changes if you like this proposal.

-- 
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] Release maven 1.1 RC1

[Jeff Jensen]

+1

-Original Message-
From: Lukas Theussl [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 09, 2007 8:20 AM
To: Maven Developers List
Subject: Re: [vote] Release maven 1.1 RC1

+1

-Lukas


Arnaud HERITIER wrote:
 Hi folks,
 
  The time has come to release maven 1.1 RC1.
 
  Since the beta 3 we fixed several issues [1] and particularly :
  - We fixed latest incompabilities that avoided maven 1.1 to read POM
 working with maven 1.0.X [MAVEN-1755]. The new parser is a little bit more
 strict, thus if a pom isn't read, it's because it doesn't respect the
 schema.
  - We changed the central repository to
 http://repo1.maven.org/maven/[MAVEN-1789]
  - We improved the windows installer and changed the LF
 [MAVEN-1812][MAVEN-1808] [2]
  - We updated 33 plugins [3][4] to fixed a lot of bugs and add some
 improvements.
 
  We are preparing the release note.
  You'll find the binaries in 1 hour here :

http://people.apache.org/repo/m1-snapshot-repository/maven/distributions/200
70508/ 
 
 
  Vote closes in 72 hours.
 
 +1 from me.
 
 Arnaud
 
 [1]

http://jira.codehaus.org/browse/MAVEN?report=com.atlassian.jira.plugin.syste
m.project:roadmap-panel 
 
 [2]

http://maven.apache.org/maven-1.x/plugins/nsis/screenshots.html#Modern_UI_Sc
reenShots 
 
 [3] http://jira.codehaus.org/browse/MAVEN-1769
 [4]

http://people.apache.org/~aheritier/staging-sites/m1-core/maven-1.x/plugins/
bundledHistory.html 
 
 
 ..
 Arnaud Heritier
 OCTO Technology
 [EMAIL PROTECTED]
 www.octo.com | blog.octo.com
 ...
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] [m1] couple of plugins for rc1

[Jeff Jensen]

+1 for all


-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 04, 2007 4:41 PM
To: Maven Developers List
Subject: Re: [vote] [m1] couple of plugins for rc1

+1 for all

Arnaud

On 02/05/07, Stephane Nicoll [EMAIL PROTECTED] wrote:

 +1

 Stéphane

 On 5/1/07, Lukas Theussl [EMAIL PROTECTED] wrote:
  Hi,
 
  Here's a bunch of plugins I'd like to release for inclusion in m11-rc1:
 
  maven-artifact-plugin-1.9
  maven-changelog-plugin-1.9.2
  maven-dist-plugin-1.7.1
  maven-eclipse-plugin-1.12
  maven-ejb-plugin-1.7.3
  maven-linkcheck-plugin-1.4.1
  maven-multiproject-plugin-1.5.1
  maven-test-plugin-1.8.1
  maven-war-plugin-1.6.3
  maven-xdoc-plugin-1.10.1
 
 
  Most of them were ready since a long time and were only waiting for the
  maven-model-3.0.2 release that happened last week. Otherwise changes are
  mostly minor, except for the artifact plugin, which will now only work
  with rc1.
 
  Due to the maven-model dependency, I plan to announce the release of
  these plugins together with the rc1 release only.
 
  +1 from me, 72h to vote...
 
  Thanks,
  -Lukas
 
 
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/artifact/
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/changelog/
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/dist/
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/eclipse/
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/ejb/
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/linkcheck/
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/multiproject/
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/test/
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/war/
 

http://people.apache.org/~ltheussl/staging-sites/m1-plugins/maven-1.x/plugin
s/xdoc/
 
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=
 1.9-SNAPSHOT
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-changelog-plugin -Dversion=
 1.9.2-SNAPSHOT
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-dist-plugin -Dversion=1.7.1-SNAPSHOT
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-eclipse-plugin -Dversion=
 1.12-SNAPSHOT
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-ejb-plugin -Dversion=1.7.3-SNAPSHOT
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-linkcheck-plugin -Dversion=
 1.4.1-SNAPSHOT
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-multiproject-plugin
  -Dversion=1.5.1-SNAPSHOT
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-test-plugin -Dversion=1.8.1-SNAPSHOT
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-war-plugin -Dversion=1.6.3-SNAPSHOT
 
  maven plugin:download
  -
 Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
 http://repo1.maven.org/maven
  -DgroupId=maven -DartifactId=maven-xdoc-plugin -Dversion=1.10.1-SNAPSHOT
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 

..
Arnaud Héritier
OCTO Technology
[EMAIL PROTECTED]
..
50, Avenue des Champs-Elysées
75008 Paris
Tél : (33) 1 58 56 10 00
Fax : (33) 1 58 56 10 01
GSM : (33) 6 03 52 71 31
www.octo.com | blog.octo.com
...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]

RE: [M1][vote] release plugins : idea 1.7, jalopy 1.5.1, jar 1.8.1, javadoc 1.9, multichanges 1.3, plugin 1.7.1

[Jeff Jensen]

+1

-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 23, 2007 10:49 AM
To: Maven Developers List
Subject: [M1][vote] release plugins : idea 1.7, jalopy 1.5.1, jar 1.8.1,
javadoc 1.9, multichanges 1.3, plugin 1.7.1

Here is a new list of plugins to release for maven 1.x.

--
IDEA 1.7
--
Changes in this version include :

  New Features:
o Autodetect which version control system to use Fixes MPIDEA-43.

Download :
maven plugin:download
  -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-idea-plugin
  -Dversion=1.7-SNAPSHOT

Staging site :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/idea/

--
JALOPY 1.5.1
--
Changes in this version include :

  New Features:
o Add a property that controls the source code encoding. Fixes MPJALOPY-12.
  Thanks to Joachim Bader.

  Changes:
o Upgrade plexus-utils to version 1.0.5 Fixes MAVEN-1803.

Download :
maven plugin:download
  -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-jalopy-plugin
  -Dversion=1.5.1-SNAPSHOT

Staging site :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/jalopy/

--
JAR 1.8.1
--
Changes in this version include :

  Changes:
o Change the default repository to http://repo1.maven.org/maven/ for
  dependencies url in the manifest. Fixes MAVEN-1789.
o Update to velocity 1.5.

Download :
maven plugin:download
  -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-jar-plugin
  -Dversion=1.8.1-SNAPSHOT

Staging site :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/jar/

--
JAVADOC 1.9
--
Changes :

Download :
maven plugin:download
  -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-javadoc-plugin
  -Dversion=1.9-SNAPSHOT

Staging site :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/javadoc/

--
MULTICHANGES 1.3
--

Changes in this version include :

  New Features:
o New page to describe the next releases.
o New RSS feed for releases.

  Changes:
o New internal format to store information about releases.
o Remove usage of the deprecated dependency-handle tag.

Download :
maven plugin:download
  -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-multichanges-plugin
  -Dversion=1.3-SNAPSHOT

Staging site :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/multichanges/

--
PLUGIN 1.7.1
--

Changes in this version include :

  Fixed bugs:
o assert:assertPluginAvailable : Fix error (NoSuchElementException) if the
  minimum release number has less elements than the version number
installed.

  Changes:
o Don't check that a given plugin version is available in the bootstrap.
o Update dependencies to unify them between plugins. The following
  dependencies are updated : commons-jelly-tags-interaction v1.0 to v1.1,
  jaxen v1.0-FCS-full to 1.1-beta-9. The following dependencies are removed
:
  saxpath.
o Upgrade to Xerces 2.8.0. Replace the deprecated xmlParserAPIs by xml-apis
  1.3.03. Add the xml-resolver dependency for xerces. Fixes MAVEN-1753.

Download :
maven plugin:download
  -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-plugin-plugin
  -Dversion=1.7.1-SNAPSHOT

Staging site :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/plugin/


Normal voting rules, 72 hours, +1/0/-1

My +1 for all

Arnaud



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [m1] review of plugins to release

[Jeff Jensen]

Agreed.  Putting the release management hat on, betas, RCs, etc. are
not much of a beta/RC when they keep adding new functionalitythey are
continued development releases.  :-)


-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 23, 2007 5:43 AM
To: Maven Developers List
Subject: Re: [m1] review of plugins to release

Ok, I agree. I don't know if Jeff's change in the javadoc is dangerous, but
It's certainly a better idea to postpone its integration in the
distribution.
I'll in some minutes the vote for all the plugins I mentioned but it's not a
vote to incorporate them in the RC1 distribution.
I think to release maven-model-3.0.2 tomorrow to finish the delay of 72h.
Then we'll be able to release all the others plugins (I havjust to finish
few work on nsis today or tomorrow).

Cheers.

Arnaud


On 23/04/07, Lukas Theussl [EMAIL PROTECTED] wrote:

 We have talked about it in private already: I think we have made the
 error far too often now, that we waited for 'small' releases in order to
 get the big one out. I also don't like adding new features in the last
 minute, eg I haven't had time to really test Jeff's last changes to the
 javadoc plugin. Thus, in general, I'd prefer to release m11 with the set
 of plugins that we have scheduled, small fixes/additions to plugins
 should be done independently afterwards. The only exception I would
 consider is the multichanges plugin, which has some very cool new
 features, we are using it already for the maven site and it's well tested.


 Among the scheduled plugins, all except test are basically ready for a
 realease as is, as soon as maven-model-3.0.2 is out, so I think we could
 finalize an rc1 by the end of this week.

 Cheers,
 -Lukas


 Arnaud HERITIER wrote:
  Hi guys,
 
   We have actually in the pipe the following plugins to release for maven
  1.1 RC1 [1][2]:
   - artifact 1.9
   - changelog 1.9.2
   - dist 1.7.1
   - eclipse 1.11.1
   - ejb 1.7.3
   - linkcheck 1.4.1
   - multiproject 1.5.1
   - nsis 2.1
   - test 1.8.1
   - war 1.6.3
   - xdoc 1.10.1
   With the last snapshot of the artifact plugin, a release is done in few

  minutes ;-) The longest is to wait 72h for the vote !
 
   Thus I have some doubts about some others plugins which have changes
  already applied [3] that could justify a new release :
   - artifact 1.8.1 should be created and released to solve the issue we
 had
  in the maven 1.1 beta 3 [4]. Due to the upgrade of wagon, the plugin in
 the
  trunk isn't compatible with maven 1.1-beta-3. Is it necessary ?
   - idea 1.7 : 1 new feature
   - jalopy 1.5.1 : 1 new feature
   - jar 1.9 : 1 minor fix (perhaps a version 1.8.1?)
   - javadoc 1.9 : 1 new feature and 1 fix (the page will be updated in
 some
  hours)
   - jxr 1.6 : should we try to use jxr 2.1 ?
   - multichanges 1.3 : 2 new features
   - plugin 1.8 : 1 fix (perhaps a version 1.7.1)
 
  WDYT ?
 
  Arnaud
 
 
  [1] http://jira.codehaus.org/browse/MAVEN-1769
  [2] http://docs.codehaus.org/display/MAVEN/Maven+1.1+plugin
  [3]
 
http://maven.zones.apache.org/~continuum/staging-sites/m1-plugins/maven-1.x/
plugins/bundled/multichanges-report-next.html


http://maven.zones.apache.org/%7Econtinuum/staging-sites/m1-plugins/maven-1
.x/plugins/bundled/multichanges-report-next.html
 
  [4] http://maven.apache.org/maven-1.x/news.html
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] maven-model 3.0.2 for maven 1.1

[Jeff Jensen]

+1
Generated docs look good.


 -Original Message-
 From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
 Sent: Friday, April 20, 2007 5:49 PM
 To: Maven Developers List
 Subject: [vote] maven-model 3.0.2 for maven 1.1
 
 Hi team,
 
   We finalized the new version of maven-model 3.0.2 for maven 1.1.
   You can find the new web site in [1] and the model documentation [2]
will
 replace the one actually in the maven 1 site [3].
   I deployed a Snapshot of the library.
   In this new version, the pom can be read/write with xpp3, dom4j and
stax.
 In maven 1.1 RC1 we now use the stax reader/writer which supports xml
 entities to reintroduce the compatibility with old maven 1.0.X projects.
 (Thanks a lot for all the modello team and specially to Brett.)
 
   The vote is open for 72h.
 
   My +1
 
 Arnaud
 
 [1]

http://people.apache.org/~aheritier/staging-sites/maven-model/3.0.2-SNAPSHOT
/
 [2]
 http://people.apache.org/~aheritier/staging-sites/maven-model/3.0.2-
 SNAPSHOT/maven.html
 [3] http://maven.apache.org/maven-1.x/reference/project-descriptor.html



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [m1] review of plugins to release

[Jeff Jensen]

 -Original Message-
 From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
 Sent: Saturday, April 21, 2007 7:23 PM
 To: Maven Developers List
 Subject: Re: [m1] review of plugins to release
 
 On 22/04/07, Jeff Jensen [EMAIL PROTECTED] wrote:
 
Thus I have some doubts about some others plugins which have changes
   already applied [3] that could justify a new release :
 
  I'm open to including none/some/all.  If your concern is delaying the
1.1
  release further, I understand the option to include none.  Are there
any
  that are ready and only need vote/release and therefore would cause
  close
  to no impact?
 
 
 In the list I given, except for the artifact 1.8.1 et jxr everything is
 ready. We can launch the vote and proceed to the release.
 I'm also against to delay the RC1. It's just that some of this plugins can
 be released before the ones which are waiting for the maven-model release.

So it is a great idea to release those that are ready and will complete in
time, but doing so may take time away from other RC tasks.

On the other hand, 1.1 has been years in the making, what's another week or
so!?  ;-)


  There will be further plugin updates/releases after m1.1 final, so
perhaps
  none is just fine anyway (just the inconvenience of the
  not-bundled-in-the-release issue...).
 
 
- artifact 1.8.1 should be created and released to solve the issue we
  had
   in the maven 1.1 beta 3 [4]. Due to the upgrade of wagon, the plugin
in
  the
   trunk isn't compatible with maven 1.1-beta-3. Is it necessary ?
 
  I'm not sure of your question...
  You mention maven 1.1-beta-3, which at this point doesn't matter to me
(I
  consider the beta's obsolete by the RC's).  Is there a problem with
  artifact
  and the RC?
 
 
 Some/Few/A lot ? of users aren't using snapshots of the RC1 but the last
 beta. For those ones they need the artifact plugin 1.8.1 but our snapshot
of
 this plugin aren't compatible with the beta 3. Do we have to deliver to
them
 a version 1.8.1 of this plugin because the note we gave on the news is now
 erroneous ?

Hmm, that makes me wonder then why it is still a snapshot and not released
;-) 

It is kinda funny to release something to support a beta, especially one
that is about to be superseded by a RC!  That's equivalent to treating
beta's as a release (backwards compatibility).

I consider the beta's dead, especially once the RC1 is released and not just
snapshots.

I respect the fact that you did some changes to make things compatible with
1.0; that was good because 1.0 is a true final release.  Alphas, Betas, and
RCs are just milestone releases/test drives on the way to the final
release.  (the problem with m1.1 is that it has truly had many final
releases - IMO a couple of the betas and RCs were release quality and could
have been made final :-).

I think the main reason not to do this artifact backwards-beta-compatible
release is the time it takes to do it.  That may not take very long, but it
does take time away from direct RC work.

However, not trying to be mean/insensitive about user needs...
It is one of those things that is good to get user feedback on, but what is
the decision criteria?  What is the threshold of need - if one person says
I need it, will you do it?

If the team can define the decision criteria, then we can know if we need
to.  If there is no criteria, then the answer is no need.


 -Original Message-
  From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
  Sent: Saturday, April 21, 2007 3:23 PM
  To: Maven Developers List
  Subject: [m1] review of plugins to release
 
  Hi guys,
 
We have actually in the pipe the following plugins to release for
maven
  1.1 RC1 [1][2]:
- artifact 1.9
- changelog 1.9.2
- dist 1.7.1
- eclipse 1.11.1
- ejb 1.7.3
- linkcheck 1.4.1
- multiproject 1.5.1
- nsis 2.1
- test 1.8.1
- war 1.6.3
- xdoc 1.10.1
With the last snapshot of the artifact plugin, a release is done in
few
  minutes ;-) The longest is to wait 72h for the vote !
 
Thus I have some doubts about some others plugins which have changes
  already applied [3] that could justify a new release :
- artifact 1.8.1 should be created and released to solve the issue we
  had
  in the maven 1.1 beta 3 [4]. Due to the upgrade of wagon, the plugin in
  the
  trunk isn't compatible with maven 1.1-beta-3. Is it necessary ?
- idea 1.7 : 1 new feature
- jalopy 1.5.1 : 1 new feature
- jar 1.9 : 1 minor fix (perhaps a version 1.8.1?)
- javadoc 1.9 : 1 new feature and 1 fix (the page will be updated in
  some
  hours)
- jxr 1.6 : should we try to use jxr 2.1 ?
- multichanges 1.3 : 2 new features
- plugin 1.8 : 1 fix (perhaps a version 1.7.1)
 
  WDYT ?
 
  Arnaud
 
 
  [1] http://jira.codehaus.org/browse/MAVEN-1769
  [2] http://docs.codehaus.org/display/MAVEN/Maven+1.1+plugin
  [3]
 
 
http://maven.zones.apache.org/~continuum/staging-sites/m1-plugins/maven-1.x/
  plugins/bundled

RE: ConcurrentModificationException in maven 1.x - any ideas ?

[Jeff Jensen]

 someone have an idea...

I wonder what would happen if we used PathFinder to run Maven/the build;
perhaps it would find the issue? 


-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Sunday, April 15, 2007 8:10 PM
To: Maven Developers List
Subject: ConcurrentModificationException in maven 1.x - any ideas ?

Hi guys,

  We have regularly a ConcurrentModificationException (MAVEN-1840) when we
build maven 1.X with continuum.
http://maven.zones.apache.org:8180/continuum/servlet/continuum/target/Projec
tBuild.vm?view=ProjectBuildbuildId=247id=6

  I tried to fix it but without success. The problem is that I can't
reproduce it locally. I someone have an idea...

cheers

Arnaud



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] Release maven-developer-activity-plugin and maven-file-activity-plugin 1.6.1 for maven 1.X

[Jeff Jensen]

+1

-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Sunday, April 15, 2007 7:41 PM
To: Maven Developers List
Subject: [vote] Release maven-developer-activity-plugin and
maven-file-activity-plugin 1.6.1 for maven 1.X

Hi,

  Those two plugins have a similar fix and weren't release for several
months (more than 1 year in fact).

  Changes :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/developer-activity/changes-report.html#Release1_6_1-SNAPSHOThttp://peopl
e.apache.org/%7Eaheritier/staging-sites/m1-plugins/maven-1.x/plugins/site/ch
anges-report.html#Release1_7_2-SNAPSHOT
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/file-activity/changes-report.html#Release1_6_1-SNAPSHOThttp://people.apa
che.org/%7Eaheritier/staging-sites/m1-plugins/maven-1.x/plugins/site/changes
-report.html#Release1_7_2-SNAPSHOT

http://people.apache.org/%7Eaheritier/staging-sites/m1-plugins/maven-1.x/pl
ugins/site/changes-report.html#Release1_7_2-SNAPSHOT
Staging sites :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/developer-activity/http://people.apache.org/%7Eaheritier/staging-sites/m
1-plugins/maven-1.x/plugins/site/
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/file-activity/http://people.apache.org/%7Eaheritier/staging-sites/m1-plu
gins/maven-1.x/plugins/site/

  Download :

maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/ m1
-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven
-DartifactId=maven-developer-activity-plugin -Dversion=1.6.1-SNAPSHOT
maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/ m1
-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven
-DartifactId=maven-file-activity-plugin -Dversion=1.6.1-SNAPSHOT


+1 from me, 72h to vote

Cheers,



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] Release maven-announcement-plugin 1.4.1 for maven 1.X

[Jeff Jensen]

+1

-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Sunday, April 15, 2007 7:42 PM
To: Maven Developers List
Subject: Re: [vote] Release maven-announcement-plugin 1.4.1 for maven 1.X

On 16/04/07, Arnaud HERITIER [EMAIL PROTECTED] wrote:

 Hi,

   In the logic to try to release often I propose to release the
 announcement which has only one minor change. It's to have these one
 included in the RC1.

   Changes :

http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/announcement/changes-report.html#Release1_4_1-SNAPSHOThttp://people.apac
he.org/%7Eaheritier/staging-sites/m1-plugins/maven-1.x/plugins/site/changes-
report.html#Release1_7_2-SNAPSHOT


http://people.apache.org/%7Eaheritier/staging-sites/m1-plugins/maven-1.x/pl
ugins/site/changes-report.html#Release1_7_2-SNAPSHOT
 Staging site :

http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/announcement/http://people.apache.org/%7Eaheritier/staging-sites/m1-plug
ins/maven-1.x/plugins/site/

   Download :

 maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1
 -snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven
 -DartifactId=maven-site-plugin -Dversion= 1.4.1-SNAPSHOT


Bad cut'n paste
maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1
-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven
-DartifactId=maven-announcement-plugin -Dversion= 1.4.1-SNAPSHOT

+1 from me, 72h to vote

 Cheers,



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] Release maven-site-plugin 1.7.2 for maven 1.X

[Jeff Jensen]

+1

-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Sunday, April 15, 2007 6:32 PM
To: Maven Developers List
Subject: [vote] Release maven-site-plugin 1.7.2 for maven 1.X

Hi,

  I encountered some problems with the site plugin and its rsync deployment
feature.
  I propose to release a new version to fix these problems.

  Changes :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/site/changes-report.html#Release1_7_2-SNAPSHOT
  Staging site :
http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi
ns/site/
  Download :
  maven plugin:download
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,
http://repo1.maven.org/maven
-DgroupId=maven -DartifactId=maven-site-plugin -Dversion=1.7.2-SNAPSHOT

+1 from me, 72h to vote

Cheers,
Arnaud



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: ConcurrentModificationException in maven 1.x - any ideas ?

[Jeff Jensen]

Yes, that is the one.

I have not used it.  I have followed it for the past couple of years, and
find it very intriguing.  Others have had success with it, and wonder if it
would help find the problem you are seeing.  I wish I had some time for it,
I think it would be fun to do that.


I also wonder about some of the static checker results.  Tools like FindBugs
and Lint4J have a few checks for thread issues.  Has anyone ever run them on
the code base?  PMD and Checkstyle don't really have those kinds of checks
like the aforementioned do.


-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 17, 2007 3:38 PM
To: Maven Developers List
Subject: Re: ConcurrentModificationException in maven 1.x - any ideas ?

You are talking about this one : http://javapathfinder.sourceforge.net/ ?
I never used it. Did you ?
You think it is possible ?

Arnaud

On 17/04/07, Jeff Jensen [EMAIL PROTECTED] wrote:

  someone have an idea...

 I wonder what would happen if we used PathFinder to run Maven/the build;
 perhaps it would find the issue?


 -Original Message-
 From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
 Sent: Sunday, April 15, 2007 8:10 PM
 To: Maven Developers List
 Subject: ConcurrentModificationException in maven 1.x - any ideas ?

 Hi guys,

   We have regularly a ConcurrentModificationException (MAVEN-1840) when we
 build maven 1.X with continuum.


http://maven.zones.apache.org:8180/continuum/servlet/continuum/target/Projec
 tBuild.vm?view=ProjectBuildbuildId=247id=6

   I tried to fix it but without success. The problem is that I can't
 reproduce it locally. I someone have an idea...

 cheers

 Arnaud



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Creating a schedule for releases

[Jeff Jensen]

That sounds like a great idea...and one less place to visit.
 

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 02, 2007 3:23 PM
To: Maven Developers List
Subject: RE: Creating a schedule for releases

I know the calendar is already out there so this might be late info (I
didn't think of it before), but I thought I'd point out that Jira has the
ability to set release dates and there is a calendar portlet you can add to
show them. It's probably less functionality than the google one, but it
could also incorporate the releases of all plugins, including ones where the
lead isn't on the PMC (if there are any). 

-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 12:08 PM
To: Maven Developers List
Subject: Re: Creating a schedule for releases


On 2 Apr 07, at 12:00 PM 2 Apr 07, Joakim Erdfelt wrote:

 Looks like we'll need an new maven-ical-report for the site 
 generation.

 To inject the schedule into the site, with links to the live-schedule.


I think just pointing to the calendar will suffice. I think a lot of
people will just end up subscribing to the feed.

Jason.

 - Joakim

 Jason van Zyl wrote:

 On 2 Apr 07, at 9:44 AM 2 Apr 07, Brian E. Fox wrote:

 +1. More info helps the users to plan and gives the devs
 something to
 work towards. I'd like to see some tentative plans for 2.1 also.


 2.1-alpha-1 will go on the schedule, the issues are registered for it

 and John and I would like to cut the alpha in the coming week so 
 we'll get wiki fleshed out with details of the issues listed in JIRA.

 Jason.

 -Original Message-
 From: Jason van Zyl [mailto:[EMAIL PROTECTED]
 Sent: Monday, April 02, 2007 9:38 AM
 To: Maven Developers List
 Subject: Creating a schedule for releases

 Hi,

 Taking the lead from the Mylar development team, whom I have a great

 deal of respect for, I would like to create a shared Google calendar

 where we can put some releases on schedules. I know at least for 
 Maven itself, Doxia, Wagon and some plugins I'm working on I have a 
 clear idea of when they will be released. But what the Mylar team 
 does is work under the general Europa guidelines and they try and do

 releases every 6 weeks. So I'm not sure how the everything will be 
 ultimately schedule but I would like to make a start at trying to 
 provide some transparency as the Mylar team does.

 So the though was that we would have a calendar on Google where 
 everyone on the PMC has access to the schedule (as it's a PMC person

 who has to do a release) and I'll start the by putting in the Maven 
 releases. I planned 4 weeks between the last releases and it ended 
 up being 6 so I'll shoot for that again, but even if we're off a bit

 it keeps the users informed and they will have a single place to 
 look for planned releases dates.

 I would like to set this up asap.

 +1

 Jason.

 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: confluence (was: We're near the release of 1.0 final)

[Jeff Jensen]

I wish it was all in one place - Maven site.

Too many don't know or don't go.  If it must reside elsewhere, the link to
external site docs must be very prominent.


-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 29, 2007 4:26 PM
To: Maven Developers List
Subject: Re: confluence (was: We're near the release of 1.0 final)

[snip]

Anyone else with 2 cents to spare?

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: confluence (was: We're near the release of 1.0 final)

[Jeff Jensen]

So what are the plans for what each would contain - Maven site and wiki?
Would Maven site contain only the generated tool docs (e.g. reports like
Javadoc, PMD) and would the wiki contain only hand-written user docs?

What I can't understand by just looking at those examples is how was all
that content created?  Did a mvn site run gen some and the hand created
wiki pages link to it?

No argument - those are nice sites.  Just not understanding yet the Maven
plans for wiki/site usage.  My fear, obviously, is continued separate
works, as some people I helped with Maven have a not happy-out-of-the-box
experience, which includes scattered docs - I always have to give them
multiple URLs for info and/or they keep Googling for answers.

If you plan to integrate Maven site and the wiki so well like the examples
you provided, then the user sees them as one source.  Very nice.


-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 29, 2007 7:34 PM
To: Maven Developers List
Subject: Re: confluence (was: We're near the release of 1.0 final)

That's exactly what this would provide.

While I don't propose moving the whole site to it, I think it makes sense as
an integrated subsite.

Take a look at these examples:
http://incubator.apache.org/openejb/
http://incubator.apache.org/openjpa/
http://geronimo.apache.org/

- Brett

On 30/03/2007, at 10:27 AM, Jeff Jensen wrote:

 I wish it was all in one place - Maven site.

 Too many don't know or don't go.  If it must reside elsewhere, the 
 link to external site docs must be very prominent.


 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Thursday, March 29, 2007 4:26 PM
 To: Maven Developers List
 Subject: Re: confluence (was: We're near the release of 1.0 final)

 [snip]

 Anyone else with 2 cents to spare?

 - Brett

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

M2 FAQ has ibiblio ref

[Jeff Jensen]

The M2 FAQ has a ref to ibiblio.  Does this need to change to the new
Maven Central ref?

http://maven.apache.org/general.html#available-plugins



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

M2 FAQ has ibiblio ref

[Jeff Jensen]

The M2 FAQ has a ref to ibiblio.  Does this need to change to the new
Maven Central ref?

http://maven.apache.org/general.html#available-plugins



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: M2 FAQ has ibiblio ref

[Jeff Jensen]

OK, would you like me to remove the question entirely or change it to
something correct you have in mind?


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Saturday, March 24, 2007 10:22 PM
To: Maven Developers List
Subject: Re: M2 FAQ has ibiblio ref

tha info is not even applicable anymore

On 3/24/07, Jeff Jensen [EMAIL PROTECTED] wrote:
 The M2 FAQ has a ref to ibiblio.  Does this need to change to the new
 Maven Central ref?

 http://maven.apache.org/general.html#available-plugins



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] [m1] plugin releases

[Jeff Jensen]

+1 for all but clover (never used it!).
 

-Original Message-
From: Lukas Theussl [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 22, 2007 7:38 AM
To: Maven Developers List
Subject: [vote] [m1] plugin releases

Hi,

These are the plugins that do not need the updated maven-model, so I'd like
to release them already:

maven-clover-plugin-1.11.2
maven-jdiff-plugin-1.5.1
maven-pdf-plugin-2.5.1
maven-pmd-plugin-1.10
maven-scm-plugin-1.6.1
maven-site-plugin-1.7.1


Changes are mostly minor, have a look at the changes and jira reports at the
stage sites given below.

+1 from me, 72h to vote

Cheers,
-Lukas


http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
clover/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
jdiff/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
pdf/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
pmd/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
scm/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
site/


maven plugin:download
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,ht
tp://repo1.maven.org/maven
-DgroupId=maven -DartifactId=maven-clover-plugin -Dversion=1.11.2-SNAPSHOT

maven plugin:download
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,ht
tp://repo1.maven.org/maven
-DgroupId=maven -DartifactId=maven-jdiff-plugin -Dversion=1.5.1-SNAPSHOT

maven plugin:download
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,ht
tp://repo1.maven.org/maven
-DgroupId=maven -DartifactId=maven-pdf-plugin -Dversion=2.5.1-SNAPSHOT

maven plugin:download
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,ht
tp://repo1.maven.org/maven
-DgroupId=maven -DartifactId=maven-pmd-plugin -Dversion=1.10-SNAPSHOT

maven plugin:download
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,ht
tp://repo1.maven.org/maven
-DgroupId=maven -DartifactId=maven-scm-plugin -Dversion=1.6.1-SNAPSHOT

maven plugin:download
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,ht
tp://repo1.maven.org/maven
-DgroupId=maven -DartifactId=maven-site-plugin -Dversion=1.7.1-SNAPSHOT

-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Lifecycle issues with Cobertura plugin and custom plugin

[Jeff Jensen]

I think it is clear now - Ralph, you jumped into a thread about the Maven 2
Cobertura plugin, and began asking about the Maven 1 plugin.  This confused
subsequent replies!

If you have Cobertura questions or issues, please start a new thread as
Lukas suggested.


-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 08, 2007 8:56 AM
To: Maven Developers List
Subject: Re: Lifecycle issues with Cobertura plugin and custom plugin

I didn't talk abou lifecycle and phases and a surefire plugin. My first
response to this thread was to simply ask what the well known problem 
was in the hopes I could figure out how to get the cobertura plugin for
maven 1 working better. (I did by the way).  You must have confused me with
the originator of this thread.

Btw - the maven.compile.debug setting is fine.

Ralph

Lukas Theussl wrote:
 Your mail is very confusing: you talk about lifecycle and phases and a 
 surefire plugin, all of which do not exist in Maven 1. If you are 
 indeed using the m1 plugin, then your question should go to the 
 plugins-user list at sourceforge (see [1] for links). (Btw, did you 
 check your maven.compile.debug setting?)

 Cheers,
 -Lukas

 [1] http://maven-plugins.sourceforge.net/maven-cobertura-plugin/


 Ralph Goers wrote:
 No, we have many Maven 1 based projects. We have wanted to move to 
 Maven 2 but cannot until MNG-1577 is applied.  I've actually waded 
 through quite a bit of the code in both versions.

 Version 1.3 of the Cobertura plugin also uses Cobertura 1.8 so I 
 guess there must be something blatantly wrong with that version. I 
 guess I should try version 1.2 which uses Cobertura 1.7.

 Ralph

 Bob Allison wrote:

 I thought you were using Maven 2.  The Maven 2 plugin v2.1 uses 
 Cobertura 1.8 which exhibits this problem.  By downgrading the 
 plugin to v2.0, you use v1.7 of Cobertura which does not have this 
 problem.

 - Original Message - From: Ralph Goers 
 [EMAIL PROTECTED]
 To: Maven Developers List dev@maven.apache.org
 Sent: Wednesday, February 07, 2007 9:14 AM
 Subject: Re: Lifecycle issues with Cobertura plugin and custom 
 plugin


 What is this well known problem. I tried upgrading the plugin for 
 maven 1.0.2 from version 1.1.1 of cobertura to 1.3 and have the 
 same problem - all the reports show 0 coverage.

 Ralph

 Bob Allison wrote:

 Sounds like the well-known Cobertura 2.1 problem.  Try explicitly 
 specifying version 2.0 of the plugin and see if that fixes it.

 - Original Message - From: drekka 
 [EMAIL PROTECTED]
 To: dev@maven.apache.org
 Sent: Wednesday, February 07, 2007 1:13 AM
 Subject: Lifecycle issues with Cobertura plugin and custom plugin



 Hi guys,
 I've been trying to nut this out for a couple of days now and 
 need your help. A few weeks ago I wrote a Junit4 plugin which 
 works perfectly in the test phase. It doesn't fork or anything 
 fancy, just gets on with the job.
 It's header contains the following annotations:

 * @requiresDependencyResolution test
 * @goal runJunit4Tests
 * @phase test

 However when I added the Cobertrua plugin to the mix, the 
 cobertura report keeps reporting 0% coverage. The logs indicate 
 that my plugin is working and using the 
 generated-classes/cobertura/ directory. It also indicates that 
 the classes are being instrumented correctly. yet looking at the 
 .ser file cobertura uses it would appear that either the 
 instrumented classes are not logging correctly or not being used 
 as nothing is appended to the file.

 This lead me to conclude that there is something wrong with the 
 way I've setup the plugin within maven. From reading the source 
 of the cobertura plugin it appears that the plugin forks a new 
 process to run the test phase again. At this point I'm not sure 
 what happens as the maven doco is really hard to follow and leave 
 me with more questions than answers. The logs indicate that the 
 test are run twice. Once before instrumenting and once after. 
 I've looked for any direct connection between the surefire and 
 cobertura plugins but cannot see anything.

 Any ideas guys ?

 ciao
 Derek
 --
 View this message in context: 
 http://www.nabble.com/Lifecycle-issues-with-Cobertura-plugin-and-
 custom-plugin-tf3185205s177.html#a8840433

 Sent from the Maven Developers mailing list archive at Nabble.com.



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [M1] Status for modello / maven-model / m1-core

[Jeff Jensen]

For a quick opinion ASAP, I did a quick review of the pages, and they look
pretty good.  When I can review more in-depth, I may suggest some additional
info/clarifications and writing changes on the site docs.

My initial suggestion on the Overview page is that I would like a link to an
example/real page of each of the potential items that it can generate to
help the reader understand what they could get when using it.  Of course,
for starters, use the POM reference page as one.


-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 11, 2007 7:53 PM
To: Maven Developers List
Subject: Re: [M1] Status for modello / maven-model / m1-core

ping ??
Sorry, but I would like to have your opinion ASAP.
My holidays are ended at the end of this week and I want to finish as much
tasks as possible before.

Arnaud

On 1/10/07, Arnaud HERITIER [EMAIL PROTECTED] wrote:

 Hi guys,

   Since some days I'm working on modello / maven-model / m1-core.
   Here is the current status. If you have some comments ... feel free

 Modello
   To resolve relative entities in the POM (to keep the compatibility 
 with maven 1.0.x) I had to update the STAX-RI plugin to add a new read 
 method (http://jira.codehaus.org/browse/MODELLO-77
 ) with a path as parameter (instead of a stream).

 Modello plugin for maven 1.
   I updated the maven-modello-plugin for m1 to use the latest versions 
 of modello.
   I also updated (created) a documentation for it :
   http://maven.apache.org/maven-1.x/plugins/modello/
   If some of you can take some minutes to review it (my english 
 particularly ;-) )
   I'm not sure, but it could be possible when we'll release it to move 
 it out from the sandbox ? It could be a new plugin in the m1 
 distribution, even if I'm not sure that it will have a lot of users 
 ;-) (Note that this is a really little plugin to maintain)

 Maven-model
   I built the documentation from modello :
 http://maven.apache.org/maven-1.x/reference/maven-model/3.0.2-SNAPSHOT
 /maven.html

   The problem is that we manually updated the previous documentation 
 build from the model by Brett.
   I propose that now we always use (as in m2) the documentation (and 
 the
 site) generated by modello.
   We'll update the model documentation if necessary.
   We have to fix in the maven.mdo the documentation which was updated 
 in the generated xdoc and not in the real model.
   I attached the patch which lists changes from the previous generation.
   The problem is to merge changes in links and in some comments for m1.
   In a modello model we can't have some notes for a given version of 
 the model ?

   I continue to test m1 with the new model which uses a stax 
 reader/writer.

 Arnaud





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: svn commit: r491675 - /maven/maven-1/plugins/trunk/pmd/project.xml

[Jeff Jensen]

Asm 3.0 is not on Ibiblio yet, which I knew, but Lukas told me that
committing these changes already would break the bootstrap, and asked me to
revert them.

I can't answer your other questions: I did not receive an email from
continuum.  I did not bootstrap after the change.


-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 01, 2007 5:13 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r491675 -
/maven/maven-1/plugins/trunk/pmd/project.xml

I hope you don't refer to the mail sent by continuum ?
Actually the problem of the bootstrap which fail is somewhere else ... In
the pdf plugin What is the problem with the bootstrap after the upgrade ?

Arnaud

On 1/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Author: jjensen
 Date: Mon Jan  1 15:06:09 2007
 New Revision: 491675

 URL: http://svn.apache.org/viewvc?view=revrev=491675
 Log:
 Undoing initial upg steps so bootstrap does not fail.

 Modified:
 maven/maven-1/plugins/trunk/pmd/project.xml

 Modified: maven/maven-1/plugins/trunk/pmd/project.xml
 URL:
 http://svn.apache.org/viewvc/maven/maven-1/plugins/trunk/pmd/project.x
 ml?view=diffrev=491675r1=491674r2=491675

 ==
 
 --- maven/maven-1/plugins/trunk/pmd/project.xml (original)
 +++ maven/maven-1/plugins/trunk/pmd/project.xml Mon Jan  1 15:06:09 
 +++ 2007
 @@ -158,7 +158,7 @@
  dependency
groupIdpmd/groupId
artifactIdpmd/artifactId
 -  version3.9/version
 +  version3.7/version
urlhttp://pmd.sourceforge.net/url
  /dependency
  dependency
 @@ -166,15 +166,17 @@
artifactIdoro/artifactId
version2.0.8/version
  /dependency
 +!--
  dependency
groupIdasm/groupId
artifactIdasm/artifactId
version3.0/version
  /dependency
 +--
  dependency
groupIdjaxen/groupId
artifactIdjaxen/artifactId
 -  version1.1-beta-10/version
 +  version1.1-beta-9/version
  /dependency
/dependencies
 /project






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: svn commit: r491630 - in /maven/maven-1/plugins/trunk/pmd: project.xml xdocs/changes.xml

[Jeff Jensen]

Thanks Arnaud.  I will commit the change and update  close the JIRA when
things are complete.
 

-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 01, 2007 5:06 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r491630 - in /maven/maven-1/plugins/trunk/pmd:
project.xml xdocs/changes.xml


 Modified: maven/maven-1/plugins/trunk/pmd/xdocs/changes.xml
 URL:
 http://svn.apache.org/viewvc/maven/maven-1/plugins/trunk/pmd/xdocs/cha
 nges.xml?view=diffrev=491630r1=491629r2=491630

 ==
 
 --- maven/maven-1/plugins/trunk/pmd/xdocs/changes.xml (original)
 +++ maven/maven-1/plugins/trunk/pmd/xdocs/changes.xml Mon Jan  1 
 +++ 13:05:29
 2007
 @@ -25,6 +25,7 @@
/properties
body
  release version=1.10-SNAPSHOT date=In SVN
 +  action dev=jjensen type=updateUpgrade to PMD 
 + 3.9./action


Jeff,

You forgot to add the reference to the issue (and to close this one) :
http://jira.codehaus.org/browse/MPPMD-29

Arnaud



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: svn commit: r491675 - /maven/maven-1/plugins/trunk/pmd/project.xml

[Jeff Jensen]

That was my next step - investigate ASM upload.  I have not done that yet.
So I am not aware of its status yet.

I know you are in progress on the zones continuous builds, which is really
great.
Will the Maven 1 continuous builds emails have its own list?  I'm drowning
in emails already and don't want to sift through M2 ones on that list too
(it's too much on the dev, user, and commits lists already...).  M2 has much
more activity than M1, as one would expect.

Where is the notifications info?  It is not on the mail lists link.  Did you
mean some other build messages are going to it, or that the zones ones will
go there when you are done? 
http://maven.apache.org/maven-1.x/mail-lists.html


-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 01, 2007 5:34 PM
To: Maven Developers List
Subject: Re: svn commit: r491675 -
/maven/maven-1/plugins/trunk/pmd/project.xml

On 1/2/07, Jeff Jensen [EMAIL PROTECTED] wrote:

 Asm 3.0 is not on Ibiblio yet, which I knew, but Lukas told me that 
 committing these changes already would break the bootstrap, and asked 
 me to revert them.


Ok, he's right. It will be a real problem. Is there an upload issue opened
for ASM ?

I can't answer your other questions: I did not receive an email from
 continuum.  I did not bootstrap after the change.


ok.  Those mails are sent to [EMAIL PROTECTED]
I'm configuring continuum on maven.zones.apache.org to automatically build
the bootstrap for us.

Arnaud

-Original Message-
 From: Arnaud HERITIER [mailto: [EMAIL PROTECTED]
 Sent: Monday, January 01, 2007 5:13 PM
 To: dev@maven.apache.org
 Subject: Re: svn commit: r491675 -
 /maven/maven-1/plugins/trunk/pmd/project.xml

 I hope you don't refer to the mail sent by continuum ?
 Actually the problem of the bootstrap which fail is somewhere else ... 
 In the pdf plugin What is the problem with the bootstrap after the upgrade
?

 Arnaud

 On 1/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
  Author: jjensen
  Date: Mon Jan  1 15:06:09 2007
  New Revision: 491675
 
  URL: http://svn.apache.org/viewvc?view=revrev=491675
  Log:
  Undoing initial upg steps so bootstrap does not fail.
 
  Modified:
  maven/maven-1/plugins/trunk/pmd/project.xml
 
  Modified: maven/maven-1/plugins/trunk/pmd/project.xml
  URL:
  http://svn.apache.org/viewvc/maven/maven-1/plugins/trunk/pmd/project
  .x
  ml?view=diffrev=491675r1=491674r2=491675
 
  
  ==
  
  --- maven/maven-1/plugins/trunk/pmd/project.xml (original)
  +++ maven/maven-1/plugins/trunk/pmd/project.xml Mon Jan  1 15:06:09
  +++ 2007
  @@ -158,7 +158,7 @@
   dependency
 groupIdpmd/groupId
 artifactIdpmd/artifactId
  -  version3.9/version
  +  version3.7/version
 url http://pmd.sourceforge.net/url
   /dependency
   dependency
  @@ -166,15 +166,17 @@
 artifactIdoro/artifactId
 version2.0.8/version
   /dependency
  +!--
   dependency
 groupIdasm/groupId
 artifactIdasm/artifactId
 version3.0/version
   /dependency
  +--
   dependency
 groupIdjaxen/groupId
 artifactIdjaxen/artifactId
  -  version1.1-beta-10/version
  +  version1.1-beta-9/version
   /dependency
 /dependencies
  /project
 
 
 



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-changes-plugin questions

[Jeff Jensen]

I like the changes page as a simplified, user-friendly list of notable changes
made for each release.  The defect/RFE tracking system has the details for the
initiated users when desired.


Quoting Stephane Nicoll [EMAIL PROTECTED]:

 On 12/27/06, Jason van Zyl [EMAIL PROTECTED] wrote:
 
  I never really understood the changes.xml myself, as I don't want to
  keep things in an issue tracking system and changes.xml or is this
  for folks who don't employ an issue tracking system?

 Yes and no. I've always seen it as a technical changelog of the
 project. When end-users create issues, the summary is not always
 understandable so we end up with a list of things beings solved.

 The changes.xml allows to describe in more details what happened. It's
 a good thing actually and it's certainly a good alternative for people
 not using an Issue tracker that maven handles.

 Stéphane


 
   - Keeping it in a maven-changes-plugin brings M1 and M2 more in
   sync than they were before, which eases migration pains.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vote] [m1] release changes, genapp, pom, clover, java, jira, simian plugins

[Jeff Jensen]

+1

Particularly we have been using the changes, java, and simian plugin
snapshots with no problems.  Thanks Lukas!


-Original Message-
From: Lukas Theussl [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 18, 2006 5:22 PM
To: Maven Developers List
Subject: [vote] [m1] release changes, genapp, pom, clover, java, jira,
simian plugins

Hi all,

I am slowly starting to get familiar with Maven again...

The following m1 plugins only had some trivial updates since the respective
versions included in maven-1.1-beta-3, I think we could quickly release them
for inclusion in 1.1-rc1:

[] maven-changes-plugin-1.7
[] maven-genapp-plugin-2.3.1
[] maven-pom-plugin-1.5.1
[] maven-clover-plugin-1.11.1
[] maven-java-plugin-1.6.1
[] maven-jira-plugin-1.3.1
[] maven-simian-plugin-1.6.1

For an overview of changes, check the changes and jira(-roadmap) reports on
the stage sites given below.


+1 from me and 72h to vote,

Cheers,
-Lukas


http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
changes/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
genapp/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
pom/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
clover/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
java/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
jira/
http://people.apache.org/~ltheussl/m1-plugins-stage-sites/maven-1.x/plugins/
simian/


maven plugin:download 
-Dmaven.repo.remote=http://repo1.maven.org/maven,http://people.apache.org/re
po/m1-snapshot-repository/ 
-DgroupId=maven -DartifactId=maven-changes-plugin -Dversion=1.7-SNAPSHOT

maven plugin:download 
-Dmaven.repo.remote=http://repo1.maven.org/maven,http://people.apache.org/re
po/m1-snapshot-repository/ 
-DgroupId=maven -DartifactId=maven-genapp-plugin -Dversion=2.3.1-SNAPSHOT

maven plugin:download 
-Dmaven.repo.remote=http://repo1.maven.org/maven,http://people.apache.org/re
po/m1-snapshot-repository/ 
-DgroupId=maven -DartifactId=maven-pom-plugin -Dversion=1.5.1-SNAPSHOT

maven plugin:download 
-Dmaven.repo.remote=http://repo1.maven.org/maven,http://people.apache.org/re
po/m1-snapshot-repository/ 
-DgroupId=maven -DartifactId=maven-clover-plugin -Dversion=1.11.1-SNAPSHOT

maven plugin:download 
-Dmaven.repo.remote=http://repo1.maven.org/maven,http://people.apache.org/re
po/m1-snapshot-repository/ 
-DgroupId=maven -DartifactId=maven-java-plugin -Dversion=1.6.1-SNAPSHOT

maven plugin:download 
-Dmaven.repo.remote=http://repo1.maven.org/maven,http://people.apache.org/re
po/m1-snapshot-repository/ 
-DgroupId=maven -DartifactId=maven-jira-plugin -Dversion=1.3.1-SNAPSHOT

maven plugin:download 
-Dmaven.repo.remote=http://repo1.maven.org/maven,http://people.apache.org/re
po/m1-snapshot-repository/ 
-DgroupId=maven -DartifactId=maven-simian-plugin -Dversion=1.6.1-SNAPSHOT


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [RANT] Maven is both heaven and hell

[Jeff Jensen]

(Since you didn't mention it) CruiseControl works really well for us, if you
need something now.


-Original Message-
From: Wendell Beckwith [mailto:[EMAIL PROTECTED] 
Sent: Monday, September 04, 2006 11:41 AM
To: Maven Developers List
Subject: Re: [RANT] Maven is both heaven and hell

[snip]

   2.) Produce nightly and weekly integration builds.
 
  We already do. We could do it better. I've brought this topic up a 
  couple of times on the Continuum list.
 
 
  I'm not on that list but I guess I will have to be to get a better 
  picture of what's going on.

 I expect this to become much more prevalent soon as Continuum is 
 getting the features we need to support it.


Yes, I understand .  We're watching Continuum's development too because we
would like to use it once it's feature set is improved.  We currently have
Anthill Pro, but http://www.zutubi.com/ Pulse looks to be a good contender
also since I only care about subv repos now.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Welcome to new committers!

[Jeff Jensen]

Thank you - I appreciate the opportunity :-).
 

-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 30, 2006 4:01 PM
To: Maven Developers List
Subject: Re: Welcome to new committers!

Welcome guys !
I'm so happy !
We double the m1 team ;-)

cheers !

Arnaud

On 8/30/06, Jimisola Laursen [EMAIL PROTECTED] wrote:


 Haha :)

 Do you have anything against Germans? :)

 Regards,
 Jimisola

 PS. My name doesn't show it, but I'm also Swedish DS.


 Joakim Erdfelt-2 wrote:
 
  Thanks!
 
  btw, it's Joakim Erdfelt not Joakime Erdfeldt
 
  I'm Swedish, not German. ;-)
 
  - Joakim Erdfelt
 
  Jason van Zyl wrote:
  Hi,
 
  We would like to welcome Joakime Erdfeldt, Shinobu Kawai, and Jeff 
  Jensen to the Maven Team!
 
  Joakime will be working on Continuum and Maven 2.x plugins, Shinobu 
  and Jeff will be working in Maven 1.x land.
 
  Thanks for your contributions thus far and have fun hacking on Maven!
  (We hope to get far more out of you now that you are committers! 
  :-))
 
  The Maven Team
 
 
 
 
  ---
  -- To unsubscribe, e-mail: [EMAIL PROTECTED] For 
  additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  
  - To unsubscribe, e-mail: [EMAIL PROTECTED] For 
  additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Welcome-to-new-committers%21-tf2192516.html#a606
 7928 Sent from the Maven Developers forum at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [m1] unable to run jar:deploy using maven-1.1-beta3

[Jeff Jensen]

Hi Stephane, Lukas, Arnaud, and I have had some emails and IRCs on it over
the past couple of weeks (I experienced the problem but they did not, so
wasn't sure if it just something with my local config or other).  We've been
doing some research with it, but nothing conclusive yet.

I found that I most easily experience the problem when starting with a
completely fresh Maven installation.  Note that I can successfully deploy
with Arnaud's 6/30 snapshot, but not after that version.

Since we are now receiving reports from other users, I created this JIRA for
us to track.  Please add your details to it!
 http://jira.codehaus.org/browse/MPARTIFACT-71

 

-Original Message-
From: Stephane Nicoll [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 10, 2006 4:48 AM
To: Maven Developers List
Subject: Fwd: [m1] unable to run jar:deploy using maven-1.1-beta3

It seems that there is a lot of problems with 1.1 and artifact deployment.
On my side, I did not upgrade our production system to 1.1 for that reason.

I am not using SCP but the filesystem. We are *unfortunately* in a full
windows environment without the ability to use scp and ftp.

On SERVERX,  I have a shared directory named 'maven-artifacts' (so
\\SERVERX\maven-artifacts maps to the root of the maven repository)

Here's my configuration:

maven.repo.list=rd
maven.repo.rd=file://serverX\\
maven.repo.rd.directory=maven-artifacts

Running m 1.0.2 without Wagon (so an old version of the artifact
plugin) is running OK. If I upgrade (both m1.0.2 and m1.1) the deployment is
running fine (no error) but nothing is deployed on the repository !

I can provide a use case if necessary. Is anyone looking into this so that
we can synchronize?

Thanks,
Stéphane







-- Forwarded message --
From: Siegfried Goeschl [EMAIL PROTECTED]
Date: Aug 10, 2006 11:33 AM
Subject: [m1] unable to run jar:deploy using maven-1.1-beta3
To: users@maven.apache.org


Hi folks,

I'm running Windows whereas the repository resides on a Linux box. I'm
unable to successfully deploy my JAR using the following settings

maven.repo.list=releases
maven.repo.releases=scp://10.0.0.20
maven.repo.releases.directory=/home/sgoeschl/temp
maven.repo.releases.username=foo
maven.repo.releases.password=bar

I get the following output

  START
Will deploy to 1 repository(ies): releases Deploying to repository: releases
Failed to deploy to: releases Reason:
org.apache.maven.wagon.authentication.AuthenticationException: Cannot
connect. Reason: reject HostKey: 10.0.0.20
org.apache.maven.wagon.authentication.AuthenticationException: Cannot
connect. Reason: reject HostKey: 10.0.0.20
 at
org.apache.maven.wagon.providers.ssh.AbstractSshWagon.openConnection(Abstrac
tSshWagon.java:232)
 at
org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143)
 at
org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106)
 at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deployFiles(Defau
ltArtifactDeployer.java:372)
 END

+) I gave it a try using scpexe://10.0.0.20 but it seems to do nothing
apart from sucess messages

+) I can successfully use putty's pscp to copy the files on my box

Any ideas or hints?!

Thanks in advance

Siegfried Goeschl

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
.::You're welcome ::.

-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [result] [vote] Jeff Jensen as Maven Plugins committer

[Jeff Jensen]

Thank you!  I am honored by this privilege.


 -Original Message-
 From: Lukas Theussl [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, August 03, 2006 9:38 AM
 To: Maven Developers List
 Cc: Maven Project Management Committee List
 Subject: [result] [vote] Jeff Jensen as Maven Plugins committer
 
 6x +1
 
 Welcome Jeff!
 
 -Lukas
 
 Lukas Theussl wrote:
  Jeff has recently helped as a lot with patches and 
 documentation for 
  Maven 1.1-beta-3, he is also an active maintainer of some 
 m1 plugins 
  at the sourceforge project. He would like to continue 
 helping us, so I 
  propose we give him access to apply his own patches.
  
  +1
  
  -Lukas
  
  
 -
  To unsubscribe, e-mail: [EMAIL PROTECTED] For 
  additional commands, e-mail: [EMAIL PROTECTED]
  
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] For 
 additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]