Re: What is the best way to use SemVer versions with maven-artifact?

[Benson Margulies]

I seem to recall that it's already configurable, that someone else has been
here and done this.


On Mon, Jan 11, 2021 at 8:24 AM Dennis Lundberg 
wrote:

> Hi all,
>
> When using a CI environments that create a new SemVer-compliant version for
> every build. These could use a qualifier like "-build" together with the
> build number. Here is an example:
>
> 1.2.3-build417
>
> This signifies build number 417 of the not-yet-released version 1.2.3.
>
> The current behavior of maven-artifact is 1.2.3-build417 > 1.2.3.
>
> This is the opposite of what is expected for a SemVer version number. One
> way to solve this would be to add an alias for the qualifier "build" which
> should equal "snapshot". So when doing version comparisons 1.2.3-build417 <
> 1.2.3.
>
> I have a feeling though that this might wreck things for people that do not
> follow SemVer. What would be the best way to solve this? It would be great
> if a user can tell Maven to follow SemVer. I imagine creating a
> SemVer-compliant brother to ComparableVersion, in combination with making
> the version comparison class configurable in some way.
>
> --
> Dennis Lundberg
>

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.11.3

[Benson Margulies]

+1 binding

On Tue, Aug 11, 2020 at 1:08 PM Ian Lavallee  wrote:

> +1
>
> On Mon, Aug 10, 2020 at 10:20 AM Elliotte Rusty Harold  >
> wrote:
>
> > Let's try this one more time. I updated Jira and regenerated the
> > release notes. Nothing else has changed:
> >
> > Hi,
> >
> > We solved 3 issues:
> >
> > [MSHARED-949] - dependency:analyze should recommend narrower scope
> > where possible
> > [MSHARED-948] - Update link to Jira
> > [MSHARED-932] - Remove JMock dependency
> >
> > There are still five issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer
> >
> >
> > Staging repo:
> >
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
> >
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip
> >
> > Source release checksum(s):
> > maven-dependency-analyzer-1.11.3-source-release.zip sha512:
> >
> >
> 84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8
> >
> > Staging site:
> >
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > On Wed, Aug 5, 2020 at 4:31 PM Elliotte Rusty Harold  >
> > wrote:
> > >
> > > Hi,
> > >
> > > We solved 2 issues:
> > > * [MSHARED-932] Remove JMock dependency
> > > * [MDEP-708] dependency:analyze should recommend narrower scope
> > > where possible
> > >
> > > There are still five issues left in JIRA:
> > >
> >
> https://issues.apache.org/jira/browse/MSHARED-916?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer
> > >
> > >
> > > Staging repo:
> > >
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/
> > >
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.3/maven-dependency-analyzer-1.11.3-source-release.zip
> > >
> > > Source release checksum(s):
> > > maven-dependency-analyzer-1.11.3-source-release.zip sha512:
> > >
> >
> 84a13538660dd877e6ab7b626778267b4ddf06581752235e8e4e282306a6c896e7d737795a81fd05a804e77fa685ddf4891b20c73561bbc741ab671b5ccf75b8
> > >
> > > Staging site:
> > >
> >
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
> > >
> > > Guide to testing staged releases:
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elh...@ibiblio.org
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.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 Dependency Analyzer version 1.11.2

[Benson Margulies]

+1 binding

On Mon, Jul 27, 2020 at 5:35 AM Anders Hammar  wrote:

> +1 (binding)
>
> /Anders
>
> On Mon, Jul 27, 2020 at 1:08 PM Elliotte Rusty Harold 
> wrote:
>
> > By my count we need one more PMC member to approve this to get to
> > three. This is an important upgrade that enables lots of new work in
> > the dependency plugin. Can anyone else give us a +1? Thanks.
> >
> > On Fri, Jul 24, 2020 at 2:43 PM Benson Margulies 
> > wrote:
> > >
> > > +1 binding.
> > >
> > >
> > > On Thu, Jul 23, 2020 at 5:39 PM Eric Lilja 
> wrote:
> > >
> > > > On Fri, Jul 24, 2020 at 12:06 AM Sylwester Lachiewicz <
> > > > slachiew...@gmail.com>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > in fact, in this release, based on commits, we have also fixed:
> > > > > MSHARED-879 Reproducible builds
> > > > > MSHARED-810 Support for Java 12
> > > > > MSHARED-792 Maven Dependency Analyzer ignores Java 8 type
> > annotations on
> > > > > local variables
> > > > >
> > > > > All the above tasks was assigned to the next planned version 3.0,
> > now all
> > > > > fix tags where corrected.
> > > >
> > > >
> > > >   Vote: +1 non-binding
> > > >
> > > > Thanks for highlighting this, Sylwester. I think we have the same
> > situation
> > > > in maven-site-plugin (and maybe elsewhere). Issues fixed without a
> fix
> > > > version. I usually look at the next version in Jira to see what
> issues
> > are
> > > > already completed to make it into the next release and what other,
> > > > non-completed issues, also share the same fix version (I know some
> > > > components have several future versions, which may have their own
> > > > issues, like Maven itself, or surefire, but most do not is my
> > experience).
> > > > I would like to track all changes in Jira, including dependency
> > upgrades
> > > > and would like all pull requests to have corresponding jira issue
> with
> > a
> > > > fix version so it's easy to track progress and see as complete as
> > possible
> > > > release notes. Maybe the WoW around this needs to be aligned a bit
> more
> > > > among the developers in the Maven dev community.
> > > >
> > > > - Eric L
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.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 Dependency Analyzer version 1.11.2

[Benson Margulies]

+1 binding.


On Thu, Jul 23, 2020 at 5:39 PM Eric Lilja  wrote:

> On Fri, Jul 24, 2020 at 12:06 AM Sylwester Lachiewicz <
> slachiew...@gmail.com>
> wrote:
>
> > +1
> >
> > in fact, in this release, based on commits, we have also fixed:
> > MSHARED-879 Reproducible builds
> > MSHARED-810 Support for Java 12
> > MSHARED-792 Maven Dependency Analyzer ignores Java 8 type annotations on
> > local variables
> >
> > All the above tasks was assigned to the next planned version 3.0, now all
> > fix tags where corrected.
>
>
>   Vote: +1 non-binding
>
> Thanks for highlighting this, Sylwester. I think we have the same situation
> in maven-site-plugin (and maybe elsewhere). Issues fixed without a fix
> version. I usually look at the next version in Jira to see what issues are
> already completed to make it into the next release and what other,
> non-completed issues, also share the same fix version (I know some
> components have several future versions, which may have their own
> issues, like Maven itself, or surefire, but most do not is my experience).
> I would like to track all changes in Jira, including dependency upgrades
> and would like all pull requests to have corresponding jira issue with a
> fix version so it's easy to track progress and see as complete as possible
> release notes. Maybe the WoW around this needs to be aligned a bit more
> among the developers in the Maven dev community.
>
> - Eric L
>

Committer access for my google identity at github

[Benson Margulies]

id.apache.org lists bimargulies-google as an ID for me, but I don't see
write access at github.com. Does someone have to do something?

Re: Plexus Logging API

[Benson Margulies]

We made a community decision years ago to support slf4j. It's not helpful
to cast aspersions on it. If someone wants to lead an effort to supplant
that with log4j now that it's alive again, or even jul (please, no),
someone can start that process. Until then, using slf4j in an plugin is an
approved and reasonable decision, I think.


On Sun, May 31, 2020 at 2:00 PM Elliotte Rusty Harold 
wrote:

> I'd be happy to use JUL instead if that works better. No extra
> dependencies at all, and presumably no version conflicts.
>
> For the moment I'm not proposing any major changes to existing APIs,
> aside from perhaps marking some classes no longer implement
> AbstractLogEnabled. My question is when we have the typical logging
> cases in a plugin or library, i.e.
>
> 1. An exception is thrown and we want to log an error
> 2. We want to print some output from the plugin on the console
>
> What API do we invoke? The simplest thing we could possibly do is call
>
> Logger.getAnonymousLogger().warn( "message", ex );
>
> but whatever folks prefer is fine with me.
>
>
>
> On Sun, May 31, 2020 at 3:41 PM Romain Manni-Bucau
>  wrote:
> >
> > True but JUL is also there since more time, no?
> >
> > More seriously I think most plugins stick to getLog and bridge the output
> > cause otherwise the behavior is often undefined depending the stack.
> >
> > For ex, exec:java maven plugin generally breaks slf4j binding, so most
> impl
> > caring of logs (:run) just forward it to the secured api which is Log.
> >
> > If we want to discuss plugin logging api i think we need another thread
> but
> > i wouldnt pick slf4j.
> >
> > Le dim. 31 mai 2020 à 21:35, Sylwester Lachiewicz 
> a
> > écrit :
> >
> > > Just note - we already have SLF4J API from Maven 3.1 [1] available for
> all
> > > plugins since 2013.
> > >
> > > Sylwester
> > > [1] http://maven.apache.org/maven-logging.html
> > >
> > >
> > > niedz., 31 maj 2020 o 20:49 Xeno Amess 
> napisał(a):
> > >
> > > > I like slf4j.
> > > > But slf4j can cause dependency hell as it really lack something
> > > > named backward compatibility.
> > > > I met that thing in one of my repo.
> > > > Really bad experience for me.
> > > >
> > > > Romain Manni-Bucau  于2020年6月1日周一 上午2:35写道：
> > > >
> > > > > Hmm,we are already bound to slf4j simple logger by conf and we dont
> > > want
> > > > to
> > > > > break it so less costly is slf4j, will avoid to reimpl the binding
> > > > (needed
> > > > > with jul and log4j)...but does not solve all issues with plugins
> and
> > > > > conflicts (jul would). That said not sure we can do better without
> a
> > > huge
> > > > > investment not worth it so let's clean things a bit if we can or
> just
> > > > keep
> > > > > it as it since it does not hurt at all IMHO.
> > > > >
> > > > > Le dim. 31 mai 2020 à 20:24, Gary Gregory 
> a
> > > > > écrit :
> > > > >
> > > > > > I'm sure you all know that Apache's own Log4j 2 has it's own API
> > > facade
> > > > > > with a backing implementation and bridges to other logging
> systems
> > > like
> > > > > > SLF4 and Logback, and Java Logging. Not only that but it is
> actively
> > > > > > maintained by more than a single  BDFL (like yours truly) I won't
> > > > debate
> > > > > > the pros vs slf4j...
> > > > > >
> > > > > > ;-)
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Sun, May 31, 2020, 13:41 Robert Scholte  >
> > > > wrote:
> > > > > >
> > > > > > > Some pro's and cons:
> > > > > > >
> > > > > > > There have always been concerns about SLF4J, especially
> because it
> > > is
> > > > > > > maintained by only one person.
> > > > > > > Although Ceki did help us to make Maven work well with SLF4J,
> it
> > > > still
> > > > > is
> > > > > > > a risk.
> > > > > > > Depending on third party libraries always comes with a risk.
> > > > > > > Having our own logging interfaces (I don't consider plexus as a
> > > third
> > > > > > > party library, as it is maintained by Maven developers) means
> could
> > > > > > switch
> > > > > > > to another framework at any time.
> > > > > > > That said, we might even switch to the Java Logging Framework,
> as
> > > > > > > available since Java 1.4
> > > > > > >
> > > > > > > On the other hand, SLF4J has become the leading standard, so
> even
> > > in
> > > > > the
> > > > > > > worst case scenario I expect there will a way to keep using the
> > > > current
> > > > > > > SLF4J API.
> > > > > > >
> > > > > > > One of the benefits of dropping Plexus Logging is getting rid
> of
> > > > > > > the AbstractLogEnabled and LogEnabled classes, which bind the
> > > > > components
> > > > > > > very strict to the Plexus logging framework.
> > > > > > >
> > > > > > > thanks,
> > > > > > > Robert
> > > > > > > On 31-5-2020 19:21:51, Elliotte Rusty Harold <
> elh...@ibiblio.org>
> > > > > wrote:
> > > > > > > To be clear, my proposal is not to do anything to the plexus
> > > logging
> > > > > > > API or the code in the plexus project. I simply would like to
> > > chamge
> > > > > > > some Maven 

Re: Modernizing plugin dependencies

[Benson Margulies]

Would it make sense to branch from 2.1 and do a controlled update? What
version of maven core are we willing to require?


On Wed, May 13, 2020 at 1:41 PM Benson Margulies 
wrote:

> 2.1 has a terrible bug; it does not compensate for long-ago changes in
> which ArtifactItem.getClassifier() returns null instead of "".
>
> I think then perhaps branching it and making a 2.1.1 is called for.
>
>
> On Wed, May 13, 2020 at 5:52 AM Karl Heinz Marbaise 
> wrote:
>
>> Hi,
>>
>> On 13.05.20 01:59, Benson Margulies wrote:
>> > What's current best practice for updating the versions of the test
>> harness
>> > and other bits and bobs?
>> >
>>
>> the problem with Test harness is that it brings more recent versions of
>> maven-core with it which is from my point of view a no go for test
>> harness more recent versions ...That's the reason why it is currently
>> kept at version 2.1...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>

Re: Modernizing plugin dependencies

[Benson Margulies]

2.1 has a terrible bug; it does not compensate for long-ago changes in
which ArtifactItem.getClassifier() returns null instead of "".

I think then perhaps branching it and making a 2.1.1 is called for.


On Wed, May 13, 2020 at 5:52 AM Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 13.05.20 01:59, Benson Margulies wrote:
> > What's current best practice for updating the versions of the test
> harness
> > and other bits and bobs?
> >
>
> the problem with Test harness is that it brings more recent versions of
> maven-core with it which is from my point of view a no go for test
> harness more recent versions ...That's the reason why it is currently
> kept at version 2.1...
>
> Kind regards
> Karl Heinz Marbaise
>

Modernizing plugin dependencies

[Benson Margulies]

What's current best practice for updating the versions of the test harness
and other bits and bobs?

https://issues.apache.org/jira/browse/MDEP-480

[Benson Margulies]

I'm helping someone dust this off as a warm up to development in the
plugin. Could folks have a look at the JIRA and see if the feature makes
sense?

Re: Merging via GitHub

[Benson Margulies]

Could you send me a pointer to refresh my memory on procedures? It's been a
while ...

On Mon, May 11, 2020 at 1:42 PM Michael Osipov  wrote:

> Folks,
>
> please do NOT merge via merge button in GitHub:
>
> > commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master,
> origin/HEAD)
> > Merge: 34253e3d f7de3a6e
> > Author: Elliotte Rusty Harold 
> > Commit: GitHub 
> >
> > Merge pull request #66 from apache/plex
> >
> > [SCM-930] update plexus-utils
> >
> > commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9
> > Author: Elliotte Rusty Harold 
> > Commit: Elliotte Rusty Harold 
> >
> > update plexus-utils
>
> 1. It produces useless merge commits
> 2. GitHub is NOT a blessed committer
>
> It is OK, wenn a clean rebased merge is performed and not traces of
> GitHub are left.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Running mojo unit test in the debugger

[Benson Margulies]

I am trying to recall how to debug a Junit test that uses
AbstractMojoTestCase. Simply asking an IDE to debug the test fails with
plexus container errors. I cannot recall if these can be debugged as
ordinary unit tests somehow, or whether we need to set remote debugging
options to the surefire plugin and attach the debugger.

MSHADE-209: 'too expensive test'

[Benson Margulies]

There's a good patch in a PR. It has no test, and the author references

https://github.com/apache/maven-plugins/blame/8762d5746501b894cf766f38111fc514938be280/maven-shade-plugin/src/test/java/org/apache/maven/plugins/shade/filter/MinijarFilterTest.java

containing a commented out test case marked 'too expensive'.

Could anyone comment on the decision process here? We have a lot of
expensive tests, what's so bad about this one?

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

[Benson Margulies]

Is it still non-critical if the user lacks write access to that directory?

On Sat, Feb 25, 2017 at 8:07 AM, Robert Scholte  wrote:
> Hi,
>
> found a non-critical issue. It seems like with every Maven build, a new
> lib/ext/jansi-64-1-xxx.13 is generated.
> If this is a temp-file, I'd rather write it to the OS temp folder instead of
> the Maven distribution.
>
> Robert
>
> On Thu, 23 Feb 2017 17:10:18 +0100, Stephen Connolly
>  wrote:
>
>> Hi,
>>
>> We solved 65 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12339664=Text
>>
>> There are still a couple of issues left in JIRA for 3.5.0, but I do not
>> think any of those are blocking an alpha release:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> In addition there are 315 issues left in JIRA for Maven core:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1324
>>
>> The distributable binaries and sources for testing can be found here:
>>
>> https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/
>>
>> Specifically the zip, tarball, and source archives can be found here:
>>
>> https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-bin.zip
>>
>> https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-bin.tar.gz
>>
>> https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-src.zip
>>
>> https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-src.tar.gz
>>
>> Source release checksum(s):
>> apache-maven-3.5.0-alpha-1-src.tar.gz sha1:
>> 6055696aece5b0bfdd0308dae60838b37e218aba
>> apache-maven-3.5.0-alpha-1-src.zip sha1:
>> 7d6adcdf8929205bf20399c71c6a2bdb9ee4f6dd
>>
>> Git tag:
>>
>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8e6bbc4d4aa7cdc837625a05358c98ca15f72698
>>
>> Staging site:
>> https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>>
>> Thanks,
>> -Stephen
>
>
> -
> 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: Build Maven offline

[Benson Margulies]

Then don't include it in the distro. Packaging non-standard, possibly
broken, versions in distros is not doing anyone any favors. Users are
better off just downloading for themselves.

On Mon, Feb 13, 2017 at 8:47 AM, Guo Yunhe  wrote:
>> Don't. Don't do the same as done here: 
>> https://www.rpmfind.net/linux/RPM/fedora/25/s390x/m/maven-3.3.9-6.fc25.noarch.html
>>
>> The completely disassembled your tarball and build Maven theirselves. This 
>> is a non-canoncial build which we are likely not going to support! The 
>> modifications to this aren't known to us. Rather untar our offical tarball 
>> and rebuilt your package.
>>
>> Though, you have to grab the tarball from the Internet somehow.
>>
>> Michael
>
> I know what you worry about. But the packaging system doesn't allow internet 
> download and compiled binary usually. I have to build it from source somehow.
>
> --
> Guo Yunhe
> Aalto University
> Espoo, Finland
>
> -
> 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: MNG-5567: Zips on classpath

[Benson Margulies]

How? When I declare a zip dependency on a non-reactor artifact, it is
just zip. Packaging doesn't show up in , or
is this what you are proposing?

On Thu, Feb 9, 2017 at 12:18 PM, Michael Osipov <micha...@apache.org> wrote:
> Am 2017-02-09 um 21:10 schrieb Benson Margulies:
>>
>> -1 to zips on the classpath. We need to disentangle the java classpath
>> from the general concept of 'module X depends on module Y'. I created
>> quite a lot of code that uses zips as containers to pass files from
>> one place to another, and would be horribly broken if their transitive
>> dependencies started showing up.
>
>
> This is because we finally need packaging zip. It would solve your problem.
>
>
> -
> 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: MNG-5567: Zips on classpath

[Benson Margulies]

-1 to zips on the classpath. We need to disentangle the java classpath
from the general concept of 'module X depends on module Y'. I created
quite a lot of code that uses zips as containers to pass files from
one place to another, and would be horribly broken if their transitive
dependencies started showing up.

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

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

[Benson Margulies]

there is always merge --squash. Makes the master history dead simple
on the theory that no one cares about the dev history of a feature
branch.

On Mon, Jan 16, 2017 at 1:24 AM, Christian Schulte  wrote:
> Am 16.01.2017 um 10:21 schrieb Stephen Connolly:
>> or if you want less commands
>>
>> git checkout BRANCH
>> git pull --rebase origin master
>> git push origin BRANCH:master
>> git push origin :BRANCH
>>
>> but personally I prefer to separate the fetch from the rebase as you have
>> at least more of a feeling of control (e.g. you can check the git log
>> origin/master locally first before doing the rebase
>
> Ok. Thanks.
>
>
> -
> 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] Reset Maven Core, Integration Tests and Resolver repository master branches

[Benson Margulies]

+1

On Jan 4, 2017 10:03 AM, "Robert Scholte"  wrote:

> +1
>
> On Wed, 04 Jan 2017 13:16:11 +0100, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Hi,
>>
>> We have collectively managed to mess up our ability to follow the original
>> release plan for 3.4.0 which was originally supposed to consist of an
>> effective no-op change of Eclipse's Aether for the code after migration to
>> Apache's Maven Resolver plus some other orthogonal changes around logging
>> colourization and launcher script bug fixes.
>>
>> Given that some developer private builds of the current master branch have
>> been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been
>> closed with a fixed version of 3.4.0.
>>
>> For us to release a 3.4.0 with those fixes reverted, could cause confusion
>> with our user community.
>>
>> Additionally the informal practice of keeping existing integration tests
>> as
>> RTC has not been followed, leading to some people to question whether the
>> integration tests remain valid.
>>
>> For all the above reasons it is proposed to do *all* the following as an
>> whole:
>>
>> 1. In git://git.apache.org/maven.git we will rename the current master
>> branch to `pre-reset-master` and recreate `master`
>> as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
>> https://github.com/apache/maven/commit/bce33aa2662a51d18cb00
>> 347cf2fb174dc195fb1
>> )
>>
>> 2. In git://git.apache.org/maven-integration-testing.git we will rename
>> the
>> current master branch to `pre-reset-master` and recreate `master`
>> as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
>> https://github.com/apache/maven-integration-testing/commit/f
>> 31241ad6cb6474e559289f1bd7110ea5d5a4fba
>> )
>>
>> 3. In git://git.apache.org/maven-resolver.git we will rename the current
>> master branch to `pre-reset-master` and recreate `master`
>> as b74f7a1e8837875b4780199f644119f55d22465d (
>> https://github.com/apache/maven-resolver/commit/b74f7a1e8837
>> 875b4780199f644119f55d22465d),
>> i.e. the 1.0.x branch
>>
>> We will then proceed to have (ideally) the original committers cherry-pick
>> (and tidy up an squash... if the original committers are not able to
>> assist
>> then squashing may not be practicable) those changes that have been agreed
>> for 3.5.0 as summarized on the
>> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
>> (authorative source of the decisions summarized in the wiki page is the
>> mail thread:
>> https://mail-archives.apache.org/mod_mbox/maven-dev/201612.m
>> box/%3CCA%2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw
>> %40mail.gmail.com%3E
>>  ).
>>
>> As this involves a --force push on the `master` branch, we want to get the
>> approval of the committers before continuing.
>>
>> The vote will be open for at least 72 hours.
>>
>> The vote will be decided by a simple majority of valid votes cast. There
>> is
>> no veto.
>>
>> The vote is open to all committers.
>>
>> In addition, for the vote to be valid, there must be at least 3x+1 votes
>> from PMC members
>>
>> [ ] +1: Yes
>> [ ] 0:
>> [ ] -1: No
>>
>> -Stephen
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

[Benson Margulies]

On Mon, Jan 2, 2017 at 1:38 PM, Hervé BOUTEMY  wrote:

> Christian,
>
> Please read Tibor's concerns:
> - big change,
> - near release (with parallel branches for JUnit 5)
> And I'll add: noise, like addition of final, reordering of imports,
> addition/
> suppression of empty lines
>
> Please follow Tibor's request, which tries to be as kind as possible:
> > So now please revert last change [1] and let's start from the ground.
> > We should again learn from the beginning and start communicating in the
> > community; otherwise this is the end of the project.
>

In my uninteresting opinion, Tibor should formally veto the commit. That's
not un-nice, it's the way to express, clearly and crisply, his view that
the change is not acceptable without further discussion and refinement. On
the other hand, I don't think that the remarks about 'playgrounds' or
'sandboxes' are appropriate or respectful. We should all assume good intent
and professional intent. We are running a CTR system here, and so we should
expect something like this to happen from time to time, where someone
commits with the best of intentions and someone else feels strongly that
more work is needed.

Once Tibor has vetoed, Christian should revert, and then the process should
unfold from there.



> Regards,
>
> Hervé
>
> Le lundi 2 janvier 2017, 18:46:00 CET Christian Schulte a écrit :
> > I am not checking out surefire because I am bored. I get blamed for
> > failing ITs and I am quite pissed that the CI system is sending out
> > failure notifications and all you see is an issue with surefire and not
> > with the build job or the actual build you get an email for. With
> > current master, there are no IT failures (core and plugins) and
> > everything can be build as well. Jenkins has not send out a single
> > success mail although it could do that for a long time already. I
> > re-started the build jobs multiple times a day and they never run
> > through. It's not Jenkins to blame or anything about the CI system. Most
> > of the time it's surefire. There is one core IT failing sporadically on
> > Windows which seems to have to do with some core extension classpath
> > ordering issue. I don't know. No-one seems to care about that. It could
> > have been introduced by the changes to add support for extension.xml
> > files. Nothing I have worked on. The core has been released with that IT
> > failing.
> >
> >
> >
> > -
> > 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: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

[Benson Margulies]

The normal Apache process here is this: if someone finds a commit
sufficiently objectionable, as per CTR, they
https://www.apache.org/foundation/glossary.html#Veto it. It gets reverted
post haste, no vote is needed.


According to the Apache methodology, a change which has been made or
proposed may be made moot through the exercise of a veto by a committer to
the codebase  in
question. If the R-T-C
 commit
policy is in effect, a veto prevents the change from being made. In either
the R-T-C or C-T-R

environments,
a veto applied to a change that has already been made forces it to be
reverted. Vetos may not be overridden nor voted down, and only cease to
apply when the committer who issued the veto withdraws it. All vetos *must* be
accompanied by a valid technical justification; a veto without such a
justification is invalid; in case of doubt, deciding whether a technical
justification is valid is up to the PMC. Vetos force discussion and, if
supported, version control rollback or appropriate code changes. Vetoed
code commits are best reverted by the original committer, unless an urgent
solution is needed (e.g., build breakers). Vetos only apply to code
changes; they do not apply to procedural issues such as software releases.

On Mon, Jan 2, 2017 at 11:36 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Well I'm not happy with how development has evolved here, hence my rather
> vocal stepping up tovtr and pull core back into order.
>
> If you want to do a reset, you'll need a vote from committers ok-zing the
> reset.
>
> Do NOT call a vote without ensuring that you have consensus *first*.
>
> Votes should be used to *confirm* consensus not establish it.
>
> When you have a vote first, it divides the community into the +1's and the
> -1's.
>
> When you have a discussion first, you can identify the concerns of people
> likely to vote -1 up front and modify the proposal to include them such
> that they become a 0 or even a +1. That will grow and strengthen our
> community.
>
> I would hate to see us move to RTC, as that requires a higher level of
> involvement from committers in order to get changes made... though it seems
> committers have been running as C rather than CTR... where is the evidence
> of the TRs?
>
> With CTR, each commit is an implicit vote where the absence of a -1 after
> 72h implies approval.
>
> Another option, rather than a reset is you could *veto* the commit.
>
> Vote -1 on the commit, by replying to the commit email and state your
> reasoning. The original committer is then required to either address your
> concerns or revert the commit.
>
> Vetoing an individual commit is normally seen as rude, but if it is the
> correct thing to do, then do it.
>
> The situation on core+integration-tests is somewhat different. A lot of
> those commits are probably fine... but just should not be in the first
> release after 3.3.9... and reverting only to restore again later will only
> further complicate a history that already has quite a few reverts and
> reworks... in that regard I feel a reset is appropriate... and so far I
> have not seen any disagreement (such that I expect to call a vote on
> Wednesday - giving a little more seasonal time for confirmation of
> consensus)
>
> I do think we need to get into at least a more "branchy" development
> style... if not full fledged PRs, though we need better CI support to
> assist (again I am working on that for core+integration-tests)
>
>
> On Mon 2 Jan 2017 at 14:42, Tibor Digana  wrote:
>
> > I also have such feeling that Maven became a playground.
> >
> > Last week I saw it in reality and after Robert told me we made playground
> >
> > in our sources I could not believe this could happen in such professional
> >
> > project like Maven.
> >
> >
> >
> > I would appreciate it if the change [1]
> >
> > e5a6b9c8d4f514100a01dea2acf1fb059e294968 was reverted in Surefire and a
> new
> >
> > pull request was open at GitHub making the code review.
> >
> > I use to do this with myself with big changes and I am waiting for anyone
> >
> > in the PR. We are doing the same with one excellent guy from another ASF
> >
> > project who is supporting us with JUnit 5 addons and this works pretty
> > well.
> >
> >
> >
> > The situation in Surefire is quite ambitious to release Versions 2.19.2
> and
> >
> > 3.0.0-RC1 in parallel with 2.19.3 JDK9 support and JUnit 5 support now in
> >
> > January.
> >
> >
> >
> > The problem is that these Surefire three plugins are so easy to crash
> with
> >
> > whatever changes and therefore I implemented dumping internal errors to
> >
> > dump files which will help us investigate two Jira issues - critical and
> >
> > blocker. And there are much more thinks to talk about the features...
> >
> >
> >
> > I would 

Re: [VOTE] Maven Assembly Plugin 3.0.0

[Benson Margulies]

There is no reason to cancel over one missing link. If there are
enough +1 votes, the vote passes. There's no need to view a -1 as a
veto, especially if it's something that can be fixed up later.


On Sun, Nov 6, 2016 at 6:22 PM, Michael Osipov  wrote:
> Am 2016-11-07 um 00:13 schrieb Olivier Lamy:
>>
>> Hi
>> So I have to cancel.
>> Always funny to see old issues popping up and turning as critical when
>> someone want to release :P
>> @Michael
>> Regarding https://maven.apache.org/plugins-archives/index.html if you
>> mention the link from breadcrumb that's something generated by site plugin
>> and it's a relative link so it will work with the site deployed to the non
>> staged location.
>
>
> I noticed this earlier this day. No issue here. Just mislead.
>
>> I personally think voting -1 for missing link is just totally
>> inappropriate!!
>
>
> Unvote that but component.html link is still broken.
>
>> What will you vote for real technical problem??!!
>
>
> -2? :-D
>
> I'm just saying that some stuff is misleading for a new major release and it
> deserves to be fixed, especially when documentation does not match reality.
>
>
>> On 6 November 2016 at 07:23, Christian Schulte  wrote:
>>
>>> The plugin is affected by
>>> .
>>> Would it be possible to release the plugin with downgraded
>>> 'plexus-interpolation' 1.21?
>>>
>>> Am 11/05/16 um 02:07 schrieb Olivier Lamy:

 Hi,

 We solved 34 issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?
 version=12330359=Text=12317220=Create

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1295/
 https://repository.apache.org/content/repositories/maven-
 1295/org/apache/maven/plugins/maven-assembly-plugin/3.0.0/
 maven-assembly-plugin-3.0.0-source-release.zip

 Source release checksum(s):
 maven-assembly-plugin-3.0.0-source-release.zip sha1:
 faeacc0f237f17d99455fced91ec3e667ba69493

 Staging site:
 https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/

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

 Vote open for at least 72 hours.

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

>>>
>>>
>>> -
>>> 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

Combining parent and child configuration

[Benson Margulies]

I'm helping out a bit with the bnd-maven-plugin.

They are currently recursing up the chain of parents, looking at the
DOM for , to combine parent and child information.

There's 
http://blog.sonatype.com/2011/01/maven-how-to-merging-plugin-configuration-in-complex-projects/,
but

(a) gosh it looks messy, and
(b) it doesn't work for scalar properties. -  the code in there
collects a scalar String from each level of parent and combines them
into a list.

is there some other technique for accumulating configuration up the
parent chain that I'm missing?

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

Anyone want to put a better general include/exclude filter in core?

[Benson Margulies]

This is adapted from a class in the shade plugin

https://github.com/benson-basis/alta/blob/issue-5-include-exclude/src/main/java/com/github/veithen/alta/IncludeExcludeArtifactFilter.java

I think it would live next to:

org.apache.maven.artifact.resolver.filter.IncludesArtifactFilter

pretty happily.

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

Re: opinions on MJAVADOC-451

[Benson Margulies]

On Fri, Aug 5, 2016 at 10:37 AM, Christopher  wrote:
> I'm always in favor of adding skip properties. They are very useful for
> manipulating builds for debugging, running on CI servers, controlling
> executions in child poms, etc. Even if it's not recommended to run
> unattended, it's still possible, so a skip option is useful.

Me too.  I don't see the point about arguing that some goal 'doesn't
belong in a lifecycle'. We can't predict what people will find useful.

>
> On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:
>
>> Anyone want to give this a quick read/opinion? :-)
>>
>> -Richard
>>
>> -- Original Message --
>>
>> From: "Richard Sand" 
>> To: dev@maven.apache.org
>> Sent: 8/1/2016 6:33:30 PM
>> Subject: opinions on MJAVADOC-451
>>
>> >Hi all,
>> >
>> >I'd like to ask for opinions on
>> >https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
>> >I have been discussing this off list and essentially disagree on it.
>> >
>> >The request is very simple - to add a "skip" parameter to the
>> >javadoc:fix goal. In my projects we are using the fix goal unattended,
>> >i.e. with the parameter "force=true", as part of the regular build
>> >lifecycle.
>> >
>> >Most goals (including javadoc) that run in the regular lifecycle have a
>> >skip option. Robert's position (and forgive me if I misrepresent this
>> >at all Robert and please weigh in) is that javadoc:fix should not be
>> >used in the lifecycle and that the goal should in fact have
>> >requireDirectInvocation=true. He also pointed out to me that I can
>> >create a profile to enable/disable the goal as an alternative.
>> >
>> >My opinion is that, since the goal does not require direct invocation,
>> >then running within the lifecycle has to be considered acceptable use
>> >of the goal. And having a skip parameter adds 5 lines of code, is a
>> >common and normal pattern used by many other plugins/goals, and allows
>> >the goal to be used in this fashion without introducing even more
>> >profiles.
>> >
>> >I've submitted patches for this issue and also several other issues in
>> >the javadoc plugin as I continue to work through getting the goal to
>> >work well automated. Just pointing out that I'm not just asking for the
>> >larger community to do stuff to make my life easier - I'm trying to
>> >contribute as best I can and provide patches for what I uncover.
>> >
>> >Best regards,
>> >
>> >Richard
>> >
>> >

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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Benson Margulies]

We have this body of code. People in the world use it.  Refactoring
this code to break its existing users, just to avoid an awkward name,
strike me as a poor use of time. My suggestion remains that we pick
some inoffensive descriptive string and use it.

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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Benson Margulies]

I my view, we should not be inventing brand names for miscellaneous
internal pieces of Maven. We have hundreds of such pieces. Why give
nicknames to some?

On Thu, Aug 4, 2016 at 11:40 AM, Manfred Moser  wrote:
> I also prefer something like a short name even if its a shortcut like Mars. 
> In fact.. I like Mars. We would have the mars-core and other artifacts and 
> maybe also the Mars Ant Task (port of Aether Ant Tasks.. 
> https://maven.apache.org/components/aether-archives/aether-ant-tasks-LATEST/)
>
> Manfred
>
> Christian Schulte wrote on 2016-08-04 01:49:
>
>> Am 08/04/16 um 02:34 schrieb Ralph Goers:
>>> I much prefer MARS, especially if you can come up with corresponding 
>>> wordplay
>>> for VENUS… ;-)
>>
>> Better than 'resolver'.
>>
>>>
>>> Seriously, the overlap with Java ARchive is bound to be confusing, and might
>>> even make people think that the component has something to do with them.
>>
>> It has. But who...
>>
>>
>> -
>> 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: SHA512 by default for GPG sigs

[Benson Margulies]

Greg, the proposal is for the _Default ASF POM_ to be set up so that
_all_ projects would use SHA-512. This is not a question for the Maven
PMC.

On Wed, May 18, 2016 at 1:58 PM, Greg Trasuk  wrote:
>
> Hi Christopher:
>
> Thanks for your involvement.  Apache Maven is one of many projects at the 
> Apache Software Foundation.  Each project has its own mailing lists.  So your 
> discussion should probably go to dev@maven.apache.org, which I’ve cc’d on 
> this response.  If you’re not subscribed to that list, you probably should do 
> that as well - check the Apache Maven web site (http://maven.apache.org) for 
> more info.
>
> Thanks again,
>
> Greg Trasuk
>
>> On May 18, 2016, at 1:45 PM, Christopher  wrote:
>>
>> Hi all,
>>
>> I'm not sure a better list to get feedback on, but I wanted to bring
>> attention to the proposal here:
>> https://issues.apache.org/jira/browse/MPOM-118
>>
>> Essentially this is a suggestion to configure the maven-gpg-plugin to sign
>> using SHA512 as its digest algorithm in the ASF Parent POM, used by many
>> Maven/Java-based projects within ASF. This configuration takes affect
>> during software releases when this plugin is activated (typically prior to
>> a release candidate vote, and staging a release in Nexus for distribution
>> to Maven Central).
>>
>> This would only affect the hash algorithm used to generate GPG signatures
>> for releases, and not any separate SHA/MD hashes published separately by
>> any project, which can be weaker (SHA1, MD5) for convenience, and don't
>> convey the strong authenticity statement that digital signatures provide.
>>
>> For background, gpg uses SHA1 by default, unless the signing key or gpg
>> configuration has a preference to use another algorithm (as described on
>> https://www.apache.org/dev/openpgp).
>>
>> This proposed configuration change wouldn't force the use of SHA512 (it
>> could still be overridden by a project), but it would make it the default,
>> which helps improve the security of releases in the case where release
>> managers have failed to keep their configuration up-to-date with the best
>> recommendations for using gpg.
>>
>> Thoughts? +1s? Discuss here or on the JIRA please.
>>
>> Thank you.
>
>
> -
> 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: help review/accept [MSHADE-182]

[Benson Margulies]

The tools jar is an old standby, do you need someone to fix a pom to
have the right profile?


On Tue, Jan 26, 2016 at 3:34 PM, Arnaud Héritier  wrote:
> No feedback guys ?
>
> On Thu, Jan 21, 2016 at 11:02 PM, Arnaud Héritier 
> wrote:
>
>> Build (install -Prun-its) of the PR:
>> Ok with Java 7 and Maven 3.3.9 on MacOS X
>> Ko with Java 6 and Maven 3.2.5 on MacOS X
>>
>> [INFO] Building: MSHADE-185/pom.xml
>> [INFO] ..FAILED (1.4 s)
>>
>> Could not find artifact com.sun:tools:jar:1.6 at specified path
>> /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/../lib/tools.jar
>>
>> But the issue is the same for me on master branch thus there is no
>> regression with the PR
>>
>>
>> On Thu, Jan 21, 2016 at 9:30 PM, Arnaud Héritier 
>> wrote:
>>
>>> Hi,
>>>
>>>   I may try to help but I imagine that it's not only a merge to do.
>>>   I had a look at the current shade build (without your fix) and it is
>>> failing on another test on MacOS
>>>   Am I the only one ?
>>>
>>> Best regards
>>>
>>> On Fri, Jan 15, 2016 at 12:37 PM, Kanstantsin Shautsou <
>>> kanstantsin@gmail.com> wrote:
>>>
 Hi, could somebody help with processing
 https://issues.apache.org/jira/browse/MSHADE-182
 https://github.com/apache/maven-plugins/pull/79

 Bug exists for 1 year. Everything described in PR and issue.

>>>
>>>
>>>
>>> --
>>> -
>>> Arnaud Héritier
>>> http://aheritier.net
>>> Mail/GTalk: aheritier AT gmail DOT com
>>> Twitter/Skype : aheritier
>>>
>>
>>
>>
>> --
>> -
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>>
>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier

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

Re: [VOTE] Release Apache Maven JAR Utilities version 1.2

[Benson Margulies]

+1

On Sat, Jan 2, 2016 at 8:42 PM, Michael Osipov  wrote:
> Am 2015-12-31 um 21:30 schrieb Michael Osipov:
>>
>> Hi,
>>
>> We solved 5 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12334441
>>
>>
>> There are still a couple of issues left in JIRA:
>>
>> https://issues.apache.org/jira/issues/?jql=component%20%3D%20maven-shared-jar%20AND%20project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
>>
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1242/
>>
>> https://repository.apache.org/content/repositories/maven-1242/org/apache/maven/shared/maven-shared-jar/1.2/maven-shared-jar-1.2-source-release.zip
>>
>>
>> Source release checksum(s):
>> maven-shared-jar-1.2-source-release.zip sha1:
>> 0fce6592e9ffc2d31b3ad9e59d6a488af31f78ac
>>
>> Staging site:
>> https://maven.apache.org/shared-archives/maven-shared-jar-LATEST/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>
>
> Guys,
>
> less than a day to go. I need votes.
>
> Here is my +1.
>
>
> -
> 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: What happened to Maven Eclipse Plugin?

[Benson Margulies]

On Fri, Dec 25, 2015 at 4:22 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> Yeah, I've avoid m2e until the other day to see if it got any better. Not.
> So your solution is to switch IDEs... hm, not a huge fan of IJ... is there
> an Eclipse-like Java Perspective? I find file based editing retarded.

I don't understand the question. Generally, I would apply the term
'perspective' to Eclipse. I do still know people who live happily in
GNU Emacs with Java, not that I'm prepared to do that myself at this
point.


I find that IJ in its current form is not so different from Eclipse
was, only it doesn't eat my machine and crash as Eclipse + M2E used to
do back before I made the switch. You have a tree of files or packages
on the left, and one or more windows of code on the right, and some
tool at the bottom.

>
> Gary
> On Dec 25, 2015 12:49 PM, "Benson Margulies" <bimargul...@gmail.com> wrote:
>
>> Eclipse's single classpath makes it fundamentally broken with any maven
>> project that has test dependences. So some of us bailed to intellij long
>> ago.  m-e-p has one set of incurable issues, and m2e, while much improved,
>> can still eat all your memory on a moderate project.
>>
>> We've watched the lack of maintainers for long enough. It fails the apache
>> test of offering reasonable responsiveness on the mailing list, so it needs
>> to go.
>> On Dec 25, 2015 3:38 PM, "Gary Gregory" <garydgreg...@gmail.com> 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
>> > >
>> > >
>> >
>>

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

Re: What happened to Maven Eclipse Plugin?

[Benson Margulies]

Eclipse's single classpath makes it fundamentally broken with any maven
project that has test dependences. So some of us bailed to intellij long
ago.  m-e-p has one set of incurable issues, and m2e, while much improved,
can still eat all your memory on a moderate project.

We've watched the lack of maintainers for long enough. It fails the apache
test of offering reasonable responsiveness on the mailing list, so it needs
to go.
On Dec 25, 2015 3:38 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: I wish we had a way to declare a dependency that wouldn't participate in the classpath

[Benson Margulies]

On Dec 13, 2015 3:25 AM, "Stephen Connolly" <stephen.alan.conno...@gmail.com>
wrote:

> pom?
>

1. The feature descriptor is xml

2. I believe that this still adds transitive dependencies to the dependency
graph.




>
> On Saturday 12 December 2015, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
> > Sometimes, we want to declare a dependency without changing a classpath.
> >
> > Project A builds an OSGi bundle and a Karaf feature (classifier
> > 'feature', type 'xml').
> >
> > Project B wants to consume the feature. it wants to declare the
> > feature descriptor as a dependency, to (a) ensure reactor order, and
> > (b) make the dependency information available to plugins.
> >
> > But it does _not_ want A's OSGi bundle and it's dependencies in the
> > classpath.
> >
> > The only way out is to exclude them, one-by-one. And when someone adds
> > a dependency to A, you have to maintain the exclusion list.
> >
> > Another example is the tomcat plugin: it needs wars as dependencies,
> > and similarly it needs to avoid having their dependencies in the
> > classpath.
> >
> > To me, this calls out for another scope.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-h...@maven.apache.org
> <javascript:;>
> >
> >
>
> --
> Sent from my phone
>

Re: I wish we had a way to declare a dependency that wouldn't participate in the classpath

[Benson Margulies]

On Sun, Dec 13, 2015 at 3:59 PM, Robert Scholte <rfscho...@apache.org> wrote:
> Op Sun, 13 Dec 2015 21:23:16 +0100 schreef Andreas Gudian
> <andreas.gud...@gmail.com>:
>
>
>> 2015-12-13 12:05 GMT+01:00 Robert Scholte <rfscho...@apache.org>:
>>
>>> The first time I heard about JDK9s Jigsaw having a classpath and a
>>> modulepath, which can be used at the same time AND both containing jars,
>>> I
>>> had a big "OH NO!". We can't change the pom, so the first thing that
>>> came to my mind was indeed using the scope for this. But that'll have a
>>> huge impact: if jars need to be used at compile time but don't have that
>>> scope, what will happen with transitive resolution for example?
>>> I had a small talk with Alan, Mark and Alexander of the Jigsaw team about
>>> this. You could say that this is a new specification of a jar which asks
>>> for a different file-extension. They said that the jar file specification
>>> was extended. I said that we can't expect from users to know what kind of
>>> jar it is. Also, buildtools shouldn't pay the price for analyzing the jar
>>> to discover if it has a module-info or not. Mark immediately answered
>>> that
>>> they should take care of it.
>>> Now that I'm working on the maven-compiler-plugin it looks like it won't
>>> be a compile time issue. However, depending on our approach it might be
>>> an
>>> issue for Surefire.
>>> So yes: I recognize the situation. Dependencies are all very classpath
>>> oriented assuming that a specific type is always used in the same way.
>>>
>>> That's why I want to drop the strict scopes for plugins. Best example is
>>> the maven-javadoc-plugin where you can add jars for bootclasspath,
>>> doclets,
>>> resources, taglets. My idea: don't add these dependencies as
>>> configuration
>>> elements, but as standard plugin dependencies with there own scope. And
>>> since there dependencies are specific for this plugin, it can choose any
>>> scope it likes and select them within its own Mojo code.
>>>
>>
>> But I would guess such specially scoped dependencies still show up on the
>> classpath of the plugin itself, right? For example, right now I'm looking
>> into MCOMPILE-203 which is about configuring the -processorpath option of
>> javac. Right now I have it working locally with a new
>> configuration-element. Using a special scope in the plugin-dependency
>> would, currently, mean polluting the plugins classpath - which wouldn't be
>> that ideal.
>>
>> Or are plugin-dependencies with funky scopes already filtered out right
>> now?
>>
>
> I would expect that for plugins only the compile and runtime scoped
> dependencies are used as their whitelist.
> Not sure what will happen with unknown scopes, but it it works then it is
> quite hard to get those dependencies (maybe including their transitive ones)
> IMO it is Maven which is responsible for resolving dependencies, and not the
> plugin with its own configuration.

The idea that I would write in a JIRA, if it passed a certain level of
plausibility-testing here, is this:

When the compile plugin and the surefire plugin (main examples) are
building classpaths, they should prune at type!=jar. No change to the
dependency tree, only to the management of classpaths by the plugins
that, well, manage classpaths. They could have options to change this
behavior in case someone really wants a war file in the classpath for
some reason, but that should not be default behavior. No need, in this
schema, to add a scope.


>
> Robert
>
>
>>>
>>> For plugins such a change is easy, but within the scope of the pom that's
>>> hard.
>>>
>>> Robert
>>>
>>>
>>> Op Sat, 12 Dec 2015 22:04:47 +0100 schreef Benson Margulies <
>>> bimargul...@gmail.com>:
>>>
>>>
>>> Sometimes, we want to declare a dependency without changing a classpath.
>>>>
>>>>
>>>> Project A builds an OSGi bundle and a Karaf feature (classifier
>>>> 'feature', type 'xml').
>>>>
>>>> Project B wants to consume the feature. it wants to declare the
>>>> feature descriptor as a dependency, to (a) ensure reactor order, and
>>>> (b) make the dependency information available to plugins.
>>>>
>>>> But it does _not_ want A's OSGi bundle and it's dependencies in the
>>>> classpath.
>>>>
>>>> The only way out is to exclude them, one-by-one. And when 

Re: I wish we had a way to declare a dependency that wouldn't participate in the classpath

[Benson Margulies]

On Sun, Dec 13, 2015 at 9:40 AM, Benson Margulies <bimargul...@gmail.com> wrote:
> On Dec 13, 2015 3:25 AM, "Stephen Connolly"
> <stephen.alan.conno...@gmail.com> wrote:
>>
>> pom?
>
>
> 1. The feature descriptor is xml
>
> 2. I believe that this still adds transitive dependencies to the dependency
> graph.

How about the following proposition: of the type is not jar, nothing
goes onto the classpath? Not the thing, not its dependencies?

>
>
>
>>
>>
>> On Saturday 12 December 2015, Benson Margulies <bimargul...@gmail.com>
>> wrote:
>>
>> > Sometimes, we want to declare a dependency without changing a classpath.
>> >
>> > Project A builds an OSGi bundle and a Karaf feature (classifier
>> > 'feature', type 'xml').
>> >
>> > Project B wants to consume the feature. it wants to declare the
>> > feature descriptor as a dependency, to (a) ensure reactor order, and
>> > (b) make the dependency information available to plugins.
>> >
>> > But it does _not_ want A's OSGi bundle and it's dependencies in the
>> > classpath.
>> >
>> > The only way out is to exclude them, one-by-one. And when someone adds
>> > a dependency to A, you have to maintain the exclusion list.
>> >
>> > Another example is the tomcat plugin: it needs wars as dependencies,
>> > and similarly it needs to avoid having their dependencies in the
>> > classpath.
>> >
>> > To me, this calls out for another scope.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;>
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> > <javascript:;>
>> >
>> >
>>
>> --
>> Sent from my phone

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

I wish we had a way to declare a dependency that wouldn't participate in the classpath

[Benson Margulies]

Sometimes, we want to declare a dependency without changing a classpath.

Project A builds an OSGi bundle and a Karaf feature (classifier
'feature', type 'xml').

Project B wants to consume the feature. it wants to declare the
feature descriptor as a dependency, to (a) ensure reactor order, and
(b) make the dependency information available to plugins.

But it does _not_ want A's OSGi bundle and it's dependencies in the classpath.

The only way out is to exclude them, one-by-one. And when someone adds
a dependency to A, you have to maintain the exclusion list.

Another example is the tomcat plugin: it needs wars as dependencies,
and similarly it needs to avoid having their dependencies in the
classpath.

To me, this calls out for another scope.

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

How the Lucene PMC manages releases

[Benson Margulies]

Given the number of 'burned' releases recently, I thought people might
be interested in hearing about an alternative approach.

When a Lucene dev has a sudden urge to make a release, he or she set
up a release with a version of x.y.z-RC1. This is a real release. It
goes up for a vote.

If there's something grossly wrong with it, the RM burns it and tries
again with RC2, etc.

If it passes the vote, the user community (not just the dev community)
is invited/exhorted to test it for a bit. Problems are repaired. If
the fixes are significant, then the the next step is another RC. When
an RC is clean, or manifests only tiny problems, the RM goes ahead and
puts up x.y.z for a vote.

The result of this is that a non-RC release hardly every gets burned.

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

Re: How the Lucene PMC manages releases

[Benson Margulies]

On Sun, Nov 15, 2015 at 2:35 PM, Paul Benedict <pbened...@apache.org> wrote:
> That's how it use to work, but that requires a double voting process: vote
> once on the RC and then again if the RC is ready for production. It's
> easier to just burn the numbers; if it fails, move to the next; otherwise
> you release what you have.

There's an advantage that I think you might be missing. When you vote
an RC, it becomes a formal release, and you can advertise it to the
user community for testing, which might get you more testers than you
get on the dev@ list.


>
>
> Cheers,
> Paul
>
> On Sun, Nov 15, 2015 at 11:48 AM, Anders Hammar <and...@hammar.net> wrote:
>
>> That's how Maven core releases were done in the early v3.0.x days.
>> Personally I think it worked very good.
>>
>> /Anders (mobile)
>> On Nov 15, 2015 15:40, "Benson Margulies" <bimargul...@gmail.com> wrote:
>>
>> > Given the number of 'burned' releases recently, I thought people might
>> > be interested in hearing about an alternative approach.
>> >
>> > When a Lucene dev has a sudden urge to make a release, he or she set
>> > up a release with a version of x.y.z-RC1. This is a real release. It
>> > goes up for a vote.
>> >
>> > If there's something grossly wrong with it, the RM burns it and tries
>> > again with RC2, etc.
>> >
>> > If it passes the vote, the user community (not just the dev community)
>> > is invited/exhorted to test it for a bit. Problems are repaired. If
>> > the fixes are significant, then the the next step is another RC. When
>> > an RC is clean, or manifests only tiny problems, the RM goes ahead and
>> > puts up x.y.z for a vote.
>> >
>> > The result of this is that a non-RC release hardly every gets burned.
>> >
>> > -
>> > 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

3-ing maven plugins

[Benson Margulies]

Could some kind soul please remind me of the wiki page where we've got
a procedure for making plugins come up to the maven three base level?
I want to do it to the maven-bundle-plugin over at felix (assuming,
for the moment, that enough dependencies have been released) :-)

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

Re: [VOTE] Release Apache Maven Filtering 3.0.0

[Benson Margulies]

+1

On Mon, Nov 9, 2015 at 2:44 PM, Karl Heinz Marbaise  wrote:
> Hi,
>
> someone else ?
>
> Kind regards
> Karl Heinz Marbaise
> On 11/7/15 2:21 PM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> Note: This is a Maven 3.0 / JDK 6 release
>>
>> We solved 6 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12331472
>>
>>
>> There are several issue open:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>>
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1232
>>
>> https://repository.apache.org/content/repositories/maven-1232/org/apache/maven/shared/maven-filtering/3.0.0/maven-filtering-3.0.0-source-release.zip
>>
>>
>> Source release checksum(s):
>> maven-filtering-3.0.0-source-release.zip sha1:
>> 7aaeded846ab39af41a94ece6bf5746fdc810800
>>
>> Staging site:
>> http://maven.apache.org/shared-archives/maven-filtering-LATEST/
>>
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Kind regards
>> Karl Heinz Marbaise
>
>
> -
> 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

How to split a component out of shade?

[Benson Margulies]

I recently taught the Apache Felix Maven Bundle Plugin to produce a
dependency-reduced POM. I copied some source code from the
maven-shade-plugin. When/if I update the bundle plugin to a Maven 3
base, I'd prefer to share rather than to copy.

Do we have a common practice? Is the desired process to create yet
another shared component, or just to make the shade plugin build have
a subproject for the reusable piece?

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

Re: Updating the default versions for maven-compiler-plugin

[Benson Margulies]

-1. We might want to move to 1.7, but many people are still not in a
position to use 1.8.

On Fri, Nov 6, 2015 at 7:56 AM, Attila-Mihály Balázs  wrote:
> Hello,
>
> Given that we're almost in 2015, what do people think about updating the
> default source / target for maven-compiler-plugin to 1.8? (And also on the
> site:
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html).
>
> If there is interest, I'm happy to submit a patch!
>
> Cheers,
> Attila Balazs (Grey Panther)
>
> -
> 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 Shared Components POM Version 22

[Benson Margulies]

+1

On Sat, Oct 31, 2015 at 4:48 PM, Karl Heinz Marbaise  wrote:
> Hi,
>
> JIRA Reference:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12328931
>
> Changes since the last release:
> http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-22/pom.xml?r1=HEAD=1632934_format=h
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1231
> https://repository.apache.org/content/repositories/maven-1231/org/apache/maven/shared/maven-shared-components/22/maven-shared-components-22-source-release.zip
>
> Source release checksum(s):
> maven-shared-components-22-source-release.zip sha1:
> 3d15806931d6ee32e32cdde591357d7d02225eb5
>
> Staging site:
> http://maven.apache.org/pom-archives/maven-shared-components-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> 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: easing Maven parent poms management

[Benson Margulies]

+1. I had infra set up a staging group for us some time ago to make
this easier; you can stage all of them and test by using the repo URL
for the staging group.

On Sun, Nov 1, 2015 at 8:00 AM, Karl Heinz Marbaise  wrote:
> Hi,
>
> +1 for releasing them in one go...
>
>
> On 11/1/15 10:03 AM, Hervé BOUTEMY wrote:
>>
>> Currently, we have 5 Maven parent POMs [1] (not counting Doxia), each with
>> its
>> own release cycle.
>> Releasing each separately is a pain. And knowing which pom is at which
>> version
>> is a pain also.
>
> Unfortunately true...
>
>
>>
>> What would you think of:
>>
>> 1. setting the same version to every Maven parent POM: next would be
>> version
>> 29, since the maximum currently is plugins parent at 28
>
>
> To make a clear step start with version 30
>
> Kind regards
> Karl Heinz Marbaise
>
>>
>> 2. releasing the 5 POMs in only one release
>>
>> This would mean putting all the poms in pom svn [2] (currently plugins
>> parent
>> is in plugins, shared in shared, skins in skin...).
>> I still don't know if the best bet is to make Maven parent the release
>> root:
>> maven
>> |-- plugins
>> |-- shared
>> |-- skins
>> |-- archetypes
>>
>> or if we should create a new parent that is only used as reactor
>>
>> any opinion?
>>
>> Regards,
>>
>> Hervé
>>
>> [1] http://maven.apache.org/pom/index.html
>>
>> [2] http://svn.apache.org/repos/asf/maven/pom/trunk/maven/
>>
>> -
>> 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] Maven 3.3.7

[Benson Margulies]

Sure you can close the PR. Put 'Closes #nn.' in a commit message.
On Oct 28, 2015 4:38 PM, "Stephen Connolly" 
wrote:

> I
>
> On Wednesday 28 October 2015, Michael Osipov  wrote:
>
> > Am 2015-10-28 um 18:28 schrieb Stephen Connolly:
> >
> >> Thanks for contributions from non-committers go to:
> >> *  Martin Schäf
> >> * Joseph Walton
> >> * Keith Turner
> >> * Anton Tanasenko
> >> * Stephen Kitt
> >> * "tssp at web dot de" (whoever you are - a small commit with clear
> >> intent of Apache License grant)
> >> * "sugartxy " (on technical basis of this
> >> change I think this is acceptable to infer a grant of Apache License)
> >> * Florencia Tarditti
> >> * Robert Stern
> >>
> >
> > That is a good example that if you encourage people to contribute and
> > resolve the PRs in time, they will contribute. Some of the commits have
> > been merged by me and I was quite grateful to those who created a PR,
> > regardless how small the improvement is.
>
>
> Yes, and that is why - as well as giving evidence that I have done my duty
> as a PMC member in reviewing the commits involved in the release *from a
> code provenance point of view* - I called out the names ;-)
>
>
> >
> > Though, the lifecycle on GitHub is still mediocre. I cannot request
> > Jenkins to run the tests, I cannot close the PR. For me who has only
> little
> > time for this, the state is somewhat frustrating.
>
>
> Yes I feel your pain... From some recent debate on the ASF board list,
> others feel your pain and there is some banging of heads to find better
> ways of working while maintaining the core needs of the ASF about
> establishing provenance... I am sure things will get better as time
> progresses ;-)
>
>
> >
> > Michael
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Sent from my phone
>

Re: MNG-5899 Project models are no longer mutable in reactor

[Benson Margulies]

On Tue, Oct 27, 2015 at 10:40 AM, Igor Fedorenko <i...@ifedorenko.com> wrote:
> I think this only highlights the need to have immutable core model. The
> bundle plugin has no way to know how the shade plugin manipulates the
> pom and the generated bundle manifest will be based on original project
> model. (assuming I understand your suggested usecase)

At one extreme, we could declare that things like shade can't fit into
the reactor model. If you need to produce an artifact with a pom
different than the pom you start from, you need to build it
separately, put it into a repo, and consume it in other builds. We
have this situation because people don't like that; they want to
incorporate changes to the dependency tree in the reactor process.
That's what you'd have with a 100% immutable model. So, we could ask,
is there anything we can design that supplies the feature without
making a giant mess?

>
> --
> Regards,
> Igor
>
> On Tue, Oct 27, 2015, at 10:12 AM, Benson Margulies wrote:
>> On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko <i...@ifedorenko.com>
>> wrote:
>> > Did you really mean "the core model has to be mutable"? The rest of your
>> > message appears to suggest you do not want the model to be mutable, but
>> > I am not sure.
>> >
>> > In any case, I think the core model must not be mutable. If the core
>> > model is mutable, this means pom.xml is not the ultimate source of truth
>> > about the project. It will not be possible to look at the pom and tell
>> > anything conclusively about the project if we allow plugins make random
>> > changes to the model. Tools like m2e will not be able to display project
>> > dependency hierarchy with any certainty, nor, in fact, be able to
>> > implement workspace dependency resolution.
>> >
>> > As for the shade plugin, assuming I understand the usecase correctly,
>> > dependency reduced pom is semantically equal to pom with all "reduced"
>> > dependencies marked as optional=true. It may be okay for the shade
>> > plugin to require users explicitly add optional=true to relevant
>> > dependencies and fail the build if this is not the case. Maybe provide a
>> > way to automatically change source pom.xml on filesystem before failing
>> > the build too.
>>
>> I've tried to do this by hand. It yields a variety of downstream
>> problems. For example, OSGi tools take optional dependences as
>> optional OSGi dependences, not as removed dependencies.
>>
>> So I think we need another approach to this dilemma; shade, if nothing
>> else, is a critical enabling technology, and having the downstream
>> builds in the reactor work with the output is essential.
>>
>>
>> >
>> > --
>> > Regards,
>> > Igor
>> >
>> > On Tue, Oct 27, 2015, at 09:35 AM, Jason van Zyl wrote:
>> >> The core model has to be mutable. I think there can be an ancillary model
>> >> that carried other types of information like the dependency reduction.
>> >> But mutation and re-consumption within the reactor I think is a bad idea
>> >> and the complication enumerated below seems fairly extreme. Do you have a
>> >> concrete use case in mind?
>> >>
>> >> > On Oct 27, 2015, at 2:41 AM, Stephen Connolly 
>> >> > <stephen.alan.conno...@gmail.com> wrote:
>> >> >
>> >> > Context: MNG-5899 [1] which was originally reported as MSHADE-206 [2]
>> >> >
>> >> > I understand why the change[3] was made... but this change breaks
>> >> > about 80-90% of the use cases for the shade plugin...
>> >> >
>> >> > Is there any way we can consider a compromise?
>> >> >
>> >> > I think it should be permitted for a plugin to replace the project
>> >> > model with a dependency reduced model, i.e. one where the transitive
>> >> > dependency tree is either the same or a strict subset of the
>> >> > transitive dependency tree of the original.
>> >> >
>> >> > If a plugin makes such a substitution then the reactor build order
>> >> > will remain unaffected but the classpaths of downstream modules would
>> >> > be affected.
>> >> >
>> >> > As I see it, if we were to try and permit such substitutions, we would
>> >> > need to augment the mojo API:
>> >> >
>> >> > * A Mojo would need to advertise that it performs Project Dependency
>> >> > Reduction, because...

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.2 (Take 2)

[Benson Margulies]

+1

On Tue, Oct 27, 2015 at 4:20 PM, Karl Heinz Marbaise  wrote:
> Hi,
>
> i need one more binding VOTE...
>
> Kind regards
> Karl Heinz Marbaise
>
> On 10/24/15 12:48 PM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> We solved 7 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12333008
>>
>>
>> There are still a couple of issues left in JIRA:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>>
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1226
>>
>> https://repository.apache.org/content/repositories/maven-1225/org/apache/maven/plugins/maven-shade-plugin/2.4.2/maven-shade-plugin-2.4.2-source-release.zip
>>
>>
>> Source release checksum(s):
>> maven-shade-plugin-2.4.2-source-release.zip sha1:
>> 8bcc97553cbac68142ee7bf8c7ce2fb9af678a42
>>
>> Staging site:
>> http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
>>
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>
>
> -
> To unsubscribe, e-mail: dev-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: MNG-5899 Project models are no longer mutable in reactor

[Benson Margulies]

On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko  wrote:
> Did you really mean "the core model has to be mutable"? The rest of your
> message appears to suggest you do not want the model to be mutable, but
> I am not sure.
>
> In any case, I think the core model must not be mutable. If the core
> model is mutable, this means pom.xml is not the ultimate source of truth
> about the project. It will not be possible to look at the pom and tell
> anything conclusively about the project if we allow plugins make random
> changes to the model. Tools like m2e will not be able to display project
> dependency hierarchy with any certainty, nor, in fact, be able to
> implement workspace dependency resolution.
>
> As for the shade plugin, assuming I understand the usecase correctly,
> dependency reduced pom is semantically equal to pom with all "reduced"
> dependencies marked as optional=true. It may be okay for the shade
> plugin to require users explicitly add optional=true to relevant
> dependencies and fail the build if this is not the case. Maybe provide a
> way to automatically change source pom.xml on filesystem before failing
> the build too.

I've tried to do this by hand. It yields a variety of downstream
problems. For example, OSGi tools take optional dependences as
optional OSGi dependences, not as removed dependencies.

So I think we need another approach to this dilemma; shade, if nothing
else, is a critical enabling technology, and having the downstream
builds in the reactor work with the output is essential.


>
> --
> Regards,
> Igor
>
> On Tue, Oct 27, 2015, at 09:35 AM, Jason van Zyl wrote:
>> The core model has to be mutable. I think there can be an ancillary model
>> that carried other types of information like the dependency reduction.
>> But mutation and re-consumption within the reactor I think is a bad idea
>> and the complication enumerated below seems fairly extreme. Do you have a
>> concrete use case in mind?
>>
>> > On Oct 27, 2015, at 2:41 AM, Stephen Connolly 
>> >  wrote:
>> >
>> > Context: MNG-5899 [1] which was originally reported as MSHADE-206 [2]
>> >
>> > I understand why the change[3] was made... but this change breaks
>> > about 80-90% of the use cases for the shade plugin...
>> >
>> > Is there any way we can consider a compromise?
>> >
>> > I think it should be permitted for a plugin to replace the project
>> > model with a dependency reduced model, i.e. one where the transitive
>> > dependency tree is either the same or a strict subset of the
>> > transitive dependency tree of the original.
>> >
>> > If a plugin makes such a substitution then the reactor build order
>> > will remain unaffected but the classpaths of downstream modules would
>> > be affected.
>> >
>> > As I see it, if we were to try and permit such substitutions, we would
>> > need to augment the mojo API:
>> >
>> > * A Mojo would need to advertise that it performs Project Dependency
>> > Reduction, because...
>> >
>> > * The build plan would need to delay concurrent builds of modules that
>> > depend on the project using such a mojo until after the mojo has
>> > completed execution
>> >
>> > * The replacement of the project model would have to be via a specific
>> > API call such that validation of the transitive dependency tree rule
>> > was maintained as well as restricting usage of that API to mojos that
>> > have advertised their use of dependency reduction.
>> >
>> > Is there anything else that we would need to consider if we were
>> > implementing the above?
>> >
>> > (Shade would not be the only consumer of this API as I see it, for
>> > example the flatten maven plugin may well want to consume this API
>> > also...)
>> >
>> > WDYT?
>> >
>> > [1]: https://issues.apache.org/jira/browse/MNG-5899
>> > [2]: https://issues.apache.org/jira/browse/MSHADE-206
>> > [3]: 
>> > https://github.com/apache/maven/commit/be3fb200326208ca4b8c41ebf16d5ae6b8049792
>> >
>> > -
>> > 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, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>>
>> 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
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Reproducibility versus ranges

[Benson Margulies]

Folks,

I would appreciate some assistance in thinking through the
implications of the use of version ranges.

As a thought experiment, consider a loosely-coupled collection of
maven project, maintained with a semver discipline.

Each component has dependencies, and those are written with ordinary
dependency elements. No dependency management, no ranges.

Maven will resolve version numbers, and the builds will be 100%
reproducible. However, the resolution algorithm is not semver, it's
doing the tree distance thing.

So, to get semver semantics, I might consider adding ranges. However,
and here I hope I'm confused, I just lost reproducibility. If someone
adds a new version to the repository, a re-run of the build will
select it if it satisfies the ranges. Rebuilding from the tag is not
the same build.

Am I missing something? Could it be that the release process somehow
resolves the ranges and writes them into the poms?

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

Re: Reproducibility versus ranges

[Benson Margulies]

On Mon, Oct 26, 2015 at 11:42 AM, Anders Hammar
<anders.g.ham...@gmail.com> wrote:
> You're right, this is the problem. What would need to be done is the
> version to be fixed for the release version (tag).

Do we have any tooling for this? In my imagination, the top pom for a
product to be released could be auto-decorated with
dependencyManagement locks.

>
> /Anders (mobile)
> Den 26 okt 2015 15:55 skrev "Benson Margulies" <bimargul...@gmail.com>:
>
>> Folks,
>>
>> I would appreciate some assistance in thinking through the
>> implications of the use of version ranges.
>>
>> As a thought experiment, consider a loosely-coupled collection of
>> maven project, maintained with a semver discipline.
>>
>> Each component has dependencies, and those are written with ordinary
>> dependency elements. No dependency management, no ranges.
>>
>> Maven will resolve version numbers, and the builds will be 100%
>> reproducible. However, the resolution algorithm is not semver, it's
>> doing the tree distance thing.
>>
>> So, to get semver semantics, I might consider adding ranges. However,
>> and here I hope I'm confused, I just lost reproducibility. If someone
>> adds a new version to the repository, a re-run of the build will
>> select it if it satisfies the ranges. Rebuilding from the tag is not
>> the same build.
>>
>> Am I missing something? Could it be that the release process somehow
>> resolves the ranges and writes them into the poms?
>>
>> -
>> 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: [RESULT] [VOTE] Release Maven Checkstyle Plugin version 2.17

[Benson Margulies]

I'm on the case for the checkins. Or ducks.


On Sun, Oct 18, 2015 at 3:45 PM, Michael Osipov <micha...@apache.org> wrote:
> Hi,
>
> The vote has passed with the following result:
>
> +1 (binding): Karl Heinz Marbaise, Benson Margulies, Daniel Kulp, Hervé
> Boutemy
>
>
> I will promote the artifacts to the central repo.
>
> PMC members, please promote the source release ZIP file and add this release
> the board report.
>
>
> -
> 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 plugin for code signing @Apache

[Benson Margulies]

Eclipse checks that sort of signature on jar files, as I recall.

On Sun, Oct 18, 2015 at 2:14 AM, Hervé BOUTEMY  wrote:
> Hi,
>
> Perhaps the "code signing" feature for jars should be explained, since we
> already have maven-gpg-plugin [1] to sign code, that is used for years with
> great success.
>
> From what I read on ASF signing, it adds a feature for Windows executables,
> that is checked by the OS at runtime and displayed to end-users.
>
> For jars, I don't see what we get better than gpg.
> What I suppose is that if a plugin is done, it will be an Apache-specific
> plugin: not same interest than doing a plugin for general public use.
>
> What do you expect from this signing feature for jars?
>
> Regards,
>
> Hervé
>
> [1] http://maven.apache.org/plugins/maven-gpg-plugin/
>
> Le jeudi 8 octobre 2015 12:26:57 Maxim Solodovnik a écrit :
>> Hello All,
>>
>> More than a year ago INFRA announce availability of code signing at Apache:
>> https://blogs.apache.org/infra/entry/code_signing_service_now_available
>>
>> but still there is no maven plugin for doing that :(
>> I never wrote maven plugins and need more time to write "Hello world" level
>> plugins before I can fix/create anything :)
>>
>> Maybe anyone is interested to write maven plugin so code can be signed at
>> Apache? :)
>>
>> Thanks in advance!
>
>
> -
> 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: Problem testing the checkstyle release

[Benson Margulies]

I never suggested that it should hinder the release. I was able to
test it myself, it's my co-worker who couldn't join in. You do have a
+1 from me, I look forward to the announcement.

On Sun, Oct 18, 2015 at 8:18 AM, Michael Osipov <micha...@apache.org> wrote:
> Am 2015-10-16 um 15:01 schrieb Benson Margulies:
>>
>> Maven-plugins 28 is released, of course; what's up? It worked for me,
>> but not for one of my co-workers.
>
>
> Benson,
>
> where you actually able to resolve your problem? From my point of view this
> should not hinder the plugin release.
>
> Michael
>
>
>
> -
> 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: [RESULT] [VOTE] Release Apache Maven Release version 2.5.3

[Benson Margulies]

This vote passes:

+1 binding: bimargulies, khmarbais, herve.boutemy, rfscholte
+1: tibordigana

On Sat, Oct 17, 2015 at 3:45 PM, Robert Scholte <rfscho...@apache.org> wrote:
> +1
>
> Op Wed, 14 Oct 2015 14:05:18 +0200 schreef Benson Margulies
> <bimargul...@gmail.com>:
>
>> Hi,
>>
>> We solved 2 issues:
>>
>> Release Notes - Maven Release Plugin - Version 2.5.3
>>
>> ** Bug
>> * [MRELEASE-921] - perform goal doesn't support providerImplementation
>> * [MRELEASE-925] - Old version of plexus utils forced here causes
>> failures
>>
>>
>> There are still a couple of issues left in JIRA:
>>
>>
>> https://issues.apache.org/jira/browse/MRELEASE-726?jql=project%20%3D%20MRELEASE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1219
>>
>>
>> https://repository.apache.org/service/local/repositories/maven-1219/content/org/apache/maven/release/maven-release/2.5.3/maven-release-2.5.3-source-release.zip
>>
>> Source release checksum(s):
>> [NAME-OF]-source-release.zip sha1:
>> 2e8f11f48b4a4196c9ea06b8569f55ae68805506]
>>
>> Staging site:
>> http://maven.apache.org/maven-release-archives/maven-release-LATEST/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> My +1.
>>
>> -
>> 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

[ANN] Apache Maven Release Plugin 2.5.3 Released

[Benson Margulies]

The Apache Maven team is pleased to announce the release of the Apache
Maven Release Component, version 2.5.3

This component automates tagging and preparing releases, and includes
the maven-release-plugin.

http://maven.apache.org/maven-release/

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-release-plugin
2.5.3


You can download the appropriate sources etc. from the download page:

http://maven.apache.org/components/maven-release/download.cgi

Release Notes - Maven Release - 2.5.3

** Bug
* [MRELEASE-921] - perform goal doesn't support providerImplementation
* [MRELEASE-925] - Old version of plexus utils forced here causes failures

Enjoy,

-The Apache Maven team

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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

[Benson Margulies]

You have a +1 from me. if there's any issue here, which I doubt, it's
not worth a -1.

On Sat, Oct 17, 2015 at 1:00 PM, Tibor Digana <tibordig...@apache.org> wrote:
> The doc of "*trimStackTrace*" says
> "Whether to trim the stack trace in the reports to just the lines within
> the test, or show the full trace."
> My bad in previous email.
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#trimStackTrace
>
>
> On Sat, Oct 17, 2015 at 6:56 PM, Tibor Digana-2 [via Maven] <
> ml-node+s40175n5849436...@n5.nabble.com> wrote:
>
>> No, we did not short the stack.
>> We now properly implemented "*trimStackTrace*", where it works as expected
>> in std/out and XML report as well
>> "Option to print summary of test suites or just print the test cases that
>> have errors."
>>
>> Please try to set it to false and let me know.
>>
>> I won't be able to check you conversation till the late evening tomorrow
>> when the Vote will be gone.
>>
>> The Vote will elapse on Sunday 5 a.m. After that we have to options:
>> 1. make the regular release, or
>> 2. start Take 3 if we want me to fix something.
>>
>> Honestly making the release Vote of surefire is more painful than
>> maven-shared-* staff.
>>
>> Enjoy the Vote ☺
>>
>>
>> On Fri, Oct 16, 2015 at 7:25 PM, Benson Margulies <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5849436=0>>
>> wrote:
>>
>> > On Fri, Oct 16, 2015 at 1:23 PM, Andreas Gudian
>> > <[hidden email] <http:///user/SendEmail.jtp?type=node=5849436=1>>
>> wrote:
>> > > Benson, is there a full stack trace in the XML test report? I would
>> have
>> > > expected that we shorten out most of the stack traces on the console
>> > > output...
>> >
>> > No. That's why I complained.
>> >
>> >
>> > >
>> > > 2015-10-16 16:35 GMT+02:00 Benson Margulies <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5849436=2>>:
>> > >
>> > >> On Fri, Oct 16, 2015 at 10:31 AM, Tibor Digana <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5849436=3>>
>> > >> wrote:
>> > >> > Can you give me the link?
>> > >>
>> > >>
>> > >>
>> >
>> https://github.com/ops4j/org.ops4j.pax.exam2/commit/c466e58cae6c2275a38bc2712cc76a70f768d769
>> > >>
>> > >>
>> > >> >
>> > >> > On Fri, Oct 16, 2015 at 4:27 PM, Benson Margulies [via Maven] <
>> > >> > [hidden email]
>> <http:///user/SendEmail.jtp?type=node=5849436=4>> wrote:
>> > >> >
>> > >> >> I've committed the fix to the master for pax-exam.
>> > >> >>
>> > >> >>
>> > >> >> On Fri, Oct 16, 2015 at 10:19 AM, Benson Margulies
>> > >> >> <[hidden email] <http://
>> > >> /user/SendEmail.jtp?type=node=5849346=0>>
>> > >> >> wrote:
>> > >> >>
>> > >> >> > On Fri, Oct 16, 2015 at 9:56 AM, Tibor Digana
>> > >> >> > <[hidden email] <http://
>> > >> /user/SendEmail.jtp?type=node=5849346=1>>
>> > >> >> wrote:
>> > >> >> >> try to debug this stack part of ProbeRunner.
>> > >> >> >> What version of pax-exam-spi you use?
>> > >> >> >
>> > >> >> > 4.6.0. I am testing the fix to pax-exam now.
>> > >> >> >
>> > >> >> >>
>> > >> >> >>  at org.ops4j.pax.exam.spi.
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
>> > >> >> >>  at
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
>>
>> > >> >>
>> > >> >> >>  - locked <0x411> (a
>> > org.ops4j.pax.exam.spi.reactors.ReactorManager)
>> > >> >> >>  at
>> > >> >>
>> org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRu

Re: VOTE] Release Apache Maven Shared Archiver 3.0.0

[Benson Margulies]

+1 binding. Checked sum, tested the other day by running plugins using it.

On Sat, Oct 17, 2015 at 10:18 AM, Karl Heinz Marbaise  wrote:
> Hi,
>
> here we need two more binding VOTE's..
>
> Kind regards
> Karl Heinz Marbaise
> On 10/16/15 11:54 AM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> here is my +1..
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 10/14/15 8:51 PM, Karl Heinz Marbaise wrote:
>>>
>>> Hi,
>>>
>>> Note: This is a Maven 3.0 / JDK 6 release
>>>
>>> We solved 6 issues:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12333673
>>>
>>>
>>>
>>> There are several issue open:
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>>>
>>>
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-1220/
>>>
>>> https://repository.apache.org/content/repositories/maven-1220/org/apache/maven/maven-archiver/3.0.0/maven-archiver-3.0.0-source-release.zip
>>>
>>>
>>>
>>> Source release checksum(s):
>>> maven-archiver-3.0.0-source-release.zip sha1:
>>> 2c03268faa0c72eb24b1f2657ce96e26aaa2f6f1
>>>
>>> Staging site:
>>> http://maven.apache.org/shared-archives/maven-archiver-LATEST/
>>>
>>>
>>> Guide to testing staged releases:
>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>
>>> Vote open for 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>
>>
>
> -
> To unsubscribe, e-mail: dev-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 Surefire Plugin version 2.19 (Take 2)

[Benson Margulies]

On Fri, Oct 16, 2015 at 1:23 PM, Andreas Gudian
<andreas.gud...@gmail.com> wrote:
> Benson, is there a full stack trace in the XML test report? I would have
> expected that we shorten out most of the stack traces on the console
> output...

No. That's why I complained.


>
> 2015-10-16 16:35 GMT+02:00 Benson Margulies <bimargul...@gmail.com>:
>
>> On Fri, Oct 16, 2015 at 10:31 AM, Tibor Digana <tibordig...@apache.org>
>> wrote:
>> > Can you give me the link?
>>
>>
>> https://github.com/ops4j/org.ops4j.pax.exam2/commit/c466e58cae6c2275a38bc2712cc76a70f768d769
>>
>>
>> >
>> > On Fri, Oct 16, 2015 at 4:27 PM, Benson Margulies [via Maven] <
>> > ml-node+s40175n5849346...@n5.nabble.com> wrote:
>> >
>> >> I've committed the fix to the master for pax-exam.
>> >>
>> >>
>> >> On Fri, Oct 16, 2015 at 10:19 AM, Benson Margulies
>> >> <[hidden email] <http://
>> /user/SendEmail.jtp?type=node=5849346=0>>
>> >> wrote:
>> >>
>> >> > On Fri, Oct 16, 2015 at 9:56 AM, Tibor Digana
>> >> > <[hidden email] <http://
>> /user/SendEmail.jtp?type=node=5849346=1>>
>> >> wrote:
>> >> >> try to debug this stack part of ProbeRunner.
>> >> >> What version of pax-exam-spi you use?
>> >> >
>> >> > 4.6.0. I am testing the fix to pax-exam now.
>> >> >
>> >> >>
>> >> >>  at org.ops4j.pax.exam.spi.
>> >> >>
>> >>
>> reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
>> >> >>  at
>> >> >>
>> >>
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
>> >>
>> >> >>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
>> >> >>  at
>> >> org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
>> >> >>
>> >> >>
>> >> >> On Fri, Oct 16, 2015 at 3:46 PM, Benson Margulies <[hidden email]
>> >> <http:///user/SendEmail.jtp?type=node=5849346=2>>
>> >> >> wrote:
>> >> >>
>> >> >>> Step 1: here's the backtrace of the InvocationTargetException. It's
>> >> >>> caused by an IllegalArgumentException, which I will break on next.
>> >> >>>
>> >> >>> That is in turn, as you supposed, caused by the use of the file:
>> >> >>>
>> >> >>>
>> >> >>>
>> >>
>> jar:file:/Users/benson/x/rosapi1.5/itests/tests/target/rosapi-itests-tests.jar!/META-INF/maven/dependencies.properties
>> >>
>> >> >>>
>> >> >>> being non-hierarchical.
>> >> >>>
>> >> >>> So, the underlying issue is a bug in pax-exam. However, I still
>> wonder
>> >> >>> what you think about the fact that failsafe did not provide any
>> >> >>> backtrace.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> "main@1" prio=5 tid=0x1 nid=NA runnable
>> >> >>>   java.lang.Thread.State: RUNNABLE
>> >> >>>  at
>> >> >>>
>> >>
>> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>> >>
>> >> >>>  at
>> >> >>>
>> >>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> >>
>> >> >>>  at
>> >> >>>
>> >>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >>
>> >> >>>  at java.lang.reflect.Method.invoke(Method.java:497)
>> >> >>>  at
>> >> >>>
>> >>
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
>> >>
>> >> >>>  at
>> >> >>>
>> >>
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
>> >>
>> >> >>>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
>> >> >>>  at
>> >> org.ops4j.pax.exam

Problem testing the checkstyle release

[Benson Margulies]

Maven-plugins 28 is released, of course; what's up? It worked for me,
but not for one of my co-workers.

$ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Parent for Text Analytics Maven Projects 57.2.4-SNAPSHOT
[INFO] 
Downloading: 
https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-checkstyle-plugin/2.17/maven-checkstyle-plugin-2.17.pom
Downloaded: 
https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-checkstyle-plugin/2.17/maven-checkstyle-plugin-2.17.pom
(14 KB at 7.7 KB/sec)
Downloading: 
https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28.pom
Downloading: 
http://repository.apache.org/snapshots/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28.pom
Downloading: 
http://nexus.basistech.net:8081/nexus/content/groups/public/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28.pom
[INFO] 
[INFO] BUILD FAILURE

[ERROR] Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.17
or one of its dependencies could not be resolved: Failed to read
artifact descriptor for
org.apache.maven.plugins:maven-checkstyle-plugin:jar:2.17: Could not
find artifact org.apache.maven.plugins:maven-plugins:pom:28 in
checkstyle-stage
(https://repository.apache.org/content/repositories/maven-1223/) ->
[Help 1]

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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

[Benson Margulies]

On Fri, Oct 16, 2015 at 8:20 AM, Tibor Digana  wrote:
> https://repository.apache.org/content/repositories/maven-1222

Tested on my current major project. No issues. +1 binding.

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

Re: [VOTE] Release Maven Checkstyle Plugin version 2.17

[Benson Margulies]

On Fri, Oct 16, 2015 at 5:53 AM, Karl Heinz Marbaise  wrote:
> http://maven.apache.org/guides/development/guide-testing-releases.html



+1

Ran it on one of my projects, where it promptly exploded due to
checkstyle incompatibilities. So I know it worked.

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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

[Benson Margulies]

Step 1: here's the backtrace of the InvocationTargetException. It's
caused by an IllegalArgumentException, which I will break on next.

That is in turn, as you supposed, caused by the use of the file:

jar:file:/Users/benson/x/rosapi1.5/itests/tests/target/rosapi-itests-tests.jar!/META-INF/maven/dependencies.properties

being non-hierarchical.

So, the underlying issue is a bug in pax-exam. However, I still wonder
what you think about the fact that failsafe did not provide any
backtrace.



"main@1" prio=5 tid=0x1 nid=NA runnable
  java.lang.Thread.State: RUNNABLE
 at 
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:497)
 at 
org.ops4j.pax.exam.spi.reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
 at 
org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
 - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
 at org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
 at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
 at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
 at 
sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
 at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
 at 
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
 at 
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
 at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
 at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
 at org.junit.runner.Computer.getRunner(Computer.java:40)
 at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
 at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
 at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
 at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
 at org.junit.runners.Suite.(Suite.java:81)
 at org.junit.runner.Computer.getSuite(Computer.java:28)
 at org.junit.runner.Request.classes(Request.java:75)
 at org.junit.runner.Request.classes(Request.java:91)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:497)
 at 
org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
 at 
org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
 at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
 at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
 at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)

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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

[Benson Margulies]

Um, maybe I voted too soon. Using the new failsafe plugin, I get the
following, and no backtrace, on each of my integration test classes.
Any suggestions, Tibor?


---
Test set: com.basistech.ws.itest.FrontEndIT
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.008
sec <<< FAILURE! - in com.basistech.ws.itest.FrontEndIT
initializationError(com.basistech.ws.itest.FrontEndIT)  Time elapsed:
0.004 sec  <<< ERROR!
org.ops4j.pax.exam.TestContainerException:
java.lang.reflect.InvocationTargetException
at 
com.basistech.ws.itest.FrontEndIT.paxConfiguration(FrontEndIT.java:44)

Effective pom:

 
maven-failsafe-plugin
2.19

  
integration-tests

  integration-test
  verify


  
true

/Users/benson/x/rosapi1.5/itests/tests/target
1.5.0-SNAPSHOT
/Users/benson/x/rosapi1.5/itests/tests
4.0.2
false
  
  

org.apache.karaf:org.apache.karaf.client

org.jboss.logging:jboss-logging

org.ops4j.pax.logging:pax-logging-service

org.ops4j.pax.logging:pax-logging-api
  

  


  
true
  
  

org.apache.karaf:org.apache.karaf.client

org.jboss.logging:jboss-logging

org.ops4j.pax.logging:pax-logging-service

org.ops4j.pax.logging:pax-logging-api
  

   wrote:
> On Fri, Oct 16, 2015 at 8:20 AM, Tibor Digana  wrote:
>> https://repository.apache.org/content/repositories/maven-1222
>
> Tested on my current major project. No issues. +1 binding.

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

Re: Problem testing the checkstyle release

[Benson Margulies]

Anders, I added a pluginRepository for the stage to my settings.xml.
As far as I know,  adds, it
doesn't replace.

So why isn't it searching for the parent in the usual way in the other
repositories? Or do I have to manually put central in as a
pluginRepository if I'm just trying to add one?


On Fri, Oct 16, 2015 at 9:19 AM, Anders Hammar <and...@hammar.net> wrote:
> It looks like a specific staging repo is accessed (look at the URL in the
> end). As the parent has been released it is no longer available there.
>
> /Anders (mobile)
> Den 16 okt 2015 15:01 skrev "Benson Margulies" <bimargul...@gmail.com>:
>
>> Maven-plugins 28 is released, of course; what's up? It worked for me,
>> but not for one of my co-workers.
>>
>> $ mvn clean install
>> [INFO] Scanning for projects...
>> [INFO]
>> [INFO]
>> 
>> [INFO] Building Parent for Text Analytics Maven Projects 57.2.4-SNAPSHOT
>> [INFO]
>> 
>> Downloading:
>> https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-checkstyle-plugin/2.17/maven-checkstyle-plugin-2.17.pom
>> Downloaded:
>> https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-checkstyle-plugin/2.17/maven-checkstyle-plugin-2.17.pom
>> (14 KB at 7.7 KB/sec)
>> Downloading:
>> https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28.pom
>> Downloading:
>> http://repository.apache.org/snapshots/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28.pom
>> Downloading:
>> http://nexus.basistech.net:8081/nexus/content/groups/public/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28.pom
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>>
>> [ERROR] Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.17
>> or one of its dependencies could not be resolved: Failed to read
>> artifact descriptor for
>> org.apache.maven.plugins:maven-checkstyle-plugin:jar:2.17: Could not
>> find artifact org.apache.maven.plugins:maven-plugins:pom:28 in
>> checkstyle-stage
>> (https://repository.apache.org/content/repositories/maven-1223/) ->
>> [Help 1]
>>
>> -
>> 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 Surefire Plugin version 2.19 (Take 2)

[Benson Margulies]

On Fri, Oct 16, 2015 at 9:34 AM, Tibor Digana
<tibor.dig...@googlemail.com> wrote:
> No idea what com.basistech.ws.itest.
> FrontEndIT.paxConfiguration(FrontEndIT.java:44)
> is doing, obviously some Java Reflection calls.

No, it is not. Unless it's buried in pax-exam.

And if it were, don't you 'owe' me a full backtrace? I will see if I
can get one in IntelliJ ... that might be suggestive about what's
going on.

@Configuration
public static Option[] paxConfiguration() {
return new Option[]{
composite(Utils.baseConfiguration(frontEndPort, null)),
// this is here in case we decide to set up a mock worker.
replaceConfigurationFile("etc/anvils/transport-rules.tsv",
new File("src/config/front-end-transport-rules.tsv")),
Utils.distributionOption("rosapi-assembly-front-end")
};
}


Well, pax-exam is complex, and I can't rule out anything in it.




>
> But don't expect that everything goes well because you maybe relied on one
> of the bugs reported in Surefire.
> Since now the failsafe plugin takes jar (built src/main/java) instead of
> target/classes/.
> If you rely on target/classes/, use surefire-plugin because that's what the
> unit tests do.
>
>
> On Fri, Oct 16, 2015 at 3:04 PM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> Um, maybe I voted too soon. Using the new failsafe plugin, I get the
>> following, and no backtrace, on each of my integration test classes.
>> Any suggestions, Tibor?
>>
>>
>>
>> ---
>> Test set: com.basistech.ws.itest.FrontEndIT
>>
>> ---
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.008
>> sec <<< FAILURE! - in com.basistech.ws.itest.FrontEndIT
>> initializationError(com.basistech.ws.itest.FrontEndIT)  Time elapsed:
>> 0.004 sec  <<< ERROR!
>> org.ops4j.pax.exam.TestContainerException:
>> java.lang.reflect.InvocationTargetException
>> at
>> com.basistech.ws.itest.FrontEndIT.paxConfiguration(FrontEndIT.java:44)
>>
>> Effective pom:
>>
>>  
>> maven-failsafe-plugin
>> 2.19
>> 
>>   
>> integration-tests
>> 
>>   integration-test
>>   verify
>> 
>> 
>>   
>> true
>>
>>
>> /Users/benson/x/rosapi1.5/itests/tests/target
>> 1.5.0-SNAPSHOT
>> /Users/benson/x/rosapi1.5/itests/tests
>> 4.0.2
>> false
>>   
>>   
>>
>>
>> org.apache.karaf:org.apache.karaf.client
>>
>>
>> org.jboss.logging:jboss-logging
>>
>>
>> org.ops4j.pax.logging:pax-logging-service
>>
>>
>> org.ops4j.pax.logging:pax-logging-api
>>   
>> 
>>   
>> 
>> 
>>   
>> true
>>   
>>   
>>
>> org.apache.karaf:org.apache.karaf.client
>>
>> org.jboss.logging:jboss-logging
>>
>> org.ops4j.pax.logging:pax-logging-service
>>
>> org.ops4j.pax.logging:pax-logging-api
>>   
>> 
>>   >
>>
>>
>> On Fri, Oct 16, 2015 at 8:55 AM, Benson Margulies <bimargul...@gmail.com>
>> wrote:
>> > On Fri, Oct 16, 2015 at 8:20 AM, Tibor Digana <tibordig...@apache.org>
>> wrote:
>> >> https://repository.apache.org/content/repositories/maven-1222
>> >
>> > Tested on my current major project. No issues. +1 binding.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
>
> --
> Cheers
> Tibor

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

Re: Problem testing the checkstyle release

[Benson Margulies]

On Fri, Oct 16, 2015 at 9:38 AM, Anders Hammar <and...@hammar.net> wrote:
> No, you don't. Maybe there is some cached metadata incorrect or the
> metadata at apache.
> Could you try adding the -U switch?
>
> Also, I only have the staging repo in my settings as a profile and I only
> activate it explicitly when testing staged stuff.

Me too. That's what my co-worker was trying to do.

>
> /Anders (mobile)
> Den 16 okt 2015 15:35 skrev "Benson Margulies" <bimargul...@gmail.com>:
>
>> Anders, I added a pluginRepository for the stage to my settings.xml.
>> As far as I know,  adds, it
>> doesn't replace.
>>
>> So why isn't it searching for the parent in the usual way in the other
>> repositories? Or do I have to manually put central in as a
>> pluginRepository if I'm just trying to add one?
>>
>>
>> On Fri, Oct 16, 2015 at 9:19 AM, Anders Hammar <and...@hammar.net> wrote:
>> > It looks like a specific staging repo is accessed (look at the URL in the
>> > end). As the parent has been released it is no longer available there.
>> >
>> > /Anders (mobile)
>> > Den 16 okt 2015 15:01 skrev "Benson Margulies" <bimargul...@gmail.com>:
>> >
>> >> Maven-plugins 28 is released, of course; what's up? It worked for me,
>> >> but not for one of my co-workers.
>> >>
>> >> $ mvn clean install
>> >> [INFO] Scanning for projects...
>> >> [INFO]
>> >> [INFO]
>> >> 
>> >> [INFO] Building Parent for Text Analytics Maven Projects 57.2.4-SNAPSHOT
>> >> [INFO]
>> >> 
>> >> Downloading:
>> >>
>> https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-checkstyle-plugin/2.17/maven-checkstyle-plugin-2.17.pom
>> >> Downloaded:
>> >>
>> https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-checkstyle-plugin/2.17/maven-checkstyle-plugin-2.17.pom
>> >> (14 KB at 7.7 KB/sec)
>> >> Downloading:
>> >>
>> https://repository.apache.org/content/repositories/maven-1223/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28.pom
>> >> Downloading:
>> >>
>> http://repository.apache.org/snapshots/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28.pom
>> >> Downloading:
>> >>
>> http://nexus.basistech.net:8081/nexus/content/groups/public/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28.pom
>> >> [INFO]
>> >> 
>> >> [INFO] BUILD FAILURE
>> >>
>> >> [ERROR] Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.17
>> >> or one of its dependencies could not be resolved: Failed to read
>> >> artifact descriptor for
>> >> org.apache.maven.plugins:maven-checkstyle-plugin:jar:2.17: Could not
>> >> find artifact org.apache.maven.plugins:maven-plugins:pom:28 in
>> >> checkstyle-stage
>> >> (https://repository.apache.org/content/repositories/maven-1223/) ->
>> >> [Help 1]
>> >>
>> >> -
>> >> 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 Surefire Plugin version 2.19 (Take 2)

[Benson Margulies]

On Fri, Oct 16, 2015 at 9:56 AM, Tibor Digana
<tibor.dig...@googlemail.com> wrote:
> try to debug this stack part of ProbeRunner.
> What version of pax-exam-spi you use?

4.6.0. I am testing the fix to pax-exam now.

>
>  at org.ops4j.pax.exam.spi.
> reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
>  at
> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
>  at org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
>
>
> On Fri, Oct 16, 2015 at 3:46 PM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> Step 1: here's the backtrace of the InvocationTargetException. It's
>> caused by an IllegalArgumentException, which I will break on next.
>>
>> That is in turn, as you supposed, caused by the use of the file:
>>
>>
>> jar:file:/Users/benson/x/rosapi1.5/itests/tests/target/rosapi-itests-tests.jar!/META-INF/maven/dependencies.properties
>>
>> being non-hierarchical.
>>
>> So, the underlying issue is a bug in pax-exam. However, I still wonder
>> what you think about the fact that failsafe did not provide any
>> backtrace.
>>
>>
>>
>> "main@1" prio=5 tid=0x1 nid=NA runnable
>>   java.lang.Thread.State: RUNNABLE
>>  at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>>  at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>  at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:497)
>>  at
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
>>  at
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
>>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
>>  at org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
>>  at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
>>  at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
>>  at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
>>  at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>  at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>>  at
>> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>>  at
>> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>>  at
>> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
>>  at
>> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
>>  at org.junit.runner.Computer.getRunner(Computer.java:40)
>>  at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
>>  at
>> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
>>  at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
>>  at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
>>  at org.junit.runners.Suite.(Suite.java:81)
>>  at org.junit.runner.Computer.getSuite(Computer.java:28)
>>  at org.junit.runner.Request.classes(Request.java:75)
>>  at org.junit.runner.Request.classes(Request.java:91)
>>  at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>>  at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>  at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:497)
>>  at
>> org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
>>  at
>> org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
>>  at
>> org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
>>  at
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
>>  at
>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
>>  at
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
>>  at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
>
> --
> Cheers
> Tibor

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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

[Benson Margulies]

I've committed the fix to the master for pax-exam.


On Fri, Oct 16, 2015 at 10:19 AM, Benson Margulies
<bimargul...@gmail.com> wrote:
> On Fri, Oct 16, 2015 at 9:56 AM, Tibor Digana
> <tibor.dig...@googlemail.com> wrote:
>> try to debug this stack part of ProbeRunner.
>> What version of pax-exam-spi you use?
>
> 4.6.0. I am testing the fix to pax-exam now.
>
>>
>>  at org.ops4j.pax.exam.spi.
>> reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
>>  at
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
>>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
>>  at org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
>>
>>
>> On Fri, Oct 16, 2015 at 3:46 PM, Benson Margulies <bimargul...@gmail.com>
>> wrote:
>>
>>> Step 1: here's the backtrace of the InvocationTargetException. It's
>>> caused by an IllegalArgumentException, which I will break on next.
>>>
>>> That is in turn, as you supposed, caused by the use of the file:
>>>
>>>
>>> jar:file:/Users/benson/x/rosapi1.5/itests/tests/target/rosapi-itests-tests.jar!/META-INF/maven/dependencies.properties
>>>
>>> being non-hierarchical.
>>>
>>> So, the underlying issue is a bug in pax-exam. However, I still wonder
>>> what you think about the fact that failsafe did not provide any
>>> backtrace.
>>>
>>>
>>>
>>> "main@1" prio=5 tid=0x1 nid=NA runnable
>>>   java.lang.Thread.State: RUNNABLE
>>>  at
>>> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>>>  at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>  at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>  at java.lang.reflect.Method.invoke(Method.java:497)
>>>  at
>>> org.ops4j.pax.exam.spi.reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
>>>  at
>>> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
>>>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
>>>  at org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
>>>  at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
>>>  at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
>>>  at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
>>>  at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>>  at
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>>>  at
>>> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>>>  at
>>> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>>>  at
>>> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
>>>  at
>>> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
>>>  at org.junit.runner.Computer.getRunner(Computer.java:40)
>>>  at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
>>>  at
>>> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
>>>  at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
>>>  at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
>>>  at org.junit.runners.Suite.(Suite.java:81)
>>>  at org.junit.runner.Computer.getSuite(Computer.java:28)
>>>  at org.junit.runner.Request.classes(Request.java:75)
>>>  at org.junit.runner.Request.classes(Request.java:91)
>>>  at
>>> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>>>  at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>  at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>  at java.lang.reflect.Method.invoke(Method.java:497)
>>>  at
>>> org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
>>>  at
>>> org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4Pr

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

[Benson Margulies]

On Fri, Oct 16, 2015 at 10:31 AM, Tibor Digana <tibordig...@apache.org> wrote:
> Can you give me the link?

https://github.com/ops4j/org.ops4j.pax.exam2/commit/c466e58cae6c2275a38bc2712cc76a70f768d769


>
> On Fri, Oct 16, 2015 at 4:27 PM, Benson Margulies [via Maven] <
> ml-node+s40175n5849346...@n5.nabble.com> wrote:
>
>> I've committed the fix to the master for pax-exam.
>>
>>
>> On Fri, Oct 16, 2015 at 10:19 AM, Benson Margulies
>> <[hidden email] <http:///user/SendEmail.jtp?type=node=5849346=0>>
>> wrote:
>>
>> > On Fri, Oct 16, 2015 at 9:56 AM, Tibor Digana
>> > <[hidden email] <http:///user/SendEmail.jtp?type=node=5849346=1>>
>> wrote:
>> >> try to debug this stack part of ProbeRunner.
>> >> What version of pax-exam-spi you use?
>> >
>> > 4.6.0. I am testing the fix to pax-exam now.
>> >
>> >>
>> >>  at org.ops4j.pax.exam.spi.
>> >>
>> reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
>> >>  at
>> >>
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
>>
>> >>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
>> >>  at
>> org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
>> >>
>> >>
>> >> On Fri, Oct 16, 2015 at 3:46 PM, Benson Margulies <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5849346=2>>
>> >> wrote:
>> >>
>> >>> Step 1: here's the backtrace of the InvocationTargetException. It's
>> >>> caused by an IllegalArgumentException, which I will break on next.
>> >>>
>> >>> That is in turn, as you supposed, caused by the use of the file:
>> >>>
>> >>>
>> >>>
>> jar:file:/Users/benson/x/rosapi1.5/itests/tests/target/rosapi-itests-tests.jar!/META-INF/maven/dependencies.properties
>>
>> >>>
>> >>> being non-hierarchical.
>> >>>
>> >>> So, the underlying issue is a bug in pax-exam. However, I still wonder
>> >>> what you think about the fact that failsafe did not provide any
>> >>> backtrace.
>> >>>
>> >>>
>> >>>
>> >>> "main@1" prio=5 tid=0x1 nid=NA runnable
>> >>>   java.lang.Thread.State: RUNNABLE
>> >>>  at
>> >>>
>> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>>
>> >>>  at
>> >>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>
>> >>>  at
>> >>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>> >>>  at java.lang.reflect.Method.invoke(Method.java:497)
>> >>>  at
>> >>>
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.addConfigurationsToReactor(ReactorManager.java:239)
>>
>> >>>  at
>> >>>
>> org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184)
>>
>> >>>  - locked <0x411> (a org.ops4j.pax.exam.spi.reactors.ReactorManager)
>> >>>  at
>> org.ops4j.pax.exam.junit.impl.ProbeRunner.(ProbeRunner.java:78)
>> >>>  at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82)
>> >>>  at org.ops4j.pax.exam.junit.PaxExam.(PaxExam.java:73)
>> >>>  at
>> >>>
>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
>>
>> >>>  at
>> >>>
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>
>> >>>  at
>> >>>
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>
>> >>>  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>> >>>  at
>> >>>
>> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
>>
>> >>>  at
>> >>>
>> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
>>
>> >>>  at
>> >>>
>> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
>>
>> >>>  at
>> >>>
>>

Releasable by default?

[Benson Margulies]

I'd like to open a discussion of a possible policy.

The policy would look something like the following:

___

All of the projects managed by the Maven PMC are maintained in a
releasable condition. If a developer wants to make a change that will
result in an a component being unreleasable for any significant period
of time, that developer is responsible for setting up a branch
structure that preserved the releasability of the component for the
duration. They might do their work on a sandbox branch, or they might
set up a maintenance branch for the current state of the code.
___


I see several advantages to this policy:

1: The work to fix a small problem or add a small feature is
proportionate.  You can't suddenly find yourself needing to release
four components and / or make a branch and do merges to get a fix out
to the users (including yourself).

2: If we ever have to deal with a security fix, we will find it much
less painful.

3: We recognize the reality that we're all volunteers, and that good
intentions don't always lead to timely activity.

It seems to me that this is in the general territory of 'CD' which is
pretty popular in the world at large.

What do people think?

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

[VOTE] Release Apache Maven Release version 2.5.3

[Benson Margulies]

Hi,

We solved 2 issues:

Release Notes - Maven Release Plugin - Version 2.5.3

** Bug
* [MRELEASE-921] - perform goal doesn't support providerImplementation
* [MRELEASE-925] - Old version of plexus utils forced here causes failures


There are still a couple of issues left in JIRA:

https://issues.apache.org/jira/browse/MRELEASE-726?jql=project%20%3D%20MRELEASE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

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

https://repository.apache.org/service/local/repositories/maven-1219/content/org/apache/maven/release/maven-release/2.5.3/maven-release-2.5.3-source-release.zip

Source release checksum(s):
[NAME-OF]-source-release.zip sha1: 2e8f11f48b4a4196c9ea06b8569f55ae68805506]

Staging site:
http://maven.apache.org/maven-release-archives/maven-release-LATEST/

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

Vote open for 72 hours.

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

My +1.

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

Re: Releasable by default?

[Benson Margulies]

On Wed, Oct 14, 2015 at 8:31 AM, Jason van Zyl <ja...@takari.io> wrote:
> I don’t think we need a policy for this, it’s just common sense not to break 
> master.
>
> If someone inadvertently makes master not work properly then provide a reason 
> and put that change on a branch. The developer who did it might not have time 
> at the point someone else finds the issue so anyone can correct the issue 
> with a reasonable explanation.


>
> All our projects should work on master. But I’m not going to try and force 
> someone to fix the issue by policy if they happen to make a mistake. Just fix 
> it and carry on.

'Always working' is not the same as 'always releasable'. From an
English language standpoint, collection of working, interdependent
snapshots is a 'working' state. Your use of the term 'break' is
important here; no one 'broke' anything AFAIK in the sense checking in
grossly broken code; rather, various people rendered various things
unreleasable due to snapshot dependencies, or due to code that is
working, but in their view not ready to release.

I don't think people are making mistakes. I think that they don't
honestly all or always  see 'always releasable' as a guiding
principle.

To be concrete: maven-release-plugin was left unreleasable due to a
snapshot dependency on SCM. SCM is perhaps unreleasable due to several
1/2-cooked JIRAs. A whole raft of plugins are unreleasable due to the
'Maven 3 baseline' project. Maybe this one isn't a fair Axiom Scheme
of examples, because I think there was a general consensus to do this
stuff on trunk -- but it is talking quite a long time.

If the term 'policy' disturbs you due to the implications of coercion,
 then let's not call it a policy. Let's call it a working principle.
I'm not trying to coerce anyone; the Apache veto/revert mechanism for
CTR is perfectly sufficient, as per your remark about 'fix it and move
on.' I perceive a presumption of 'leave it to the person who wants to
make a release to make a branch'. I'd like to move the presumption in
the other direction.



>
>> On Oct 14, 2015, at 8:14 AM, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> I'd like to open a discussion of a possible policy.
>>
>> The policy would look something like the following:
>>
>> ___
>>
>> All of the projects managed by the Maven PMC are maintained in a
>> releasable condition. If a developer wants to make a change that will
>> result in an a component being unreleasable for any significant period
>> of time, that developer is responsible for setting up a branch
>> structure that preserved the releasability of the component for the
>> duration. They might do their work on a sandbox branch, or they might
>> set up a maintenance branch for the current state of the code.
>> ___
>>
>>
>> I see several advantages to this policy:
>>
>> 1: The work to fix a small problem or add a small feature is
>> proportionate.  You can't suddenly find yourself needing to release
>> four components and / or make a branch and do merges to get a fix out
>> to the users (including yourself).
>>
>> 2: If we ever have to deal with a security fix, we will find it much
>> less painful.
>>
>> 3: We recognize the reality that we're all volunteers, and that good
>> intentions don't always lead to timely activity.
>>
>> It seems to me that this is in the general territory of 'CD' which is
>> pretty popular in the world at large.
>>
>> What do people think?
>>
>> -
>> 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, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> What matters is not ideas, but the people who have them. Good people can fix 
> bad ideas, but good ideas can't save bad people.
>
>  -- Paul Graham
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> 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: r1708587 - in /maven/release/trunk: ./ maven-release-manager/ maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ maven-release-manager/src/main/java/org/apache

[Benson Margulies]

On Wed, Oct 14, 2015 at 6:41 PM, Olivier Lamy  wrote:
> did you create a branch with this change?
> At least to help the guys who worked on that...

Since it was a single commit, I didn't think it necessary. I could
either reapply it to trunk or make a branch;  to some extent I'm
waiting to hear from them.

In fact, my first thought was to release SCM and then apply it with
the -SNAPSHOT removed, but SCM seems clogged by incomplete jiras.


>
> On 14 October 2015 at 22:52,  wrote:
>>
>> Author: bimargulies
>> Date: Wed Oct 14 11:52:53 2015
>> New Revision: 1708587
>>
>> URL: http://svn.apache.org/viewvc?rev=1708587=rev
>> Log:
>> SCM-775: revert the change, so that I can release this plugin.
>>
>> Modified:
>> maven/release/trunk/maven-release-manager/pom.xml
>>
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/PropertiesReleaseDescriptorStore.java
>>
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
>>
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractScmCommitPhase.java
>>
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ScmBranchPhase.java
>>
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java
>>
>> maven/release/trunk/maven-release-manager/src/main/mdo/release-descriptor.mdo
>>
>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/AbstractScmReleaseMojo.java
>> maven/release/trunk/pom.xml
>>
>> Modified: maven/release/trunk/maven-release-manager/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/pom.xml?rev=1708587=1708586=1708587=diff
>>
>> ==
>> --- maven/release/trunk/maven-release-manager/pom.xml (original)
>> +++ maven/release/trunk/maven-release-manager/pom.xml Wed Oct 14 11:52:53
>> 2015
>> @@ -235,7 +235,7 @@
>>
>>  
>>  
>> -  2.5.3
>> +  2.5.1
>>false
>>true
>>
>>
>> Modified:
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/PropertiesReleaseDescriptorStore.java
>> URL:
>> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/PropertiesReleaseDescriptorStore.java?rev=1708587=1708586=1708587=diff
>>
>> ==
>> ---
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/PropertiesReleaseDescriptorStore.java
>> (original)
>> +++
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/PropertiesReleaseDescriptorStore.java
>> Wed Oct 14 11:52:53 2015
>> @@ -238,11 +238,6 @@ public class PropertiesReleaseDescriptor
>>
>>  properties.setProperty( "pushChanges", Boolean.toString(
>> config.isPushChanges() ) );
>>
>> -if ( config.getWorkItem() != null )
>> -{
>> -properties.setProperty( "workItem", config.getWorkItem() );
>> -}
>> -
>>  // others boolean properties are not written to the properties
>> file because the value from the caller is always
>>  // used
>>
>>
>> Modified:
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
>> URL:
>> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java?rev=1708587=1708586=1708587=diff
>>
>> ==
>> ---
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
>> (original)
>> +++
>> maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
>> Wed Oct 14 11:52:53 2015
>> @@ -101,7 +101,6 @@ public class ReleaseUtils
>>  mergeInto.setRemoteTagging( toBeMerged.isRemoteTagging() );
>>  mergeInto.setLocalCheckout( toBeMerged.isLocalCheckout() );
>>  mergeInto.setPushChanges( toBeMerged.isPushChanges() );
>> -mergeInto.setWorkItem( toBeMerged.getWorkItem() );
>>  mergeInto.setWaitBeforeTagging( toBeMerged.getWaitBeforeTagging()
>> );
>>
>>  // If the user specifies versions, these should be override the
>> existing versions
>> @@ -174,7 +173,6 @@ public class ReleaseUtils
>>  remoteTaggingStr == null ? false : Boolean.valueOf(
>> remoteTaggingStr ).booleanValue() );
>>  String pushChanges = properties.getProperty( "pushChanges" );
>>  releaseDescriptor.setPushChanges( 

Re: [RESULT] [VOTE] Release Apache Maven maven-plugin parent-pom version 28

[Benson Margulies]

This vote passes:

+1 binding: me, Kristian Rosenvold, Hervé, Karl Hans, Olivier.
+1 other: Michael Osipov, Tibor Digana

I will proceed with the process.


On Sun, Oct 11, 2015 at 8:34 PM, Olivier Lamy <ol...@apache.org> wrote:
> +1
>
> On 12 October 2015 at 05:20, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
>
>> Hi,
>>
>> +1 ...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 10/11/15 2:56 AM, Benson Margulies wrote:
>>
>>> Hi,
>>>
>>> 2 changes in JIRA. Many other commits.
>>>
>>>
>>> ** Bug
>>>  * [MPOM-88] - yyy-LATEST deployment URL breaks site parent reference
>>> menu
>>>  * [MPOM-89] - Unbalanced versions of Maven Invoker Plugin
>>>
>>> There are no pending issues I can find in JIRA for this pom.
>>>
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-1217
>>>
>>> https://repository.apache.org/service/local/repositories/maven-1217/content/org/apache/maven/plugins/maven-plugins/28/maven-plugins-28-source-release.zip
>>>
>>> Source release checksum(s):  72ec7a3308eee4d9b60ab0b2aa5608ba48178537
>>>
>>> Staging site:
>>> http://maven.apache.org/pom-archives/maven-plugins-LATEST/
>>>
>>> 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.
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
>
> --
> Olivier Lamy
> 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

Release is in limbo waiting for SCM release; I veto a commit from May

[Benson Margulies]

I am now -1 on commit

1677765 chrisgwarp 1.9.5-SNAPSHOT

from maven-release. Back in May, this made source changes to require
an unreleased, incompatible, SCM version. Now I can't release release
to fix a critical problem. Further, since it involves this level of
API dependency, I think it requires the version fo

In my view, if you make change like this, you are responsible for
getting the dependency released in a timely fashion. if you can't you
should make a branch. The general 3.0 project is an exception in which
we all agreed to switch around.

My understanding of the commit veto policy for the ASF as a whole is
this: I've presented a _technical_ objection to the commit (it
prevents releases of the plugin), so the author should revert it. If
the author does not revert it, I will tomorrow. After all, it's still
there in svn and can be remerged onto a new branch.

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

[ANN] Apache Maven Plugins (parent POM) version 28 Released

[Benson Margulies]

The Apache Maven team is pleased to announce the release of the Apache
Maven Plugins parent POM, version 28.

This POM is the common parent of all of the plugins maintained by the
Apache Maven PMC, and, as such, is of limited use to developers
outside of the Maven project. See the svn history of
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-plugins/pom.xml
for information on the content of this release.

The primary change here is to move to version 27 of the overall Maven
parent POM.\

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

Re: Can anyone explain this missing plexus utils class?

[Benson Margulies]

I got a lecture on this from Stephen Connolly, who took some time out
from Marathon training to educate me. We're all wrong.

The only way to 'lock down' a version is to use a range: [foo). All
other versions are 'recommended'.

If there are no ranges, then the resolution algorithm decides what
version to take. It does _not_, contrary to my prior belief, take the
highest version. Instead, it has a tree-topology distance metric to
determine the 'closest' dependency. Also contrary to my understanding,
dependencyManagement does influence this process, it's not merely a
notational convenience.

So, release asks for 3.0.10, the use of dep-management asks a bit
harder, scm asks for 3.0.15, it loses because it is not nearest.

I thus conclude that the unpredictable appearance of this bug results
from a process wherein the m-r-p does not always ask SCM to do
something that uses the problem class from 3.0.15.

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

Re: Can anyone explain this missing plexus utils class?

[Benson Margulies]

OK, I retract my doc comment in part:

"In addition, the version and scope of artifacts which are
incorporated from transitive dependencies may also be controlled by
specifying them in a dependency management section." is hinting at
reality, but I think it could be made much stronger; the difference
between 'all 12 modules say version=N' and 'the parent has
depManagement that says N' needs to be cast into higher relief.


On Tue, Oct 13, 2015 at 10:14 AM, Benson Margulies
<bimargul...@gmail.com> wrote:
> I am perfectly willing to stand corrected; I started this email thread
> to get some insight. I may have misheard Stephen over the noise of the
> other runners.
>
> However, I will say that I don't like two aspects of this, and I
> wonder if they could be improved.
>
> The first is documentation.
>
> https://maven.apache.org/pom.html#Dependency_Management does not
> mention the locking semantics. It describes my ignorant understanding
> of the semantics: a notational convenience for DRY of 
> elements. Seems to me that it should have the real semantics, I'll
> take a look.
>
> The second is the ease of messing up.
>
> The maven-release project is set up as a ticking bomb under this
> regime. The project uses dependencyManagement to lock to a version; so
> if any dependency requires a newer version, the result is the
> explosion we have experienced. To me, this seems to call for a
> build-time warning: "You have locked plexus-utils to 3.0.10, but your
> dependency X calls for newer version 3.0.15'.
>
> Is that a thinkable behavior?

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

Re: Can anyone explain this missing plexus utils class?

[Benson Margulies]

On Tue, Oct 13, 2015 at 10:29 AM, Jason van Zyl  wrote:
>
>> The second is the ease of messing up.
>>
>> The maven-release project is set up as a ticking bomb under this
>> regime. The project uses dependencyManagement to lock to a version; so
>> if any dependency requires a newer version, the result is the
>> explosion we have experienced. To me, this seems to call for a
>> build-time warning: "You have locked plexus-utils to 3.0.10, but your
>> dependency X calls for newer version 3.0.15'.
>>
>> Is that a thinkable behavior?
>>
>
> Again, you have to know your product. The only holistic view of this is with 
> the M2Eclipse Dependency Hierarchy View. You can see what versions are 
> getting managed. You can see what it was and what it has been managed to. If 
> a change in one dependency indirectly changes another with an incompatibility 
> then you hoist it up and lock it down. So in this case you may actually want 
> to hoist plexus-utils up and lock it down to 3.0.10 if it makes everything 
> work.
>
> I am just accustomed to seeing the whole graph in M2Eclipse and excluding, 
> refactoring and locking things down while I’m running tests. I get everything 
> working and then don’t think about much until a required dependency change 
> causes something not to work and I track it down again in the Dependency 
> Hierarchy View, fix it and carry on. Trying to fix these issue without an 
> interactive tool like the Dependency Hierarchy View is going to take you 10x 
> longer. It’s really not productive.

In this case, someone did hoist it up and lock it down. Unfortunately,
someone else then upgraded SCM, and didn't think or know to consider
the possibility that upgrading SCM would result in plexus-utils being
managed down for it. Think about what you are asking people to do:
every time you change the dependency version for some dependency, you
must do a full analysis of the entire dependency tree. Absent
universal use of semantic versioning, I appreciate that this is
perhaps inevitable, but I bet that 90% of the commits in the maven
plugins that change a dependency version are not accompanied by this
analysis. (If the tests of the M-R-P had reached this case, we
wouldn't be in this situation.)

I won't go back to Eclipse due to the many awful things that went
wrong for me with it and Maven compared to IntelliJ, however useful
this particular tool might be. I'll be studying the output of mvn
dependency:tree and possibly adding more display to it as needed.



>
>> -
>> 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, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> To do two things at once is to do neither.
>
>  -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> 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: Can anyone explain this missing plexus utils class?

[Benson Margulies]

I am perfectly willing to stand corrected; I started this email thread
to get some insight. I may have misheard Stephen over the noise of the
other runners.

However, I will say that I don't like two aspects of this, and I
wonder if they could be improved.

The first is documentation.

https://maven.apache.org/pom.html#Dependency_Management does not
mention the locking semantics. It describes my ignorant understanding
of the semantics: a notational convenience for DRY of 
elements. Seems to me that it should have the real semantics, I'll
take a look.

The second is the ease of messing up.

The maven-release project is set up as a ticking bomb under this
regime. The project uses dependencyManagement to lock to a version; so
if any dependency requires a newer version, the result is the
explosion we have experienced. To me, this seems to call for a
build-time warning: "You have locked plexus-utils to 3.0.10, but your
dependency X calls for newer version 3.0.15'.

Is that a thinkable behavior?

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

Re: [VOTE] Release Apache Maven Shared Utils 3.0.0 (Take 2)

[Benson Margulies]

+1.

On Tue, Oct 13, 2015 at 4:08 PM, Karl Heinz Marbaise  wrote:
> Hi,
>
> I need two more binding VOTEs...
>
> Kind regards
> Karl Heinz Marbaise
> On 10/13/15 7:26 PM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> here is my +1.
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>> On 10/11/15 10:17 PM, Karl Heinz Marbaise wrote:
>>>
>>> Hi,
>>>
>>> Note: This is a Maven 3.0 / JDK 6 release
>>>
>>> We solved 5 issues:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12333677
>>>
>>>
>>>
>>> There are several issue open:
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>>>
>>>
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-1218
>>>
>>> https://repository.apache.org/content/repositories/maven-1218/org/apache/maven/shared/maven-shared-utils/3.0.0/maven-shared-utils-3.0.0-source-release.zip
>>>
>>>
>>>
>>> Source release checksum(s):
>>> maven-shared-uitls-3.0.0-source-release.zip sha1:
>>> 531e4484d149ca8aa498b8ce947254c815af08e5
>>>
>>> Staging site:
>>> http://maven.apache.org/shared-archives/maven-shared-utils-LATEST/
>>>
>>>
>>> Guide to testing staged releases:
>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>
>>> Vote open for 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>
>
> -
> To unsubscribe, e-mail: dev-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: Can anyone explain this missing plexus utils class?

[Benson Margulies]

On Sun, Oct 11, 2015 at 11:39 PM, Dan Tran <dant...@gmail.com> wrote:
> For the current case,  maven-release-plugin correctly pick up
> plexus-utils-3.0.10 since it is locked by maven-release's
> dependencyManagement. This is the correct behavior
>
> To fix this issue at project/consumer level, one must have pluginManagement
> to pick up the correct plexus-util (3.0.15)

Dan, pluginManangement != dependencyManagement.


>
>
> -Dan
>
> On Sun, Oct 11, 2015 at 5:22 PM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> On Oct 11, 2015 6:59 PM, "Dan Tran" <dant...@gmail.com> wrote:
>>
>> > Hi all, according to my understanding,  maven uses depManagement to lock
>> > down and version.
>> >
>> >
>>  just sets defaults for version, scope, optional, and
>> exclusions. It doesn't 'lock' any more than writing the same things in the
>> regular dependency element does.
>>
>> What do you expect to happen if two dependencies disagree on version?
>>
>>
>>
>> > If it not so, it is a very serious miss understanding for lots of users
>> >
>> > Can someone confirm?
>> >
>> > -Dan
>> >
>> > On Sun, Oct 11, 2015 at 1:07 PM, Benson Margulies <bimargul...@gmail.com
>> >
>> > wrote:
>> >
>> > > Tibor, I don't understand. Normally, the maven core 'rounds up' to the
>> > > highest dependency called for by all the things in the dependency
>> > > tree. Specifying a version does not 'lock it down'. If release depends
>> > > on 3.0.10, and also depends on SCM that depends on 3.0.15, I'd expect
>> > > 15 to be used. Is the problem here that SCM is injected without a
>> > > conventional dependency, or something?
>> > >
>> > > I'm also not following your preferred solution. What is your
>> > > alternative to the obvious edit to the maven-release
>> > > dependencyManagement area? plexus-utils is not managed in the
>> > > maven-plugins pom at all.
>> > >
>> > >
>> > > On Sun, Oct 11, 2015 at 3:22 PM, Dan Tran <dant...@gmail.com> wrote:
>> > > > Dont think it is maven core issue,   maven-release parent's
>> > > > dependencyManagment locks plexus-utils to 3.0.10.
>> > > >
>> > > > May as well fix up maven-release's dependencyManagement to cover all
>> > > other
>> > > > dependencies
>> > > >
>> > > > -D
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Sun, Oct 11, 2015 at 12:07 PM, Tibor Digana <
>> tibordig...@apache.org
>> > >
>> > > > wrote:
>> > > >
>> > > >> The problem is that plexus-utils:3.0.10 does not have
>> > > >> org/codehaus/plexus/util/xml/
>> > > >> pull/EntityReplacementMap
>> > > >> It starts since 3.0.13. Maybe 3.0.12 which is missing in my repo.
>> > > >>
>> > > >> On Sun, Oct 11, 2015 at 9:02 PM, Benson Margulies [via Maven] <
>> > > >> ml-node+s40175n5848412...@n5.nabble.com> wrote:
>> > > >>
>> > > >> > The fully-document JIRA is MRELEASE-925.
>> > > >> >
>> > > >> > On Sun, Oct 11, 2015 at 3:00 PM, Benson Margulies <[hidden email]
>> > > >> > <http:///user/SendEmail.jtp?type=node=5848412=0>> wrote:
>> > > >> >
>> > > >> > > This is presumably a core issue, won't someone comment who
>> delves
>> > > into
>> > > >> > > that part of the salt mine?
>> > > >> > >
>> > > >> > >
>> > > >> > > On Sun, Oct 11, 2015 at 2:57 PM, Dan Tran <[hidden email]
>> > > >> > <http:///user/SendEmail.jtp?type=node=5848412=1>> wrote:
>> > > >> > >> I encounter the same issue and filed at
>> > > >> > >> https://issues.apache.org/jira/browse/MRELEASE-907
>> > > >> > >>
>> > > >> > >> -D
>> > > >> > >>
>> > > >> > >> On Sat, Oct 10, 2015 at 5:43 PM, Benson Margulies <[hidden
>> email]
>> > > >> > <http:///user/SendEmail.jtp?type=node=5848412=2>>
>> > > >> > >> wrote:
>> > > >> > >>
>> >

Intend to release release 2.5.3

[Benson Margulies]

To me, it's a pretty urgent situation when the current version of the
release plugin blows up; what if we end up unable to release the
release plugin? So, absent any objections or further discussion of the
plexus-utils version, I intend start the process for 2.5.3 tomorrow,
since I already made the simple edit to align maven-release with scm.

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

Re: Two more proposed releases

[Benson Margulies]

Just writing for myself, I want to explain why I am pushing just a bit.

I can justify spending time on Maven because I can, amongst other
things, solve some practical problems for my colleagues. If we hit a
plugin issue, I can (usually) fix it, fix whatever other low-hanging
items are in the JIRA backlog, and make a release, all within a week.

The situation with the hanging 3.0 releases makes this harder. Yea, I
can make a branch, but it creates complexity and work to have very
many of these, and I particularly don't want to be creating branches
of the underlying shared components.

So, it's good to get it right, but it might also be good to get it
right enough soon.



On Sun, Oct 11, 2015 at 5:59 AM, Robert Scholte <rfscho...@apache.org> wrote:
> I keep changing the method signatures from time to time if I discover
> there's a better way.
> Once released we shouldn't touch method signatures anymore.
> It's a matter of rewriting plugins and testing to confirm that all works as
> intended.
>
> Robert
>
> Op Sat, 10 Oct 2015 23:58:58 +0200 schreef Tibor Digana
> <tibor.dig...@googlemail.com>:
>
>
>> What is unstable on it, any non-jira issues?
>>
>> On Sat, Oct 10, 2015 at 11:31 PM, Robert Scholte <rfscho...@apache.org>
>> wrote:
>>
>>> maven-common-artifact-filters shouldn't be a problem.
>>>
>>> but the API for maven-artifact-transfer isn't stable enough yet, so
>>> please
>>> don't.
>>>
>>> Robert
>>>
>>> Op Sat, 10 Oct 2015 21:05:56 +0200 schreef Benson Margulies <
>>> bimargul...@gmail.com>:
>>>
>>> maven-common-artifact-filters and maven-artifact-transfer, both 3.0.
>>>>
>>>>
>>>> -
>>>> 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 Common Artifact Filters version 2.0

[Benson Margulies]

I guess I swapped two of them in reading the email. I will unwind.
On Oct 11, 2015 1:53 AM, "Tibor Digana"  wrote:

> @Benson
> That's good that you take this responsibility but I guess you rush too much
> with this artifact since we still use the old maven-shared-utils:0.7 in it.
> Normally I am taking a look in dependency three and I consider dependencies
> being in release Vote. That's the case of maven-shared-utils:3.0 which is
> worth to wait half day for it been in Maven Central. Then I am convinced
> this is on 3.0 with dependencies compiled with Java 6.
> The artifact maven-shared-utils is pretty old. I made release of
> maven-shared-utils in version 0.8 and 0.9 few months ago and this artifact
> still does not reflect those fixes made.
>
>
> On Sun, Oct 11, 2015 at 2:12 AM, bimargulies [via Maven] <
> ml-node+s40175n5848272...@n5.nabble.com> wrote:
>
> > Hi,
> >
> > We solved 5 issues:
> >
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12331499=Text=12317922=Create_token=A5KQ-2QAV-T4JA-FDED%7C8959a4aa0ef1e581a93c2903df89c21523603417%7Clin
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/browse/MSHARED-386?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-common-artifact-filters%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1216
> >
> >
> https://repository.apache.org/service/local/repositories/maven-1216/content/org/apache/maven/shared/maven-common-artifact-filters/3.0/maven-common-artifact-filters-3.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-common-artifact-filters-3.0-source-release.zip sha1:
> > 78ac8c0179d5cf1c829173cf5071d17e63f0f10f
> >
> > Staging site:
> >
> >
> http://maven.apache.org/shared-archives/maven-common-artifact-filters-LATEST/
> >
> > 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.
> >
> > -
> > To unsubscribe, e-mail: [hidden email]
> > 
> > For additional commands, e-mail: [hidden email]
> > 
> >
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Common-Artifact-Filters-version-2-0-tp5848272.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
> >
> > .
> > NAML
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Re-VOTE-Release-Apache-Maven-Common-Artifact-Filters-version-2-0-tp5848308.html
> Sent from the Maven Developers mailing list archive at Nabble.com.

Re: [CANCELLED] [VOTE] Release Apache Maven Common Artifact Filters version 2.0

[Benson Margulies]

 I was clearly up too late.

On Sun, Oct 11, 2015 at 6:46 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> Hi Benson,
>
> as i already mentioned
>
> -0 from me based on the missing upgrade to maven-shared-utils-3.0.0 ...which
> can only be a few days in worst case...so i don't see a reason for that rush
> at the moment...
>
>
> On 10/11/15 2:12 AM, Benson Margulies wrote:
>>
>> Hi,
>>
>> We solved 5 issues:
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12331499=Text=12317922=Create_token=A5KQ-2QAV-T4JA-FDED%7C8959a4aa0ef1e581a93c2903df89c21523603417%7Clin
>>
>> There are still a couple of issues left in JIRA:
>>
>> https://issues.apache.org/jira/browse/MSHARED-386?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-common-artifact-filters%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1216
>>
>> https://repository.apache.org/service/local/repositories/maven-1216/content/org/apache/maven/shared/maven-common-artifact-filters/3.0/maven-common-artifact-filters-3.0-source-release.zip
>>
>> Source release checksum(s):
>> maven-common-artifact-filters-3.0-source-release.zip sha1:
>> 78ac8c0179d5cf1c829173cf5071d17e63f0f10f
>>
>> Staging site:
>>
>> http://maven.apache.org/shared-archives/maven-common-artifact-filters-LATEST/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>
> -
> To unsubscribe, e-mail: dev-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: Can anyone explain this missing plexus utils class?

[Benson Margulies]

This is presumably a core issue, won't someone comment who delves into
that part of the salt mine?


On Sun, Oct 11, 2015 at 2:57 PM, Dan Tran <dant...@gmail.com> wrote:
> I encounter the same issue and filed at
> https://issues.apache.org/jira/browse/MRELEASE-907
>
> -D
>
> On Sat, Oct 10, 2015 at 5:43 PM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> I see that the bad version of plexus-utils is called out in the
>> maven-release parent pom. I patched it in place in my local repo, and
>> now I can run the release of maven-plugins. I'll write a JIRA for the
>> release plugin.
>>
>>
>> On Sat, Oct 10, 2015 at 8:40 PM, Benson Margulies <bimargul...@gmail.com>
>> wrote:
>> > This happens trying to release maven-plugins version 28, with 3.2.5
>> > and 3.3.1, even after cleaning my local repo.
>> >  That class is not in plexus-utils 3.0.10, which is being used here,
>> > it is in the newer version of plexus-utils in the maven lib dir.
>> >
>> > I could force a dependency on the right plexus-utils in the
>> > declaration of the release plugin... but that seems extreme in the
>> > maven-plugins parent pom.
>> >
>> > I've seen this sporadically for weeks, but it's always gone away when
>> > switch maven versions until now.
>> >
>> > On Sat, Oct 10, 2015 at 8:19 PM, Benson Margulies <bimargul...@gmail.com>
>> wrote:
>> >> mvn release:prepare with 3.2.5
>> >>
>> >> ➜ maven-plugins mvn release:prepare
>> >> [INFO] Scanning for projects...
>> >> [INFO]
>> >> [INFO]
>> 
>> >> [INFO] Building Apache Maven Plugins 28-SNAPSHOT
>> >> [INFO]
>> 
>> >> [INFO]
>> >> [INFO] --- maven-release-plugin:2.5.2:prepare (default-cli) @
>> maven-plugins ---
>> >> [INFO] Verifying that there are no local modifications...
>> >> [INFO]   ignoring changes on: **/pom.xml.backup,
>> >> **/release.properties, **/pom.xml.branch, **/pom.xml.next,
>> >> **/pom.xml.releaseBackup, **/pom.xml.tag
>> >> [INFO]
>> 
>> >> [INFO] BUILD FAILURE
>> >> [INFO]
>> 
>> >> [INFO] Total time: 1.163 s
>> >> [INFO] Finished at: 2015-10-10T20:18:26-04:00
>> >> [INFO] Final Memory: 18M/310M
>> >> [INFO]
>> 
>> >> [ERROR] Failed to execute goal
>> >> org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare
>> >> (default-cli) on project maven-plugins: Execution default-cli of goal
>> >> org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare failed: A
>> >> required class was missing while executing
>> >> org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare:
>> >> org/codehaus/plexus/util/xml/pull/EntityReplacementMap
>> >> [ERROR] -
>> >> [ERROR] realm =
>> plugin>org.apache.maven.plugins:maven-release-plugin:2.5.2
>> >> [ERROR] strategy =
>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
>> >> [ERROR] urls[0] =
>> >>
>> file:/Users/benson/.m2/repository/org/apache/maven/plugins/maven-release-plugin/2.5.2/maven-release-plugin-2.5.2.jar
>> >> [ERROR] urls[1] =
>> >>
>> file:/Users/benson/.m2/repository/org/apache/maven/release/maven-release-manager/2.5.2/maven-release-manager-2.5.2.jar
>> >> [ERROR] urls[2] =
>> >>
>> file:/Users/benson/.m2/repository/org/apache/maven/release/maven-release-api/2.5.2/maven-release-api-2.5.2.jar
>> >> [ERROR] urls[3] =
>> >>
>> file:/Users/benson/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
>> >> [ERROR] urls[4] =
>> >> file:/Users/benson/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
>> >> [ERROR] urls[5] =
>> >>
>> file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-6/plexus-interactivity-api-1.0-alpha-6.jar
>> >> [ERROR] urls[6] =
>> >>
>> file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
>> >

Re: Two more proposed releases

[Benson Margulies]

On Sun, Oct 11, 2015 at 2:36 PM, Tibor Digana <tibordig...@apache.org> wrote:
> @Benson, what about to join together with Robert and help him. I guess he
> is going to make a lot of work on our plugins in SNAPSHOT Versions and
> testing them all over again. Then you may utilize your time in Maven one
> way or another as you always wanted.

Well, that depends. More people don't always make a API design project
go faster.

> Other activity i.e. development than your ambition to become release mgmt
> would help the others to continue in your way you already started with a
> good work have made till now and that's positive feeling I guess.

Tibor, my typical dev cycle here is fixes to plugins. I don't claim to
qualified to work on the core. As I wrote, my ability to commit time
to Maven depends on my ability to deliver results in releases. If
someone wants to suggest some JIRAs that help get us closer to
releasable plugins, I'll be happy to look at them.

>
> On Sun, Oct 11, 2015 at 1:05 PM, Benson Margulies [via Maven] <
> ml-node+s40175n5848364...@n5.nabble.com> wrote:
>
>> Just writing for myself, I want to explain why I am pushing just a bit.
>>
>> I can justify spending time on Maven because I can, amongst other
>> things, solve some practical problems for my colleagues. If we hit a
>> plugin issue, I can (usually) fix it, fix whatever other low-hanging
>> items are in the JIRA backlog, and make a release, all within a week.
>>
>> The situation with the hanging 3.0 releases makes this harder. Yea, I
>> can make a branch, but it creates complexity and work to have very
>> many of these, and I particularly don't want to be creating branches
>> of the underlying shared components.
>>
>> So, it's good to get it right, but it might also be good to get it
>> right enough soon.
>>
>>
>>
>> On Sun, Oct 11, 2015 at 5:59 AM, Robert Scholte <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5848364=0>> wrote:
>>
>> > I keep changing the method signatures from time to time if I discover
>> > there's a better way.
>> > Once released we shouldn't touch method signatures anymore.
>> > It's a matter of rewriting plugins and testing to confirm that all works
>> as
>> > intended.
>> >
>> > Robert
>> >
>> > Op Sat, 10 Oct 2015 23:58:58 +0200 schreef Tibor Digana
>> > <[hidden email] <http:///user/SendEmail.jtp?type=node=5848364=1>>:
>>
>> >
>> >
>> >> What is unstable on it, any non-jira issues?
>> >>
>> >> On Sat, Oct 10, 2015 at 11:31 PM, Robert Scholte <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5848364=2>>
>> >> wrote:
>> >>
>> >>> maven-common-artifact-filters shouldn't be a problem.
>> >>>
>> >>> but the API for maven-artifact-transfer isn't stable enough yet, so
>> >>> please
>> >>> don't.
>> >>>
>> >>> Robert
>> >>>
>> >>> Op Sat, 10 Oct 2015 21:05:56 +0200 schreef Benson Margulies <
>> >>> [hidden email] <http:///user/SendEmail.jtp?type=node=5848364=3>>:
>>
>> >>>
>> >>> maven-common-artifact-filters and maven-artifact-transfer, both 3.0.
>> >>>>
>> >>>>
>> >>>> -
>> >>>> To unsubscribe, e-mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node=5848364=4>
>> >>>> For additional commands, e-mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node=5848364=5>
>> >>>>
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node=5848364=6>
>> >>> For additional commands, e-mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node=5848364=7>
>> >>>
>> >>>
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node=5848364=8>
>> > For additional commands, e-mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node=5848364=9>
>> >
>>
>> -
>> To unsubscribe, e-mail: [hidden email]
>> <http:///user/SendEma

Re: Can anyone explain this missing plexus utils class?

[Benson Margulies]

The fully-document JIRA is MRELEASE-925.

On Sun, Oct 11, 2015 at 3:00 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> This is presumably a core issue, won't someone comment who delves into
> that part of the salt mine?
>
>
> On Sun, Oct 11, 2015 at 2:57 PM, Dan Tran <dant...@gmail.com> wrote:
>> I encounter the same issue and filed at
>> https://issues.apache.org/jira/browse/MRELEASE-907
>>
>> -D
>>
>> On Sat, Oct 10, 2015 at 5:43 PM, Benson Margulies <bimargul...@gmail.com>
>> wrote:
>>
>>> I see that the bad version of plexus-utils is called out in the
>>> maven-release parent pom. I patched it in place in my local repo, and
>>> now I can run the release of maven-plugins. I'll write a JIRA for the
>>> release plugin.
>>>
>>>
>>> On Sat, Oct 10, 2015 at 8:40 PM, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>> > This happens trying to release maven-plugins version 28, with 3.2.5
>>> > and 3.3.1, even after cleaning my local repo.
>>> >  That class is not in plexus-utils 3.0.10, which is being used here,
>>> > it is in the newer version of plexus-utils in the maven lib dir.
>>> >
>>> > I could force a dependency on the right plexus-utils in the
>>> > declaration of the release plugin... but that seems extreme in the
>>> > maven-plugins parent pom.
>>> >
>>> > I've seen this sporadically for weeks, but it's always gone away when
>>> > switch maven versions until now.
>>> >
>>> > On Sat, Oct 10, 2015 at 8:19 PM, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>> >> mvn release:prepare with 3.2.5
>>> >>
>>> >> ➜ maven-plugins mvn release:prepare
>>> >> [INFO] Scanning for projects...
>>> >> [INFO]
>>> >> [INFO]
>>> 
>>> >> [INFO] Building Apache Maven Plugins 28-SNAPSHOT
>>> >> [INFO]
>>> 
>>> >> [INFO]
>>> >> [INFO] --- maven-release-plugin:2.5.2:prepare (default-cli) @
>>> maven-plugins ---
>>> >> [INFO] Verifying that there are no local modifications...
>>> >> [INFO]   ignoring changes on: **/pom.xml.backup,
>>> >> **/release.properties, **/pom.xml.branch, **/pom.xml.next,
>>> >> **/pom.xml.releaseBackup, **/pom.xml.tag
>>> >> [INFO]
>>> 
>>> >> [INFO] BUILD FAILURE
>>> >> [INFO]
>>> 
>>> >> [INFO] Total time: 1.163 s
>>> >> [INFO] Finished at: 2015-10-10T20:18:26-04:00
>>> >> [INFO] Final Memory: 18M/310M
>>> >> [INFO]
>>> 
>>> >> [ERROR] Failed to execute goal
>>> >> org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare
>>> >> (default-cli) on project maven-plugins: Execution default-cli of goal
>>> >> org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare failed: A
>>> >> required class was missing while executing
>>> >> org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare:
>>> >> org/codehaus/plexus/util/xml/pull/EntityReplacementMap
>>> >> [ERROR] -
>>> >> [ERROR] realm =
>>> plugin>org.apache.maven.plugins:maven-release-plugin:2.5.2
>>> >> [ERROR] strategy =
>>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
>>> >> [ERROR] urls[0] =
>>> >>
>>> file:/Users/benson/.m2/repository/org/apache/maven/plugins/maven-release-plugin/2.5.2/maven-release-plugin-2.5.2.jar
>>> >> [ERROR] urls[1] =
>>> >>
>>> file:/Users/benson/.m2/repository/org/apache/maven/release/maven-release-manager/2.5.2/maven-release-manager-2.5.2.jar
>>> >> [ERROR] urls[2] =
>>> >>
>>> file:/Users/benson/.m2/repository/org/apache/maven/release/maven-release-api/2.5.2/maven-release-api-2.5.2.jar
>>> >> [ERROR] urls[3] =
>>> >>
>>> file:/Users/benson/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
>>> >> [ERROR] urls[4] =

Re: Can anyone explain this missing plexus utils class?

[Benson Margulies]

Tibor, I don't understand. Normally, the maven core 'rounds up' to the
highest dependency called for by all the things in the dependency
tree. Specifying a version does not 'lock it down'. If release depends
on 3.0.10, and also depends on SCM that depends on 3.0.15, I'd expect
15 to be used. Is the problem here that SCM is injected without a
conventional dependency, or something?

I'm also not following your preferred solution. What is your
alternative to the obvious edit to the maven-release
dependencyManagement area? plexus-utils is not managed in the
maven-plugins pom at all.


On Sun, Oct 11, 2015 at 3:22 PM, Dan Tran <dant...@gmail.com> wrote:
> Dont think it is maven core issue,   maven-release parent's
> dependencyManagment locks plexus-utils to 3.0.10.
>
> May as well fix up maven-release's dependencyManagement to cover all other
> dependencies
>
> -D
>
>
>
>
> On Sun, Oct 11, 2015 at 12:07 PM, Tibor Digana <tibordig...@apache.org>
> wrote:
>
>> The problem is that plexus-utils:3.0.10 does not have
>> org/codehaus/plexus/util/xml/
>> pull/EntityReplacementMap
>> It starts since 3.0.13. Maybe 3.0.12 which is missing in my repo.
>>
>> On Sun, Oct 11, 2015 at 9:02 PM, Benson Margulies [via Maven] <
>> ml-node+s40175n5848412...@n5.nabble.com> wrote:
>>
>> > The fully-document JIRA is MRELEASE-925.
>> >
>> > On Sun, Oct 11, 2015 at 3:00 PM, Benson Margulies <[hidden email]
>> > <http:///user/SendEmail.jtp?type=node=5848412=0>> wrote:
>> >
>> > > This is presumably a core issue, won't someone comment who delves into
>> > > that part of the salt mine?
>> > >
>> > >
>> > > On Sun, Oct 11, 2015 at 2:57 PM, Dan Tran <[hidden email]
>> > <http:///user/SendEmail.jtp?type=node=5848412=1>> wrote:
>> > >> I encounter the same issue and filed at
>> > >> https://issues.apache.org/jira/browse/MRELEASE-907
>> > >>
>> > >> -D
>> > >>
>> > >> On Sat, Oct 10, 2015 at 5:43 PM, Benson Margulies <[hidden email]
>> > <http:///user/SendEmail.jtp?type=node=5848412=2>>
>> > >> wrote:
>> > >>
>> > >>> I see that the bad version of plexus-utils is called out in the
>> > >>> maven-release parent pom. I patched it in place in my local repo, and
>> > >>> now I can run the release of maven-plugins. I'll write a JIRA for the
>> > >>> release plugin.
>> > >>>
>> > >>>
>> > >>> On Sat, Oct 10, 2015 at 8:40 PM, Benson Margulies <[hidden email]
>> > <http:///user/SendEmail.jtp?type=node=5848412=3>>
>> > >>> wrote:
>> > >>> > This happens trying to release maven-plugins version 28, with 3.2.5
>> > >>> > and 3.3.1, even after cleaning my local repo.
>> > >>> >  That class is not in plexus-utils 3.0.10, which is being used
>> here,
>> > >>> > it is in the newer version of plexus-utils in the maven lib dir.
>> > >>> >
>> > >>> > I could force a dependency on the right plexus-utils in the
>> > >>> > declaration of the release plugin... but that seems extreme in the
>> > >>> > maven-plugins parent pom.
>> > >>> >
>> > >>> > I've seen this sporadically for weeks, but it's always gone away
>> > when
>> > >>> > switch maven versions until now.
>> > >>> >
>> > >>> > On Sat, Oct 10, 2015 at 8:19 PM, Benson Margulies <[hidden email]
>> > <http:///user/SendEmail.jtp?type=node=5848412=4>>
>> > >>> wrote:
>> > >>> >> mvn release:prepare with 3.2.5
>> > >>> >>
>> > >>> >> ➜ maven-plugins mvn release:prepare
>> > >>> >> [INFO] Scanning for projects...
>> > >>> >> [INFO]
>> > >>> >> [INFO]
>> > >>>
>> > 
>> > >>> >> [INFO] Building Apache Maven Plugins 28-SNAPSHOT
>> > >>> >> [INFO]
>> > >>>
>> > 
>> > >>> >> [INFO]
>> > >>> >> [INFO] --- maven-release-plugin:2.5.2:prepare (default-cli) @
>> > >>> maven-plugins ---
>> > >&

Re: [ANN] Apache Maven maven-dependency-tree 3.0

[Benson Margulies]

As far as I knew, JIRA would only include resolved issues in a
release. it used to complain if an unresolved issue was tagged with a
release that one was releasing.

The log shows that Robert did this. So I marked it resolved in JIRA.

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

Re: [ANN] Apache Maven maven-dependency-tree 3.0

[Benson Margulies]

On Sun, Oct 11, 2015 at 6:54 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> Hi Benson,
>
> sorry...oversight this..my fault...

I don't know why you are apologizing; the JIRA needed fixing, I fixed it.

>
> (It is too late)..
>
> Kind regards
> Karl Heinz Marbaise
> On 10/12/15 12:38 AM, Benson Margulies wrote:
>>
>> As far as I knew, JIRA would only include resolved issues in a
>> release. it used to complain if an unresolved issue was tagged with a
>> release that one was releasing.
>>
>> The log shows that Robert did this. So I marked it resolved in JIRA.
>>
>
> -
> 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: [ANN] Apache Maven maven-dependency-tree 3.0

[Benson Margulies]

Hey, I just assume that the JIRAs are correct. What component do you
think it should be?


On Sun, Oct 11, 2015 at 4:51 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> Hi,
>
> If i take a look into JIRA there are 4 issues in 3.0 release...
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12331490
>
> is MSHARED-420  wrongly assigned to maven-dependency-tree 3.0, cause it is
> not part of the release nor it is it ready ?
>
>
> Kind regards
> Karl Heinz Marbaise
>
> On 10/10/15 9:04 PM, Benson Margulies wrote:
>>
>> The Maven team is pleased to announce the release of the Apache Maven
>> Dependency Tree, version 3.0
>>
>> A tree-based API for resolution of Maven project dependencies
>>
>> http://maven.apache.org/shared/maven-dependency-tree/
>>
>> You should specify the version in your project's dependency configuration:
>>
>> 
>>org.apache.maven.shared
>>maven-dependency-tree
>>3.0
>> 
>>
>>
>> Release Notes - Apache Maven Dependency Tree - Version 3.0
>>
>> Bug
>> * [MSHARED-422] Change DependencyGraphBuilder method signatures
>>
>> Improvement
>> * [MSHARED-421] Change JDK + Maven requirements
>> * [MSHARED-371] Increase chance of java8 compliance by updating to
>> plexus-component-* 1.6
>>
>>
>
> -
> 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: [ANN] Apache Maven maven-dependency-tree 3.0

[Benson Margulies]

I am confused and away from my computer. I will try to clarify later
On Oct 11, 2015 5:57 PM, "Karl Heinz Marbaise" <khmarba...@gmx.de> wrote:

> Hi Benson,
>
> On 10/11/15 11:39 PM, Benson Margulies wrote:
>
>> Hey, I just assume that the JIRAs are correct. What component do you
>> think it should be?
>>
>
> sorry i couldn't read...So the question is: Is this completely done or
> not? Based on the jira it is not and neither based on the svn history...
>
> So this should be moved forward to a new release of the component...
>
> Kind regards
> Karl Heinz Marbaise
>
>>
>>
>> On Sun, Oct 11, 2015 at 4:51 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
>> wrote:
>>
>>> Hi,
>>>
>>> If i take a look into JIRA there are 4 issues in 3.0 release...
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12331490
>>>
>>> is MSHARED-420  wrongly assigned to maven-dependency-tree 3.0, cause it
>>> is
>>> not part of the release nor it is it ready ?
>>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> On 10/10/15 9:04 PM, Benson Margulies wrote:
>>>
>>>>
>>>> The Maven team is pleased to announce the release of the Apache Maven
>>>> Dependency Tree, version 3.0
>>>>
>>>> A tree-based API for resolution of Maven project dependencies
>>>>
>>>> http://maven.apache.org/shared/maven-dependency-tree/
>>>>
>>>> You should specify the version in your project's dependency
>>>> configuration:
>>>>
>>>> 
>>>> org.apache.maven.shared
>>>> maven-dependency-tree
>>>> 3.0
>>>> 
>>>>
>>>>
>>>> Release Notes - Apache Maven Dependency Tree - Version 3.0
>>>>
>>>> Bug
>>>> * [MSHARED-422] Change DependencyGraphBuilder method signatures
>>>>
>>>> Improvement
>>>> * [MSHARED-421] Change JDK + Maven requirements
>>>> * [MSHARED-371] Increase chance of java8 compliance by updating to
>>>> plexus-component-* 1.6
>>>>
>>>>
>>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>
>

Re: Can anyone explain this missing plexus utils class?

[Benson Margulies]

On Oct 11, 2015 6:59 PM, "Dan Tran" <dant...@gmail.com> wrote:

> Hi all, according to my understanding,  maven uses depManagement to lock
> down and version.
>
>
 just sets defaults for version, scope, optional, and
exclusions. It doesn't 'lock' any more than writing the same things in the
regular dependency element does.

What do you expect to happen if two dependencies disagree on version?



> If it not so, it is a very serious miss understanding for lots of users
>
> Can someone confirm?
>
> -Dan
>
> On Sun, Oct 11, 2015 at 1:07 PM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
> > Tibor, I don't understand. Normally, the maven core 'rounds up' to the
> > highest dependency called for by all the things in the dependency
> > tree. Specifying a version does not 'lock it down'. If release depends
> > on 3.0.10, and also depends on SCM that depends on 3.0.15, I'd expect
> > 15 to be used. Is the problem here that SCM is injected without a
> > conventional dependency, or something?
> >
> > I'm also not following your preferred solution. What is your
> > alternative to the obvious edit to the maven-release
> > dependencyManagement area? plexus-utils is not managed in the
> > maven-plugins pom at all.
> >
> >
> > On Sun, Oct 11, 2015 at 3:22 PM, Dan Tran <dant...@gmail.com> wrote:
> > > Dont think it is maven core issue,   maven-release parent's
> > > dependencyManagment locks plexus-utils to 3.0.10.
> > >
> > > May as well fix up maven-release's dependencyManagement to cover all
> > other
> > > dependencies
> > >
> > > -D
> > >
> > >
> > >
> > >
> > > On Sun, Oct 11, 2015 at 12:07 PM, Tibor Digana <tibordig...@apache.org
> >
> > > wrote:
> > >
> > >> The problem is that plexus-utils:3.0.10 does not have
> > >> org/codehaus/plexus/util/xml/
> > >> pull/EntityReplacementMap
> > >> It starts since 3.0.13. Maybe 3.0.12 which is missing in my repo.
> > >>
> > >> On Sun, Oct 11, 2015 at 9:02 PM, Benson Margulies [via Maven] <
> > >> ml-node+s40175n5848412...@n5.nabble.com> wrote:
> > >>
> > >> > The fully-document JIRA is MRELEASE-925.
> > >> >
> > >> > On Sun, Oct 11, 2015 at 3:00 PM, Benson Margulies <[hidden email]
> > >> > <http:///user/SendEmail.jtp?type=node=5848412=0>> wrote:
> > >> >
> > >> > > This is presumably a core issue, won't someone comment who delves
> > into
> > >> > > that part of the salt mine?
> > >> > >
> > >> > >
> > >> > > On Sun, Oct 11, 2015 at 2:57 PM, Dan Tran <[hidden email]
> > >> > <http:///user/SendEmail.jtp?type=node=5848412=1>> wrote:
> > >> > >> I encounter the same issue and filed at
> > >> > >> https://issues.apache.org/jira/browse/MRELEASE-907
> > >> > >>
> > >> > >> -D
> > >> > >>
> > >> > >> On Sat, Oct 10, 2015 at 5:43 PM, Benson Margulies <[hidden email]
> > >> > <http:///user/SendEmail.jtp?type=node=5848412=2>>
> > >> > >> wrote:
> > >> > >>
> > >> > >>> I see that the bad version of plexus-utils is called out in the
> > >> > >>> maven-release parent pom. I patched it in place in my local
> repo,
> > and
> > >> > >>> now I can run the release of maven-plugins. I'll write a JIRA
> for
> > the
> > >> > >>> release plugin.
> > >> > >>>
> > >> > >>>
> > >> > >>> On Sat, Oct 10, 2015 at 8:40 PM, Benson Margulies <[hidden
> email]
> > >> > <http:///user/SendEmail.jtp?type=node=5848412=3>>
> > >> > >>> wrote:
> > >> > >>> > This happens trying to release maven-plugins version 28, with
> > 3.2.5
> > >> > >>> > and 3.3.1, even after cleaning my local repo.
> > >> > >>> >  That class is not in plexus-utils 3.0.10, which is being used
> > >> here,
> > >> > >>> > it is in the newer version of plexus-utils in the maven lib
> dir.
> > >> > >>> >
> > >> > >>> > I could force a dependency on the right plexus-utils in the
> > >> > >>> > decl

[ANN] Apache Maven Assembly Plugin 2.6 Released

[Benson Margulies]

The Apache Maven team is pleased to announce the release of the Apache
Maven Assembly Plugin, version 2.6

This plugin builds directories and archives of files, usually for releases.

http://maven.apache.org/plugins/maven-assembly-plugin/

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-assembly-plugin



You can download the appropriate sources etc. from the download page:

http://maven.apache.org/plugins/maven-2.6-plugin/download.cgi

Release Notes - Maven Assembly Plugin - Version 2.6

Improvements:
MASSEMBLY-780   Snappy supported  06/Oct/15

NOTE: This version requires Java 1.6.


Enjoy,

-The Apache Maven team

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

Getting plugins to easily releasable condition -- parent 28?

[Benson Margulies]

I'm motivated to get back to the state where it's easy to release a
plugin from the trunk.

Is there any impediment to releasing parent 28 of the plugins?

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

Two more proposed releases

[Benson Margulies]

maven-common-artifact-filters and maven-artifact-transfer, both 3.0.

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

[ANN] Apache Maven maven-dependency-tree 3.0

[Benson Margulies]

The Maven team is pleased to announce the release of the Apache Maven
Dependency Tree, version 3.0

A tree-based API for resolution of Maven project dependencies

http://maven.apache.org/shared/maven-dependency-tree/

You should specify the version in your project's dependency configuration:


  org.apache.maven.shared
  maven-dependency-tree
  3.0



Release Notes - Apache Maven Dependency Tree - Version 3.0

Bug
* [MSHARED-422] Change DependencyGraphBuilder method signatures

Improvement
* [MSHARED-421] Change JDK + Maven requirements
* [MSHARED-371] Increase chance of java8 compliance by updating to
plexus-component-* 1.6


Enjoy,

-The Maven team

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

Can anyone explain this missing plexus utils class?

[Benson Margulies]

mvn release:prepare with 3.2.5

➜ maven-plugins mvn release:prepare
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Apache Maven Plugins 28-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-release-plugin:2.5.2:prepare (default-cli) @ maven-plugins ---
[INFO] Verifying that there are no local modifications...
[INFO]   ignoring changes on: **/pom.xml.backup,
**/release.properties, **/pom.xml.branch, **/pom.xml.next,
**/pom.xml.releaseBackup, **/pom.xml.tag
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 1.163 s
[INFO] Finished at: 2015-10-10T20:18:26-04:00
[INFO] Final Memory: 18M/310M
[INFO] 
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare
(default-cli) on project maven-plugins: Execution default-cli of goal
org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare failed: A
required class was missing while executing
org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare:
org/codehaus/plexus/util/xml/pull/EntityReplacementMap
[ERROR] -
[ERROR] realm =plugin>org.apache.maven.plugins:maven-release-plugin:2.5.2
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/Users/benson/.m2/repository/org/apache/maven/plugins/maven-release-plugin/2.5.2/maven-release-plugin-2.5.2.jar
[ERROR] urls[1] =
file:/Users/benson/.m2/repository/org/apache/maven/release/maven-release-manager/2.5.2/maven-release-manager-2.5.2.jar
[ERROR] urls[2] =
file:/Users/benson/.m2/repository/org/apache/maven/release/maven-release-api/2.5.2/maven-release-api-2.5.2.jar
[ERROR] urls[3] =
file:/Users/benson/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
[ERROR] urls[4] =
file:/Users/benson/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
[ERROR] urls[5] =
file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-6/plexus-interactivity-api-1.0-alpha-6.jar
[ERROR] urls[6] =
file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
[ERROR] urls[7] =
file:/Users/benson/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[8] =
file:/Users/benson/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[9] =
file:/Users/benson/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[10] =
file:/Users/benson/.m2/repository/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2.jar
[ERROR] urls[11] =
file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[12] =
file:/Users/benson/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
[ERROR] urls[13] =
file:/Users/benson/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
[ERROR] urls[14] =
file:/Users/benson/.m2/repository/commons-io/commons-io/2.2/commons-io-2.2.jar
[ERROR] urls[15] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-providers-standard/1.9.4/maven-scm-providers-standard-1.9.4.pom
[ERROR] urls[16] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-accurev/1.9.4/maven-scm-provider-accurev-1.9.4.jar
[ERROR] urls[17] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-bazaar/1.9.4/maven-scm-provider-bazaar-1.9.4.jar
[ERROR] urls[18] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-clearcase/1.9.4/maven-scm-provider-clearcase-1.9.4.jar
[ERROR] urls[19] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvsexe/1.9.4/maven-scm-provider-cvsexe-1.9.4.jar
[ERROR] urls[20] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvs-commons/1.9.4/maven-scm-provider-cvs-commons-1.9.4.jar
[ERROR] urls[21] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvsjava/1.9.4/maven-scm-provider-cvsjava-1.9.4.jar
[ERROR] urls[22] =
file:/Users/benson/.m2/repository/org/netbeans/lib/cvsclient/20060125/cvsclient-20060125.jar
[ERROR] urls[23] =
file:/Users/benson/.m2/repository/ch/ethz/ganymed/ganymed-ssh2/build210/ganymed-ssh2-build210.jar
[ERROR] urls[24] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-gitexe/1.9.4/maven-scm-provider-gitexe-1.9.4.jar
[ERROR] urls[25] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-git-commons/1.9.4/maven-scm-provider-git-commons-1.9.4.jar
[ERROR] urls[26] =