Re: [ANN] Apache Maven Verifier 1.7.1 Released

[Christopher]

Never mind. I see it now.
It says "This library provides a test harness for Maven integration tests."
For some reason, this paragraph didn't render in my email client upon
first viewing.
My mistake. Sorry for the noise.

On Mon, Apr 6, 2020 at 5:41 PM Christopher  wrote:
>
> What does maven-verifier-plugin do?
> Including this information on future announcement messages would be
> helpful, thanks.
>
> On Mon, Apr 6, 2020 at 5:34 PM Robert Scholte  wrote:
> >
> > The Apache Maven team is pleased to announce the release of the Apache 
> > Maven Verifier, version 1.7.1
> >
> > This library provides a test harness for Maven integration tests.
> >
> > https://maven.apache.org/shared/maven-verifier/ 
> > [https://maven.apache.org/shared/maven-verifier/]
> >
> > You should specify the dependency in your project:
> >
> > 
> > org.apache.maven.shared
> > maven-verifier
> > 1.7.1
> > 
> >
> > You can download the appropriate sources etc. from the download page:
> >
> > https://maven.apache.org/shared/maven-verifier/download.html 
> > [https://maven.apache.org/shared/maven-verifier/download.html]
> >
> >
> > Release Notes - Maven Shared Components - Version maven-verifier-1.7.1
> >
> > ** Bug
> > * [MSHARED-872] - Embedded3xLauncher cannot be initialized
> >
> > 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: [ANN] Apache Maven Verifier 1.7.1 Released

[Christopher]

What does maven-verifier-plugin do?
Including this information on future announcement messages would be
helpful, thanks.

On Mon, Apr 6, 2020 at 5:34 PM Robert Scholte  wrote:
>
> The Apache Maven team is pleased to announce the release of the Apache Maven 
> Verifier, version 1.7.1
>
> This library provides a test harness for Maven integration tests.
>
> https://maven.apache.org/shared/maven-verifier/ 
> [https://maven.apache.org/shared/maven-verifier/]
>
> You should specify the dependency in your project:
>
> 
> org.apache.maven.shared
> maven-verifier
> 1.7.1
> 
>
> You can download the appropriate sources etc. from the download page:
>
> https://maven.apache.org/shared/maven-verifier/download.html 
> [https://maven.apache.org/shared/maven-verifier/download.html]
>
>
> Release Notes - Maven Shared Components - Version maven-verifier-1.7.1
>
> ** Bug
> * [MSHARED-872] - Embedded3xLauncher cannot be initialized
>
> 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: maven-apache-parent 22 ETA?

[Christopher]

Hi Maven devs,

I just wanted to circle back to this. Is the ASF parent POM still
being maintained by the Maven community? And regarding my other
questions, I never got a response. Thanks for any response you can
give.

On Mon, Aug 5, 2019 at 4:14 PM Christopher  wrote:
>
> Hi,
>
> In spite of the specific title, I actually have several questions
> (note, I'm not currently subscribed to list, so feel free to CC me
> directly on any responses):
>
> 1. What's the timeline for the maven-apache-parent 22? It seems a bit
> overdue, especially given all the plugins that have been updated since
> 21 was released.
>
> I'm hoping https://github.com/apache/maven-apache-parent/pull/1 gets
> merged in. Can somebody merge that before 22 is released? Two people
> reviewed and approved it 10 months ago.
>
> 2. I had another idea for adding something like the following to
> satisfy the use case for cross-compilation using newer JDKs without
> specifying `-bootstrapclasspath`. Would this be worth a pull request
> (or a committer could just add it if they think it's a good idea).
>
> 
>   8
> 
> 
>   jdk-release-flag
>   
> [9,)
>   
>   
> ${compilerCompliance}
>   
> 
>
> 3. And finally... I noticed that JDK 11's javadoc is not getting the
> backports of the JDK 12 upstream patches... even though 11 is supposed
> to be an LTS version. This causes javadocs generated with
> maven-javadoc-plugin to be broken for projects which aren't using
> modules. Specifically, the following bug appears to not be patched in
> 11 that affect all users of maven-javadoc-plugin. Some plugin goals
> output (such as javadoc:aggregate) can be patched after building, but
> others (javadoc:jar) can't easily be patched, because the broken
> javadoc jar would have to be disassembled to patch and reconstructed.
> Is there a workaround for these planned by the maven-javadoc-plugin
> developers, or is the hope that upstream will fix it eventually?
>
> https://bugs.openjdk.java.net/browse/JDK-8215291 (severe loss of
> functionality when building non-modular code... which is most java
> code today... using JDK 11)
>
> https://bugs.openjdk.java.net/browse/JDK-8227487 (a minor regression
> also not patched in 11)
> https://bugs.openjdk.java.net/browse/JDK-8214856 (another bug, not
> sure how serious, also not patched in 11)
>
>
> Thanks,
>
> Christopher

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

maven-apache-parent 22 ETA?

[Christopher]

Hi,

In spite of the specific title, I actually have several questions
(note, I'm not currently subscribed to list, so feel free to CC me
directly on any responses):

1. What's the timeline for the maven-apache-parent 22? It seems a bit
overdue, especially given all the plugins that have been updated since
21 was released.

I'm hoping https://github.com/apache/maven-apache-parent/pull/1 gets
merged in. Can somebody merge that before 22 is released? Two people
reviewed and approved it 10 months ago.

2. I had another idea for adding something like the following to
satisfy the use case for cross-compilation using newer JDKs without
specifying `-bootstrapclasspath`. Would this be worth a pull request
(or a committer could just add it if they think it's a good idea).


  8


  jdk-release-flag
  
[9,)
  
  
${compilerCompliance}
  


3. And finally... I noticed that JDK 11's javadoc is not getting the
backports of the JDK 12 upstream patches... even though 11 is supposed
to be an LTS version. This causes javadocs generated with
maven-javadoc-plugin to be broken for projects which aren't using
modules. Specifically, the following bug appears to not be patched in
11 that affect all users of maven-javadoc-plugin. Some plugin goals
output (such as javadoc:aggregate) can be patched after building, but
others (javadoc:jar) can't easily be patched, because the broken
javadoc jar would have to be disassembled to patch and reconstructed.
Is there a workaround for these planned by the maven-javadoc-plugin
developers, or is the hope that upstream will fix it eventually?

https://bugs.openjdk.java.net/browse/JDK-8215291 (severe loss of
functionality when building non-modular code... which is most java
code today... using JDK 11)

https://bugs.openjdk.java.net/browse/JDK-8227487 (a minor regression
also not patched in 11)
https://bugs.openjdk.java.net/browse/JDK-8214856 (another bug, not
sure how serious, also not patched in 11)


Thanks,

Christopher

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

Re: Bug in processing surefire/failsafe groups

[Christopher]

Version 2.21.0 didn't quite achieve a perfect fix. Now the plugin proceeds,
but instead, I get the following in my build:

[WARNING] Corrupted STDOUT by directly writing to native stream in forked
JVM 1. See FAQ web page and the dump file
/path/to/target/failsafe-reports/2018-04-04T14-48-54_810-jvmRun1.dumpstream

And inside that file, I get:

# Created on 2018-04-04T14:49:31.119

Corrupted STDOUT by directly writing to native stream in forked JVM 1.
Stream '[WARNING] Couldn't load group class
'org.apache.accumulo.test.categories.SunnyDayTests' in Surefire|Failsafe
plugin. The group class is ignored!'.
java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma
after third character in command '[WARNING] Couldn't load group class
'org.apache.accumulo.test.categories.SunnyDayTests' in Surefire|Failsafe
plugin. The group class is ignored!'.
  at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.(ForkClient.java:511)
  at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
  at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
  at
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
  at java.lang.Thread.run(Thread.java:748)

Ignoring the class is great and the expected behavior... but "Corrupted
STDOUT" is still concerning.

On Wed, Apr 4, 2018 at 2:52 PM Christopher <ctubb...@apache.org> wrote:

> Enrico: Thanks for the info. I'm using the version inherited from the ASF
> parent POM 19, which turns out to be 2.20.1. Version 2.21.0 seems to fix
> the problem. Thanks!
>
> Tibor: No, I didn't get previous email. The Maven lists are too spammy for
> me to subscribe. That could be the reason. Please CC me if follow-up is
> needed. Thanks.
>
>
> On Sat, Mar 31, 2018 at 10:16 AM Enrico Olivelli <eolive...@gmail.com>
> wrote:
>
>> This problem has been fixed in 2.21.0, what version are you running?
>>
>> Enrico
>>
>>
>> Il sab 31 mar 2018, 14:54 Tibor Digana <tibordig...@apache.org> ha
>> scritto:
>>
>>> Christopher,
>>>
>>> Did you receive my previous answer?
>>> There is some problem with email delivery.
>>> Tibor
>>>
>>> On Fri, Mar 30, 2018 at 8:58 PM, Christopher <ctubb...@apache.org>
>>> wrote:
>>>
>>> > Found a bug in maven-failsafe-plugin (
>>> > https://github.com/apache/accumulo/issues/411) when using groups
>>> (JUnit
>>> > categories):
>>> > http://maven.apache.org/surefire/maven-failsafe-
>>> > plugin/integration-test-mojo.html#groups
>>> > http://maven.apache.org/surefire/maven-failsafe-
>>> > plugin/integration-test-mojo.html#excludedGroups
>>> >
>>> > The problem is when the class corresponding to a configured group is
>>> not on
>>> > the class path. This is particularly problematic in multi-module
>>> builds, if
>>> > a group is specified which exists in one module but not another one.
>>> >
>>> > It appears the bug occurs because the configured group/category is
>>> loaded
>>> > from the class path, and then compared to the classes to find matching
>>> > tests. However, this seems backwards. If the tests were examined first,
>>> > then the name of the groups could be matched against the configuration
>>> > without loading to load the configured groups/category. Even if this
>>> is not
>>> > possible due to some limitation on how these groups are passed to
>>> JUnit or
>>> > some other restriction, a ClassNotFoundException (CNFE) should be
>>> handled
>>> > more sanely: For example, in the case of a CNFE for the "groups"
>>> parameter,
>>> > then it's clearly not possible for any tests to be included, so no
>>> tests
>>> > should run. In the case of a CNFE for "excludedGroups", then it's
>>> clearly
>>> > not possible for any tests to match, so none should be excluded.
>>> >
>>> > This bug has got me thinking about a related feature I'd like to see in
>>> > maven-surefire-plugin and maven-failsafe-plugin: I'd like to see
>>> groups /
>>> > excludedGroups specified by patterns, similar to `-Dtest=MyTest`
>>> instead of
>>> > `-Dtest=org.apache.project.package.subpackage.testing.MyTest`, it
>>> would be
>>> > nice to set `-Dgroups=MyGroup` rather than
>>> > `-Dgroups=org.apache.project.package.subpackage.testing.
>>> > categories.MyGroup`.
>>> > If groups could be specified as patterns, it would be more obvious
>>> that a
>>> > CNFE could not occur... if a pattern didn't match any classes, then it
>>> > wouldn't result in a CNFE... it would simply return an empty set.
>>> >
>>> > Thanks,
>>> >
>>> > Christopher
>>> >
>>>
>> --
>>
>>
>> -- Enrico Olivelli
>>
>

Re: Bug in processing surefire/failsafe groups

[Christopher]

Enrico: Thanks for the info. I'm using the version inherited from the ASF
parent POM 19, which turns out to be 2.20.1. Version 2.21.0 seems to fix
the problem. Thanks!

Tibor: No, I didn't get previous email. The Maven lists are too spammy for
me to subscribe. That could be the reason. Please CC me if follow-up is
needed. Thanks.

On Sat, Mar 31, 2018 at 10:16 AM Enrico Olivelli <eolive...@gmail.com>
wrote:

> This problem has been fixed in 2.21.0, what version are you running?
>
> Enrico
>
>
> Il sab 31 mar 2018, 14:54 Tibor Digana <tibordig...@apache.org> ha
> scritto:
>
>> Christopher,
>>
>> Did you receive my previous answer?
>> There is some problem with email delivery.
>> Tibor
>>
>> On Fri, Mar 30, 2018 at 8:58 PM, Christopher <ctubb...@apache.org> wrote:
>>
>> > Found a bug in maven-failsafe-plugin (
>> > https://github.com/apache/accumulo/issues/411) when using groups (JUnit
>> > categories):
>> > http://maven.apache.org/surefire/maven-failsafe-
>> > plugin/integration-test-mojo.html#groups
>> > http://maven.apache.org/surefire/maven-failsafe-
>> > plugin/integration-test-mojo.html#excludedGroups
>> >
>> > The problem is when the class corresponding to a configured group is
>> not on
>> > the class path. This is particularly problematic in multi-module
>> builds, if
>> > a group is specified which exists in one module but not another one.
>> >
>> > It appears the bug occurs because the configured group/category is
>> loaded
>> > from the class path, and then compared to the classes to find matching
>> > tests. However, this seems backwards. If the tests were examined first,
>> > then the name of the groups could be matched against the configuration
>> > without loading to load the configured groups/category. Even if this is
>> not
>> > possible due to some limitation on how these groups are passed to JUnit
>> or
>> > some other restriction, a ClassNotFoundException (CNFE) should be
>> handled
>> > more sanely: For example, in the case of a CNFE for the "groups"
>> parameter,
>> > then it's clearly not possible for any tests to be included, so no tests
>> > should run. In the case of a CNFE for "excludedGroups", then it's
>> clearly
>> > not possible for any tests to match, so none should be excluded.
>> >
>> > This bug has got me thinking about a related feature I'd like to see in
>> > maven-surefire-plugin and maven-failsafe-plugin: I'd like to see groups
>> /
>> > excludedGroups specified by patterns, similar to `-Dtest=MyTest`
>> instead of
>> > `-Dtest=org.apache.project.package.subpackage.testing.MyTest`, it would
>> be
>> > nice to set `-Dgroups=MyGroup` rather than
>> > `-Dgroups=org.apache.project.package.subpackage.testing.
>> > categories.MyGroup`.
>> > If groups could be specified as patterns, it would be more obvious that
>> a
>> > CNFE could not occur... if a pattern didn't match any classes, then it
>> > wouldn't result in a CNFE... it would simply return an empty set.
>> >
>> > Thanks,
>> >
>> > Christopher
>> >
>>
> --
>
>
> -- Enrico Olivelli
>

Bug in processing surefire/failsafe groups

[Christopher]

Found a bug in maven-failsafe-plugin (
https://github.com/apache/accumulo/issues/411) when using groups (JUnit
categories):
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#groups
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#excludedGroups

The problem is when the class corresponding to a configured group is not on
the class path. This is particularly problematic in multi-module builds, if
a group is specified which exists in one module but not another one.

It appears the bug occurs because the configured group/category is loaded
from the class path, and then compared to the classes to find matching
tests. However, this seems backwards. If the tests were examined first,
then the name of the groups could be matched against the configuration
without loading to load the configured groups/category. Even if this is not
possible due to some limitation on how these groups are passed to JUnit or
some other restriction, a ClassNotFoundException (CNFE) should be handled
more sanely: For example, in the case of a CNFE for the "groups" parameter,
then it's clearly not possible for any tests to be included, so no tests
should run. In the case of a CNFE for "excludedGroups", then it's clearly
not possible for any tests to match, so none should be excluded.

This bug has got me thinking about a related feature I'd like to see in
maven-surefire-plugin and maven-failsafe-plugin: I'd like to see groups /
excludedGroups specified by patterns, similar to `-Dtest=MyTest` instead of
`-Dtest=org.apache.project.package.subpackage.testing.MyTest`, it would be
nice to set `-Dgroups=MyGroup` rather than
`-Dgroups=org.apache.project.package.subpackage.testing.categories.MyGroup`.
If groups could be specified as patterns, it would be more obvious that a
CNFE could not occur... if a pattern didn't match any classes, then it
wouldn't result in a CNFE... it would simply return an empty set.

Thanks,

Christopher

Maven plugin developer doumentation

[Christopher]

Hi,

I develop some Maven plugins, and am struggling trying to find
documentation on which dependencies are provided by a particular version of
Maven, and when I should use a newer compatible version as the dependency
in my plugin.

For example, I have a plugin which declares 3.2.5 as a prerequisite and has
the following dependencies:
  maven-core (3.2.5, provided)
  maven-plugin-api (3.2.5, provided)
  maven-plugin-annotations (3.5, provided)
  plexus-utils (3.0.24, provided)

However, I don't actually know which versions of these plugins are provided
by which Maven versions, and whether or not I could use this plugin with an
earlier version of Maven. Perhaps I could set the prerequisite to 3.0.5 and
it would work fine?

Ideally, every version of Maven would release with a guide for plugin
developers, to let developers know which versions of the dependencies they
should use, but I can't find anything like that. Is there a useful guide
somewhere?

A related problem that could be covered by a developer guide: which maven
library code is executed during plugin execution, and which are executed
during plugin compilation? (In other words, when is it safe to user a newer
version of a particular dependency, without breaking that plugin's
compatibility with a particular version of Maven?) Perhaps this really
boils down to: "How stable are the APIs for these Maven libraries used for
Maven plugins?"

Hopefully, there's already a useful guide out there, or maybe just a few
simple guidelines which can be shared with me. Otherwise, I fear this might
be another "dependency hell" issue.


Thanks for any guidance you can provide for managing plugin dependencies,

Christopher

Re: Missing docs for mapping arrays

[Christopher]

I never got a response from this. I think it's still relevant.

On Fri, Oct 7, 2016 at 5:33 PM Christopher <ctubb...@apache.org> wrote:

> All-
>
> I noticed today, while reading the guide to configuring plugins[1], that
> the information about mapping collections/lists explains how it is similar
> to, and different from, mapping arrays. However, there's no section on that
> page, or link to anywhere else, to explain how arrays themselves are mapped.
>
> [1]: https://maven.apache.org/guides/mini/guide-configuring-plugins.html
>
>

Missing docs for mapping arrays

[Christopher]

All-

I noticed today, while reading the guide to configuring plugins[1], that
the information about mapping collections/lists explains how it is similar
to, and different from, mapping arrays. However, there's no section on that
page, or link to anywhere else, to explain how arrays themselves are mapped.

[1]: https://maven.apache.org/guides/mini/guide-configuring-plugins.html

Re: JUnit categories in surefire/failsafe

[Christopher]

On Wed, Aug 31, 2016 at 4:43 AM Tibor Digana <tibordig...@apache.org> wrote:

> >>One thing we noticed was that the user property is the same for both
> plugins.
> We are aware of this and we will break the backwards compatibility.
> This change is planned in Surefire 3.0.
> I am thinking of temporary fix but better not to do it.
> Please reference and use these user/properties since they will be in 3.0:
> ${surefire.groups}
> ${failsafe.groups}
>
>
Thanks. We'll do that. We had created our own, but it's better to use the
property names which will appear in future versions of the plugins.


> Do you still need "_ALL_, _NONE_, _UNCATEGORIZED_"?
>
>
>
Not at the moment, and these were secondary. After thinking about it, "ALL"
and "NONE" aren't needed, so long as it's easy enough to set the
groups/excludedGroups properties to empty with an override. My main concern
about those two options were that it might be hard to set a property to
"empty" to override a default non-empty value, because Maven might just
treat it as though it weren't set at all, and ignore it. I'd have to
experiment to see if that's the case or if it properly sets it to null or
empty string or whatever when it's in the DOM without a value or if it's a
system property without a value.

The most useful of the three would be UNCATEGORIZED, so it can be combined
with other categories and I'd expect that would require JUnit support
underneath.


>
> On Wed, Aug 31, 2016 at 10:23 AM, Tibor Digana <tibordig...@apache.org>
> wrote:
>
> > Hi Christopher,
> >
> > Some offtopic. I will answer your email but first I have a question for
> you
> > and Accumulo project.
> > I visited Accumulo cca one week ago. Why the build [1] hangs on IT test
> > executed by maven-failsafe-plugin:2.19.1?
> > I asked INFRA team to display Thread Dump button. Do you see this button,
> > can you grap the thread dump? I would like to see what's going on in
> > Failsafe plugin. We have such issue [3] but now it most probably is user
> > error because the developer overrides std/out via System.setOut() but
> this
> > hypothesis has not been confirmed yet because it's too early.
> >
> > [1] https://builds.apache.org/job/Accumulo-master-IT/
> > [2]
> https://wiki.jenkins-ci.org/display/JENKINS/Thread+Dump+Action+Plugin
> > [3] https://issues.apache.org/jira/browse/SUREFIRE-1193
> >
> >
> >
> > On Wed, Aug 31, 2016 at 3:00 AM, Christopher [via Maven] <
> > ml-node+s40175n5879500...@n5.nabble.com> wrote:
> >
> > > tl;dr - A proposal for config independence for groups/excludeGroups
> > > properties and some special keywords for ALL, NONE, and UNCATEGORIZED
> > > groups.
> > >
> > > ***
> > >
> > > In the Apache Accumulo project, we're currently in process of trying to
> > > make use of JUnit categories to separate different classes of tests.
> > >
> > > So, we're using the maven-surefire-plugin and maven-failsafe-plugin
> > > configuration properties: groups, excludeGroups
> > >
> > > One thing we noticed was that the user property is the same for both
> > > plugins. This is a problem, because one cannot pass in a system
> property
> > > on
> > > the command-line to affect one without affecting the other.
> > >
> > > I propose that maven-surefire-plugin and maven-failsafe-plugin
> deprecate
> > > the existing groups/excludeGroups properties, and replace them with
> > > tests.groups/tests.excludeGroups, and it.groups/it.excludeGroups. (This
> > > should probably be done for other shared properties as well.)
> > >
> > > Users can simulate this by doing something like this:
> > > ${it.groups}
> > >
> > > However, this may cause problems if the property is not defined I
> > > haven't tested to be sure.
> > >
> > > ***
> > >
> > > That leads me to a question and a second proposal:
> > > Is there a way to specify uncategorized test classes? Or all test
> > classes?
> > > Or none?
> > >
> > > If not, I would like to propose that some special keywords be created
> > > which
> > > can represent:
> > > _ALL_, _NONE_, _UNCATEGORIZED_ (or similar)
> > >
> > > That way, users can do things like:
> > > my.special.Category,_UNCATEGORIZED_
> > > _NONE_
> > > or
> > > _NONE_
> > > or
> > > _ALL_
> > >
> > > These keywords may require some support from the underlying test
> > > framework,
> >

Re: JUnit categories in surefire/failsafe

[Christopher]

On Wed, Aug 31, 2016 at 4:23 AM Tibor Digana <tibordig...@apache.org> wrote:

> Hi Christopher,
>
> Some offtopic. I will answer your email but first I have a question for you
> and Accumulo project.
> I visited Accumulo cca one week ago. Why the build [1] hangs on IT test
> executed by maven-failsafe-plugin:2.19.1?
>

I wasn't aware it was hanging. That particular Jenkins job is an
experimental attempt by one of our developers to try to run all of our
tests in parallel, and it's quite spammy when there's a failure. I don't
track it. I'm tracking some of our other jobs.

Usually, though, our problem is with our tests, not necessarily failsafe,
but I can't be sure unless you point me directly to the failure, instead of
the job page.


> I asked INFRA team to display Thread Dump button. Do you see this button,
> can you grap the thread dump? I would like to see what's going on in
> Failsafe plugin. We have such issue [3] but now it most probably is user
> error because the developer overrides std/out via System.setOut() but this
> hypothesis has not been confirmed yet because it's too early.
>
>
I don't see the button, but our tests do set the surefire/maven option to
redirect test output to a file. I didn't think we're doing System.setOut()
at all, but it looks like we are doing it in one failsafe IT, and one
surefire test. I'll have to investigate these a bit more. I think there's
probably a better way to do those tests.

I'm adding our dev list to the distro. Let's continue this conversation
there, if necessary, and bring it back to the Maven list if we can figure
out what's going on.


> [1] https://builds.apache.org/job/Accumulo-master-IT/
> [2] https://wiki.jenkins-ci.org/display/JENKINS/Thread+Dump+Action+Plugin
> [3] https://issues.apache.org/jira/browse/SUREFIRE-1193
>
>
>
> On Wed, Aug 31, 2016 at 3:00 AM, Christopher [via Maven] <
> ml-node+s40175n5879500...@n5.nabble.com> wrote:
>
> > tl;dr - A proposal for config independence for groups/excludeGroups
> > properties and some special keywords for ALL, NONE, and UNCATEGORIZED
> > groups.
> >
> > ***
> >
> > In the Apache Accumulo project, we're currently in process of trying to
> > make use of JUnit categories to separate different classes of tests.
> >
> > So, we're using the maven-surefire-plugin and maven-failsafe-plugin
> > configuration properties: groups, excludeGroups
> >
> > One thing we noticed was that the user property is the same for both
> > plugins. This is a problem, because one cannot pass in a system property
> > on
> > the command-line to affect one without affecting the other.
> >
> > I propose that maven-surefire-plugin and maven-failsafe-plugin deprecate
> > the existing groups/excludeGroups properties, and replace them with
> > tests.groups/tests.excludeGroups, and it.groups/it.excludeGroups. (This
> > should probably be done for other shared properties as well.)
> >
> > Users can simulate this by doing something like this:
> > ${it.groups}
> >
> > However, this may cause problems if the property is not defined I
> > haven't tested to be sure.
> >
> > ***
> >
> > That leads me to a question and a second proposal:
> > Is there a way to specify uncategorized test classes? Or all test
> classes?
> > Or none?
> >
> > If not, I would like to propose that some special keywords be created
> > which
> > can represent:
> > _ALL_, _NONE_, _UNCATEGORIZED_ (or similar)
> >
> > That way, users can do things like:
> > my.special.Category,_UNCATEGORIZED_
> > _NONE_
> > or
> > _NONE_
> > or
> > _ALL_
> >
> > These keywords may require some support from the underlying test
> > framework,
> > like JUnit, so I can understand if these keywords cannot happen.
> >
> > Even if the keywords cannot be made to work, I still think it'd be good
> to
> > deprecate-and-separate the properties for the two plugins, so they can be
> > controlled independently with user properties.
> >
> > Thanks.
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://maven.40175.n5.nabble.com/JUnit-categories-in-
> > surefire-failsafe-tp5879500.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
>

JUnit categories in surefire/failsafe

[Christopher]

tl;dr - A proposal for config independence for groups/excludeGroups
properties and some special keywords for ALL, NONE, and UNCATEGORIZED
groups.

***

In the Apache Accumulo project, we're currently in process of trying to
make use of JUnit categories to separate different classes of tests.

So, we're using the maven-surefire-plugin and maven-failsafe-plugin
configuration properties: groups, excludeGroups

One thing we noticed was that the user property is the same for both
plugins. This is a problem, because one cannot pass in a system property on
the command-line to affect one without affecting the other.

I propose that maven-surefire-plugin and maven-failsafe-plugin deprecate
the existing groups/excludeGroups properties, and replace them with
tests.groups/tests.excludeGroups, and it.groups/it.excludeGroups. (This
should probably be done for other shared properties as well.)

Users can simulate this by doing something like this:
${it.groups}

However, this may cause problems if the property is not defined I
haven't tested to be sure.

***

That leads me to a question and a second proposal:
Is there a way to specify uncategorized test classes? Or all test classes?
Or none?

If not, I would like to propose that some special keywords be created which
can represent:
_ALL_, _NONE_, _UNCATEGORIZED_ (or similar)

That way, users can do things like:
my.special.Category,_UNCATEGORIZED_
_NONE_
or
_NONE_
or
_ALL_

These keywords may require some support from the underlying test framework,
like JUnit, so I can understand if these keywords cannot happen.

Even if the keywords cannot be made to work, I still think it'd be good to
deprecate-and-separate the properties for the two plugins, so they can be
controlled independently with user properties.

Thanks.

Re: Profile Activation

[Christopher]

If there could be "AND" and "OR" primitives for profile activation
conditions, you could do something like:

   
 
   !profilea
 
 
   profilea
   !true
 
   

Sadly, this feature does not exist.

On Fri, Aug 12, 2016, 11:45 Karl Heinz Marbaise  wrote:

> Hi to all,
>
> I have the following profile:
>
>
>
>profile-not-value-true
>
>  
>profilea
>!true
>  
>
>
>  
>
>  com.soebes.maven.plugins
>  echo-maven-plugin
>  
>
>  initialize
>  
>echo
>  
>
>  
>  
>
>  profile not value true
>
>  
>
>  
>
>  
>
> So the question is: What would you expect you need to do to activate
> this profile?
>
> Currently this profile is activated cause if I don't define the property
> "profilea" at all it seemed to that Maven is assuming this means "not
> value 'true'" ?
>
> I have assumed it should be activated if the property exists which means
> giving it on command line like this:
>
> mvn -Dprofilea
>
>
>
> WDYT ?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: slf4j runtime dependency for plugin

[Christopher]

On Mon, Aug 15, 2016 at 2:37 AM Michael Osipov <micha...@apache.org> wrote:

> Am 2016-08-14 um 23:21 schrieb Christopher:
> > On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov <micha...@apache.org>
> wrote:
> >
> >> Am 2016-08-12 um 23:48 schrieb Christopher:
> >>> Hi,
> >>>
> >>> I use a plugin which has a runtime dependency on an slf4j
> implementation,
> >>> but the plugin itself is built without declaring one in its pom. (
> >>> https://github.com/koraktor/mavanagaiata/issues/43)
> >>>
> >>> In some versions of Maven, I get a warning about slf4j not finding an
> >>> implementation. In other versions, it is silent.
> >>>
> >>> Was an slf4j implementation provided in newer versions to the execution
> >> of
> >>> plugins?
> >>>
> >>> Will there be a multiple-binding conflict if the plugin itself provides
> >> one
> >>> of its own to get rid of the warning on certain versions of maven which
> >>> result in that warning (I didn't see one when I tried)?
> >>>
> >>> If there is a risk of a conflict, which implementation would be
> preferred
> >>> in order to converge on one provided by Maven?
> >>>
> >>> Is there another solution the plugin should seek?
> >>>
> >>> In general, what dependencies are plugins expected to provide, and what
> >>> dependencies are expected to be provided by Maven, and how are
> conflicts
> >>> resolved in the architecture?
> >>>
> >>> Feel free to comment on the GitHub issue directly, or here. I'll be
> >>> watching both.
> >>
> >> I will cite what I have written on Stack Overflow
> >> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
> >> holds true:
> >>
> >> You *never* provide a log implementation. The client application has to
> >> do so. Otherwhise this would be a violation of separation of concerns.
> >> Don't do any assumptions about an unknown client.
> >>
> >>
> > I agree with that sentiment...generally. But this is a maven plugin, so
> I'm
> > trying to figure out what Maven is going to provide it when it executes.
> If
> > it's not going to provide an implementation, then the plugin has to. If
> you
> > have answers to the specific questions I asked above, I think it might
> help.
>
> It should not matter to you what Maven provides. It will always provide
> some backend. Otherwise Maven won't be able to log itself.  Even if
> Maven would not provide anything. It is not your task to force some
> implementation. It is a several failure of the client to do so.
>
> Michael
>

That would make more sense to me if there were a universally agreed upon
logging API, and all clients were guaranteed to provide *some* backend for
that standard logging API. Unfortunately, no logging API seems to be
universal, and the one provided in Java itself is awful. I'm not even sure
what Maven uses underneath, and it may not use SLF4J at all (which means it
has no reason to provide an implementation).

This is actually a pretty unfortunate circumstance in the first place...
Maven plugins should only be logging to the provided Maven logger itself,
and the plugin shouldn't care what backend Maven is using for that logger. This
particular plugin is doing the right thing... using the Maven logger and
relying on Maven for the backend. Unfortunately, it seems the
org.eclipse.jgit dependency does its own logging, and that's outside this
plugin's control.

Until there is a universal logging framework, these heuristics about what
the "right" thing to do are not going to be perfect. Ideals like "rely on
the client to provide the implementation" aren't going to fully match
reality. Personally, I'd like to see an slf4j-like API make its way into
Java itself. Then, perhaps these kinds of issues wouldn't come up as often.

Re: slf4j runtime dependency for plugin

[Christopher]

On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov <micha...@apache.org> wrote:

> Am 2016-08-12 um 23:48 schrieb Christopher:
> > Hi,
> >
> > I use a plugin which has a runtime dependency on an slf4j implementation,
> > but the plugin itself is built without declaring one in its pom. (
> > https://github.com/koraktor/mavanagaiata/issues/43)
> >
> > In some versions of Maven, I get a warning about slf4j not finding an
> > implementation. In other versions, it is silent.
> >
> > Was an slf4j implementation provided in newer versions to the execution
> of
> > plugins?
> >
> > Will there be a multiple-binding conflict if the plugin itself provides
> one
> > of its own to get rid of the warning on certain versions of maven which
> > result in that warning (I didn't see one when I tried)?
> >
> > If there is a risk of a conflict, which implementation would be preferred
> > in order to converge on one provided by Maven?
> >
> > Is there another solution the plugin should seek?
> >
> > In general, what dependencies are plugins expected to provide, and what
> > dependencies are expected to be provided by Maven, and how are conflicts
> > resolved in the architecture?
> >
> > Feel free to comment on the GitHub issue directly, or here. I'll be
> > watching both.
>
> I will cite what I have written on Stack Overflow
> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
> holds true:
>
> You *never* provide a log implementation. The client application has to
> do so. Otherwhise this would be a violation of separation of concerns.
> Don't do any assumptions about an unknown client.
>
>
I agree with that sentiment...generally. But this is a maven plugin, so I'm
trying to figure out what Maven is going to provide it when it executes. If
it's not going to provide an implementation, then the plugin has to. If you
have answers to the specific questions I asked above, I think it might help.

slf4j runtime dependency for plugin

[Christopher]

Hi,

I use a plugin which has a runtime dependency on an slf4j implementation,
but the plugin itself is built without declaring one in its pom. (
https://github.com/koraktor/mavanagaiata/issues/43)

In some versions of Maven, I get a warning about slf4j not finding an
implementation. In other versions, it is silent.

Was an slf4j implementation provided in newer versions to the execution of
plugins?

Will there be a multiple-binding conflict if the plugin itself provides one
of its own to get rid of the warning on certain versions of maven which
result in that warning (I didn't see one when I tried)?

If there is a risk of a conflict, which implementation would be preferred
in order to converge on one provided by Maven?

Is there another solution the plugin should seek?

In general, what dependencies are plugins expected to provide, and what
dependencies are expected to be provided by Maven, and how are conflicts
resolved in the architecture?

Feel free to comment on the GitHub issue directly, or here. I'll be
watching both.

Thanks.

Re: opinions on MJAVADOC-451

[Christopher]

On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory <garydgreg...@gmail.com> wrote:

> On Aug 5, 2016 7:41 AM, "Benson Margulies" <bimargul...@gmail.com> wrote:
> >
> > On Fri, Aug 5, 2016 at 10:37 AM, Christopher <ctubb...@apache.org>
> 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.
>
> Why not add the ability to skip various (named) activities to maven itself?
>

That exists. It's called profiles... but it's very verbose in the POM. It's
much more pleasant to work with if the behavior of the individual plugin is
flexible through configuration.

A feature could be added to Maven to skip specific named executions of
plugins, I suppose... but that sounds like a feature that would require
some discussion and debate before showing up in some future version of
Maven. The proposal is something which could be done today, which would
work, regardless of the version of Maven you're using, and which is
consistent with similar configurable behavior in countless existing plugins.

Re: opinions on MJAVADOC-451

[Christopher]

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.

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

Re: Merging maven-release-plugin config

[Christopher]

For what it's worth, they are *not* equivalent:

The  element only applies to the release:perform goal,
not the release:prepare goal. , on the other hand gets used by
both goals.

Thus, the ASF parent has activated the apache-release profile on both
goals, and the Maven parent only activates it for the release:perform goal,
presumably to save on some additional work during the preparation step
(speculation) at the possible cost of delayed notification of problems
which might arise in executing the plugins in that profile.

On Sat, May 28, 2016 at 5:19 AM Hervé BOUTEMY  wrote:

> +1
>
> Regards,
>
> Hervé
>
> Le samedi 28 mai 2016 00:42:00 Michael Osipov a écrit :
> > Hi folks,
> >
> > I just have noticed that ASF Parent says:
> >
> > 
> >org.apache.maven.plugins
> >maven-release-plugin
> >2.5.3
> >
> >  ...
> >  -Papache-release ${arguments}
> >  ..
> >
> > 
> >
> > and Maven Parent:
> >
> > 
> >org.apache.maven.plugins
> >maven-release-plugin
> >
> >  ...
> >  apache-release
> >  ...
> >  ${arguments}
> >
> > 
> >
> > Both seem equivalent to me. it safe to remove those two properties from
> > Maven Parent?
> >
> > 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: SHA512 by default for GPG sigs

[Christopher]

Yes, that is correct. I'm referring to the ASF-wide parent pom.

If I understand the situation correctly, releases of that POM are managed
by the Maven PMC, but because of it's utility throughout the ASF, Hervé
Boutemy had commented on MPOM-118 that it should be brought to the
attention of a larger audience. This thread is the result of his
observation. :)

But there is no harm done. Thanks for providing an opportunity to clarify.

On Wed, May 18, 2016 at 3:26 PM Greg Trasuk <tras...@stratuscom.com> wrote:

> Whoops.  Sorry about that.
>
> Greg
>
> > On May 18, 2016, at 2:50 PM, Benson Margulies <bimargul...@gmail.com>
> wrote:
> >
> > 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 <tras...@stratuscom.com>
> 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 <ctubb...@apache.org> 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
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] ASF Parent POM Version 18 (take 2)

[Christopher]

On Sun, May 15, 2016 at 4:57 PM Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 16 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12332150=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheapache-1008/
>
> https://repository.apache.org/content/repositories/orgapacheapache-1008/org/apache/apache/18/apache-18-source-release.zip
>
> Changes since the last release:
>
> http://svn.apache.org/viewvc/maven/pom/tags/apache-18/pom.xml?r1=HEAD=1675930_format=h
>
> Source release checksum(s):
> apache-18-source-release.zip sha1: 4515e18322edd0b6fd28c31779abbdb72ee619cd
>
> Staging site:
> http://maven.apache.org/pom-archives/asf-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
+1 (non-binding)

Verified signatures and hashes and previewed changes from last RC. I did
notice that Hervé's key is pretty old and weak now (1024 DSA/2048 Elgamal),
and that the digest algorithm used for the signature was the
not-recommended SHA-1. I recommend future releases use SHA512 for the
digest algorithm [1], and Hervé think about transitioning to a stronger key
[2] (at the very least, update the existing key to prefer SHA512 when
signing [3]).

[1]: https://www.apache.org/dev/openpgp#sha1
[2]: https://www.apache.org/dev/openpgp#generate-key
[3]: https://www.apache.org/dev/openpgp#key-prefs

Re: [VOTE] ASF Parent POM Version 18

[Christopher]

On Tue, May 10, 2016 at 2:37 PM Michael Osipov <micha...@apache.org> wrote:

> Am 2016-05-10 um 20:04 schrieb Christopher:
> > On Tue, May 10, 2016 at 6:58 AM Michael Osipov <1983-01...@gmx.net>
> wrote:
> >
> >>
> >>
> >>> Gesendet: Montag, 09. Mai 2016 um 23:04 Uhr
> >>> Von: "Hervé BOUTEMY" <herve.bout...@free.fr>
> >>> An: "Maven Developers List" <dev@maven.apache.org>
> >>> Betreff: [VOTE] ASF Parent POM Version 18
> >>>
> >>> Hi,
> >>>
> >>> We solved 12 issues:
> >>>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12332150=Text
> >>>
> >>> Staging repo:
> >>>
> https://repository.apache.org/content/repositories/orgapacheapache-1007/
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapacheapache-1007/org/apache/apache/18/apache-18-source-release.zip
> >>>
> >>> Changes since the last release:
> >>>
> >>
> http://svn.apache.org/viewvc/maven/pom/tags/apache-18/pom.xml?r1=HEAD=1675930_format=h
> >>>
> >>> Source release checksum(s):
> >>> apache-18-source-release.zip sha1:
> >> e0a0b64bd092feb7b0f0eac9049ca6896951be9a
> >>>
> >>> Staging site:
> >>> http://maven.apache.org/pom-archives/asf-LATEST/
> >>>
> >>> Guide to testing staged releases:
> >>> http://maven.apache.org/guides/development/guide-testing-releases.html
> >>>
> >>> Vote open for 72 hours.
> >>
> >>
> >> -1, along with MPOM-106, MASSEMBLY should have been upgraded to 2.6. It
> is
> >> still at 2.5.5.
> >>
> >>
> > -0 (non-binding). I was also expecting 2.6 assembly
> > (https://issues.apache.org/jira/browse/MPOM-108)
>
> I relied on MPOM-106 to do the right thing...
>
> > Also, the scm section seems wrong for a release: all the URLs point to
> the
> > tag, but the actual  element is entirely missing.
>
> This one is redudant with Subversion. See
> https://maven.apache.org/pom.html#SCM
>
>
>
Okay, it's been awhile since I used maven-release-plugin with an svn, and I
couldn't remember how that section worked, and it just looked funny to me.
After looking back at an older Accumulo release from before we switched to
git, I can see it did the same thing. I should have checked before I said
anything. :)

Re: [VOTE] ASF Parent POM Version 18

[Christopher]

On Tue, May 10, 2016 at 6:58 AM Michael Osipov <1983-01...@gmx.net> wrote:

>
>
> > Gesendet: Montag, 09. Mai 2016 um 23:04 Uhr
> > Von: "Hervé BOUTEMY" 
> > An: "Maven Developers List" 
> > Betreff: [VOTE] ASF Parent POM Version 18
> >
> > Hi,
> >
> > We solved 12 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12332150=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapacheapache-1007/
> >
> https://repository.apache.org/content/repositories/orgapacheapache-1007/org/apache/apache/18/apache-18-source-release.zip
> >
> > Changes since the last release:
> >
> http://svn.apache.org/viewvc/maven/pom/tags/apache-18/pom.xml?r1=HEAD=1675930_format=h
> >
> > Source release checksum(s):
> > apache-18-source-release.zip sha1:
> e0a0b64bd092feb7b0f0eac9049ca6896951be9a
> >
> > Staging site:
> > http://maven.apache.org/pom-archives/asf-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
>
>
> -1, along with MPOM-106, MASSEMBLY should have been upgraded to 2.6. It is
> still at 2.5.5.
>
>
-0 (non-binding). I was also expecting 2.6 assembly
(https://issues.apache.org/jira/browse/MPOM-108)

Also, the scm section seems wrong for a release: all the URLs point to the
tag, but the actual  element is entirely missing.

I also found a few other little things:

https://issues.apache.org/jira/browse/MPOM-112
https://issues.apache.org/jira/browse/MPOM-113
https://issues.apache.org/jira/browse/MPOM-114
https://issues.apache.org/jira/browse/MPOM-115
https://issues.apache.org/jira/browse/MPOM-116
https://issues.apache.org/jira/browse/MPOM-117

Re: [VOTE] Release Apache Source Release Assembly Descriptor version 1.0.6

[Christopher]

+1 (non-binding)

On Mon, May 2, 2016 at 7:50 PM Hervé BOUTEMY  wrote:

> Hi,
>
> In preparation to Apache parent pom version 18, we need a little bugfix on
> Apache Source Release Assembly Descriptor to fix MPOM-106
>
> We solved 1 issue:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314621=12329542=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1006/
>
> https://repository.apache.org/content/repositories/orgapacheapache-1006/org/apache/apache/resources/apache-source-release-assembly-descriptor/1.0.6/apache-source-release-assembly-descriptor-1.0.6-source-release.zip
>
> Source release checksum(s):
> apache-source-release-assembly-descriptor-1.0.6-source-release.zip sha1:
> d2f887c6af52f78927819914a60680aef2ce01c2
>
> 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
>
>

Re: Question regarding maven build on RHEL 7 failing for Apache Phoenix 4.6-HBase-1.1

[Christopher]

You should try `mvn clean install -DskipTests`

Putting package in there is redundant (in most cases), as install is later
in the maven build lifecycle and will include the package phase, and it's
probably triggering a second lifecycle execution (only up to the package
phase) after it goes through the full lifecycle (up through install phase).

See:
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

That said, I just tried `mvn clean verify -DskipTests` (because I don't
want to install into my local maven repo right now), on CentOS 7 x86_64
from the HEAD of the master branch (45a9d67), and it built fine.

On Thu, Feb 18, 2016 at 6:09 PM Nidhi Marwaha  wrote:

> Hi,
>
> I am trying to build Apache Phoenix on RHEL 7. The build fails on
> *Phoenix-Pherf *
>
> The goals and options for build is -
>
> *clean install package -DskipTests*
>
> *Java version - *java-1.7.0-openjdk-1.7.0.75
>
> *16:09:22* [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.5.2:single
> (make-dependency-jar) on project phoenix-pherf: Failed to create
> assembly: Error creating assembly archive jar-with-dependencies:
> Problem creating jar:
>
> jar:file:/a/workspace/Phoenix-4.6-HBase-1.2-ppc64le/phoenix-pherf/target/phoenix-pherf-4.6.1-HBase-1.1-SNAPSHOT.jar!/org/apache/phoenix/pherf/configuration/Column.class:
> JAR entry org/apache/phoenix/pherf/configuration/Column.class not
> found in
> /a/workspace/Phoenix-4.6-HBase-1.2-ppc64le/phoenix-pherf/target/phoenix-pherf-4.6.1-HBase-1.1-SNAPSHOT.jar
> -> [Help 1
>
> I downloaded phoenix-pherf-4.6.1-HBase-1.1-SNAPSHOT.jar and extracted
> and I see the class file it is complaining about; they do exist.
>
> *The build works fine on RHEL 6. **The issue is only for RHEL 7.*
>
>
> Has anyone tried to build on RHEL 7? Any idea on what might be causing
> the error ?
>
>
> Thanks,
>
> Nidhi
>

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

[Christopher]

On Tue, Jan 26, 2016 at 8:29 AM Paul Benedict  wrote:

> I'm more curious of the growth of "skip" parameters of plugins. Do they
> exist really to skip the plugin, or are they really representative of the
> desire to skip an entire phase?
>
> [snip]

I frequently disable a subset of plugins which run at the "package"
(usually supplemental artifacts, like javadoc jars or source jars) or
"verify" phase (like findbugs or checkstyle), for testing, while leaving
others enabled.

While I can imagine it would be useful to skip an entire phase in some
situations, I've never encountered the desire to do so. It might be an
interesting feature to have in the toolkit, though.

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

[Christopher]

On Mon, Jan 25, 2016 at 2:51 PM, Robert Scholte  wrote:
> Hi,
>
> I really wonder why it is useful to add a skip-parameter to the packaging
> plugin? The goal for every Maven project is to end up with some (packaged)
> artifact, right?
> A skip-parameter because a lot of other plugins have it as well is IMHO not
> a good reason, so what would be a valid usecase here?
>

I would argue that it's useful to be able to skip over arbitrary
plugins, regardless of what they do, simply for testing other parts of
the build.

-
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

[Christopher]

+1 to at least 1.7

However, since 1.7 is EOL, I do think it also makes sense to default
to 1.8, since it's the earliest version still getting public security
updates, and therefore it's reasonable that most people should be
using that version if possible. It's a trivial matter to configure the
plugin for an earlier version if the software needs to be built to
support a system that's not updated. These systems can (and probably
already are) using older versions of this plugin anyway, so changing
the default in newer versions isn't likely to affect them.

But, at the very least, 1.7 is a big +1, incremental improvement to the default.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Fri, Nov 6, 2015 at 2:04 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> +1 for 1.7.
>
> Gary
>
> On Fri, Nov 6, 2015 at 4:56 AM, Attila-Mihály Balázs <dify@gmail.com>
> 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
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Re: [INVOKER] suppress logs during install goal

[Christopher]

Rather than a general solution about modifying the logger, I wonder if
there's just something the invoker:install goal could do to resolve /
copy these differently, so that it can have an option to be less
verbose in that specific mojo.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Fri, Jun 12, 2015 at 12:33 PM, Robert Scholte rfscho...@apache.org wrote:
 I still have this wish to be able to change the logging for one specific
 plugin from commandline, but that's still not possible (there are already
 several threads about it on this dev-list).
 The reason is that on startup the decision has already been made with
 LoggerFactory to use. You can't change the logging level during runtime for
 already instantiated classes, in this case some Aether specific classes.

 So up until now there are just 2 options: define the preferred logging
 levels up front or start a new JVM with the preferred logging levels. The
 last option explains why the maven-invoker-plugin can have a different
 logging level compared to the started Maven execution.

 thanks,
 Robert

 Op Fri, 12 Jun 2015 00:06:09 +0200 schreef Christopher
 ctubb...@apache.org:


 Hi,

 Thanks for the suggestion. I'm not sure it's sufficient, though,
 because (assuming that works) it seems like it would also suppress
 messages I want to see. I really only want it to suppress the messages
 during the invoker:install task, and not any other time.

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Wed, Jun 10, 2015 at 3:16 PM, Robert Scholte rfscho...@apache.org
 wrote:

 Hi,

 AFAIK it is Aether which is responsible for these messages.
 If you use M3.1.1 or above, you can change the logging of
 conf/logging/simplelogger.properties

 Based on http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html I
 would
 expect this to work:
 org.slf4j.simpleLogger.log.org.sonatype.aether = warn
 org.slf4j.simpleLogger.log.org.eclipse.aether = warn

 Since this logging is still done by the main executor of Maven (and not
 by
 the forked executor from the invoker-plugin) this seems to be your best
 option.

 thanks,
 Robert

 Op Wed, 10 Jun 2015 02:08:01 +0200 schreef Christopher
 ctubb...@apache.org:

 Hi,

 I have a maven plugin which has some ITs which are executed using the
 recommended way using the maven-invoker-plugin. However, the
 invoker:install goal always spams my build server's logs with
 Downloading messages, copying from my local repo to a location I
 specify under target/.

 I absolutely cannot figure out a way to suppress this output. It is
 spammy, and happens every build (because it's not going to the local
 repo, for the reasons described in the plugin docs). And, I really
 don't care that it copied something from my local repo to this
 directory in target/ being logged at the INFO level.

 What's the best solution to work towards? I don't think there is one
 now, but if one were to be created, what would it look like?

 The ideas I thought of so far:

 1. add silenttrue/silent option on the install goal
 2. add logfilename/log option on the install goal
 3. some manipulation of the logger configuration to hide logs from this
 plugin
 4. since this is a common task before running ITs for plugins, it
 could be baked in to the integration-test goal, and automatically
 suppressed

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

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



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


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


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


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

Re: [INVOKER] suppress logs during install goal

[Christopher]

Hi,

Thanks for the suggestion. I'm not sure it's sufficient, though,
because (assuming that works) it seems like it would also suppress
messages I want to see. I really only want it to suppress the messages
during the invoker:install task, and not any other time.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Wed, Jun 10, 2015 at 3:16 PM, Robert Scholte rfscho...@apache.org wrote:
 Hi,

 AFAIK it is Aether which is responsible for these messages.
 If you use M3.1.1 or above, you can change the logging of
 conf/logging/simplelogger.properties

 Based on http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html I would
 expect this to work:
 org.slf4j.simpleLogger.log.org.sonatype.aether = warn
 org.slf4j.simpleLogger.log.org.eclipse.aether = warn

 Since this logging is still done by the main executor of Maven (and not by
 the forked executor from the invoker-plugin) this seems to be your best
 option.

 thanks,
 Robert

 Op Wed, 10 Jun 2015 02:08:01 +0200 schreef Christopher
 ctubb...@apache.org:

 Hi,

 I have a maven plugin which has some ITs which are executed using the
 recommended way using the maven-invoker-plugin. However, the
 invoker:install goal always spams my build server's logs with
 Downloading messages, copying from my local repo to a location I
 specify under target/.

 I absolutely cannot figure out a way to suppress this output. It is
 spammy, and happens every build (because it's not going to the local
 repo, for the reasons described in the plugin docs). And, I really
 don't care that it copied something from my local repo to this
 directory in target/ being logged at the INFO level.

 What's the best solution to work towards? I don't think there is one
 now, but if one were to be created, what would it look like?

 The ideas I thought of so far:

 1. add silenttrue/silent option on the install goal
 2. add logfilename/log option on the install goal
 3. some manipulation of the logger configuration to hide logs from this
 plugin
 4. since this is a common task before running ITs for plugins, it
 could be baked in to the integration-test goal, and automatically
 suppressed

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 -
 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

[INVOKER] suppress logs during install goal

[Christopher]

Hi,

I have a maven plugin which has some ITs which are executed using the
recommended way using the maven-invoker-plugin. However, the
invoker:install goal always spams my build server's logs with
Downloading messages, copying from my local repo to a location I
specify under target/.

I absolutely cannot figure out a way to suppress this output. It is
spammy, and happens every build (because it's not going to the local
repo, for the reasons described in the plugin docs). And, I really
don't care that it copied something from my local repo to this
directory in target/ being logged at the INFO level.

What's the best solution to work towards? I don't think there is one
now, but if one were to be created, what would it look like?

The ideas I thought of so far:

1. add silenttrue/silent option on the install goal
2. add logfilename/log option on the install goal
3. some manipulation of the logger configuration to hide logs from this plugin
4. since this is a common task before running ITs for plugins, it
could be baked in to the integration-test goal, and automatically
suppressed

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

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

Re: Full migration to Git

[Christopher]

+1

On Fri, May 29, 2015, 07:23 Jason van Zyl ja...@takari.io wrote:

 I think it's time for a full migration of all our repositories to Git. I
 just see the email with Dennis struggling to merge a simple pull request
 and I think it's just time to switch completely. I think someone already
 started a list and we should just move through it. Personally I find SVN is
 just a huge hindrance at this point, especially for contributors.

 Thanks,

 Jason

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

 The most dangerous risk: spending your life not doing what you want on the
 bet you can buy yourself freedom to do it later.

  -- Randy Komisar












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

Re: Feedback wanted on Checktyle plugin ruleset docs

[Christopher]

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

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

 Hi,

 I'm trying to visualize which version of the Checkstyle plugin
 includes which predefined rulesets. There's are 3 alternatives for you
 to look at here:

 https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/config/index.html

 Please let me know which alternative you think is the most easy to
 understand.

 --
 Dennis Lundberg

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

Re: [VOTE] Release Apache Maven Fluido Skin Version 1.4

[Christopher]

Isn't it generally understood that releases are by majority vote? Thus,
clarification seems unnecessary. -1 only means veto under consensus voting,
not majority voting. Right?

On Tue, Apr 28, 2015, 07:45 Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Karl,

 You are the release manager for this vote so you get to decide what to do.
 My point was that the -1 cannot stop a release, if the release manager gets
 3x+1(binding) then they can release irrespective of the number of -1's...
 though I suspect that the PMC would frown on a release manager who
 repeatedly cut releases where there was a majority of -1's... and if the
 PMC didn't frown appropriately then the board might frown on the PMC ;-)

 But none the less, on release votes if you are casting a -1 it is better to
 either cast a -0.99 or advertise the fact that it is not a veto, e.g.
 -1 (non-veto) so that the rest of the wider community is aware that this is
 not a veto on the release rather a problem with the release that the
 release manager needs to decide the severity of.

 On 27 April 2015 at 20:23, Karl Heinz Marbaise khmarba...@gmx.de wrote:

  Hi Stephen,
 
  I'm fully aware that no vetos allowed apart from that the suggestions
 made
  by Michael are better than my implementation and i have decided to drop
 the
  release VOTE anywaycause a much better implementation does exists...
 
  Kind regards
  Karl Heinz Marbaise
  On 4/27/15 9:14 PM, Stephen Connolly wrote:
 
  Remember there are no vetos allowed on release votes
 
  On Monday, 27 April 2015, Michael Osipov micha...@apache.org wrote:
 
   Am 2015-04-25 um 17:05 schrieb Karl Heinz Marbaise:
 
   Hi,
 
  We solved 9 issues:
 
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926version=12331574
 
 
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1184
 
 
 
 
 https://repository.apache.org/content/repositories/maven-1184/org/apache/maven/skins/maven-fluido-skin/1.4/maven-fluido-skin-1.4-source-release.zip
 
 
  Source release checksum(s):
  maven-fluido-skin-1.4-source-release.zip sha1:
  f4575cc56f2296b35e4404fb6f64e41eccfb1515
 
  Staging site:
  http://maven.apache.org/skins-archives/maven-fluido-skin-LATEST/
 
  Guide to testing staged releases:
 
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
 
  -1 because one cannot follow the fix made in MSKINS-110.
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 

Re: [VOTE] ASF Parent POM Version 17

[Christopher]

+1 (non-binding)

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Mon, Apr 27, 2015 at 3:58 AM, Stevo Slavić ssla...@gmail.com wrote:
 +1 (non-binding)

 On Fri, Apr 24, 2015 at 9:08 PM, Karl Heinz Marbaise khmarba...@gmx.de
 wrote:

 Hi,

 We solved 10 issues:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250version=12329009

 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheapache-1005


 https://repository.apache.org/content/repositories/orgapacheapache-1005/org/apache/apache/17/apache-17-source-release.zip

 Source release checksum(s):
 apache-17-source-release.zip sha1: 640e27bb2ae3b77962ccdf2d82fe6628a83894be

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

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

 Changes since last release:

 http://svn.apache.org/viewvc/maven/pom/tags/apache-17/pom.xml?r1=HEADr2=1639452diff_format=h


 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: Timeline for ASF parent pom 17

[Christopher]

Yes, thank you.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Fri, Apr 10, 2015 at 4:07 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 Hi,

 I have fixed this two issues...i will take a look the next days if i can do
 some more things...

 And hopefully i will start a release VOTE next week ?

 Would that help?


 Kind regards
 Karl Heinz Marbaise


 On 4/10/15 12:12 AM, Christopher wrote:

 +1

 MPOM-47 is extremely trivial. It just updates the assembly descriptor
 dependency from 1.0.4 to 1.0.5 so source-release assemblies have the
 option of creating source-release assemblies which are tar.gz only (in
 addition to the existing zip only and zip+tar.gz options).

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Thu, Apr 9, 2015 at 5:55 PM, Sean Busbey bus...@cloudera.com wrote:

 Hiya!

 The Accumulo project would like to update to ASF-17 for our next release
 so
 we can get MPOM-69 and MPOM-47. We'd like to have our release out soon;
 we
 plan to start release candidates in the next couple of weeks.

 The ASF-17 release has 2 remaining open tickets, both of which have
 patches
 available. Can we get these reviewed and a release started?

 --
 Sean


 -
 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: running net start fails from Maven but succeeds from Ant

[Hahn, Christopher (SAN DIEGO)]

I appreciate the tenacity!

Look earlier in the threadI have a build.xml that
defined the restartora target.  

It runs fine when called from ant on the command line,
but fails when called out in the pom (also pasted in below)

Any clues appreciated.

Chris

-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org] 
Sent: Tuesday, November 09, 2010 10:29 PM
To: Maven Developers List
Subject: Re: running net start fails from Maven but succeeds from Ant

On 2010-11-09 22:58, Hahn, Christopher (SAN DIEGO) wrote:
  Hello,
 
 I will discuss upgrading our antrun plugin with my group,
 but some dependencies seem to be up to date
 
 Thank you for taking the time.
 
 Chris
 
 P.S. Here is the plugin config:

Hmm, I don't see any execution in here that tells us what Ant code you
are invoking. Do you embed the code int the POM or are you referring to
an external build.xml file?

  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-antrun-plugin/artifactId
 version1.2/version
 dependencies
   dependency
 groupIdant/groupId
 artifactIdant-nodeps/artifactId
 version1.6.5/version
   /dependency
   !-- For populating version files Could probably be
replaced by xmltask --
   dependency
 groupIdjakarta-regexp/groupId
 artifactIdjakarta-regexp/artifactId
 version1.4/version
   /dependency
   dependency
 groupIdant/groupId
 artifactIdant-jakarta-regexp/artifactId
 version1.6.1/version
   /dependency
   dependency
 groupIdcom.sun/groupId
 artifactIdtools/artifactId
 version1.5.0/version
 scopesystem/scope
 systemPath${java.home}/../lib/tools.jar/systemPath
   /dependency
   dependency
 !-- For codesigning loop --
 groupIdant-contrib/groupId
 artifactIdant-contrib/artifactId
 version1.0b3/version
   /dependency
   dependency
 !-- For xslt task --
 groupIdant/groupId
 artifactIdant-trax/artifactId
 version1.6.5/version
   /dependency
   dependency
 !-- For XSLT 2.0 transform in xslt task --
 groupIdnet.sf.saxon/groupId
 artifactIdsaxon/artifactId
 version8.7/version
   /dependency
 /dependencies
   /plugin
 
 -Original Message-
 From: Dennis Lundberg [mailto:denn...@apache.org] 
 Sent: Tuesday, November 09, 2010 11:49 AM
 To: Maven Developers List
 Subject: Re: running net start fails from Maven but succeeds from Ant
 
 On 2010-11-09 20:23, Hahn, Christopher (SAN DIEGO) wrote:
 Hi,

 Thank you for getting back to me.

 I am seeing version 1.2 of the plugin.
 
 This is rather old. The latest version is 1.6. Please try that one.
 
 The weird thing is that the ant I used (1.8) was only installed,
 by me, in order to drive the ant only command line test.

 I could not find an ant install on this box, and am thinking
 that Maven is using its own plugins to run this within Maven.
 
 The Maven plugin has its own internal copy of Ant. It doesn't use the
 one that you installed.
 
 what seems odd to me is that I am using the simplest aspects
 of this capability.  ...i.e. a straight exec with args.

 no conditionals or such.
 
 What does your plugin config look like?
 

 Thanks again,

 Chris

 -Original Message-
 From: Dennis Lundberg [mailto:denn...@apache.org] 
 Sent: Tuesday, November 09, 2010 11:04 AM
 To: Maven Developers List
 Subject: Re: running net start fails from Maven but succeeds from Ant

 Hi

 I assume that you are using the Maven AntRun Plugin to run the snippet,
 but you didn't tell us which version of the plugin you are using.
 Different versions of the plugin uses/supports different versions of Ant.

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

 On 2010-11-09 19:50, Hahn, Christopher (SAN DIEGO) wrote:
 Hello all,

  

 I am looking into why an Ant task is failing from Maven, but succeeding

 when called directly using ant.

  

 We have in a build.xml this block:

 ===

   target name=restartora

 exec executable=C:/Windows/system32/net.exe  failonerror=false

   arg line=stop OracleServiceORCL/

 /exec

 exec executable=C:/Windows/system32/net.exe  failonerror=true

   arg line=start OracleServiceORCL/

 /exec

   /target

 ===

  

 I added this target as a dependency to an oracle load target and

 am getting this error:

 ===

 [concat] restartora:
 [concat] [INFO]
 
 [concat] [ERROR] BUILD ERROR
 [concat] [INFO

Upgrading maven-assembly-plugin

[Hahn, Christopher (SAN DIEGO)]

Hello,

Yesterday I was asked to upgrade the version of maven-assembly-plugin
in our local repository.

I settled on the 2.2 release, change the version in my toplevel pom to this 
value,
and ran the command I expected to handle this for me.

Output:
===
C:\depot\SM\9.20\9.21mvn -N
[INFO] Scanning for projects...
[INFO] 
[INFO] Building Service Manager
[INFO]task-segment: [install]
[INFO] 
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.2/maven-assembly-plugin-2.2.pom
[WARNING] Unable to get resource 
'org.apache.maven.plugins:maven-assembly-plugin:pom:2.2' from repository 
central (http://repo1.maven.org/maven2): Error transferring file: Connection 
timed out: connec
t
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.2/maven-assembly-plugin-2.2.pom
[WARNING] Unable to get resource 
'org.apache.maven.plugins:maven-assembly-plugin:pom:2.2' from repository 
central (http://repo1.maven.org/maven2): Error transferring file: Connection 
timed out: connec
t
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error building POM (may not be this project's POM).


Project ID: org.apache.maven.plugins:maven-assembly-plugin

Reason: POM 'org.apache.maven.plugins:maven-assembly-plugin' not found in 
repository: Unable to download the artifact from any repository

  org.apache.maven.plugins:maven-assembly-plugin:pom:2.2

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

 for project org.apache.maven.plugins:maven-assembly-plugin


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 43 seconds
[INFO] Finished at: Wed Nov 10 10:37:26 PST 2010
[INFO] Final Memory: 6M/16M
[INFO] 
===

Now, I paste the path used:
   
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.2/
into a browser and I see the needed files without problem.

I did not see how to fix this, and so I thought to manually do the install.  I 
downloaded
the jar file and the pom, and ran an install command:
===
C:\depot\SM\9.20\9.21mvn install:install-file -f 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.2/maven-assembly-plugin-2.2.pom
 -Dfile=c:/ACM_Mirror/tasks/000_AAA__cur
rent/0055_Maven_Upgrade/maven-assembly-plugin-2.2.jar 
-DgroupId=org.apache.maven.plugins -DartifactId=maven-assembly-plugin 
-Dversion=2.2 -Dpackaging=jar -DlocalRepositoryPath=http://servicemanager.la
bs.peregrine.com/nexus/content/groups/servicemanager-devel/
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'install'.
[INFO] 
[INFO] Building Maven Default Project
[INFO]task-segment: [install:install-file] (aggregator-style)
[INFO] 
[INFO] [install:install-file {execution: default-cli}]
[INFO] Installing 
c:\ACM_Mirror\tasks\000_AAA__current\0055_Maven_Upgrade\maven-assembly-plugin-2.2.jar
 to 
C:\Users\hahnch\.m2\repository\org\apache\maven\plugins\maven-assembly-plugin\2.2\maven-assem
bly-plugin-2.2.jar
[INFO] 
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time:  1 second
[INFO] Finished at: Wed Nov 10 10:35:41 PST 2010
[INFO] Final Memory: 3M/15M
[INFO] 
===

As you see, that worked fine, but only installed the artifact to my local 
repository.

After running the install command above, I thought to run mvn -N deploy but it
keeps trying to reach the official Maven server, and failing.

Any pointers appreciated,

Chris

P.S. When working from command line, I tried setting HTTP_PROXY and unsetting 
it too.
My browser can see the files, so the URL and connectivity do not seem to be the 
problem.



[cid:image001.png@01CB80C3.A70546B0]

Christopher Hahn
The Dude
Software Production Engineering
RD Services, Hewlett-Packard
Phone: 858-655-4096
Cell: 619-630-9791
ch...@hp.commailto:christopher.h...@hp.com

Visit our SPE Portalhttp://teams5

RE: RE: running net start fails from Maven but succeeds from Ant

[Hahn, Christopher (SAN DIEGO)]

Ah, yes, the env is so often the issue (i.e. cron)

I will think about this.

Thank you for taking the time.

Chris

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Wednesday, November 10, 2010 3:06 PM
To: Maven Developers List
Subject: Re: RE: running net start fails from Maven but succeeds from Ant

Well I've seen differences in the environment that gets passed from maven to
ant versus running ant directly.
.. And to further complicate this, the environment that ant gets is
different again when in a forked maven  eg during release: prepare

- Stephen

---
Sent from my Android phone, so random spelling mistakes are a direct result
of using swype to type on the screen

On 10 Nov 2010 16:49, Hahn, Christopher (SAN DIEGO) 
christopher.h...@hp.com wrote:

I appreciate the tenacity!

Look earlier in the threadI have a build.xml that
defined the restartora target.

It runs fine when called from ant on the command line,
but fails when called out in the pom (also pasted in below)

Any clues appreciated.


Chris

-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org]

Sent: Tuesday, November 09, 2010 10:29 PM
To: Maven Developers List
Subject: Re: running net start f...

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

RE: running net start fails from Maven but succeeds from Ant

[Hahn, Christopher (SAN DIEGO)]

Hi,

Thank you for getting back to me.

I am seeing version 1.2 of the plugin.

The weird thing is that the ant I used (1.8) was only installed,
by me, in order to drive the ant only command line test.

I could not find an ant install on this box, and am thinking
that Maven is using its own plugins to run this within Maven.

what seems odd to me is that I am using the simplest aspects
of this capability.  ...i.e. a straight exec with args.

no conditionals or such.

Thanks again,

Chris

-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org] 
Sent: Tuesday, November 09, 2010 11:04 AM
To: Maven Developers List
Subject: Re: running net start fails from Maven but succeeds from Ant

Hi

I assume that you are using the Maven AntRun Plugin to run the snippet,
but you didn't tell us which version of the plugin you are using.
Different versions of the plugin uses/supports different versions of Ant.

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

On 2010-11-09 19:50, Hahn, Christopher (SAN DIEGO) wrote:
 Hello all,
 
  
 
 I am looking into why an Ant task is failing from Maven, but succeeding
 
 when called directly using ant.
 
  
 
 We have in a build.xml this block:
 
 ===
 
   target name=restartora
 
 exec executable=C:/Windows/system32/net.exe  failonerror=false
 
   arg line=stop OracleServiceORCL/
 
 /exec
 
 exec executable=C:/Windows/system32/net.exe  failonerror=true
 
   arg line=start OracleServiceORCL/
 
 /exec
 
   /target
 
 ===
 
  
 
 I added this target as a dependency to an oracle load target and
 
 am getting this error:
 
 ===
 
 [concat] restartora:
 [concat] [INFO]
 
 [concat] [ERROR] BUILD ERROR
 [concat] [INFO]
 
 [concat] [INFO] An Ant BuildException has occured: The following error
 occurred while executing this line:
 [concat] SNIP/build.xml:121: Execute failed: java.io.IOException:
 Cannot run program C:/Windows/system32/net.exe (in directory
 SNIP): error=2, No such file or directory
 [concat] [INFO]
 
 
 ===
 
  
 
 However, when run from the command line using Ant, I see:
 
 ===
 
 D:\SNIPd:\ant\apache-ant-1.8.0\bin\ant.bat -f build.xml restartora
 
 Buildfile: D:\SNIP\build.xml
 
  
 
 restartora:
 
  [exec] The OracleServiceORCL service is stopping...
 
  [exec] The OracleServiceORCL service was stopped successfully.
 
  [exec]
 
  [exec] The OracleServiceORCL service is starting
 
  [exec] The OracleServiceORCL service was started successfully.
 
  [exec]
 
  
 
 BUILD SUCCESSFUL
 
 Total time: 30 seconds
 
 D:\ SNIP
 
 ===
 
  
 
 I fully qualified the references, and so do not think that this is
 
 an environment issue(but this is still what I suspect, as my
 
 Ant might be too-much newer than my Maven)
 
  
 
 I am using:
 
 ===
 
 D:\p4\SM\7.10\7.11\server\test\smsetupset MAVEN_OPTS=-Xmx1024m -Xms128m
 
 Maven version: 2.0.10
 
 Java version: 1.5.0_19
 
 OS name: windows 2003 version: 5.2 arch: x86 Family: windows
 
 ===
 
  
 
 Any kicks in the head appreciated,
 
  
 
 Chris
 
  
 
 
 
 cid:image001.png@01CAF080.AD65F1E0
 
   
 
 *Christopher Hahn*
 The Dude
 
 Software Production Engineering
 RD Services, Hewlett-Packard
 Phone: 858-655-4096
 Cell: 619-630-9791
 ch...@hp.com mailto:christopher.h...@hp.com
 
  
 
 */Visit our SPE Portal/*
 http://teams5.sharepoint.hp.com/teams/SPE/default.aspx*//*
 
 
 
  
 
  
 


-- 
Dennis Lundberg

-
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: running net start fails from Maven but succeeds from Ant

[Hahn, Christopher (SAN DIEGO)]

 Hello,

I will discuss upgrading our antrun plugin with my group,
but some dependencies seem to be up to date

Thank you for taking the time.

Chris

P.S. Here is the plugin config:

 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
version1.2/version
dependencies
  dependency
groupIdant/groupId
artifactIdant-nodeps/artifactId
version1.6.5/version
  /dependency
  !-- For populating version files Could probably be
   replaced by xmltask --
  dependency
groupIdjakarta-regexp/groupId
artifactIdjakarta-regexp/artifactId
version1.4/version
  /dependency
  dependency
groupIdant/groupId
artifactIdant-jakarta-regexp/artifactId
version1.6.1/version
  /dependency
  dependency
groupIdcom.sun/groupId
artifactIdtools/artifactId
version1.5.0/version
scopesystem/scope
systemPath${java.home}/../lib/tools.jar/systemPath
  /dependency
  dependency
!-- For codesigning loop --
groupIdant-contrib/groupId
artifactIdant-contrib/artifactId
version1.0b3/version
  /dependency
  dependency
!-- For xslt task --
groupIdant/groupId
artifactIdant-trax/artifactId
version1.6.5/version
  /dependency
  dependency
!-- For XSLT 2.0 transform in xslt task --
groupIdnet.sf.saxon/groupId
artifactIdsaxon/artifactId
version8.7/version
  /dependency
/dependencies
  /plugin

-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org] 
Sent: Tuesday, November 09, 2010 11:49 AM
To: Maven Developers List
Subject: Re: running net start fails from Maven but succeeds from Ant

On 2010-11-09 20:23, Hahn, Christopher (SAN DIEGO) wrote:
 Hi,
 
 Thank you for getting back to me.
 
 I am seeing version 1.2 of the plugin.

This is rather old. The latest version is 1.6. Please try that one.

 The weird thing is that the ant I used (1.8) was only installed,
 by me, in order to drive the ant only command line test.
 
 I could not find an ant install on this box, and am thinking
 that Maven is using its own plugins to run this within Maven.

The Maven plugin has its own internal copy of Ant. It doesn't use the
one that you installed.

 what seems odd to me is that I am using the simplest aspects
 of this capability.  ...i.e. a straight exec with args.
 
 no conditionals or such.

What does your plugin config look like?

 
 Thanks again,
 
 Chris
 
 -Original Message-
 From: Dennis Lundberg [mailto:denn...@apache.org] 
 Sent: Tuesday, November 09, 2010 11:04 AM
 To: Maven Developers List
 Subject: Re: running net start fails from Maven but succeeds from Ant
 
 Hi
 
 I assume that you are using the Maven AntRun Plugin to run the snippet,
 but you didn't tell us which version of the plugin you are using.
 Different versions of the plugin uses/supports different versions of Ant.
 
 http://maven.apache.org/plugins/maven-antrun-plugin/
 
 On 2010-11-09 19:50, Hahn, Christopher (SAN DIEGO) wrote:
 Hello all,

  

 I am looking into why an Ant task is failing from Maven, but succeeding

 when called directly using ant.

  

 We have in a build.xml this block:

 ===

   target name=restartora

 exec executable=C:/Windows/system32/net.exe  failonerror=false

   arg line=stop OracleServiceORCL/

 /exec

 exec executable=C:/Windows/system32/net.exe  failonerror=true

   arg line=start OracleServiceORCL/

 /exec

   /target

 ===

  

 I added this target as a dependency to an oracle load target and

 am getting this error:

 ===

 [concat] restartora:
 [concat] [INFO]
 
 [concat] [ERROR] BUILD ERROR
 [concat] [INFO]
 
 [concat] [INFO] An Ant BuildException has occured: The following error
 occurred while executing this line:
 [concat] SNIP/build.xml:121: Execute failed: java.io.IOException:
 Cannot run program C:/Windows/system32/net.exe (in directory
 SNIP): error=2, No such file or directory
 [concat] [INFO]
 

 ===

  

 However, when run from the command line using Ant, I see:

 ===

 D:\SNIPd:\ant\apache-ant-1.8.0\bin\ant.bat -f build.xml restartora

 Buildfile: D:\SNIP\build.xml

  

 restartora:

  [exec] The OracleServiceORCL service is stopping

Developed new maven plugin for Jlint

[Christopher Moraes]

Hi,
I have developed a maven plugin for Jlint 3.1 and want to contribute the
plugin code back to the maven project.  I've gone through the maven
developer documentation, but somehow cannot find instruction related to
contributing plugin source code.

Can someone please point me to any instructions related to this.

Thanks and regards,
Chris

pde build with maven

[Christopher Klewes]

Hi, i want to setup my rcp project with a maven build. so first i want 
to build succesfully the example from the pde-maven-plugin site.


i started by downloading the following eclipse sdk and delta pack:
- eclipse-3.4.1-delta-pack.zip
- eclipse-RCP-SDK-3.4.1-win32.zip

i read through the examples from pde-maven-plugin mojo and found a 
tutorial that builds a product.


this tutorial can be found here:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/pde-maven-plugin/

i downloaded this one: 
pde-maven-plugin-1.0-20080304.235354-2-tutorials.zip (if you want an 
SSCCE (http://pscode.org/sscce.html))


after i imported the project to my eclipse ide i have done som changes 
to build.properties and pom.xml to ensure the paths are well formed. 
(the name of the plugin is: test.pde_maven_plugin.simple_application)


now i tried the pde build to be sure its running without maven:

1) launch the application (SUCCESSFUL)
2) launch the product (SUCCESSFUL)
3) export as product and launch (SUCCESSFUL)

everything works fine! now i tried to do the maven install, but this failed:

BUILD FAILED
D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v20080604\scripts\productBuild\productBuild.xml:25: 
The following error occurred while executing this line:
D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v20080604\scripts\productBuild\productBuild.xml:53: 
Unable to find plug-in: test.pde_maven_plugin.simple_application. Please 
check the error log for more details.


as you can see, the pde build (i think) can't found the application i 
want to export, it seems that maven doesn't calls the pde build for the 
application first, it assumes that the plugin has already be there? if i 
change the maven packaging to jar, do the install, copy this jar to my 
target.env into plugins change packaging back to zip, do the install 
again. everything runs fine, but this isn't a great solutions or? in my 
pov i think this should be done by pde build? please correct me if i am 
wrong if you need more informartions just let me know -- or if you got 
time have a look inside the maven-pde-plugin tutorial.


thank you
chris

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

[jira] Commented: (MNG-1819) StringIndexOutOfBoundsException when running maven

[Christopher Cobb (JIRA)]

[ http://jira.codehaus.org/browse/MNG-1819?page=comments#action_53424 ] 

Christopher Cobb commented on MNG-1819:
---

I am also running cygwin.

If I open a windows cmd shell, I get:

C:\downloads\maven-2.0.1\binmvn
[INFO] Scanning for projects...
[INFO] 

[ERROR] BUILD FAILURE
[INFO] 

[INFO] You must specify at least one goal. Try 'install'
[INFO] 

[INFO] For more information, run Maven with the -e switch
[INFO] 

[INFO] Total time:  1 second
[INFO] Finished at: Wed Dec 14 11:34:47 EST 2005
[INFO] Final Memory: 1M/2M
[INFO] 



If I open a cygwin rxvt bash shell, I get (whose path has been purified of 
directories with spaces with PATH=`echo $PATH|tr : '\n'|grep -v   | tr '\n' 
:`), I get:

/downloads/maven-2.0.1/bin $ ./mvn
[WARNING] Failed to initialize environment variable resolver. Skipping 
environment substitution in settings.
[WARNING] Failed to initialize environment variable resolver. Skipping 
environment substitution in settings.
[INFO] Scanning for projects...
[INFO] 

[ERROR] FATAL ERROR
[INFO] 

[INFO] String index out of range: -1
[INFO] 

[INFO] Trace
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1768)
at 
org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:188)
at 
org.codehaus.plexus.util.interpolation.EnvarBasedValueSource.init(EnvarBasedValueSource.java:16)
at 
org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolate(RegexBasedModelInterpolator.java:86)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:725)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildStandaloneSuperProject(DefaultMavenProjectBuilder.java:1334)
at org.apache.maven.DefaultMaven.getSuperProject(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:281)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] 

[INFO] Total time:  1 second
[INFO] Finished at: Wed Dec 14 11:36:03 EST 2005
[INFO] Final Memory: 1M/2M
[INFO] 




 StringIndexOutOfBoundsException when running maven
 --

  Key: MNG-1819
  URL: http://jira.codehaus.org/browse/MNG-1819
  Project: Maven 2
 Type: Bug

 Versions: 2.0.1
  Environment: win xp, cygwin
 Reporter: Dan Diephouse



 Just trying out 2.0.1 and I am getting this message below. any ideas?
 $ mvn.bat
 [WARNING] Failed to initialize environment variable resolver. Skipping 
 environment substitution in settings.
 [INFO] Scanning for projects...
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] String index out of range: -1
 [INFO] 
 
 [INFO] Trace
 java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1768)
at 
 org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:188)
at 
 org.codehaus.plexus.util.interpolation.EnvarBasedValueSource.init(EnvarBasedValueSource.java:16)
at 
 org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolate(RegexBasedModelInterpolator.java:86