Re: 3.8.2 transitive dependency insecure repo

[Stuart McCulloch]

The odd thing is that the pom blocked in the original
message, org.jboss.weld:weld-parent:pom:6, is available on central:


https://repo1.maven.org/maven2/org/jboss/weld/weld-parent/6/weld-parent-6.pom

I haven't been able to find anything in that dependency chain that isn't
also on central - but some of them do refer to remote repositories (which
apparently is allowed, but is discouraged)

Anyway I'm happy to change this dependency to a later version like 1.2 that
has the remote repository in a separate profile.

On Sat, 14 Aug 2021 at 20:36, Michael Osipov  wrote:

> Am 2021-08-14 um 21:25 schrieb Delany:
> > Ok, sorry I didn't mention before you released, I wasn't sure of my
> setup.
> > https://issues.apache.org/jira/browse/MNG-7214
>
> Thanks, I just did a git log on the pom.xml and this issue existed for
> at least five years in the codebase, no one ever noticed before the HTTP
> blocker or being behind a firewall and working w/ a repo manager.
>
> > On Sat, 14 Aug 2021 at 20:56, Michael Osipov 
> wrote:
> >
> >> Thank you very, very much for this edge case.
> >>
> >> Gosh, I hate all of this JBoss conglomerate with a passion.
> >>
> >> This is our problem:
> >>> [INFO] |  +- org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.4:compile
> >>> [INFO] |  |  \- javax.enterprise:cdi-api:jar:1.0:compile
> >>> [INFO] |  | \- javax.annotation:jsr250-api:jar:1.0:compile
> >>
> >> Guess what, although javax.enterprise:cdi-api is in javax namespace its
> >> parent is
> >>> 
> >>>org.jboss.weld
> >>>weld-api-parent
> >>>1.0
> >>>../parent/pom.xml
> >>> 
> >>
> >> WTF? How is this possible? Who signed this? The API should be completely
> >> decoupled of Weld. The repo is burried in the parents. This is
> >> absolutely unacceptable. It leaks now in the entire buildchain for
> >> everyone who depends on our artifacts.
> >>
> >> We can do two things here:
> >> 1. Exclude this transitive dependency and lose @Typed in Plexus to JSR
> >> 330 migration
> >> 2. Ask Stuart McCulloch to push a new Sisu release with updates to CDI
> >> 1.2 which parents do not have a repo anymore.
> >>
> >> Still leaves a very bad after taste
> >>
> >> Please file an issue, I will try talk to Stuart.
> >>
> >> I think this is ugly enough to justify 3.8.3 for all of those who
> >> depends on our JARs. Plain Maven users aren't affected.
> >>
> >> Michael
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Parameter priority for a Maven Plugin

[Stuart McCulloch]

If you configure a constant value in your POM then that takes precedence
over values from the command-line.

If you want to make the value configurable on the command-line and have a
default value in your POM then the recommended approach is to introduce a
property:

  
some-default-value
  

  
org.example
some-maven-plugin

  ${some-key}

  

https://issues.apache.org/jira/browse/MNG-4979

On Thu, 10 Sep 2020 at 19:27, Oliver B. Fischer 
wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Dear all,
>
> I always believed that the commandline parameters for a Maven plugin
> have a higher priority then the values configured in the configuration
> element of a plugin configuration.
>
> But now I have the problem, that we can't overwrite the plugin
> configuration in the POM by commandline parameters. This behaviour is
> reproducable and I have written tests for this.
>
> Am I wrong or did I misunderstand something and the current behavior is
> correct?
>
> Oliver
>
> BTW, we currently use org.apache.maven:maven-core:jar:3.5.0
>
>
> - --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEU7j685HGR9cAsMGwB88X6wLziPwFAl9ab/0ACgkQB88X6wLz
> iPzpEw/9HnZRnvHHaT9Wkx9COlezKsucpoQIlqFb8b8LGO6OaS1Eo0BGGEO9qz+V
> BeuPoBRUN0gPSufPehuM/X6yHPyczGIM/gUx8AahRqIVPysUBBVsTHIh9/RAH6fI
> zS9ToTFissHfhzFshHafb39OD/EeZ/ftt8k20BfI5b7qkfIjytvYHsaFFY9ZVNhk
> H3wKzbdvZ6EcG9hx3UjglLAQKWwyMDzVUDqp3P5Be/KDfSmmAPAqjwj0UKm8/E+6
> p9QhrCgHOHKcKPOtXeScYS3RykkDNFoKUbPtsfmPQxNHtfjO6VkBvDNUsoDcf/He
> 3maEoJ7JxpUak0tU8Y87DJv8MLVsSkwhgIzmXpQR/MK8YJBkXpmNd2K4l1GVlro0
> nFkjhVwgya39pt6B0m8EEIPQZhErGVrwqMPkWKaFShiDIz/meav1BVVWuiClYpBn
> +uMCwOYM+0AnR609EvUNEBcd5HtO7Su2CSnKQkGRuOlPZ1A0QhCTCEcrV69QVb4P
> M6/vIyVo2R6ZZXWYX00bYwVED92XpdO9peRdrW92TjTGdWHK2j5FqKntiIB99QuY
> ekHTnVTVif8bMZplts3S1pY8Qeo/NdxbJ1Bu97VMCo5x7NUi+5qUCwhGlmgN9u3c
> B0hoyiJa0+2CES980J1XrmlcK+JUeHWnfiEfutvZCpmbUxnnIkg=
> =VP64
> -END PGP SIGNATURE-
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Any specific requirements for extensions?

[Stuart McCulloch]

Scratch that - the AetherModule and DefaultServiceLocator are only used by
clients that don't use dependency injection, they're not used by Maven
itself.

The log snippet you posted above shows both SyncContextFactory components
are being bound in the same realm - they are therefore given the exact same
priority, both being "default", which means the one with the earlier
alphabetical name wins. This is DefaultSyncContextFactory, as shown by its
order in the logs.

Note if the replacement component was bound in a plugin realm then it would
automatically win because the baseline priority is bumped for each plugin
realm added to the system. This is to support Maven's standard behaviour of
always allowing a plugin to override previously bound components. A
component's priority is based on the baseline priority of its realm, with
default components given a boost compared to non-default components. In
other words default components always have a higher priority than
non-default components regardless of the realm/plugin, while components
bound in later plugins have slightly higher priorities than the equivalent
component bound in earlier plugins.

Because the replacement component is bound in the same realm as the
original (since the extension is being pulled into the core realm) then it
has the same baseline priority. So to make sure it appears first you'll
need to explicitly give it a higher priority. You can do this by adding:

@javax.annotation.Priority(Integer.MAX_VALUE)

to RedissonSyncContextFactory - this will give that component the highest
priority, so it will always appear before any other implementation of that
interface.

On Wed, 12 Aug 2020 at 10:17, Stuart McCulloch  wrote:

> The issue is indeed with AetherModule which is installed by Maven
> via MavenAetherModule
>
> This module adds concrete bindings for various Aether components which
> cannot be overridden in plugins/extensions.
>
> These bindings will need to be changed to support overriding, I'll create
> a patch to show how this could be done.
>
> On Tue, 11 Aug 2020 at 12:07, Michael Osipov  wrote:
>
>> Am 2020-08-11 um 11:48 schrieb Stuart McCulloch:
>> > JSR330 annotation scanning is enabled for all realms including
>> > extensions, so it should be picked up.
>> >
>> > Does the replacement implementation have the same "hint" or name?
>> > ie. @Named("default")
>> >
>> > You can turn on detailed container logging with -Dsisu.debug which will
>> log
>> > all bindings discovered in each realm/extension and any potential
>> issues.
>>
>> Hi Stuart,
>>
>> I have followed your advice and added explicit names: "default" for both:
>>
>> > @Named( "default" )
>> > @Singleton
>> > public class DefaultSyncContextFactory
>> > implements SyncContextFactory
>>
>> and
>>
>> > @Named( "default" )
>> > @Singleton
>> > public class RedissonSyncContextFactory
>> > implements SyncContextFactory
>>
>> I can see this:
>> > 77. LinkedKeyBinding{key=Key[type=java.lang.Object, annotation=*],
>> source=ClassRealm[plexus.core, parent: null], scope=Scopes.NO_SCOPE,
>> target=Key[type=org.eclipse.aether.internal.impl.DefaultSyncContextFactory,
>> annotation=[none]]}
>> > 78. LinkedKeyBinding{key=Key[type=java.lang.Object, annotation=*],
>> source=ClassRealm[plexus.core, parent: null], scope=Scopes.NO_SCOPE,
>> target=Key[type=org.eclipse.aether.synccontext.RedissonSyncContextFactory,
>> annotation=[none]]}
>> > 249.
>> ProviderInstanceBinding{key=Key[type=org.eclipse.aether.impl.SyncContextFactory,
>> annotation=[none]], source=org.eclipse.sisu.wire.LocatorWiring,
>> scope=Scopes.NO_SCOPE,
>> provider=org.eclipse.sisu.wire.BeanProviders$7@6cce16f4}
>> > 334.
>> ConstructorBinding{key=Key[type=org.eclipse.aether.internal.impl.DefaultSyncContextFactory,
>> annotation=[none]], source=ClassRealm[plexus.core, parent: null],
>> scope=Scopes.SINGLETON}
>> > 335.
>> ConstructorBinding{key=Key[type=org.eclipse.aether.synccontext.RedissonSyncContextFactory,
>> annotation=[none]], source=ClassRealm[plexus.core, parent: null],
>> scope=Scopes.SINGLETON}
>>
>> I am afraid that the AetherModule as well as DefaultServiceLocator
>> basically break the bean names, thus making it unusable. The extension
>> is defitively not picked up because I don't see log statements from it.
>>
>> Tried also:
>> > bind( SyncContextFactory.class ).annotatedWith( Names.named( "default"
>> ) ) //
>> > .to( DefaultSyncContextFactory.class ).in( Singleton.class );
>>
>> Even removing did not work.
>>
>> Changed order in m2.conf, no avail.
>>
>> Anything else I could try?
>>
>> Michael
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: Any specific requirements for extensions?

[Stuart McCulloch]

The issue is indeed with AetherModule which is installed by Maven
via MavenAetherModule

This module adds concrete bindings for various Aether components which
cannot be overridden in plugins/extensions.

These bindings will need to be changed to support overriding, I'll create a
patch to show how this could be done.

On Tue, 11 Aug 2020 at 12:07, Michael Osipov  wrote:

> Am 2020-08-11 um 11:48 schrieb Stuart McCulloch:
> > JSR330 annotation scanning is enabled for all realms including
> > extensions, so it should be picked up.
> >
> > Does the replacement implementation have the same "hint" or name?
> > ie. @Named("default")
> >
> > You can turn on detailed container logging with -Dsisu.debug which will
> log
> > all bindings discovered in each realm/extension and any potential issues.
>
> Hi Stuart,
>
> I have followed your advice and added explicit names: "default" for both:
>
> > @Named( "default" )
> > @Singleton
> > public class DefaultSyncContextFactory
> > implements SyncContextFactory
>
> and
>
> > @Named( "default" )
> > @Singleton
> > public class RedissonSyncContextFactory
> > implements SyncContextFactory
>
> I can see this:
> > 77. LinkedKeyBinding{key=Key[type=java.lang.Object, annotation=*],
> source=ClassRealm[plexus.core, parent: null], scope=Scopes.NO_SCOPE,
> target=Key[type=org.eclipse.aether.internal.impl.DefaultSyncContextFactory,
> annotation=[none]]}
> > 78. LinkedKeyBinding{key=Key[type=java.lang.Object, annotation=*],
> source=ClassRealm[plexus.core, parent: null], scope=Scopes.NO_SCOPE,
> target=Key[type=org.eclipse.aether.synccontext.RedissonSyncContextFactory,
> annotation=[none]]}
> > 249.
> ProviderInstanceBinding{key=Key[type=org.eclipse.aether.impl.SyncContextFactory,
> annotation=[none]], source=org.eclipse.sisu.wire.LocatorWiring,
> scope=Scopes.NO_SCOPE,
> provider=org.eclipse.sisu.wire.BeanProviders$7@6cce16f4}
> > 334.
> ConstructorBinding{key=Key[type=org.eclipse.aether.internal.impl.DefaultSyncContextFactory,
> annotation=[none]], source=ClassRealm[plexus.core, parent: null],
> scope=Scopes.SINGLETON}
> > 335.
> ConstructorBinding{key=Key[type=org.eclipse.aether.synccontext.RedissonSyncContextFactory,
> annotation=[none]], source=ClassRealm[plexus.core, parent: null],
> scope=Scopes.SINGLETON}
>
> I am afraid that the AetherModule as well as DefaultServiceLocator
> basically break the bean names, thus making it unusable. The extension
> is defitively not picked up because I don't see log statements from it.
>
> Tried also:
> > bind( SyncContextFactory.class ).annotatedWith( Names.named( "default" )
> ) //
> > .to( DefaultSyncContextFactory.class ).in( Singleton.class );
>
> Even removing did not work.
>
> Changed order in m2.conf, no avail.
>
> Anything else I could try?
>
> Michael
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Any specific requirements for extensions?

[Stuart McCulloch]

JSR330 annotation scanning is enabled for all realms including
extensions, so it should be picked up.

Does the replacement implementation have the same "hint" or name?
ie. @Named("default")

You can turn on detailed container logging with -Dsisu.debug which will log
all bindings discovered in each realm/extension and any potential issues.

On Thu, 6 Aug 2020 at 11:45, Michael Osipov  wrote:

> Folks,
>
> I am trying to write an extension for Maven Resolver which shall replace
> a default implementation. The implemented interface is an exported
> package in maven-core, the implementing class has proper javax.inject
> annotations @Named(...) and @Singleton so does the default (bundled)
> one. Put in lib/ext as well as to .mvn/extensions.xml. At no case the
> new implementation is picked up by Maven Resolver. Sisu descriptor has
> been created also.
>
> Is there anything I have missed? Does it require rather Plexus annotations?
>
> Michael
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Shade plugin cannot find default setter?

[Stuart McCulloch]

It looks like you're missing the  tag inside the 
list:
https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html

try:




javax.ejb
jakarta.ejb

javax.ejb.*





On Mon, 4 May 2020 at 15:01, Russell Gold  wrote:

> I’m attempting to use the shade plugin to relocate some dependent classes
> with the following configuration:
>
> 
> 
> javax.ejb
> jakarta.ejb
> 
> javax.ejb.*
> 
> 
> 
>
>
> but when I try running, I see:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on
> project orb-gmbal-pfl-shading: Unable to parse configuration of mojo
> org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade for parameter
> pattern: Cannot find default setter in class
> org.apache.maven.plugins.shade.mojo.PackageRelocation -> [Help 1]
>
> How do I get past this?
>
> Thanks,
> Russ

Re: warning default invalid module name Errors Replicated

[Stuart McCulloch]

Is this Ubuntu?  I seem to remember they have their own build of Maven
which differs from the Apache source.

( https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1754602  suggests
it's a known bug in their packaging/build? )

If you download Maven from http://maven.apache.org/download.cgi and follow
the instructions in http://maven.apache.org/install.html then you shouldn't
see those warnings.

On Mon, 6 Jan 2020 at 00:02, zahid  wrote:

> I installed maven using *sudo apt-get install  maven*
>
> I even got this message at the end.
>
> *update-alternatives: using /usr/share/maven/bin/mvn to provide
> /usr/bin/mvn (mvn) in auto mode*
>
> from the console output showing my current system settings, what  do you
> say should be the  exact settings  for env. variable(s) ? I don't want to
> screw up anything. From the information I received I thought if  mvn
> -version works, that means maven setup is complete. Anyway I think the
> "sudo apt-get install maven"  people need to be notified of this bug.
>
> kub18@UB18:~/javafx/helloapp$ *echo $M2_HOME*
>
> kub18@UB18:~/javafx/helloapp$ *echo $MAVEN_HOME*
>
> kub18@UB18:~/javafx/helloapp$ *whereis maven*
> *maven: /etc/maven /usr/share/maven*
>
> kub18@UB18:~/javafx/helloapp$ *whereis mvn*
> *mvn: /usr/bin/mvn /usr/share/man/man1/mvn.1.gz*
>
> kub18@UB18:~/javafx/helloapp$ mvn -version
> Apache Maven 3.6.0
> Maven home: /usr/share/maven
> Java version: 11.0.5, vendor: Private Build, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "5.0.0-37-generic", arch: "amd64", family:
> "unix"
>
>
> On 05/01/2020 22:38, Stuart McCulloch wrote:
>
> The Java 11 warning mentions that "/usr/share/maven/lib/guice.jar" has a
> class named "com.google.inject.internal.cglib.core.$ReflectUtils$1"
>
> This looks suspect because the official Maven distribution uses the
> "no-AOP" version of Guice which doesn't contain any CGLIB classes. It
> suggests that whoever provided that copy of Maven has replaced the "no-AOP"
> version with the "AOP" version, and this will cause warnings on Java 11.
> (The "AOP" version uses CGLIB which currently relies on certain reflective
> access that Java 11 warns about - whereas the "no-AOP" version doesn't.)
>
> If you install an official Maven distribution from Apache (and make sure
> that the MAVEN_HOME environment variable points to it) then you shouldn't
> see that warning.
>
> On Sun, 5 Jan 2020 at 22:24, Karl Heinz Marbaise 
> wrote:
>
>> Hi,
>>
>> On 05.01.20 22:54, zahid wrote:
>> > Thank you. These files has been generated by NETBEANS IDE.
>>
>> I have my doubts that plugins generated as dependencies by Netbeans if
>> so this is simply a bug 
>>
>>
>> >
>> > *Netbeans uses a very old version Apache Maven 3.3.9 and these warnings
>> > do not appear.
>>
>> This means you don't have defined all your used plugins correctly within
>> your pom.xml (pluginManagement as you already done with
>> maven-compiler-plugin) with their appropriate versions.
>>
>> Older plugins versions didn't even know something about Java Module
>> system (JPMS) names etc. (This is what you get with Maven 3.3.9..) That
>> looks like that those warnings have gone but they are still there
>> because older plugins didn't recogzined them...
>>
>>
>> > *
>> >
>> > *I still get these warnings with the revised pom.xml
>> > *
>> >
>> > kub18@UB18:~/javafx/helloapp$ mvn  javafx:run
>> > WARNING: An illegal reflective access operation has occurred
>> > WARNING: Illegal reflective access by
>> > com.google.inject.internal.cglib.core.$ReflectUtils$1
>> > (file:/usr/share/maven/lib/guice.jar) to method
>> >
>> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
>> > WARNING: Please consider reporting this to the maintainers of
>> > com.google.inject.internal.cglib.core.$ReflectUtils$1
>> > WARNING: Use --illegal-access=warn to enable warnings of further
>> illegal
>> > reflective access operations
>> > WARNING: All illegal access operations will be denied in a future
>> release
>> > [INFO] Scanning for projects...
>> > [INFO]
>> > [INFO] --< co.uk.backbutton:HelloFX
>> >  >--
>> > [INFO] Building HelloFX 1.0-SNAPSHOT
>> > [INFO] [ jar
>> > ]-

Re: warning default invalid module name Errors Replicated

[Stuart McCulloch]

The Java 11 warning mentions that "/usr/share/maven/lib/guice.jar" has a
class named "com.google.inject.internal.cglib.core.$ReflectUtils$1"

This looks suspect because the official Maven distribution uses the
"no-AOP" version of Guice which doesn't contain any CGLIB classes. It
suggests that whoever provided that copy of Maven has replaced the "no-AOP"
version with the "AOP" version, and this will cause warnings on Java 11.
(The "AOP" version uses CGLIB which currently relies on certain reflective
access that Java 11 warns about - whereas the "no-AOP" version doesn't.)

If you install an official Maven distribution from Apache (and make sure
that the MAVEN_HOME environment variable points to it) then you shouldn't
see that warning.

On Sun, 5 Jan 2020 at 22:24, Karl Heinz Marbaise  wrote:

> Hi,
>
> On 05.01.20 22:54, zahid wrote:
> > Thank you. These files has been generated by NETBEANS IDE.
>
> I have my doubts that plugins generated as dependencies by Netbeans if
> so this is simply a bug 
>
>
> >
> > *Netbeans uses a very old version Apache Maven 3.3.9 and these warnings
> > do not appear.
>
> This means you don't have defined all your used plugins correctly within
> your pom.xml (pluginManagement as you already done with
> maven-compiler-plugin) with their appropriate versions.
>
> Older plugins versions didn't even know something about Java Module
> system (JPMS) names etc. (This is what you get with Maven 3.3.9..) That
> looks like that those warnings have gone but they are still there
> because older plugins didn't recogzined them...
>
>
> > *
> >
> > *I still get these warnings with the revised pom.xml
> > *
> >
> > kub18@UB18:~/javafx/helloapp$ mvn  javafx:run
> > WARNING: An illegal reflective access operation has occurred
> > WARNING: Illegal reflective access by
> > com.google.inject.internal.cglib.core.$ReflectUtils$1
> > (file:/usr/share/maven/lib/guice.jar) to method
> >
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> > WARNING: Please consider reporting this to the maintainers of
> > com.google.inject.internal.cglib.core.$ReflectUtils$1
> > WARNING: Use --illegal-access=warn to enable warnings of further illegal
> > reflective access operations
> > WARNING: All illegal access operations will be denied in a future release
> > [INFO] Scanning for projects...
> > [INFO]
> > [INFO] --< co.uk.backbutton:HelloFX
> >  >--
> > [INFO] Building HelloFX 1.0-SNAPSHOT
> > [INFO] [ jar
> > ]-
> > [INFO]
> > [INFO] --- javafx-maven-plugin:0.0.3:run (default-cli) @ HelloFX ---
> > [INFO]
> > 
> > [INFO] BUILD SUCCESS
> > [INFO]
> > 
> > [INFO] Total time:  3.934 s
> > [INFO] Finished at: 2020-01-05T21:51:22Z
> > [INFO]
> > 
>
>
> This is something completely different.
>
> If the pom is the one your are using than you should use Maven 3.6.3 and
> correctly check your environment if it's pointing to the correct Maven
> installation... (Do you use M2_HOME or MAVEN_HOME environment variables?
> Only add the bin directory of the Maven installation to the PATH nothing
> else).
>
> I suppose /usr/share/maven/lib/guice.jar) is from your Maven
> installation on your system?
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> >
> > *REVISED pom.xml*
> >
> > kub18@UB18:~/javafx/helloapp$ cat pom.xml
> > http://maven.apache.org/POM/4.0.0;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd;>
> >
> >  4.0.0
> >  co.uk.backbutton
> >  HelloFX
> >  1.0-SNAPSHOT
> >
> >  
> > UTF-8
> >
> UTF-8
> > 11
> > 11
> >  
> >
> >  
> >  
> >  org.openjfx
> >  javafx-controls
> >  14-ea+6
> >  
> >  
> >  org.openjfx
> >  javafx-fxml
> >  13
> >  
> >  
> >
> >  
> >  
> >   
> >  
> > org.apache.maven.plugins
> > maven-compiler-plugin
> >  3.8.0
> >  
> > ${maven.compiler.source}
> >  
> >  
> >
> >  
> >  org.openjfx
> > javafx-maven-plugin
> >  0.0.3
> >  
> >  HelloFX
> >  
> >  
> >  
> >   
> >  
> > 
> >
> >
> > On 05/01/2020 20:53, Karl Heinz Marbaise wrote:
> >> Hi,
> >>
> >>
> >> On 05.01.20 21:31, zahid wrote:
> >>>
> >>> mvn -version
> >>> Apache Maven 3.6.0
> >>> Maven home: /usr/share/maven
> >>> Java version: 11.0.5, vendor: Private Build, runtime:
> >>> /usr/lib/jvm/java-11-openjdk-amd64
> 

Re: Found Issues - Release Apache Maven Version 3.6.2

[Stuart McCulloch]

How are you replacing them currently?

The typical way is to use the extensions mechanism:
https://maven.apache.org/docs/3.3.1/release-notes.html#Core_Extensions

Components contributed via an extension have a higher priority over the
original component in core (assuming that they have the same JSR330 name or
Plexus hint)

On Thu, 29 Aug 2019 at 11:46, Alexander Bubenchikov <
alexander.bubenchi...@jetbrains.com> wrote:

> Hi Enrico, my name is Alex, I've joined to Jetbrains this year and
> responsible for maven integration and Intellij idea.
>
> he issue happen because we replace some components in maven
> (ModelInterpolator in this case) to our own implementation which have
> injected PathTranslator and UrlNormalizer
> I've workarounded the issue in our code, but I didn't dig well into this.
> Is there any new way to replace maven components?
>
> On Wed, Aug 28, 2019 at 11:57 PM Enrico Olivelli 
> wrote:
>
> > It may be due to any change regarding jsr 330 like
> > https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-6686
> >
> >
> > I think it is an issue for Idea and not for us.
> > It would be good to have some developer from Jetbrains on this list
> >
> >
> > Enrico
> >
> > Il mer 28 ago 2019, 22:23 Tibor Digana  ha
> > scritto:
> >
> > > I do not have NPE in the log.
> > > Guice is certainly not CDI. Moving Guice to CDI must be painful.
> > > One reason why PathTranslator could not be found is that there are
> > several
> > > bean instances of the same interface.
> > > Second problem might go with the Guice/CDI.
> > > See this inheritance:
> > >
> > > @Named
> > > @Singleton
> > > public class DefaultPathTranslator
> > > implements PathTranslator
> > > {
> > >
> > > public interface PathTranslator
> > > {
> > >
> > >
> > >
> > > On Wed, Aug 28, 2019 at 10:04 PM Filipe Sousa 
> wrote:
> > >
> > >> Hi,
> > >>
> > >> Not sure if it’s the same bug I commented in
> > >>
> >
> https://issues.apache.org/jira/browse/MNG-6638?focusedCommentId=16852351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16852351
> > >>
> > >> I reported to Jetbrains
> > https://youtrack.jetbrains.com/issue/IDEA-215315
> > >>  and is supposed to
> > be
> > >> fixed in 2019.3
> > >>
> > >> > On 28 Aug 2019, at 20:43, Tibor Digana 
> > wrote:
> > >> >
> > >> > I used Maven 3.6.2 in the IntelliJ IDEA 2019.2.1 and I found these
> > >> errors
> > >> > in the log file:
> > >> > ~/.IntelliJIdea2019.2/system/log/idea.log
> > >> >
> > >> > 2019-08-28 21:31:32,072 [255937677]  ERROR -
> > >> #org.jetbrains.idea.maven
> > >> > - com.google.inject.CreationException: Unable to create injector,
> see
> > >> the
> > >> > following errors:
> > >> >
> > >> > 1) No implementation for org.apache.maven.model.path.PathTranslator
> > was
> > >> > bound.
> > >> >  while locating org.apache.maven.model.path.PathTranslator
> > >> >for field at
> > >> >
> > >>
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
> > >> > Source)
> > >> >  at
> > >> >
> > >>
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> > >> >
> > >> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer
> was
> > >> > bound.
> > >> >  while locating org.apache.maven.model.path.UrlNormalizer
> > >> >for field at
> > >> >
> > >>
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
> > >> > Source)
> > >> >  at
> > >> >
> > >>
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> > >> >
> > >> > 2 errors
> > >> > java.lang.RuntimeException: com.google.inject.CreationException:
> > Unable
> > >> to
> > >> > create injector, see the following errors:
> > >> >
> > >> > 1) No implementation for org.apache.maven.model.path.PathTranslator
> > was
> > >> > bound.
> > >> >  while locating org.apache.maven.model.path.PathTranslator
> > >> >for field at
> > >> >
> > >>
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
> > >> > Source)
> > >> >  at
> > >> >
> > >>
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> > >> >
> > >> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer
> was
> > >> > bound.
> > >> >  while locating org.apache.maven.model.path.UrlNormalizer
> > >> >for field at
> > >> >
> > >>
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
> > >> > Source)
> > >> >  at
> > >> >
> > >>
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> > >> >
> > >> > 2 errors
> > >> > at
> > >> >
> > >>
> >
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:543)
> > >> > at
> > >> >
> > >>
> >
> 

Re: No implementation for org.apache.maven.model.resolution.ModelResolver was bound

[Stuart McCulloch]

ModelResolver isn't a component and therefore isn't available for injection
- I can see two implementations of that interface in Maven, but both are
manually created:


https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java#L276


https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L280

Of the two implementations ProjectModelResolver is the only one that's
public

On Wed, 23 Jan 2019 at 08:53, Simone Tripodi 
wrote:

> Hi all mates,
>
> I have been developing an OSS MOJO where, when executed, Maven is not
> able to inject required components due to the the error below:
>
> 
> Execution apis-jar of goal
> org.apache.sling:slingfeature-maven-plugin:0.8.1-SNAPSHOT:apis-jar
> failed: Unable to load the mojo 'apis-jar' (or one of its required
> components) from the plugin
> 'org.apache.sling:slingfeature-maven-plugin:0.8.1-SNAPSHOT':
> com.google.inject.ProvisionException: Unable to provision, see the
> following errors:
>
> [ERROR]
> [ERROR] 1) No implementation for
> org.apache.maven.model.resolution.ModelResolver was bound.
> [ERROR]   while locating org.apache.sling.feature.maven.mojos.ApisJarMojo
> [ERROR]   at
> ClassRealm[extension>org.apache.sling:slingfeature-maven-plugin:0.8.1-SNAPSHOT,
> parent: sun.misc.Launcher$AppClassLoader@3d4eac69] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> [ERROR]   while locating org.apache.maven.plugin.Mojo annotated with
>
> @com.google.inject.name.Named(value=org.apache.sling:slingfeature-maven-plugin:0.8.1-SNAPSHOT:apis-jar)
> [ERROR]
> [ERROR] 1 error
> [ERROR]   role: org.apache.maven.plugin.Mojo
> [ERROR]   roleHint:
> org.apache.sling:slingfeature-maven-plugin:0.8.1-SNAPSHOT:apis-jar
> 
>
> The right dependency is declared in the POM:
>
> 
> 
> org.apache.maven
> maven-model-builder
> 3.6.0
> 
> 
>
> that seems to contain correct metadata in `META-INF/plexus/components.xml`
>
> Error happens in this environment:
>
> 
> $ mvn -version
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
> PermSize=256m; support was removed in 8.0
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: /Applications/apache-maven-3.5.4
> Java version: 1.8.0_152, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/jre
> Default locale: en_CH, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
> 
>
> Do you have any hint on how to fix it?
> Many thanks in advance!
> ~Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: mvn --version (java inconsistency?)

[Stuart McCulloch]

I believe that's true for the current releases, but it looks like it will
change in the future:
https://github.com/AdoptOpenJDK/openjdk-build/issues/465

On Sun, 4 Nov 2018 at 19:46, Elliot Huntington 
wrote:

> Now that Oracle is charging licensing fees to use Oracle Java as of Java
> 11, I am switching to Open JDK. Here is the output for my environment
> configuration in case it is helpful. Everything looks consistent to me
> except the bold output which lists Oracle as the java vendor.
>
> Is Oracle listed as the vendor of Open JDK 11, or might I have
> misconfigured my environment variables such that "maven --version" would
> report a differing java versions for build and runtime scopes?
>
> *echo $JAVA_HOME*
> ~/.sdkman/candidates/java/current
>
> *which java*
> ~/.sdkman/candidates/java/current/bin/java
>
> *java --version*
> openjdk 11.0.1 2018-10-16
> OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
>
> *which mvn*
> ~/.sdkman/candidates/maven/current/bin/mvn
>
> *mvn --version*
> Maven home: ~/.sdkman/candidates/maven/current
> Java version: 11.0.1, *vendor: Oracle Corporation*, runtime:
> ~/.sdkman/candidates/java/11.0.1-open
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-137-generic", arch: "amd64", family:
> "unix"
>

Re: Is there a guide on how to use Sisu within Maven plugins?

[Stuart McCulloch]

On 3 Feb 2017 16:44, "Laird Nelson"  wrote:

On Fri, Feb 3, 2017 at 1:15 AM Hervé BOUTEMY  wrote:

> notice:@Component we're using in a Mojo is from Maven Plugin Tools
> org.apache.maven.plugins.annotations.Component [1]
>

Right; I (now :-)) understand this part and all of the things related to it.

The part I didn't get was that there's only one components.xml that can
possibly contain the wiring information.  There's no way, in other words,
to supply *another* components.xml that should override it.


This isn't quite right - each Maven plugin has a plugin.xml which
indirectly contributes bindings (the Maven plugin manager calls Plexus to
register bindings for mojos, etc.) - it can also have zero or more
component.xml files which are discovered by scanning the plugin realm. It
can also have a Sisu index resource file which is generated at build time
listing all JSR330 components in the plugin annotated with @Named.

All these binding sources (scoped to the plugin realm) are used to create
an injector for the plugin. This injector is also setup to look up
components from injectors visible to the plugin (such as Maven extensions)
which is where you should be able to override components.

If you have an example extension which should be overriding a component but
isn't then I'm happy to take a look.

--
Cheers, Stuart

Best,
Laird

Re: Is there a guide on how to use Sisu within Maven plugins?

[Stuart McCulloch]

Here's a brief overview of the different layers...

Maven plugin annotations are only used at plugin build time to generate
Maven's plugin.xml - they are not used at runtime (at least the container
doesn't use them)

Maven uses this plugin.xml descriptor to setup the plugin in Plexus
(creating the class realm, registering component descriptors as well as
arranging for parameter processing - which builds on the converter API
provided by Plexus)

Plexus is now a facade on top of Sisu. This facade provides the expected
API, mapping calls to Sisu and using listeners/adapters to mimic Plexus
behaviour - such as limiting component visibility based on realm visibility.

(This was developed from scratch by observing what APIs were used by Plexus
based apps, mainly Maven, and iterating until the API surface and behaviour
matched)

Plexus bindings (be that defined in components.xml, Plexus annotations, or
registered programmatically) are canonicalized as Guice bindings to provide
interoperability with JSR330.

Sisu provides a flexible bean layer on top of Guice. It also adds extra
dynamics such as injected collections that track components provided by
different injectors (in the Maven-Plexus-Guice mapping a plugin is
represented by a single injector) as well as the ability to look up or
watch for components across multiple injectors.

Circling back to the original question: yes you can override components in
recent versions of Maven but there are some caveats. First your component
must be visible to the plugin (ie be in the same realm or a parent/imported
realm like an extension). Second you'll need to use the priority annotation
to raise its priority (default components get a low positive priority,
based on their realm order - non-default components get a negative
priority).

If someone puts together a buildable example that should work, but isn't
then I'm happy to take a look - just in case you're hitting an edge-case -
it would also help me flesh out the documentation on the wiki.

HTH

--
Cheers, Stuart

On 3 Feb 2017 11:47, "Robert Scholte"  wrote:

> On Fri, 03 Feb 2017 12:39:56 +0100, Hervé BOUTEMY 
> wrote:
>
> Le vendredi 3 février 2017, 10:43:42 CET Robert Scholte a écrit :
>>
>>> What I expect to happen is that Plexus Component Annotations will be
>>> fully
>>> replaced with JSR330 annotations.
>>> In that case there will be only 1 @Component annotation, i.e.
>>> org.apache.maven.plugins.annotations.Component, which is fine by me.
>>>
>> We should document that
>>
>> Notice that plexus @Component is not equivalent to @Inject: Plexus
>> @Requirement is equivalent to @Inject
>>
>> And for Maven Plugin Tools, since it is used to generate plugin.xml,
>> having an
>> annotation that matches the XML fragment will help.
>>
>> The more I think at it, the more I think Maven Plugin Tools should promote
>> @Requirement (and we don't care that it is the same name as the
>> @Requirement
>> from Plexus, that means @Inject with JSR330)
>>
>> Also, I expect the community to be more familiar with the maven plugin
>>> annotations than with plexus annotations.
>>>
>> I documented how to switch from Plexus javadoc to Plexus annotations: is
>> there
>> some doc on switching from Plexus annotations to JSR330?
>>
>
> https://wiki.eclipse.org/Sisu/PlexusMigration
>
>
>> Keep in mind that the original question is actually: can I
>>> override/redefine the default implementation for a 'service'?
>>>
>> that's not this email thread: I suppose you're referring to an other
>> discussion
>>
>> Regards,
>>
>> Hervé
>>
>> The
>>> discussion about the annotations caused extra confusion but in the end
>>> had
>>> nothing to do with the issue.
>>>
>>> thanks,
>>> Robert
>>>
>>> On Fri, 03 Feb 2017 10:15:05 +0100, Hervé BOUTEMY >> >
>>>
>>> wrote:
>>> > notice:@Component we're using in a Mojo is from Maven Plugin Tools
>>> > org.apache.maven.plugins.annotations.Component [1]
>>> >
>>> > it's different from @Component from Plexus, which is
>>> > org.codehaus.plexus.component.annotations.Component [2]
>>> >
>>> > Using the same class name in a different package is probably a bad
>>> idea,
>>> > because it's really confusing, sorry: perhaps we should deprecate
>>> > @Component
>>> > in Maven Plugin Tools and create an annotation with another name.
>>> > Any idea on a new name?
>>> >
>>> >
>>> > Then Maven Plugin Tools uses its annotations (@Mojo, @Execute,
>>> > @Parameter and
>>> > @Component in org.apache.maven.plugins.annotations) to generate
>>> META-INF/
>>> > maven/plugin.xml plugin descriptor [3] . @Component annotation is more
>>> > precisely at the source of
>>> >
>>> >   
>>> >
>>> > 
>>> >
>>> >   
>>> >   
>>> >   
>>> >
>>> > 
>>> >
>>> >   
>>> >
>>> > part
>>> >
>>> > Perhaps creating a @Requirement annotation in Maven Plugin Tools to
>>> > replace
>>> > @Component would reduce confusion: it would still not make a 

Re: Maven Plugin and JSR330

[Stuart McCulloch]

Thanks, looks good to me

On Sunday, 20 November 2016 at 17:46, Dan Tran wrote:

> I filed a PR at https://github.com/apache/maven/pull/98.
>  
> On Thu, Nov 17, 2016 at 8:48 PM, Dan Tran <dant...@gmail.com 
> (mailto:dant...@gmail.com)> wrote:
> > It works!!! Thanks Stuard
> >  
> > So my change should be good for commit for 3.4?
> >  
> > -Dan
> >  
> > On Sun, Nov 13, 2016 at 3:01 PM, Stuart McCulloch <mccu...@gmail.com 
> > (mailto:mccu...@gmail.com)>
> > wrote:
> >  
> > > Hi Dan,
> > >  
> > > There are two places in MavenCli which create a container.
> > >  
> > > You’ve enabled JSR250 for the temporary container that resolves the core
> > > extensions, but not the main container that runs the Mojos:
> > >  
> > > https://github.com/dantran/maven/blob/master/maven-embedder/
> > > src/main/java/org/apache/maven/cli/MavenCli.java#L585
> > >  
> > > If I enable JSR250 in the above line then your test passes.
> > >  
> > > --
> > > Cheers, Stuart
> > >  
> > >  
> > > On Sunday, 13 November 2016 at 22:10, Dan Tran wrote:
> > >  
> > > > @Stuard
> > > >  
> > > > Could you review my changes at
> > > > https://github.com/dantran/maven/commits/master? I still not able to
> > > >  
> > >  
> > > get
> > > > @PostContruct working yet
> > > >  
> > > > Thanks
> > > >  
> > > > -Dan
> > > >  
> > > > On Sun, Sep 11, 2016 at 7:27 PM, Dan Tran <dant...@gmail.com 
> > > > (mailto:dant...@gmail.com) (mailto:
> > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > >  
> > > > > Thanks Stuart, very much appreciated
> > > > >  
> > > > > -D
> > > > >  
> > > > > On Sun, Sep 11, 2016 at 7:22 PM, Stuart McCulloch <mccu...@gmail.com 
> > > > > (mailto:mccu...@gmail.com)
> > > (mailto:mccu...@gmail.com)>
> > > > > wrote:
> > > > >  
> > > > > > Sorry, last week was very busy with work and family
> > > > > >  
> > > > > > I’ve listed the necessary config changes in
> > > > > > https://issues.apache.org/jira/browse/MNG-6084
> > > > > >  
> > > > > > --
> > > > > > Cheers, Stuart
> > > > > >  
> > > > > >  
> > > > > > On Sunday, 11 September 2016 at 04:28, Dan Tran wrote:
> > > > > >  
> > > > > > > @Stuart, ping :-)
> > > > > > >  
> > > > > > > On Tue, Sep 6, 2016 at 7:06 PM, Dan Tran <dant...@gmail.com 
> > > > > > > (mailto:dant...@gmail.com)
> > > (mailto:dant...@gmail.com) (mailto:
> > > > > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > > > > >  
> > > > > > > > @Stuart, could you provide instructions on how to enable JSR 250
> > > > > > support?
> > > > > > > >  
> > > > > > > > Thanks
> > > > > > > >  
> > > > > > > >  
> > > > > > > > -Dan
> > > > > > > >  
> > > > > > > > On Fri, Sep 2, 2016 at 9:22 AM, Dan Tran <dant...@gmail.com 
> > > > > > > > (mailto:dant...@gmail.com)
> > > (mailto:dant...@gmail.com) (mailto:
> > > > > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > > > > > >  
> > > > > > > > > here you go https://issues.apache.org/jira/browse/MNG-6084
> > > > > > > > >  
> > > > > > > > > Very much appreciated
> > > > > > > > >  
> > > > > > > > > -Dan
> > > > > > > > >  
> > > > > > > > > On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <
> > > mccu...@gmail.com (mailto:mccu...@gmail.com)
> > > > > > (mailto:mccu...@gmail.com)>
> > > > > > > > > wrote:
> > > > > > > > >  
> > > > > > > > > > On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
> > > > > > > > > > > Hi Stuart
> > > > > > > > > &g

Re: Maven Plugin and JSR330

[Stuart McCulloch]

Hi Dan,  

There are two places in MavenCli which create a container.

You’ve enabled JSR250 for the temporary container that resolves the core 
extensions, but not the main container that runs the Mojos:

https://github.com/dantran/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L585
  

If I enable JSR250 in the above line then your test passes.

--  
Cheers, Stuart


On Sunday, 13 November 2016 at 22:10, Dan Tran wrote:

> @Stuard
>  
> Could you review my changes at
> https://github.com/dantran/maven/commits/master? I still not able to get
> @PostContruct working yet
>  
> Thanks
>  
> -Dan
>  
> On Sun, Sep 11, 2016 at 7:27 PM, Dan Tran <dant...@gmail.com 
> (mailto:dant...@gmail.com)> wrote:
>  
> > Thanks Stuart, very much appreciated
> >  
> > -D
> >  
> > On Sun, Sep 11, 2016 at 7:22 PM, Stuart McCulloch <mccu...@gmail.com 
> > (mailto:mccu...@gmail.com)>
> > wrote:
> >  
> > > Sorry, last week was very busy with work and family
> > >  
> > > I’ve listed the necessary config changes in
> > > https://issues.apache.org/jira/browse/MNG-6084
> > >  
> > > --
> > > Cheers, Stuart
> > >  
> > >  
> > > On Sunday, 11 September 2016 at 04:28, Dan Tran wrote:
> > >  
> > > > @Stuart, ping :-)
> > > >  
> > > > On Tue, Sep 6, 2016 at 7:06 PM, Dan Tran <dant...@gmail.com 
> > > > (mailto:dant...@gmail.com) (mailto:
> > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > >  
> > > > > @Stuart, could you provide instructions on how to enable JSR 250
> > > support?
> > > > >  
> > > > > Thanks
> > > > >  
> > > > >  
> > > > > -Dan
> > > > >  
> > > > > On Fri, Sep 2, 2016 at 9:22 AM, Dan Tran <dant...@gmail.com 
> > > > > (mailto:dant...@gmail.com) (mailto:
> > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > > >  
> > > > > > here you go https://issues.apache.org/jira/browse/MNG-6084
> > > > > >  
> > > > > > Very much appreciated
> > > > > >  
> > > > > > -Dan
> > > > > >  
> > > > > > On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <mccu...@gmail.com 
> > > > > > (mailto:mccu...@gmail.com)
> > > (mailto:mccu...@gmail.com)>
> > > > > > wrote:
> > > > > >  
> > > > > > > On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
> > > > > > > > Hi Stuart
> > > > > > > >  
> > > > > > > > Thanks for helping out.
> > > > > > > >  
> > > > > > > > I have 3 mojos, sharing one singleton component which depends on
> > > > > > > another
> > > > > > > > singleton component thru injection. All working now via both
> > > > > > >  
> > > > > > >  
> > > > > >  
> > > > > >  
> > > > >  
> > > >  
> > >  
> > > injection
> > > > > > >  
> > > > > > > type
> > > > > > > > ( after some cleanup)
> > > > > > > >  
> > > > > > > > should I file a JIRA to enable JSR-250 support fo rmaven 3.4?
> > > > > > > Sure - send me the ticket number and I’ll add some commentary this
> > > > > > > weekend
> > > > > > > > looking forward to use it
> > > > > > > >  
> > > > > > > > Thanks
> > > > > > > >  
> > > > > > > > -Dan
> > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > > > On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch <
> > > mccu...@gmail.com (mailto:mccu...@gmail.com)
> > > > > > > (mailto:mccu...@gmail.com)> wrote:
> > > > > > > >  
> > > > > > > > > Hi Dan,
> > > > > > > > >  
> > > > > > > > > Constructor injection (and component injection) is working
> > > for me
> > > > > > > with
> > > > > > > > > Maven 3.3.9 if I follow the example in
> > > > &g

Re: Is there a plugin to override classifiers based on groupId?

[Stuart McCulloch]

You could write a custom enforcer rule to check the classifier of projects
with particular groupIds:

http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html

Then configure the enforcer plugin to apply that rule in your corporate pom
or wherever you want to enforce it...

On 22 Oct 2016 00:08, "Rémy Saissy"  wrote:

> Hi,
> is there a Maven plugin that allows to automatically append a classifier
> given a groupId?
>
> I would do something like that:
>
>  
> org.apache.maven.plugins
> maven-???-plugin
> x.y
> 
>   
> 
>   
> 
>   
> groupId
> com.company.dept
>   
>   
> classifier
> myclassifier
> false
>   
>  
>   
> 
>   
> 
>   
>
>
>
>
> eg. My company has lot projects that should all use a classifier (two
> values possible depending on the deployment target).
> We could go through all projects over and over again to ensure that they
> everybody uses the proper classifiers or put some hard rules in the
> deployment code but we would like to find a simple and painless way to
> ensure that classifiers are respected. Hence the question.
>
> Thanks!
>
>
>
> --
> Rémy Saissy
> Photos: http://picasaweb.google.com/remy.saissy
> Blog: http://blog.remysaissy.com
>

Re: Maven Plugin and JSR330

[Stuart McCulloch]

Sorry, last week was very busy with work and family

I’ve listed the necessary config changes in 
https://issues.apache.org/jira/browse/MNG-6084  

--  
Cheers, Stuart


On Sunday, 11 September 2016 at 04:28, Dan Tran wrote:

> @Stuart, ping :-)
>  
> On Tue, Sep 6, 2016 at 7:06 PM, Dan Tran <dant...@gmail.com 
> (mailto:dant...@gmail.com)> wrote:
>  
> > @Stuart, could you provide instructions on how to enable JSR 250 support?
> >  
> > Thanks
> >  
> >  
> > -Dan
> >  
> > On Fri, Sep 2, 2016 at 9:22 AM, Dan Tran <dant...@gmail.com 
> > (mailto:dant...@gmail.com)> wrote:
> >  
> > > here you go https://issues.apache.org/jira/browse/MNG-6084
> > >  
> > > Very much appreciated
> > >  
> > > -Dan
> > >  
> > > On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <mccu...@gmail.com 
> > > (mailto:mccu...@gmail.com)>
> > > wrote:
> > >  
> > > > On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
> > > > > Hi Stuart
> > > > >  
> > > > > Thanks for helping out.
> > > > >  
> > > > > I have 3 mojos, sharing one singleton component which depends on
> > > > another
> > > > > singleton component thru injection. All working now via both injection
> > > >  
> > > > type
> > > > > ( after some cleanup)
> > > > >  
> > > > > should I file a JIRA to enable JSR-250 support fo rmaven 3.4?
> > > > Sure - send me the ticket number and I’ll add some commentary this
> > > > weekend
> > > > > looking forward to use it
> > > > >  
> > > > > Thanks
> > > > >  
> > > > > -Dan
> > > > >  
> > > > >  
> > > > >  
> > > > > On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch <mccu...@gmail.com 
> > > > > (mailto:mccu...@gmail.com)
> > > > (mailto:mccu...@gmail.com)> wrote:
> > > > >  
> > > > > > Hi Dan,
> > > > > >  
> > > > > > Constructor injection (and component injection) is working for me
> > > > with
> > > > > > Maven 3.3.9 if I follow the example in
> > > > >  
> > > >  
> > > > http://maven.apache.org/maven-
> > > > > > jsr330.html
> > > > > >  
> > > > > > Is your plugin code available somewhere?
> > > > > >  
> > > > > > PS. at the moment Maven doesn’t enable container support for JSR-250
> > > > > > lifecycle, but it is implemented by Sisu under a feature flag:
> > > > > >  
> > > > > > https://github.com/eclipse/sisu.plexus/blob/releases/0.3.
> > > > > > 3/org.eclipse.sisu.plexus/src/org/codehaus/plexus/
> > > > > > ContainerConfiguration.java#L62
> > > > > >  
> > > > > > --
> > > > > > Cheers, Stuart
> > > > > >  
> > > > > >  
> > > > > > On Wednesday, 31 August 2016 at 16:59, Dan Tran wrote:
> > > > > >  
> > > > > > > Hi Thomas,
> > > > > > >  
> > > > > > > You are right!!! looking for how to fix this...
> > > > > > >  
> > > > > > > The only thing working for me is field injection at MOJO. event 
> > > > > > > The
> > > > > > > constructor injection ( as documented) at MOJO is not.
> > > > > > >  
> > > > > > > Thanks
> > > > > > >  
> > > > > > > -Dan
> > > > > > >  
> > > > > > > On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer 
> > > > > > > <t.bro...@gmail.com (mailto:t.bro...@gmail.com)
> > > > (mailto:t.bro...@gmail.com)
> > > > > > (mailto:t.bro...@gmail.com)> wrote:
> > > > > > >  
> > > > > > > > On Wed, Aug 31, 2016 at 8:43 AM Dan Tran <dant...@gmail.com 
> > > > > > > > (mailto:dant...@gmail.com)
> > > > (mailto:dant...@gmail.com) (mailto:
> > > > > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > > > > > >  
> > > > > > > > > Hi
> > > > > > > > >  
> > > > > > > > > I have a need to inject my jsr330 component into my plugins[1]
> > > > and I
> > > > > > > > > found 2 issues
> > > > > > > > >  
> > > > > > > > > 1. @Inject under MOJO works, but my singleton component
> > > > @PreDestroy
> > > > > > never
> > > > > > > > > got called
> > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > > > @PreDestroy is not part of JSR 330, it's a CDI thing, so no
> > > > wonder
> > > > > > it's not
> > > > > > > > called.
> > > > > > >  
> > > > > >  
> > > > > >  
> > > > >  
> > > >  
> > > >  
> > >  
> > >  
> >  
> >  
>  
>  
>  

Re: Maven Plugin and JSR330

[Stuart McCulloch]

On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
> Hi Stuart
>  
> Thanks for helping out.
>  
> I have 3 mojos, sharing one singleton component which depends on another
> singleton component thru injection. All working now via both injection type
> ( after some cleanup)
>  
> should I file a JIRA to enable JSR-250 support fo rmaven 3.4?
Sure - send me the ticket number and I’ll add some commentary this weekend
> looking forward to use it
>  
> Thanks
>  
> -Dan
>  
>  
>  
> On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch <mccu...@gmail.com 
> (mailto:mccu...@gmail.com)> wrote:
>  
> > Hi Dan,
> >  
> > Constructor injection (and component injection) is working for me with
> > Maven 3.3.9 if I follow the example in http://maven.apache.org/maven-
> > jsr330.html
> >  
> > Is your plugin code available somewhere?
> >  
> > PS. at the moment Maven doesn’t enable container support for JSR-250
> > lifecycle, but it is implemented by Sisu under a feature flag:
> >  
> > https://github.com/eclipse/sisu.plexus/blob/releases/0.3.
> > 3/org.eclipse.sisu.plexus/src/org/codehaus/plexus/
> > ContainerConfiguration.java#L62
> >  
> > --
> > Cheers, Stuart
> >  
> >  
> > On Wednesday, 31 August 2016 at 16:59, Dan Tran wrote:
> >  
> > > Hi Thomas,
> > >  
> > > You are right!!! looking for how to fix this...
> > >  
> > > The only thing working for me is field injection at MOJO. event The
> > > constructor injection ( as documented) at MOJO is not.
> > >  
> > > Thanks
> > >  
> > > -Dan
> > >  
> > > On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer <t.bro...@gmail.com 
> > > (mailto:t.bro...@gmail.com)
> > (mailto:t.bro...@gmail.com)> wrote:
> > >  
> > > > On Wed, Aug 31, 2016 at 8:43 AM Dan Tran <dant...@gmail.com 
> > > > (mailto:dant...@gmail.com) (mailto:
> > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > >  
> > > > > Hi
> > > > >  
> > > > > I have a need to inject my jsr330 component into my plugins[1] and I
> > > > > found 2 issues
> > > > >  
> > > > > 1. @Inject under MOJO works, but my singleton component @PreDestroy
> > never
> > > > > got called
> > > >  
> > > >  
> > > >  
> > > > @PreDestroy is not part of JSR 330, it's a CDI thing, so no wonder
> > it's not
> > > > called.
> > >  
> >  
> >  
>  

Re: Maven Plugin and JSR330

[Stuart McCulloch]

Hi Dan,  

Constructor injection (and component injection) is working for me with Maven 
3.3.9 if I follow the example in http://maven.apache.org/maven-jsr330.html

Is your plugin code available somewhere?  

PS. at the moment Maven doesn’t enable container support for JSR-250 lifecycle, 
but it is implemented by Sisu under a feature flag:

https://github.com/eclipse/sisu.plexus/blob/releases/0.3.3/org.eclipse.sisu.plexus/src/org/codehaus/plexus/ContainerConfiguration.java#L62

--  
Cheers, Stuart


On Wednesday, 31 August 2016 at 16:59, Dan Tran wrote:

> Hi Thomas,
>  
> You are right!!! looking for how to fix this...
>  
> The only thing working for me is field injection at MOJO. event The
> constructor injection ( as documented) at MOJO is not.
>  
> Thanks
>  
> -Dan
>  
> On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer  (mailto:t.bro...@gmail.com)> wrote:
>  
> > On Wed, Aug 31, 2016 at 8:43 AM Dan Tran  > (mailto:dant...@gmail.com)> wrote:
> >  
> > > Hi
> > >  
> > > I have a need to inject my jsr330 component into my plugins[1] and I
> > > found 2 issues
> > >  
> > > 1. @Inject under MOJO works, but my singleton component @PreDestroy never
> > > got called
> > >  
> >  
> >  
> > @PreDestroy is not part of JSR 330, it's a CDI thing, so no wonder it's not
> > called.
> >  
>  
>  
>  

Re: Why is my maven-compiler-plugin out of date ?

[Stuart McCulloch]

If you don’t configure a specific version in your pom for one of the standard 
plugins, Maven will use the version specified in the default lifecycle bindings.

For example Maven 3.3.3, defaults to maven-compiler-plugin 3.1:

https://github.com/apache/maven/blob/maven-3.3.3/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml#L117

The default bindings are not always updated to the most recent releases, it 
depends how long they’ve been available and whether there’s a pressing need to 
update.

Also since people might use different versions of Maven to build your project, 
best practise is to always define the versions of plugins in your pom:

https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Introduction
 (see “important note”)

which makes builds more reproducible in the future.

HTH  

On Wednesday, 5 August 2015 at 16:11, Ron Wheeler wrote:

 Can you see where the compiler plugin is added to your build?
 Parent pom, project pom
  
 Does this help.
 https://maven.apache.org/pom.html#Plugin_Management
  
 On 05/08/2015 10:58 AM, sreya...@yahoo.com.INVALID 
 (mailto:sreya...@yahoo.com.INVALID) wrote:
  I downloaded the latest version of Maven from their site and am using it in 
  Eclipse. But it seems my maven-compiler-plugin is out of date ie. version 
  3.1 while according to this page the most recent version is 3.3. First of 
  all if I am using the latest version of maven why do I have to use an 
  outdated plugin ? Secondly why is it out of date ? I looked up the 
  Super-POM and nothing about the compiler plugin was referenced there.
   
   
   
   
   
   
   
  Regards
  Sreyan Chakravarty
   
  
  
  
 --  
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com (mailto:rwhee...@artifact-software.com)
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102
  
  
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
 (mailto:users-unsubscr...@maven.apache.org)
 For additional commands, e-mail: users-h...@maven.apache.org 
 (mailto:users-h...@maven.apache.org)
  
  

Re: maven-checkstyle-plugin does not include test resources

[Stuart McCulloch]

On Monday, 25 May 2015 at 09:46, WonderCsabo wrote:
 The documentation says it includes these resources by default, but apparently
 it never does.
 
 After examining the code, it seems CheckstyleViolationCheckMojo.execute()
 forgets to call request.setTestResources(), hence that is always null and
 skipped from audit.
 
 I wanted to file a report on JIRA, but it seems codehaus is shutting down
 and i cannot add new issues anymore. :S
 
 

FYI, you can log new issues at https://issues.apache.org/jira/browse/MCHECKSTYLE

See also https://maven.apache.org/issue-tracking.html and 
https://maven.apache.org/plugins/index.html for updated links to the new JIRA 
projects
 
 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/maven-checkstyle-plugin-does-not-include-test-resources-tp5835797.html
 Sent from the Maven - Users mailing list archive at Nabble.com 
 (http://Nabble.com).
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
 (mailto:users-unsubscr...@maven.apache.org)
 For additional commands, e-mail: users-h...@maven.apache.org 
 (mailto:users-h...@maven.apache.org)

Re: Integration Test: Dependency problem

[Stuart McCulloch]

The log shows that it’s looking for artifacts with an extension of ‘bundle’, 
whereas the bundle packaging type actually produces artifacts with an extension 
of ‘jar’ - this suggests that the bundle lifecycle extension has not been 
installed for the itest project.

What does the sip-detection pom.xml look like? Have you tried adding 
maven-bundle-plugin to the pluginManagement of that pom.xml with 
extensionstrue/extensions ?

What do the dependency declarations in the itest pom.xml look like?  

On Friday, 27 March 2015 at 08:04, Christian Eugster wrote:

 Hi,
  
 I am quite new to maven and I have the following problem:
  
 I have a project with several modules (api and impl) and one of them is an 
 integration test module, that contains only a test class. The pom of this 
 module references (as I see) all dependencies. When I run the parents pom all 
 modules are successfully installed, even the itest module seems to run 
 successfully (as the log says). When I run only the itest module using mvn 
 test I get dependency errors, saying that the other modules could not be 
 found and the run ends with errors (while running the parents pom ends 
 successfully). I checked also the local repository for the compiled jars and 
 all are there. I do not understand what is going wrong. Can anyone give me a 
 hint?
  
 I am running on yosemite, eclipse juno with m2e (but with mvn form 
 commandline it is the same). Following the log for the parent poms run, that 
 for the itest run
  
 Thank you in advance for any hints!
  
 Regards Christian
  
 The log for parents pom run:
  
 Christians-Docuteam-MacBook:sip-detection christian$ mvn install
 [INFO] Scanning for projects...
 [INFO] 
 
 [INFO] Reactor Build Order:
 [INFO]  
 [INFO] sip-detection
 [INFO] sip-detector-api Bundle
 [INFO] sip-detector-matterhorn Blueprint Bundle
 [INFO] sip-detection-processor bundle
 [INFO] sip-detection-features
 [INFO] sip-detector-itest
 [INFO]  
 [INFO] 
 
 [INFO] Building sip-detection 0.0.1-SNAPSHOT
 [INFO] 
 
 [INFO]  
 [INFO] --- maven-install-plugin:2.4:install (default-install) @ sip-detection 
 ---
 [INFO] Installing 
 /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/pom.xml
  to 
 /Users/christian/.m2/repository/ch/eugster/herakles/sip-detection/0.0.1-SNAPSHOT/sip-detection-0.0.1-SNAPSHOT.pom
 [INFO]  
 [INFO] 
 
 [INFO] Building sip-detector-api Bundle 0.0.1-SNAPSHOT
 [INFO] 
 
 [INFO]  
 [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ 
 sip-detector-api ---
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] skip non existing resourceDirectory 
 /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/src/main/resources
 [INFO]  
 [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ 
 sip-detector-api ---
 [INFO] Nothing to compile - all classes are up to date
 [INFO]  
 [INFO] --- maven-resources-plugin:2.7:testResources (default-testResources) @ 
 sip-detector-api ---
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] skip non existing resourceDirectory 
 /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/src/test/resources
 [INFO]  
 [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
 sip-detector-api ---
 [INFO] No sources to compile
 [INFO]  
 [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ 
 sip-detector-api ---
 [INFO]  
 [INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @ 
 sip-detector-api ---
 [INFO]  
 [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
 sip-detector-api ---
 [INFO] Installing 
 /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/target/sip-detector-api-0.0.1-SNAPSHOT.jar
  to 
 /Users/christian/.m2/repository/ch/eugster/herakles/sip-detector-api/0.0.1-SNAPSHOT/sip-detector-api-0.0.1-SNAPSHOT.jar
 [INFO] Installing 
 /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/pom.xml
  to 
 /Users/christian/.m2/repository/ch/eugster/herakles/sip-detector-api/0.0.1-SNAPSHOT/sip-detector-api-0.0.1-SNAPSHOT.pom
 [INFO]  
 [INFO] --- maven-bundle-plugin:2.5.3:install (default-install) @ 
 sip-detector-api ---
 [INFO] Installing 
 ch/eugster/herakles/sip-detector-api/0.0.1-SNAPSHOT/sip-detector-api-0.0.1-SNAPSHOT.jar
 [INFO] Writing OBR metadata
 [INFO]  
 [INFO] 
 
 

Re: Integration Test: Dependency problem

[Stuart McCulloch]

type is not quite the same as packaging - packaging defines the lifecycle
used to build the project (what plugins get called for each phase) whereas
type is more about the final artifact and defines the extension amongst
other things.

The bundle lifecycle does define a type called 'bundle' with an extension
of 'jar'  - but as this is not a core type you need to add the bundle
plugin and set extensions to true - otherwise if you depend on artifacts
with type 'bundle' maven will assume the extension should also be
'.bundle'  (which is why the lookup was failing earlier)

But since bundles are also jars then you can simplify this when declaring
dependencies and just use the default dependency type (which has the same
extension: '.jar') which then means you don't need to pull in the bundle
plugin as an extension.
On 27 Mar 2015 17:00, Christian Eugster christian.eugs...@gmx.net wrote:

 So I can remove the type tag from dependencies. Is then tag type only used
 once, when introducing a new artifact in tag packaging?

 Regards Christian

 Christian Eugster
 Grissian 14
 I-39010 Tisens
 I:  +39 0473 420 873
 CH: +41 79 107 92 27
 christian.eugs...@gmx.net




  Am 27.03.2015 um 17:50 schrieb Stuart McCulloch mccu...@gmail.com:
 
  I see you're declaring dependencies with typebundle/type whereas you
  should just leave them with the default type (jar). While the packaging
  type is bundle (to activate the different packaging lifecycle) the
  artifacts produced are declared as type jar and can be referenced as
  dependencies with the default type.
 
  If you do remove typebundle/type then you likely won't need to add
 the
  bundle plugin to the top-level plugInManagement (though it is still good
  practice to pin plugin versions in your corporate pom)
  On 27 Mar 2015 16:36, Christian Eugster christian.eugs...@gmx.net
 wrote:
 
  Hi,
 
  but as  I understand, the bundles have - as the normal jars - the
  extension jar, the unique difference are some extra entries in the
  MANIFEST.MF file. Is that wrong?
 
  I added the frequently used dependencies to the parents pom as managed
  dependencies and added those required for itest in the itest pom. I
 added
  as you proposed the maven-bundle-plugin to the plugin management of the
  parent pom. So the poms look like:
 
 
  sip-detection POM:
 
  ?xml version=1.0 encoding=UTF-8?
  project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
  http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
  http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/xsd/maven-4.0.0.xsd;
 modelVersion4.0.0/modelVersion
 
 parent
 groupIdch.eugster.herakles/groupId
 artifactIdingest/artifactId
 version0.0.1-SNAPSHOT/version
 /parent
 
 artifactIdsip-detection/artifactId
 packagingpom/packaging
 
 modules
 modulesip-detector-api/module
 modulesip-detector-matterhorn/module
 modulesip-detection-processor/module
 modulesip-detection-features/module
 modulesip-detector-itest/module
   /modules
 
  /project
 
  itest POM:
 
  ?xml version=1.0 encoding=UTF-8?
  project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
  http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
  http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/xsd/maven-4.0.0.xsd;
 
 !--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at
 
  http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
 --
 
 modelVersion4.0.0/modelVersion
 
 parent
 artifactIdsip-detection/artifactId
 groupIdch.eugster.herakles/groupId
 version0.0.1-SNAPSHOT/version
 /parent
 
 artifactIdsip-detector-itest/artifactId
 packagingpom/packaging
 
 namesip-detector-itest/name
 descriptionsip-detector-itest/description
 
 properties
 pax.exam.version4.4.0/pax.exam.version
 karaf.version3.0.3/karaf.version
 /properties
 
 dependencies
 dependency
 groupIdch.eugster.herakles/groupId
 artifactIdsip-detector-api/artifactId
 version0.0.1-SNAPSHOT

Re: Integration Test: Dependency problem

[Stuart McCulloch]

I see you're declaring dependencies with typebundle/type whereas you
should just leave them with the default type (jar). While the packaging
type is bundle (to activate the different packaging lifecycle) the
artifacts produced are declared as type jar and can be referenced as
dependencies with the default type.

If you do remove typebundle/type then you likely won't need to add the
bundle plugin to the top-level plugInManagement (though it is still good
practice to pin plugin versions in your corporate pom)
On 27 Mar 2015 16:36, Christian Eugster christian.eugs...@gmx.net wrote:

 Hi,

 but as  I understand, the bundles have - as the normal jars - the
 extension jar, the unique difference are some extra entries in the
 MANIFEST.MF file. Is that wrong?

 I added the frequently used dependencies to the parents pom as managed
 dependencies and added those required for itest in the itest pom. I added
 as you proposed the maven-bundle-plugin to the plugin management of the
 parent pom. So the poms look like:


 sip-detection POM:

 ?xml version=1.0 encoding=UTF-8?
 project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
 http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
 http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
 modelVersion4.0.0/modelVersion

 parent
 groupIdch.eugster.herakles/groupId
 artifactIdingest/artifactId
 version0.0.1-SNAPSHOT/version
 /parent

 artifactIdsip-detection/artifactId
 packagingpom/packaging

 modules
 modulesip-detector-api/module
 modulesip-detector-matterhorn/module
 modulesip-detection-processor/module
 modulesip-detection-features/module
 modulesip-detector-itest/module
   /modules

 /project

 itest POM:

 ?xml version=1.0 encoding=UTF-8?
 project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
 http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
 http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/maven-4.0.0.xsd;

 !--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
 --

 modelVersion4.0.0/modelVersion

 parent
 artifactIdsip-detection/artifactId
 groupIdch.eugster.herakles/groupId
 version0.0.1-SNAPSHOT/version
 /parent

 artifactIdsip-detector-itest/artifactId
 packagingpom/packaging

 namesip-detector-itest/name
 descriptionsip-detector-itest/description

 properties
 pax.exam.version4.4.0/pax.exam.version
 karaf.version3.0.3/karaf.version
 /properties

 dependencies
 dependency
 groupIdch.eugster.herakles/groupId
 artifactIdsip-detector-api/artifactId
 version0.0.1-SNAPSHOT/version
 typebundle/type
 /dependency
 dependency
 groupIdch.eugster.herakles/groupId
 artifactIdsip-detector-matterhorn/artifactId
 version${project.version}/version
 typebundle/type
 /dependency
 dependency
 groupIdch.eugster.herakles/groupId
 artifactIdsip-matterhorn-profile/artifactId
 version${project.version}/version
 typebundle/type
 /dependency
 dependency
 groupIdch.eugster.herakles/groupId
 artifactIdsip-api/artifactId
 version${project.version}/version
 typebundle/type
 /dependency
 dependency
 groupIdch.eugster.herakles/groupId
 artifactIdsip-detection-processor/artifactId
 version${project.version}/version
 typebundle/type
 /dependency
 dependency
 groupIdorg.apache.camel/groupId
 

Re: mvn clean package requests access rights for local Nexus repository

[Stuart McCulloch]

On Thursday, 19 March 2015 at 10:41, Markus Karg wrote:
 As I said I cannot reproduce the bug anymore, so do you think the requested 
 test makes any sense still?
  
  

The Nexus system feeds record authz/authc events as well as any upload attempts:

http://books.sonatype.com/nexus-book/reference/using-sect-feeds.html

this should help identify what exactly happened from the perspective of the 
server
  
 -Ursprüngliche Nachricht-
 Von: Martin Gainty [mailto:mgai...@hotmail.com]  
 Gesendet: Donnerstag, 19. März 2015 02:04
 An: users@maven.apache.org (mailto:users@maven.apache.org)
 Betreff: RE: AW: mvn clean package requests access rights for local Nexus 
 repository
  
 as bernd suggested can you view possible access when you enable -X?
 might also help to see extension errors with -e mvn -e -X package  
 package.out can we view package.out?
  
 I would be interested looking at the netstat deltas specifically
 shnetstat -a  netstat_before.log
 run command
 shmvn -X package
  
 run another shell and view any new network connections
  netstat -a  netstat_after.log
  
  
 any deltas between netstat_before.log and netstat_after.log can you display 
 both here so we can diff the 2 files?
 ?
 Martin
  
  
  From: k...@quipsy.de (mailto:k...@quipsy.de)
  To: users@maven.apache.org (mailto:users@maven.apache.org)
  Date: Wed, 18 Mar 2015 16:42:06 +0100
  Subject: AW: mvn clean package requests access rights for local  
  Nexus repository
   
  Bernd,
   
  your theory failed the test:
   
  * Unplugged USB stick, so Maven has no passwords anymore
  * Removed .m2\repository folder from disk, so Maven is enforced to  
  download rather everything newly from our Nexus mirror
  * mvn clean package built maven-dependency-plugin without any  
  problem
   
  Conclusion: It is definitively NOT a download problem, but still supports 
  my theory that maven-dependency-plugin wants to UPLOAD something at 
  package phase.
   
  If I just would have kept the protocol earlier today, I could tell you  
  what thing actually it was... :-(
   
  Regards
  -Markus
   
   
  -Ursprüngliche Nachricht-
  Von: Bernd [mailto:e...@zusammenkunft.net]
  Gesendet: Mittwoch, 18. März 2015 14:27
  An: Maven Users List
  Betreff: Re: mvn clean package requests access rights for local  
  Nexus repository
   
  Hello,
   
  It sounds more like a download as it does not ask again. You can wipe your 
  local repo cache (or use a different one in settings.xml) and try to 
  reproduce the problem. If you run with -X and actually keep the maven log 
  output you should be able to see the access in question.
   
  Gruss
  Bernd
  Am 18.03.2015 14:02 schrieb Markus Karg k...@quipsy.de 
  (mailto:k...@quipsy.de):
   
   Dear Maven Experts,

   just did svn checkout to get trunk of maven-dependency-plugin, and  
   wanted to build it using mvn clean package. What then happened is  
   really
   scary:


   * It complained about missing access on that path where my USB
   stick stores the encrypted password for my local Nexus repository.

   * My local Nexus repository is a mirror of central with public
   access, only demanding passwords for uploads.

   * I plugged in my stick, did mvn clean package again, and it
   worked pretty well.

   * REMOVED my stick, and since then mvn clean package works
   without, still!

   That looks if packaging maven-dependency-plugin would need to  
   WRITE into my Nexus (possibly central?) at package phase, if a  
   particular thing is not found there.

   This is scary, as nobody expects UPLOADS are done at packaging.

   If somebody has an explanation why that happens, I'd ask him to  
   publish here, so everybody will understand the reason for this! :)

   Regards
   -Markus

   
  B KKK
  KCB [ X ܚX KK[XZ[
   
  
 \ \ ][ X ܚX PX] [ \X K ܙ B ܈Y][
  ۘ[ [X[ K[XZ[
  
 \ \ Z[X] [ \X K ܙ B
  
  
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
 (mailto:users-unsubscr...@maven.apache.org)
 For additional commands, e-mail: users-h...@maven.apache.org 
 (mailto:users-h...@maven.apache.org)
  
  

Re: Injection using Sisu doubt

[Stuart McCulloch]

Assuming you’re using Maven 3.1.1 or later then yes, that should work.  

--  
Cheers, Stuart


On Monday, 16 March 2015 at 18:09, Cristiano Gavião wrote:

 Hello,
  
 I've create a mojo and set it to use sisu based injection.
  
 I added to this mojo a constructor like this:
  
 @Inject
 public MyMojo( RuntimeInformation runtimeInformation,
 MavenProjectHelper projectHelper, BuildContext
 buildContextr) {
  
 this.buildContext = buildContext;
 this.runtimeInformation = runtimeInformation;
 this.projectHelper = projectHelper;
 }
  
 and it worked properly.
  
 Now suppose that I have a pojo component annotated with a @Named  
 annotation and it should be consumed by the mojo:
  
 @Named
 public MyPojo{
  
 }
  
 Is it possible to inject objects from the maven classes into an instance  
 of this pojo as I did with the mojo above?
  
 thanks,
  
 Cristiano  

Re: source-plugin vs, the initialize phase?

[Stuart McCulloch]

Use the jar-no-fork and test-jar-no-fork goals of the maven-source-plugin - 
these won’t fork the build (which is what is causing initialize to run multiple 
times)

On Thursday, 15 January 2015 at 16:24, org.apache.maven.u...@io7m.com wrote:

 Hi.
  
 I have a custom plugin that inserts some extra files into the jars
 produced by the jar plugin. Because of the way the plugin works, it
 will fail if it tries to make the modifications to a jar file that has
 already had the modifications made. For reasons that aren't really
 relevant here, modifying the plugin to cope with jars that have been  
 modified isn't feasible.
  
 The simplest way to resolve this issue seems to be to have the clean  
 plugin delete any existing jar file unconditionally (so if the user  
 doesn't specify clean on the command line, the module is cleaned  
 anyway and the plugin doesn't have to receive an already-edited jar).
  
 Anyway, the following pom file unconditonally runs the clean plugin
 in the initialize phase:
  
 ?xml version=1.0 encoding=UTF-8?
 project
 xmlns=http://maven.apache.org/POM/4.0.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
  
 modelVersion4.0.0/modelVersion
 groupIdcom.io7m.example/groupId
 artifactIdinit-test/artifactId
 version0.1.0/version
 packagingjar/packaging
  
 prerequisites
 maven3.0.3/maven
 /prerequisites
  
 properties
 project.build.sourceEncodingUTF-8/project.build.sourceEncoding
 project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding
 /properties
  
 dependencies
 /dependencies
  
 build
 plugins
 !-- Clean all artifacts automatically at the start of the build. --
 plugin
 artifactIdmaven-clean-plugin/artifactId
 version2.5/version
 executions
 execution
 idauto-clean/id
 phaseinitialize/phase
 goals
 goalclean/goal
 /goals
 /execution
 /executions
 /plugin
  
 !-- Create source jar --
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-source-plugin/artifactId
 version2.2.1/version
 executions
 execution
 phasepackage/phase
 goals
 goaljar/goal
 goaltest-jar/goal
 /goals
 /execution
 /executions
 /plugin
 /plugins
 /build
 /project
  
 This would be fine, except that if you attempt to run the above pom with mvn 
 verify,
 the maven-source-plugin will cause the maven-clean-plugin to be executed 
 twice:
  
 [INFO] Scanning for projects...
 [INFO]  
 [INFO] 
 
 [INFO] Building init-test 0.1.0
 [INFO] 
 
 [INFO]  
 [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test ---
 [INFO]  
 [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
 init-test ---
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] skip non existing resourceDirectory 
 /tmp/sandbox/init-test/src/main/resources
 [INFO]  
 [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ init-test ---
 [INFO] No sources to compile
 [INFO]  
 [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
 init-test ---
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] skip non existing resourceDirectory 
 /tmp/sandbox/init-test/src/test/resources
 [INFO]  
 [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ 
 init-test ---
 [INFO] No sources to compile
 [INFO]  
 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ init-test ---
 [INFO] No tests to run.
 [INFO]  
 [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ init-test ---
 [WARNING] JAR will be empty - no content was marked for inclusion!
 [INFO] Building jar: /tmp/sandbox/init-test/target/init-test-0.1.0.jar
 [INFO]  
 [INFO]  maven-source-plugin:2.2.1:jar (default)  generate-sources @ 
 init-test 
 [INFO]  
 [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test ---
 [INFO] Deleting /tmp/sandbox/init-test/target
 [INFO]  
 [INFO]  maven-source-plugin:2.2.1:jar (default)  generate-sources @ 
 init-test 
 [INFO]  
 [INFO] --- maven-source-plugin:2.2.1:jar (default) @ init-test ---
 [INFO] No sources in project. Archive not created.
 [INFO]  
 [INFO]  maven-source-plugin:2.2.1:test-jar (default)  generate-sources @ 
 init-test 
 [INFO]  
 [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test ---
 [INFO]  
 [INFO]  maven-source-plugin:2.2.1:test-jar (default)  generate-sources @ 
 init-test 
 [INFO]  
 [INFO] --- maven-source-plugin:2.2.1:test-jar (default) @ init-test ---
 [INFO] No sources in project. Archive not created.
 [INFO] 
 
 [INFO] BUILD SUCCESS
 [INFO] 
 
 [INFO] Total time: 0.925 s
 [INFO] Finished at: 2015-01-15T16:05:19+00:00
 [INFO] Final Memory: 10M/228M
 [INFO] 

Re: Exception overlaying zip in war

[Stuart McCulloch]

On Monday, 8 December 2014 at 16:24, Paul Benedict wrote:
 I configured the WAR plugin to overlay a zip file. Nothing fancy. Here's
 the config:
 
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-war-plugin/artifactId
 version2.5/version
 configuration
 overlays
 groupIdorg.company/groupId
 
 

^ missing overlay ... /overlay ? 
 artifactIdui/artifactId
 typezip/type
 /overlays
 /configuration
 /plugin
 
 I get an exception:
 java.lang.ClassCastException: java.lang.String cannot be
 cast to org.apache.maven.plugin.war.Overlay
 at
 org.apache.maven.plugin.war.overlay.OverlayManager.initialize(OverlayManager.java:122)
 
 I looked at the WAR source. I don't know how a String is making it into the
 ListOverlay collection. Any WAR developers here?
 
 Cheers,
 Paul
 
 

Re: Sign and deploy a pom-only artifact to maven central

[Stuart McCulloch]

Does your pom have a release profile that executes gpg signing? ie. like in
https://github.com/sonatype/oss-parents/blob/master/forge-parent/pom.xml
On 9 Nov 2014 11:51, Simon Taddiken simon.taddi...@gmail.com wrote:

 Hi,

 I'm trying to introduce a common parent pom for my projects. So I have
 created a maven artifact which only consists of that pom.xml and no further
 sources, resources or whatsoever. On a normal project, upon deploying, a
 artifactId-version.pom and corresponding .asc is created within the
 target folder.

 However, on my pom-only project, there is no signed output for the pom
 file and thus deploying to maven central fails (staging actually works, but
 the staging repo can not be closed because the central sync requirement
 Signature Validation fails).

 I'm basically following the guide here:
 http://central.sonatype.org/pages/apache-maven.html
 for deploying to maven central.

 How can I force a signed output for the pom file?

 --
 Regards
 Simon

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

Re: Javadoc plugin parsing problem

[Stuart McCulloch]

On Wednesday, 22 October 2014 at 14:08, Michal Konopa wrote:
 Hello all,
 I'm experimenting a little bit with aggregating Javadoc from dependency 
 sources - according to:
 http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate-dependency-sources.html
  
 document.
 
 I put the Javadoc plugin inside build tag of my POM :
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 version2.10.1/version
 configuration
 outputDirectory${project.build.directory}/javadoc/outputDirectory
 reportOutputDirectory${project.reporting.outputDirectory}/javadoc/reportOutputDirectory
 /configuration
 executions
 execution
 idattach-javadocs/id
 phasepackage/phase
 goals
 goaljar/goal
 /goals
 configuration
 includeDependencySourcestrue/includeDependencySources
 dependencySourceExcludescommons-cli:*/dependencySourceExcludes
 
 

^ this is wrong, it should be:

  dependencySourceExcludes
dependencySourceExcludecommons-cli:*/dependencySourceExclude
  /dependencySourceExcludes


as in the example at 
http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate-dependency-sources.html#Fine-Tuning_Included_Dependencies

( BTW the error indicates this because it says it is expecting a list of 
elements but is instead being given a string )
 /configuration
 /execution
 /executions
 /plugin
 
 But I got the following error:
 
 Failed to execute goal 
 org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar 
 (attach-javadocs) on project simply-iqrf-dpa-v210: Unable to parse 
 configuration of mojo 
 org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar for parameter 
 dependencySourceExcludes: Cannot assign configuration entry 
 'dependencySourceExcludes' with value 'commons-cli:*' of type 
 java.lang.String to property of type java.util.List - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
 execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar 
 (attach-javadocs) on project simply-iqrf-dpa-v210: Unable to parse 
 configuration of mojo 
 org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar for parameter 
 dependencySourceExcludes: Cannot assign configuration entry 
 'dependencySourceExcludes' with value 'commons-cli:*' of type 
 java.lang.String to property of type java.util.List
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:221)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
 at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
 at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
 at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable 
 to parse configuration of mojo 
 org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar for parameter 
 dependencySourceExcludes: Cannot assign configuration entry 
 'dependencySourceExcludes' with value 'commons-cli:*' of type 
 java.lang.String to property of type java.util.List
 at 
 org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:597)
 at 
 org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:529)
 at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:92)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
 ... 19 more
 Caused by: 
 org.codehaus.plexus.component.configurator.ComponentConfigurationException: 
 Cannot assign configuration entry 'dependencySourceExcludes' with value 
 'commons-cli:*' of type java.lang.String to property 

Re: systemPropertyVariables

[Stuart McCulloch]

On 19 Sep 2014 09:09, Edmond chouaffé e...@in-telegence.net wrote:

 Hi guys.

 I have been struggling to get systemPropertyVariables from the
maven-surefire-plugin working.
 I am running an ubunto machine where I have defined the JBOSS_HOME
variable as such in the .profile file: export JBOSS_HOME=test.
 However i can't override that value with systemPropertyVariables:

Since JBOSS_HOME is an environment variable, I would try using the
environmentVariables option to override it (available in surefire 2.13 and
above)


 systemPropertyVariables

jboss.home${project.basedir}/target/wildfly-8.1.0.Final/jboss.home

JBOSS_HOME${project.basedir}/target/wildfly-8.1.0.Final/JBOSS_HOME

jbossHome${project.basedir}/target/wildfly-8.1.0.Final/jbossHome
 /systemPropertyVariables

 As you can notice, I've tried numerous alternatives, but none of them
does work.

 --
 Regards
 Edmond Chouaffé
 Master of Science
 Softwareentwickler
 
 IN-telegence GmbH
 Oskar-Jäger-Str. 125
 D-50825 Köln
   Tel:
   +49 (0)221 - 260 15 84

   Fax:
   +49 (0)221 - 260 15 09

   E-mail:
   e...@in-telegence.net

   Home:
   www.in-telegence.net


 Registergericht AG Köln - HRB 34038 | USt-ID Nr. DE 210 882 245 |
Geschäftsführende Gesellschafter: Christian Plätke und Holger Jansen
 
 ACHTUNG:
 Diese Nachricht sowie eventuelle Anhänge können geschützte oder
vertrauliche Information enthalten und ist ausschließlich für den
bezeichneten Adressaten bestimmt. Andere Personen dürfen den Inhalt dieser
Nachricht weder offenbaren noch kopieren oder verteilen. Die weitere
Nutzung, Verbreitung oder Vervielfältigung dieser E-Mail ist nicht erlaubt
und gegebenenfalls gesetzeswidrig. Sollten Sie diese E-Mail irrtümlich
erhalten haben oder nicht der autorisierte Empfänger sein, so löschen Sie
diese Nachricht sowie deren Anhänge bitte unverzüglich und informieren Sie
den Absender.

Re: systemPropertyVariables

[Stuart McCulloch]

On 19 Sep 2014 11:12, Stuart McCulloch mccu...@gmail.com wrote:

 On 19 Sep 2014 09:09, Edmond chouaffé e...@in-telegence.net wrote:
 
  Hi guys.
 
  I have been struggling to get systemPropertyVariables from the
maven-surefire-plugin working.
  I am running an ubunto machine where I have defined the JBOSS_HOME
variable as such in the .profile file: export JBOSS_HOME=test.
  However i can't override that value with systemPropertyVariables:

 Since JBOSS_HOME is an environment variable, I would try using the
environmentVariables option to override it (available in surefire 2.13 and
above)

typo: should read 2.1.3 and above


 
  systemPropertyVariables
 
jboss.home${project.basedir}/target/wildfly-8.1.0.Final/jboss.home
 
JBOSS_HOME${project.basedir}/target/wildfly-8.1.0.Final/JBOSS_HOME
 
jbossHome${project.basedir}/target/wildfly-8.1.0.Final/jbossHome
  /systemPropertyVariables
 
  As you can notice, I've tried numerous alternatives, but none of them
does work.
 
  --
  Regards
  Edmond Chouaffé
  Master of Science
  Softwareentwickler
  
  IN-telegence GmbH
  Oskar-Jäger-Str. 125
  D-50825 Köln
Tel:
+49 (0)221 - 260 15 84
 
Fax:
+49 (0)221 - 260 15 09
 
E-mail:
e...@in-telegence.net

 
Home:
www.in-telegence.net
 
 
  Registergericht AG Köln - HRB 34038 | USt-ID Nr. DE 210 882 245 |
Geschäftsführende Gesellschafter: Christian Plätke und Holger Jansen
  
  ACHTUNG:
  Diese Nachricht sowie eventuelle Anhänge können geschützte oder
vertrauliche Information enthalten und ist ausschließlich für den
bezeichneten Adressaten bestimmt. Andere Personen dürfen den Inhalt dieser
Nachricht weder offenbaren noch kopieren oder verteilen. Die weitere
Nutzung, Verbreitung oder Vervielfältigung dieser E-Mail ist nicht erlaubt
und gegebenenfalls gesetzeswidrig. Sollten Sie diese E-Mail irrtümlich
erhalten haben oder nicht der autorisierte Empfänger sein, so löschen Sie
diese Nachricht sowie deren Anhänge bitte unverzüglich und informieren Sie
den Absender.

Re: maven 3.1.1 crashes on GC overhead limit exceeded with millions of org.eclipse.aether.graph.DefaultDependencyNode

[Stuart McCulloch]

I wonder if this might be related to 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=418250 ?

On 27 Aug 2014, at 04:35, Juven Xu juvens...@gmail.com wrote:

 maven: 3.1.1  
 jdk: 1.7.0_25 Java HotSpot(TM) Server VM (build 23.25-b01, mixed mode)
 
 the error message is:
 
 [INFO] Building buy-client 1.1.8-o2o630-SNAPSHOT
 [INFO] 
   
 [WARNING] The POM for com.taobao.logistics:logistics-common:jar:2.4.5 is 
 invalid, transitive dependencies (if any) will not be available, enable debug 
 logging for more details  
 [WARNING] The POM for 
 com.taobao.thboss:thboss-common:jar:1.0.2-20131230.121421-32 is invalid, 
 transitive dependencies (if any) will not be available, enable debug logging 
 for more details  
 [WARNING] The POM for 
 com.taobao.hbaseextend:hbase-client:jar:1.0.1-20121211.063750-2 is invalid, 
 transitive dependencies (if any) will not be available, enable debug logging 
 for more details  
 [WARNING] The POM for 
 com.taobao.hbaseextend:hbasetransit-client:jar:1.0.1-20121211.064048-1 is 
 invalid, transitive dependencies (if any) will not be available, enable debug 
 logging for more details  
 [WARNING] The POM for 
 com.taobao.sharereport:share-report-common:jar:1.5.1-20121030.080558-17 is 
 invalid, transitive dependencies (if any) will not be available, enable debug 
 logging for more details  
 [WARNING] The POM for 
 com.taobao.trade:tradeback-client:jar:1.0.0-20131118.063752-35 is invalid, 
 transitive dependencies (if any) will not be available, enable debug logging 
 for more details  
 [ERROR] GC overhead limit exceeded - [Help 1]  
 [ERROR]  
 [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
 switch.  
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.  
 [ERROR]  
 [ERROR] For more information about the errors and possible solutions, please 
 read the following articles:  
 [ERROR] [Help 1] 
 http://cwiki.apache.org/confluence/display/MAVEN/OutOfMemoryError
 
 
 the jvm is full and a log of full gc happening, gc stat:
 
  S0 S1 E  O  P YGC YGCTFGCFGCT GCT
  0.00   0.00 100.00 100.00  67.33 505.92539  101.650  107.575
  0.00   0.00 100.00 100.00  67.33 505.92539  101.650  107.575
  0.00   0.00 100.00 100.00  67.33 505.92539  101.650  107.575
  0.00   0.00 100.00 100.00  67.33 505.92540  104.805  110.730
  0.00   0.00 100.00 100.00  67.33 505.92540  104.805  110.730
  0.00   0.00 100.00 100.00  67.33 505.92540  104.805  110.730
  0.00   0.00 100.00 100.00  67.33 505.92541  107.840  113.765
  0.00   0.00 100.00 100.00  67.33 505.92541  107.840  113.765
  0.00   0.00 100.00 100.00  67.33 505.92541  107.840  113.765
  0.00   0.00 100.00 100.00  67.33 505.92542  110.864  116.788
  0.00   0.00 100.00 100.00  67.33 505.92542  110.864  116.788
  0.00   0.00 100.00 100.00  67.33 505.92542  110.864  116.788
  0.00   0.00  95.86 100.00  67.33 505.92542  114.029  119.954
  0.00   0.00 100.00 100.00  67.33 505.92543  114.029  119.954
  0.00   0.00 100.00 100.00  67.33 505.92543  114.029  119.954
  0.00   0.00 100.00 100.00  67.33 505.92543  114.029  119.954
  0.00   0.00 100.00 100.00  67.33 505.92544  117.087  123.011
 
 and the vm is full of org.eclipse.aether.graph.DefaultDependencyNode
 
 $ jmap -histo 4072 | head -30
 
 num #instances #bytes  class name
 --
   1:   5019593  281097208  
 org.eclipse.aether.graph.DefaultDependencyNode
   2:   6075641  145815384  java.util.ArrayList
   3:   6076588  116705216  [Ljava.lang.Object;
   4:   2375373   76011936  
 org.eclipse.aether.internal.impl.DataPool$GraphKey
   5:   2439860   58556640  java.util.HashMap$Entry
   6:231529   34940048  [Ljava.util.HashMap$Entry;
   7:231420   34810936  [Lorg.eclipse.aether.graph.Exclusion;
   8:598180   28712640  
 org.eclipse.aether.repository.RemoteRepository
   9:839969   26879008  java.util.LinkedHashMap$Entry
  10:597260   15767704  
 [Lorg.eclipse.aether.repository.RemoteRepository;
  11:208071   11651976  java.util.LinkedHashMap
  12:5972889556608  java.util.Arrays$ArrayList
  13:5972699556304  
 java.util.Collections$UnmodifiableRandomAccessList
  14:1254797259280  [C
  15: 290993530504  constMethodKlass
  16:1978513165616  java.util.Collections$SingletonList
  17:1977063163296  java.util.HashMap$KeySet
  18:1974763159616  java.util.LinkedHashSet
  19:1973493157584  
 org.eclipse.aether.util.graph.selector.AndDependencySelector
  20:197347

Re: Default version of maven-compiler-plugin

[Stuart McCulloch]

Each Maven distribution has various built-in defaults, you can see the defaults 
for 3.2.1 here:


https://github.com/apache/maven/blob/maven-3.2.1/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml

The compiler plugin is explicitly set to 2.5.1 unless you override the version 
in your pom.xml (I believe this is for stability reasons)

On 25 Jun 2014, at 19:19, John Glass johnglas...@yahoo.com.INVALID wrote:

 Is anyone else experiencing this?
 I'm wondering maybe it's some dependency of one of the other standard plugins.
 With Maven 3.1.1 I get the same dependency (2.5.1), while with Maven 3.0.5 I 
 get an older version (2.3.2)
 
 On Wednesday, June 25, 2014 7:45 PM, John Glass 
 johnglas...@yahoo.com.INVALID wrote:
 
 
 
 No settings.xml in M2_HOME, global settings as per installation default 
 (which is empty).
 I have just reinstalled it and I get the same behavior.
 
 Maven 3.2.1 on Windows 7.
 
 Of course the effective pom shows 2.5.1 usage.
   mvn help:effective-pom
 
 
 
 
 On Wednesday, June 25, 2014 7:36 PM, Ron Wheeler 
 rwhee...@artifact-software.com wrote:
 
 
 
 
 Somehow your project is overriding Maven's desire to use 3.1.
 settings.xml?
 
 Ron
 
 
 On 25/06/2014 1:19 PM, John Glass wrote:
 There is no parent pom referenced from my project's.
 Here's my POM:
 
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
 
groupIdmygroup/groupId
artifactIdmyartifact/artifactId
version0.0.1/version
packagingjar/packaging
 
 /project
 
 
 On Wednesday, June 25, 2014 7:09 PM, Ron Wheeler 
 rwhee...@artifact-software.com wrote:
 
 
 Are you sure that you are not overriding the version in your parent
 POM's dependency management section?
 
 Ron
 
 On 25/06/2014 12:48 PM, John Glass wrote:
 I'm using maven 3.2.1 and when I run maven with -X I notice that 
 version 2.5.1 of the compiler plugin is used:
 
 [DEBUG] Goal: 
 org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile 
 (default-compile)
 However, if I run
 
   mvn help:describe -Dplugin=compiler
 
 I get:
 
 Name: Maven Compiler Plugin
 Description: The Compiler Plugin is used to compile the sources of 
 yourproject.
 Group Id: org.apache.maven.plugins
 Artifact Id: maven-compiler-plugin
 Version: 3.1
 Goal Prefix: compiler
 
 What is the rationale for Maven using 2.5.1?
 
 John
 
 
 
 
 -- 
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com 
 mailto:rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
 mailto:users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org 
 mailto:users-h...@maven.apache.org
 
 
 
 
 
 
 
 -- 
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102

Re: http://central.maven.org/maven2/org/eclipse/m2e gone ??

[Stuart McCulloch]

I don’t believe it ever existed on central, IIRC it’s a placeholder used by 
m2e: http://stackoverflow.com/a/7423909

On 16 May 2014, at 20:48, Dan Tran dant...@gmail.com wrote:

 any one?
 
 http://central.maven.org/maven2/org/eclipse/m2e
 
 Thanks
 
 -D
 
 
 On Thu, May 15, 2014 at 4:34 PM, Dan Tran dant...@gmail.com wrote:
 
 I am looking for org.eclipse.m2e:lifecycle-mapping:1.0.0
 
 and it is not at maven central any more.
 
 do you see the same thing?
 
 
 Thanks
 
 -D
 


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

Re: http://central.maven.org/maven2/org/eclipse/m2e gone ??

[Stuart McCulloch]

On 16 May 2014, at 22:59, Dan Tran dant...@gmail.com wrote:

 umm, what worries me why it disappears from maven central which suppose to
 be a well guarded place?

It has not disappeared as it was never on central in the first place - it's 
just a placeholder GAV that m2e uses for configuration purposes. You should 
contact the m2e team about deploying a basic stub on central.

 a JIRA case is filed at  https://issues.sonatype.org/browse/CENTRALSRV-74
 
 -D
 
 
 On Fri, May 16, 2014 at 1:29 PM, Curtis Rueden ctrue...@wisc.edu wrote:
 
 Hi Dan,
 
 I am looking for org.eclipse.m2e:lifecycle-mapping:1.0.0
 
 and it is not at maven central any more.
 
 My team definitely felt the pain of its absence from Central as well.
 
 To avoid the problem, we use this workaround:
 
profile
  idonly-eclipse/id
  activation
property
  namem2e.version/name
/property
  /activation
  build
pluginManagement
  plugins
!-- This plugin's configuration is used to store Eclipse m2e
 settings
 only. It has no influence on the Maven build itself. --
plugin
  groupIdorg.eclipse.m2e/groupId
  artifactIdlifecycle-mapping/artifactId
  version1.0.0/version
  configuration
...
  /configuration
/plugin
  /plugins
/pluginManagement
  /build
/profile
 
 Beautiful, right? ;-)
 
 -Curtis
 
 
 On Fri, May 16, 2014 at 2:48 PM, Dan Tran dant...@gmail.com wrote:
 
 any one?
 
 http://central.maven.org/maven2/org/eclipse/m2e
 
 Thanks
 
 -D
 
 
 On Thu, May 15, 2014 at 4:34 PM, Dan Tran dant...@gmail.com wrote:
 
 I am looking for org.eclipse.m2e:lifecycle-mapping:1.0.0
 
 and it is not at maven central any more.
 
 do you see the same thing?
 
 
 Thanks
 
 -D
 
 
 

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

Re: Log4J - cannot find symbol - method trace(String)

[Stuart McCulloch]

Also check your java imports, just in case you’ve imported a different Logger 
by mistake (such as java.util.logging.Logger) 

On 30 Apr 2014, at 12:48, Nick Stolwijk nick.stolw...@gmail.com wrote:

 You can use the dependency:tree[1] goal to view a tree of your
 dependencies to see if the correct version of Log4J is being included
 in the compiler classpath.
 
 [1] https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html
 
 Hth,
 
 Nick Stolwijk
 
 ~~~ Try to leave this world a little better than you found it and,
 when your turn comes to die, you can die happy in feeling that at any
 rate you have not wasted your time but have done your best ~~~
 
 Lord Baden-Powell
 
 
 On Wed, Apr 30, 2014 at 1:41 PM, Dušan Rychnovský
 geraltzri...@gmail.com wrote:
 Hi everyone,
 
 I have the following dependency in my project's POM:
 
 ...
 dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.17/version
 /dependency
 ...
 
 The artifact is downloaded to my local repository, but, during the compile
 phase, the following error is emitted and the build process is aborted:
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
 (default-compile) on project dbtoixattrdt: Compilation failure: Compilation
 failure:
 [ERROR]
 d:\prace\dbtoixattrdt\DBToIXATTRDT-TRUNK\src\main\java\dbtoixattrdt\TraceLogAspect.java:[19,8]
 error: cannot find symbol
 [ERROR] symbol:   method trace(String)
 [ERROR] location: variable logger of type Logger
 
 This error message does not make much sense, as the trace method should be
 available on the Logger class in Log4J version 1.2.17.
 
 What can be wrong?
 
 Thanks in advance,
 Dušan
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Class loader issues after Maven 3.1.0

[Stuart McCulloch]

See 
http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3ca70f13ef-38e2-49a8-b696-b5e592092...@gmail.com%3e
 for why this is happening

AFAICT neither of the suggested solutions mentioned in the above email have 
been applied to DefaultClassRealmManager, so I believe this is still an issue 
in Maven 3.2.1

On 17 Apr 2014, at 14:57, Martin Grigorov mgrigo...@apache.org wrote:

 Hi,
 
 We have troubles use 'mvn jetty:run' for
 https://github.com/apache/wicket/tree/master/wicket-examples after
 upgrading to Maven 3.1.0+.
 
 It fails with:
 
 2014-04-17 16:22:57.160:WARN:oejuc.AbstractLifeCycle:FAILED
 org.mortbay.jetty.plugin.JettyServer@44e5b006: java.lang.LinkageError:
 loader constraint violation: when resolving overridden method
 org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;
 the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader)
 of the current class, org/jboss/weld/Weld, and its superclass loader
 (instance of org/codehaus/plexus/classworlds/realm/ClassRealm), have
 different Class objects for the type
 tion/Annotation;)Ljavax/enterprise/inject/Instance; used in the signature
 java.lang.LinkageError: loader constraint violation: when resolving
 overridden method
 org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;
 the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader)
 of the current class, org/jboss/weld/Weld, and its superclass loader
 (instance of org/codehaus/plexus/classworlds/realm/ClassRealm), have
 different Class objects for the type
 tion/Annotation;)Ljavax/enterprise/inject/Instance; used in the signature
 at
 org.jboss.weld.servlet.StaticWeldProvider$WeldSingleton.clinit(StaticWeldProvider.java:29)
 at
 org.jboss.weld.servlet.StaticWeldProvider.getCDI(StaticWeldProvider.java:49)
 at javax.enterprise.inject.spi.CDI.current(CDI.java:60)
 at
 org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:85)
 at
 org.jboss.weld.servlet.api.helpers.ForwardingServletListener.contextInitialized(ForwardingServletListener.java:34)
 at
 org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:171)
 at
 org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:733)
 ...
 
 The issue is not new. We just noticed that when using 3.0.5 it runs fine so
 it should be some change in Maven itself.
 
 I've found that another user had the same issue:
 http://stackoverflow.com/a/18168215/497381
 
 How to reproduce:
 1) git clone https://github.com/apache/wicket.git
 2) mvn install (just to have all dependencies)
 3) cd wicket-examples
 4) mvn jetty:run (fails with 3.1.0+)
 
 Thanks!
 
 
 Martin Grigorov
 Wicket Training and Consulting


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

Re: Class loader issues after Maven 3.1.0

[Stuart McCulloch]

On 17 Apr 2014, at 15:15, Martin Grigorov mgrigo...@apache.org wrote:

 Thanks, Stuart!
 
 I can confirm that the issue is still there in 3.2.1.
 Is there an open issue at http://jira.codehaus.org/browse/MNG that I can
 follow ?

I don’t believe so, suggest you open a new issue and refer to that maven-dev 
discussion.

 Martin Grigorov
 Wicket Training and Consulting
 
 On Thu, Apr 17, 2014 at 5:12 PM, Stuart McCulloch mccu...@gmail.com wrote:
 
 See
 http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3ca70f13ef-38e2-49a8-b696-b5e592092...@gmail.com%3efor
  why this is happening
 
 AFAICT neither of the suggested solutions mentioned in the above email
 have been applied to DefaultClassRealmManager, so I believe this is still
 an issue in Maven 3.2.1
 
 On 17 Apr 2014, at 14:57, Martin Grigorov mgrigo...@apache.org wrote:
 
 Hi,
 
 We have troubles use 'mvn jetty:run' for
 https://github.com/apache/wicket/tree/master/wicket-examples after
 upgrading to Maven 3.1.0+.
 
 It fails with:
 
 2014-04-17 16:22:57.160:WARN:oejuc.AbstractLifeCycle:FAILED
 org.mortbay.jetty.plugin.JettyServer@44e5b006: java.lang.LinkageError:
 loader constraint violation: when resolving overridden method
 
 org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;
 the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader)
 of the current class, org/jboss/weld/Weld, and its superclass loader
 (instance of org/codehaus/plexus/classworlds/realm/ClassRealm), have
 different Class objects for the type
 tion/Annotation;)Ljavax/enterprise/inject/Instance; used in the signature
 java.lang.LinkageError: loader constraint violation: when resolving
 overridden method
 
 org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;
 the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader)
 of the current class, org/jboss/weld/Weld, and its superclass loader
 (instance of org/codehaus/plexus/classworlds/realm/ClassRealm), have
 different Class objects for the type
 tion/Annotation;)Ljavax/enterprise/inject/Instance; used in the signature
 at
 
 org.jboss.weld.servlet.StaticWeldProvider$WeldSingleton.clinit(StaticWeldProvider.java:29)
 at
 
 org.jboss.weld.servlet.StaticWeldProvider.getCDI(StaticWeldProvider.java:49)
 at javax.enterprise.inject.spi.CDI.current(CDI.java:60)
 at
 
 org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:85)
 at
 
 org.jboss.weld.servlet.api.helpers.ForwardingServletListener.contextInitialized(ForwardingServletListener.java:34)
 at
 
 org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:171)
 at
 
 org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:733)
 ...
 
 The issue is not new. We just noticed that when using 3.0.5 it runs fine
 so
 it should be some change in Maven itself.
 
 I've found that another user had the same issue:
 http://stackoverflow.com/a/18168215/497381
 
 How to reproduce:
 1) git clone https://github.com/apache/wicket.git
 2) mvn install (just to have all dependencies)
 3) cd wicket-examples
 4) mvn jetty:run (fails with 3.1.0+)
 
 Thanks!
 
 
 Martin Grigorov
 Wicket Training and Consulting
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 


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

Re: Guice provision error with AbstractMavenLifecycleParticipant

[Stuart McCulloch]

On 1 Mar 2014, at 19:12, William Ferguson william.fergu...@xandar.com.au 
wrote:

 Thanks for the exceptionally clear explanation Stuart.
 
 I don't think we can just avoid the exception with stubbed implementations
 of the Resolver because the the plugin doesn't use the Resolver directly.
 It asks for an Aether RepositorySystem:
@Requirement
private RepositorySystem repoSystem;
 
 which is what instantiates the VersionResolver.

I don’t think this is an issue, just declaring a dummy component locally using 
@Component should satisfy the missing binding that leads to the original 
exception.

In other words: at the moment you have a broken dependency chain that stops 
Guice from creating an instance of the repository system - if you provide a 
dummy link in the form of a local @Component(hint=“dummy) that implements 
VersionResolver then the chain will be complete from the perspective of the 
current plugin and the repository system can be created. Of course you can’t 
then do much with it because it would be using the dummy resolver, but it would 
avoid the original exception at creation time and allow the IntelliJ pom 
processing to continue. Note you may also need to stub out other resolver 
components required by the repository system.

Of course as Manfred points out, if IntelliJ updated their bundled version of 
Maven to 3.1.x or later then that would also solve the problem and doesn’t 
require any plugin changes.

 I'll have another look at maven-dependency-tree but I didn't see a clear
 path towards what we wanted.
 
 Could you shed some more light on:
 Unfortunately adding a direct plugin dependency to the
 maven-aether-provider from 3.1.1 won't help
 because Maven will filter out this dependency as being supplied from
 Maven core
 
 What's doing the filtering and why?

IIRC this is done in DefaultClassRealmManager from maven-core… the reason it 
filters out dependencies/packages explicitly exported by core is to avoid class 
consistency issues, otherwise you could end up with the same class being 
defined twice, once by the core class loader and once by a plugin’s class 
loader. Such classes would then be incompatible as they were defined by 
different class loaders and couldn’t then be used for sharing data, such as 
sharing repository information between core and a plugin.

 What would be need to make it not filter out a maven-core library that is a
 different version of the running Maven instance?

You can’t without doing some complicated class loader hacks, this is a 
fundamental feature of Maven’s plugin system.

 William
 
 On Fri, Feb 28, 2014 at 12:13 PM, Stuart McCulloch mccu...@gmail.comwrote:
 
 On 28 Feb 2014, at 01:17, William Ferguson william.fergu...@xandar.com.au
 wrote:
 
 As part of the development of the android-maven-plugin we have need to
 add
 in an AbstractMavenLifecycleParticipant so that we can modify the compile
 classpath to add artefacts that are contained within a project's
 dependencies. Igor provided a lot of the coaching on this.
 
 The build works fine. Does what is intended.
 
 But now, when you open a project in intelliJ13 that uses the
 android-maven-plugin, IntelliJ declares a problem with the POM that
 references our MavenLifecycleParticipant.
 
 What I'd like help with is:
 1) Is this a problem with the plugin itself. Ie have we defined something
 incorrectly.
 2) Is it just a problem with how IntelliJ is parsing a POM that declares
 the plugin.
 
 If it is (1), what do we need to do to fix it?
 
 However, I suspect it is (2) because similar error messages seem to occur
 when plugins designed for Maven 3.1 (and the switch to Eclipse Aether
 from
 Sonatype Aether) are used in a Maven-3.0 environment. I'm thinking that
 maybe IntelliJ is using a Maven-3.0 core. But I'm really not sure and
 would
 love some clarity from those who understand what is going on a bit
 better.
 And if it is (2) is there anything we or IntelliJ can do to fix it?
 
 The plugin itself can be found at:
 https://github.com/jayway/maven-android-plugin
 
 A project showing the failure can be found at:
 
 https://github.com/jayway/maven-android-plugin-samples/tree/master/morseflash/morseflash-app
 
 And the error message is (visible via flyover in the POM editor window or
 in idea.log):
 
 I can recreate the same exception on the command-line using the plugin
 with Maven 3.0.5 (after I removed the 3.1.1 pre-req from the plugin's
 pom.xml)
 
 The issue is that the plugin expects Maven core to supply an
 implementation of org.eclipse.aether.impl.VersionResolver, namely
 DefaultVersionResolver from maven-aether-provider.
 
 However in Maven 3.0.x the maven-aether-provider module only supplies an
 implementation of org.sonatype.aether.impl.VersionResolver ... which is why
 you see that exception :/
 
 Unfortunately adding a direct plugin dependency to the
 maven-aether-provider from 3.1.1 won't help because Maven will filter out
 this dependency as being supplied from Maven core

Re: Guice provision error with AbstractMavenLifecycleParticipant

[Stuart McCulloch]

On 28 Feb 2014, at 01:17, William Ferguson william.fergu...@xandar.com.au 
wrote:

 As part of the development of the android-maven-plugin we have need to add
 in an AbstractMavenLifecycleParticipant so that we can modify the compile
 classpath to add artefacts that are contained within a project's
 dependencies. Igor provided a lot of the coaching on this.
 
 The build works fine. Does what is intended.
 
 But now, when you open a project in intelliJ13 that uses the
 android-maven-plugin, IntelliJ declares a problem with the POM that
 references our MavenLifecycleParticipant.
 
 What I'd like help with is:
 1) Is this a problem with the plugin itself. Ie have we defined something
 incorrectly.
 2) Is it just a problem with how IntelliJ is parsing a POM that declares
 the plugin.
 
 If it is (1), what do we need to do to fix it?
 
 However, I suspect it is (2) because similar error messages seem to occur
 when plugins designed for Maven 3.1 (and the switch to Eclipse Aether from
 Sonatype Aether) are used in a Maven-3.0 environment. I'm thinking that
 maybe IntelliJ is using a Maven-3.0 core. But I'm really not sure and would
 love some clarity from those who understand what is going on a bit better.
 And if it is (2) is there anything we or IntelliJ can do to fix it?
 
 The plugin itself can be found at:
 https://github.com/jayway/maven-android-plugin
 
 A project showing the failure can be found at:
 https://github.com/jayway/maven-android-plugin-samples/tree/master/morseflash/morseflash-app
 
 And the error message is (visible via flyover in the POM editor window or
 in idea.log):

I can recreate the same exception on the command-line using the plugin with 
Maven 3.0.5 (after I removed the 3.1.1 pre-req from the plugin’s pom.xml)

The issue is that the plugin expects Maven core to supply an implementation of 
org.eclipse.aether.impl.VersionResolver, namely DefaultVersionResolver from 
maven-aether-provider.

However in Maven 3.0.x the maven-aether-provider module only supplies an 
implementation of org.sonatype.aether.impl.VersionResolver … which is why you 
see that exception :/

Unfortunately adding a direct plugin dependency to the maven-aether-provider 
from 3.1.1 won’t help because Maven will filter out this dependency as being 
supplied from Maven core

If you want the plugin to work on both Maven 3.0.x and 3.1.x then you’ll either 
need to use an API common to both (like the shared maven-dependency-tree 
component) or write two versions of the code that talks to Aether and select 
the appropriate one at runtime using reflection. But if you just want to avoid 
the exception when Intellij processes the pom.xml then you could conceivably 
provide dummy/stubbed @Component implementations of the Eclipse/Aether 
resolver, with the role set to a non-default value such as “dummy” so that it 
doesn’t interfere with the default implementation provided in Maven 3.1.1

 java.lang.RuntimeException: com.google.inject.ProvisionException:
 Guice provision errors:
 
 1) No implementation for org.eclipse.aether.impl.VersionResolver was bound.
  while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
  at 
 ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
 parent: sun.misc.Launcher$AppClassLoader@39172e08]
  at 
 ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
 parent: sun.misc.Launcher$AppClassLoader@39172e08]
  while locating org.eclipse.aether.RepositorySystem
  while locating
 com.jayway.maven.plugins.android.phase_prebuild.AarMavenLifecycleParticipant
  at 
 ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
 parent: sun.misc.Launcher$AppClassLoader@39172e08]
  at 
 ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
 parent: sun.misc.Launcher$AppClassLoader@39172e08]
  while locating org.apache.maven.AbstractMavenLifecycleParticipant
 annotated with @com.google.inject.name.Named(value=AarMavenLifecycleListener)
 
 
 We are tracking this at:
 https://code.google.com/p/maven-android-plugin/issues/detail?id=449
 
 
 Any help appreciated.
 
 
 William


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

Re: Looking for org.apache.poi 3.10-FINAL

[Stuart McCulloch]

On 16 February 2014 10:31, David Law m2ecli...@apconsult.de wrote:

 Hi Mirko,

 I think though 6 days!!! should be adequate for that.
 In fact, I think 6 minutes should be adequate.

 So I really need someone to explain how I can move forward with this issue.


FWIW, I did a search today for org.apache.poi:poi in my local m2e
and 3.10-FINAL appeared - so it's definitely in the index from the 15th
(which is the index downloaded on my local computer according to the file
under .metadata/.plugins/org.eclipse.m2e.core/nexus), but not sure when it
was indexed...

You could always post a question on
https://issues.sonatype.org/browse/MVNCENTRAL if you want a definitive
answer of what happened, when, and why.

All the best,
 DaveLaw


 On 16.02.2014 10:49, Mirko Friedenhagen wrote:

 David,

 just guessing:
 - indexing takes it's time, there are only two hours difference between
 the
 commit (??l and end of indexing.
 - commit (tag creation), artifact creation (jar build), deployment (upload
 to staging),  promotion (move of staged to released) and synchronization
 from oss.sonatype.org to repo1 add delays :-)

 Regards
 Mirko


 On 16.02.2014 09:43, David Law wrote:

 Hi,

 I'm new to maven  thought I'd try it out on the recently checked-in:
 org.apache.poi3.10-FINAL

 I'm using m2eclipse standard config with Eclipse Kepler.  Repo defaults
 to:
 http://repo.maven.apache.org/maven2

 The Problem:
 m2eclipse does not know the  org.apache.poi  3.10-FINAL  artifact.

 Now, I guess the problem could be any combination of:
 a) me  b) POI  c) maven  d) m2eclipse  e) eclipse?

 QUESTION) Can anyone help to localise it?

 Here's what I've found out so far:

 0) repo is: http://repo.maven.apache.org/maven2

 1) org.apache.poi  3.10-FINAL was committed @ 09-Feb-2014 11:50

 2) as of now repo Timestamp is: 09-Feb-2014 13:50
 (nexus.index.timestamp=20140209134945.568 +)
 (found in
 http://repo.maven.apache.org/maven2/.index/nexus-maven-
 repository-index.properties)

 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit
 (6 days ago).

 4) exit eclipse

 5) deleted the index
 C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus

 6) start eclipse - updating index

 7) org.apache.poi  3.10-FINAL is still not there (that is: here) in my
 list of artifacts

 All the best,
 DaveLaw


-- 
Cheers, Stuart

Re: Looking for org.apache.poi 3.10-FINAL

[Stuart McCulloch]

On 16 February 2014 14:36, David Law m2ecli...@apconsult.de wrote:

 Hi Stuart,

 thanks for that very useful information.
 Are you using the default repo?
 (http://repo.maven.apache.org/maven2)


I switch depending what workspace I'm using, as I have a corporate repo as
well as a local nexus instance (enabled to download remote indexes)

But I just tried from a fresh installation with the default repo to confirm
and it is in the latest index with nexus.index.timestamp=20140216125157.106


 All the best,
 DaveLaw

 On 16.02.2014 14:36, Stuart McCulloch wrote:

 On 16 February 2014 10:31, David Law m2ecli...@apconsult.de wrote:

  Hi Mirko,

 I think though 6 days!!! should be adequate for that.
 In fact, I think 6 minutes should be adequate.

 So I really need someone to explain how I can move forward with this
 issue.

  FWIW, I did a search today for org.apache.poi:poi in my local m2e
 and 3.10-FINAL appeared - so it's definitely in the index from the 15th
 (which is the index downloaded on my local computer according to the file
 under .metadata/.plugins/org.eclipse.m2e.core/nexus), but not sure when
 it
 was indexed...

 You could always post a question on
 https://issues.sonatype.org/browse/MVNCENTRAL if you want a definitive
 answer of what happened, when, and why.

 All the best,

 DaveLaw


 On 16.02.2014 10:49, Mirko Friedenhagen wrote:

  David,

 just guessing:
 - indexing takes it's time, there are only two hours difference between
 the
 commit (??l and end of indexing.
 - commit (tag creation), artifact creation (jar build), deployment
 (upload
 to staging),  promotion (move of staged to released) and synchronization
 from oss.sonatype.org to repo1 add delays :-)

 Regards
 Mirko

  On 16.02.2014 09:43, David Law wrote:

  Hi,

 I'm new to maven  thought I'd try it out on the recently checked-in:
 org.apache.poi3.10-FINAL

 I'm using m2eclipse standard config with Eclipse Kepler.  Repo defaults
 to:
 http://repo.maven.apache.org/maven2

 The Problem:
 m2eclipse does not know the  org.apache.poi  3.10-FINAL  artifact.

 Now, I guess the problem could be any combination of:
 a) me  b) POI  c) maven  d) m2eclipse  e) eclipse?

 QUESTION) Can anyone help to localise it?

 Here's what I've found out so far:

 0) repo is: http://repo.maven.apache.org/maven2

 1) org.apache.poi  3.10-FINAL was committed @ 09-Feb-2014 11:50

 2) as of now repo Timestamp is: 09-Feb-2014 13:50
 (nexus.index.timestamp=20140209134945.568 +)
 (found in
 http://repo.maven.apache.org/maven2/.index/nexus-maven-
 repository-index.properties)

 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit
 (6 days ago).

 4) exit eclipse

 5) deleted the index
 C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus

 6) start eclipse - updating index

 7) org.apache.poi  3.10-FINAL is still not there (that is: here) in my
 list of artifacts

 All the best,
 DaveLaw


-- 
Cheers, Stuart

Re: adding repository url

[Stuart McCulloch]

On 15 February 2014 11:13, 454329 abhi454...@gmail.com wrote:

 Hi there ,

 I have this dependency present in my pom.xml .
 dependency
 groupIdorg.apache.solr/groupId
 artifactIdsolr-cell/artifactId
 version4.0/version


Did a quick search for solr-cell on http://search.maven.org/ and I suspect
the version above should be 4.0.0, not 4.0...

/dependency

 However , while trying to mvn install results in buil error because this
 dependency isn't resolved successfully.

 I tried hunting for the respository url which can fetch this dependency for
 me, but all was in vain.

 However, i found pm.xml files for this dependency.I don't know, but can I
 link this pom with my pom.xml which is present in my code to resolve
 dependency ?

 Or what i should do ?



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/adding-repository-url-tp5784961.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

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




-- 
Cheers, Stuart

Re: Possible build collision between CI snapshot build and Release build

[Stuart McCulloch]

On 15 February 2014 15:51, Thomas Broyer t.bro...@gmail.com wrote:

 On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.net
 wrote:

  Hi Dan,
  Not sure what you mean. You say CI, are you taking about a specific
  server? If Jenkins for example, wouldn't it then be more a Jenkins user
 ml
  question?
 
  And I don't see how a snapshot build could interfere with another build
  with a release version.
  Could you give details about your issue so that we can help you?
 

 mvn release:prepare does a first commit with the POM modified with the
 no-SNAPSHOT version, then another commit with the POM modified with the
 next SNAPSHOT version.
 If a build is triggered for the first commit and basically does a mvn
 install or, worse, a mvn deploy, then it'll end up deploying your
 release version, the very same that mvn release:perform will deploy too
 (very same version information, not necessarily the same artifact: might
 not deploy javadoc and sources for example, or the artifact might be
 slightly different because you have plugins in a profile triggered only on,
 or never on, release builds).
 I think that what Dan referred to as a CI snapshot build is the kind of
 build triggered by a commit (which generally builds snapshots).


Perhaps write a custom enforcer rule (enabled by a profile on CI) that
fails the build when the project artifact version is not a snapshot?

   http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html


  Cheers
  Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.com a écrit :
 
   Hello
  
  
   It is possible that while release:prepare cutting the tag and CI for
   snapshot build wakeup at the same time.  Is there a way to prevent
 this?
   like a a profile to fail the build if the version happen to be a
 release
   version.  Ie is there a way to detect this in a profile?
  
   I currently have to keep remind my self to turn off CI snapshot build
  while
   release is in progress, and too many to remember.
  
   Advice is greatly appreciated
  
   -Dan
  
 

 --
 Thomas Broyer
 /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ 
 http://xn--nna.ma.xn--bwa-xxb.je/


-- 
Cheers, Stuart

Re: Strange Array configuration for plugin params

[Stuart McCulloch]

On 13 Feb 2014, at 17:46, Dan Tran dant...@gmail.com wrote:

 A contributor for MOJO-2006 [1] uses array configuration at
 
 http://maven.apache.org/guides/plugin/guide-java-plugin-development.html (
 array session)
 
 here is the text
 
/**
 * My List.
 */
@Parameter
private List myList;
 
 myList
  paramvalue1/param
  paramvalue2/param
 /myList
 
 For details on the mapping of the individual collection elements, see Mapping
 Listshttp://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Lists.
 
 However if you drill down to 'Mapping Lists' it has the usual configuration
 that we are custom-ed to
 
  animals
animalcat/animal
animaldog/animal
animalaardvark/animal
   /animals
 
 is it there by accident? or the plugin api support both format?

Both formats are supported.

 Thanks
 
 [1] https://jira.codehaus.org/browse/MOJO-2006


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

Re: Maven multi-module site

[Stuart McCulloch]

On 5 Feb 2014, at 13:23, Melvyn de Kort mel...@mdekort.nl wrote:

 Our maximum heap size is already 4G, can't increase that any more I'm
 afraid.

It could be running out of PermGen space, which is controlled by a different 
setting:

MAVEN_OPTS=-XX:MaxPermSize=256m

 Regards,
 
 Melvyn de Kort
 
 
 On Wed, Feb 5, 2014 at 2:18 PM, Ron Wheeler
 rwhee...@artifact-software.comwrote:
 
 On 05/02/2014 4:22 AM, Melvyn de Kort wrote:
 
 Hi all,
 
 We have a large multi-module project with over 90 submodules.
 When we run a mvn site-deploy command, the build will run out of memory.
 This used to work, but I guess we reached a threshold.
 
 Our idea is to split the site command in groups of modules, or maybe build
 every module separately.
 However, we still want to have an aggregated site in the end.
 
 Does anybody have experience in how to configure and run such a setup?
 
 Kind regards,
 
 Melvyn de Kort
 
 
 Have you increased the memory to the max that your virtual memory can
 support?
 This does not give you a better structure but should solve your current
 bottleneck.
 Memory is very cheap. Virtual memory is even cheaper.
 
 Ron
 
 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 


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

Re: Strange log traffic from the assembly plugin

[Stuart McCulloch]

On 3 Feb 2014, at 14:34, Benson Margulies bimargul...@gmail.com wrote:

 Does anyone recognize the following? It correlates with a mystery.

Looks like http://jira.codehaus.org/browse/MASSEMBLY-671 … basically it happens 
when there’s a problem with the assembly descriptor which then triggers a code 
path that leads to this cryptic debug message (because something in the code is 
looking up a resolver with a non-existent hint). Typically the assembly plugin 
still goes on and produces an assembly, but the contents may not be what you 
want due to the issue with the descriptor.

Another example: 
http://mail-archives.apache.org/mod_mbox/maven-users/201110.mbox/%3CCAHCAor7DcA9UKMpQredEovqkxw2EPZxJkqJ+=pewkuxjjve...@mail.gmail.com%3E

 [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
 org.codehaus.plexus.component.repository.exception.ComponentLookupException:
 java.util.NoSuchElementException
  role: org.apache.maven.artifact.resolver.ArtifactResolver
  roleHint: project-cache-aware
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257)
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233)
 at 
 org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148)
 at 
 com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
 at 
 com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
 at 
 com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
 at 
 com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
 at com.google.inject.Scopes$1$1.get(Scopes.java:59)
 at 
 com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
 at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
 at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
 at 
 org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
 at 
 org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
 at 
 org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112)
 at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
 at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436)
 at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
 at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
 at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
 at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
 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:597)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
 at 

Re: Strange log traffic from the assembly plugin

[Stuart McCulloch]

On 3 Feb 2014, at 14:44, Stuart McCulloch mccu...@gmail.com wrote:
 On 3 Feb 2014, at 14:34, Benson Margulies bimargul...@gmail.com wrote:
 
 Does anyone recognize the following? It correlates with a mystery.
 
 Looks like http://jira.codehaus.org/browse/MASSEMBLY-671 … basically it 
 happens when there’s a problem with the assembly descriptor which then 
 triggers a code path that leads to this cryptic debug message (because 
 something in the code is looking up a resolver with a non-existent hint). 
 Typically the assembly plugin still goes on and produces an assembly, but the 
 contents may not be what you want due to the issue with the descriptor.
 
 Another example: 
 http://mail-archives.apache.org/mod_mbox/maven-users/201110.mbox/%3CCAHCAor7DcA9UKMpQredEovqkxw2EPZxJkqJ+=pewkuxjjve...@mail.gmail.com%3E

More details: this debug message appears the first time that something uses the 
DefaultRepositoryAssembler from the shared maven-repository-builder component:


http://svn.apache.org/viewvc/maven/shared/tags/maven-repository-builder-1.0-alpha-2/src/main/java/org/apache/maven/shared/repository/DefaultRepositoryAssembler.java?view=markup#l96

http://svn.apache.org/viewvc/maven/shared/tags/maven-repository-builder-1.0-alpha-2/src/main/java/org/apache/maven/shared/repository/DefaultRepositoryAssembler.java?view=markup#l710

The DefaultRepositoryAssembler first looks for the 'project-cache-aware’ 
ArtifactResolver before falling back to the default - this change was 
introduced back in the Maven2 days:

http://svn.apache.org/viewvc?view=revisionrevision=564256

but I can’t seem to find out where the 'project-cache-aware’ hinted version of 
ArtifactResolver was ever implemented… which is why the first lookup fails and 
it goes on to use the default implementation.

Summary: this is a debug log message that is likely unrelated to the actual 
issue you’re investigating, it will always happen first time 
DefaultRepositoryAssembler is used.

 [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
 org.codehaus.plexus.component.repository.exception.ComponentLookupException:
 java.util.NoSuchElementException
 role: org.apache.maven.artifact.resolver.ArtifactResolver
 roleHint: project-cache-aware
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257)
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233)
 at 
 org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292)
 at 
 org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148)
 at 
 com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
 at 
 com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
 at 
 com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
 at 
 com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
 at 
 com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
 at com.google.inject.Scopes$1$1.get(Scopes.java:59)
 at 
 com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
 at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
 at 
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
 at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
 at 
 org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
 at 
 org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
 at 
 org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112)
 at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
 at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436)
 at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145

Re: How to include @inheritDoc from a dependent jar

[Stuart McCulloch]

On 15 Jan 2014, at 08:20, Mikael Petterson mikael.petter...@ericsson.com 
wrote:

 Hi,
 
 New try :-)
 
 I have the following:
 
 Interface in dependency jar javadoc:
 
 /**
 * Deletes the object found at the specified location.
 * 
 * @param Object any type of object
 * @throws InvalidObjectException lots of text
 * @throws NoSuchObjectException lots of text
 */
 public void delete (Object object)throws throws InvalidObjectException, 
 NoSuchObjectException;
 
 Implementing class:
 
 /**
 * {@inheritDoc}
 */
@Override
public void delete(Object object) throws InvalidObjectException, 
 NoSuchObjectException {
   //implementation of delete
}
 
 Is this correct or?   Since this will not produce any javadoc for 
 implementation of delete ( last code).
 
 Do I need to do anything special in the maven javadoc plugin?

The javadoc tool works primarily from source, and by default the maven javadoc 
plugin doesn’t include the sources of dependencies - which is why @inheritDoc 
doesn’t include the javadoc from the dependency.

You can tell the javadoc plugin to include the sources of dependencies with:

includeDependencySourcestrue/includeDependencySources

and include the sources of transitive dependencies with:


includeTransitiveDependencySourcestrue/includeTransitiveDependencySources

You can also use dependencySourceExcludes / dependencySourceIncludes to control 
which particular sources get pulled in 

( this assumes that the dependency sources - typically produced by the maven 
source plugin - are available in the local/remote repository )

 Br.
 
 //mike
 
 -Original Message-
 From: Martin Gainty [mailto:mgai...@hotmail.com]
 Sent: den 14 januari 2014 13:27
 To: users@maven.apache.org
 Subject: RE: How to include @inheritDoc from a dependent jar
 
 
 
 
 From: mikael.petter...@ericsson.com
 To: users@maven.apache.org
 Subject: How to include @inheritDoc from a dependent jar
 Date: Tue, 14 Jan 2014 12:14:21 +
 
 Hi,
 
 We are building a maven site that will contain javadoc for our AppX api ( 
 jar file).
 AppX depends on a few other jar files ( that we have built using maven) . 
 One dependency jar contain an interface with javadoc and we have a class 
 implementing it, in AppX.
 AppX has @inheritDoc in in the javadoc so we don't have to rewrite it.
 
 When I use the following under report
 
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 version2.8.1/version
 /plugin
 
 But when I open up the javadoc for my Appx and look at the class 
 implementing the interface there is no javadoc. What am I missing?
 
 MG@Inheritdoc pulls Javadoc comments @comment @author @param @throws 
 MG@return from Implemented interface If you have none of the Javadoc 
 MGtags in the corresponding base method of implemented interface then 
 MGAppX class will not be able to 'inherit' those Javadoc attributes
 
 Br,
 
 //mike
 The longest journey is the the journey inwards..Of him who has chosen his 
 dentiny..Who has started upon his quest for the source of his being Dag 
 Hammarskjold
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Maven Central Opinion

[Stuart McCulloch]

On 5 Jan 2014, at 13:15, Tommy Svensson to...@natusoft.se wrote:

 I was asked to submit one of my opensource tools at github to maven central. 
 This turned out to be a rather complex procedure.

[ disclaimer: I work at Sonatype ]

Any suggestions for improving the process are welcome - most of the 
requirements below are actually more recommendations / effects of the 
maven-release-plugin workflow, so maybe we need to clarify this on the wiki.

 Sonatype puts the following requirements on anyone wanting to submit to maven 
 central:
 
 - You are forced to set a Sonatype pom as parent of your project and thus 
 inherit things you have no control over. 

The wiki recommends a parent pom with the relevant distributionManagement (so 
Maven knows where to deploy artifacts) plus some release configuration for 
adding sources, javadoc, signatures, etc.

You can always use a different parent pom and copy the distributionManagement 
section across - feel free to ask for help with this, and we can always add a 
section to the wiki if others would find this useful

 - You are forced to have a SNAPSHOT version even if you have no use for such.

This is the standard Maven release workflow - you don’t strictly need this if 
you’re just uploading releases, just go to the existing tagged release and use 
“mvn deploy”

(you’ll need override the deploy properties on the command line ie. 
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository
 if your pom doesn’t point to OSSRH)

 - You are forced at submission time to select a new version for your software 
 even if you have no idea if it will be a minor, bugfix or new functionality 
 at this point in time. 

As above, you can always deploy an existing release - either with “mvn deploy” 
or by packaging it up as a bundle and uploading it using the UI:


https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-UploadStagingBundle

However, once you have released an artifact to central its content should never 
change

 - Your public repository (github, etc) which you are forced to point out in 
 your pom are no longer yours to decide over. It will be updated during the 
 submission process. 

That’s the Maven release plugin - it updates the released pom so it points to 
the right tagged release, then changes it back for development

Some projects do releases differently by using the versions plugin to update 
the poms, tagging the release manually, then finally using “mvn deploy

 - After running 3 different mvn commands you also need to login to Sonatypes 
 nexus server and ”release” the artifacts before the become available. 

That’s so you can check the uploaded artifacts before they get distributed to 
central, mirrors, and from there to developers machines - because once a 
release is on central its content should never change

If you want to skip this step then you can by configuring the 
nexus-staging-maven-plugin which can help manage the staging workflow:


http://books.sonatype.com/nexus-book/reference/staging-sect-deployment.html#staging-sect-deployment-nexus-staging-maven-plugin

plugin
  groupIdorg.sonatype.plugins/groupId
  artifactIdnexus-staging-maven-plugin/artifactId
  extensionstrue/extensions
  configuration
releaseAfterClosetrue/releaseAfterClose
  /configuration
/plugin

You can also use this plugin to access the same staging commands available to 
you through the Nexus UI (or you could even use the underlying REST API if you 
wish)

Finally depending on your project there are alternative routes to central, such 
as http://www.apache.org/dev/publishing-maven-artifacts.html for Apache 
projects, or the new https://bintray.com/ service. 

 The idea of the maven repository that has grown larger than maven itself is a 
 completely brilliant idea. It takes open source to a new level where anyone 
 can just depend on other open source code and automatically download it on 
 build. This is really good for the open source world (well, at least the 
 Java/JVM part of it) . The fact that the release process to this central 
 repository is far too complex, I see as a really great problem, inhibiting 
 the easy sharing of open source work. I have often found open source tools 
 and frameworks that are not available in maven central, and that is because 
 not everyone is willing to put up with this, which now also includes myself. 
 As I see it, either this procedure needs to be changed to provide a trivial 
 release of binary artifacts without affecting your poms, or there need to be 
 an alternative open repository providing ease of release, where it is trivial 
 for anyone to share their binaries for easy access by others. I’m wondering 
 if I’m alone in this view or if there are others who agree with me ? 
 
 Tommy Svensson
 
 
 -
 To 

Re: Residual package goal state affects outcome of Mojo definition in descriptor file.

[Stuart McCulloch]

On 19 Dec 2013, at 15:31, Jeremy Whiting jwhit...@redhat.com wrote:

 Hi,
 I am using the maven-plugin-plugin for a hibernate project to provide a user 
 plugin. I am finding the Mojo definition is not generated.  I found a 
 workaround for the issue. This discussion is related to the issue discussed 
 here
 http://mail-archives.apache.org/mod_mbox/maven-users/201303.mbox/ajax/%3C201303081348.35442.thomas%40koch.ro%3E
 
 I'm using Java5 annotations to define things like the goal and lifecycle 
 phase. There are no parameters for the Mojo. These are the only annotations 
 defined in the Mojo.
 
 ...
 @Mojo ( name=enhance, defaultPhase = LifecyclePhase.COMPILE )
 @Execute ( goal =enhance , phase = LifecyclePhase.COMPILE )
 public class MavenEnhancePlugin extends AbstractMojo implements 
 EnhancementContext {
 ...
 
 I've found the two descriptor files generated can be generated either with or 
 without a Mojo definition. Depending on the execution of the goal 'package' 
 happening sequentially once or twice. Two examples are provided to 
 demonstrate this.
 These are two descriptor files referred to.
 
 META-INF/maven/plugin.xml
 META-INF/maven/org.hibernate.orm.tooling/hibernate-enhance-maven-plugin/plugin-help.xml
 
 For comparison here is command line output. Some of it is omitted for 
 brevity. You'll notice in Example 2 after the second package goal execution 
 there is a mojo tag in the descriptor.

Based on the log output below this looks like 
http://jira.codehaus.org/browse/MNG-5346

ie. the descriptor goal is running before the classes are compiled, and the 
Java5 annotation extractor works off the classes.

You’ll need to update your plugin configuration to look like the example in 
this link: 


http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html

ie. add additional executions to run the descriptor goal after the classes have 
been compiled.

 Example 1)
 
 $ mvn clean package -DskipTests
 [INFO] Scanning for projects...
 [INFO]
 [INFO] 
 
 [INFO] Building Enhance Plugin of the Hibernate project for use with Maven 
 build system. 4.2.8.Final
 [INFO] 
 
 [INFO]
 [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ 
 hibernate-enhance-maven-plugin ---
 [INFO] Deleting 
 /run/media/whitingjr/theark/work/redhat/java/jboss/hibernate/hibernate-orm/hibernate-enhance-maven-plugin/target
 [INFO]
 [INFO] --- maven-plugin-plugin:3.2:descriptor (default-descriptor) @ 
 hibernate-enhance-maven-plugin ---
 [INFO] Using 'UTF-8' encoding to read mojo metadata.
 [INFO] Applying mojo extractor for language: java-annotations
 [INFO] Mojo extractor for language: java-annotations found 0 mojo descriptors.
 [INFO] Applying mojo extractor for language: java
 [INFO] Mojo extractor for language: java found 0 mojo descriptors.
 [INFO] Applying mojo extractor for language: bsh
 [INFO] Mojo extractor for language: bsh found 0 mojo descriptors.
 [INFO]
 [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
 hibernate-enhance-maven-plugin ---
 [debug] execute contextualize
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] Copying 3 resources
 [INFO]
 [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ 
 hibernate-enhance-maven-plugin ---
 [INFO] Compiling 1 source file to 
 /run/media/whitingjr/theark/work/redhat/java/jboss/hibernate/hibernate-orm/hibernate-enhance-maven-plugin/target/classes
 [INFO]
 [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
 hibernate-enhance-maven-plugin ---
 [debug] execute contextualize
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] skip non existing resourceDirectory 
 /run/media/whitingjr/theark/work/redhat/java/jboss/hibernate/hibernate-orm/hibernate-enhance-maven-plugin/src/test/resources
 [INFO]
 [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ 
 hibernate-enhance-maven-plugin ---
 [INFO] No sources to compile
 [INFO]
 [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ 
 hibernate-enhance-maven-plugin ---
 [INFO] Tests are skipped.
 [INFO]
 [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ 
 hibernate-enhance-maven-plugin ---
 [INFO] Building jar: 
 /run/media/whitingjr/theark/work/redhat/java/jboss/hibernate/hibernate-orm/hibernate-enhance-maven-plugin/target/hibernate-enhance-maven-plugin-4.2.8.Final.jar
 [INFO]
 [INFO] --- maven-plugin-plugin:3.2:addPluginArtifactMetadata 
 (default-addPluginArtifactMetadata) @ hibernate-enhance-maven-plugin ---
 [INFO] 
 
 [INFO] BUILD SUCCESS
 [INFO] 
 
 [INFO] Total time: 4.005s
 [INFO] Finished at: Thu Dec 19 10:17:23 GMT 2013
 [INFO] Final Memory: 18M/333M
 [INFO] 
 

Re: is the wagon-maven-plugin broken?

[Stuart McCulloch]

Looks like a shading issue in maven-wagon/wagon-providers/wagon-http:


https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=blob;f=wagon-providers/wagon-http/pom.xml;h=1fd61e34da435024062a566f6bd68410d98fdc67;hb=HEAD#l87

It doesn’t shade in commons-io, commons-lang, or jsoup; despite 
wagon-http-shared switching from plexus-utils to commons-lang/io, and over to 
jsoup as the HTML parser:


https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=ec65719a

https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=02681881

[INFO] --- maven-shade-plugin:1.4:shade (default) @ wagon-http ---
[INFO] Excluding 
org.apache.maven.wagon:wagon-http-shared:jar:2.6-SNAPSHOT from the shaded jar.
[INFO] Excluding org.jsoup:jsoup:jar:1.7.2 from the shaded jar.
[INFO] Excluding commons-lang:commons-lang:jar:2.6 from the shaded jar.
[INFO] Excluding commons-io:commons-io:jar:2.2 from the shaded jar.
[INFO] Including org.apache.httpcomponents:httpclient:jar:4.3.1 in the 
shaded jar.
[INFO] Including commons-codec:commons-codec:jar:1.6 in the shaded jar.
[INFO] Including commons-logging:commons-logging:jar:1.1.3 in the 
shaded jar.
[INFO] Including org.apache.httpcomponents:httpcore:jar:4.3 in the 
shaded jar.
[INFO] Excluding 
org.apache.maven.wagon:wagon-provider-api:jar:2.6-SNAPSHOT from the shaded jar.
[INFO] Excluding org.codehaus.plexus:plexus-utils:jar:3.0.8 from the 
shaded jar.
[INFO] Attaching shaded artefact.

It might be less fragile to just exclude unwanted dependencies in the 
wagon-http shade configuration, rather than have to keep the list of includes 
in sync?

As to why the IT passes with M2 but fails with M3... wagon-http is included in 
the distribution lib (uber jar for M2, separate jar for M3) so M2 is using an 
older version of wagon that doesn’t suffer from the above issue.

On 16 Dec 2013, at 16:28, Dan Tran dant...@gmail.com wrote:

 fails with mvn 3 and works with mvn2 :(
 
 On Sun, Dec 15, 2013 at 11:11 PM, Sankaran, Nambi nsanka...@ebay.comwrote:
 
 Please try the integration tests from the http-download
 
 https://svn.codehaus.org/mojo/trunk/mojo/wagon-maven-plugin/src/it/http-download/
 
 
 -Original Message-
 From: Dan Tran [mailto:dant...@gmail.com]
 Sent: Sunday, December 15, 2013 11:09 PM
 To: Maven Users List
 Subject: Re: is the wagon-maven-plugin broken?
 
 got  small pom to reproduce this issue? does it work with maven 2?
 
 -D
 
 
 On Sun, Dec 15, 2013 at 9:32 PM, Sankaran, Nambi nsanka...@ebay.com
 wrote:
 
 None of the goals in “wagon-maven-plugin” work
 http://mojo.codehaus.org/wagon-maven-plugin/plugin-info.html
 
 Have anyone used any of these goals before?
 
 https://svn.codehaus.org/mojo/trunk/mojo/wagon-maven-plugin/src/it/htt
 p-download/pom.xml
 
 [INFO] Scanning for projects...
 [WARNING]
 [WARNING] Some problems were encountered while building the effective
 model for org.codehaus.mojo:wagon-maven-plugin:pom:testing
 [WARNING] 'build.plugins.plugin.version' for
 org.codehaus.mojo:wagon-maven-plugin is missing. @ line 16, column 21
 [WARNING] [WARNING] It is highly recommended to fix these problems
 because they threaten the stability of your build.
 [WARNING]
 [WARNING] For this reason, future Maven versions might no longer
 support building such malformed projects.
 [WARNING]
 [INFO]
 [INFO]
 --
 -- [INFO] Building wagon-maven-plugin testing [INFO]
 --
 --
 [INFO]
 [INFO] --- wagon-maven-plugin:1.0-beta-4:list (http-list) @
 wagon-maven-plugin --- [INFO] Scanning remote file system:
 http://repo1.maven.org/maven2/commons-dbutils/commons-dbutils ...
 [INFO]
 --
 --
 [INFO] BUILD FAILURE
 [INFO]
 --
 --
 [INFO] Total time: 7.598s
 [INFO] Finished at: Sun Dec 15 21:29:01 PST 2013 [INFO] Final Memory:
 6M/123M [INFO]
 --
 --
 [ERROR] Failed to execute goal
 org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:list (http-list) on
 project
 wagon-maven-plugin: Execution http-list of goal
 org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:list failed: A
 required class was missing while executing
 org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:list:
 org/apache/commons/io/IOUtils
 [ERROR] -
 [ERROR] realm =pluginorg.codehaus.mojo:wagon-maven-plugin:1.0-beta-4
 [ERROR] strategy =
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
 [ERROR] urls[0] =
 file:/Users/nsankaran/.m2/raptor2/org/codehaus/mojo/wagon-maven-plugin
 /1.0-beta-4/wagon-maven-plugin-1.0-beta-4.jar
 [ERROR] urls[1] =
 

Re: is the wagon-maven-plugin broken?

[Stuart McCulloch]

On 16 Dec 2013, at 18:45, Dan Tran dant...@gmail.com wrote:

 Thank you Stuart for root cause analysis
 
 So I guess the work around is to place commons-io, commons-lang and jsoup
 at maven3's lib directory.
 
 Do we have jira for wagon for this issue?

There you go:  http://jira.codehaus.org/browse/WAGON-407

 -D
 
 
 On Mon, Dec 16, 2013 at 9:38 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 Looks like a shading issue in maven-wagon/wagon-providers/wagon-http:
 
 
 https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=blob;f=wagon-providers/wagon-http/pom.xml;h=1fd61e34da435024062a566f6bd68410d98fdc67;hb=HEAD#l87
 
 It doesn’t shade in commons-io, commons-lang, or jsoup; despite
 wagon-http-shared switching from plexus-utils to commons-lang/io, and over
 to jsoup as the HTML parser:
 
 
 https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=ec65719a
 
 https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=02681881
 
[INFO] --- maven-shade-plugin:1.4:shade (default) @ wagon-http ---
[INFO] Excluding
 org.apache.maven.wagon:wagon-http-shared:jar:2.6-SNAPSHOT from the shaded
 jar.
[INFO] Excluding org.jsoup:jsoup:jar:1.7.2 from the shaded jar.
[INFO] Excluding commons-lang:commons-lang:jar:2.6 from the shaded
 jar.
[INFO] Excluding commons-io:commons-io:jar:2.2 from the shaded jar.
[INFO] Including org.apache.httpcomponents:httpclient:jar:4.3.1 in
 the shaded jar.
[INFO] Including commons-codec:commons-codec:jar:1.6 in the shaded
 jar.
[INFO] Including commons-logging:commons-logging:jar:1.1.3 in the
 shaded jar.
[INFO] Including org.apache.httpcomponents:httpcore:jar:4.3 in the
 shaded jar.
[INFO] Excluding
 org.apache.maven.wagon:wagon-provider-api:jar:2.6-SNAPSHOT from the shaded
 jar.
[INFO] Excluding org.codehaus.plexus:plexus-utils:jar:3.0.8 from
 the shaded jar.
[INFO] Attaching shaded artefact.
 
 It might be less fragile to just exclude unwanted dependencies in the
 wagon-http shade configuration, rather than have to keep the list of
 includes in sync?
 
 As to why the IT passes with M2 but fails with M3... wagon-http is
 included in the distribution lib (uber jar for M2, separate jar for M3) so
 M2 is using an older version of wagon that doesn’t suffer from the above
 issue.
 
 On 16 Dec 2013, at 16:28, Dan Tran dant...@gmail.com wrote:
 
 fails with mvn 3 and works with mvn2 :(
 
 On Sun, Dec 15, 2013 at 11:11 PM, Sankaran, Nambi nsanka...@ebay.com
 wrote:
 
 Please try the integration tests from the http-download
 
 
 https://svn.codehaus.org/mojo/trunk/mojo/wagon-maven-plugin/src/it/http-download/
 
 
 -Original Message-
 From: Dan Tran [mailto:dant...@gmail.com]
 Sent: Sunday, December 15, 2013 11:09 PM
 To: Maven Users List
 Subject: Re: is the wagon-maven-plugin broken?
 
 got  small pom to reproduce this issue? does it work with maven 2?
 
 -D
 
 
 On Sun, Dec 15, 2013 at 9:32 PM, Sankaran, Nambi nsanka...@ebay.com
 wrote:
 
 None of the goals in “wagon-maven-plugin” work
 http://mojo.codehaus.org/wagon-maven-plugin/plugin-info.html
 
 Have anyone used any of these goals before?
 
 https://svn.codehaus.org/mojo/trunk/mojo/wagon-maven-plugin/src/it/htt
 p-download/pom.xml
 
 [INFO] Scanning for projects...
 [WARNING]
 [WARNING] Some problems were encountered while building the effective
 model for org.codehaus.mojo:wagon-maven-plugin:pom:testing
 [WARNING] 'build.plugins.plugin.version' for
 org.codehaus.mojo:wagon-maven-plugin is missing. @ line 16, column 21
 [WARNING] [WARNING] It is highly recommended to fix these problems
 because they threaten the stability of your build.
 [WARNING]
 [WARNING] For this reason, future Maven versions might no longer
 support building such malformed projects.
 [WARNING]
 [INFO]
 [INFO]
 --
 -- [INFO] Building wagon-maven-plugin testing [INFO]
 --
 --
 [INFO]
 [INFO] --- wagon-maven-plugin:1.0-beta-4:list (http-list) @
 wagon-maven-plugin --- [INFO] Scanning remote file system:
 http://repo1.maven.org/maven2/commons-dbutils/commons-dbutils ...
 [INFO]
 --
 --
 [INFO] BUILD FAILURE
 [INFO]
 --
 --
 [INFO] Total time: 7.598s
 [INFO] Finished at: Sun Dec 15 21:29:01 PST 2013 [INFO] Final Memory:
 6M/123M [INFO]
 --
 --
 [ERROR] Failed to execute goal
 org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:list (http-list) on
 project
 wagon-maven-plugin: Execution http-list of goal
 org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:list failed: A
 required class was missing while executing
 org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:list:
 org/apache/commons/io/IOUtils
 [ERROR

Re: Upgrade to 3.1.1 causes problems

[Stuart McCulloch]

You could try replacing:

maven-3.1.1/boot/plexus-classworlds-2.5.1.jar

with:

maven-3.0.5/boot/plexus-classworlds-2.4.jar

in case the change to use unsynchronised class loading in classworlds 2.5 when 
running on Java 1.7 is causing the issue.

On 5 Dec 2013, at 16:32, Collins Solutions collins-soluti...@austin.rr.com 
wrote:

 It is happening on more than one machine.
 
 On 12/04/2013 10:14 PM, Wayne Fay wrote:
 ...well, it looks as though this is only a temporary solution. After I got
 everything to build successfully once I cleaned out my repository, I got the
 same error when I ran the build a second time. I tried upgraded my Maven
 Is this only happening on one machine, or more than one?
 
 Wayne
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Maven compilation error is not within its bound

[Stuart McCulloch]

On 2 Dec 2013, at 11:15, Adrien Ruffié adriennolar...@hotmail.fr wrote:

 I have found more information here:
 
 http://stackoverflow.com/questions/19266797/different-compilation-behavior-w
 ith-type-cast-between-eclipse-and-maven/19267547#19267547
 
 that say:
 
 Eclipse comes with its own Java compiler; Maven uses javac. Most of the
 time, both accept the same code but generics are complicated and compiler do
 have bugs. There are a couple of known bugs in javac of Java 6 which cause
 problems, for example.
 
 Oracle will not fix them. The solution is to use Java 7 to run Maven and
 configure the maven-compiler-plugin the generate Java 6 byte code (see Kumar
 Sambhav's answer).
 
 
 But how I can use Eclipse to compile in Maven ?

See 
http://maven.apache.org/plugins/maven-compiler-plugin/non-javac-compilers.html 
- to use the eclipse compiler:

  plugin
artifactIdmaven-compiler-plugin/artifactId
version3.1/version
configuration
  compilerIdeclipse/compilerId
/configuration
dependencies
  dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-compiler-eclipse/artifactId
version2.3/version
  /dependency
/dependencies
  /plugin

 Because I try this:
 
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source1.6/source
target1.6/target
compilerVersion1.6/compilerVersion
forktrue/fork
executablejava -classpath
 ${env.M2_REPO}/org/eclipse/jdt/${org.eclipse.jdt.core.version}/core-${or
 g.eclipse.jdt.core.version}.jar
 org.eclipse.jdt.internal.compiler.batch.Main -classpath rt.jar
 -sourcepath src/main/executable
/configuration
dependencies
dependency
groupIdorg.eclipse.jdt/groupId
artifactIdcore/artifactId
version3.3.0-v_771/version 
/dependency
/dependencies
 /plugin
 
 But I get the following error I attached file
 
 Do you know how I can correctly build my project ?
 
 
 
 
 -Message d'origine-
 De : Alexander Kriegisch [mailto:alexan...@kriegisch.name] 
 Envoyé : lundi 2 décembre 2013 10:55
 À : users@maven.apache.org
 Objet : Re: Maven compilation error is not within its bound
 
 Maven does not compile anything, the Java compiler does. The Maven Compiler
 Plugin is used to configure compilation according to your needs:
 http://maven.apache.org/plugins/maven-compiler-plugin/
 
 Maven default source/target version is 1.5, as you can see in the parent
 POM:
 http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-23/pom.xml?view=co;
 revision=1434744content-type=text%2Fplain
 
 If you want 1.6, please override like this:
 
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-compiler-plugin/artifactId
   version3.0/version
   configuration
   source1.6/source
   target1.6/target
   /configuration
 /plugin
 
 -- 
 Alexander Kriegisch
 
 
 Adrien Ruffié schrieb am 02.12.2013 10:36:
 
 Hello Alexander,
 
 Thank you very much for your response,
 
 For maven version is 3.0.4, the property java.version is set to 1.6 and my
 Eclipse project is 1.6 in compiler properties tab.
 I cannot use Maven+Eclipse to package my webapp because, it is Jenkins
 with maven which package, but maven doesn#039;t compile correctly ...
 The generics doesn#039;t cause problem in the webapp (we have make
 several testcases), but were I can see which compiler source/target is
 used by Eclipse/Maven ?
 
 Great thank again
 
 Adrien
 
 -Message d#039;origine-
 De : Alexander Kriegisch [mailto:alexan...@kriegisch.name] 
 Envoyé : lundi 2 décembre 2013 10:24
 À : Maven Users List
 Objet : Re: Maven compilation error quot;is not within its boundquot;
 
 Do Eclipse and Maven use the same compiler source/target versions? Which
 is you Maven version?
 
 To me it looks like you do have a problem with generics there. Maybe you
 use a new feature from a Java version greater than the one used by Maven.
 Hard to speculate without source code and pom.xml though.
 
 -- 
 Alexander Kriegisch
 
 
 gt; Am 02.12.2013 um 10:13 schrieb Adrien Ruffié
 lt;adriennolar...@hotmail.frgt;:
 gt; 
 gt; Hello all, 
 gt; 
 gt; I have my webapp projet in Eclipse which compile correctly but when I
 try to
 gt; perform quot;mvn clean compilequot;, several following logs
 appears: 
 gt; 
 gt; [ERROR]
 gt;
 
 \Java\Workspaces\Indigo\mycompanycrm4\mycompany-webapp\src\main\java\com\myc
 gt;
 
 ompany\frontline\display\render\custom\ImageHandleBarRenderBoolCustom.java:[
 gt; 16,95] type parameter
 gt;
 
 com.mycompany.frontline.property.display.valuable.bean.BooleanMonoValueBean
 gt; is not within its bound 
 gt; 
 gt; My class implements correctly generic, inteface, 

Re: Maven compilation error is not within its bound

[Stuart McCulloch]

On 2 Dec 2013, at 15:31, Adrien Ruffié adriennolar...@hotmail.fr wrote:

 Not very well ... sorry it is  a very bad problem because I'm cannot upgrade
 to Java 1.7 and all not give me satisfaction in compilation, so Eclipse work
 well ... I don't have idea

You shouldn't need to upgrade to Java 1.7 to use the eclipse compiler in Maven, 
just use the plugin configuration shown below and Maven will compile your code 
using the eclipse compiler (also known as ecj).

 -Message d'origine-
 De : Stuart McCulloch [mailto:mccu...@gmail.com] 
 Envoyé : lundi 2 décembre 2013 15:35
 À : Maven Users List
 Objet : Re: Maven compilation error is not within its bound
 
 On 2 Dec 2013, at 11:15, Adrien Ruffié adriennolar...@hotmail.fr wrote:
 
 I have found more information here:
 
 http://stackoverflow.com/questions/19266797/different-compilation-beha
 vior-w
 ith-type-cast-between-eclipse-and-maven/19267547#19267547
 
 that say:
 
 Eclipse comes with its own Java compiler; Maven uses javac. Most of 
 the time, both accept the same code but generics are complicated and 
 compiler do have bugs. There are a couple of known bugs in javac of 
 Java 6 which cause problems, for example.
 
 Oracle will not fix them. The solution is to use Java 7 to run Maven 
 and configure the maven-compiler-plugin the generate Java 6 byte code 
 (see Kumar Sambhav's answer).
 
 
 But how I can use Eclipse to compile in Maven ?
 
 See
 http://maven.apache.org/plugins/maven-compiler-plugin/non-javac-compilers.ht
 ml - to use the eclipse compiler:
 
  plugin
artifactIdmaven-compiler-plugin/artifactId
version3.1/version
configuration
  compilerIdeclipse/compilerId
/configuration
dependencies
  dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-compiler-eclipse/artifactId
version2.3/version
  /dependency
/dependencies
  /plugin
 
 Because I try this:
 
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-compiler-plugin/artifactId
   version2.0.2/version
   configuration
   source1.6/source
   target1.6/target
   compilerVersion1.6/compilerVersion
   forktrue/fork
   executablejava -classpath 
 ${env.M2_REPO}/org/eclipse/jdt/${org.eclipse.jdt.core.version}/core-${
 or
 g.eclipse.jdt.core.version}.jar
 org.eclipse.jdt.internal.compiler.batch.Main -classpath rt.jar 
 -sourcepath src/main/executable
   /configuration
   dependencies
   dependency
   groupIdorg.eclipse.jdt/groupId
   artifactIdcore/artifactId
   version3.3.0-v_771/version 
   /dependency
   /dependencies
 /plugin
 
 But I get the following error I attached file
 
 Do you know how I can correctly build my project ?
 
 
 
 
 -Message d'origine-
 De : Alexander Kriegisch [mailto:alexan...@kriegisch.name] Envoyé : 
 lundi 2 décembre 2013 10:55 À : users@maven.apache.org Objet : Re: 
 Maven compilation error is not within its bound
 
 Maven does not compile anything, the Java compiler does. The Maven 
 Compiler Plugin is used to configure compilation according to your needs:
 http://maven.apache.org/plugins/maven-compiler-plugin/
 
 Maven default source/target version is 1.5, as you can see in the 
 parent
 POM:
 http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-23/pom.xml?vi
 ew=co revision=1434744content-type=text%2Fplain
 
 If you want 1.6, please override like this:
 
 plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-compiler-plugin/artifactId
  version3.0/version
  configuration
  source1.6/source
  target1.6/target
  /configuration
 /plugin
 
 --
 Alexander Kriegisch
 
 
 Adrien Ruffié schrieb am 02.12.2013 10:36:
 
 Hello Alexander,
 
 Thank you very much for your response,
 
 For maven version is 3.0.4, the property java.version is set to 1.6 
 and my Eclipse project is 1.6 in compiler properties tab.
 I cannot use Maven+Eclipse to package my webapp because, it is 
 Jenkins with maven which package, but maven doesn#039;t compile
 correctly ...
 The generics doesn#039;t cause problem in the webapp (we have make 
 several testcases), but were I can see which compiler source/target 
 is used by Eclipse/Maven ?
 
 Great thank again
 
 Adrien
 
 -Message d#039;origine-
 De : Alexander Kriegisch [mailto:alexan...@kriegisch.name] Envoyé : 
 lundi 2 décembre 2013 10:24 À : Maven Users List Objet : Re: Maven 
 compilation error quot;is not within its boundquot;
 
 Do Eclipse and Maven use the same compiler source/target versions? 
 Which is you Maven version?
 
 To me it looks like you do have a problem with generics there. Maybe 
 you use a new feature from a Java version greater than the one used by
 Maven.
 Hard to speculate without source code and pom.xml though.
 
 --
 Alexander

Re: maven 3.1.1 StackOverflowError

[Stuart McCulloch]

Looks like http://jira.codehaus.org/browse/PLXCOMP-208 which was fixed in 
plexus-archiver-2.2.

Which plugin was executing before the error? It should hopefully just be a 
matter of updating your pom.xml to use a more recent version of the plugin 
which depends on plexus-archiver-2.2 or later.

On 22 Nov 2013, at 20:23, Goldfish captain.p.goldf...@gmx.de wrote:

 Hi I'm trying to install my maven project and it is ending in a
 StackOverflowError.
 I can build it on several systems but the one system that it must build on
 in the end does not finish... I just can't explain to myself what this error
 even means and trying google on this error did not help either...
 
 Exception in thread main java.lang.StackOverflowError
   at sun.nio.cs.US_ASCII$Encoder.encodeArrayLoop(US_ASCII.java:198)
   at sun.nio.cs.US_ASCII$Encoder.encodeLoop(US_ASCII.java:231)
   at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561)
   at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:271)
   at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
   at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207)
   at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:129)
   at java.io.PrintStream.write(PrintStream.java:526)
   at java.io.PrintStream.print(PrintStream.java:669)
   at java.io.PrintStream.println(PrintStream.java:806)
   at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:381)
   at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:376)
   at org.slf4j.impl.SimpleLogger.info(SimpleLogger.java:538)
   at org.apache.maven.cli.logging.Slf4jLogger.info(Slf4jLogger.java:59)
   at
 org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:464)
   at
 org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:467)
   at
 org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:467)
   at
 org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:467)
 
 
 The system is: 
 Debian Linux 7.0
 Kernel and CPU  Linux 3.2.0-4-686-pae on i686
 
 
 
 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/maven-3-1-1-StackOverflowError-tp5776099.html
 Sent from the Maven - Users mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: MavenEmbedder problem with 3.1.x

[Stuart McCulloch]

Update the lib-jenkins-maven-embedder dependency to version 3.11, since this is 
the version that works with the latest aether/sisu dependencies.

On 20 Nov 2013, at 09:41, Bernd Adamowicz wrote:

 No answer so far. Should I file a bug? Any opinion?
 
 Bernd Adamowicz
 
 
 -Original Message-
 From: Bernd Adamowicz [mailto:bernd.adamow...@esailors.de] 
 Sent: Montag, 18. November 2013 16:12
 To: users@maven.apache.org
 Subject: MavenEmbedder problem with 3.1.x
 
 Hi all,
 
 When switching from Maven 3.0.x to 3.1.x some of our projects where not able 
 to execute anymore due to a problem with MavenEmbedder. Both projects are 
 command line based, no Maven plugin around it.
 
 I think the most important part of the stack trace is this:
 
 37) No implementation for 
 java.util.Setorg.eclipse.aether.spi.localrepo.LocalRepositoryManagerFactory 
 was bound.
  while locating 
 java.util.Setorg.eclipse.aether.spi.localrepo.LocalRepositoryManagerFactory
for parameter 0 at 
 org.eclipse.aether.internal.impl.DefaultLocalRepositoryProvider.init(Unknown
 ...
 37 errors
  role: org.apache.maven.execution.MavenExecutionRequestPopulator
  roleHint:
at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:246)
at hudson.maven.MavenEmbedder.lookup(MavenEmbedder.java:567)
at 
 hudson.maven.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:157)
at hudson.maven.MavenEmbedder.init(MavenEmbedder.java:120)
at hudson.maven.MavenEmbedder.init(MavenEmbedder.java:109)
at hudson.maven.MavenEmbedder.init(MavenEmbedder.java:136)
at test.embedder.AppTest.testLookup(AppTest.java:57)
 
 I know this problem came when I changed my aether-dependencies from 
 'org.sonatype.aether' to 'org.eclipse.aether' in order to work with Maven 
 3.1.x.
 
 Fortunately this can be reproduced with a simple project which can be found 
 here: https://dl.dropboxusercontent.com/u/86229859/embedder-test.tgz
 
 Usage of the MavenEmbedder looks like this:
 
 package test.embedder;
 import hudson.maven.MavenEmbedder;
 import hudson.maven.MavenEmbedderException;
 import hudson.maven.MavenRequest;
 import java.io.File;
 import org.apache.maven.model.building.ModelBuildingRequest;
 import org.apache.maven.project.MavenProject;
 
 public class App {
private static final ClassLoadermavenClassLoader = 
 App.class.getClassLoader();
private static final ThreadLocalMavenEmbedder embedder = new 
 ThreadLocalMavenEmbedder() {
 
 @Override
 protected MavenEmbedder initialValue() {
 try {
 MavenRequest req = new MavenRequest();
 
 req.setValidationLevel(ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_3_1);
 return new MavenEmbedder(mavenClassLoader, req);
 } catch (MavenEmbedderException e) {
 throw new RuntimeException(
 Error creating MavenEmbedder, e);
 }
 }
 };
 
public static MavenProject getMavenProject(File pomFile) {
try {
return embedder.get().readProject(pomFile);
} catch (Exception e) {
throw new RuntimeException(Error parsing POM at  + pomFile, e);
}
}
 }
 
 This unit test will then trigger the error:
 
 package test.embedder;
 import static org.testng.AssertJUnit.assertEquals;
 import static org.testng.AssertJUnit.assertNotNull;
 import java.io.File;
 import org.apache.commons.io.FileUtils;
 import org.apache.maven.project.MavenProject;
 import org.testng.annotations.BeforeClass;
 import org.testng.annotations.Test;
 
 public class AppTest {
private static File mvnUtilFolder = null;
@BeforeClass
public static void setUpBeforeClass() throws Exception {
mvnUtilFolder = 
 FileUtils.toFile(AppTest.class.getClassLoader().getResource(mvnUtil));
}
 
@Test
public void testGetMavenProject() {
File mvnPom = new File(mvnUtilFolder.getAbsolutePath() + /pom.xml);
MavenProject mvnProject = App.getMavenProject(mvnPom);
assertNotNull(mvnProject);
assertEquals(3.5.2, mvnProject.getVersion());
}
 }
 
 For me all this looks like a 'simple' classloader issue when Guice tries to 
 load the classes (e.g.:  
 org.eclipse.aether.spi.localrepo.LocalRepositoryManagerFactory) but can't 
 find them.
 
 I've googled presumably all the places dealing with problems when 

Re: Dependency exclusions being ignored

[Stuart McCulloch]

Try adding:

typeplugin/type

to those 2 dependency exclusions.

( the jaxen pom: 
http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pom
 declares those dependencies to be of type plugin )

On 14 Nov 2013, at 13:14, Jason Tesser wrote:

 I have the following POM http://pastebin.com/P4TvzqJn but my exclusion for
 artifactIdabdera-client/artifactId are not being respected.  Actually
 only 2 of them are not
 the 2 not working are maven-plugins and maven-plugins
 they are coming down anyways
 see http://pastebin.com/c59HM8Bj
 what am I missing
 I have altered the POM but I cleared my local cache and refreshed
 dependencies


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

Re: Dependency exclusions being ignored

[Stuart McCulloch]

You mean the POM relocation to an other version number is not fully supported 
in Gradle message?

If you look at the pom it has a relocation element (bit like a symbolic link):


http://search.maven.org/remotecontent?filepath=xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom


http://maven.apache.org/guides/mini/guide-relocation.html#How_to_relocate_a_Maven_2_artifact_to_a_different_groupId

you'd have to ask the Gradle team why they don't fully support this.

As a workaround you could force the version to 1.0.b2 in your 
dependencyManagement section:

dependency
groupIdxml-apis/groupId
artifactIdxml-apis/artifactId
version1.0.b2/version
/dependency

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
  (see part about managing versions of transitive dependencies)

On 14 Nov 2013, at 14:32, Jason Tesser wrote:

 you are referring to the maven-plugins I think
 
 But what about the xml-api thing?
 
 On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 Try adding:
 
typeplugin/type
 
 to those 2 dependency exclusions.
 
 ( the jaxen pom:
 http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pomdeclares
  those dependencies to be of type plugin )
 
 On 14 Nov 2013, at 13:14, Jason Tesser wrote:
 
 I have the following POM http://pastebin.com/P4TvzqJn but my exclusion
 for
 artifactIdabdera-client/artifactId are not being respected.  Actually
 only 2 of them are not
 the 2 not working are maven-plugins and maven-plugins
 they are coming down anyways
 see http://pastebin.com/c59HM8Bj
 what am I missing
 I have altered the POM but I cleared my local cache and refreshed
 dependencies
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 


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

Re: Dependency exclusions being ignored

[Stuart McCulloch]

Doh, sorry - worth a try :)

You could try forcing jaxen to 1.1.4 (using dependencyManagement) as that 
version doesn't have those odd plugin dependencies

On 14 Nov 2013, at 14:36, Jason Tesser wrote:

 Also that doesn't work. Invalid POM
 
 cannot say
 exclusion
 groupIdmaven-plugins/groupId
 artifactIdmaven-cobertura-plugin/artifactId
 typeplugin/type
 /exclusion
 
 
 On Thu, Nov 14, 2013 at 9:32 AM, Jason Tesser jasontes...@gmail.com wrote:
 
 you are referring to the maven-plugins I think
 
 But what about the xml-api thing?
 
 
 On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu...@gmail.comwrote:
 
 Try adding:
 
typeplugin/type
 
 to those 2 dependency exclusions.
 
 ( the jaxen pom:
 http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pomdeclares
  those dependencies to be of type plugin )
 
 On 14 Nov 2013, at 13:14, Jason Tesser wrote:
 
 I have the following POM http://pastebin.com/P4TvzqJn but my exclusion
 for
 artifactIdabdera-client/artifactId are not being respected.
 Actually
 only 2 of them are not
 the 2 not working are maven-plugins and maven-plugins
 they are coming down anyways
 see http://pastebin.com/c59HM8Bj
 what am I missing
 I have altered the POM but I cleared my local cache and refreshed
 dependencies
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 


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

Re: Dependency exclusions being ignored

[Stuart McCulloch]

BTW, I ran your pom.xml through:

mvn dependency:tree

using Maven3 and the exclusions for those 2 maven-plugins were respected, which 
suggests your exclusion issue might also be specific to Gradle.

On 14 Nov 2013, at 14:53, Stuart McCulloch wrote:

 You mean the POM relocation to an other version number is not fully 
 supported in Gradle message?
 
 If you look at the pom it has a relocation element (bit like a symbolic link):
 
   
 http://search.maven.org/remotecontent?filepath=xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom
 
   
 http://maven.apache.org/guides/mini/guide-relocation.html#How_to_relocate_a_Maven_2_artifact_to_a_different_groupId
 
 you'd have to ask the Gradle team why they don't fully support this.
 
 As a workaround you could force the version to 1.0.b2 in your 
 dependencyManagement section:
 
dependency
   groupIdxml-apis/groupId
   artifactIdxml-apis/artifactId
   version1.0.b2/version
/dependency
 
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
   (see part about managing versions of transitive dependencies)
 
 On 14 Nov 2013, at 14:32, Jason Tesser wrote:
 
 you are referring to the maven-plugins I think
 
 But what about the xml-api thing?
 
 On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 Try adding:
 
   typeplugin/type
 
 to those 2 dependency exclusions.
 
 ( the jaxen pom:
 http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pomdeclares
  those dependencies to be of type plugin )
 
 On 14 Nov 2013, at 13:14, Jason Tesser wrote:
 
 I have the following POM http://pastebin.com/P4TvzqJn but my exclusion
 for
 artifactIdabdera-client/artifactId are not being respected.  Actually
 only 2 of them are not
 the 2 not working are maven-plugins and maven-plugins
 they are coming down anyways
 see http://pastebin.com/c59HM8Bj
 what am I missing
 I have altered the POM but I cleared my local cache and refreshed
 dependencies
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 


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

Re: A case that fools maven-compiler-plugin

[Stuart McCulloch]

Looks like a JDK issue, because I can recreate it by just using 'javac'

( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391197 seems the closest 
match )

As a workaround, move the import pack.Prop; line above the static import and 
it should compile.

On 12 Nov 2013, at 11:51, Adrian Panasiuk wrote:

 Hi,
 
 I have a found a case where maven-compiler-plugin 3.1 compiles files in the
 wrong order. As it is near impossible to post a bug report on jira, I'm
 posting here. If the bug is of any relevance, here's the test case, if it's
 not that important, then I'm cool with leaving it unresolved as well:
 
 
 // pack/Prop.java:
 
 package pack;
 
 public class Prop { }
 
 //pack/age/Cond.java:
 
 package pack.age;
 
 import static pack.age.Cond.De.and;
 import pack.Prop;
 
 
 public class Cond
 {
 public static class De extends Prop {
 public static void and() {}
 }
 public static void main( String[] args )
 {
 Prop z;
 }
 }
 
 
 mvn3 clean compile
 
 and an error message:
 
 [ERROR] /home/adi/plg/winiary/src/main/java/pack/age/Cond.java:[9,40]
 cannot find symbol
 symbol: class Prop
 location: class pack.age.Cond
 
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
 (default-compile) on project ztrupa: Compilation failure
 [ERROR] /home/adi/plg/winiary/src/main/java/pack/age/Cond.java:[9,40]
 cannot find symbol
 [ERROR] symbol: class Prop
 [ERROR] location: class pack.age.Cond
 
 
 Best regards,
 AP


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

Re: Get last version of a artifact

[Stuart McCulloch]

Looking at the *MetadataSource components in the Maven source they're only 
bound under:

org.apache.maven.artifact.metadata.ArtifactMetadataSource

and not:

org.apache.maven.repository.legacy.metadata.ArtifactMetadataSource

For example in MavenMetadataSource.java:

import org.apache.maven.artifact.metadata.ArtifactMetadataSource;
// ...

@Component( role = ArtifactMetadataSource.class, hint = maven )
public class MavenMetadataSource
implements ArtifactMetadataSource
{
// ...

So if you change to use 
org.apache.maven.artifact.metadata.ArtifactMetadataSource it should work (this 
is the API supported by both Maven 2.x and 3.x)

HTH

On 30 Oct 2013, at 13:24, Romain Gilles wrote:

 Hi all,
 I'm developing a maven plugin and I want to discover the last version of a
 specific artifact. I had a look to the maven-vesions-plugin. But I don't
 know why when I try to get a (deprecated) ArtifacteMetadataSource as follow:
   @Component
private ArtifactMetadataSource artifactMetadataSource
 
 I get an exception:
 
 1) No implementation for
 org.apache.maven.repository.legacy.metadata.ArtifactMetadataSource was
 bound.
 
 I'm usign Maven 3.0.5 as a model and runtime.
 Could somebody help me?
 
 Thanks,
 
 Romain.


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

Re: How to filter Project artifacts/dependencies?

[Stuart McCulloch]

You can use requiresDependencyResolution (as Anders mentioned below) to choose 
the initial scope of what gets populated into project.getArtifacts

You can also use maven-common-artifact-filters to filter those artifacts 
further by scope, groupId, artifactId, etc:


http://maven.apache.org/shared/maven-common-artifact-filters/project-summary.html

http://maven.apache.org/shared/maven-common-artifact-filters/apidocs/index.html

On 17 Oct 2013, at 07:26, Anders Hammar wrote:

 I believe you handle scope via the Mojo annotation [1]. Have a look at*
 requiresDependencyResolution.*
 
 [1]
 http://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Mojo.html
 
 /Anders
 
 
 On Thu, Oct 17, 2013 at 5:00 AM, Pino Silvaggio 
 pino.silvag...@gmail.comwrote:
 
 I am writing a Maven plugin which needs to filter a project dependencies
 based criteria like scope, is snapshot, is optional, the groupId, etc...
 
 So, all the Project.getRuntimeArtifacts(), getCompileArtifacts(), etc..
 are deprecated.
 
 There is still getArtifacts().
 
 But how do you filter a project dependencies efficiently. Yea, I've looked
 at aether but that doesn't seem to be an option since it doesn't look like
 there is a way to account for the project resolved dependencies?
 
 So the question is how do you filter a project dependencies like aether
 can with filters.
 
 Also, why is there no way to ask if a dependency will be in a specific
 scope?
 
 Like if dependency a will be in scope Runtime, Compile and Test.
 
 -
 
 p
 
 
 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 


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

Re: Build error java.lang.IllegalArgumentException: Negative time, at java.io.File.setLastModified(File.java:1344)

[Stuart McCulloch]

Some related reports from 2011:

https://jira.codehaus.org/browse/MJAR-142
https://jira.codehaus.org/browse/MWAR-255

AFAICT the PlexusIoFileResource is effectively doing 
setLastModified(file.lastModified()) to 


https://github.com/sonatype/plexus-io/blob/master/src/main/java/org/codehaus/plexus/components/io/resources/PlexusIoFileResource.java#L107

This JDK bug could be triggering the problem:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6791812

In which case the PlexusIoFileResource code just needs to be more defensive and 
not trust that lastModified returns a positive value...

On 3 Oct 2013, at 19:29, Ron Wheeler wrote:

 This is an error that I get when I execute my project in Eclipse/STS while 
 running from a RAM drive.
 If I run the same project running on Eclipse/STS while running on a regular 
 disk drive it works.
 
 It is pretty deep in the Maven code and looks like Maven/Plexus sends a bad 
 argument to a Java function.
 
 I have found another complaint like this by Googling but no one had any 
 suggestion about how to fix it.
 
 My only fix is to stop using my high speed version and build it in my slow 
 disk based Eclipse and maven (Same software just not on a RAM drive).
 
 I am intrigued by the idea that I am able to achieve some ability to reverse 
 time but it does not actually let me get more work done in a day. Quite the 
 contrary.
 
 Ron
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.4:single (default) on 
 project util-pom-hibernate-mysql-tomcat: Execution default of goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed: Negative 
 time - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single (default) on 
 project util-pom-hibernate-mysql-tomcat: Execution default of goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed: Negative 
 time
at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default of goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single 
 failed: Negative time
at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
 Caused by: java.lang.IllegalArgumentException: Negative time
at java.io.File.setLastModified(File.java:1344)
at 
 org.codehaus.plexus.components.io.resources.PlexusIoFileResource.setLastModified(PlexusIoFileResource.java:174)
at 
 org.codehaus.plexus.components.io.resources.PlexusIoFileResource.setFile(PlexusIoFileResource.java:107)
at 
 org.codehaus.plexus.components.io.resources.PlexusIoFileResource.init(PlexusIoFileResource.java:82)
at 
 org.codehaus.plexus.components.io.resources.PlexusIoFileResource.init(PlexusIoFileResource.java:66)
at 
 org.codehaus.plexus.components.io.resources.PlexusIoFileResource.init(PlexusIoFileResource.java:49)
at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addParentDirs(AbstractZipArchiver.java:446)
at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:394)
at 
 

Re: Parent SNAPSHOT not resolved Maven 2.2.1 - 3.0.4 - (Nexus repo)

[Stuart McCulloch]

On 3 Oct 2013, at 11:11, Anders Hammar wrote:

 It should be the same for deps as well as parents. One difference could be
 if you have a repo declared in the pom (not setiings.xml). It might be that
 that repo is only used for deps and not the parent, I don't know.

FWIW, I've run some tests locally and confirm it is the same for (non-reactor) 
dependencies when you don't have a snapshot repository declared in your pom 
hierarchy or settings.xml

Use mvn help:effective-pom to check as a lot of corporate/oss organizational 
setups will declare a snapshot repository somewhere, otherwise Maven would not 
know where to fetch non-reactor snapshots.

PS. note that an anaemic repository entry with just an id and url is still 
considered a snapshot repository because the default setting for the snapshots 
and releases flags is true unless configured otherwise.

 /Anders
 
 On Thu, Oct 3, 2013 at 12:08 PM, NRO nourredine.roui...@gmail.com wrote:
 
 I understand your point, but the explaination you provide is based on how
 it
 is implemented...and not on how it is specified.
 
 The fact that maven can resolve the same artifact when it is a dependency
 means that it is not a limitation but an implementation issue.
 
 That looks bad to me to have to add a fake repository to have Maven resolve
 the parent SNAPSHOT.
 
 Note that in my example the foo repository does not exist at all neither
 http://foo URL.
 It is juste a fake declaration in the settings.xml.
 
 This means that maven at the end, failover and still uses the mirror to go
 to Nexus and retrieve the SNAPSHOT parent.
 
 Why (repo!=mirror) applies to Parent and not to project dependencies ?
 
 At the end we added the fake repo declaration to all our settings.xml, but
 that's not very elegant, but it works.
 
 
 
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Parent-SNAPSHOT-not-resolved-Maven-2-2-1-3-0-4-Nexus-repo-tp5772374p5772379.html
 Sent from the Maven - Users mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 


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

Re: Parent SNAPSHOT not resolved Maven 2.2.1 - 3.0.4 - (Nexus repo)

[Stuart McCulloch]

The scenario described below fails for me with or without a mirror setting - as 
I would expect it to.

Given a child project with a missing parent pom Maven will attempt to resolve 
the parent given the available context, namely:

settings.xml
current pom.xml
Maven's super-pom

If neither the settings.xml nor the current pom.xml define a snapshot 
repository then the only repository definition is from Maven's default 
super-pom:

  repositories
repository
  snapshots
enabledfalse/enabled
  /snapshots
  idcentral/id
  nameCentral Repository/name
  urlhttp://repo.maven.apache.org/maven2/url
/repository
  /repositories

which clearly disables snapshots.

Defining a mirror in your settings.xml does not change repository definitions, 
as Tamas mentioned before all it does is re-route requests via the mirror. 
Therefore since there are no repositories defined with snapshots enabled, Maven 
will not request to fetch the parent pom snapshot. But if you add a snapshot 
repository definition somewhere (settings.xml or current pom.xml) then Maven 
will respect that and request the parent pom snapshot from that repository. If 
you have a mirror in your settings.xml then that request will be routed via the 
server defined in the mirror.

Note that Maven will also attempt to use the parent relativePath definition 
from the current pom to attempt to find the parent pom on disk - so assuming 
the default relativePath, Maven would also be able to find the parent pom if it 
was located in the parent directory relative to the child (../pom.xml).

The same thing is true of snapshot dependencies - if none of your settings.xml, 
pom.xml, or any pom in the hierarchy define a snapshot repository then Maven 
will not have anywhere it could request the snapshot from, regardless of the 
mirror definition (as mirror != repository). Only if the snapshot dependency 
was available somewhere in the reactor (the effective plan of the build on 
disk) would Maven be able to resolve the snapshot.

HTH

On 3 Oct 2013, at 13:22, NRO wrote:

 Ok, lets talk with a concrete simple example:
 
 PARENT POM:
 
 project xmlns=http://maven.apache.org/POM/4.0.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
  modelVersion4.0.0/modelVersion
 
  groupIda.b.c/groupId
  artifactIdparente/artifactId
  version0.0.1-SNAPSHOT/version
  packagingpom/packaging
  nameparente/name
  descriptionddd/description
 
   distributionManagement
   repository
   idinternal.project.release/id
   nameinternal.project.release/name
   url${maven2Repository_projet}/project_release/url
   /repository
 
   snapshotRepository
   idinternal.project.snapshot/id
   nameinternal.project.snapshot/name
   url${maven2Repository_projet}/project_snapshot/url
   /snapshotRepository
 
   site
   idprojects_Website/id
   
 url${projects_Website}/cti/melusine/${project.artifactId}/${project.version}/url
   /site
   /distributionManagement
 /project
 ---
 CHILD POM
 
 project xmlns=http://maven.apache.org/POM/4.0.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
  modelVersion4.0.0/modelVersion
 
  parent
groupIda.b.c/groupId
artifactIdparente/artifactId
version0.0.1-SNAPSHOT/version
  /parent
 
  groupIda.c/groupId
  artifactIddeleteme/artifactId
  version0.0.1-SNAPSHOT/version
  nameaaa/name
  descriptionbbb/description
 /project
 -
 
 These very simple Poms demonstrate the problem.
 
 You need to deply parent first and then delete parent from local repo and
 then try building child.
 As you notice there are no SNAPSHOT repository declaration nowhere.
 Distibution managment is a separate thing in the parent itself.
 
 
 
 
 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Parent-SNAPSHOT-not-resolved-Maven-2-2-1-3-0-4-Nexus-repo-tp5772374p5772383.html
 Sent from the Maven - Users mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Parent SNAPSHOT not resolved Maven 2.2.1 - 3.0.4 - (Nexus repo)

[Stuart McCulloch]

On 3 Oct 2013, at 14:31, NRO wrote:

 Thanks for the clear explanation.
 
 All our artifacts are served by our Nexus Repository Manager (external and
 internal).
 All our repositories (hosted and proxy) are managed by Nexus, this is why
 our settings.xml and parent poms does not need to refer to other
 repositories because we want to control all from Nexus.
 
 So declaring a fake snapshot repository will help Maven re-route resolution
 to a parent pom...
 
 BTW if you replace the snapshot parent by a release version, the same
 problem appear despite the maven central in super pom...

This isn't what I see locally using the same poms as below, with the parent 
version set to a release it will attempt to fetch it:

...snip...
Downloading: 
http://repo.maven.apache.org/maven2/a/b/c/parente/0.0.1/parente-0.0.1.pom

Repeating the same test using a mirror (and clearing the local repository of 
any cached records about the pom, see below):

...snip...
Downloading: 
https://some.repo.manager/content/groups/some.group/a/b/c/parente/0.0.1/parente-0.0.1.pom

Note that Maven will record failed attempts to fetch releases in your local 
repository:

[ERROR] Non-resolvable parent POM: Failure to find 
a.b.c:parente:pom:0.0.1 in http://repo.maven.apache.org/maven2 was cached in 
the local repository,
resolution will not be reattempted until the update interval of 
central has elapsed or updates are forced and 'parent.relativePath' points at 
wrong local POM @ line 7, column 10 - [Help 2]

and will not attempt to fetch the release again until the update interval 
elapses (default is daily) or you use -U to force it to re-check.

 Again adding the fake repository helps solving the case.
 
 I am still not convinced it is a feature ;-)

Since there is no snapshot repository defined in the current pom.xml, 
settings.xml, or Maven super-pom - and the relativePath doesn't lead to the 
parent pom - how should Maven know where to fetch it?

I guess you could say that defining a mirror in your settings.xml should add an 
implicit snapshot repository definition, but how would you remove such a 
repository definition if you didn't want it? Because each snapshot repository 
is queried separately, if you then defined additional snapshot repositories 
then you could end up with multiple queries going through the mirror. In a way 
this all comes back to the fact that mirror != repository and I'm not sure that 
mixing these concepts by adding implicit repositories based on mirror 
definitions is a good thing - especially when there's a simple solution 
(declare the repository in settings.xml) that captures the intent and would 
also work when not mirroring.

(just my 2 sen)

 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Parent-SNAPSHOT-not-resolved-Maven-2-2-1-3-0-4-Nexus-repo-tp5772374p5772386.html
 Sent from the Maven - Users mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Artifacts missing in maven-aether-provider in Maven 3.1.0

[Stuart McCulloch]

On 30 Sep 2013, at 14:22, Bernd Adamowicz wrote:

 OK. Thanks for clarifying this!
 
 However, one question remains about the missing classes:
 
 * org.apache.maven.repository.internal.MavenRepositorySystemSession
 * org.apache.maven.repository.internal.MavenServiceLocator
 
 Have they been replaced by other classes or is there a migration path? We're 
 using a plugin that depends on them.

Looking at the commit history those classes were replaced by the following 
methods:

MavenRepositorySystemUtils.newSession();

MavenRepositorySystemUtils.newServiceLocator();

https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=82b345e0094813b34fcac85e64dde2d5e02b4cc9

 Thanks,
 Bernd
 
 On Thu, 19 Sep 2013 23:52:20 +0200, Stuart McCulloch mccu...@gmail.com 
 wrote:
 
 Maven 3.1.0 was released after the Maven runtime project moved to git:
 
  https://git-wip-us.apache.org/repos/asf?p=maven.git;a=summary
 
 Specifically:
 
  
 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;h=5a0e6574404b4964522d90c3438e25574a95466c;hb=893ca28a1da9d5f51ac03827af98bb730128f9f2
 
 The tag you saw in svn is probably the leftover of an aborted release before 
 the move to git.
 
 On 19 Sep 2013, at 22:36, Bernd Adamowicz wrote:
 
 Hi all!
 
 When switching from 3.0.4 to 3.1.0 I encountered that obviously the classes
 
 * org.apache.maven.repository.internal.MavenRepositorySystemSession
 * org.apache.maven.repository.internal.MavenServiceLocator
 
 are no longer there. Seems, the last version with these classes was 3.0.5.
 
 However, if I check out maven-aether-provider from 
 http://svn.apache.org/repos/asf/maven/maven-3/tags/maven-3.1.0/maven-aether-provider
  and have a look at the sources, the classes are there. The Jar after 
 building the project also contains them. But the official Jar at Maven 
 Central does not.
 
 Tried to find a hint somewhere inside the release notes with no success. 
 So, can anyone tell me what's going on here? Where are these classes?
 
 Thanks for any help!
 Bernd
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 -- 
 Bernd Adamowicz
 Softwaremanagement
 
 Georg-Fahrbach-Straße 21
 74653 Ingelfingen-Criesbach
 Mobil: +49 (0)171 7278857
 Mail: i...@bernd-adamowicz.de
 http://www.bernd-adamowicz.de
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: issues when disabling settings.xml

[Stuart McCulloch]

On 24 Sep 2013, at 01:31, Jamie Archibald wrote:

 I typically work behind a Nexus server at work which I use a settings.xml
 file. When I come home I remove the settings.xml from my m2 folder.
 
 As soon as I do this I can no longer resolve my maven dependencies that are
 my work modules, even though they show up in my m2 repo.
 
 When I put the settings.xml back into my m2 repo the dependencies can
 resolve.
 
 This happens with both snapshots and non-snapshots.
 
 What am I missing here?

Sounds like http://jira.codehaus.org/browse/MNG-5181, the 
--legacy-local-repository option mentioned at the end of that issue is 
available in Maven 3.1.0

 -- 
 Jamie


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

Re: Artifacts missing in maven-aether-provider in Maven 3.1.0

[Stuart McCulloch]

Maven 3.1.0 was released after the Maven runtime project moved to git:

https://git-wip-us.apache.org/repos/asf?p=maven.git;a=summary

Specifically:


https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;h=5a0e6574404b4964522d90c3438e25574a95466c;hb=893ca28a1da9d5f51ac03827af98bb730128f9f2

The tag you saw in svn is probably the leftover of an aborted release before 
the move to git.

On 19 Sep 2013, at 22:36, Bernd Adamowicz wrote:

 Hi all!
 
 When switching from 3.0.4 to 3.1.0 I encountered that obviously the classes
 
 * org.apache.maven.repository.internal.MavenRepositorySystemSession
 * org.apache.maven.repository.internal.MavenServiceLocator
 
 are no longer there. Seems, the last version with these classes was 3.0.5.
 
 However, if I check out maven-aether-provider from 
 http://svn.apache.org/repos/asf/maven/maven-3/tags/maven-3.1.0/maven-aether-provider
  and have a look at the sources, the classes are there. The Jar after 
 building the project also contains them. But the official Jar at Maven 
 Central does not.
 
 Tried to find a hint somewhere inside the release notes with no success. So, 
 can anyone tell me what's going on here? Where are these classes?
 
 Thanks for any help!
 Bernd
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Maven parsing pom.xml incorrectly

[Stuart McCulloch]

On 18 Sep 2013, at 15:09, Paul Benedict wrote:

 I believe this behavior is correct. IIRC, XML does not allow double-dashes
 inside a comment.

Specifically http://www.w3.org/TR/REC-xml/#sec-comments

For compatibility, the string  --  (double-hyphen) must not occur 
within comments.

 On Wed, Sep 18, 2013 at 9:06 AM, Andrew Pennebaker 
 apenneba...@42six.comwrote:
 
 I'm using Thrift in my Maven project, compiling my .thrift code to .java as
 part of the generate-sources step. To do this, I use the maven antrun
 plugin in my pom.xml, which executes a command line call to the thrift
 executable, and sends it the appropriate argument flags, such as -out and
 --gen.
 
 However, when I comment out this plugin with the standard XML comment
 syntax !-- ... --, Maven fails to parse the pom file. It doesn't like the
 fact that the comment contains --gen, expecting the comment to end right
 there.
 
 Can we please improve Maven's comment syntax parsing for pom.xml?
 
 
 
 
 -- 
 Cheers,
 Paul


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

Re: Cannot find 'httpConfiguration' in class org.apache.maven.wagon.providers.http.LightweightHttpsWagon

[Stuart McCulloch]

Wagon is trying to apply a given configuration, but it fails because it has a 
property that doesn't exist in the chosen wagon provider.

Which version of Maven (and Wagon) are you using? Do you have a 
httpConfiguration section in your settings.xml?

On 18 Sep 2013, at 21:37, Richard Sand wrote:

 Can anyone tell me the providence of this error message?
 
 [WARNING] Could not apply configuration for idfconnect.com to wagon
 org.apache.maven.wagon.providers.http.LightweightHttpsWagon:Cannot find
 'httpConfiguration' in class
 org.apache.maven.wagon.providers.http.LightweightHttpsWagon
 
 Best regards,
 
 Richard
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Mojo Developer Cook Book: For accessing artifacts and repositories

[Stuart McCulloch]

Since Maven3 this class is available in the maven-compat component:


http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22maven-compat%22

Note that plugins compiled against the old maven-artifact component should 
still work with Maven3 (it gets translated under the covers)

On 14 Jul 2013, at 14:02, Igor Zapletnev wrote:

 I have tried to resolve artifact as described in mojo dev cook
 bookhttp://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook#MojoDeveloperCookbook-Creatingandresolvinganartifact.
 
 
 org.apache.maven.artifact.resolver.ArtifactResolver class is missing in the
 latest maven-artifact plug-in. Is there any other replacement for this
 functionality?


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

Re: How to get an instance of MavenProjectHelper in a Maven3.0 plugin?

[Stuart McCulloch]

On 9 Jul 2013, at 18:47, Richard Sand wrote:

 Ah, simple solutions... :-)
 
 Now I'm onto the next similar problem, getting a JarArchiver. I'm getting 1) 
 No implementation for org.codehaus.plexus.archiver.jar.JarArchiver was bound. 
 In the 2.0 plugin I'm attempting to migrate, it has the comment-style 
 annotation:
 
* @parameter 
 expression=${component.org.codehaus.plexus.archiver.Archiver#jar}

^ you want to use role = org.codehaus.plexus.archiver.Archiver.class, hint = 
jar

 I tried using just @Component as well as @Component(role = 
 org.codehaus.plexus.archiver.jar.JarArchiver.class)
 
 Any clues?
 
 Thanks again!
 
 Richard Sand | CEO
 IDF Connect, Inc. 
 2207 Concord Ave, #359
 Wilmington | Delaware 19803 | USA 
 Office: +1 302 425 0516 | Fax: +1 856 866 1899
 Mobile: +1 267 984 3651
 
 
 -Original Message-
 From: Mirko Friedenhagen [mailto:mfriedenha...@gmail.com] 
 Sent: Tuesday, July 09, 2013 12:33 PM
 To: Maven Users List
 Subject: Re: How to get an instance of MavenProjectHelper in a Maven3.0 
 plugin?
 
 Hello,
 
 I think @Component without a role is sufficient. Besides, I guess role should 
 be an interface and not the concrete class.
 DefaultMavenProjectHelper is the implementation of MavenProjectHelper :-).
 
 Regards Mirko
 --
 Sent from my mobile
 On Jul 9, 2013 6:18 PM, Richard Sand rs...@idfconnect.com wrote:
 
 Hi all -
 
 I'm trying to write a Maven 3.0 plugin and cannot figure out how to 
 get an instance of MavenProjectHelper.
 
 First, just taking a stab in the dark, I tried to get it the same way 
 I got MavenProject, e.g. as a parameter populated by Maven:
 
@Parameter(defaultValue=${projecthelper}, required = true, 
 readonly =
 true)
private MavenProjectHelper  mavenProjectHelper;
 
 That gave me the typical error message that the parameters 
 'mavenProjectHelper' are missing or invalid.
 
 I also tried values projectHelper and project.helper. Just stabs in 
 the dark.
 
 Next I tried using DefaultMavenProjectHelper as a component:
 
/**
 * The Maven project helper component
 *
 */
 
 @Component(role=org.apache.maven.project.DefaultMavenProjectHelper.class)
private MavenProjectHelper  mavenProjectHelper;
 
 But that gave me this error:
 
ERROR] 1) No implementation for
 org.apache.maven.project.DefaultMavenProjectHelper was bound.
 
 Any advice? Thanks!
 
 Richard Sand | CEO
 IDF Connect, Inc.
 2207 Concord Ave, #359
 Wilmington | Delaware 19803 | USA
 Office: +1 302 425 0516 | Fax: +1 856 866 1899
 Mobile: +1 267 984 3651
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Problems setting up a custom package type

[Stuart McCulloch]

On 3 Jul 2013, at 22:05, Mirko Friedenhagen wrote:

 Hello Robert,
 
 thanks for the quick answer, however I still get the same error :-(.

It looks like you have mismatched tags on line 27 of your components.xml:

   validateorg.apache.maven.plugins:maven-enforcer-plugin:enforce/package

 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/
 
 
 On Wed, Jul 3, 2013 at 10:50 PM, Robert Scholte rfscho...@apache.org wrote:
 Hi Mirko,
 
 you're missing an org.apache.maven.artifact.handler.ArtifactHandler, which
 you can find in [2]
 
 Robert
 
 Op Wed, 03 Jul 2013 22:46:04 +0200 schreef Mirko Friedenhagen
 mfriedenha...@gmail.com:
 
 Hello,
 
 I am playing with a custom package type[0], mainly to enforce
 execution of check goals.
 I read in the mvnref[1] and looked at some samples [2,3].
 
 Now every time I run my integration test[4], the build fails because
 the packaging type is not found.
 
 --- snip ---
 [DEBUG] Populating class realm
 extensionnet.oneandone.maven.plugins:foss-jar-maven-plugin:1.0-SNAPSHOT
 [DEBUG]   Included:
 net.oneandone.maven.plugins:foss-jar-maven-plugin:jar:1.0-SNAPSHOT
 [DEBUG]   Included: org.sonatype.sisu:sisu-inject-bean:jar:2.3.0
 [DEBUG]   Included: org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0
 [DEBUG]   Included: org.sonatype.aether:aether-util:jar:1.13.1
 [DEBUG]   Included: org.codehaus.plexus:plexus-interpolation:jar:1.14
 [DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:3.0.10
 [DEBUG]   Included:
 org.codehaus.plexus:plexus-component-annotations:jar:1.5.5
 [DEBUG]   Included: org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3
 [DEBUG]   Included: org.sonatype.plexus:plexus-cipher:jar:1.4
 [DEBUG]   Included:
 org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.2
 [DEBUG]   Included: com.google.guava:guava:jar:14.0.1
 [DEBUG] Extension realms for project
 
 net.oneandone.maven.plugins:foss-jar-maven-plugin-test-foss-jar:foss-jar:1.0-SNAPSHOT:
 
 [ClassRealm[extensionnet.oneandone.maven.plugins:foss-jar-maven-plugin:1.0-SNAPSHOT,
 parent: sun.misc.Launcher$AppClassLoader@2ed4a1d3]]
 [DEBUG] Created new class realm
 
 projectnet.oneandone.maven.plugins:foss-jar-maven-plugin-test-foss-jar:1.0-SNAPSHOT
 [DEBUG] Populating class realm
 
 projectnet.oneandone.maven.plugins:foss-jar-maven-plugin-test-foss-jar:1.0-SNAPSHOT
 [DEBUG] Looking up lifecyle mappings for packaging foss-jar from
 
 ClassRealm[projectnet.oneandone.maven.plugins:foss-jar-maven-plugin-test-foss-jar:1.0-SNAPSHOT,
 parent: ClassRealm[maven.api, parent: null]]
 [ERROR] The build could not read 1 project - [Help 1]
 org.apache.maven.project.ProjectBuildingException: Some problems were
 encountered while processing the POMs:
 [ERROR] Unknown packaging: foss-jar @ line 7, column 16
 
at
 org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:363)
at
 org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:636)
at
 org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:585)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:234)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 [ERROR]
 [ERROR]   The project
 
 net.oneandone.maven.plugins:foss-jar-maven-plugin-test-foss-jar:1.0-SNAPSHOT
 (/Users/mirko/workspace/foss/foss-jar/target/it/test-foss-jar/pom.xml)
 has 1 error
 [ERROR] Unknown packaging: foss-jar @ line 7, column 16
 [ERROR]
 [ERROR]
 [ERROR] For more information about the errors and possible solutions,
 please read the following articles:
 [ERROR] [Help 1]
 http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
 --- snap ---
 
 I do not understand what I am doing wrong here. Any hints welcome :-).
 
 Regards Mirko
 [0]
 https://github.com/mfriedenhagen/foss-jar-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xml
 [1]
 http://books.sonatype.com/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html#ex-override-lifecycle
 [2]
 

Re: URL Problem in Maven Apache Site

[Stuart McCulloch]

On 2 Jul 2013, at 11:52, Salva Vilarrasa wrote:

 Hello,
 My name is Salva and are preparing some slides to give a technical
 presentation on Maven 3 and while preparing the slides i wanted to
 introduce the changes from Maven 2 to Maven 3 and the compatibility issues
 people may encounter but the official page/link is not working:
 
 https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-profiles.xml
 
 Is there any other place where i can find this information, are u planning
 on updating that wiki page ?

https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-profiles.xml

 Thanks, any help would be appreciated.
 -- 
 Software Architect
 Salva Vilarrasa /


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

Re: Could not initialize class org.sonatype.guice.bean.reflect.Logs

[Stuart McCulloch]

I'm still unable to recreate this locally, even when using a project with
exactly the same layout/hierarchy as the one from that gist.

Does this happen when building from the command-line, or is there another
step involved? Such as building from an IDE or from CI?


On 30 May 2013 08:50, Simone Tripodi simonetrip...@apache.org wrote:

 Hi Stuart,

 thanks again for your kind feedbacks, much more than appreciated!

 
  Actually by guice-bean/plexus-* I meant guice-bean-* and guice-plexus-*
 (ie. the modules that eventually feed into sisu-inject-bean and
 sisu-inject-plexus respectively)
 
  I didn't see any guice-bean-* dependency when I took your POM (without
 parent) and ran it through dependency:tree so maybe the parent POM is
 affecting the dependencies.
 
  Any chance you could post the results of dependency:tree from your real
 project? (with internal details redacted of course)
 

 I just published another gist[1] with the result, I just masked the
 internal stuff with `acme` :P Many thanks in advance for having a look
 at it.

  I also took your POM and pasted it into a sample mojo project plus tests
 and was able to get it to work once I added a dependency to
 org.apache.maven:maven-compat (provides some legacy APIs used by the
 plugin test harness)
 
  Also note that the Aether API will change in Maven 3.1.0
 (org.sonatype.aether-org.eclipse.aether) so where possible it's better to
 stick to the standard Maven APIs, otherwise you have to be prepared to
 handle the upcoming package change.
 

 Thanks for the advice, will take it in consideration!
 All the best, have a nice day,
 -Simo

 [1] https://gist.github.com/simonetripodi/5676291

 http://people.apache.org/~simonetripodi/
 http://twitter.com/simonetripodi

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




-- 
Cheers, Stuart

Re: Is the maven repo damaged?

[Stuart McCulloch]

On 31 May 2013, at 22:04, Loyall, David wrote:

 Hello.
 
 My maven installation has had some trouble downloading artifacts today.
 
 
 hobbes@metalbaby:~/scratch$ mvn 
 org.apache.maven.plugins:maven-dependency-plugin:2.8:get 
 -Dartifact=org.springsource:spring-jdbc:3.2.3.RELEASE
 [INFO] Scanning for projects...
 [INFO]
 [INFO] 
 
 [INFO] Building Maven Stub Project (No POM) 1
 [INFO] 
 
 [INFO]
 [INFO] --- maven-dependency-plugin:2.8:get (default-cli) @ standalone-pom ---
 [INFO] Resolving org.springsource:spring-jdbc:jar:3.2.3.RELEASE with 
 transitive dependencies
 Downloading: 
 http://repo.maven.apache.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.pom
 [WARNING] Missing POM for org.springsource:spring-jdbc:jar:3.2.3.RELEASE
 Downloading: 
 http://repo.maven.apache.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.jar
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 4.374s
 [INFO] Finished at: Fri May 31 15:54:12 CDT 2013
 [INFO] Final Memory: 8M/106M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-dependency-plugin:2.8:get (default-cli) on 
 project standalone-pom: Couldn't download artifact: Missing:
 [ERROR] --
 [ERROR] 1) org.springsource:spring-jdbc:jar:3.2.3.RELEASE
 [ERROR]
 [ERROR] Try downloading the file manually from the project website.
 [ERROR]
 [ERROR] Then, install it using the command:
 [ERROR] mvn install:install-file -DgroupId=org.springsource 
 -DartifactId=spring-jdbc -Dversion=3.2.3.RELEASE -Dpackaging=jar 
 -Dfile=/path/to/file
 [ERROR]
 [ERROR] Alternatively, if you host your own repository you can deploy the 
 file there:
 [ERROR] mvn deploy:deploy-file -DgroupId=org.springsource 
 -DartifactId=spring-jdbc -Dversion=3.2.3.RELEASE -Dpackaging=jar 
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
 [ERROR]
 [ERROR] Path to dependency:
 [ERROR] 1) org.apache.maven.plugins:maven-downloader-plugin:jar:1.0
 [ERROR] 2) org.springsource:spring-jdbc:jar:3.2.3.RELEASE
 [ERROR]
 [ERROR] --
 [ERROR] 1 required artifact is missing.
 [ERROR]
 [ERROR] for artifact:
 [ERROR] org.apache.maven.plugins:maven-downloader-plugin:jar:1.0
 [ERROR]
 [ERROR] from the specified remote repositories:
 [ERROR] central (http://repo.maven.apache.org/maven2, releases=true, 
 snapshots=false)
 [ERROR] - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
 switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]
 [ERROR] For more information about the errors and possible solutions, please 
 read the following articles:
 [ERROR] [Help 1] 
 http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
 
 I did some troubleshooting and determined that the problem is that the 
 artifacts aren't on the repo in the place where mvn is looking for them.
 
 http://repo.maven.apache.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.pom
 == 404
 
 I checked some other locations, too:
 http://repo2.maven.apache.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.pom
 == 404
 http://central.maven.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.pom
 == 404
 
 If it doesn't exist, fine, but, why does this say that the file should be in 
 those location?
 http://search.maven.org/#artifactdetails%7Corg.springframework%7Cspring-jdbc%7C3.2.3.RELEASE%7Cjar
 
 Am I reading that correctly?

The search results say it's under org.springframework... whereas you appear 
to be looking under org.springsource...

  Is it true that I should find org.springsource:spring-jdbc:3.2.3.RELEASE at 
 one of those URLs that is 404?  Or at least find it with my mvn client?
 
 These search results and direct url are the same as above, except the 
 latter works!
 http://search.maven.org/#artifactdetails%7Clog4j%7Clog4j%7C1.2.17%7Cbundle
 http://repo2.maven.apache.org/maven2/log4j/log4j/1.2.17/log4j-1.2.17.pom
 
 I hope this helps,
 --Dave
 


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

Re: Is the maven repo damaged?

[Stuart McCulloch]

Spring artifacts are deployed under a groupId of org.springframework, not 
org.springsource:

http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.springframework%22

On 31 May 2013, at 22:17, Richard Vowles wrote:

 It does appear dead,
 
 http://repo1.maven.org/maven2/org/springsource/
 
 gives a 404
 
 Do you not have your own Nexus to protect yourself from this?
 On Jun 1, 2013 9:12 AM, Loyall, David david.loy...@nebraska.gov wrote:
 
 Hello.
 
 My maven installation has had some trouble downloading artifacts today.
 
 
 hobbes@metalbaby:~/scratch$ mvn
 org.apache.maven.plugins:maven-dependency-plugin:2.8:get
 -Dartifact=org.springsource:spring-jdbc:3.2.3.RELEASE
 [INFO] Scanning for projects...
 [INFO]
 [INFO]
 
 [INFO] Building Maven Stub Project (No POM) 1
 [INFO]
 
 [INFO]
 [INFO] --- maven-dependency-plugin:2.8:get (default-cli) @ standalone-pom
 ---
 [INFO] Resolving org.springsource:spring-jdbc:jar:3.2.3.RELEASE with
 transitive dependencies
 Downloading:
 http://repo.maven.apache.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.pom
 [WARNING] Missing POM for org.springsource:spring-jdbc:jar:3.2.3.RELEASE
 Downloading:
 http://repo.maven.apache.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.jar
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 4.374s
 [INFO] Finished at: Fri May 31 15:54:12 CDT 2013
 [INFO] Final Memory: 8M/106M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-dependency-plugin:2.8:get (default-cli) on
 project standalone-pom: Couldn't download artifact: Missing:
 [ERROR] --
 [ERROR] 1) org.springsource:spring-jdbc:jar:3.2.3.RELEASE
 [ERROR]
 [ERROR] Try downloading the file manually from the project website.
 [ERROR]
 [ERROR] Then, install it using the command:
 [ERROR] mvn install:install-file -DgroupId=org.springsource
 -DartifactId=spring-jdbc -Dversion=3.2.3.RELEASE -Dpackaging=jar
 -Dfile=/path/to/file
 [ERROR]
 [ERROR] Alternatively, if you host your own repository you can deploy the
 file there:
 [ERROR] mvn deploy:deploy-file -DgroupId=org.springsource
 -DartifactId=spring-jdbc -Dversion=3.2.3.RELEASE -Dpackaging=jar
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
 [ERROR]
 [ERROR] Path to dependency:
 [ERROR] 1) org.apache.maven.plugins:maven-downloader-plugin:jar:1.0
 [ERROR] 2) org.springsource:spring-jdbc:jar:3.2.3.RELEASE
 [ERROR]
 [ERROR] --
 [ERROR] 1 required artifact is missing.
 [ERROR]
 [ERROR] for artifact:
 [ERROR] org.apache.maven.plugins:maven-downloader-plugin:jar:1.0
 [ERROR]
 [ERROR] from the specified remote repositories:
 [ERROR] central (http://repo.maven.apache.org/maven2, releases=true,
 snapshots=false)
 [ERROR] - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with the
 -e switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]
 [ERROR] For more information about the errors and possible solutions,
 please read the following articles:
 [ERROR] [Help 1]
 http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
 
 
 I did some troubleshooting and determined that the problem is that the
 artifacts aren't on the repo in the place where mvn is looking for them.
 
 
 http://repo.maven.apache.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.pom
 == 404
 
 I checked some other locations, too:
 
 http://repo2.maven.apache.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.pom
 == 404
 
 http://central.maven.org/maven2/org/springsource/spring-jdbc/3.2.3.RELEASE/spring-jdbc-3.2.3.RELEASE.pom
 == 404
 
 If it doesn't exist, fine, but, why does this say that the file should be
 in those location?
 
 http://search.maven.org/#artifactdetails%7Corg.springframework%7Cspring-jdbc%7C3.2.3.RELEASE%7Cjar
 
 Am I reading that correctly?  Is it true that I should find
 org.springsource:spring-jdbc:3.2.3.RELEASE at one of those URLs that is
 404?  Or at least find it with my mvn client?
 
 These search results and direct url are the same as above, except the
 latter works!
 http://search.maven.org/#artifactdetails%7Clog4j%7Clog4j%7C1.2.17%7Cbundle
 http://repo2.maven.apache.org/maven2/log4j/log4j/1.2.17/log4j-1.2.17.pom
 
 I hope this helps,
 --Dave
 
 


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

Re: Could not initialize class org.sonatype.guice.bean.reflect.Logs

[Stuart McCulloch]

On 29 May 2013, at 10:49, Simone Tripodi wrote:

 Hi all mates,
 
 I am updating a set of old Maven plugins using Mvn3+Aether APIs, but
 unfortunately I am no longer able to run Mvn tests due to
 org.sonatype.guice.bean.reflect.Logs class cannot be found in the
 classpath, follows below the (almost) complete stacktrace (what is
 missing is just the test class - it is not an OSS project).
 
 All guice-bean* dependencies are included in the project, included the
 guice-bean-reflect-2.3.0 that contains the missing class.
 
 Do you know why I get that error?

Maven3 never exposed those packages from the core and the individual 
guice-bean/plexus-* jars were never used in Maven3, only the final 
sisu-inject-bean/plexus aggregate jars.

If you've added your own dependencies to guice-bean/plexus-* jars then this is 
likely the cause of the conflict because they'll be implementing the same API 
as the aggregate jars.

Do you have a link to your test project? If you remove all guice-bean/plexus-* 
dependencies then you'll probably find it works.

In Eclipse/Sisu I've collapsed these interim jars because while they could 
technically be re-used individually it was actually simpler (and smaller) to 
keep them in the same bundle. 

 Any hint would be much more than appreciated!
 Many thanks in advance, all the best!
 -Simo
 
 java.lang.NoClassDefFoundError: Could not initialize class
 org.sonatype.guice.bean.reflect.Logs
   at 
 org.sonatype.guice.plexus.scanners.PlexusTypeRegistry.loadRole(PlexusTypeRegistry.java:194)
   at 
 org.sonatype.guice.plexus.scanners.PlexusTypeRegistry.addComponent(PlexusTypeRegistry.java:110)
   at 
 org.sonatype.guice.plexus.scanners.PlexusXmlScanner.parseComponent(PlexusXmlScanner.java:329)
   at 
 org.sonatype.guice.plexus.scanners.PlexusXmlScanner.parseComponentsXml(PlexusXmlScanner.java:198)
   at 
 org.sonatype.guice.plexus.scanners.PlexusXmlScanner.scan(PlexusXmlScanner.java:94)
   at 
 org.sonatype.guice.plexus.binders.PlexusXmlBeanModule.configure(PlexusXmlBeanModule.java:89)
   at 
 org.sonatype.guice.plexus.binders.PlexusBindingModule.configure(PlexusBindingModule.java:62)
   at 
 com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:229)
   at com.google.inject.spi.Elements.getElements(Elements.java:103)
   at com.google.inject.spi.Elements.getElements(Elements.java:80)
   at 
 org.sonatype.guice.bean.binders.MergedModule.configure(MergedModule.java:54)
   at 
 com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:229)
   at com.google.inject.spi.Elements.getElements(Elements.java:103)
   at 
 com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:136)
   at 
 com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
   at com.google.inject.Guice.createInjector(Guice.java:94)
   at com.google.inject.Guice.createInjector(Guice.java:71)
   at com.google.inject.Guice.createInjector(Guice.java:61)
   at 
 org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:470)
   at 
 org.codehaus.plexus.DefaultPlexusContainer.init(DefaultPlexusContainer.java:196)
   at 
 org.codehaus.plexus.DefaultPlexusContainer.init(DefaultPlexusContainer.java:160)
   at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.setupContainer(AbstractMojoTestCase.java:159)
   at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.getContainer(AbstractMojoTestCase.java:179)
   at 
 org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:107)
 
 http://people.apache.org/~simonetripodi/
 http://twitter.com/simonetripodi
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Could not initialize class org.sonatype.guice.bean.reflect.Logs

[Stuart McCulloch]

On 29 May 2013, at 14:33, Simone Tripodi wrote:

 Hi Stuart! :)
 
 thanks a lot for jumping in the discussion, very appreciated! :)
 
 
 Maven3 never exposed those packages from the core and the individual 
 guice-bean/plexus-* jars were never used in Maven3, only the final 
 sisu-inject-bean/plexus aggregate jars.
 If you've added your own dependencies to guice-bean/plexus-* jars then this 
 is likely the cause of the conflict because they'll be implementing the same 
 API as the aggregate jars.
 
 Nope I didn't add any guice-bean* dependency manually, they are all
 inherited by maven-core as transitive dependencies. The only plexus-*
 dependency I added is org.codehaus.plexus:plexus-utils:3.0.1

Actually by guice-bean/plexus-* I meant guice-bean-* and guice-plexus-* (ie. 
the modules that eventually feed into sisu-inject-bean and sisu-inject-plexus 
respectively)

 Do you have a link to your test project? If you remove all 
 guice-bean/plexus-* dependencies then you'll probably find it works.
 
 Nope, unfortunately, it is not an OSS project :( I hope that the
 POM[1] only can help you to understand where the mistake is...

I didn't see any guice-bean-* dependency when I took your POM (without parent) 
and ran it through dependency:tree so maybe the parent POM is affecting the 
dependencies.

Any chance you could post the results of dependency:tree from your real 
project? (with internal details redacted of course)

I also took your POM and pasted it into a sample mojo project plus tests and 
was able to get it to work once I added a dependency to 
org.apache.maven:maven-compat (provides some legacy APIs used by the plugin 
test harness) 

Also note that the Aether API will change in Maven 3.1.0 
(org.sonatype.aether-org.eclipse.aether) so where possible it's better to 
stick to the standard Maven APIs, otherwise you have to be prepared to handle 
the upcoming package change.

 In Eclipse/Sisu I've collapsed these interim jars because while they could 
 technically be re-used individually it was actually simpler (and smaller) to 
 keep them in the same bundle.
 
 I am maybe off-topic here, but what do you think about the approach we
 adopted in Onami, where we distribute small modules AND the collapsed
 jar?

It works, but for Sisu everyone just wants the aggregate jar so it wasn't worth 
the effort of maintaining the separate modules (and some people found the extra 
choice confusing).

 Many thanks for your help and have a nice day!
 All the best,
 -Simo
 
 [1] https://gist.github.com/simonetripodi/5670183
 
 http://people.apache.org/~simonetripodi/
 http://twitter.com/simonetripodi
 
 
 On Wed, May 29, 2013 at 12:05 PM, Stuart McCulloch mccu...@gmail.com wrote:
 On 29 May 2013, at 10:49, Simone Tripodi wrote:
 
 Hi all mates,
 
 I am updating a set of old Maven plugins using Mvn3+Aether APIs, but
 unfortunately I am no longer able to run Mvn tests due to
 org.sonatype.guice.bean.reflect.Logs class cannot be found in the
 classpath, follows below the (almost) complete stacktrace (what is
 missing is just the test class - it is not an OSS project).
 
 All guice-bean* dependencies are included in the project, included the
 guice-bean-reflect-2.3.0 that contains the missing class.
 
 Do you know why I get that error?
 
 Maven3 never exposed those packages from the core and the individual 
 guice-bean/plexus-* jars were never used in Maven3, only the final 
 sisu-inject-bean/plexus aggregate jars.
 
 If you've added your own dependencies to guice-bean/plexus-* jars then this 
 is likely the cause of the conflict because they'll be implementing the same 
 API as the aggregate jars.
 
 Do you have a link to your test project? If you remove all 
 guice-bean/plexus-* dependencies then you'll probably find it works.
 
 In Eclipse/Sisu I've collapsed these interim jars because while they could 
 technically be re-used individually it was actually simpler (and smaller) to 
 keep them in the same bundle.
 
 Any hint would be much more than appreciated!
 Many thanks in advance, all the best!
 -Simo
 
 java.lang.NoClassDefFoundError: Could not initialize class
 org.sonatype.guice.bean.reflect.Logs
  at 
 org.sonatype.guice.plexus.scanners.PlexusTypeRegistry.loadRole(PlexusTypeRegistry.java:194)
  at 
 org.sonatype.guice.plexus.scanners.PlexusTypeRegistry.addComponent(PlexusTypeRegistry.java:110)
  at 
 org.sonatype.guice.plexus.scanners.PlexusXmlScanner.parseComponent(PlexusXmlScanner.java:329)
  at 
 org.sonatype.guice.plexus.scanners.PlexusXmlScanner.parseComponentsXml(PlexusXmlScanner.java:198)
  at 
 org.sonatype.guice.plexus.scanners.PlexusXmlScanner.scan(PlexusXmlScanner.java:94)
  at 
 org.sonatype.guice.plexus.binders.PlexusXmlBeanModule.configure(PlexusXmlBeanModule.java:89)
  at 
 org.sonatype.guice.plexus.binders.PlexusBindingModule.configure(PlexusBindingModule.java:62)
  at 
 com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:229

Re: Maven Exception. Possibly maven repository broken: No implementation for org.codehaus.plexus.logging.Logger was bound

[Stuart McCulloch]

Have you tried restarting the affected slave? The remote class cache might be 
holding onto an old/broken class.

On 12 Apr 2013, at 08:31, Johannes Pfeifer wrote:

 Hello Maven users,
  
 We use Maven and Jenkins to build our java products. Our builds broke the 
 maven repositories yesterday, when the maven version changed from one build 
 to another. This was an unknown error of one change that was made to build 
 server (and will never be made again).
 In one build the maven version is 3.0.4 and in the next build the maven 
 version 3.0-beta-2 was used. Since then our build maven repository seems to 
 be broken, throwing the exception listed below.
 How can we fix this?
 We tried clearing the repository by:
 1) Re-running the project with maven 3.0.4
 2) Removing repository: rm -rfv ~jenkins/.m2/repository
 3) Clearing the jenkins workspace: rm -rfv ./*
 4) Clearing repository through mojo in pom.xml
 ...
 executions
 execution
 idremove-old-artifacts/id
 phasepackage/phase
 goals
 goalremove-project-artifact/goal
 /goals
 configuration
 removeAlltrue/removeAll
 /configuration
 /execution
 /executions
 ...
  
 Unfortunatly this did not help and we are still getting this exception:
 [ERROR] Internal error: com.google.inject.ProvisionException: Guice provision 
 errors:
 1) Error injecting: 
 org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant
 at ClassRealm[extensionorg.eclipse.tycho:tycho-maven-plugin:0.17.0, parent: 
 ClassRealm[maven.api, parent: null]]
 at ClassRealm[extensionorg.eclipse.tycho:tycho-maven-plugin:0.17.0, parent: 
 ClassRealm[maven.api, parent: null]]
 while locating org.apache.maven.AbstractMavenLifecycleParticipant annotated 
 with @com.google.inject.name.Named(value=TychoMavenLifecycleListener)
 1 error: Guice provision errors:
 1) Error injecting: 
 org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver
 at ClassRealm[extensionorg.eclipse.tycho:tycho-maven-plugin:0.17.0, parent: 
 ClassRealm[maven.api, parent: null]]
 at ClassRealm[extensionorg.eclipse.tycho:tycho-maven-plugin:0.17.0, parent: 
 ClassRealm[maven.api, parent: null]]
 while locating org.eclipse.tycho.resolver.TychoDependencyResolver
 while locating org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant
 1 error: Guice provision errors:
 1) No implementation for org.codehaus.plexus.logging.Logger was bound.
 while locating org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver
 1 error
 - [Help 1]
 org.apache.maven.InternalErrorException: Internal error: 
 com.google.inject.ProvisionException: Guice provision errors:
 1) Error injecting: 
 org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant
 at ClassRealm[extensionorg.eclipse.tycho:tycho-maven-plugin:0.17.0, parent: 
 ClassRealm[maven.api, parent: null]]
 at ClassRealm[extensionorg.eclipse.tycho:tycho-maven-plugin:0.17.0, parent: 
 ClassRealm[maven.api, parent: null]]
 while locating org.apache.maven.AbstractMavenLifecycleParticipant annotated 
 with @com.google.inject.name.Named(value=TychoMavenLifecycleListener)
 1 error
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:164)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
 at java.lang.reflect.Method.invoke(Method.java:611)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: com.google.inject.ProvisionException: Guice provision errors:
 1) Error injecting: 
 org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant
 at ClassRealm[extensionorg.eclipse.tycho:tycho-maven-plugin:0.17.0, parent: 
 ClassRealm[maven.api, parent: null]]
 at ClassRealm[extensionorg.eclipse.tycho:tycho-maven-plugin:0.17.0, parent: 
 ClassRealm[maven.api, parent: null]]
 while locating org.apache.maven.AbstractMavenLifecycleParticipant annotated 
 with @com.google.inject.name.Named(value=TychoMavenLifecycleListener)
 1 error
 at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:952)
 at 
 org.sonatype.guice.bean.locators.QualifiedBean.getValue(QualifiedBean.java:85)
 at 
 org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:55)
 at 
 org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:129)
 at java.util.AbstractCollection.addAll(AbstractCollection.java:92)
 at 
 org.apache.maven.DefaultMaven.getLifecycleParticipants(DefaultMaven.java:539)
 at 

Re: No mojo definitions were found for plugin

[Stuart McCulloch]

On 8 Mar 2013, at 16:54, Thomas Koch wrote:

 Thomas Koch:
 [DEBUG] Using 0 mojo extractors.
 
 I could track down the problem. The field mojoDescriptorExtractors in  the 
 DefaultMojoScanner class is not filed by plexus with the available extractors 
 although they should be available on the classpath.
 
 Now I don't know how to debug this issue. Why doesn't plexus find those 
 extractors?

Perhaps you could post a link to your re-packaging build so people can recreate 
the issue? There's not enough information here to debug the problem remotely.

 Thomas Koch, http://www.koch.ro
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: No mojo definitions were found for plugin

[Stuart McCulloch]

On 11 Mar 2013, at 21:28, Thomas Koch wrote:

 Stuart McCulloch:
 Perhaps you could post a link to your re-packaging build so people can
 recreate the issue? There's not enough information here to debug the
 problem remotely.
 
 http://anonscm.debian.org/gitweb/?p=pkg-java/maven-plugin-
 tools.git;a=tree;hb=refs/heads/update_to_3.2
 
 The build works as follow:
 
 - build all modules without maven, with some debian specific ant magic

Unfortunately I don't have a debian system to hand - and despite spending this 
evening unpacking various deb files I'm unable to get enough of this 'magic' to 
work to recreate the issue. Far too many hard-coded references to 
/usr/share/java/... in various build files, including some patched class 
files. If you could provide a tarball of all the packages needed to build so 
that I could just unpack locally on a non-debian system (without requiring it 
to be located under /usr) and invoke a few commands to recreate the issue 
then that would help immensely.

Since you presumably have a working build for 2.8, I suggest you compare the 
differences to check what has changed and what might affect the results. Plexus 
components are found by scanning the runtime classpath for 
META-INF/plexus/components.xml files, so make sure that you have the various 
extractor jars on your classpath and those jars have 
META-INF/plexus/components.xml files that describe their extractors. Also 
unpack and compare the contents of your patched jars with the ones from Maven 
which work.

 - call maven-plugin-plugin on itself, see debian/build.xml, target package
 
 The last step fails. It would already help me a lot if you could give me a 
 hint how I could get some debug logging from plexus to see why it doesn't 
 pick 
 up the available extractor classes.
 
 Regards,
 
 Thomas Koch, http://www.koch.ro


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

Re: Possible PluginManager interaction with Guice bug

[Stuart McCulloch]

On 31 January 2013 21:29, Martin Gainty mgai...@hotmail.com wrote:


 Gentlemen
 I found a consistent bug with PluginManager not able to locate @goal/** *
 artifactId=modello-maven-plugin
  * @author a href=mailto:tryg...@inamo.no;Trygve Laugstøl/a
  * @version 1.5
  * @threadSafe
  */
 public abstract class AbstractModelloGeneratorMojo extends AbstractMojo
 notice the lack of @goal .. because this is an abstract class which is
 expected to be extend'ed by a concrete
 the PluginManager backtraces classes to find who is extending AbstractMojo
 and correctly identifies
 org.codehaus.modello.maven.AbstractModelloGeneratorMojo
 org.apache.maven.plugin.MojoExecutionException: Error generating: No such
 plugin: java
  at
 org.codehaus.modello.maven.AbstractModelloGeneratorMojo.doExecute(AbstractModelloGeneratorMojo.java:324)

 abstract class AbstractModelloGeneratorMojo has no @goal .. pluginManager
 will always throw MojoExecutionException

 solution is to have the concrete class which contains annotated @goal
 extend AbstractMojo
 /*** Echos an object string to the output screen.
  * @goal java
  * @requiresProject false
 @Mojo(name java)
 */
 public class ModelloJavaMojo extends AbstractMojo implements
 org.codehaus.modello.core.ModelloCore
 { public void execute()
 }

 if I run mvn dependency:tree i can see the guice injector the
 modello-maven-plugin is expecting
 [DEBUG] org.codehaus.modello:modello-maven-plugin:maven-plugin:1.1
 [DEBUG]com.google.inject:guice:jar:2.0:compile

 maven-core implements guice as well
 [DEBUG]org.apache.maven:maven-core:jar:3.0.2:compile
 [DEBUG]   org.sonatype.sisu:sisu-guice:jar:2.9.1:compile

 the options seem to be
 1)disable guice and replace with plexus..if you find a way please let me
 know
 2)refactor all concrete classes which already implement @goal to extend
 AbstractMojo so PluginManager will
 find the Mojo which contains the expected goal from plugin.xml

 Thoughts?


Don't see how this relates to guice, seems more likely to be something to
do with the build-time generation of the plugin.xml. Suggest you create an
issue on http://jira.codehaus.org/browse/MPLUGIN and attach your test
project. Also I don't see anywhere in the PluginManager implementation
where it backtraces classes to find who is extending AbstractMojo,
instead it looks up the implementation indirectly via the MojoDescriptor
that's populated from the plugin.xml.

-- 
Cheers, Stuart


 Martin Gainty

Re: Possible PluginManager interaction with Guice bug

[Stuart McCulloch]

On 1 February 2013 12:04, Martin Gainty mgai...@hotmail.com wrote:


 Stuart
 Yes i agree that the PluginManager *should* be discovering the implementor
 at mojo implementation for Java class but instead pulls in
 AbstractModelloGeneratorMojo which extends AbstractMojo


Remember to attach your test project that demonstrates the actual problem.


 Jira entry

 http://jira.codehaus.org/browse/MPLUGIN-240?focusedCommentId=318476#comment-318476
 Thanks,
 Martin Gainty
 __
 Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

 Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
 Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
 Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
 dient lediglich dem Austausch von Informationen und entfaltet keine
 rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
 E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
 Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
 destinataire prévu, nous te demandons avec bonté que pour satisfaire
 informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
 de ceci est interdite. Ce message sert à l'information seulement et n'aura
 pas n'importe quel effet légalement obligatoire. Étant donné que les email
 peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
 aucune responsabilité pour le contenu fourni.

   Date: Fri, 1 Feb 2013 11:12:54 +
  Subject: Re: Possible PluginManager interaction with Guice bug
  From: mccu...@gmail.com
  To: users@maven.apache.org
 
  On 31 January 2013 21:29, Martin Gainty mgai...@hotmail.com wrote:
 
  
   Gentlemen
   I found a consistent bug with PluginManager not able to locate
 @goal/** *
   artifactId=modello-maven-plugin
* @author a href=mailto:tryg...@inamo.no;Trygve Laugstøl/a
* @version 1.5
* @threadSafe
*/
   public abstract class AbstractModelloGeneratorMojo extends AbstractMojo
   notice the lack of @goal .. because this is an abstract class which is
   expected to be extend'ed by a concrete
   the PluginManager backtraces classes to find who is extending
 AbstractMojo
   and correctly identifies
   org.codehaus.modello.maven.AbstractModelloGeneratorMojo
   org.apache.maven.plugin.MojoExecutionException: Error generating: No
 such
   plugin: java
at
  
 org.codehaus.modello.maven.AbstractModelloGeneratorMojo.doExecute(AbstractModelloGeneratorMojo.java:324)
  
   abstract class AbstractModelloGeneratorMojo has no @goal ..
 pluginManager
   will always throw MojoExecutionException
  
   solution is to have the concrete class which contains annotated @goal
   extend AbstractMojo
   /*** Echos an object string to the output screen.
* @goal java
* @requiresProject false
   @Mojo(name java)
   */
   public class ModelloJavaMojo extends AbstractMojo implements
   org.codehaus.modello.core.ModelloCore
   { public void execute()
   }
  
   if I run mvn dependency:tree i can see the guice injector the
   modello-maven-plugin is expecting
   [DEBUG] org.codehaus.modello:modello-maven-plugin:maven-plugin:1.1
   [DEBUG]com.google.inject:guice:jar:2.0:compile
  
   maven-core implements guice as well
   [DEBUG]org.apache.maven:maven-core:jar:3.0.2:compile
   [DEBUG]   org.sonatype.sisu:sisu-guice:jar:2.9.1:compile
  
   the options seem to be
   1)disable guice and replace with plexus..if you find a way please let
 me
   know
   2)refactor all concrete classes which already implement @goal to extend
   AbstractMojo so PluginManager will
   find the Mojo which contains the expected goal from plugin.xml
  
   Thoughts?
  
 
  Don't see how this relates to guice, seems more likely to be something to
  do with the build-time generation of the plugin.xml. Suggest you create
 an
  issue on http://jira.codehaus.org/browse/MPLUGIN and attach your test
  project. Also I don't see anywhere in the PluginManager implementation
  where it backtraces classes to find who is extending AbstractMojo,
  instead it looks up the implementation indirectly via the MojoDescriptor
  that's populated from the plugin.xml.
 
  --
  Cheers, Stuart
 
 
   Martin Gainty
  





-- 
Cheers, Stuart

Re: mvn build 3.1-snapshot failes when building core

[Stuart McCulloch]

On 5 Nov 2012, at 09:30, Stadelmann Josef wrote:

 my svn trunk update has 
 Completed: At revision: 1405720  
 
 using maven 3.0.5-snapshot to build maven 3.1-snapshot

Any particular reason why you're using one unreleased snapshot to build a 
different snapshot?

 it always fails when building the CORE
 
 any ideas welcome ! or shall I file a JIRA ?

The buildnumber plugin failed because it couldn't find the 
org/tmatesoft/svn/core/SVNException class, but that class should be in 
svnkit-1.3.5.jar (which is on the plugin's classpath)

Check 
E:/Users/C770817/.m2/repository/org/tmatesoft/svnkit/svnkit/1.3.5/svnkit-1.3.5.jar
 to see if it's actually a valid jar file and has this class - you might have a 
corrupt download.

If it is corrupted, delete that jar file and retry the build.

 Josef
 
 
 cd E:\asf\maven\maven-3\trunk; JAVA_HOME=C:\\Program
 Files\\Java\\jdk1.6.0_30
 M2_HOME=E:\\Users\\C770817\\SW-UMGEBUNG\\apache-maven-3.0.5
 E:\\Users\\C770817\\SW-UMGEBUNG\\apache-maven-3.0.5\\bin\\mvn.bat clean
 install
 Scanning for projects...
 
 Reactor Build Order:
 
 Apache Maven
 Maven Model
 Maven Artifact
 Maven Plugin API
 Maven Model Builder
 Maven Settings
 Maven Settings Builder
 Maven Repository Metadata Model
 Maven Aether Provider
 Maven Core
 Maven Compat
 Maven Embedder
 Maven Distribution
 
 
 Building Apache Maven 3.1-SNAPSHOT
 
 
 [clean:clean]
 Deleting E:\asf\maven\maven-3\trunk\target
 
 [remote-resources:process]
 
 [animal-sniffer:check]
 Checking unresolved references to org.codehaus.mojo.signature:java15:1.0
 
 [site:attach-descriptor]
 
 [install:install]
 Installing E:\asf\maven\maven-3\trunk\pom.xml to
 E:\Users\C770817\.m2\repository\org\apache\maven\maven\3.1-SNAPSHOT\mave
 n-3.1-SNAPSHOT.pom
 Installing E:\asf\maven\maven-3\trunk\target\maven-3.1-SNAPSHOT-site.xml
 to
 E:\Users\C770817\.m2\repository\org\apache\maven\maven\3.1-SNAPSHOT\mave
 n-3.1-SNAPSHOT-site.xml
 
 
 Building Maven Model 3.1-SNAPSHOT
 
 
 [clean:clean]
 Deleting E:\asf\maven\maven-3\trunk\maven-model\target
 
 [modello:java]
 outputDirectory:
 E:\asf\maven\maven-3\trunk\maven-model\target\generated-sources\modello
 Working on model: src/main/mdo/maven.mdo
 Generating current version: 4.0.0
 
 [modello:xpp3-reader]
 outputDirectory:
 E:\asf\maven\maven-3\trunk\maven-model\target\generated-sources\modello
 Working on model: src/main/mdo/maven.mdo
 Generating current version: 4.0.0
 
 [modello:xpp3-extended-reader]
 outputDirectory:
 E:\asf\maven\maven-3\trunk\maven-model\target\generated-sources\modello
 Working on model: src/main/mdo/maven.mdo
 Generating current version: 4.0.0
 
 [modello:xpp3-writer]
 outputDirectory:
 E:\asf\maven\maven-3\trunk\maven-model\target\generated-sources\modello
 Working on model: src/main/mdo/maven.mdo
 Generating current version: 4.0.0
 
 [remote-resources:process]
 
 [resources:resources]
 [debug] execute contextualize
 Using 'UTF-8' encoding to copy filtered resources.
 skip non existing resourceDirectory
 E:\asf\maven\maven-3\trunk\maven-model\src\main\resources
 Copying 3 resources
 
 [compiler:compile]
 Compiling 50 source files to
 E:\asf\maven\maven-3\trunk\maven-model\target\classes
 
 [animal-sniffer:check]
 Checking unresolved references to org.codehaus.mojo.signature:java15:1.0
 
 [resources:testResources]
 [debug] execute contextualize
 Using 'UTF-8' encoding to copy filtered resources.
 skip non existing resourceDirectory
 E:\asf\maven\maven-3\trunk\maven-model\src\test\resources
 Copying 3 resources
 
 [compiler:testCompile]
 Compiling 37 source files to
 E:\asf\maven\maven-3\trunk\maven-model\target\test-classes
 
 [surefire:test]
 Surefire report directory:
 E:\asf\maven\maven-3\trunk\maven-model\target\surefire-reports
 
 ---
 T E S T S
 ---
 Running org.apache.maven.model.ActivationFileTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016
 sec
 Running org.apache.maven.model.ActivationOSTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015
 sec
 Running org.apache.maven.model.ActivationPropertyTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
 Running org.apache.maven.model.ActivationTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
 Running org.apache.maven.model.BuildTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
 Running org.apache.maven.model.CiManagementTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
 Running org.apache.maven.model.ContributorTest
 

Re: [maven-3/trunk] bootstrap-build failing

[Stuart McCulloch]

On 1 November 2012 10:29, Stadelmann Josef 
josef.stadelm...@axa-winterthur.ch wrote:

 How can I cure best the problems shown below? it occurs during a
 bootstrap-build of maven-3/trunk on my Vista System.
 (see red lines, which are of interesst to me).

 I have successfully build from sources SLF4J é all. Where does this
 bootstrap-build.xml expect this files now?
 where do I have to copy the SLF4J-*.jars and maybe others to make the
 maven-3/trunk build.xml (bootstrap-build) happy?


SLF4J should be downloaded by the [artifact:dependencies] task, just like
all the other bootstrap dependencies - you shouldn't need to build it
yourself.

Has the final error shown below, (which makes the bootstrap-build fail?) to
 do with the absence of SLF4J-*.jar's or what does it indicate?


The SLF4J messages about 'Failed to load class' and 'Defaulting to
no-operation' are informational and should not fail the build. It means
that it couldn't find a backend implementation (the current build does not
specify a particular backend on purpose) so it's telling you about this in
case you had meant to choose a backend but forgot:
http://www.slf4j.org/codes.html#StaticLoggerBinder

The final error just says that Java returned 1 on exit, but doesn't say why
- you could try running ant -d -f build.xml to see if that gives more
information about the failure at the end.

FWIW, I just tried the bootstrap build on a clean system (OSX,
Java 1.6.0_37, Ant 1.8.4) and it built without errors - note that I still
saw the SLF4J messages, but those are expected at the moment

This on a Windows Vista System
 Josef

 ant -f E:\\asf\\maven\\maven-3\\trunk all
 clean-bootstrap:
 initTaskDefs:
 Building Apache Maven ...
 isMavenHomeSet:
 init:
 maven.home = E:\Users\C770817\SW-UMGEBUNG\apache-maven-3.1
 maven.repo.local = /E:/Users/C770817/.m2/repository
 distributionId = apache-maven
 distributionName = Apache Maven
 distributionDirectory = apache-maven
 prompt-maven-home-exists:
 pull:
 Copying 1 file to E:\asf\maven\maven-3\trunk
 Deleting: E:\asf\maven\maven-3\trunk\dependencies.xml
 generate-sources:
 Created dir: E:\asf\maven\maven-3\trunk\bootstrap\target
 Created dir: E:\asf\maven\maven-3\trunk\bootstrap\target\generated-sources
 Generating sources for maven-model/src/main/mdo/maven.mdo
 Generating sources for maven-plugin-api/src/main/mdo/lifecycle.mdo
 Generating sources for maven-model-builder/src/main/mdo/profiles.mdo
 Generating sources for maven-settings/src/main/mdo/settings.mdo
 Generating sources for maven-core/src/main/mdo/toolchains.mdo
 Generating sources for maven-repository-metadata/src/main/mdo/metadata.mdo
 Generating sources for maven-compat/src/main/mdo/profiles.mdo
 Generating sources for maven-compat/src/main/mdo/paramdoc.mdo
 compile-boot:
 Created dir: E:\asf\maven\maven-3\trunk\bootstrap\target\classes
 Compiling 719 source files to
 E:\asf\maven\maven-3\trunk\bootstrap\target\classes
 Note: Some input files use or override a deprecated API.
 Note: Recompile with -Xlint:deprecation for details.
 Note: Some input files use unchecked or unsafe operations.
 Note: Recompile with -Xlint:unchecked for details.
 Copying 1 file to E:\asf\maven\maven-3\trunk\bootstrap\target\classes
 process-classes:
 Using plexus version 1.5.5
 SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
 SLF4J: Defaulting to no-operation (NOP) logger implementation
 SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.
 [INFO] Discovered 129 component descriptors(s)
 maven-compile:
 SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
 SLF4J: Defaulting to no-operation (NOP) logger implementation
 SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
 details.
 null 3.1-SNAPSHOT
 ${distributionShortName} home: unknown maven home
 Java version: 1.6.0_30, vendor: Sun Microsystems Inc.
 Java home: C:\Program Files\Java\jdk1.6.0_30\jre
 Default locale: de_CH, platform encoding: Cp1252
 OS name: windows vista, version: 6.0, arch: x86, family:
 windows[debug] execute contextualize
 [debug] execute contextualize

 ---
  T E S T S
 ---
 Running org.apache.maven.model.ActivationFileTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
 Running org.apache.maven.model.ActivationOSTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
 Running org.apache.maven.model.ActivationPropertyTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
 Running org.apache.maven.model.ActivationTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
 Running org.apache.maven.model.BuildTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
 Running org.apache.maven.model.CiManagementTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
 Running 

Re: AW: [maven-3/trunk] bootstrap-build failing

[Stuart McCulloch]

On 1 Nov 2012, at 15:06, Stadelmann Josef wrote:

 OK Stuart,
 at my Vista System, it fails. Just downloaded and installed ant 1.8.4
 
 $ java -version
 java version 1.6.0_30
 Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
 Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode)
 
 C770817@C036357 /e/asf/maven/maven-3/trunk
 
 $ ant -version
 Apache Ant(TM) version 1.8.4 compiled on May 22 2012
 
 $ ant -d -f build.xml
 ...
 BUILD FAILED
 E:\asf\maven\maven-3\trunk\build.xml:250: Java returned: 1
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:111)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
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:597)
at 
 org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:392)
at org.apache.tools.ant.Target.performTasks(Target.java:413)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at 
 org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
 
 Total time: 2 minutes 7 seconds
 
 E:\asf\maven\maven-3\trunk
 
 So I have no clue why this ant bootstrap-build fails  on my Vista System 
 which is a clean as many other systems used to develop code.
 The line build.xml(250) is where ...MavenCLI class gets invoked/forked by a 
 java command. I have no clue why 1 is returned to/by Java.

Line 250 in build.xml is where it forks the JVM - if you capture the output 
from running ant -d -f build.xml and look for maven-compile: then it should 
show the actual command it forks (ie. the one that returns error code 1). You 
could copy that command and all its arguments (ie. java -classpath ...snip... 
org.apache.maven.cli.MavenCli ...etc...) and try it from the command-line to 
see if there's an error message that's not getting passed on. Perhaps also add 
'-X' after 'org.apache.maven.cli.MavenCli' to enable full debug output.

 OK - we sit behind a firewall , if that makes a difference?

The bootstrap build should use your local settings.xml just like Maven, so as 
long this is configured with any proxy needed to access Maven Central then it 
should be fine.

 Josef
 
 -Ursprüngliche Nachricht-
 Von: Stuart McCulloch [mailto:mccu...@gmail.com] 
 Gesendet: Donnerstag, 1. November 2012 14:52
 An: Maven Users List
 Betreff: Re: [maven-3/trunk] bootstrap-build failing
 
 On 1 November 2012 10:29, Stadelmann Josef  
 josef.stadelm...@axa-winterthur.ch wrote:
 
 How can I cure best the problems shown below? it occurs during a 
 bootstrap-build of maven-3/trunk on my Vista System.
 (see red lines, which are of interesst to me).
 
 I have successfully build from sources SLF4J é all. Where does this 
 bootstrap-build.xml expect this files now?
 where do I have to copy the SLF4J-*.jars and maybe others to make the 
 maven-3/trunk build.xml (bootstrap-build) happy?
 
 
 SLF4J should be downloaded by the [artifact:dependencies] task, just like all 
 the other bootstrap dependencies - you shouldn't need to build it yourself.
 
 Has the final error shown below, (which makes the bootstrap-build fail?) to
 do with the absence of SLF4J-*.jar's or what does it indicate?
 
 
 The SLF4J messages about 'Failed to load class' and 'Defaulting to 
 no-operation' are informational and should not fail the build. It means that 
 it couldn't find a backend implementation (the current build does not specify 
 a particular backend on purpose) so it's telling you about this in case you 
 had meant to choose a backend but forgot:
 http://www.slf4j.org/codes.html#StaticLoggerBinder
 
 The final error just says that Java returned 1 on exit, but doesn't say why
 - you could try running ant -d -f build.xml to see if that gives more 
 information about the failure at the end.
 
 FWIW, I just tried the bootstrap build on a clean system (OSX, Java 1.6.0_37, 
 Ant 1.8.4) and it built without errors - note that I still saw the SLF4J 
 messages, but those are expected at the moment
 
 This on a Windows Vista System
 Josef
 
 ant -f E:\\asf\\maven\\maven-3\\trunk all
 clean-bootstrap:
 initTaskDefs:
 Building Apache Maven ...
 isMavenHomeSet:
 init:
 maven.home = E:\Users\C770817

Re: maven-compiler-plugin woes

[Stuart McCulloch]

On 4 Oct 2012, at 19:22, Davis Ford wrote:

 This doesn't make a whole lot of sense to me.  Any idea what the problem is
 here?

You've given the jersey-server dependency a scope of runtime which means it 
is on the runtime and test classpaths, but _not_ the compile classpath, 
therefore the class is not visible to the compiler.

If you change the scope to be either compile (ie. you expect to provide this 
in your final deliverable) or provided (ie. you expect the container running 
your code to provide this) then it will compile.

See the table from 
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
 for more details.

 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 2.944s
 [INFO] Finished at: Thu Oct 04 17:54:16 UTC 2012
 [INFO] Final Memory: 9M/23M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
 (default-compile) on project example-server: Compilation failure:
 Compilation failure:
 [ERROR]
 /home/ubuntu/git/example-server/src/main/java/com/example/m2m/service/DeviceService.java:[17,25]
 error: package com.sun.jersey.api does not exist
 [ERROR]
 /home/ubuntu/git/my-server/src/main/java/com/example/m2m/service/DeviceService.java:[33,11]
 error: cannot find symbol
 [ERROR] symbol:   class JResponse
 [ERROR] location: class DeviceService
 
 The class I wrote DeviceService.java has this import:
 
 import com.sun.jersey.api.JResponse;
 
 pom.xml snipped:
 
 dependencies
   dependency
groupIdcom.sun.jersey/groupId
artifactIdjersey-server/artifactId
version${jersey.version}/version
scoperuntime/scope
  /dependency
   etc...
 /dependencies
 
 Ok, the compiler can't find it -- works fine in Eclipse - I built the
 eclipse project with mvn eclipse:eclipse, it resolves to the
 jersey-server-1.14.jar - in Eclipse, I expand the jar, and see the class is
 indeed in there.  dependency:tree shows it is in the classpath, and scope
 is runtime =
 
 ubuntu@$ mvn dependency:tree
 [INFO] Scanning for projects...
 [INFO]
 
 [INFO]
 
 [INFO] Building Example Webapp 1.0-SNAPSHOT
 [INFO]
 
 [INFO]
 [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ example-server
 ---
 [INFO] com.example:example-server:war:1.0-SNAPSHOT
 [INFO] +- org.zeromq:jzmq:jar:1.0:compile
 [INFO] +- com.google.protobuf:protobuf-java:jar:LATEST:compile
 [INFO] +- javax.ws.rs:jsr311-api:jar:1.1.1:compile
 [INFO] +- com.sun.jersey:jersey-server:jar:1.14:runtime
 [INFO] |  +- asm:asm:jar:3.1:runtime
 [INFO] |  \- com.sun.jersey:jersey-core:jar:1.14:runtime
 [INFO] +- com.sun.jersey:jersey-json:jar:1.14:runtime
 [INFO] |  +- org.codehaus.jettison:jettison:jar:1.1:runtime
 [INFO] |  |  \- stax:stax-api:jar:1.0.1:runtime
 [INFO] |  +- com.sun.xml.bind:jaxb-impl:jar:2.2.3-1:runtime
 [INFO] |  |  \- javax.xml.bind:jaxb-api:jar:2.2.2:runtime
 [INFO] |  | +- javax.xml.stream:stax-api:jar:1.0-2:runtime
 [INFO] |  | \- javax.activation:activation:jar:1.1:runtime
 [INFO] |  +- org.codehaus.jackson:jackson-core-asl:jar:1.9.2:runtime
 [INFO] |  +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.2:runtime
 [INFO] |  +- org.codehaus.jackson:jackson-jaxrs:jar:1.9.2:runtime
 [INFO] |  \- org.codehaus.jackson:jackson-xc:jar:1.9.2:runtime
 [INFO] +- com.sun.jersey.contribs:jersey-spring:jar:1.14:runtime
 [INFO] |  +- com.sun.jersey:jersey-servlet:jar:1.14:runtime
 [INFO] |  +- org.springframework:spring-core:jar:3.0.0.RC3:runtime
 [INFO] |  |  \- org.springframework:spring-asm:jar:3.0.0.RC3:runtime
 [INFO] |  +- org.springframework:spring-beans:jar:3.0.0.RC3:runtime
 [INFO] |  +- org.springframework:spring-context:jar:3.0.0.RC3:runtime
 [INFO] |  |  +- aopalliance:aopalliance:jar:1.0:runtime
 [INFO] |  |  \- org.springframework:spring-expression:jar:3.0.0.RC3:runtime
 [INFO] |  +- org.springframework:spring-web:jar:3.0.0.RC3:runtime
 [INFO] |  \- org.springframework:spring-aop:jar:3.0.0.RC3:runtime
 [INFO] +- org.slf4j:jcl-over-slf4j:jar:1.5.8:compile
 [INFO] +- org.slf4j:slf4j-api:jar:1.5.8:compile
 [INFO] +- org.slf4j:slf4j-log4j12:jar:1.5.8:compile
 [INFO] +- log4j:log4j:jar:1.2.14:compile
 [INFO] \- junit:junit:jar:4.8.2:test
 
 Let's validate that the class does indeed exist in that jarfile...and it
 does =
 
 ubuntu@$ jar tf
 ~/.m2/repository/com/sun/jersey/jersey-server/1.14/jersey-server-1.14.jar
 META-INF/MANIFEST.MF
 META-INF/
 META-INF/jersey-module-version
 META-INF/maven/
 META-INF/maven/com.sun.jersey/
 META-INF/maven/com.sun.jersey/jersey-server/
 META-INF/maven/com.sun.jersey/jersey-server/pom.properties
 META-INF/maven/com.sun.jersey/jersey-server/pom.xml
 META-INF/services/
 META-INF/services/com.sun.jersey.spi.StringReaderProvider
 

Re: Bndlib bug?

[Stuart McCulloch]

Bugs can be reported on the github site: https://github.com/bndtools/bnd or via 
the Apache Felix project. You should also try the latest 2.4.0-SNAPSHOT of the 
bundleplugin, as this uses the latest bndlib code which is expected to be 
released soon.

--
Cheers, Stuart

On 21 Sep 2012, at 01:04, Martin Gainty mgai...@hotmail.com wrote:

 Folks
 
 I came upon a fairly serious bug in in bndlib 1.50.0 ...
 i have a patch that works as a maven dependency for
  groupIdorg.apache.felix/groupId
  artifactIdmaven-bundle-plugin/artifactId
  version2.3.7/version
 
 i have tested this patch on 
 axis2-eclipse-service-plugin (eclipse plugin to generate axis2-1.6.2 service)
 
 Any ideas on where the JIRA is for bndlib and how to submit the patch would 
 be appreciated
 
 Thanks,
 Martin 
 __ 
 Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
 Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
 sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
 oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich 
 dem Austausch von Informationen und entfaltet keine rechtliche 
 Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen 
 wir keine Haftung fuer den Inhalt uebernehmen.
 Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
 destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
 l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci 
 est interdite. Ce message sert à l'information seulement et n'aura pas 
 n'importe quel effet légalement obligatoire. Étant donné que les email 
 peuvent facilement être sujets à la manipulation, nous ne pouvons accepter 
 aucune responsabilité pour le contenu fourni.
 

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

Re: maven-jar-plugin refuses to include META-INF/persistence.xml ! - Problem solved

[Stuart McCulloch]

On 12 Aug 2012, at 03:54, Wayne Fay wayne...@gmail.com wrote:

 I'm also using the Apache Felix bundle-plugin which allows for:
 
packagingbundle/packaging
 
 This is not a packaging delivered by Apache Maven. Thus you can
 blame whoever is making this packaging available to you.
 
 That is, I can use either or of bundle or jar for packaging. However 
 when i use:
 
packagingbundle/packaging
 
 I don't get the META-INF/persistence.xml file in the jar.
 
 Most likely the bundle packaging does not include META-INF for some
 reason. I would talk to the Apache Felix people about this issue so
 they can resolve it in their code.

This is working as designed, as covered in the FAQ:

   
http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html#ApacheFelixBundlePluginFAQ-WhenIbuildabundle%252Csomeclassesarebuiltin%2522target%252Fclasses%2522butthey%2527renotincludedinthefinaljar.

Not everything in target/classes ends up in the bundle by default (unlike jar) 
- the underlying bnd library will only pull what resources/packages you tell it 
to into the bundle. While the plugin attempts to generate reasonable defaults 
based on your source, it can't do this for generated resources such as this 
persistence.xml file (see last FAQ item). Instead you need something like:

   Include-Resource{maven-resources}, 
META-INF/persistence.xml=target/classes/META-INF/persistence.xml/Include-Resource

Where {maven-resources} is a placeholder for the default detected resources, as 
described in the Include-Resource section of 
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

The raw format of bnd's Include-Resource instruction can be found at 
http://www.aqute.biz/Bnd/Format#include-resource

HTH

--
Cheers, Stuart

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

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

Re: install jar file into local repository

[Stuart McCulloch]

On 27 July 2012 14:05, Matthias Pfeifer mpfeife...@gmail.com wrote:

 Hello,

 I have a jar file that i plan to add to a projects dependencies. I
 need to test this jar file as a dependency of some project and
 therefore did

 $ mvn -l mvn.log -e -X install:install-file -Dfile=myartifact.jar
 -DgroupId=com.mycompany -DartifactId=myartifact -Dversion=6.1.0 RC
 -Dpackaging=jar

 to install it.

 Maven informs me about BUILD SUCCESS (mvn.log is attached). Taking a
 look into the repository

 $ ls $HOME/.m2/repository/com/mycompany/myartifact/6.1.0\ RC/
 -rwx--+ 1 myusername Domain Users  184 Jul 27 14:54
 _maven.repositories
 -rwx--+ 1 myusername Domain Users 453125 Jul 19 10:53
 ndf-core-6.1.0 RC.jarqls


^ this extension looks odd, almost as if qls was somehow attached to the
end of your command (making it -Dpackaging=jarqls instead
of -Dpackaging=jar)

-rwx--+ 1 myusername Domain Users  497 Jul 27 14:54
 ndf-core-6.1.0 RC.pom

 Reveals that the jar file is not present. Either I have the wrong
 expectation here or something else i am doing wrong.

 Is this not the way to install a jar-file to a local repository?
 According to official FAQ Question 11 it is...

 Matthias

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


-- 
Cheers, Stuart

Re: problems compiling osgi-4.3 bundles using maven

[Stuart McCulloch]

Also be aware of an issue using JDK7 to compile against the official OSGi 4.3 
API jars...

   
http://stackoverflow.com/questions/10911231/how-to-compile-mavenized-osgi-4-3-bundle-with-openjdk-7

Solutions are to either use JDK6, or use the recently released OSGi 5.0 API 
jars, or rebuild the 4.3 API jars locally (or use ones that someone else has 
rebuilt)

On 16 Jul 2012, at 13:09, Ron Wheeler wrote:

 What is at line 258 in Startup.java.
 It says it can not find the definition of an object referenced on that line.
 
 Ron
 
 On 16/07/2012 4:55 AM, Michał Zegan wrote:
 D:\projekty\naszmud\naszmud-startup\src\main\com\tyflonet\naszmud\Startup.java:[258,36]
 error: cannot find symbol
 
 
 -- 
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: problems compiling osgi-4.3 bundles using maven

[Stuart McCulloch]

On 16 Jul 2012, at 14:25, Michał Zegan wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 It looks like this is the correct thing to fix and I am using jdk7
 because jdk7 contains some funny features not present in jdk6 that I
 need/want to use.
 Can you tell me why the compiler won't display the full error message?

probably related to http://jira.codehaus.org/browse/MCOMPILER-158

 W dniu 2012-07-16 15:03, Stuart McCulloch pisze:
 Also be aware of an issue using JDK7 to compile against the official OSGi 
 4.3 API jars...
 
 
 http://stackoverflow.com/questions/10911231/how-to-compile-mavenized-osgi-4-3-bundle-with-openjdk-7
 
 Solutions are to either use JDK6, or use the recently released OSGi
 5.0 API jars, or rebuild the 4.3 API jars locally (or use ones that
 someone else has rebuilt)
 
 On 16 Jul 2012, at 13:09, Ron Wheeler wrote:
 
 What is at line 258 in Startup.java.
 It says it can not find the definition of an object referenced on
 that line.
 
 Ron
 
 On 16/07/2012 4:55 AM, Michał Zegan wrote:
 
 D:\projekty\naszmud\naszmud-startup\src\main\com\tyflonet\naszmud\Startup.java:[258,36]
 error: cannot find symbol
 
 
 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQIcBAEBAgAGBQJQBBYuAAoJEIm05B02l8E63JwQAIVbHi61pwVFuAY4uO7KK+yX
 neJPf252QeFQWmLTBHXrmeLWSLaHJtE4TMkkBa4Du9x61P/tuMcEgKRVBHrwBVUF
 Ywif5dR81tL5w+6KXsXsgpzdR0gcCbIHjO+Rjdjslp2at1SOEfna08VsgweFMyU3
 cZvcboQFtkTJId6n47eEoptcTg9EAqvtv+byIBwxKAT+atJyNYTcqq/tkEEZ+HOw
 dY+56S047K0K/g0xIQbOZ3625FGROdvHAMasnSIl+9dnW1kY4EXAsXEZWj92miqg
 EaoOPwcIyRQJKFxGg8tth0fpVh7lH8I91t68lug3tSctlmpUYrvRGMAgwITuAVml
 0sjxXVTrwdRC7w/3kADky+ZMWAXzvRJsHSyA91PO2dsNd+SCKWkoZsOxLWG0IYNY
 GKNUTL/ADc7rsujqfYie4cB7yROJKtRM/xMDzZ3MA7reDA1XByJyqfuuCm9XMpS3
 4pSsrWF4Ysvchc6vUYtVRrhfQ3VChemSJoQf6vcZ8CWjiHLv4934GigQ/x5vQRhc
 XiI6ve9UCLi3FbWrWkBs1qJl8vInnfORM3VchEQ7YRDTh76HKHiAACzQXT21B1sd
 lukB/j02HzEHB2jffGLKTJb9QNkTY6Z+GhhcsqlM0KIjTnNIkKrOADcVLpKEXxJS
 1moO+Ha7KZmWxaWSx1T0
 =bdcZ
 -END PGP SIGNATURE-
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Memory Leak?

[Stuart McCulloch]

On 12 May 2012, at 07:32, Hilco Wijbenga wrote:

 On 11 May 2012 22:47, Anders Hammar and...@hammar.net wrote:
 This is not uncommon for large multi-module builds. You need to
 increase the memory available for Maven, such as the heap depending on
 the error you're getting.
 Do this by setting the MAVEN_OPTS env variable.
 
 I know, it is already getting 2GB. I can't set it any higher (Maven
 refuses to even start then).

You might be running out of PermGen space - this is a separate heap in the 
HotSpot JVM used for classes, etc. Normally the default PermGen limit is ok, 
but can become an issue when running large apps or doing lots of code 
generation / compilation. The other thing is that bumping the main heap size 
doesn't change the default PermGen limit - instead you need to use something 
like:

   -XX:MaxPermSize=256m

https://cwiki.apache.org/MAVEN/outofmemoryerror.html

 My experience is that this is mainly due to the plugins being used in
 the build, not Maven core. Are you using Maven 3? Maven 3 core has a
 smaller memory footprint than Maven 2.
 
 Maven 3.0.3. Should Maven not simply release plugins (and the memory
 they use) between module builds?

IIRC the Maven plugin manager should release mojos after each execution - of 
course this depends on the plugin not having a memory leak involving static 
members, which can keep memory around until the classloader is unloaded (which 
can take longer depending on other references). Also if you're hitting the 
PermGen limit then it's more about the amount of classes and interned strings 
you're loading rather the amount of objects being created.

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


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

Re: Memory Leak?

[Stuart McCulloch]

On 12 May 2012, at 12:05, Mark Struberg wrote:

 It could also be a proxy problem of course. How is guice doing proxies? 

Maven currently uses guice-no_aop 
http://code.google.com/p/google-guice/wiki/OptionalAOP so any proxies would use 
the standard JVM proxy mechanism.
That said, I wouldn't expect many proxies to be generated with Maven - they're 
typically only used when there are circular references between constructors.

 Proxies are also loaded via the ClassLoader and consume perm gen space.
 
 LieGrue,
 strub
 
 - Original Message -
 From: Stuart McCulloch mccu...@gmail.com
 To: Maven Users List users@maven.apache.org
 Cc: 
 Sent: Saturday, May 12, 2012 11:36 AM
 Subject: Re: Memory Leak?
 
 On 12 May 2012, at 07:32, Hilco Wijbenga wrote:
 
 On 11 May 2012 22:47, Anders Hammar and...@hammar.net wrote:
 This is not uncommon for large multi-module builds. You need to
 increase the memory available for Maven, such as the heap depending on
 the error you're getting.
 Do this by setting the MAVEN_OPTS env variable.
 
 I know, it is already getting 2GB. I can't set it any higher (Maven
 refuses to even start then).
 
 You might be running out of PermGen space - this is a separate heap in the 
 HotSpot JVM used for classes, etc. Normally the default PermGen limit is ok, 
 but 
 can become an issue when running large apps or doing lots of code generation 
 / 
 compilation. The other thing is that bumping the main heap size doesn't 
 change the default PermGen limit - instead you need to use something like:
 
-XX:MaxPermSize=256m
 
 https://cwiki.apache.org/MAVEN/outofmemoryerror.html
 
 My experience is that this is mainly due to the plugins being used in
 the build, not Maven core. Are you using Maven 3? Maven 3 core has a
 smaller memory footprint than Maven 2.
 
 Maven 3.0.3. Should Maven not simply release plugins (and the memory
 they use) between module builds?
 
 IIRC the Maven plugin manager should release mojos after each execution - of 
 course this depends on the plugin not having a memory leak involving static 
 members, which can keep memory around until the classloader is unloaded 
 (which 
 can take longer depending on other references). Also if you're hitting the 
 PermGen limit then it's more about the amount of classes and interned 
 strings you're loading rather the amount of objects being created.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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