Re: Mojo parameters of type java.nio.file.Path

[Stuart McCulloch]

That's correct, Maven still uses the Plexus configuration API to convert
XML configuration to mojo parameters.

Sisu looks for the best matching converter as follows for Plexus
configuration requests:

1. custom converters registered via ConverterLookup (Plexus API)
2. built-in converters that mimic Plexus behaviour
3. built-in converters registered with Guice as TypeConverter bindings
(used when configuring beans)

By default Plexus' File converter doesn't do any base directory alignment -
but Maven registers an evaluator that provides some custom alignment rules:

https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java#L461

To provide the same custom alignment for Path we just need to copy this
class and replace 'File' with 'Path':

https://github.com/eclipse/sisu.plexus/blob/releases/0.3.5/org.eclipse.sisu.plexus/src/org/codehaus/plexus/component/configurator/converters/basic/FileConverter.java


On Sun, 31 Jul 2022 at 09:24, Konrad Windszus  wrote:

> At least for Maven 3.8.6 this is not true.
> Plexus Container API is still used in
> https://github.com/apache/maven/blob/84538c9988a25aec085021c365c560670ad80f63/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L625
>
> A complete stack trace for injecting File parameters in Mojos looks like
> this:
> Thread [main] (Suspended (breakpoint at line 35 in FileConverter))
> FileConverter.fromString(String) line: 35
>
> FileConverter(AbstractBasicConverter).fromConfiguration(ConverterLookup,
> PlexusConfiguration, Class, Class, ClassLoader, ExpressionEvaluator,
> ConfigurationListener) line: 43
> FileConverter.fromConfiguration(ConverterLookup,
> PlexusConfiguration, Class, Class, ClassLoader, ExpressionEvaluator,
> ConfigurationListener) line: 45
> CompositeBeanHelper.convertProperty(Class, Class, Type,
> PlexusConfiguration) line: 273
> CompositeBeanHelper.setProperty(Object, String, Class,
> PlexusConfiguration) line: 210
> ObjectWithFieldsConverter.processConfiguration(ConverterLookup,
> Object, ClassLoader, PlexusConfiguration, ExpressionEvaluator,
> ConfigurationListener) line: 101
> BasicComponentConfigurator.configureComponent(Object,
> PlexusConfiguration, ExpressionEvaluator, ClassRealm,
> ConfigurationListener) line: 34
> DefaultMavenPluginManager.populatePluginFields(Object,
> MojoDescriptor, ClassRealm, PlexusConfiguration, ExpressionEvaluator) line:
> 635
> DefaultMavenPluginManager.getConfiguredMojo(Class,
> MavenSession, MojoExecution) line: 597
> DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution)
> line: 124
> MojoExecutor.doExecute2(MavenSession, MojoExecution) line: 370
> MojoExecutor.doExecute(MavenSession, MojoExecution, ProjectIndex,
> DependencyContext) line: 351
> MojoExecutor.execute(MavenSession, MojoExecution, ProjectIndex,
> DependencyContext) line: 215
> MojoExecutor.execute(MavenSession, MojoExecution, ProjectIndex,
> DependencyContext, PhaseRecorder) line: 171
> MojoExecutor.execute(MavenSession, List,
> ProjectIndex) line: 163
> LifecycleModuleBuilder.buildProject(MavenSession, MavenSession,
> ReactorContext, MavenProject, TaskSegment) line: 117
> LifecycleModuleBuilder.buildProject(MavenSession, ReactorContext,
> MavenProject, TaskSegment) line: 81
> SingleThreadedBuilder.build(MavenSession, ReactorContext,
> ProjectBuildList, List, ReactorBuildStatus) line: 56
> LifecycleStarter.execute(MavenSession) line: 128
> DefaultMaven.doExecute(MavenExecutionRequest, MavenSession,
> MavenExecutionResult, DefaultRepositorySystemSession) line: 294
> DefaultMaven.doExecute(MavenExecutionRequest) line: 192
> DefaultMaven.execute(MavenExecutionRequest) line: 105
> MavenCli.execute(CliRequest) line: 960
> MavenCli.doMain(CliRequest) line: 293
> MavenCli.main(String[], ClassWorld) line: 196
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line:
> not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 566
> Launcher.launchEnhanced(String[]) line: 282
> Launcher.launch(String[]) line: 225
> Launcher.mainWithExitCode(String[]) line: 406
> Launcher.main(String[]) line: 347
>
> Even in Maven 4 (
> https://github.com/apache/maven/blob/a53a1aa232bc383baf055d884a7c66319d10d404/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L644)
> the Plexus API is still used.
>
> So I think that sisu.plexus is really the project that needs the
> enhancement/fix.
> Is there any plan to get rid of Plexus Containers API for Maven 4?
>
> Thanks,
> Konrad
>
>
> On 2022/07/29 17:17:30 Tamás 

Re: Maven plugins - injecting Maven components

[Stuart McCulloch]

Sorry, I was just struggling to see where exposing JSR330 has negatively
impacted users in practice (ie excluding anything related to exposing CDI)

For the CDI API sure, when that was exposed we didn't anticipate that the
CDI spec would evolve how it did - so removing that is logical - but when
there's a simple standard which has remained consistent (and the Jakarta
variant is just a relocation due to naming issues) then I would have
thought it would help users to let them use that rather than force them to
use another API

But regardless, the container will still work with whatever's exposed. So
as Sylwester says the best way forward is probably with a
design/requirement doc - then if there's any new annotations (over the
existing Plexus or JSR330 ones) we can just update the container to support
them.

--
Cheers, Stuart

On Thu, 2 Jun 2022, 10:21 Romain Manni-Bucau,  wrote:

> @Stuart: api validating or enforcing classloader in mojo need workarounds
> since you will use javax.inject from maven and not from your mojo
> container/code (embedding an OSGi container can have this issue in some
> cases without much hack but most container using classloaders will hit it,
> I hit it at talend for component framework, some tomcat extensions as well
> etc...). Nothing theorical and even if it would be theorical, we have to
> respect out mojo design right? so we can't do that anyway until we assume
> to maintain it and not move to jakarta anytime soon without a
> classfiletransformer maintaining the mapping which is something which was
> requested to be avoided on maven 4 path IIRC.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 2 juin 2022 à 11:08, Sylwester Lachiewicz 
> a
> écrit :
>
> > Maybe design document and later with PoC API, implementation is something
> > that we missed and You can help here to solve this problem for users,
> based
> > on real case from You?
> >
> > Br
> > Sylwester
> >
> >
> > czw., 2 cze 2022, 10:57 użytkownik Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > napisał:
> >
> > > Hi Stuart,
> > >
> > > Not really, they relate to cdi or atinject spec and explain why we must
> > not
> > > expose it to plugins - and more generally how exposing standard or
> > > mainstream API does not reach our isolation goal for plugins.
> > > Concretely our maven-core extension.xml file should not list any
> > > javax/jakarta package and probably not widely used API (mentionned
> slf4j)
> > > too, this is a general rule if we want to keep our plugin mecanism sane
> > and
> > > working for most people and in time.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le jeu. 2 juin 2022 à 10:51, Stuart McCulloch  a
> > écrit
> > > :
> > >
> > > > Thanks - afaict those all relate to the CDI API which was previously
> > only
> > > > added so people could use the @Typed annotation during early
> migration
> > > away
> > > > from Plexus specifics (this is not required by the container, it's an
> > > > optional dependency)
> > > >
> > > > As mentioned before I only know of one external extension that was
> > still
> > > > using the @Typed annotation for one of its components, and it would
> be
> > > > possible to alter that extension to not need that (if anyone still
> even
> > > > uses it) - so it would be fine to remove the CDI API dependency from
> > > Maven.
> > > >
> > > > On Thu, 2 Jun 2022, 08:09 Romain Manni-Bucau,  >
> > > > wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > Sorry for the delay.
> > > > >
> > > > > Here what I found back but an be worth checking ot

Re: Maven plugins - injecting Maven components

[Stuart McCulloch]

Could you highlight which one was specifically an issue with JSR330 (ie. an
actual issue, not a theoretical one) and not the CDI API as I must have
missed it?

On Thu, 2 Jun 2022, 09:57 Romain Manni-Bucau,  wrote:

> Hi Stuart,
>
> Not really, they relate to cdi or atinject spec and explain why we must not
> expose it to plugins - and more generally how exposing standard or
> mainstream API does not reach our isolation goal for plugins.
> Concretely our maven-core extension.xml file should not list any
> javax/jakarta package and probably not widely used API (mentionned slf4j)
> too, this is a general rule if we want to keep our plugin mecanism sane and
> working for most people and in time.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 2 juin 2022 à 10:51, Stuart McCulloch  a écrit
> :
>
> > Thanks - afaict those all relate to the CDI API which was previously only
> > added so people could use the @Typed annotation during early migration
> away
> > from Plexus specifics (this is not required by the container, it's an
> > optional dependency)
> >
> > As mentioned before I only know of one external extension that was still
> > using the @Typed annotation for one of its components, and it would be
> > possible to alter that extension to not need that (if anyone still even
> > uses it) - so it would be fine to remove the CDI API dependency from
> Maven.
> >
> > On Thu, 2 Jun 2022, 08:09 Romain Manni-Bucau, 
> > wrote:
> >
> > > Hi
> > >
> > > Sorry for the delay.
> > >
> > > Here what I found back but an be worth checking other project mailing
> > lists
> > > since it often leads to dirty workarounds:
> > >
> > > - https://lists.apache.org/thread/wlocsqglzsn18g3o4vc8721gm3nmn99x
> > > - https://lists.apache.org/thread/d9rhh61yy1mtorcc7n6v903rs24md649
> > > - https://lists.apache.org/thread/oygsxwfr0t6j1bjj8gqw03fwnhst1281 /
> > > https://lists.apache.org/thread/7cs0ptv293b0zddwg5zogqf4m0c81jv8 (this
> > one
> > > comes from tomee@)
> > > - https://lists.apache.org/thread/pjxvmy4lwp7mxk8mvnzrd031rktvqgh1
> > (when I
> > > said it was reported quite a long time ago and broke quite quickly
> after
> > it
> > > was added)
> > > - https://lists.apache.org/thread/w8f2k5ktfw4yzvo4y5zbszw3nnl636dy
> > >
> > > One interesting related tickets:
> > >
> > > - https://issues.apache.org/jira/browse/MNG-6354
> > >
> > > Side note: browsing plugin lists/chans can also be interesting
> (thinking
> > to
> > > TomEE, Meecrowave, Jetty which hit these conflicts by the past out of
> my
> > > head).
> > >
> > > To summarize current state:
> > >
> > > - we depend and export JSR 330 (@inject) and JSR 250 (postconstruct
> etc),
> > > these ones are frozen and legacy due to javax->jakarta renaming, it
> means
> > > libraries we use and relying on them will likely move anytime soon to
> > > jakarta so if we want to be able to upgrade without build hacks we'll
> > need
> > > to drop javax support and move to jakarta (not tomorrow but it will
> come
> > > and likely for maven 4 to avoid to break multiple times?)
> > > - anything we export from our maven.core realm can conflict with plugin
> > > realms until we let mojo class realm strategy be configurable
> > (parent/child
> > > first) but it also means we take the risk the container features don't
> > work
> > > anymore if we do - no more injections in mojo for ex. So even if for
> > > javax.* risk is low since it is not legacy dependencies, it is a rule
> we
> > > should apply to most of our exported libraries (yes, slf4j I'm looking
> at
> > > you for ex). General rule of thumb would be to only export packages we
> > own
> > > like org.apache.maven, org.codehaus.plexus etc...
> > > - so overall the minimum risk solution is to NOT expose these API and
> > > consider them internal to maven ecosystem (I don't see us breaking
> maven
> > > plugins, it is too much work for the industry without any gain for end
> > > users IMHO)
> > >
> > > Hope it helps a bit.
> > >
&g

Re: Maven plugins - injecting Maven components

[Stuart McCulloch]

; > >
> > >
> >
> https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/
> > > > [3] https://maven.apache.org/maven-jsr330.html
> > > >
> > > >
> > > > pt., 20 maj 2022 o 21:13 Romain Manni-Bucau 
> > > > napisał(a):
> > > >
> > > > > I'm not sure for shared, I always considered them as internals of
> > maven
> > > > > projects and rarely saw them reused except a very few times but
> > > reasoning
> > > > > is the same whatever module we speak about: does it impact external
> > > > > consumer? If yes -> only org.apache.maven API or
> > > assimilated/assimilable
> > > > > (plexus is today I think), else we don't care and do what we like
> > IMHO.
> > > > >
> > > > >
> > > > > Le ven. 20 mai 2022 à 21:01, Sylwester Lachiewicz <
> > > slachiew...@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > And what about shared libraries?  they can be used by plugins or
> > even
> > > > > > externally.
> > > > > > Sylwester
> > > > > >
> > > > > > pt., 20 maj 2022, 19:15 użytkownik Romain Manni-Bucau <
> > > > > > rmannibu...@gmail.com>
> > > > > > napisał:
> > > > > >
> > > > > > > It is quite simple:
> > > > > > >
> > > > > > > Maven plugin: maven API or plexus annotations are preferred
> > > > > > > Maven core: JSR 330 is out internal API for IoC
> > lookups/injections
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Le ven. 20 mai 2022 à 18:08, Slawomir Jaranowski <
> > > > > s.jaranow...@gmail.com
> > > > > > >
> > > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I'm a little confused - what should be conclusions from this
> > > > > > discussion?
> > > > > > > >
> > > > > > > > I asked about using JSR330 with maven components like
> > > MavenProject,
> > > > > > > > MavenSession ... in plugin Mojo code.
> > > > > > > > But I see discussion about using JSR330 at general in Maven
> > > plugins
> > > > > > > >
> > > > > > > > Currently we widely use  JSR330 in core Maven plugins as
> > > > replacement
> > > > > > for
> > > > > > > > plexus annotations.
> > > > > > > >
> > > > > > > > Can anybody else summarize it? ... Maybe I wrong understood
> > this
> > > > > > > > discussion.
> > > > > > > >
> > > > > > > >
> > > > > > > > śr., 18 maj 2022 o 16:07 Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > > > > > napisał(a):
> > > > > > > >
> > > > > > > > > Le mer. 18 mai 2022 à 15:19, Stuart McCulloch <
> > > mccu...@gmail.com
> > > > >
> > > > > a
> > > > > > > > écrit
> > > > > > > > > :
> > > > > > > > >
> > > > > > > > > > On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau <
> > > > > > 

Re: Maven plugins - injecting Maven components

[Stuart McCulloch]

On Wed, 18 May 2022 at 14:15, Romain Manni-Bucau 
wrote:

> Le mer. 18 mai 2022 à 15:03, Stuart McCulloch  a écrit
> :
>
> > I do wonder whether we're conflating the real issues of exposing the CDI
> > API (for @Typed) with the much smaller JSR330 API
> >
>
> Yes as soon as you have a different version needed by a plugin and the api
> exposed (parent first forced - and if not forced we dont know if it works).
>

There's only ever been one version of the JSR 330 API because it's so small
and complete (and I'd be surprised if the jakarta.inject API is any
different...)


> So we shouldnt leak what others can use in the API - no parent ClassRealm
> access.
>
>
> >
> > Does anyone have a link to an issue that specifically involved exporting
> > the JSR330 API (I did a quick search but the threads I found were all
> about
> > the CDI API)
> > IIRC there was only one external plugin/extension that ever used @Typed,
> so
> > we could easily just stop exporting the CDI API while continuing to
> export
> > JSR330
> >
> > (other comments inline below...)
> >
> > On Wed, 18 May 2022 at 10:52, Jason van Zyl  wrote:
> >
> > > I have used SLF4J and JSR330 in plugins for years without issue. They
> all
> > > still work and nothing has mysteriously stopped working even made 7+
> > years
> > > ago. I honestly don’t see much point in making our own annotations, and
> > > I’ve not encountered any of the issues Romain presents.
> > >
> > > To Romain’s points:
> > >
> > > 1. I don’t see it as an issue that two entirely different universes of
> > > classes don’t work 100% in the same classloader. Just fork and use a
> > > separate process as these two universes were never meant to actually
> run
> > in
> > > the same classloader. They don’t run that way in production so why
> would
> > > you try doing that during a build or testing.
> > >
> > > 2. I don’t think that’s an issue, if we wanted to augment what we do
> with
> > > another CI spec we can with Sisu. I think any of the standard CI
> > > specifications provide everything we might potentially need. We may not
> > use
> > > them now, but Sisu would allow us to use which ever spec we wished, in
> > > whatever combination we wish. Stuart, correct me if I’m wrong.
> > >
> >
> > Yes, supporting different annotations is one of the main features of
> Sisu -
> > it doesn't force you to export a particular API (the previous decision to
> > export JSR330 to plugins was because it was a standard, so it made it
> > easier to share injectable components between Maven and other ecosystems
> > without having to continually write adapters - but it's not a fundamental
> > requirement)
> >
> >
> > > 3. It’s been fine for how many years? Sisu is our defense here, it can
> > > look at annotation A or B and provide the same behavior for the user.
> I’m
> > > sure Stuart can show us how to get javax.inject and jakarta.inject
> > working
> > > simultaneously for a co-existence and/or transition. Again Stuart,
> > correct
> > > me if I’m wrong.
> > >
> >
> > There's an initial PR to add jakarta.inject support to Guice which people
> > are working on - once that's in the changes needed in Sisu are relatively
> > small.
> >
> >
> > > Jason
> > >
> > > > On May 16, 2022, at 1:14 PM, Slawomir Jaranowski <
> > s.jaranow...@gmail.com>
> > > wrote:
> > > >
> > > > But from other side we can use JSR-330 in Mojo [1]
> > > >
> > > > so we will:
> > > >
> > > >   @Parameter( defaultValue = "${project}", readonly = true, required
> =
> > > > true )
> > > >private MavenProject project;
> > > >
> > > >@Inject
> > > >public SuperMojo( Jsr330Component component )
> > > >{
> > > >}
> > > >
> > > > From code perspective will be clear
> > > >
> > > >@Inject
> > > >public SuperMojo( MavenProject project, Jsr330Component component
> )
> > > >{
> > > >}
> > > >
> > > >
> > > > [1] https://maven.apache.org/maven-jsr330.html
> > > >
> > > > pon., 16 maj 2022 o 18:42 Romain Manni-Bucau 
> > > > napisał(a):
> > > >
> > > >> Hi Sławomir,
> > > >>
> > > >> This i

Re: Maven plugins - injecting Maven components

[Stuart McCulloch]

I do wonder whether we're conflating the real issues of exposing the CDI
API (for @Typed) with the much smaller JSR330 API

Does anyone have a link to an issue that specifically involved exporting
the JSR330 API (I did a quick search but the threads I found were all about
the CDI API)
IIRC there was only one external plugin/extension that ever used @Typed, so
we could easily just stop exporting the CDI API while continuing to export
JSR330

(other comments inline below...)

On Wed, 18 May 2022 at 10:52, Jason van Zyl  wrote:

> I have used SLF4J and JSR330 in plugins for years without issue. They all
> still work and nothing has mysteriously stopped working even made 7+ years
> ago. I honestly don’t see much point in making our own annotations, and
> I’ve not encountered any of the issues Romain presents.
>
> To Romain’s points:
>
> 1. I don’t see it as an issue that two entirely different universes of
> classes don’t work 100% in the same classloader. Just fork and use a
> separate process as these two universes were never meant to actually run in
> the same classloader. They don’t run that way in production so why would
> you try doing that during a build or testing.
>
> 2. I don’t think that’s an issue, if we wanted to augment what we do with
> another CI spec we can with Sisu. I think any of the standard CI
> specifications provide everything we might potentially need. We may not use
> them now, but Sisu would allow us to use which ever spec we wished, in
> whatever combination we wish. Stuart, correct me if I’m wrong.
>

Yes, supporting different annotations is one of the main features of Sisu -
it doesn't force you to export a particular API (the previous decision to
export JSR330 to plugins was because it was a standard, so it made it
easier to share injectable components between Maven and other ecosystems
without having to continually write adapters - but it's not a fundamental
requirement)


> 3. It’s been fine for how many years? Sisu is our defense here, it can
> look at annotation A or B and provide the same behavior for the user. I’m
> sure Stuart can show us how to get javax.inject and jakarta.inject working
> simultaneously for a co-existence and/or transition. Again Stuart, correct
> me if I’m wrong.
>

There's an initial PR to add jakarta.inject support to Guice which people
are working on - once that's in the changes needed in Sisu are relatively
small.


> Jason
>
> > On May 16, 2022, at 1:14 PM, Slawomir Jaranowski 
> wrote:
> >
> > But from other side we can use JSR-330 in Mojo [1]
> >
> > so we will:
> >
> >   @Parameter( defaultValue = "${project}", readonly = true, required =
> > true )
> >private MavenProject project;
> >
> >@Inject
> >public SuperMojo( Jsr330Component component )
> >{
> >}
> >
> > From code perspective will be clear
> >
> >@Inject
> >public SuperMojo( MavenProject project, Jsr330Component component )
> >{
> >}
> >
> >
> > [1] https://maven.apache.org/maven-jsr330.html
> >
> > pon., 16 maj 2022 o 18:42 Romain Manni-Bucau 
> > napisał(a):
> >
> >> Hi Sławomir,
> >>
> >> This is a complex topic, basically there is a will to get a real IoC for
> >> maven-core and keep a maven specific API for plugin writers so I'm
> tempted
> >> to say option 1 for mojo.
> >>
> >> As a reminder the issues exposing @Inject are:
> >>
> >> 1. We can conflict with plugins (it is the case already and a lot of
> >> servers have to workaround that with custom classloaders)
> >> 2. We have no guarantee next version of @Inject will be compatible -
> there
> >> is a trend to break at jakarta EE
> >> 3. When we'll want to migrate to jakarta.inject (or another API) we'll
> >> break all consumers if it is used outside maven project itself
> >>
> >> Where this policy has its limitations is that extensions are now kind of
> >> "plugins" in the sense it should only use a public API but currently it
> has
> >> to use internal one (@Inject).
> >> So while I think option 1 is really the way to go, we probably have some
> >> work to extend it to extension mid-term and clean the API for maven 4.
> >>
> >> Hope it helps.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>
> >>
> >> Le lun. 16 mai 2022 à 18:13, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> >> a
> >> écrit :
> >>
> >>> Hi,
> >>>
> >>> We can inject Maven components into plugins in many ways ...
> >>>
> >>> We can use @Parameter, like:
> >>>
> >>>@Parameter( defaultValue = "${project}", readonly = true, required =
> >>> true )
> >>>private MavenProject project;
> >>>
> >>>@Parameter( defaultValue = "${session}", readonly = true, required =
> >>> true )
> 

Re: @Parameter on a NIO Path

[Stuart McCulloch]

The converter should be straightforward - it can either be done in the
Maven codebase or Sisu because the classpath scanning will pick it up
regardless.

I'll post an example next week. (Don't have access to my laptop at the
moment.)

I've also been planning a new Sisu release, so if we can sort this out soon
then it can go into that release.

On Sat, 29 May 2021, 18:07 Gary Gregory,  wrote:

> I don't really care about this or that superclass-shim-widget-whatever, i
> just want to use a Path for a parameter. So what is the recommendation?
>
> Gary
>
> On Sat, May 29, 2021, 12:36 Tamás Cservenák  wrote:
>
> > Howdy,
> >
> > Something is wrong here...
> > You want to _extend_ sisu-plexus-shim, codebase that is here to buy out
> > (functionally) old Plexus Containers? The one meant to be a drop-in
> > replacement for legacy Plexus containers? Given we have STILL mixed use
> of
> > sisu-plexus-shim and "original" plexus-container, having them "drift
> away"
> > from each other is just opening a big door for problems.
> >
> > If not proactively working on Plexus Container removal (so not
> proactively
> > moving to JSR330), then at least keep that code _frozen_, as
> > investing/extending shim-legacy codebase (sisu-plexus) meant to be
> removed
> > is something I cannot understand,
> >
> > I'd rather look into hooking in Guice TypeConverter SPI than using Plexus
> > oldie AbstractBasicConverter (that servers as superclass of mentioned
> > FileConverter)
> >
> > Ultimately, what's wrong with making that parameter a String and invoke
> > Paths.get(string) with it?
> >
> > We should be by now in blue box, while to me it seems we keep insisting
> > (and extending) red box:
> > https://imgur.com/a/sc3rwPK
> >
> > Re Sisu project: it is healthy and all fine, thanks, 1.0 planned release
> is
> > soon to come. But given Plexus Shim (shim!) is in place as "compatibility
> > layer", there is not much sense in investing into it, it played it's
> role,
> > it bought out p-c-d for all these years, but it's role is NOT to become
> > yet-another p-c-d instead of p-c-d.
> >
> > Thanks
> > T
> >
> > On Sat, May 29, 2021 at 5:03 PM Robert Scholte 
> > wrote:
> >
> > > Someone needs to implement #563525[1]
> > > I've had the confirmation that increasing source/target of Java makes
> > > sense.
> > >
> > >
> > > thanks,
> > > Robert
> > >
> > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=563525
> > > On 29-5-2021 16:07:50, Gary Gregory  wrote:
> > > Hi All,
> > >
> > > How do I use a @Parameter on a NIO Path?
> > >
> > > I don't a place to plugin a factory of some kind.
> > >
> > > TY,
> > >
> > > Gary
> > >
> >
>

Re: maven-site-plugin and sisu-inject-plexus

[Stuart McCulloch]

On Sat, 17 Apr 2021 at 13:47, Elliotte Rusty Harold 
wrote:

> I'd certainly prefer to use a fully supported, maintained, and
> documented framework instead of Plexus. So about Sisu:
>

Sisu is basically a few modules installed on top of Guice to make it more
dynamic, plus a thin compatibility layer that provides the Plexus API

Maven has used Sisu (and Guice) since version 3 - the general idea was to
allow plugins to use standard annotations (like JSR330 @Inject) while still
supporting legacy plugins.


> Where is it documented?
>

The main project site is https://www.eclipse.org/sisu/

The doc most useful for Maven developers is
http://wiki.eclipse.org/Sisu/PlexusMigration

There's more detail in the javadoc:
https://www.eclipse.org/sisu/docs/api/org.eclipse.sisu.inject/reference/packages.html
https://www.eclipse.org/sisu/docs/api/org.eclipse.sisu.plexus/reference/packages.html


> Is it under active development?
>

Yes - contributions are also welcome.


> When will 1.0 be released?
>

This year, if everything goes to plan.


> Which projects besides Maven use it?
>

Various Sonatype projects, including Nexus.


> On Sat, Apr 17, 2021 at 12:29 PM Tamás Cservenák 
> wrote:
> >
> > To be clear, am talking about this artifact (sisu plexus shim):
> >
> https://repo1.maven.org/maven2/org/eclipse/sisu/org.eclipse.sisu.plexus/0.3.4/
> >
> > Whenever you see plexus-container-default, you SHOULD replace it with
> this
> > above (or better yet, convert to plain sisu).
> >
> > T
> >
> > On Sat, Apr 17, 2021, 14:25 Tamás Cservenák  wrote:
> >
> > > Plexus-container-default is NOT (and SHOULD NOT) be used anywhere, but
> the
> > > drop in sisu-plexus drop replacement should be used instead.
> > >
> > > If we use p-c-d anywhere (even in UTs), that's bad, as maven uses s-p
> > > instead.
> > >
> > > p-c-d is not used in maven for sure.
> > >
> > > T
> > >
> > > On Sat, Apr 17, 2021, 14:02 Elliotte Rusty Harold 
> > > wrote:
> > >
> > >> plexus-container-default is used by Maven shared utils and thus by
> > >> almost everything in Maven. Not that this is a good thing, but c'est
> > >> la vie.
> > >>
> > >> There's a lot of over-engineered, unnecessary code splitting between
> > >> Maven, Aether, Plexus, and Modello. Maven's a pretty classic example
> > >> of why developers should resist the urge to build yet another
> > >> framework. Code maintenance and development would be far simpler and
> > >> less expensive today if 20 years ago the Maven developers had simply
> > >> written a build tool without trying to extend it to a general purpose
> > >> framework. YAGNI.
> > >>
> > >> On Tue, Feb 9, 2021 at 4:39 PM Tamás Cservenák 
> > >> wrote:
> > >> >
> > >> > Howdy,
> > >> >
> > >> > my 5 cents:
> > >> >
> > >> > Something is stale, very stale in there, as
> plexus-container-default was
> > >> > abandoned about 10 (maybe 12?) years ago, and sisu "shim"
> > >> > (sisu-inject-plexus) was created as the direct replacement (as
> > >> functional
> > >> > and as API).
> > >> >
> > >> > If your project has Plexus "the old container"
> > >> (plexus-container-default)
> > >> > pulled in, it means something on project or it's transitive
> dependency
> > >> hull
> > >> > lags for about 10+ years if not more :)
> > >> >
> > >> > Given Plexus is "maven only" (mostly), it is most probably that some
> > >> > dependency (governed by us, chance is 90%+) pulls it in, that has
> not
> > >> been
> > >> > touched for quite a long time.
> > >> >
> > >> > Plexus et al is one of the reasons why "maven pulls down the
> internet",
> > >> > especially as we resolve/download it only to toss it away (drop it).
> > >> >
> > >> > HTH
> > >> > T
> > >> >
> > >> > On Tue, Feb 9, 2021 at 5:13 PM Slawomir Jaranowski <
> > >> s.jaranow...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Project used class like org.codehaus.plexus.PlexusContainer
> > >> > >
> > >> > > We can remove direct dependency because we have transitive
> dependency
> > >> > > from other artifacts - of course we needn't remove it.
> > >> > >
> > >> > > [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
> > >> > > maven-site-plugin ---
> > >> > > [WARNING] Using Maven 2 dependency tree to get verbose output,
> which
> > >> may be
> > >> > > inconsistent with actual Maven 3 resolution
> > >> > > [INFO]
> > >> > >
> > >>
> org.apache.maven.plugins:maven-site-plugin:maven-plugin:3.10.0-SNAPSHOT
> > >> > > [INFO] +- org.apache.maven:maven-compat:jar:3.0.5:provided
> > >> > > [INFO] |  \-
> (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
> > >> > > scope updated from provided; omitted for duplicate)
> > >> > > [INFO] +- org.apache.maven:maven-core:jar:3.0.5:compile
> > >> > > [INFO] |  \-
> (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
> > >> > > omitted for conflict with 1.4.2)
> > >> > > [INFO] +- org.apache.maven:maven-plugin-api:jar:3.0.5:compile
> > >> > > [INFO] |  \-
> (org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:compile -
> > >> > > omitted for 

Re: JSR330 in extensions and plugins, Singleton or not Singleton

[Stuart McCulloch]

Here's a quick patch that does the split:
https://gist.github.com/mcculls/d22f01b0e380fdd9f9e2ac1e1bba7dd0

With these changes I get the following output:

mvn validate
[INFO] extension generated information: Build started at 1612479700634
[INFO] Scanning for projects...
[INFO]
[INFO]

[INFO] Building maven demo 0
[INFO]

[INFO]
[INFO] --- maven-demo-mojo:0:info (demo) @ maven-demo ---
[INFO] Information: Build started at 1612479700634
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 0.108 s
[INFO] Finished at: 2021-02-04T23:01:40Z
[INFO] Final Memory: 9M/309M
[INFO]



On Thu, 4 Feb 2021 at 22:46, Stuart McCulloch  wrote:

> Yes it's down to classloading - the extension and plugin have different
> classloaders and the InfoHolder class loaded by the extension is different
> to the one loaded by the plugin. They may share the same name and have the
> same original bytecode, but they were defined by different classloaders.
> You can see this by adding a constructor to InfoHolder and printing out its
> classloader (you can also print the class' hashcode to show it really is a
> different class, just with the same name.)
>
> To share the extension class with the plugin you'll need to add an
> extension descriptor to the jar:
>
>https://maven.apache.org/ref/3.6.0/maven-core/extension.html
>
> But you'll also need to solve a second issue which comes down to the fact
> you're using the same jar as an extension and a plugin - the component
> metadata is going to be registered in both places, which will still lead to
> two separate copies (each component will be a singleton in its own 'realm'
> governed by the component metadata.)
>
> I would recommend using two separate projects - one for the extension and
> one for the plugin. The extension project will have the component and
> the extension descriptor, while the plugin project will just have the mojo
> and depend on the extension project.
>
>
> On Thu, 4 Feb 2021 at 20:40, Matthieu Brouillard 
> wrote:
>
>> Hum some words have disappeared from my previous mail.
>> The project URL is https://github.com/McFoggy/maven-jsr330-demo
>> <https://github.com/McFoggy/maven-jsr330-demoYou>.
>> And the corrected sentence is: You will see that the project is simple...
>> Sorry for the double post.
>>
>>
>> On Thu, Feb 4, 2021 at 9:27 PM Matthieu Brouillard <
>> matth...@brouillard.fr>
>> wrote:
>>
>> > Hi all,
>> >
>> > As I was trying to cleanup & simplify my plugins by moving to JSR330, I
>> > came across a weird use case in which a `@Singleton` object exists
>> multiple
>> > times (several instances) during the build:
>> > - it is first used by an extension, to store some value
>> > - then used in a mojo to retrieve and print the value
>> >
>> > Before opening an issue, I wanted to be sure that I did not make some
>> > errors in the simplified project and that my expectations of how it
>> should
>> > work are OK.
>> >
>> > I pushed a simplified project with README here:
>> > https://github.com/McFoggy/maven-jsr330-demoYou will that the project
>> is
>> > simple:
>> > - the @Singleton information store
>> > - the extension filling the store
>> > - the mojo
>> >
>> > Thanks for any enlightenment.
>> >
>> > PS: can the issue come from different classloaders being probably used?
>> >
>> > Matthieu
>> >
>>
>

Re: JSR330 in extensions and plugins, Singleton or not Singleton

[Stuart McCulloch]

Yes it's down to classloading - the extension and plugin have different
classloaders and the InfoHolder class loaded by the extension is different
to the one loaded by the plugin. They may share the same name and have the
same original bytecode, but they were defined by different classloaders.
You can see this by adding a constructor to InfoHolder and printing out its
classloader (you can also print the class' hashcode to show it really is a
different class, just with the same name.)

To share the extension class with the plugin you'll need to add an
extension descriptor to the jar:

   https://maven.apache.org/ref/3.6.0/maven-core/extension.html

But you'll also need to solve a second issue which comes down to the fact
you're using the same jar as an extension and a plugin - the component
metadata is going to be registered in both places, which will still lead to
two separate copies (each component will be a singleton in its own 'realm'
governed by the component metadata.)

I would recommend using two separate projects - one for the extension and
one for the plugin. The extension project will have the component and
the extension descriptor, while the plugin project will just have the mojo
and depend on the extension project.


On Thu, 4 Feb 2021 at 20:40, Matthieu Brouillard 
wrote:

> Hum some words have disappeared from my previous mail.
> The project URL is https://github.com/McFoggy/maven-jsr330-demo
> .
> And the corrected sentence is: You will see that the project is simple...
> Sorry for the double post.
>
>
> On Thu, Feb 4, 2021 at 9:27 PM Matthieu Brouillard  >
> wrote:
>
> > Hi all,
> >
> > As I was trying to cleanup & simplify my plugins by moving to JSR330, I
> > came across a weird use case in which a `@Singleton` object exists
> multiple
> > times (several instances) during the build:
> > - it is first used by an extension, to store some value
> > - then used in a mojo to retrieve and print the value
> >
> > Before opening an issue, I wanted to be sure that I did not make some
> > errors in the simplified project and that my expectations of how it
> should
> > work are OK.
> >
> > I pushed a simplified project with README here:
> > https://github.com/McFoggy/maven-jsr330-demoYou will that the project is
> > simple:
> > - the @Singleton information store
> > - the extension filling the store
> > - the mojo
> >
> > Thanks for any enlightenment.
> >
> > PS: can the issue come from different classloaders being probably used?
> >
> > Matthieu
> >
>

Re: Where is the actual compiler for Maven

[Stuart McCulloch]

https://github.com/codehaus-plexus/plexus-compiler/tree/master/plexus-compilers
is the current location I believe

On Mon, 13 Jul 2020 at 21:25, Ian Lavallee  wrote:

> Hi all,
>
> I am trying to make changes to the actual compiler for Maven so I can
> notify the user when they have runtime dependencies scoped as compile from
> maven-dependency-analyzer. I've looked at the maven-compiler plugin but the
> only actual compilers I can find are in sonatype-plexus-compiler
>  which hasn't had a commit in
> 5 years. Is this still what Maven uses? If not can someone direct me where
> to look?
>
> Thanks,
> Ian
>

Re: Question Guice provision errors

[Stuart McCulloch]

Can't recreate it locally, but that error would only occur if it couldn't
load the default implementation defined for that interface
(DefaultCheckstyleExecutor)

You could try using -Dorg.sonatype.inject.debug=true to dump out detailed
logs of what it's trying to bind (this is an old flag specific to the
library that shipped with 3.0.5)

What version of Java are you using?  Also have you checked that the jars in
your local repo are not corrupt and contain the expected classes?

On Sat, 4 Apr 2020 at 18:35, Karl Heinz Marbaise  wrote:

> Hi, currently I'm stumbling over the following issue:
>
> Running Maven 3.0.5 and following plugin (also had that with other
> plugins)...
>
> Can someone give me a hint what cause this kind of issue:
>
>
> INFO] --- maven-checkstyle-plugin:3.0.0:check (checkstyle-check) @
> maven-project-installer-project-it ---
> Apr 04, 2020 7:30:21 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
> WARNING: Error injecting:
> org.apache.maven.plugins.checkstyle.CheckstyleViolationCheckMojo
> com.google.inject.ProvisionException: Guice provision errors:
>
> 1) No implementation for
> org.apache.maven.plugins.checkstyle.exec.CheckstyleExecutor was bound.
>while locating
> org.apache.maven.plugins.checkstyle.CheckstyleViolationCheckMojo
>
> 1 error
> at
> com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
> at
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1000)
> at
>
> org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:45)
> at
>
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:84)
> at
>
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:52)
> at
>
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> at
>
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> at
>
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:138)
> 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(ProviderInterna
>
> Also observed that with maven-remote-resources-plugin:1.7.0...
>
>
>
> Kind regards
> Karl-Heinz Marbaise
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Regression in model interpolation coming from using JSR-330?

[Stuart McCulloch]

@Named is the same as marking a component in Plexus and giving it a hint -
and just as you can have components with explicit hints/names, you can also
have components without an explicit name. If you don't choose an explicit
name then it will use the fully-qualified class as the name.

As for having multiple implementations and how they are selected - as Hervé
mentioned before, this is the stock behaviour that Maven was built on (the
semantics originated in Plexus and have been carried over as the runtime
has evolved) and it's this that allows plugins/extensions to adapt and
extend Maven.

On Thu, 7 Nov 2019 at 09:45, Tibor Digana  wrote:

> Question.
> Why we used @Named? I was talking about it in before that the names must
> not be the same but i do not understand why we use @Named since there is no
> benefit from expression language in Maven where the name of bean is only
> useful as a reference to the bean.
> Additionally, two beans having @Named @Singleton implementing the same
> interface is a strange combination. Even if somebody wants to inject the
> interface it will be the same problem. And the same with names.
>
> On Thu, Nov 7, 2019 at 4:48 AM Stuart McCulloch  wrote:
>
> > The index generator is very simple and just indexes named classes, which
> > makes it very fast with negligible impact on the build.
> >
> > To spot this kind of ambiguity at generation time would require a deep
> > analysis of the type hierarchy and caching of those hierarchies to check
> > for overlaps.
> >
> > This would quickly become messy (especially for the case where we're
> > indexing via an annotation processor) compared to checking at runtime.
> >
> > Also in some ways this is better handled by application ITs. The
> container
> > doesn't really have enough context to definitively say "this is wrong"
> > because it could be that the developer intended to have multiple
> > implementations and plans to have them all injected into a list. It could
> > also be that two implementations happen to share the same superclass or
> > interface which would make them ambiguous if someone asked for an
> > implementation at that particular type level, but in reality they are
> only
> > ever injected as different sub-types where there is no ambiguity.
> >
> > Compare this to checking at the application level: when adding a
> > replacement component you'd just need an IT confirming that new component
> > is being used. Most of the time the replacement is there to fix a bug, so
> > you'd expect regression tests to catch if it wasn't used. Other reasons
> to
> > rewrite or replace a component are performance related, in which case you
> > might also expect a performance related IT to verify the new
> implementation
> > is having an effect.
> >
> > On Thu, 7 Nov 2019 at 03:08, Gabriel Belingueres 
> > wrote:
> >
> > > @Hervé: The patch worked fine. Thanks!
> > >
> > > @Stuart: In the light that the model interpolator was the only case
> > found,
> > > that is, both equally qualifying classes were located inside the same
> > > javax.injected.Named file, I wonder if it would be easier to check for
> > > ambiguities at generation time, in the sisu-maven-plugin (adding an
> > > optional parameter to fail the build if this kind of case is found).
> > WDYT?
> > >
> > > Regards,
> > > Gabriel
> > >
> > >
> > > El mié., 6 de nov. de 2019 a la(s) 13:39, Herve Boutemy (
> > > hbout...@apache.org)
> > > escribió:
> > >
> > > > MNG-6799 issue created [1]
> > > > proposed fix added to the reproducible branch [2] by simply removing
> > the
> > > > @Named annotation for the deprecated StringSearchModelInterpolator:
> CI
> > > > seems ok
> > > > ok for merge?
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > [1] https://issues.apache.org/jira/browse/MNG-6799
> > > >
> > > > [2]
> > > >
> > >
> >
> https://github.com/apache/maven/commit/16961b32b7dccbc9447ed4e18b4e0949d5fe3b56
> > > >
> > > > On 2019/11/03 21:27:21, Stuart McCulloch  wrote:
> > > > > I did a quick review of the various components in core
> > > > > and StringVisitorModelInterpolator / StringSearchModelInterpolator
> > > > appears
> > > > > to be the only case where a role (ModelInterpolator) has two
> > > non-default
> > > > > implementations and another component on

Re: Regression in model interpolation coming from using JSR-330?

[Stuart McCulloch]

The index generator is very simple and just indexes named classes, which
makes it very fast with negligible impact on the build.

To spot this kind of ambiguity at generation time would require a deep
analysis of the type hierarchy and caching of those hierarchies to check
for overlaps.

This would quickly become messy (especially for the case where we're
indexing via an annotation processor) compared to checking at runtime.

Also in some ways this is better handled by application ITs. The container
doesn't really have enough context to definitively say "this is wrong"
because it could be that the developer intended to have multiple
implementations and plans to have them all injected into a list. It could
also be that two implementations happen to share the same superclass or
interface which would make them ambiguous if someone asked for an
implementation at that particular type level, but in reality they are only
ever injected as different sub-types where there is no ambiguity.

Compare this to checking at the application level: when adding a
replacement component you'd just need an IT confirming that new component
is being used. Most of the time the replacement is there to fix a bug, so
you'd expect regression tests to catch if it wasn't used. Other reasons to
rewrite or replace a component are performance related, in which case you
might also expect a performance related IT to verify the new implementation
is having an effect.

On Thu, 7 Nov 2019 at 03:08, Gabriel Belingueres 
wrote:

> @Hervé: The patch worked fine. Thanks!
>
> @Stuart: In the light that the model interpolator was the only case found,
> that is, both equally qualifying classes were located inside the same
> javax.injected.Named file, I wonder if it would be easier to check for
> ambiguities at generation time, in the sisu-maven-plugin (adding an
> optional parameter to fail the build if this kind of case is found). WDYT?
>
> Regards,
> Gabriel
>
>
> El mié., 6 de nov. de 2019 a la(s) 13:39, Herve Boutemy (
> hbout...@apache.org)
> escribió:
>
> > MNG-6799 issue created [1]
> > proposed fix added to the reproducible branch [2] by simply removing the
> > @Named annotation for the deprecated StringSearchModelInterpolator: CI
> > seems ok
> > ok for merge?
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://issues.apache.org/jira/browse/MNG-6799
> >
> > [2]
> >
> https://github.com/apache/maven/commit/16961b32b7dccbc9447ed4e18b4e0949d5fe3b56
> >
> > On 2019/11/03 21:27:21, Stuart McCulloch  wrote:
> > > I did a quick review of the various components in core
> > > and StringVisitorModelInterpolator / StringSearchModelInterpolator
> > appears
> > > to be the only case where a role (ModelInterpolator) has two
> non-default
> > > implementations and another component only asks for the first
> > > implementation. There are other roles which have multiple
> > implementations,
> > > but in those cases that's expected because each implementation has a
> > > specific name and handles a specific case (see the various
> > ProfileActivator
> > > implementations which are all then injected into a list in
> > > DefaultProfileSelector.)
> > >
> > > It also appears that StringVisitorModelInterpolator was only added
> > recently
> > > - if it's meant to be a replacement of StringSearchModelInterpolator
> then
> > > one option would be to simply remove StringSearchModelInterpolator.
> > > Alternatively if StringSearchModelInterpolator is needed to be kept
> > around
> > > for compatibility reasons (such as someone directly extending it
> outside
> > of
> > > Maven) then the Named annotation could be removed
> > > from StringSearchModelInterpolator so it isn't automatically picked up.
> > >
> > > Wrt. extra checks, checking for multiple implementations in the same
> > > realm/classloader that haven't been given specific names is a
> > possibility -
> > > you can open feature requests at
> > > https://bugs.eclipse.org/bugs/describecomponents.cgi?product=Sisu
> > >
> > > On Sun, 3 Nov 2019 at 19:05, Gabriel Belingueres <
> belingue...@gmail.com>
> > > wrote:
> > >
> > > > Hi Hervé:
> > > >
> > > > I was thinking in the lines of some checking at the maven core level
> > only,
> > > > enough to detect problems and ensure there are no regressions.
> > > >
> > > > At the plugin level, I guess the assurance that the right component
> is
> > > > injected can be checked with an integration test.
> > > >
> > &

Re: Regression in model interpolation coming from using JSR-330?

[Stuart McCulloch]

I did a quick review of the various components in core
and StringVisitorModelInterpolator / StringSearchModelInterpolator appears
to be the only case where a role (ModelInterpolator) has two non-default
implementations and another component only asks for the first
implementation. There are other roles which have multiple implementations,
but in those cases that's expected because each implementation has a
specific name and handles a specific case (see the various ProfileActivator
implementations which are all then injected into a list in
DefaultProfileSelector.)

It also appears that StringVisitorModelInterpolator was only added recently
- if it's meant to be a replacement of StringSearchModelInterpolator then
one option would be to simply remove StringSearchModelInterpolator.
Alternatively if StringSearchModelInterpolator is needed to be kept around
for compatibility reasons (such as someone directly extending it outside of
Maven) then the Named annotation could be removed
from StringSearchModelInterpolator so it isn't automatically picked up.

Wrt. extra checks, checking for multiple implementations in the same
realm/classloader that haven't been given specific names is a possibility -
you can open feature requests at
https://bugs.eclipse.org/bugs/describecomponents.cgi?product=Sisu

On Sun, 3 Nov 2019 at 19:05, Gabriel Belingueres 
wrote:

> Hi Hervé:
>
> I was thinking in the lines of some checking at the maven core level only,
> enough to detect problems and ensure there are no regressions.
>
> At the plugin level, I guess the assurance that the right component is
> injected can be checked with an integration test.
>
> The way I realized the problem was that I was adding some logging traces
> into the StringVisitorModelInterpolator class but *nothing* showed (even
> the build was successful and the interpolation indeed was happening
> somewhere). Then added the same logging lines to
> StringSearchModelInterpolator, and the logging appeared in the build, which
> confirmed the issue. (I didn't test if there are any other component with
> the same problem.)
>
> El dom., 3 de nov. de 2019 a la(s) 06:27, Hervé BOUTEMY (
> herve.bout...@free.fr) escribió:
>
> > nice idea, but overriding by adding a new implementation in classpath is
> > the
> > normal overriding way: not sure how "ambiguity checker" could make a
> > difference
> > between such wanted override vs unwanted ambiguity
> >
> > BTW, how did you see that StringVisitorModelInterpolator was not used but
> > StringSearchModelInterpolator instead, please?
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 3 novembre 2019, 05:30:50 CET Gabriel Belingueres a écrit :
> > > Thanks Stuart.
> > >
> > > The reproducibility PR you mention helps in having a deterministic
> > ordering
> > > inside the Named components file to buld exactly the same executable,
> but
> > > it does not mean it is the right priority for component injection.
> > >
> > > Do you know if it is possible to configure sisu to throw an exception
> if
> > > trying to inject an ambiguous component? Otherwise, I guess we must
> > > implement some sort of "ambiguity checker", either as an integration
> test
> > > (don't know if it is possible) or either built-it into maven
> executable.
> > >
> > >
> > >
> > >
> > > El sáb., 2 de nov. de 2019 a la(s) 20:54, Stuart McCulloch (
> > >
> > > mccu...@gmail.com) escribió:
> > > > Yes, when there are multiple non-default implementations with the
> same
> > > > priority then it will pick the first in the list (where the "list" in
> > > > question is actually a combination of plugins + extensions + core
> > > > bindings for the given type)
> > > >
> > > > If a particular implementation should be treated as the default then
> it
> > > > should either start with "Default" or be annotated with
> > @Named("default")
> > > > -
> > > > the benefit of this approach is that it documents that this is the
> > default
> > > > implementation, to be favoured over the others. Alternatively if you
> > want
> > > > to have an ordering between implementations then you can use
> @Priority
> > to
> > > > assign specific priorities and favour one over the other.
> > > >
> > > > If you don't mark an implementation as default and don't define any
> > > > priorities then the only current guarantees are that implementations
> in
> > > > plugins and extensions will be favoured over impleme

Re: Regression in model interpolation coming from using JSR-330?

[Stuart McCulloch]

As Hervé noted, much of this is the way Maven (and Plexus) has always
behaved - the core defines component roles that plugins/extensions can
implement. There will typically be a core implementation (sometimes named
as the default, but not always) but that implementation can be
overridden by implementations in plugins/extensions so people can extend
and augment Maven. Sometimes the consumer of a component role wants to see
all implementations and will inject a list or a map (keyed by name) - for
example handlers of different archive types where you might ship a stock
set of handlers, but want to allow plugins to add handlers for other
archive types.

So there has always been multiple implementations of a given component
role, and an ordering to decide which one to return when someone asks for
just one implementation of that role (compared to asking for a list or a
map). Historically Plexus always gave implementations in plugins/extensions
a slightly higher priority than core - and "newer" plugins in terms of when
they were added to the runtime build a slightly higher priority than
"older" plugins. The ordering of implementations inside a given realm or
classloader followed the "classpath" ordering of the jars, while the
ordering of implementations inside a jar followed their order in the Plexus
XML descriptor.

Almost 10 years ago Maven switched from the old Plexus container to a new
shim built on top of Guice that supports the same Plexus API and behaviour.
In other words, the same ranking between core and plugin/extension
implementations and the same classpath/descriptor ordering for
implementations in the same classloader/jar. When moving from Plexus
annotations to JSR330 annotations the same behaviour was applied to the
order of implementations in the javax.injected.Named descriptor (which is
in some ways a replacement for Plexus' components.xml.) The code and
behaviour to manage all this has been there for a while since the shim
manages both sets of annotations and maps them to Guice bindings, it's only
recently that selected parts of Maven have been switching from Plexus
annotations to JSR330 annotations.

This is why the ordering in the javax.injected.Named descriptor makes a
difference in terms of multiple implementations in the same jar - it's
following the same historical ordering that Plexus would apply to
implementations in components.xml. The difference is that
the javax.injected.Named descriptor is typically built as the code is
compiled by using an annotation processor, rather than as a separate
packaging step (although that can be configured when it makes sense such as
generating an uber-index for a collection of archives.) The use of
an annotation processor means that differences in the order that javac
compiles the classes can currently affect the order of them in the
descriptor. A lot of the time that ordering doesn't change, especially when
you're using the same OS and version of java, but to make sure we get
completely reproducible builds Hervé has proposed a stricter ordering on
the javax.injected.Named descriptor.

On Sun, 3 Nov 2019 at 04:31, Gabriel Belingueres 
wrote:

> Thanks Stuart.
>
> The reproducibility PR you mention helps in having a deterministic ordering
> inside the Named components file to buld exactly the same executable, but
> it does not mean it is the right priority for component injection.
>
> Do you know if it is possible to configure sisu to throw an exception if
> trying to inject an ambiguous component? Otherwise, I guess we must
> implement some sort of "ambiguity checker", either as an integration test
> (don't know if it is possible) or either built-it into maven executable.
>
>
>
>
> El sáb., 2 de nov. de 2019 a la(s) 20:54, Stuart McCulloch (
> mccu...@gmail.com) escribió:
>
> > Yes, when there are multiple non-default implementations with the same
> > priority then it will pick the first in the list (where the "list" in
> > question is actually a combination of plugins + extensions + core
> > bindings for the given type)
> >
> > If a particular implementation should be treated as the default then it
> > should either start with "Default" or be annotated with
> @Named("default") -
> > the benefit of this approach is that it documents that this is the
> default
> > implementation, to be favoured over the others. Alternatively if you want
> > to have an ordering between implementations then you can use @Priority to
> > assign specific priorities and favour one over the other.
> >
> > If you don't mark an implementation as default and don't define any
> > priorities then the only current guarantees are that implementations in
> > plugins and extensions will be favoured over implementations in core (to
> > allow overriding). But there is an

Re: Regression in model interpolation coming from using JSR-330?

[Stuart McCulloch]

Yes, when there are multiple non-default implementations with the same
priority then it will pick the first in the list (where the "list" in
question is actually a combination of plugins + extensions + core
bindings for the given type)

If a particular implementation should be treated as the default then it
should either start with "Default" or be annotated with @Named("default") -
the benefit of this approach is that it documents that this is the default
implementation, to be favoured over the others. Alternatively if you want
to have an ordering between implementations then you can use @Priority to
assign specific priorities and favour one over the other.

If you don't mark an implementation as default and don't define any
priorities then the only current guarantees are that implementations in
plugins and extensions will be favoured over implementations in core (to
allow overriding). But there is an upcoming improvement to sort the list
inside each module that would make this more deterministic from build to
build, at least when ranking implementations inside a particular module:
https://github.com/eclipse/sisu.inject/pull/5 - with that change then
you'll get an extra guarantee that inside a module it will be ordered by
package+name.

PS. even with the old Plexus runtime annotations you could be at the whim
of classpath ordering, similarly Plexus XML descriptors are influenced by
classpath resource ordering - so ideally it's better to be explicit about
ordering

On Sat, 2 Nov 2019 at 23:07, Gabriel Belingueres 
wrote:

> Hi:
>
> I just built maven core from source and found that it was using
> StringSearchModelInterpolator instead of StringVisitorModelInterpolator, a
> regression from the last 3.6.2 release.
>
> I found that in maven-model-builder/META-INF/sisu/javax.injected.Named
> file, both interpolators are listed but in reverse order (comparing it with
> the same file in 3.6.2), that is StringSearchModelInterpolator appear first
> in the file and StringVisitorModelInterpolator second.
>
> (I believe the dependency injection picks up the first one it finds with
> the right type.)
>
> Deleting the @Named annotation from StringSearchModelInterpolator solved
> the issue, as this make the entry disappear from the javax.injected.Named
> file. Then the dependency injection uses the
> StringVisitorModelInterpolator.
>
> Can anyone confirm this issue?
> And if so, how to best prevent in the future that this type of dependency
> injection regressions from happening?
>
> Kind regards,
> Gabriel
>

Re: Second MNG-6765 ([Regression] tycho pom-less builds fails with 3.6.2)

[Stuart McCulloch]

@Named is not specific to Java EE, it's from JSR 330 which actually targets
Java SE (and there are many SE based containers that support it)

All @Named does is give a component an identity in the container (think
of @Named like the hint in Plexus [1]) so it can be referenced by that name
elsewhere. It also means you can inject lists or maps, where the key is the
name, of all component implementations for a given type. This lets plugins
and extensions contribute implementations of a core type and core can then
see them and choose the right one for the job (such as "file" for a file
specific implementation.)

Maven historically also supports overriding of components by plugins and
extensions, where if you have a component with the same interface (role)
and name (hint) then it can override the core component while that plugin
is active. This lets plugins customize certain core behaviour in a
controlled manner. If we didn't allow overriding then a lot of plugins
would fail and Maven would be a lot less flexible.

[1] https://wiki.eclipse.org/Sisu/PlexusMigration

On Sat, 19 Oct 2019 at 11:58, Tibor Digana  wrote:

> Are you talking about
> @Named( “not-default” )
> @Named( “coreAllowingOverride” ) or @Named( “coreExtensionPoint” )?
>
> In Java EE (and these annotations are from Java EE application servers)
> mean the name of the bean which is unique - it is not a group of beans.
> Please notice that beans container is Map simply speaking.
> and therefore here it would mean :
>
> "core-default" -> singleton instance (DefaultModelProcessor@1234567)
>
> so this means a conflict because you cannot create:
>
> "core-default" -> singleton instance (DefaultModelProcessor@1234567)
> "core-default" -> singleton instance (DefaultResolver@1234567)
> "core-default" -> singleton instance (AnotherBeanType@1234567)
>
> logical would be to have Expression API from Java EE and:
>
> "core-default-modelprocessor" -> singleton instance
> (DefaultModelProcessor@1234567)
> "core-default-resolver" -> singleton instance (DefaultResolver@1234567)
> "core-default-xxx" -> singleton instance (AnotherBeanType@1234567)
>
>
> On Sat, Oct 19, 2019 at 12:03 PM Hervé BOUTEMY 
> wrote:
>
> > +1
> > just added a comment on a typo
> >
> > for the name of the component, perhaps "core-default", but I won't
> > complain
> > about any choice: the javadoc is what was really needed
> >
> > notice: perhaps we have other component that should have the same
> > improvement
> > to permit overriding in the future
> >
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 18 octobre 2019, 20:04:53 CEST Robert Scholte a écrit :
> > > Hi,
> > >
> > > with the help from Stuart McCulloch we've been able to provide a patch
> > for
> > > MNG-6765[1]
> > > Please review and test.
> > >
> > > thanks,
> > > Robert
> > >
> > > [1] https://issues.apache.org/jira/browse/MNG-6765
> > > [2]
> > >
> >
> https://github.com/apache/maven/commit/24e6c0ec0a87b6682513287a23c36db6996b8
> > > 74c [3]
> > >
> >
> https://github.com/apache/maven/commit/53a70bc8543124569ee787725b2004bc92a68
> > > 1b6
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Second MNG-6765 ([Regression] tycho pom-less builds fails with 3.6.2)

[Stuart McCulloch]

OK, so this rabbit-hole is exactly what I wanted to avoid and which is why
I added a detailed description in the original patch (and not just the
annotation change)

To clarify:  plugins and extensions can already override any component,
because their baseline priority is always higher than maven core (this
mimics the same behaviour as Plexus as configured by Maven, but the
underlying approach can support different models and also allows individual
priorities per-component.)

So the patch was _not_ about allowing overriding in the general case, but
instead to fix a small corner-case where a default component uses @Typed
(which requests that it is directly bound to the given type) and another
component just @Injects that type without any qualification. I've pasted
the full explanation at the end of this email just to increase its
visibility.

In other words... if you don't use @Typed (which is almost every case) then
you can continue to use "default" or a blank name for default components
and any other name for non-default components.

The _only_ time you need to be careful is when you:

1)  start off with a default component which either uses @Named("default")
or uses @Named and the class is DefaultXYZ
and... 2)  decide to add @Typed to restrict what types a component is
visible as (ie. what it can be injected as)
and... 3) want to allow overriding of that component

when all 3 of those are true then you need to use another name such
as @Named("typed-default") to stop the container from taking the
short-circuit.

If anyone needs further details I'm happy to supply them, I just want to
make clear that this is a corner-case which shouldn't affect the current
recommendations around @Named when moving from Plexus (which is to just use
the hint) because the advice here really is only necessary when the above 3
conditions apply which is very rare.

8<---
 * Note: uses @Typed to limit the types it is available for injection to
just ModelProcessor.
 *
 * This is because the ModelProcessor interface extends ModelLocator and
ModelReader. If we
 * made this component available under all its interfaces then it could end
up being injected
 * into itself leading to a stack overflow.
 *
 * A side-effect of using @Typed is that it translates to explicit bindings
in the container.
 * So instead of binding the component under a 'wildcard' key it is now
bound with an explicit
 * key. Since this is a default component this will be a plain binding of
ModelProcessor to
 * this implementation type, ie. no hint/name.
 *
 * This leads to a second side-effect in that any @Inject request for just
ModelProcessor in
 * the same injector is immediately matched to this explicit binding, which
means extensions
 * cannot override this binding. This is because the lookup is always
short-circuited in this
 * specific situation (plain @Inject request, and plain explicit binding
for the same type.)
 *
 * The simplest solution is to use a custom @Named here so it isn't bound
under the plain key.
 * This is only necessary for default components using @Typed that want to
support overriding.
 *
 * As a non-default component this now gets a -ve priority relative to
other implementations
 * of the same interface. Since we want to allow overriding this doesn't
matter in this case.
 * (if it did we could add @Priority of 0 to match the priority given to
default components.)


On Sat, 19 Oct 2019 at 10:18, Robert Scholte  wrote:

> On Sat, 19 Oct 2019 02:25:47 +0200, Jason van Zyl  wrote:
>
> > Inline:
> >
> >  On Oct 18, 2019, at 5:15 PM, Stuart McCulloch 
> wrote:
> >>
> >> Any string apart from "default" or the empty string will work here - I
> >> happened to chose "core" because I viewed it as a core implementation.
> >>
> >> Also a quick reminder that this is only needed when a component uses
> >> @Typed
> >> and wants to allow overriding, it's not necessary in any other
> >> situation -
> >> so in that sense "allowDefaultOverride" wouldn't be quite accurate. (See
> >> the javadoc in the patch for more detail.)
> >>
> >
> > Stuart,
> >
> > There is an idiom like this used in the ReactorReader and the
> > GraphBuilder where there are implementations of them in extensions out
> > in the wild, and while those are not @Typed they use a @Named(
> > “not-default” ) key pattern. If these components are intended to allow
> > for custom implementations then a common way of doing this would be
> > easier to understand. Something like @Named( “coreAllowingOverride” )
> or
> > @Named( “coreExtensionPoint” ) or whatever most appropriate. Right now
> > there’s a bit of fiddly magic that works in Plexus with a lookup and
> > Plexus with its annotations, and slightly different way with S

Re: Second MNG-6765 ([Regression] tycho pom-less builds fails with 3.6.2)

[Stuart McCulloch]

Any string apart from "default" or the empty string will work here - I
happened to chose "core" because I viewed it as a core implementation.

Also a quick reminder that this is only needed when a component uses @Typed
and wants to allow overriding, it's not necessary in any other situation -
so in that sense "allowDefaultOverride" wouldn't be quite accurate. (See
the javadoc in the patch for more detail.)

PS. the reason DefaultModelProcessor needs to use @Typed is because it has
an "interesting" interface hierarchy where ModelProcessor extends
both ModelLocator and ModelReader, so it can act as both and delegate
accordingly - but then it also asks to have a ModelLocator and ModelReader
injected, which is where things get messy. If it had a cleaner hierarchy
(ie. it wasn't asking to inject something that it also implements) then it
wouldn't need @Typed and wouldn't then need the custom name.


On Fri, 18 Oct 2019 at 20:35, Robert Scholte  wrote:

> Hi,
>
> the adjusted @Named annotation is on DefaultModelProcessor, not
> DefaultModelBuilder.
> They both implement the ModelBuilder interface, but the one that
> extensions like to overwrite is the implementation of DefaultModelBuilder.
> So I'd prefer to stick to "core" as proposed my Stuart.
>
> thanks for the confirmation that this works,
> Robert
>
> On Fri, 18 Oct 2019 21:10:18 +0200, Jason van Zyl 
> wrote:
>
> > Hi,
> >
> > As noted in Slack I think it would be more clear if we used something
> > like
> >
> > @Named( “allowDefaultOverride” )
> >
> > vs
> >
> > @Named( “core” )
> >
> > As that expresses the intent and can be used anywhere it's allowed for
> a
> > client to override the default component.
> >
> > The tests in polyglot all pass with this change, and I’m able to run
> > polyglot example projects again, so I assume the Tycho POM-less are
> > happy again as well but hopefully someone can verify.
> >
> > Jason
> >
> >> On Oct 18, 2019, at 2:04 PM, Robert Scholte 
> >> wrote:
> >>
> >> Hi,
> >>
> >> with the help from Stuart McCulloch we've been able to provide a patch
> >> for MNG-6765[1]
> >> Please review and test.
> >>
> >> thanks,
> >> Robert
> >>
> >> [1] https://issues.apache.org/jira/browse/MNG-67
> >> [2]
> >>
> https://github.com/apache/maven/commit/24e6c0ec0a87b6682513287a23c36db6996b874c
> >> [3]
> >>
> https://github.com/apache/maven/commit/53a70bc8543124569ee787725b2004bc92a681b6
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: JSR250 in the lib

[Stuart McCulloch]

Sorry, but why would you want to write your own version of javax.inject
which is a very small static API supported by many injection systems, both
EE and non-EE

It means you can't inject components written outside of Maven unless you
write adapters or manually construct them.

It also means that someone who wants to write an injectable component for
Maven and re-use it elsewhere (such as with Spring) now needs to write two
versions.

You'll spend a lot of time and end up with duplicate APIs for doing exactly
the same thing, when you could have just bumped the JSR-250 version and
moved on.

On Mon, 14 Oct 2019 at 12:22, Tibor Digana  wrote:

> It would not be finally the same/identical list of annotations.
> We do not have to copy everything, as for instance we do not have to copy
> descriptive methods, names of annotations, packages.
> So custom annotations means that:
> + we have all responsibility in our hands
> + we do not have to rely on dead Java EE annotations
> + we can add new annottaions tailored to our Maven domain (not EE domain)
>
> We can erase some annotations, e.g.:
> 1. https://docs.oracle.com/javaee/6/api/javax/inject/Named.html - not sure
> if we use expressions with @Named beans
> instead maybe we meant something like @javax.annotation.ManagedBean but it
> is only my guess because @Named is useless without using expressions in the
> code (not in POM).
> 2. we can erase
> https://docs.oracle.com/javaee/6/api/javax/inject/Scope.html
> because we do not have e.g. HTTP Session, Conversation scope and Html
> forms, we do not have Request Sope because we have our own lifecycle with
> phases. So again not very compatible with Maven domain. Usually we have
> singletones and I have never seen scope of liveness of the bean instances
> in Maven. Maybe we would need to have a range of phases in the future where
> the bean would be valid (from compile to process-classes) even in the
> parallel Maven -T 2C, maybe.
>
> It's good that we have tried to adopt annotations from different domain and
> IMHO the MNG-6084 is the experience that we should not repeat and should
> not again adopt foreign annotations (as here in non-EE container) from
> non-Maven domains.
>
>
> On Mon, Oct 14, 2019 at 12:43 PM Stuart McCulloch 
> wrote:
>
> > There are already equivalents, adding yet another "standard" that's
> > specific to Maven is just like writing yet another logging API IMHO:
> >
> >javax.annotation.Priorityorg.eclipse.sisu.Priority
> >
> >javax.annotation.PostConstruct
> >   org.codehaus.plexus.personality.plexus.lifecycle.phase.Initializable
> >javax.annotation.PreDestroy
> >  org.codehaus.plexus.personality.plexus.lifecycle.phase.Disposable
> >
> >(these last two are not totally equivalent since the Plexus API uses
> > interfaces instead of annotations, but they support the same goal)
> >
> > The container will work with or without JSR-250 on the classpath so this
> is
> > more about what you want to let plugin component authors to use. If
> you're
> > happy with them only using Maven specific annotations and having to
> > retro-fit or add adapters when they want to use components outside of
> Maven
> > that use PostConstruct and PreDestroy then just roll back MNG-6084,
> making
> > sure to add a release note warning any plugin authors depending on this
> > feature that they will need to rewrite or adapt their plugins.
> >
> > Also note that this API is only exposed to plugins, it should _not_ be
> > leaking onto the build classpath ... if it is then that's a bug. So this
> > situation is specific to when a plugin either actively uses a dependency
> > that wants a later version of JSR-250 or wants to use that later version
> > itself.
> >
> > Since the JSR-250 API doesn't change much I still think just bumping the
> > version in the distro is the simplest and less disruptive option.
> >
> > On Mon, 14 Oct 2019 at 11:03, Tibor Digana 
> wrote:
> >
> > > All these annotations are for Java EE containers and application
> servers.
> > > A clear solution in 4.0 or 5.0 would be to develop our own annotations
> > for
> > > Maven Domain (not EE domain) within or Java package.
> > >
> > > This way we would reach:
> > > + annotations looking similar to EE annotations
> > > + isolation on the package level
> > > + the purpose of the annotations would match specific Maven domain
> > > + the JavaDoc would not be EE specific anymore
> > >
> > > Many coleagues have negative opinion to my proposal but this was only
> > mine
> > > view.
> > >
>

Re: JSR250 in the lib

[Stuart McCulloch]

There are already equivalents, adding yet another "standard" that's
specific to Maven is just like writing yet another logging API IMHO:

   javax.annotation.Priorityorg.eclipse.sisu.Priority

   javax.annotation.PostConstruct
  org.codehaus.plexus.personality.plexus.lifecycle.phase.Initializable
   javax.annotation.PreDestroy
 org.codehaus.plexus.personality.plexus.lifecycle.phase.Disposable

   (these last two are not totally equivalent since the Plexus API uses
interfaces instead of annotations, but they support the same goal)

The container will work with or without JSR-250 on the classpath so this is
more about what you want to let plugin component authors to use. If you're
happy with them only using Maven specific annotations and having to
retro-fit or add adapters when they want to use components outside of Maven
that use PostConstruct and PreDestroy then just roll back MNG-6084, making
sure to add a release note warning any plugin authors depending on this
feature that they will need to rewrite or adapt their plugins.

Also note that this API is only exposed to plugins, it should _not_ be
leaking onto the build classpath ... if it is then that's a bug. So this
situation is specific to when a plugin either actively uses a dependency
that wants a later version of JSR-250 or wants to use that later version
itself.

Since the JSR-250 API doesn't change much I still think just bumping the
version in the distro is the simplest and less disruptive option.

On Mon, 14 Oct 2019 at 11:03, Tibor Digana  wrote:

> All these annotations are for Java EE containers and application servers.
> A clear solution in 4.0 or 5.0 would be to develop our own annotations for
> Maven Domain (not EE domain) within or Java package.
>
> This way we would reach:
> + annotations looking similar to EE annotations
> + isolation on the package level
> + the purpose of the annotations would match specific Maven domain
> + the JavaDoc would not be EE specific anymore
>
> Many coleagues have negative opinion to my proposal but this was only mine
> view.
>
> On Mon, Oct 14, 2019 at 11:40 AM Stuart McCulloch 
> wrote:
>
> > The JSR-250 API was exposed in
> > https://issues.apache.org/jira/browse/MNG-6084
> >
> > It provides the @PostConstruct, @PreDestroy, and @Priority standard
> > extension annotations for use by plugin components.
> >
> > Isolating that API would affect any plugin components that rely on
> MNG-6084
> > - they would then need to revert back to Initializable and Disposable
> from
> > the Plexus API (although note that the benefit of using a javax API is
> that
> > it makes components more reusable, especially when they come from outside
> > the Maven ecosystem and just happen to be used in a Maven plugin.)
> >
> > The best solution would be to either upgrade that dependency - or
> > alternatively just expose the @PostConstruct, @PreDestroy, and @Priority
> > annotation types rather than the whole package.
> >
> > On Mon, 14 Oct 2019 at 06:01, Romain Manni-Bucau 
> > wrote:
> >
> > > Guess it just comes from guice or friends and since they dont support
> > > recent API it was not upgraded.
> > > We can upgrade it or just isolate it IMO - but requires some careness
> > since
> > > custom components can use it so needs an evolution to toggle it
> probably.
> > >
> > > Le lun. 14 oct. 2019 à 03:43, Tibor Digana  a
> > > écrit :
> > >
> > > > It is a similar issue to the problem with "javax.inject" API.
> > > > What about relocating these two APIs to a package "org.apache.maven"?
> > Any
> > > > thoughts?
> > > >
> > > > On Mon, Oct 14, 2019 at 12:11 AM Petar Tahchiev <
> paranoia...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hello guys,
> > > > >
> > > > > I just decided to upgrade my build from 3.5.0 to 3.6.2 last night
> > and I
> > > > > stumbled across multiple problems, latest one being the following
> > > > > exception:
> > > > >
> > > > > Nested exception is java.lang.NoSuchMethodError:
> > > > > javax.annotation.Resource.lookup()Ljava/lang/String;
> > > > >
> > > > > Seems like maven 3.6.2 comes with jsr-250-api-1.0.jar in the lib/
> > > folder
> > > > > and that seems to cause problems for me because I have moneta in my
> > > > > classpath which brings newer version of jsr250:
> > > > >
> > > > > [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @
> > drmartens
>

Re: JSR250 in the lib

[Stuart McCulloch]

The JSR-250 API was exposed in
https://issues.apache.org/jira/browse/MNG-6084

It provides the @PostConstruct, @PreDestroy, and @Priority standard
extension annotations for use by plugin components.

Isolating that API would affect any plugin components that rely on MNG-6084
- they would then need to revert back to Initializable and Disposable from
the Plexus API (although note that the benefit of using a javax API is that
it makes components more reusable, especially when they come from outside
the Maven ecosystem and just happen to be used in a Maven plugin.)

The best solution would be to either upgrade that dependency - or
alternatively just expose the @PostConstruct, @PreDestroy, and @Priority
annotation types rather than the whole package.

On Mon, 14 Oct 2019 at 06:01, Romain Manni-Bucau 
wrote:

> Guess it just comes from guice or friends and since they dont support
> recent API it was not upgraded.
> We can upgrade it or just isolate it IMO - but requires some careness since
> custom components can use it so needs an evolution to toggle it probably.
>
> Le lun. 14 oct. 2019 à 03:43, Tibor Digana  a
> écrit :
>
> > It is a similar issue to the problem with "javax.inject" API.
> > What about relocating these two APIs to a package "org.apache.maven"? Any
> > thoughts?
> >
> > On Mon, Oct 14, 2019 at 12:11 AM Petar Tahchiev 
> > wrote:
> >
> > > Hello guys,
> > >
> > > I just decided to upgrade my build from 3.5.0 to 3.6.2 last night and I
> > > stumbled across multiple problems, latest one being the following
> > > exception:
> > >
> > > Nested exception is java.lang.NoSuchMethodError:
> > > javax.annotation.Resource.lookup()Ljava/lang/String;
> > >
> > > Seems like maven 3.6.2 comes with jsr-250-api-1.0.jar in the lib/
> folder
> > > and that seems to cause problems for me because I have moneta in my
> > > classpath which brings newer version of jsr250:
> > >
> > > [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ drmartens
> > ---
> > > [INFO] com.demo:drmartens:war:1.0-SNAPSHOT
> > > [INFO] \-
> > >
> > >
> >
> com.nemesis.platform:nemesis-platform-core:jar:2.1.67.BUILD-SNAPSHOT:compile
> > > [INFO]\- org.javamoney:moneta:pom:1.3:compile
> > > [INFO]   \- javax.annotation:javax.annotation-api:jar:1.3.2:compile
> > > [INFO]
> > >
> 
> > >
> > > So I was able to fix this following this recommendation:
> > >
> > >
> >
> https://stackoverflow.com/questions/52607814/how-to-remove-a-maven-lib-jsr250-api-1-0-jar-from-the-plugin-classpath-jetty
> > > using extensions, but I was wondering: why do we need the JSR250 in the
> > lib
> > > folder? Also why do we need such an old version?
> > > --
> > > Regards, Petar!
> > > Karlovo, Bulgaria.
> > > ---
> > > Public PGP Key at:
> > > http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> > > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> > >
> >
>

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: Second MNG-6344

[Stuart McCulloch]

I posted some background why Maven currently uses the no-AOP build in
https://github.com/apache/maven/pull/169#issuecomment-396177378

On 10 June 2018 at 19:42, Michael Osipov  wrote:

> Am 2018-06-10 um 15:45 schrieb Robert Scholte:
>
>> I'm a bit worried about the no_aop drop. I'm pretty sure Stuart would
>> have noticed this in the past.
>> I'm very proud we can say that even Maven 3.0 still runs on the latest
>> JDK version, introducing bytecode parsers like ASM might block this benefit
>> with future versions. Don't think we need it.
>>
>
> I did not drop the no_aop. I upgraded just the version.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: cdi-api leaking?

[Stuart McCulloch]

On Tuesday, 6 February 2018 at 13:25, Romain Manni-Bucau wrote:
> 2018-02-06 12:25 GMT+01:00 Stuart McCulloch <mccu...@gmail.com 
> (mailto:mccu...@gmail.com)>:
>  
> > The "javax.enterprise.inject" CDI package was explicitly exported as part
> > of the ongoing effort to migrate legacy Plexus components onto more modern
> > standard annotations.
> >  
>  
>  
> Hmm, this looks wrong from my window cause Maven doesn't support CDI API -
> guice doesn't. So it is an interpretation of a well defined API which is by
> defintion a bad public API, no?
>  
>  

Raw Guice supports JSR330, but requires programmatic configuration (ie. 
bindings defined in modules)

Sisu builds on Guice to add support for things like annotation scanning and 
wiring, injectable collections that dynamically update as plugins come and go, 
property placeholders, etc.

If the CDI annotations are on the classpath then it also honours the @Typed 
annotation. This was a feature request to help migrate certain components from 
other Plexus-based applications over to JSR330 + @Typed. At the time there was 
a consideration that the rest of the CDI annotations would eventually be 
supported, as another compatibility layer.

Sisu also provides a Plexus compatibility layer that supports Plexus 
annotations and XML

Maven 3.x switched to Sisu so old Plexus-based components can still be used, 
while modern components can be written with JSR330. At the time of the switch 
it was decided to enable support for @Typed in Maven plugins/extensions 
(because there was a developer need for this feature, but that may well have 
changed and no longer be relevant).

So Maven currently honours using @Typed on components - if it’s decided that 
Maven doesn’t want to support @Typed in plugins then just remove the export and 
exclude the cdi-api jar. As mentioned previously support for @Typed is used by 
other downstream non-Maven applications so it will always be something the 
container supports, but it's totally optional so if you don’t want it then you 
don’t need to ship the cdi-api jar.
>  
> >  
> > Specifically, the @javax.enterprise.inject.Typed annotation lets
> > components state they are only visible for injection under a specific type,
> > rather than any type in their hierarchy.
> >  
> > There’s no annotation to control binding visibility in JSR330, because it
> > deliberately avoids configuration concerns, which is why we went with the
> > closest standard annotation (@Typed from JSR299 aka CDI). While we could
> > have decided to use our own annotation - and the container does in fact
> > support using @org.eclipse.sisu.Typed - this is not standardised or
> > portable. Also note the container will continue to support this (optional)
> > feature for other downstream users, regardless of what’s decided here - the
> > question is whether Maven still wants to use this feature and whether it
> > wants to use the standard annotation or not.
> >  
> > Another point is that whichever annotation is chosen must be
> > visible/defined from the same classloader to both core and plugins. If the
> > annotation is not exported then core and each plugin will end up with a
> > different @Typed class, defined by different classloaders. Any use of
> > @Typed in plugins would then effectively be invisible to the container,
> > because the JVM’s AnnotatedElement API (getAnnotation, isAnnotationPresent,
> > etc.) work off classes and not name equivalence.
> >  
> > Similarly shading won’t work because neither the plugin’s components nor
> > the container would know about the shaded package.
> >  
>  
>  
> Hmm, not sure. I mean it works in most projects and it is easy to expose
> the shaded API so not a big deal *technically*. Agree it would be a bad
> solution to use a misused API publicly.
>  
>  

By “not work” I really meant “not practical”. It’s not enough to just shade the 
CDI jar, you’d also need to shade the container - being careful that its 
reflective calls were properly updated (since it uses reflection to decide 
whether to load the feature or not). TBH all that work is overkill, since the 
container already supports an alternative annotation: @org.eclipse.sisu.Typed
>  
>  
> >  
> > As you can see from the thread in http://maven.40175.n5.nabble.
> > com/Linkage-error-td5784411.html a number of alternative solutions have
> > been discussed before, including narrowing the export to:
> >  
> > "javax.enterprise.inject.Typed"
> >  
> > as that’s the only annotation we’re currently interested in. Since @Typed
> > hasn’t changed between 1.x and 2.x that should be a workable solution,
> > assuming you wanted to keep using the standard ann

Re: cdi-api leaking?

[Stuart McCulloch]

The "javax.enterprise.inject" CDI package was explicitly exported as part of 
the ongoing effort to migrate legacy Plexus components onto more modern 
standard annotations.

Specifically, the @javax.enterprise.inject.Typed annotation lets components 
state they are only visible for injection under a specific type, rather than 
any type in their hierarchy.

There’s no annotation to control binding visibility in JSR330, because it 
deliberately avoids configuration concerns, which is why we went with the 
closest standard annotation (@Typed from JSR299 aka CDI). While we could have 
decided to use our own annotation - and the container does in fact support 
using @org.eclipse.sisu.Typed - this is not standardised or portable. Also note 
the container will continue to support this (optional) feature for other 
downstream users, regardless of what’s decided here - the question is whether 
Maven still wants to use this feature and whether it wants to use the standard 
annotation or not.

Another point is that whichever annotation is chosen must be visible/defined 
from the same classloader to both core and plugins. If the annotation is not 
exported then core and each plugin will end up with a different @Typed class, 
defined by different classloaders. Any use of @Typed in plugins would then 
effectively be invisible to the container, because the JVM’s AnnotatedElement 
API (getAnnotation, isAnnotationPresent, etc.) work off classes and not name 
equivalence.

Similarly shading won’t work because neither the plugin’s components nor the 
container would know about the shaded package.

As you can see from the thread in 
http://maven.40175.n5.nabble.com/Linkage-error-td5784411.html a number of 
alternative solutions have been discussed before, including narrowing the 
export to:

"javax.enterprise.inject.Typed"

as that’s the only annotation we’re currently interested in. Since @Typed 
hasn’t changed between 1.x and 2.x that should be a workable solution, assuming 
you wanted to keep using the standard annotation.

Removing the export (and thereby removing the feature to limit injection 
visibility to a specific type) was also discussed, and at the time Igor asked 
for it to be kept:

“Please keep @Typed annotation available outside of core.  

I use @Typed annotation in one of my (private) core extensions where I  
need a class to implement an interface but not make that interface  
visible for injection in other components.”

Assuming Igor still needs this feature then the only other option would be to 
ask him if he can move to the non-standard @org.eclipse.sisu.Typed. The 
existing CDI export could then be replaced by exporting “org.eclipse.sisu”. 
Once that was done then the cdi-api dependency could be excluded from the 
distribution, as the container will still work without it on the classpath 
(it’s only required if you want to use the standard CDI annotation).

So to summarise, the options are:

a)  Continue to support the standard API, but narrow the entry in 
META-INF/maven/extension.xml to “javax.enterprise.inject.Typed”

b)  Switch to support @org.eclipse.sisu.Typed

c)  Remove this feature completely from Maven

--  
Cheers, Stuart


On Tuesday, 6 February 2018 at 09:09, Romain Manni-Bucau wrote:

> 2018-02-06 9:41 GMT+01:00 Tibor Digana  (mailto:tibordig...@apache.org)>:
>  
> > Personally I would like to see a new Git branch with CDI 2.0 and the
> > integration test results on Jenkins.
> > This would give us more confidence.
> > Question: Does the CDI 2.0 have any NEW mandatory descriptive methods
> > without default value already introduced in OLD annotations CDI 1.0/1.1?
> >  
>  
>  
> It is more a change in the hierarchy. It doesn't break the user API since
> cdi is designed to be provided but it is broken if new code uses old API.
>  
> Side note: if the idea behind this answer is to ensure the default provided
> API is the last one then it doesn't work cause an API has a few logic which
> can require to be overriden (like the SPI and defaults handling).
> Maven uses its own API and exposing CDI is a leaking abuse IMHO.
>  
> Note that this is an old bug which should be fixed now IMO before maven
> considers CDI being exposed as part of the contract.
>  
> For reference, older threads:
>  
> http://maven.40175.n5.nabble.com/libs-in-mavens-lib-folder-td5828015.html
> http://maven.40175.n5.nabble.com/Linkage-error-td5784411.html#a5784470
>  
>  
> There is no risk removing it, worse case plugins would add the API as
> compile instead of provided which should likely already be the case.
>  
>  
> > On Tue, Feb 6, 2018 at 8:57 AM, Romain Manni-Bucau  > (mailto:rmannibu...@gmail.com)>
> > wrote:
> >  
> > >  
> > > For the reproducer here it is https://github.com/
> > > rmannibucau/test-maven-plugin - pretty trivial you'll see ;).
> > >  
> > > 2018-02-06 8:05 GMT+01:00 Tibor Digana  > > (mailto:tibordig...@apache.org)>:
> 

Re: ATTN: Maven core build is broken

[Stuart McCulloch]

Hi,  

A bit of background first - ClassRealm has two different different concepts of 
class loading hierarchy:

1)  the base class loader passed into the constructor, which is passed onto the 
URLClassLoader superclass

2)  the ‘parent’ class loader set via setParentClassLoader / setParentRealm

Now 1) doesn’t have any filtering applied, any class or resource requests are 
delegated straight to the base class loader before checking the realm and its 
parent/imports  

Whereas 2) does have filtering applied, as configured via importFromParent, and 
is checked after the base loader (the subsequent order depends on the realm 
strategy)

So technically there is a potential change of behaviour by setting 
PARENT_CLASS_LOADER as the base loader 1) because it won’t have any parent 
import filtering.

But looking at the call hierarchy for createRealm it turns out that Maven 
doesn’t use parent import filtering, so in practice this doesn’t change that 
particular behaviour.

( however if other external users of ClassRealmManager.createPluginRealm rely 
on parent filtering then they could potentially be affected )

A more significant difference is that parent delegation will now happen before 
checking the realm and its imports, whereas before the strategy was 
“self-first” with imports and the current realm being checked before the parent 
- as Igor mentioned this could potentially lead to classpath 
collisions/incompatibilities if PARENT_CLASS_LOADER contains common third-party 
libraries. This won’t affect CLI usage, it’s more an issue for people embedding 
Maven - but they could always add their own filtering to stop classes/resources 
leaking to Maven.

Also as Igor mentioned, if you’re going to use the parent as the base class 
loader then you don’t need to call setParentClassLoader for the same parent - 
so the realm manager code could be simplified. Maybe “newRealm” could take a 
parent argument and that could be used to decide what to use for the base class 
loader (atm it doesn’t have that information to hand)

But as a first step this one-line change looks ok, as long as we give 
integrators a heads-up so they can test the snapshot / early release candidate.

--  
Cheers, Stuart


On Thursday, 31 August 2017 at 10:18, Stephen Connolly wrote:

> I have rebased and squashed the commit: 
> https://github.com/apache/maven/compare/mng-6275
>  
> The tests should still pass: 
> https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/mng-6275/4/pipeline
>  
> So just need the code review from Stuart and Igor and then I think we are 
> good to merge...
>  
> On 31 August 2017 at 01:27, Robert Scholte <rfscho...@apache.org 
> (mailto:rfscho...@apache.org)> wrote:
> > Cool
> >  
> >  
> > On Wed, 30 Aug 2017 23:22:14 +0200, Stephen Connolly 
> > <stephen.alan.conno...@gmail.com (mailto:stephen.alan.conno...@gmail.com)> 
> > wrote:
> >  
> > > Unit test is still present in my branch, so should be a yes (if your unit
> > > test works)
> > >  
> > > On Wed 30 Aug 2017 at 21:50, Robert Scholte <rfscho...@apache.org 
> > > (mailto:rfscho...@apache.org)> wrote:
> > >  
> > > > But can you access classes via the ServiceLoader?
> > > >  
> > > > On Wed, 30 Aug 2017 22:48:40 +0200, Stephen Connolly
> > > > <stephen.alan.conno...@gmail.com 
> > > > (mailto:stephen.alan.conno...@gmail.com)> wrote:
> > > >  
> > > > > Oh wow!
> > > > >
> > > > https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/mng-6275/3/pipeline
> > > > >
> > > > > Can we get Stuart and Igor to review:
> > > > > https://github.com/apache/maven/compare/mng-6275
> > > > >
> > > > > Seems almost too easy!
> > > > >
> > > > >
> > > > >
> > > > > On 30 August 2017 at 17:02, Robert Scholte <rfscho...@apache.org 
> > > > > (mailto:rfscho...@apache.org)> wrote:
> > > > >
> > > > >> I agree
> > > > >>
> > > > >>
> > > > >> On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly <
> > > > >> stephen.alan.conno...@gmail.com 
> > > > >> (mailto:stephen.alan.conno...@gmail.com)> wrote:
> > > > >>
> > > > >> I think we'll de-scope 6275 for 3.5.1
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
> > > > >>> stephen.alan.conno...@gmail.com 
> > > >

Re: ATTN: Maven core build is broken

[Stuart McCulloch]

On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa1f99add299ff439f5ec
> should fix
>  
>  

Is it worth storing the chosen context/system loader in a member variable, or 
maybe even statically like PARENT_CLASSLOADER, rather than checking each time?

This would also avoid the off-chance that something changes the thread’s 
context loader during the build which could then influence subsequent calls to 
“newRealm”.

(IIUC when embedding we’d expect the context loader to be set correctly during 
construction of the realm manager, and that same loader should then be used for 
all realms)
> On 30 August 2017 at 02:09, Robert Scholte  (mailto:rfscho...@apache.org)> wrote:
>  
> > Now that the ITs are all in place again it is good to see that these
> > failures reflect the concerns of Igor.
> > Originally this issue said it was Java 9 related, but this is a Java 8
> > issue as well, so there's no real need to include it for 3.5.1
> > I'll revert this commit and reopen the issue.
> > Future analysis must answer the question where and how the classloading
> > must be improved.
> >  
> > Robert
> >  
> >  
> > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > stephen.alan.conno...@gmail.com (mailto:stephen.alan.conno...@gmail.com)> 
> > wrote:
> >  
> > Ok, looking a the results of the bisect-0 through bisect-3 builds, 0 and 1
> > > both fail just for the MNG-6127 integration tests, bisect-2 adds the fix
> > > for MNG-6127, so the build passes... bisect-3 also passes, so the smoking
> > > gun is...
> > >  
> > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> > > 40e6805bef287f3cc3e
> > >  
> > > On 29 August 2017 at 22:17, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com (mailto:stephen.alan.conno...@gmail.com)> 
> > > wrote:
> > >  
> > > bisect-0 is the last known good commit with the Jenkinsfile fix to confirm
> > > > that the failures are not another infra related change
> > > >  
> > > > On 29 August 2017 at 22:13, Stephen Connolly
> > > >  > > > com> wrote:
> > > >  
> > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we can identify
> > > > > the problematic commit since the last known good build of master (#123
> > > > > for
> > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> > > > >  
> > > > > On 29 August 2017 at 22:09, Stephen Connolly <
> > > > > stephen.alan.conno...@gmail.com 
> > > > > (mailto:stephen.alan.conno...@gmail.com)> wrote:
> > > > >  
> > > > > Failure is in testBootstrap, probably something obvious, here's the
> > > > > > problematic build log... you can inspect for yourself at
> > > > > > https://builds.apache.org/blue/organizations/jenkins/mave
> > > > > > n-3.x-jenkinsfile/detail/master/128/tests but there is no point in
> > > > > > looking at any tests other than testBootstrap as if that fails
> > > > > > everything
> > > > > > else will fail too
> > > > > >  
> > > > > > [WARNING] Error injecting: org.apache.maven.plugins.depen
> > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > com.google.inject.ProvisionException: Unable to provision, see the
> > > > > > following errors:
> > > > > > 1) No implementation for org.apache.maven.artifact.hand
> > > > > > ler.manager.ArtifactHandlerManager was bound.
> > > > > > while locating org.apache.maven.plugins.depen
> > > > > > dency.resolvers.ResolvePluginsMojo
> > > > > > 1 error
> > > > > > at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.j
> > > > > > ava:1025)
> > > > > > at com.google.inject.internal.InjectorImpl.getInstance(Injector
> > > > > > Impl.java:1051)
> > > > > > at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDef
> > > > > > erredClass.java:48)
> > > > > > at com.google.inject.internal.ProviderInternalFactory.provision
> > > > > > (ProviderInternalFactory.java:81)
> > > > > > at com.google.inject.internal.InternalFactoryToInitializableAda
> > > > > > pter.provision(InternalFactoryToInitializableAdapter.java:53)
> > > > > > at com.google.inject.internal.ProviderInternalFactory$1.call(Pr
> > > > > > oviderInternalFactory.java:65)
> > > > > > at com.google.inject.internal.ProvisionListenerStackCallback$Pr
> > > > > > ovision.provision(ProvisionListenerStackCallback.java:115)
> > > > > > at com.google.inject.internal.ProvisionListenerStackCallback$Pr
> > > > > > ovision.provision(ProvisionListenerStackCallback.java:133)
> > > > > > at com.google.inject.internal.ProvisionListenerStackCallback.pr
> > > > > > ovision(ProvisionListenerStackCallback.java:68)
> > > > > > at com.google.inject.internal.ProviderInternalFactory.circularG
> > > > > > et(ProviderInternalFactory.java:63)
> > > > > > at com.google.inject.internal.InternalFactoryToInitializableAda
> > > > > > pter.get(InternalFactoryToInitializableAdapter.java:45)
> > > > > > at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImp
> > > > > > l.java:1016)
> > 

Re: index out of bounds 3.5 regression

[Stuart McCulloch]

Might also be related to https://issues.apache.org/jira/browse/MNG-6216

On Friday, 30 June 2017 at 15:25, Anton Tanasenko wrote:

> You're hitting an issue [1] in plexus-utils most probably. Check if you
> have  processing instructions in one of the poms.
> 
> [1] https://github.com/codehaus-plexus/plexus-utils/issues/22
> 
> 2017-06-30 16:57 GMT+03:00 Brian Fox  (mailto:bri...@infinity.nu)>:
> 
> > I'm getting index out of bounds exceptions with 3.5 that don't occur with
> > 3.3.9. I haven't debugged it yet, but wondering if this is already known?
> > Fwiw reproducible with the DependencyCheck 2.0-snapshot master.
> > 
> > [ERROR] 13978
> > 
> > java.lang.ArrayIndexOutOfBoundsException: 13978
> > 
> > at org.codehaus.plexus.util.xml.pull.MXParser.parsePI(MXParser.java:2502)
> > 
> > at
> > org.codehaus.plexus.util.xml.pull.MXParser.parseEpilog(MXParser.java:1604)
> > 
> > at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1434)
> > 
> > at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1131)
> > 
> > at
> > org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(
> > MavenXpp3Reader.java:3856)
> > 
> > at
> > org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(
> > MavenXpp3Reader.java:595)
> > 
> > at
> > org.apache.maven.model.io.DefaultModelReader.read(
> > DefaultModelReader.java:109)
> > 
> > at
> > org.apache.maven.model.io.DefaultModelReader.read(
> > DefaultModelReader.java:82)
> > 
> > at
> > org.apache.maven.model.building.DefaultModelProcessor.read(
> > DefaultModelProcessor.java:81)
> > 
> > at
> > org.apache.maven.model.building.DefaultModelBuilder.
> > readModel(DefaultModelBuilder.java:535)
> > 
> > at
> > org.apache.maven.model.building.DefaultModelBuilder.
> > build(DefaultModelBuilder.java:275)
> > 
> > at
> > org.apache.maven.repository.internal.DefaultArtifactDescriptorReade
> > r.loadPom(DefaultArtifactDescriptorReader.java:321)
> > 
> > at
> > org.apache.maven.repository.internal.DefaultArtifactDescriptorReade
> > r.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:199)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.
> > resolveCachedArtifactDescriptor(DefaultDependencyCollector.java:544)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.
> > getArtifactDescriptorResult(DefaultDependencyCollector.java:528)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.
> > processDependency(DefaultDependencyCollector.java:418)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.
> > processDependency(DefaultDependencyCollector.java:372)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(
> > DefaultDependencyCollector.java:360)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.doRecurse(
> > DefaultDependencyCollector.java:513)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.
> > processDependency(DefaultDependencyCollector.java:467)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.
> > processDependency(DefaultDependencyCollector.java:372)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(
> > DefaultDependencyCollector.java:360)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.doRecurse(
> > DefaultDependencyCollector.java:513)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.
> > processDependency(DefaultDependencyCollector.java:467)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.
> > processDependency(DefaultDependencyCollector.java:372)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(
> > DefaultDependencyCollector.java:360)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultDependencyCollector.
> > collectDependencies(DefaultDependencyCollector.java:263)
> > 
> > at
> > org.eclipse.aether.internal.impl.DefaultRepositorySystem.
> > collectDependencies(DefaultRepositorySystem.java:325)
> > 
> > at
> > org.apache.maven.plugin.internal.DefaultPluginDependenciesResol
> > ver.resolveInternal(DefaultPluginDependenciesResolver.java:202)
> > 
> > at
> > org.apache.maven.plugin.internal.DefaultPluginDependenciesResol
> > ver.resolve(DefaultPluginDependenciesResolver.java:149)
> > 
> > at
> > org.apache.maven.plugin.internal.DefaultMavenPluginManager.
> > createPluginRealm(DefaultMavenPluginManager.java:402)
> > 
> > at
> > org.apache.maven.plugin.internal.DefaultMavenPluginManager.
> > setupPluginRealm(DefaultMavenPluginManager.java:374)
> > 
> > at
> > org.apache.maven.plugin.DefaultBuildPluginManager.getPluginRealm(
> > DefaultBuildPluginManager.java:231)
> > 
> > at
> > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> > DefaultBuildPluginManager.java:102)
> > 
> > at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> > 

Re: I think we are ready for 3.5.0-alpha-1

[Stuart McCulloch]

I’ve logged the change in precedence as 
https://issues.apache.org/jira/browse/MNG-6172 since this has the potential to 
break CI builds which relied on the previous last-one-wins behaviour

On Monday, 13 February 2017 at 06:54, Tibor Digana wrote:

> Exactly this is the problem - forkMode and reuseForks in one function.
> I will open Jira and push a fix.
>  
> On Mon, Feb 13, 2017 at 2:44 AM, Stuart McCulloch [via Maven] <
> ml-node+s40175n5898461...@n5.nabble.com 
> (mailto:ml-node+s40175n5898461...@n5.nabble.com)> wrote:
>  
> > So I tweaked ForkedLauncher from maven-verifier to dump out the forked
> > command to log.txt and at least one of the failing ITs has a duplicated
> > system property on the command-line:
> >  
> > mvn -e --batch-mode -Dmaven.repo.local=/tmp/maven-
> > surefire/surefire-integration-tests/../surefire-setup-
> > integration-tests/target/it-repo 
> > org.apache.maven.plugins:maven-clean-plugin:clean
> > -Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7
> > -DtestNgClassifier=jdk15 -DforkMode=perthread -DreuseForks=false
> > -DreuseForks=true -DthreadCount=1 -DtestProperty=testValue_${
> > surefire.threadNumber}_${surefire.forkNumber} org.apache.maven.plugins.
> > surefire:maven-dump-pid-plugin:dump-pid test
> >  
> > specifically:
> >  
> > -DreuseForks=false -DreuseForks=true
> >  
> > Looking at SurefireLauncher.java
> >  
> > https://github.com/apache/maven-surefire/blob/master/
> > surefire-integration-tests/src/test/java/org/apache/
> > maven/surefire/its/fixture/SurefireLauncher.java
> >  
> > 1. the reuseForks method adds a new system property argument each time
> > it’s called: -DreuseForks=
> > 2. the forkPerThread method calls forkMode( "perthread" ).reuseForks(
> > false )
> > 3. the forkOncePerThread calls forkPerThread().reuseForks( true )
> >  
> > So any test using SurefireLauncher’s “forkOncePerThread” method will end
> > up with two “reuseForks” system property options on the command-line - and
> > will therefore be affected by the change in system property option
> > precedence.
> >  
> > This explains why ForkModeIT fails for me locally with master, but passes
> > with 3.3.9 - with current master the -DreuseForks=false option wins,
> > whereas with 3.3.9 the -DreuseForks=true options wins.
> >  
> > If I change SurefireLauncher.forkOncePerThread to avoid duplicating this
> > system property, ie:
> >  
> > return forkMode( "perthread" ).reuseForks( true );
> >  
> > then ForkModeIT passes with both current master and previous Maven
> > releases.
> >  
> > Hope that helps...
> >  
> > --
> > Cheers, Stuart
> >  
> >  
> > On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:
> >  
> > > Ironically I got those results the wrong way round when cutting+pasting
> > :)
> > >  
> > > To clarify, when testing
> > >  
> > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> > >  
> > > with previous Maven releases the last option wins:
> > >  
> > > -Dmaven.repo.local=/tmp/zzz
> > >  
> > > whereas with current master the first option wins:
> > >  
> > > -Dmaven.repo.local=/tmp/aaa
> > >  
> > > On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
> > >  
> > > > Using the following command on a small test project:
> > > >  
> > > > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> > > >  
> > > > and checking whether the “aaa” or “zzz” directory is created gives
> > these results for previous Maven releases:
> > > >  
> > > > 2.0.11 aaa
> > > > 2.2.1 aaa
> > > > 3.0.5 aaa
> > > > 3.1.1 aaa
> > > > 3.2.5 aaa
> > > > 3.3.9 aaa
> > > >  
> > > > whereas current master gives a different result:
> > > >  
> > > > master zzz
> > > >  
> > > > which confirms the precedence of CLI arguments is currently reversed
> > on master compared to previous releases
> > > >  
> > > > --
> > > > Cheers, Stuart
> > > >  
> > > >  
> > > > On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
> > > >  
> > > > > git bisect is pointing to the following commit:
> > > > >  
> > > > > https://github.com/apache/maven/commit/
> > ca4303031357a7decaee8d

Re: I think we are ready for 3.5.0-alpha-1

[Stuart McCulloch]

So I tweaked ForkedLauncher from maven-verifier to dump out the forked command 
to log.txt and at least one of the failing ITs has a duplicated system property 
on the command-line:

mvn -e --batch-mode 
-Dmaven.repo.local=/tmp/maven-surefire/surefire-integration-tests/../surefire-setup-integration-tests/target/it-repo
 org.apache.maven.plugins:maven-clean-plugin:clean 
-Dsurefire.version=2.19.2-SNAPSHOT -DtestNgVersion=5.7 -DtestNgClassifier=jdk15 
-DforkMode=perthread -DreuseForks=false -DreuseForks=true -DthreadCount=1 
-DtestProperty=testValue_${surefire.threadNumber}_${surefire.forkNumber} 
org.apache.maven.plugins.surefire:maven-dump-pid-plugin:dump-pid test

specifically:

-DreuseForks=false -DreuseForks=true

Looking at SurefireLauncher.java

https://github.com/apache/maven-surefire/blob/master/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/SurefireLauncher.java

1.  the reuseForks method adds a new system property argument each time it’s 
called:  -DreuseForks=
2.  the forkPerThread method calls forkMode( "perthread" ).reuseForks( false )
3.  the forkOncePerThread calls forkPerThread().reuseForks( true )

So any test using SurefireLauncher’s “forkOncePerThread” method will end up 
with two “reuseForks” system property options on the command-line - and will 
therefore be affected by the change in system property option precedence.

This explains why ForkModeIT fails for me locally with master, but passes with 
3.3.9 - with current master the -DreuseForks=false option wins, whereas with 
3.3.9 the -DreuseForks=true options wins.

If I change SurefireLauncher.forkOncePerThread to avoid duplicating this system 
property, ie:

return forkMode( "perthread" ).reuseForks( true );

then ForkModeIT passes with both current master and previous Maven releases.

Hope that helps...

--  
Cheers, Stuart


On Monday, 13 February 2017 at 01:32, Stuart McCulloch wrote:

> Ironically I got those results the wrong way round when cutting+pasting :)
>  
> To clarify, when testing
>  
> mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
>  
> with previous Maven releases the last option wins:
>  
> -Dmaven.repo.local=/tmp/zzz
>  
> whereas with current master the first option wins:
>  
> -Dmaven.repo.local=/tmp/aaa  
>  
> On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:
>  
> > Using the following command on a small test project:
> >  
> > mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> >  
> > and checking whether the “aaa” or “zzz” directory is created gives these 
> > results for previous Maven releases:
> >  
> > 2.0.11 aaa
> > 2.2.1 aaa
> > 3.0.5 aaa
> > 3.1.1 aaa
> > 3.2.5 aaa
> > 3.3.9 aaa
> >  
> > whereas current master gives a different result:
> >  
> > master zzz  
> >  
> > which confirms the precedence of CLI arguments is currently reversed on 
> > master compared to previous releases
> >  
> > --  
> > Cheers, Stuart
> >  
> >  
> > On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
> >  
> > > git bisect is pointing to the following commit:
> > >  
> > > https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28
> > >  
> > > if I revert this change then the wrong PID issue disappears and 
> > > ForkModeIT passes again
> > >  
> > > I suspect that reversing the whole array of system property definitions, 
> > > while solving MNG-6078, is breaking precedence of arguments on the CLI 
> > > (which then affects these tests)  
> > >  
> > > On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
> > >  
> > > > So this is a local build status of surefire running on the top of 
> > > > certain
> > > > Maven Version.
> > > > Maven 3.3.9 OK on my side
> > > > Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd 
> > > > and
> > > > not on Win7, so I asked Michael for logs which I do not have.
> > > > So I am going to investigate.
> > > >  
> > > > On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> > > > ml-node+s40175n5898384...@n5.nabble.com 
> > > > (mailto:ml-node+s40175n5898384...@n5.nabble.com)> wrote:
> > > >  
> > > > > Can you pop on HipChat with infra?
> > > > >  
> > > > > You may need them to grab the files from the agent for you (or modify 
> > > > > the
> > > > > Jenkinsfile temporarily to archive the bits you need)
> > > > >  
> > > > > On Sun

Re: I think we are ready for 3.5.0-alpha-1

[Stuart McCulloch]

Ironically I got those results the wrong way round when cutting+pasting :)

To clarify, when testing

mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate

with previous Maven releases the last option wins:

-Dmaven.repo.local=/tmp/zzz

whereas with current master the first option wins:

-Dmaven.repo.local=/tmp/aaa  

On Monday, 13 February 2017 at 00:19, Stuart McCulloch wrote:

> Using the following command on a small test project:
>  
> mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
>  
> and checking whether the “aaa” or “zzz” directory is created gives these 
> results for previous Maven releases:
>  
> 2.0.11 aaa
> 2.2.1 aaa
> 3.0.5 aaa
> 3.1.1 aaa
> 3.2.5 aaa
> 3.3.9 aaa
>  
> whereas current master gives a different result:
>  
> master zzz  
>  
> which confirms the precedence of CLI arguments is currently reversed on 
> master compared to previous releases
>  
> --  
> Cheers, Stuart
>  
>  
> On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:
>  
> > git bisect is pointing to the following commit:
> >  
> > https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28
> >  
> > if I revert this change then the wrong PID issue disappears and ForkModeIT 
> > passes again
> >  
> > I suspect that reversing the whole array of system property definitions, 
> > while solving MNG-6078, is breaking precedence of arguments on the CLI 
> > (which then affects these tests)  
> >  
> > On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
> >  
> > > So this is a local build status of surefire running on the top of certain
> > > Maven Version.
> > > Maven 3.3.9 OK on my side
> > > Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd and
> > > not on Win7, so I asked Michael for logs which I do not have.
> > > So I am going to investigate.
> > >  
> > > On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> > > ml-node+s40175n5898384...@n5.nabble.com 
> > > (mailto:ml-node+s40175n5898384...@n5.nabble.com)> wrote:
> > >  
> > > > Can you pop on HipChat with infra?
> > > >  
> > > > You may need them to grab the files from the agent for you (or modify 
> > > > the
> > > > Jenkinsfile temporarily to archive the bits you need)
> > > >  
> > > > On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node=5898384=0>> wrote:
> > > >  
> > > > > There is build process for surefire
> > > > >  
> > > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > > release-status-test-surefire-linux
> > > > > with Jenkins file.
> > > > > This particular build fails with test
> > > > >  
> > > > > Surefire141PluggableProvidersIT
> > > > >  
> > > > > It is only one and different from your local build result.
> > > > >  
> > > > > I asked Stephen to enable Workspace, because I need to have files from
> > > > > target folders for analysis to understand what is going on the 
> > > > > machine.
> > > > > Stephen told me that I should trigger rebuild. So I did and launched
> > > > >  
> > > >  
> > > > "Build
> > > > > with Parameters" but the build failed not running Maven build, however
> > > > > Workspace appears now.
> > > > >  
> > > > > How can I force trigger the build?
> > > > >  
> > > > >  
> > > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > > release-status-test-surefire-linux/11/console
> > > > >  
> > > > > There is another build process, old one actually, and it is 
> > > > > successful.
> > > > > The difference is because I think race condition when JVM error once
> > > > >  
> > > >  
> > > > goes
> > > > > to std/err and other log in the first build with Jenkins file.
> > > > > This can, I think, be only one more assertion statement in IT but I 
> > > > > need
> > > > >  
> > > >  
> > > > to
> > > > > see Workspace.
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > > On Sun,

Re: I think we are ready for 3.5.0-alpha-1

[Stuart McCulloch]

Using the following command on a small test project:

mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate

and checking whether the “aaa” or “zzz” directory is created gives these 
results for previous Maven releases:

2.0.11 aaa
2.2.1 aaa
3.0.5 aaa
3.1.1 aaa
3.2.5 aaa
3.3.9 aaa

whereas current master gives a different result:

master zzz  

which confirms the precedence of CLI arguments is currently reversed on master 
compared to previous releases

--  
Cheers, Stuart


On Sunday, 12 February 2017 at 23:53, Stuart McCulloch wrote:

> git bisect is pointing to the following commit:
>  
> https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28
>  
> if I revert this change then the wrong PID issue disappears and ForkModeIT 
> passes again
>  
> I suspect that reversing the whole array of system property definitions, 
> while solving MNG-6078, is breaking precedence of arguments on the CLI (which 
> then affects these tests)  
>  
> On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:
>  
> > So this is a local build status of surefire running on the top of certain
> > Maven Version.
> > Maven 3.3.9 OK on my side
> > Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd and
> > not on Win7, so I asked Michael for logs which I do not have.
> > So I am going to investigate.
> >  
> > On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> > ml-node+s40175n5898384...@n5.nabble.com 
> > (mailto:ml-node+s40175n5898384...@n5.nabble.com)> wrote:
> >  
> > > Can you pop on HipChat with infra?
> > >  
> > > You may need them to grab the files from the agent for you (or modify the
> > > Jenkinsfile temporarily to archive the bits you need)
> > >  
> > > On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node=5898384=0>> wrote:
> > >  
> > > > There is build process for surefire
> > > >  
> > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > release-status-test-surefire-linux
> > > > with Jenkins file.
> > > > This particular build fails with test
> > > >  
> > > > Surefire141PluggableProvidersIT
> > > >  
> > > > It is only one and different from your local build result.
> > > >  
> > > > I asked Stephen to enable Workspace, because I need to have files from
> > > > target folders for analysis to understand what is going on the machine.
> > > > Stephen told me that I should trigger rebuild. So I did and launched
> > > >  
> > >  
> > > "Build
> > > > with Parameters" but the build failed not running Maven build, however
> > > > Workspace appears now.
> > > >  
> > > > How can I force trigger the build?
> > > >  
> > > >  
> > > > https://builds.apache.org/view/Maven/job/maven-master-
> > > release-status-test-surefire-linux/11/console
> > > >  
> > > > There is another build process, old one actually, and it is successful.
> > > > The difference is because I think race condition when JVM error once
> > > >  
> > >  
> > > goes
> > > > to std/err and other log in the first build with Jenkins file.
> > > > This can, I think, be only one more assertion statement in IT but I need
> > > >  
> > >  
> > > to
> > > > see Workspace.
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > On Sun, Feb 12, 2017 at 5:04 PM, Christian Schulte [via Maven] <
> > > > [hidden email] <http:///user/SendEmail.jtp?type=node=5898384=1>>
> > > >  
> > >  
> > > wrote:
> > > >  
> > > > > @Stephen: Are there any Jenkins jobs left running the plugin ITs with
> > > > > current Maven master? Surefire has it's own git repository. Do we have
> > > > > some Jenkins job for this as well? It's important to run all those ITs
> > > > > (plugins from subversion and the ones with theire own repository) with
> > > > > what we are going to release as 3.5.0 before releasing it.
> > > > >  
> > > > > Regards,
> > > > > --
> > > > > Christian
> > > > >  
> > > > >  
> > > > > -
> > > > > To unsubscribe, e-mai

Re: I think we are ready for 3.5.0-alpha-1

[Stuart McCulloch]

git bisect is pointing to the following commit:

https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28

if I revert this change then the wrong PID issue disappears and ForkModeIT 
passes again

I suspect that reversing the whole array of system property definitions, while 
solving MNG-6078, is breaking precedence of arguments on the CLI (which then 
affects these tests) 

On Sunday, 12 February 2017 at 20:26, Tibor Digana wrote:

> So this is a local build status of surefire running on the top of certain
> Maven Version.
> Maven 3.3.9 OK on my side
> Maven 3.5.0-SNAPSHOT failed. Wrong PIDs, other tests failed on freebsd and
> not on Win7, so I asked Michael for logs which I do not have.
> So I am going to investigate.
> 
> On Sun, Feb 12, 2017 at 9:05 PM, stephenconnolly [via Maven] <
> ml-node+s40175n5898384...@n5.nabble.com 
> (mailto:ml-node+s40175n5898384...@n5.nabble.com)> wrote:
> 
> > Can you pop on HipChat with infra?
> > 
> > You may need them to grab the files from the agent for you (or modify the
> > Jenkinsfile temporarily to archive the bits you need)
> > 
> > On Sun 12 Feb 2017 at 19:55, Tibor Digana <[hidden email]
> > > wrote:
> > 
> > > There is build process for surefire
> > > 
> > > https://builds.apache.org/view/Maven/job/maven-master-
> > release-status-test-surefire-linux
> > > with Jenkins file.
> > > This particular build fails with test
> > > 
> > > Surefire141PluggableProvidersIT
> > > 
> > > It is only one and different from your local build result.
> > > 
> > > I asked Stephen to enable Workspace, because I need to have files from
> > > target folders for analysis to understand what is going on the machine.
> > > Stephen told me that I should trigger rebuild. So I did and launched
> > > 
> > 
> > "Build
> > > with Parameters" but the build failed not running Maven build, however
> > > Workspace appears now.
> > > 
> > > How can I force trigger the build?
> > > 
> > > 
> > > https://builds.apache.org/view/Maven/job/maven-master-
> > release-status-test-surefire-linux/11/console
> > > 
> > > There is another build process, old one actually, and it is successful.
> > > The difference is because I think race condition when JVM error once
> > > 
> > 
> > goes
> > > to std/err and other log in the first build with Jenkins file.
> > > This can, I think, be only one more assertion statement in IT but I need
> > > 
> > 
> > to
> > > see Workspace.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Sun, Feb 12, 2017 at 5:04 PM, Christian Schulte [via Maven] <
> > > [hidden email] >
> > > 
> > 
> > wrote:
> > > 
> > > > @Stephen: Are there any Jenkins jobs left running the plugin ITs with
> > > > current Maven master? Surefire has it's own git repository. Do we have
> > > > some Jenkins job for this as well? It's important to run all those ITs
> > > > (plugins from subversion and the ones with theire own repository) with
> > > > what we are going to release as 3.5.0 before releasing it.
> > > > 
> > > > Regards,
> > > > --
> > > > Christian
> > > > 
> > > > 
> > > > -
> > > > To unsubscribe, e-mail: [hidden email]
> > > > 
> > > > For additional commands, e-mail: [hidden email]
> > > > 
> > > > 
> > > > 
> > > > 
> > > > --
> > > > If you reply to this email, your message will be added to the
> > > > 
> > > 
> > > 
> > 
> > discussion
> > > > below:
> > > > http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-
> > > > 
> > > 
> > 
> > 3-5-0-alpha-1-
> > > > tp5897626p5898337.html
> > > > To start a new topic under Maven Developers, email
> > > > [hidden email] 
> > > > To unsubscribe from Maven Developers, click here
> > > > <
> > > > 
> > > > .
> > > > NAML
> > > > <
> > > > 
> > > 
> > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> > > 
> > 
> > macro=macro_viewer=instant_html%21nabble%3Aemail.naml&
> > base=nabble.naml.namespaces.BasicNamespace-nabble.view.
> > web.template.NabbleNamespace-nabble.view.web.template 
> > (http://web.template.NabbleNamespace-nabble.view.web.template).
> > NodeNamespace=notify_subscribers%21nabble%
> > 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
> > instant_email%21nabble%3Aemail.naml
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > --
> > > View this message in context:
> > > http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-5-0-alpha-1-
> > > 
> > 
> > tp5897626p5898378.html
> > > Sent from the Maven Developers mailing list archive at Nabble.com 
> > > (http://Nabble.com).
> > 
> > 
> > --
> > Sent from my phone
> > 
> > 
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> > 

Re: maven git commit: [MNG-6165] Deprecate and replace incorrectly spelled public API

[Stuart McCulloch]

Note making a method final will break binary compatibility if someone has
previously overridden that method - in such cases they'd get a verify error
running with the new binary:

https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.17


On 4 Feb 2017 01:59, "Christian Schulte"  wrote:

Can we make the deprecated methods final, please? It's still binary
compatible when final. If someone has overridden such a deprecated
method, he will get a compile time error and will notice he needs to
override the new method instead.

Am 02/04/17 um 00:21 schrieb micha...@apache.org:
> Repository: maven
> Updated Branches:
>   refs/heads/MNG-6165 [created] 87c6346a0
>
>
> [MNG-6165] Deprecate and replace incorrectly spelled public API
>
> Spelling fixes:
>
> * spelling: collector
> * spelling: executions
> * spelling: repositories
> * spelling: workspace
>
> This closes #101
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/87c6346a
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/87c6346a
> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/87c6346a
>
> Branch: refs/heads/MNG-6165
> Commit: 87c6346a0db61384db0e66b9482e0ed832823b07
> Parents: 1740265
> Author: Josh Soref 
> Authored: Mon Jan 23 04:57:23 2017 +
> Committer: Michael Osipov 
> Committed: Sat Feb 4 00:20:48 2017 +0100
>
> --
>  .../repository/MetadataResolutionRequest.java   | 20 +++-
>  .../legacy/LegacyRepositorySystem.java  |  2 +-
>  .../DelegatingLocalArtifactRepository.java  |  9 +
>  .../LifecycleExecutionPlanCalculatorStub.java   | 13 -
>  .../AbstractModelInterpolatorTest.java  | 18 ++
>  5 files changed, 55 insertions(+), 7 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/87c6346a/
maven-compat/src/main/java/org/apache/maven/repository/
MetadataResolutionRequest.java
> --
> diff --git 
> a/maven-compat/src/main/java/org/apache/maven/repository/MetadataResolutionRequest.java
b/maven-compat/src/main/java/org/apache/maven/repository/
MetadataResolutionRequest.java
> index c98dd05..4fb0e32 100644
> --- a/maven-compat/src/main/java/org/apache/maven/repository/
MetadataResolutionRequest.java
> +++ b/maven-compat/src/main/java/org/apache/maven/repository/
MetadataResolutionRequest.java
> @@ -108,14 +108,32 @@ public class MetadataResolutionRequest
>  return this;
>  }
>
> +/**
> + * @deprecated instead use {@link #getRemoteRepositories()}
> + */
> +@Deprecated
>  public List getRemoteRepostories()
>  {
> +return getRemoteRepositories();
> +}
> +
> +public List getRemoteRepositories()
> +{
>  return remoteRepositories;
>  }
>
> +/**
> + * @deprecated instead use {@link #setRemoteRepositories()}
> + */
> +@Deprecated
>  public MetadataResolutionRequest setRemoteRepostories(
List remoteRepostories )
>  {
> -this.remoteRepositories = remoteRepostories;
> +return setRemoteRepositories(remoteRepositories);
> +}
> +
> +public MetadataResolutionRequest setRemoteRepositories(
List remoteRepositories )
> +{
> +this.remoteRepositories = remoteRepositories;
>
>  return this;
>  }
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/87c6346a/
maven-compat/src/main/java/org/apache/maven/repository/
legacy/LegacyRepositorySystem.java
> --
> diff --git a/maven-compat/src/main/java/org/apache/maven/repository/
legacy/LegacyRepositorySystem.java b/maven-compat/src/main/java/
org/apache/maven/repository/legacy/LegacyRepositorySystem.java
> index bd5988a..8d4d407 100644
> --- a/maven-compat/src/main/java/org/apache/maven/repository/
legacy/LegacyRepositorySystem.java
> +++ b/maven-compat/src/main/java/org/apache/maven/repository/
legacy/LegacyRepositorySystem.java
> @@ -329,7 +329,7 @@ public class LegacyRepositorySystem
>  DelegatingLocalArtifactRepository
delegatingLocalRepository =
>  (DelegatingLocalArtifactRepository)
request.getLocalRepository();
>
> -LocalArtifactRepository orig = delegatingLocalRepository.
getIdeWorspace();
> +LocalArtifactRepository orig = delegatingLocalRepository.
getIdeWorkspace();
>
>  delegatingLocalRepository.setIdeWorkspace( ideWorkspace
);
>
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/87c6346a/
maven-core/src/main/java/org/apache/maven/repository/
DelegatingLocalArtifactRepository.java
> --
> diff --git 

Re: MNG-5805 and 3.4.0-SNAPSHOT

[Stuart McCulloch]

Also note the MNG-5805 style of lifecycle configuration should go inside:

  

  
foo
 

rather than:

  

  
foo
 

There was a bug in Maven 3.3.9 where it accepted MNG-5805 style configuration 
using  but this broke backwards compatibility with plugins like 
flexmojos:

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

If you stick with  then your MNG-5805 lifecycle configuration 
will work with 3.3.9 and 3.4.0+

--  
Cheers, Stuart


On Saturday, 12 November 2016 at 22:07, Stuart McCulloch wrote:

> Hi Mirko,
>  
> Could you provide more details on how to recreate this?
>  
> While 3.4.0-SNAPSHOT uses a different version of sisu-plexus to 3.3.9 (0.3.3 
> vs 0.3.2) the XML conversion code didn't change between those versions.
>  
> There have been changes to the Maven lifecycle components since 3.3.9 which 
> could influence parsing - but I’d need a sample build/testcase to narrow it 
> down further.
>  
> --
> Cheers, Stuart
>  
> On Saturday, 12 November 2016 at 21:33, Mirko Friedenhagen wrote:
>  
> > Hello,
> >  
> > I am playing with MNG-5805 which works fine with Maven 3.3.9. However
> > with a late SNAPSHOT from 2016-10-31 I get the following:
> >  
> > 9180 [INFO] 1788 [WARNING] Expected TEXT, not XML: START_TAG seen
> > .. @3:217
> >  
> > 9180 [INFO] java.lang.Throwable
> >  
> > 9181 [INFO] at 
> > org.eclipse.sisu.plexus.PlexusXmlBeanConverter.parseBean(PlexusXmlBeanConverter.java:267)
> >  
> >  
> > Regards Mirko
> > https://issues.apache.org/jira/browse/MNG-5805
> >  
> > Apache Maven 3.4.0-SNAPSHOT (a277f6f43a9b52c17b6aa2af069554edd2b0e42e;
> > 2016-10-31T21:53:43+01:00)
> > --
> > http://illegalstateexception.blogspot.com/
> > https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> > https://bitbucket.org/mfriedenhagen/
> >  
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> > (mailto:dev-unsubscr...@maven.apache.org)
> > For additional commands, e-mail: dev-h...@maven.apache.org 
> > (mailto:dev-h...@maven.apache.org)
> >  
> >  
> >  
>  
>  

Re: MNG-5805 and 3.4.0-SNAPSHOT

[Stuart McCulloch]

Hi Mirko,

Could you provide more details on how to recreate this?

While 3.4.0-SNAPSHOT uses a different version of sisu-plexus to 3.3.9 (0.3.3 vs 
0.3.2) the XML conversion code didn't change between those versions.

There have been changes to the Maven lifecycle components since 3.3.9 which 
could influence parsing - but I’d need a sample build/testcase to narrow it 
down further.

--
Cheers, Stuart

On Saturday, 12 November 2016 at 21:33, Mirko Friedenhagen wrote:

> Hello,
>  
> I am playing with MNG-5805 which works fine with Maven 3.3.9. However
> with a late SNAPSHOT from 2016-10-31 I get the following:
>  
> 9180 [INFO] 1788 [WARNING] Expected TEXT, not XML: START_TAG seen
> .. @3:217
>  
> 9180 [INFO] java.lang.Throwable
>  
> 9181 [INFO] at 
> org.eclipse.sisu.plexus.PlexusXmlBeanConverter.parseBean(PlexusXmlBeanConverter.java:267)
>  
>  
> Regards Mirko
> https://issues.apache.org/jira/browse/MNG-5805
>  
> Apache Maven 3.4.0-SNAPSHOT (a277f6f43a9b52c17b6aa2af069554edd2b0e42e;
> 2016-10-31T21:53:43+01:00)
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
>  
>  

Re: 3.4.0 SNAPSHOT breaks Log4j build

[Stuart McCulloch]

On Wednesday, 6 July 2016 at 22:17, Christian Schulte wrote:
> Am 07/06/16 um 23:08 schrieb Stuart McCulloch:
> > On Wednesday, 6 July 2016 at 21:53, Christian Schulte wrote:
> > > Am 07/06/16 um 22:21 schrieb Ralph Goers:
> > > > This is an interesting situation. The classes that use Jackson are all 
> > > > considered optional in Log4j, so having optional set to true is indeed 
> > > > what is desired. However, we require those dependencies to compile and 
> > > > to run the unit tests. With scope set to test I would expect that the 
> > > > non-test classes that need them would fail to compile. So it sounds 
> > > > like we have to make sure all transitive dependencies needed for 
> > > > testing are also specified with optional set to true?
> > > >  
> > > > Ralph
> > > >  
> > >  
> > >  
> > > Not sure I understand the situation correctly. If the scope is set to
> > > test, it's not available in any other scope than test. Could you please
> > > point me at the POM in question? So I can 'mvn compile' that project
> > > successfully and you would expect it to not compile due to some optional
> > > transitive dependency?
> > >  
> > >  
> > >  
> >  
> >  
> > Hi Christian,
> >  
> > Gary posted a link to the build in his original post.
> >  
> > Basically at the moment it has a dependencyManagement section in the 
> > top-level pom that declares various jackson dependencies as optional, 
> > including jackson-module-jaxb-annotations. The log4j-core sub-project 
> > declares a direct dependency to jackson-dataformat-xml with compile scope, 
> > marked as optional (also note that jackson-module-jaxb-annotations is a 
> > transitive dependency of jackson-dataformat-xml).
> >  
> > With the fix for MNG-5227 the transitive dependency to 
> > jackson-module-jaxb-annotations is managed as optional and is removed from 
> > the compile and test classpath. Because the code doesn’t directly depend on 
> > jackson-module-jaxb-annotations then it compiles ok. However, the tests 
> > fail because both jackson-dataformat-xml and 
> > jackson-module-jaxb-annotations are needed at test time.
> >  
> > Without the fix for MNG-5227 the optional flags in the dependencyManagement 
> > section are ignored, and jackson-module-jaxb-annotations is included on the 
> > compile and test classpath (because the optional jackson-dataformat-xml 
> > dependency is selected and jackson-module-jaxb-annotations is now seen as a 
> > non-optional transitive dependency of jackson-dataformat-xml).
> Ok. That's MNG-5935.
>  
>  

But also related to MNG-5227 right?  Since the build fails with the old maven 
snapshot that had the fix for MNG-5227 (and the fix for MNG-5935) but passes 
with the more recent snapshot where MNG-5227 was reverted (but still contains 
the fix for MNG-5935)
>  
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
>  
>  

Re: 3.4.0 SNAPSHOT breaks Log4j build

[Stuart McCulloch]

On Wednesday, 6 July 2016 at 21:53, Christian Schulte wrote:
> Am 07/06/16 um 22:21 schrieb Ralph Goers:
> > This is an interesting situation. The classes that use Jackson are all 
> > considered optional in Log4j, so having optional set to true is indeed what 
> > is desired. However, we require those dependencies to compile and to run 
> > the unit tests. With scope set to test I would expect that the non-test 
> > classes that need them would fail to compile. So it sounds like we have to 
> > make sure all transitive dependencies needed for testing are also specified 
> > with optional set to true?
> >  
> > Ralph
>  
> Not sure I understand the situation correctly. If the scope is set to
> test, it's not available in any other scope than test. Could you please
> point me at the POM in question? So I can 'mvn compile' that project
> successfully and you would expect it to not compile due to some optional
> transitive dependency?
>  
>  

Hi Christian,

Gary posted a link to the build in his original post.

Basically at the moment it has a dependencyManagement section in the top-level 
pom that declares various jackson dependencies as optional, including 
jackson-module-jaxb-annotations. The log4j-core sub-project declares a direct 
dependency to jackson-dataformat-xml with compile scope, marked as optional 
(also note that jackson-module-jaxb-annotations is a transitive dependency of 
jackson-dataformat-xml).

With the fix for MNG-5227 the transitive dependency to 
jackson-module-jaxb-annotations is managed as optional and is removed from the 
compile and test classpath. Because the code doesn’t directly depend on 
jackson-module-jaxb-annotations then it compiles ok. However, the tests fail 
because both jackson-dataformat-xml and jackson-module-jaxb-annotations are 
needed at test time.

Without the fix for MNG-5227 the optional flags in the dependencyManagement 
section are ignored, and jackson-module-jaxb-annotations is included on the 
compile and test classpath (because the optional jackson-dataformat-xml 
dependency is selected and jackson-module-jaxb-annotations is now seen as a 
non-optional transitive dependency of jackson-dataformat-xml).

HTH
>  
> Regards,
> --  
> Christian
>  
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
>  
>  

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stuart McCulloch]

On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
> Hi to all Maven users,
>  
> If you like to help making the next Maven release better it would be  
> nice if you could help a little bit.
>  
> Please be aware of this *** This is not an official release ***
>  
> I have created downloadable packages which are available from here:
>  
> Windows: https://s.apache.org/qDs1
> Linux/Mac: https://s.apache.org/Sn7X
>  
> Every kind of feedback is helpful.
>  
> Important hint:
>  
> Based on the following issue  
> https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a  
> dependencyManagement was simply ignored with previous Maven versions.  
> This Maven version starts to handle that correct. If you have problems  
> with that please report.
>  
>  

I believe this build (git hash 227085283b6379038ec16f4cf9ad2e8869cef694) 
doesn’t actually contain the fix for MNG-5227. The previous testing snapshot 
built from 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for 
MNG-5227, but the fix was reverted to avoid breaking builds which relied on the 
old behaviour.

(this is just based on my reading of the commit history)  
>  
> This is only a current state of development (Git hash:  
> 227085283b6379038ec16f4cf9ad2e8869cef694) to get some feedback from the  
> community...
>  
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>  
> It would be nice if those who had found issues to retest their scenarios.
>  
>  
> Kind regards
> Karl Heinz Marbaise
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
>  
>  

Re: 3.4.0 SNAPSHOT breaks Log4j build

[Stuart McCulloch]

BTW, https://issues.apache.org/jira/browse/MNG-5227 was about making the 
optional flag of a dependency manageable.

Previously any optional flags in dependencyManagement sections were ignored, 
and it looks like the Log4j build relies on that historical behaviour. For 
example the jackson dependencies are all currently marked as optional in the 
top-level dependencyManagement. With previous versions of Maven these managed 
flags were simply ignored and had no effect on the build. With the 
644ac9c40ad41bf61e3b099918af33b8eb950621 maven build these optional flags were 
now being managed across any jackson dependencies in all sub-projects. Since 
jackson-module-jaxb-annotations was not declared as a direct dependency in 
log4j-core, but was only a transitive dependency of jackson-dataformat-xml, 
this ended up being marked as ‘optional’ and removed from the test-classpath.

Removing the ‘optional’ flags from the dependencyManagement section in the 
top-level pom.xml cleans up the build and should work with both old and future 
versions of Maven.  

On Wednesday, 6 July 2016 at 19:45, Stuart McCulloch wrote:

> That looks like the build (644ac9c40ad41bf61e3b099918af33b8eb950621) before 
> MNG-5227 and other breaking changes were rolled back
>  
> I just tried with a maven distribution built from latest master 
> (227085283b6379038ec16f4cf9ad2e8869cef694) and the Log4J build is passing  
>  
> On Wednesday, 6 July 2016 at 19:24, Gary Gregory wrote:
>  
> > A while back, a post made available a 3.4.0 SNAPSHOT build for testing. So
> > I'm using it here and there.
> >  
> > To replicate the 3.4.0-S failure (works fine on 3.3.9):
> >  
> > Download
> > https://repository.apache.org/content/repositories/orgapachelogging-1020/org/apache/logging/log4j/log4j-distribution/2.6.2/log4j-distribution-2.6.2-src.zip
> >  
> > (this link will be gone in a couple of days)
> >  
> > Or checkout the tag with "git clone
> > https://git-wip-us.apache.org/repos/asf/logging-log4j2.git; and then "git
> > checkout tags/log4j-2.6.2-rc1”
> >  
> > Using the src distro with 'mvn clean package' (Maven 3.4.0-SNAPSHOT), I am
> > getting:
> >  
> > Failed tests:
> > XmlCompactFileAppenderTest.testFlushAtEndOfBatch:66 line1 incorrect:
> > [http://logging.apache.org/log4j/2.0/events;>], does not contain:
> > [ > XmlCompleteFileAppenderTest.testChildElementsAreCorrectlyIndented:139
> > line3 incorrect: [], must have two-space indentation
> > XmlCompleteFileAppenderTest.testFlushAtEndOfBatch:74 line3
> > XmlFileAppenderTest.testFlushAtEndOfBatch:64 line1
> > Tests in error:
> > MarkerMixInXmlTest>MarkerMixInTest.setUp:45 ╗ NoClassDefFound
> > com/fasterxml/ja...
> > MarkerMixInXmlTest>MarkerMixInTest.setUp:45 ╗ NoClassDefFound
> > com/fasterxml/ja...
> > MarkerMixInXmlTest>MarkerMixInTest.setUp:45 ╗ NoClassDefFound
> > com/fasterxml/ja...
> > ThrowableProxyTest.testIoContainerAsXml:95->testIoContainer:78 ╗
> > NoClassDefFound
> > StackTraceElementMixInTest.testLog4jXmlObjectMapper:58->roundtrip:51 ╗
> > NoClassDefFound
> > XmlLayoutTest.testLayout:214 ╗ NoClassDefFound
> > com/fasterxml/jackson/module/ja...
> > XmlLayoutTest.testLayoutLoggerName:262 ╗ NoClassDefFound
> > com/fasterxml/jackson...
> > XmlLayoutTest.testLocationOffCompactOffMdcOff:268->testAllFeatures:122 ╗
> > NoClassDefFound
> > XmlLayoutTest.testLocationOnCompactOnMdcOn:273->testAllFeatures:122 ╗
> > NoClassDefFound
> > org.apache.logging.log4j.core.net.server.SslXmlSocketServerTest.org.apache.logging.log4j.core.net.server.SslXmlSocketServerTest
> > Run 1: SslXmlSocketServerTest.setupClass:64 ╗ NoClassDefFound
> > com/fasterxml/jackson/m...
> > Run 2: SslXmlSocketServerTest.tearDownClass:71 NullPointer
> >  
> > org.apache.logging.log4j.core.net.server.TcpXmlSocketServerTest.org.apache.logging.log4j.core.net.server.TcpXmlSocketServerTest
> > Run 1: TcpXmlSocketServerTest.setupClass:38 ╗ NoClassDefFound
> > com/fasterxml/jackson/m...
> > Run 2: TcpXmlSocketServerTest.tearDownClass:45 NullPointer
> >  
> > org.apache.logging.log4j.core.net.server.UdpXmlSocketServerTest.org.apache.logging.log4j.core.net.server.UdpXmlSocketServerTest
> > Run 1: UdpXmlSocketServerTest.setupClass:38 ╗ NoClassDefFound
> > com/fasterxml/jackson/m...
> > Run 2: UdpXmlSocketServerTest.tearDownClass:44 NullPointer
> >  
> > Everything works fine with Maven 3.3.9.
> >  
> > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> > 2015-11-10T08:41:47-08:00)
> > Maven home: E:\Java\apache-maven-3.3.9
> > Java version: 1.8.0_91, vendor: Oracle Corporation
> &

Re: 3.4.0 SNAPSHOT breaks Log4j build

[Stuart McCulloch]

That looks like the build (644ac9c40ad41bf61e3b099918af33b8eb950621) before 
MNG-5227 and other breaking changes were rolled back

I just tried with a maven distribution built from latest master 
(227085283b6379038ec16f4cf9ad2e8869cef694) and the Log4J build is passing  

On Wednesday, 6 July 2016 at 19:24, Gary Gregory wrote:

> A while back, a post made available a 3.4.0 SNAPSHOT build for testing. So
> I'm using it here and there.
>  
> To replicate the 3.4.0-S failure (works fine on 3.3.9):
>  
> Download
> https://repository.apache.org/content/repositories/orgapachelogging-1020/org/apache/logging/log4j/log4j-distribution/2.6.2/log4j-distribution-2.6.2-src.zip
>  
> (this link will be gone in a couple of days)
>  
> Or checkout the tag with "git clone
> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git; and then "git
> checkout tags/log4j-2.6.2-rc1”
>  
> Using the src distro with 'mvn clean package' (Maven 3.4.0-SNAPSHOT), I am
> getting:
>  
> Failed tests:
> XmlCompactFileAppenderTest.testFlushAtEndOfBatch:66 line1 incorrect:
> [http://logging.apache.org/log4j/2.0/events;>], does not contain:
> [ XmlCompleteFileAppenderTest.testChildElementsAreCorrectlyIndented:139
> line3 incorrect: [], must have two-space indentation
> XmlCompleteFileAppenderTest.testFlushAtEndOfBatch:74 line3
> XmlFileAppenderTest.testFlushAtEndOfBatch:64 line1
> Tests in error:
> MarkerMixInXmlTest>MarkerMixInTest.setUp:45 ╗ NoClassDefFound
> com/fasterxml/ja...
> MarkerMixInXmlTest>MarkerMixInTest.setUp:45 ╗ NoClassDefFound
> com/fasterxml/ja...
> MarkerMixInXmlTest>MarkerMixInTest.setUp:45 ╗ NoClassDefFound
> com/fasterxml/ja...
> ThrowableProxyTest.testIoContainerAsXml:95->testIoContainer:78 ╗
> NoClassDefFound
> StackTraceElementMixInTest.testLog4jXmlObjectMapper:58->roundtrip:51 ╗
> NoClassDefFound
> XmlLayoutTest.testLayout:214 ╗ NoClassDefFound
> com/fasterxml/jackson/module/ja...
> XmlLayoutTest.testLayoutLoggerName:262 ╗ NoClassDefFound
> com/fasterxml/jackson...
> XmlLayoutTest.testLocationOffCompactOffMdcOff:268->testAllFeatures:122 ╗
> NoClassDefFound
> XmlLayoutTest.testLocationOnCompactOnMdcOn:273->testAllFeatures:122 ╗
> NoClassDefFound
> org.apache.logging.log4j.core.net.server.SslXmlSocketServerTest.org.apache.logging.log4j.core.net.server.SslXmlSocketServerTest
> Run 1: SslXmlSocketServerTest.setupClass:64 ╗ NoClassDefFound
> com/fasterxml/jackson/m...
> Run 2: SslXmlSocketServerTest.tearDownClass:71 NullPointer
>  
> org.apache.logging.log4j.core.net.server.TcpXmlSocketServerTest.org.apache.logging.log4j.core.net.server.TcpXmlSocketServerTest
> Run 1: TcpXmlSocketServerTest.setupClass:38 ╗ NoClassDefFound
> com/fasterxml/jackson/m...
> Run 2: TcpXmlSocketServerTest.tearDownClass:45 NullPointer
>  
> org.apache.logging.log4j.core.net.server.UdpXmlSocketServerTest.org.apache.logging.log4j.core.net.server.UdpXmlSocketServerTest
> Run 1: UdpXmlSocketServerTest.setupClass:38 ╗ NoClassDefFound
> com/fasterxml/jackson/m...
> Run 2: UdpXmlSocketServerTest.tearDownClass:44 NullPointer
>  
> Everything works fine with Maven 3.3.9.
>  
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>  
> Apache Maven 3.4.0-SNAPSHOT (644ac9c40ad41bf61e3b099918af33b8eb950621;
> 2016-06-11T12:17:57-07:00)
> Maven home: E:\Java\apache-maven-3.4.0-SNAPSHOT\bin\..
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "Windows 7", version: "6.1", arch: "amd64", family: "Windows"
>  
> Thank you
> Gary (Apache Logging PMC)
>  
> --  
> E-Mail: garydgreg...@gmail.com (mailto:garydgreg...@gmail.com) | 
> ggreg...@apache.org (mailto:ggreg...@apache.org)
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>  
>  

Re: 3.4.0-SNAPSHOT failure with findbugs Re: colorized Maven output

[Stuart McCulloch]

On Friday, 10 June 2016 at 21:33, Arnaud Héritier wrote:
> I need to investigate but I have a bug with findbugs and 3.4.0-SNAPSHOT
>  
> [ERROR] Failed to execute goal 
> org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs (findbugs) on project 
> support-analytics: Unable to parse configuration of mojo 
> org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs for parameter 
> pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts' with 
> value '${plugin.artifacts}' of type 
> java.util.Collections.UnmodifiableRandomAccessList to property of type 
> java.util.ArrayList -> [Help 1]
>  
> Is there someone who can verify that he can reproduce the issue with this pom 
> please ?
https://github.com/gleclaire/findbugs-maven-plugin/pull/35 ?
> Cheers
>  
>  
> On Fri, Jun 10, 2016 at 9:26 AM, Arnaud Héritier  (mailto:aherit...@gmail.com)> wrote:
> > \o/
> >  
> > On Fri, Jun 10, 2016 at 8:39 AM, Hervé BOUTEMY  > (mailto:herve.bout...@free.fr)> wrote:
> > > here it is:
> > > I merged Christian fix
> > > and I managed to make ITs run as embedded (ASF Jenkins should confirm what
> > > works on my machine)
> > >  
> > > if everything goes well, I'll merge to master tonight
> > >  
> > > Regards,
> > >  
> > > Hervé
> > >  
> > > Le jeudi 9 juin 2016 09:20:38 Christian Schulte a écrit :
> > > > Am 06/09/16 um 09:04 schrieb Petar Tahchiev:
> > > > > Hello,
> > > > >
> > > > > I checked on Windows with Herve's [1]. Unfortunately I am unable to 
> > > > > build
> > > > >
> > > > > my project with 3.4.0-SNAPSHOT. I have this dependency:
> > > > > 
> > > > >
> > > > > org.drools
> > > > > drools-bom
> > > > > pom
> > > > > ${drools.version}
> > > > > import
> > > > >
> > > > > 
> > > > >
> > > > > where drools version is defined to be
> > > > > 6.4.0.Final. And when I build it I 
> > > > > get:
> > > > >
> > > > > [ERROR] Non-resolvable import POM: Failure to find
> > > > > org.kie:kie-bom:pom:${project.version} in 
> > > > > http://repo1.maven.org/maven2/
> > > > > was cached in the local repository, resolution will not be reattempted
> > > > > until the update interval of official-m2-repo has elapsed or updates 
> > > > > are
> > > > > forced @ org.drools:drools-bom:[unknown-version]
> > > > > [org.drools:drools-bom:[unknown-version]],
> > > > > [C:\Users\e-tahchpet\.m2\repository\org\drools\drools-bom\6.4.0.Final\droo
> > > > > ls-bom-6.4.0.Final.pom], line 27, column 19
> > > >
> > > > Could be a regression due to MNG-5971. It's reproducible here. Thanks
> > > > for testing a SNAPSHOT Maven version.
> > > >
> > > > > If I comment this dependency then I see some colors on windows, but 
> > > > > at the
> > > > > end of the build findbugs will break:
> > > > >
> > > > > [ERROR] Failed to execute goal
> > > > > org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs (findbugs) on
> > > > > project bom: Unable to parse configuration of mojo
> > > > > org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs for parameter
> > > > > pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts' 
> > > > > with
> > > > > value '${plugin.artifacts}' of type
> > > > > java.util.Collections.UnmodifiableRandomAccessList to property of type
> > > > > java.util.ArrayList -> [Help 1]
> > > >
> > > > That's already fixed upstream and will be fixed in the next FindBugs
> > > > plugin release.
> > > >
> > > >  > > > 4e7fe26d8f114b3c5450b86>
> > > >
> > > > Regards,
> > >  
> > >  
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> > > (mailto:dev-unsubscr...@maven.apache.org)
> > > For additional commands, e-mail: dev-h...@maven.apache.org 
> > > (mailto:dev-h...@maven.apache.org)
> > >  
> >  
> >  
> >  
> > --  
> > -
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> >  
> >  
> >  
>  
>  
>  
>  
>  
> --  
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>  
>  
>  
>  
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
>  



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;>
  4.0.0
  test
  test
  0.1.0-SNAPSHOT
  

  
org.codehaus.mojo
findbugs-maven-plugin
3.0.1

  
findbugs
verify

  check
   

Re: Archetype Maven On Windows Is Searching for BAT file

[Stuart McCulloch]

Sounds like https://issues.apache.org/jira/browse/ARCHETYPE-488 

On Wednesday, 27 April 2016 at 11:17, Petar Tahchiev wrote: 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:2.4:create-from-project
> (default-cli) on project samplestore: Error configuring command-line.
> Reason: Maven executable not found at:
> C:\apache\apache-maven-3.3.9-bin\apache-maven-3.3.9\bin\mvn.bat -> [Help 1]
> 
> It is looking for a bat file, and in my maven 3.3.9 I have mvn.cmd file.
> When I copy the mvn.cmd and rename it to mvn.bat it works fine.
> 
> This only happens with maven archetype.
> 
> Does any one know why is it looking for a bat file?
> 
> 2016-04-27 12:16 GMT+02:00 Petar Tahchiev  (mailto:paranoia...@gmail.com)>:
> 
> > Hi guys,
> > 
> > I'm on windows 10 now (yeah I know). I have a project and I want to
> > generate archetype out of it.
> > 
> > I do the command that works on linux but now it gives this:
> > 
> > 
> > 
> > 
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> > http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
> > 
> 
> 
> 
> 
> -- 
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
> 
> 

Re: NoSuchMethodError maven-plugin-testing-harness:3.0.0

[Stuart McCulloch]

FWIW, Sisu tries to maintain compatibility across different versions where 
possible - if you find that you can’t use a newer release in place of an older 
one then you can always report this (http://www.eclipse.org/sisu/support/) with 
the details and any test projects/logs. Also note that sisu-inject-bean/plexus 
artifacts from 2.4.x onwards are thin runtime wrappers around the 
org.eclipse.sisu.inject/plexus artifacts, mapping the old org.sonatype.guice 
API onto the new org.eclipse.sisu API for any clients that used that API 
directly instead of via Plexus/JSR330.

For example, if I take a Maven 3.0.5 distribution remove the 
sisu-inject-bean/plexus jars and replace them with the latest 
org.eclipse.sisu.inject/plexus jars plus javax.inject-1.jar then it still 
works. You might be able to do the same with the test classpath to exclude the 
old artifacts in favour of the new ones.

That said I would have assumed the maven-plugin-testing-harness would fully 
isolate the runtime being tested from the harness so you wouldn’t need to do 
this.

PS. which plugin are you migrating?

On Thursday, 7 January 2016 at 12:40, Tibor Digana wrote:  
> I am migrating plugin to 3.0.0 and I have a problem with a test
> because it fails due to maven-plugin-testing-harness:3.0.0 cannot call a
> method:
> setClassPathScanning(Ljava/lang/String;)Lorg/codehaus/plexus/ContainerConfiguration;
>  
> In maven-plugin-testing-harness' code the method setClassPathScanning() is
> called with String parameter but boolean is expected.
>  
> protected ContainerConfiguration setupContainerConfiguration()
> {
> ClassWorld classWorld = new ClassWorld( "plexus.core",
> Thread.currentThread().getContextClassLoader() );
>  
> ContainerConfiguration cc = new DefaultContainerConfiguration()
> .setClassWorld( classWorld )
> .setClassPathScanning( PlexusConstants.SCANNING_INDEX )
> .setAutoWiring( true )
> .setName( "maven" );
>  
> return cc;
> }
>  
> The versions are chaotic now because
> maven-plugin-testing-harness:3.0.0
> is dependent on
> maven-core:3.1.1
> with sisu-inject-plexus other than 1.4.2.
>  
> But maven-core:3.0.0 needs to have sisu-inject-plexus:1.4.2
>  
> How should I solve this?
> I tried to upgrade to maven-core:3.1.0 but got another problem.
>  
> Should we use Takari IT framework? It will cost me more time to rework all
> tests.
>  
> --  
> Cheers
> Tibor
>  
>  

Re: Would be possible to inject com.google.inject.Injector in a mojo or other component?

[Stuart McCulloch]

Hi Cristiano,

Maven core doesn’t expose the “com.google.inject” package to plugins, which 
means the Injector class seen by your plugin is different to the class seen by 
core (this is due to classworlds isolation) which is why injecting the Injector 
is not currently possible. If the “com.google.inject” package was exposed from 
core then you would be able to inject the Injector, but there is a better way 
to get what you want without requiring this:

@Inject
private Map arcrs;

This will inject a dynamic map of all components that implement Arcr, indexed 
by name. The map is lazy so instances of the components are only created when 
you attempt to get them:

Arcr selectedArcr = arcrs.get(pTracker.getNamed());

--  
Cheers, Stuart


On Wednesday, 6 January 2016 at 19:27, Cristiano Gavião wrote:

> Hi,
>  
> I have some components that implement the same interface. all of them  
> are being properly registered by sisu.
>  
> @Named(CommonMojoConstants.OCUS_PACKAGING)
> @Typed(Arcr.class)
> @Singleton
> public class IpArcrComponent implements Arcr
>  
>  
> I'm needing to control the injection in one specific case. normally I  
> can use the Injector.getInstance:
>  
> injector.getInstance(Key.get(Arcr.class,
> Names.named(pTracker.getNamed(;
>  
> But I'm getting an error (com.google.inject.ProvisionException: Unable  
> to provision) when trying to inject the Injector:
>  
> @Inject
> private Injector injector;
>  
> Its not allowed or am I missing something?
>  
> thanks,
>  
> Cristiano  

Re: Suggestions for the Announcement Mail for Maven 3.3.7 with credit to contributor/reports

[Stuart McCulloch]

BTW, the following issues should be marked as fixed in Maven 3.3.7 due to the 
upgrade to Sisu 0.3.2:  

https://issues.apache.org/jira/browse/MNG-5440
https://issues.apache.org/jira/browse/MPLUGIN-271

Another thing that might be worth mentioning is that Maven now uses the 
official Guice 4.0 release.  

--  
Cheers, Stuart


On Thursday, 29 October 2015 at 06:39, Karl Heinz Marbaise wrote:

> Hi, i have prepared an announcement mail content and want to know if  
> this would be ok...I would also emphasize the naming of  
> contributor/reports
>  
> WDYT ?
>  
> === START ==
>  
> The Apache Maven team is pleased to announce the release of
> Apache Maven 3.3.7.
>  
> http://maven.apache.org/
>  
> You can download the [appropriate sources etc. from the download  
> page](http://maven.apache.org/download.cgi).
>  
> Release Notes - Apache Maven Version 3.3.7
>  
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
>  
> Bugs:
>  
> * [MNG-5649] - Use Commons Lang's Validate to intercept invalid input
> * [MNG-5681] - Properties on command line with leading or trailing  
> quotes are stripped
> * [MNG-5721] - Possible NullPointerException in  
> org.apache.maven.repository.MetadataResolutionResult (reporter Martin  
> Schäf).
> * [MNG-5786] - Variable maven.multiModuleProjectDirectory may be set  
> incorrectly (reporter Stephan Schroevers).
> * [MNG-5787] - Moving from Maven 3.0.5 to 3.3.3 breaks plugins with  
> some dependencies on the class path (reporter Christian Schlichtherle).
> * [MNG-5796] - mvn fails when the current directory is a root drive on  
> Windows (reporter Brandon Enochs).
> * [MNG-5812] - Project base dir not fully working in Cygwin  
> (contributor tssp).
> * [MNG-5813] - Make MAVEN_OPTS env variable with mvnDebug correctly
> * [MNG-5816] - Empy maven.config cause Maven to exit with failure  
> (contributor tssp)
> * [MNG-5840] -  is used if the groupId and artifactId  
> match irrespective of the version
> * [MNG-5858] - mvn script fails to locate .mvn in current directory  
> (contributor Dave Syer).
> * [MNG-5877] - maven-aether-provider/maven-compat does not always  
> generate snapshot versions using Gregorian calendar year (contributor  
> Joseph Walton; reporter Anders Forsell).
> * [MNG-5884] - mvn script doesn't handle directories containing spaces  
> (contributor Stephen Kitt).
> * [MNG-5886] - Broken link of 'Building Maven' in README.md 
> (http://README.md) on Github  
> (reporter Shubham Chaurasia).
> * [MNG-5891] - Log file command line option description contains an  
> extra word (reporter Keith Turner).
> * [MNG-5898] - Multi-module build with ear fails to resolve war in  
> 3.3.3 (reporter Jonathan Radon).
> * [MNG-5907] -  
> org.apache.maven.repository.internal.RemoteSnapshotMetadataTest fails to  
> start at midnight
>  
> Improvements:
>  
> * [MNG-5805] - Custom packaging types: configuring  
> DefaultLifecycleMapping mojo executions (contributor Anton Tanasenko).
> * [MNG-5844] - Close IO Streams in finally or try-with-resource  
> statement (contributor Tang Xinye)
> * [MNG-5871] - make url inheritance algorithm more visible
> * [MNG-5888] - Update used modello version from 1.8.1 to 1.8.3
> * [MNG-5892] - Removing par lifecycle from default life cycle bindings
> * [MNG-5893] - Make used plugin version for maven-resources-plugin in  
> default-bindings.xml consistent
> * [MNG-5894] - Removed binding for maven-ejb3-plugin from default binding
> * [MNG-5905] - Maven build does not work with Maven 2.2.1
> * [MNG-5906] - Use canonical name for UTC timezone
> * [MNG-5911] - Upgrade maven-parent to version 27
> * [MNG-5915] - Upgrade Wagon version to 2.10
>  
> Task:
>  
> * [MNG-5887] - update Modello site url
>  
> Contributors of this release:
>  
> * tssp
> * Dave Syer
> * Joseph Walton
> * Stephen Kitt
> * Anton Tanasenko
> * Tang Xinye
>  
> Reporters of this release:
>  
> * Martin Schäf
> * Stephan Schroevers
> * Christian Schlichtherle
> * Brandon Enochs
> * Anders Forsell
> * Shubham Chaurasia
> * Keith Turner
> * Jonathan Radon
>  
> Many thanks to contributors and reporters.
>  
> Enjoy,
>  
> - The Apache Maven team
>  
> === END ==
>  
>  
> Kind regards
> Karl Heinz Marbaise
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
>  
>  

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

[Stuart McCulloch]

On Sunday, 20 September 2015 at 11:57, Robert Scholte wrote:
> Hi,
>  
> I've started running the maven-integration-testing[1] project with the  
> latest jdk9 jigsaw ea.
> I have pushed a couple of fixes to avoid too old values for source+target  
> and some other fixes.
>  
> Now there are 2 tests which suddenly fail:
> MavenITmng3864PerExecPluginConfigTest>AbstractMavenIntegrationTestCase.runTest:219->testitMNG3864:70
>   
> null expected:<2008-11-09 11:59:03> but was:
> MavenITmng3827PluginConfigTest>AbstractMavenIntegrationTestCase.runTest:219->testitMNG3827:70
>   
> null expected:<2008-11-09 11:59:03> but was:
>  
> After some investigation I can conclude that when the mojo is configured,  
> the Date parameters are still null, so it seems like there's an issue  
> exposes by plexus configuration.
>  
>  

I've tried several times, but I can't recreate these two failures - are you 
running with a non-english locale? Do they still fail when you use jdk8?

The only recent date-related change in the Sisu codebase was a patch I added 
for Dennis to use an explicit locale for date formatting:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=470780

Does it make any difference if you revert this patch? (it shouldn’t given the 
limited formats that Plexus supports, but you never know)
> To isolate the problem I've tried to build sisu.plexus [2], which also  
> requires a fresh snapshots of sisu.inject[3].
>  
>  

The Tycho build is setup to fetch snapshots via P2 if you don’t have them 
locally, but when debugging you’ll typically want to build both locally.
> The latter builds fine, but  
> when trying to build sisu.plexus with jdk9 I get the following error
>  
>  

The JDT compiler used by Tycho doesn’t support Jigsaw yet, so I’ve added a 
workaround for now to fall back to javac on jdk9:

http://git.eclipse.org/c/sisu/org.eclipse.sisu.inject.git/commit/?id=c16911ec2790b6cb33c0d0621962a08408b06fc0
http://git.eclipse.org/c/sisu/org.eclipse.sisu.plexus.git/commit/?id=cbc639794b28ca7413ac8f2c19faf5a89b7aa094
>  


>  
> [INFO]  
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Sisu Plexus ... SUCCESS [0.631s]
> [INFO] org.eclipse.sisu.plexus ... FAILURE [6.229s]
> [INFO] org.eclipse.sisu.plexus.extender .. SKIPPED
> [INFO] org.eclipse.sisu.plexus.tests . SKIPPED
> [INFO] org.eclipse.sisu.plexus.site .. SKIPPED
> [INFO]  
> 
> [INFO] BUILD FAILURE
> [INFO]  
> 
> [INFO] Total time: 53.214s
> [INFO] Finished at: Sun Sep 20 11:38:00 CEST 2015
> [INFO] Final Memory: 35M/72M
> [INFO]  
> 
> [ERROR] Failed to execute goal  
> org.eclipse.tycho:tycho-compiler-plugin:0.23.1:compile (default-compile)  
> on project org.eclipse.sisu.plexus: Compilation failure:
> Compilation failure:
> [ERROR]  
> F:\github-workspace\sisu.plexus\org.eclipse.sisu.plexus\src\org\codehaus\plexus\component\configurator\expression\TypeAwareExpressionEvaluator.java:
> [ERROR]  
> /***
> [ERROR] ^
> [ERROR] The type java.lang.Class cannot be resolved. It is indirectly  
> referenced from required .class files
> [ERROR] 1 problem (1 error)
>  
> It'll take some extra time to find the actual root cause.
>  
> Robert
>  
> [1] https://git-wip-us.apache.org/repos/asf/maven-integration-testing.git
> [2] https://github.com/eclipse/sisu.plexus.git
> [3] https://github.com/eclipse/sisu.inject.git
>  
> Op Wed, 09 Sep 2015 19:16:13 +0200 schreef Rory O'Donnell  
> :
>  
> >  
> > Hi Robert & Kristian,
> >  
> > Early-access builds of JDK 9 with Project Jigsaw are available for
> > download at jdk9.java.net/jigsaw .
> >  
> > The EA builds contain the latest prototype implementation of JSR 376
> > , the Java Platform Module
> > System,
> > as well as that of the JDK-specific APIs and tools described in JEP 261
> > .
> >  
> > If you'd like to try out the EA builds, by far the most helpful things
> > you can do are:
> >  
> > *
> >  
> > Try to run existing applications, without change, on these builds to
> > see whether the module system, or the modularization of the
> > platform, breaks your code or identifies code that depends upon
> > JDK-internal APIs or other unspecified aspects of the platform.
> >  
> > *
> >  
> > Experiment with the module system itself, perhaps by following the
> > quick start guide
> > , and start
> > thinking about how to migrate 

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

[Stuart McCulloch]

PS. the following test projects use an explicit source+target level of 1.5 
which need updating to 1.6 to pass on jdk9:

core-it-suite/src/test/resources/mng-3203/pom.xml
core-it-suite/src/test/resources/mng-5338/project/pom.xml
core-it-suite/src/test/resources/mng-5389-lifecycleParticipant-afterSession/extension/pom.xml
core-it-suite/src/test/resources/mng-5530-mojo-execution-scope/extension/pom.xml
core-it-suite/src/test/resources/mng-5530-mojo-execution-scope/extension-plugin/pom.xml
core-it-suite/src/test/resources/mng-5530-mojo-execution-scope/plugin/pom.xml
core-it-suite/src/test/resources/mng-5578-session-scope/extension/pom.xml
core-it-suite/src/test/resources/mng-5578-session-scope/extension-plugin/pom.xml
core-it-suite/src/test/resources/mng-5578-session-scope/plugin/pom.xml
core-it-suite/src/test/resources/mng-5640-lifecycleParticipant-afterSession/extension/pom.xml
core-it-suite/src/test/resources/mng-5742-build-extension-classloader/plugin/pom.xml



On Sunday, 20 September 2015 at 17:48, Stuart McCulloch wrote:

> On Sunday, 20 September 2015 at 11:57, Robert Scholte wrote:
> > Hi,
> >  
> > I've started running the maven-integration-testing[1] project with the  
> > latest jdk9 jigsaw ea.
> > I have pushed a couple of fixes to avoid too old values for source+target  
> > and some other fixes.
> >  
> > Now there are 2 tests which suddenly fail:
> > MavenITmng3864PerExecPluginConfigTest>AbstractMavenIntegrationTestCase.runTest:219->testitMNG3864:70
> >   
> > null expected:<2008-11-09 11:59:03> but was:
> > MavenITmng3827PluginConfigTest>AbstractMavenIntegrationTestCase.runTest:219->testitMNG3827:70
> >   
> > null expected:<2008-11-09 11:59:03> but was:
> >  
> > After some investigation I can conclude that when the mojo is configured,  
> > the Date parameters are still null, so it seems like there's an issue  
> > exposes by plexus configuration.
> >  
> >  
> >  
>  
> I've tried several times, but I can't recreate these two failures - are you 
> running with a non-english locale? Do they still fail when you use jdk8?
>  
> The only recent date-related change in the Sisu codebase was a patch I added 
> for Dennis to use an explicit locale for date formatting:
>  
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=470780
>  
> Does it make any difference if you revert this patch? (it shouldn’t given the 
> limited formats that Plexus supports, but you never know)
> > To isolate the problem I've tried to build sisu.plexus [2], which also  
> > requires a fresh snapshots of sisu.inject[3].
> >  
> >  
> >  
>  
> The Tycho build is setup to fetch snapshots via P2 if you don’t have them 
> locally, but when debugging you’ll typically want to build both locally.
> > The latter builds fine, but  
> > when trying to build sisu.plexus with jdk9 I get the following error
> >  
> >  
> >  
>  
> The JDT compiler used by Tycho doesn’t support Jigsaw yet, so I’ve added a 
> workaround for now to fall back to javac on jdk9:
>  
> http://git.eclipse.org/c/sisu/org.eclipse.sisu.inject.git/commit/?id=c16911ec2790b6cb33c0d0621962a08408b06fc0
> http://git.eclipse.org/c/sisu/org.eclipse.sisu.plexus.git/commit/?id=cbc639794b28ca7413ac8f2c19faf5a89b7aa094
> >  
>  
>  
> > [INFO]  
> > 
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] Sisu Plexus ... SUCCESS [0.631s]
> > [INFO] org.eclipse.sisu.plexus ... FAILURE [6.229s]
> > [INFO] org.eclipse.sisu.plexus.extender .. SKIPPED
> > [INFO] org.eclipse.sisu.plexus.tests . SKIPPED
> > [INFO] org.eclipse.sisu.plexus.site .. SKIPPED
> > [INFO]  
> > 
> > [INFO] BUILD FAILURE
> > [INFO]  
> > 
> > [INFO] Total time: 53.214s
> > [INFO] Finished at: Sun Sep 20 11:38:00 CEST 2015
> > [INFO] Final Memory: 35M/72M
> > [INFO]  
> > 
> > [ERROR] Failed to execute goal  
> > org.eclipse.tycho:tycho-compiler-plugin:0.23.1:compile (default-compile)  
> > on project org.eclipse.sisu.plexus: Compilation failure:
> > Compilation failure:
> > [ERROR]  
> > F:\github-workspace\sisu.plexus\org.eclipse.sisu.plexus\src\org\codehaus\plexus\component\configurator\expression\TypeAwareExpressionEvaluator.java:
> > [ERROR]  
> > /***

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

[Stuart McCulloch]

Hi Robert,

Apply this patch which contains a fix for deep classpath scanning under Jigsaw 
(this mode isn’t used by Maven at runtime, just this test)

https://github.com/apache/maven/pull/66

or alternatively change DefaultMavenExecutionRequestPopulatorTest to use the 
component index rather than deep classpath scanning:

diff --git 
a/maven-core/src/test/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulatorTest.java
 
b/maven-core/src/test/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulatorTest.java
index 15a7a7b..b86198b 100644
--- 
a/maven-core/src/test/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulatorTest.java
+++ 
b/maven-core/src/test/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulatorTest.java
@@ -29,6 +29,8 @@
  * under the License.
  */
  
+import org.eclipse.sisu.space.BeanScanning;
+
 public class DefaultMavenExecutionRequestPopulatorTest
 extends InjectedTestCase
 {
@@ -59,4 +61,10 @@ public void testPluginRepositoryInjection()
 assertEquals( r.getId(), repositories.get( 0 ).getId() );
 assertEquals( r.getUrl(), repositories.get( 0 ).getUrl() );
 }
+
+@Override
+public BeanScanning scanning()
+{
+return BeanScanning.GLOBAL_INDEX;
+}
 }


On Wednesday, 16 September 2015 at 09:55, Robert Scholte wrote:

> I'm just going to continue with the next failure:
>  
> ---
> Test set:  
> org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest
> ---
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.002 sec  
> <<< FAILURE! - in  
> org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest
> testPluginRepositoryInjection(org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest)
>   
> Time elapsed: 0.001 sec <<< ERROR!
> com.google.inject.CreationException: Unable to create injector, see the  
> following errors:
>  
> 1) null returned by binding at org.eclipse.sisu.wire.LocatorWiring
> but  
> org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest.testee  
> is not @Nullable
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> for field at  
> org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest.testee(Unknown
>   
> Source)
> at  
> org.eclipse.sisu.launch.InjectedTestCase$SetUpModule.configure(InjectedTestCase.java:84)
>   
> (via modules: org.eclipse.sisu.wire.WireModule ->  
> org.eclipse.sisu.launch.InjectedTestCase$SetUpModule)
>  
> 1 error
> at  
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:448)
> at  
> com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:176)
> at  
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:110)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at  
> org.eclipse.sisu.launch.InjectedTestCase.setUp(InjectedTestCase.java:61)
> at junit.framework.TestCase.runBare(TestCase.java:139)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at  
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at  
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at  
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at  
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at  
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at  
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at  
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>  
>  
> this happens when Maven master/trunk with Maven 3.3.3
>  
> @Stuart, something you can explain?
>  
> Robert
>  
>  
> Op Wed, 16 Sep 2015 09:32:10 +0200 schreef Robert Scholte  
> :
>  
> > It was a jigsaw bug, should be fixed with  
> > http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/948a1770620e
> >  
> > Op Mon, 14 Sep 2015 07:23:17 +0200 schreef Olivier Lamy  
> > :
> >  
> > > I didn't have a deep look but I guess yes.
> > >  
> > >  
> > > On 11 September 2015 at 04:43, Robert Scholte  > > (mailto:rfscho...@apache.org)>  
> > > wrote:
> > >  
> > > > 

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

[Stuart McCulloch]

PS. you should also update animal-sniffer-maven-plugin to 1.14 to pick up the 
fix for MANIMALSNIFFER-49

On Wednesday, 16 September 2015 at 10:20, Stuart McCulloch wrote:

> Hi Robert,
>  
> Apply this patch which contains a fix for deep classpath scanning under 
> Jigsaw (this mode isn’t used by Maven at runtime, just this test)
>  
> https://github.com/apache/maven/pull/66
>  
> or alternatively change DefaultMavenExecutionRequestPopulatorTest to use the 
> component index rather than deep classpath scanning:
>  
> diff --git 
> a/maven-core/src/test/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulatorTest.java
>  
> b/maven-core/src/test/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulatorTest.java
> index 15a7a7b..b86198b 100644
> --- 
> a/maven-core/src/test/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulatorTest.java
> +++ 
> b/maven-core/src/test/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulatorTest.java
> @@ -29,6 +29,8 @@
>   * under the License.
>   */
>   
> +import org.eclipse.sisu.space.BeanScanning;
> +
>  public class DefaultMavenExecutionRequestPopulatorTest
>  extends InjectedTestCase
>  {
> @@ -59,4 +61,10 @@ public void testPluginRepositoryInjection()
>  assertEquals( r.getId(), repositories.get( 0 ).getId() );
>  assertEquals( r.getUrl(), repositories.get( 0 ).getUrl() );
>  }
> +
> +@Override
> +public BeanScanning scanning()
> +{
> +return BeanScanning.GLOBAL_INDEX;
> +}
>  }
>  
>  
> On Wednesday, 16 September 2015 at 09:55, Robert Scholte wrote:
>  
> > I'm just going to continue with the next failure:
> >  
> > ---
> > Test set:  
> > org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest
> > ---
> > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.002 sec  
> > <<< FAILURE! - in  
> > org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest
> > testPluginRepositoryInjection(org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest)
> >   
> > Time elapsed: 0.001 sec <<< ERROR!
> > com.google.inject.CreationException: Unable to create injector, see the  
> > following errors:
> >  
> > 1) null returned by binding at org.eclipse.sisu.wire.LocatorWiring
> > but  
> > org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest.testee 
> >  
> > is not @Nullable
> > while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> > for field at  
> > org.apache.maven.execution.DefaultMavenExecutionRequestPopulatorTest.testee(Unknown
> >   
> > Source)
> > at  
> > org.eclipse.sisu.launch.InjectedTestCase$SetUpModule.configure(InjectedTestCase.java:84)
> >   
> > (via modules: org.eclipse.sisu.wire.WireModule ->  
> > org.eclipse.sisu.launch.InjectedTestCase$SetUpModule)
> >  
> > 1 error
> > at  
> > com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:448)
> > at  
> > com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:176)
> > at  
> > com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:110)
> > at com.google.inject.Guice.createInjector(Guice.java:96)
> > at com.google.inject.Guice.createInjector(Guice.java:73)
> > at com.google.inject.Guice.createInjector(Guice.java:62)
> > at  
> > org.eclipse.sisu.launch.InjectedTestCase.setUp(InjectedTestCase.java:61)
> > at junit.framework.TestCase.runBare(TestCase.java:139)
> > at junit.framework.TestResult$1.protect(TestResult.java:122)
> > at junit.framework.TestResult.runProtected(TestResult.java:142)
> > at junit.framework.TestResult.run(TestResult.java:125)
> > at junit.framework.TestCase.run(TestCase.java:129)
> > at junit.framework.TestSuite.runTest(TestSuite.java:255)
> > at junit.framework.TestSuite.run(TestSuite.java:250)
> > at  
> > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> > at  
> > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> > at  
> > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> > at  
> > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> > at  
> > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader

Re: JavaxToolsCompiler

[Stuart McCulloch]

Yes, the issue is that ToolProvider.getSystemJavaCompiler() is returning null 
when using the Jigsaw EA with Maven.

AFAICT this is because it’s now using the service loader mechanism which is 
influenced by the Thread’s context ClassLoader  

The following patch to make sure Maven uses the system context when looking up 
the compiler appears to solve the issue:

https://github.com/codehaus-plexus/plexus-compiler/pull/13

--  
Cheers, Stuart


On Monday, 14 September 2015 at 19:27, Alan Bateman wrote:

> On 14/09/2015 17:40, Robert Scholte wrote:
> > Hi,
> >  
> > On behalf of the Apache Maven team I'd like to ask for advice for  
> > changing the JavaxToolsCompiler[1]
> > This implementation is used when java code is being compiled with  
> > Maven *by default*, so right now when pointing JAVA_HOME to the latest  
> > JDK9 version builds will fail.
> > There are other ways to compile, e.g. use the fork-parameter[2] or  
> > with toolchains[3], but what I'd like to know is whether it is still  
> > possible/valid to use javax.tools.JavaCompiler and is so: how should  
> > we rewrite this code?
> >  
>  
>  
> Thanks for bringing this up as a few people have reported issues with  
> Maven not finding the compiler.
>  
> Just to be clear, are you seeing this issue with the regular JDK 9 EA  
> builds or just the Jigsaw EA builds? Did this start when tools.jar went  
> away? I just did a quick test to check that  
> ToolProvider.getSystemJavaCompiler() is returning the system  
> JavaCompiler is returned for both builds (and it is). Is the issue that  
> you are seeing that getSystemJavaCompiler() is returning null?
>  
> -Alan.
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
>  
>  

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

[Stuart McCulloch]

FYI, the plexus-component-metadata exception should be fixed by:  

https://github.com/sonatype/plexus-containers/pull/2

basically ClassLoader.getResourceAsStream returns null for 
“java/lang/Object.class” in jigsaw - so this skips gleaning java/lang/Object
( an alternative solution would be to return null from “readClass2” when the 
inputStream is null, but that could have wider implications )  

--  
Cheers, Stuart


On Wednesday, 9 September 2015 at 22:47, Robert Scholte wrote:

> Hi,
>  
> My first results when building Apache Maven 3.3.7-SNAPSHOT
> Without extra configuration it fails with the message:
> No compiler is provided in this environment. Perhaps you are running on a  
> JRE rather than a JDK?
>  
> However, if I add the following arguments it at least continues:
> -Dmaven.compiler.executable=D:\jdk1.9.0\bin\javac.exe -Dmaven.compiler.fork
>  
> So this is something we need to fix on our side. If I recall correctly we  
> do a tools.jar check somewhere, will require some extra investigation.
>  
> The build doesn't complete, it fails with the exception below, but  
> according to the message we need an improved version from ASM first.
>  
> best,
> Robert
>  
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute  
> goal org.codehaus.plexus:plexus-component-metadata:1.5.5:generate-metadata  
> (default) on project maven-model-builder: Error generating metadata:
> at  
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 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:116)
> at  
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at  
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at  
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at  
> sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0 
> (mailto:java.base@9.0)/Native Method)
> at  
> sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0 
> (mailto:java.base@9.0)/NativeMethodAccessorImpl.java:62)
> at  
> sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0 
> (mailto:java.base@9.0)/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9.0 
> (mailto:java.base@9.0)/Method.java:517)
> at  
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at  
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at  
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at  
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error  
> generating metadata:
> at  
> org.codehaus.plexus.maven.plugin.PlexusDescriptorMojo.execute(PlexusDescriptorMojo.java:86)
> at  
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at  
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by: java.lang.Exception: Failed to extract descriptors
> at  
> org.codehaus.plexus.metadata.DefaultMetadataGenerator.generateDescriptor(DefaultMetadataGenerator.java:86)
> at  
> org.codehaus.plexus.maven.plugin.PlexusDescriptorMojo.execute(PlexusDescriptorMojo.java:82)
> ... 22 more
> Caused by: org.codehaus.plexus.metadata.gleaner.ComponentGleanerException:  
> Can't read class java/lang/Object
> at  
> org.codehaus.plexus.metadata.gleaner.AnnotationComponentGleaner.readClass2(AnnotationComponentGleaner.java:161)
> at  
> org.codehaus.plexus.metadata.gleaner.AnnotationComponentGleaner.getClasses(AnnotationComponentGleaner.java:180)
> at  
> org.codehaus.plexus.metadata.gleaner.AnnotationComponentGleaner.glean(AnnotationComponentGleaner.java:100)
> at  
> org.codehaus.plexus.metadata.ClassComponentDescriptorExtractor.extract(ClassComponentDescriptorExtractor.java:145)
> at  
> org.codehaus.plexus.metadata.ClassComponentDescriptorExtractor.extract(ClassComponentDescriptorExtractor.java:79)
> at  
> org.codehaus.plexus.metadata.DefaultMetadataGenerator.generateDescriptor(DefaultMetadataGenerator.java:78)
> ... 23 more
> Caused by: java.io.IOException: Class not found
> at org.objectweb.asm.ClassReader.a 

Re: Maven archetype version

[Stuart McCulloch]

So… https://git-wip-us.apache.org/repos/asf/maven-archetype.git (read+write) 
has the post git-svn commits and the 2.3 release tag

While… git://git.apache.org/maven-archetype.git (read-only) only has the 
git-svn commits and is the one mirrored to github

Should git://git.apache.org/maven-archetype.git now be pulling from 
https://git-wip-us.apache.org/repos/asf/maven-archetype.git instead of git-svn 
like other Maven git repos?  

On Sunday, 26 April 2015 at 21:01, Stuart McCulloch wrote:

 Odd, this view shows several commits in the canonical repository that aren’t 
 in github, including the 2.3 release tag:
  
 https://git-wip-us.apache.org/repos/asf?p=maven-archetype.git;a=shortlog
  
 but checking out the canonical repository from 
 git://git.apache.org/maven-archetype.git 
 (http://git.apache.org/maven-archetype.git) doesn’t show these commits
  
 It’s almost as if the git repository has been rewound back to the last 
 git-svn commit:
  
 https://git-wip-us.apache.org/repos/asf?p=maven-archetype.git;a=commit;h=226215c287648629ab51d87be0b44df0218b4351
  
  
 On Sunday, 26 April 2015 at 20:25, Petar Tahchiev wrote:
  
  Hi guys,
   
  I can see in central version 2.3 of the maven-archetype plugin is out:
   
  http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/
   
  but at the same time in master pom.xml in github the version is 2.3-SNAPSHOT
   
  https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/pom.xml
   
  Is there something I'm missing?
   
  --  
  Regards, Petar!
  Karlovo, Bulgaria.
  ---
  Public PGP Key at:
  https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
  Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
   
   
   
  
  

Re: Maven archetype version

[Stuart McCulloch]

Odd, this view shows several commits in the canonical repository that aren’t in 
github, including the 2.3 release tag:

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

but checking out the canonical repository from 
git://git.apache.org/maven-archetype.git doesn’t show these commits

It’s almost as if the git repository has been rewound back to the last git-svn 
commit:

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


On Sunday, 26 April 2015 at 20:25, Petar Tahchiev wrote:

 Hi guys,
  
 I can see in central version 2.3 of the maven-archetype plugin is out:
  
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/
  
 but at the same time in master pom.xml in github the version is 2.3-SNAPSHOT
  
 https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/pom.xml
  
 Is there something I'm missing?
  
 --  
 Regards, Petar!
 Karlovo, Bulgaria.
 ---
 Public PGP Key at:
 https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
  
  

Re: [VOTE] Maven 3.3.3 Release

[Stuart McCulloch]

On Sunday, 26 April 2015 at 17:34, Jason van Zyl wrote:
 Did you create an issue in JIRA, I still don't know exactly what the problem 
 is.
  
  

AFAICT the underlying issue is that the MAVEN_OPTS setting can be reset when 
the mvn script sources .mavenrc

Before 3.3.x the mvnDebug script was a tweaked copy of mvn so this didn’t make 
any difference to debugging as MAVEN_DEBUG_OPTS was still referenced in the 
final command.

For 3.3.x onwards the mvnDebug script sets MAVEN_OPTS to “$MAVEN_OPTS 
$MAVEN_DEBUG_OPTS” and then invokes the mvn script... which means that if 
MAVEN_OPTS is subsequently reset by .mavenrc in the mvn script then the debug 
settings are lost. You can recreate this by simply adding 
MAVEN_OPTS=“-showversion” to your .mavenrc

One fix could be to source /etc/mavenrc and .mavenrc early on in mvnDebug (as 
done in the mvn script) and then set MAVEN_SKIP_RC=1 when invoking mvn with the 
combined MAVEN_OPT setting. This should stop it getting reset in the mvn script 
and allow the debug settings to pass through.
  
 On Apr 26, 2015, at 2:12 AM, Mark Struberg strub...@yahoo.de 
 (mailto:strub...@yahoo.de) wrote:
  
  +1
   
  The problem I have with mvnDebug on OSX cmd line seems to be there in older 
  3.3.x versions already. So 3.3.3 is at least better than 3.3.2. We should 
  really fix this in the next version. But otherwise the release looks good.
   
  LieGrue,
  strub
   
   
   Am 25.04.2015 um 23:45 schrieb Mark Derricutt m...@talios.com 
   (mailto:m...@talios.com):

   On 26 Apr 2015, at 9:23, Jason van Zyl wrote:

Great, thanks for testing Mirko.

   Not seeing any binding votes?

   --  
   Mark Derricutt
   http://www.theoryinpractice.net
   http://www.chaliceofblood.net
   http://plus.google.com/+MarkDerricutt
   http://twitter.com/talios
   http://facebook.com/mderricutt

   
   
   
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
  (mailto:dev-unsubscr...@maven.apache.org)
  For additional commands, e-mail: dev-h...@maven.apache.org 
  (mailto:dev-h...@maven.apache.org)
   
  
  
 Thanks,
  
 Jason
  
 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
  
 We know what we are, but know not what we may be.
  
 -- Shakespeare
  
  
  
  
  
  
  
  
  
  
  
  
  
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
 (mailto:dev-unsubscr...@maven.apache.org)
 For additional commands, e-mail: dev-h...@maven.apache.org 
 (mailto:dev-h...@maven.apache.org)
  
  

Re: libs in mavens /lib folder

[Stuart McCulloch]

Not sure I understand - the packages currently exported are limited to the ones 
that plugins/extensions need to use to communicate with Maven core (such as 
javax.inject to request injection)

Do you have a plugin or testcase which is behaving incorrectly with Maven 
3.2.5? 

On Thursday, 5 March 2015 at 15:27, Romain Manni-Bucau wrote:

 Hmm, will test soon but seems the imports are not complete, it misses:
 
 javax.decorator, javax.inject, javax.annotation and the whole
 javax.enterprise AFAIK
 
 
 Romain Manni-Bucau
 @rmannibucau https://twitter.com/rmannibucau | Blog
 http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
 LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
 http://www.tomitribe.com
 
 2015-03-05 16:20 GMT+01:00 Stuart McCulloch mccu...@gmail.com 
 (mailto:mccu...@gmail.com):
 
  I believe that was fixed in https://jira.codehaus.org/browse/MNG-5620
  (Maven 3.2.2) - can you recreate it with Maven 3.2.5?
  
  On Thursday, 5 March 2015 at 15:06, Romain Manni-Bucau wrote:
  
   no issue for maven itself but plugins are now easily broken:
   
   loader constraint violation: loader (instance of
   org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated
   loading for a different type with name
   
  
  javax/enterprise/util/TypeLiteral
   
   
   Romain Manni-Bucau
   @rmannibucau https://twitter.com/rmannibucau | Blog
   http://rmannibucau.wordpress.com | Github 
   
  
  https://github.com/rmannibucau |
   LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
   http://www.tomitribe.com
   
   2015-03-05 16:01 GMT+01:00 Jason van Zyl ja...@takari.io 
   (mailto:ja...@takari.io) (mailto:
  ja...@takari.io (mailto:ja...@takari.io)):
   
Why are you confused? From 3.1.0 to 3.3.0-SNAPSHOT the distribution, in
expanded form, has gone from ~6mb to ~9mb where the biggest

   
   
  
  contributors to
the size are Guava and the Wagon/HTTP related libraries. Those things
   
  
  have
just gotten bigger (Guava), or they have more dependencies (Wagon,
commons-httpclient and whatever it uses).

Each of those contributed roughly half of the increase. Everything else
has remained pretty much the same but don't see any cause for concern.

   
  
  I'm
really not worried about 3mb and I'm honestly not going to spend much
   
  
  time
trying to reclaim a few mb. Also looking back historically there was a
panic that not fully isolating the logging system would cause a huge
problem and in practice it has not. I honestly doubt the javax.*

   
  
  libraries
will be an issue as they are selectively exported from the core so if
   
  
  we
run into a huge problem it's easy to change.

We also don't export anything of the common utilities that use so
  nothing
stops any plugin or extension from using whatever version of
   
  
  plexus-utils,
Guava, or commons-whatever.

On Mar 5, 2015, at 6:42 AM, Mark Struberg strub...@yahoo.de 
(mailto:strub...@yahoo.de) (mailto:
  strub...@yahoo.de (mailto:strub...@yahoo.de)) wrote:

 Hi!
 
 I'm quite confused by the sheer amount of libs we already have in our
lib folder. For maven-3.2.1 this is
 
 133957 7. Mai 2013 aether-api-0.9.0.M2.jar
 12637 14. Feb 2014 aether-api.license
 34117 7. Mai 2013 aether-connector-wagon-0.9.0.M2.jar
 12637 14. Feb 2014 aether-connector-wagon.license
 144866 7. Mai 2013 aether-impl-0.9.0.M2.jar
 12637 14. Feb 2014 aether-impl.license
 17703 7. Mai 2013 aether-spi-0.9.0.M2.jar
 12637 14. Feb 2014 aether-spi.license
 133588 7. Mai 2013 aether-util-0.9.0.M2.jar
 12637 14. Feb 2014 aether-util.license
 4467 7. Mai 2013 aopalliance-1.0.jar
 44908 7. Mai 2013 cdi-api-1.0.jar
 41123 7. Mai 2013 commons-cli-1.2.jar
 173587 7. Mai 2013 commons-io-2.2.jar
 284220 7. Mai 2013 commons-lang-2.6.jar
 2189117 7. Mai 2013 guava-14.0.1.jar
 2497 7. Mai 2013 javax.inject-1.jar
 293671 24. Jul 2013 jsoup-1.7.2.jar
 3555 14. Feb 2014 jsoup.license
 5848 7. Mai 2013 jsr250-api-1.0.jar
 18116 14. Feb 2014 jsr250-api.license
 61357 14. Feb 2014 maven-aether-provider-3.2.1.jar
 53651 14. Feb 2014 maven-artifact-3.2.1.jar
 283790 14. Feb 2014 maven-compat-3.2.1.jar
 574650 14. Feb 2014 maven-core-3.2.1.jar
 59433 14. Feb 2014 maven-embedder-3.2.1.jar
 159855 14. Feb 2014 maven-model-3.2.1.jar
 165103 14. Feb 2014 maven-model-builder-3.2.1.jar
 45831 14. Feb 2014 maven-plugin-api-3.2.1.jar
 25758 14. Feb 2014 maven-repository-metadata-3.2.1.jar
 42804 14. Feb 2014 maven-settings-3.2.1.jar
 42738 14. Feb 2014 maven-settings-builder-3.2.1.jar
 291397 23. Sep 2013 org.eclipse.sisu.inject-0.0.0.M5.jar
 12637 14. Feb 2014 org.eclipse.sisu.inject.license
 196544 25. Jul 2013 org.eclipse.sisu.plexus-0.0.0.M5.jar
 12637 14. Feb 2014

Re: libs in mavens /lib folder

[Stuart McCulloch]

On Thursday, 5 March 2015 at 14:42, Mark Struberg wrote:
 Hi!
  
 I'm quite confused by the sheer amount of libs we already have in our lib 
 folder. For maven-3.2.1 this is
  
 133957 7. Mai 2013 aether-api-0.9.0.M2.jar
 12637 14. Feb 2014 aether-api.license
 34117 7. Mai 2013 aether-connector-wagon-0.9.0.M2.jar
 12637 14. Feb 2014 aether-connector-wagon.license
 144866 7. Mai 2013 aether-impl-0.9.0.M2.jar
 12637 14. Feb 2014 aether-impl.license
 17703 7. Mai 2013 aether-spi-0.9.0.M2.jar
 12637 14. Feb 2014 aether-spi.license
 133588 7. Mai 2013 aether-util-0.9.0.M2.jar
 12637 14. Feb 2014 aether-util.license
 4467 7. Mai 2013 aopalliance-1.0.jar
 44908 7. Mai 2013 cdi-api-1.0.jar
 41123 7. Mai 2013 commons-cli-1.2.jar
 173587 7. Mai 2013 commons-io-2.2.jar
 284220 7. Mai 2013 commons-lang-2.6.jar
 2189117 7. Mai 2013 guava-14.0.1.jar
 2497 7. Mai 2013 javax.inject-1.jar
 293671 24. Jul 2013 jsoup-1.7.2.jar
 3555 14. Feb 2014 jsoup.license
 5848 7. Mai 2013 jsr250-api-1.0.jar
 18116 14. Feb 2014 jsr250-api.license
 61357 14. Feb 2014 maven-aether-provider-3.2.1.jar
 53651 14. Feb 2014 maven-artifact-3.2.1.jar
 283790 14. Feb 2014 maven-compat-3.2.1.jar
 574650 14. Feb 2014 maven-core-3.2.1.jar
 59433 14. Feb 2014 maven-embedder-3.2.1.jar
 159855 14. Feb 2014 maven-model-3.2.1.jar
 165103 14. Feb 2014 maven-model-builder-3.2.1.jar
 45831 14. Feb 2014 maven-plugin-api-3.2.1.jar
 25758 14. Feb 2014 maven-repository-metadata-3.2.1.jar
 42804 14. Feb 2014 maven-settings-3.2.1.jar
 42738 14. Feb 2014 maven-settings-builder-3.2.1.jar
 291397 23. Sep 2013 org.eclipse.sisu.inject-0.0.0.M5.jar
 12637 14. Feb 2014 org.eclipse.sisu.inject.license
 196544 25. Jul 2013 org.eclipse.sisu.plexus-0.0.0.M5.jar
 12637 14. Feb 2014 org.eclipse.sisu.plexus.license
 13350 7. Mai 2013 plexus-cipher-1.7.jar
 33933 14. Feb 2014 plexus-cipher.license
 4211 7. Mai 2013 plexus-component-annotations-1.5.5.jar
 61697 17. Aug 2013 plexus-interpolation-1.19.jar
 28555 7. Mai 2013 plexus-sec-dispatcher-1.3.jar
 33933 14. Feb 2014 plexus-sec-dispatcher.license
 251792 27. Jan 2014 plexus-utils-3.0.17.jar
 358933 7. Mai 2013 sisu-guice-3.1.3-no_aop.jar
 26084 24. Jul 2013 slf4j-api-1.7.5.jar
 11207 14. Feb 2014 slf4j-api.license
 10680 17. Aug 2013 slf4j-simple-1.7.5.jar
 11207 14. Feb 2014 slf4j-simple.license
 11288 14. Jan 2014 wagon-file-2.6.jar
 1388197 14. Jan 2014 wagon-http-2.6-shaded.jar
 10373 14. Jan 2014 wagon-http-shared-2.6.jar
 52572 14. Jan 2014 wagon-provider-api-2.6.jar
  
  
 Lets look into details:
  
  
 44908 7. Mai 2013 cdi-api-1.0.jar
  
 What for? Do we use CDI in maven now? If so, why do we still have guava and 
 guice? - No then remove it
This provides the standard javax.enterprise.inject.Typed annotation which is 
respected by the container and helps migrate Plexus components (where you want 
to limit their visibility to a specific role) to more standard/modern 
annotations

If you don’t have any components that need this feature then it can be removed 
(or if you prefer to use a non-standard annotation in your components then 
that’s also possible, albeit less portable)
 41123 7. Mai 2013 commons-cli-1.2.jar
 173587 7. Mai 2013 commons-io-2.2.jar
 284220 7. Mai 2013 commons-lang-2.6.jar
  
 That might clash with many customer projects or is this very well guarded 
 from any plugin classloader?
  
 In maven-shared-utils we shaded in the few classes we used from this libs.
  
 2189117 7. Mai 2013 guava-14.0.1.jar
 This is also used pretty often in custom projects. Same question as for 
 commons-*. Is it well isolated?

I believe so, I haven’t seen any issues with this library and Guava has been 
bundled with Maven long before we changed containers (back when it was called 
google collections)
  
 2497 7. Mai 2013 javax.inject-1.jar
 We are only lucky that there is atm only a single version of this spec out 
 there. So currently not much of an issue but a ticking time bomb.

This is for components that want to use the standard JSR330 annotations, and is 
required by Guice - not sure why this is a problem, given that the spec is 
stable (the same applies to the aopalliance spec which is still at 1.0)
 5848 7. Mai 2013 jsr250-api-1.0.jar
  
 commons-annotations (JSR-250) are part of the JRE since java-1.4. So why do 
 we add it?
Actually they were added in JavaSE 6, but now that maven core is at this level 
then this library can be removed/excluded - the key annotations are 
@PostConstruct and @PreDestroy which are supported by the container when you 
use setJSR250Lifecycle(true) in the ContainerConfiguration.
  
 txs and LieGrue,
 strub
  
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
 (mailto:dev-unsubscr...@maven.apache.org)
 For additional commands, e-mail: dev-h...@maven.apache.org 
 (mailto:dev-h...@maven.apache.org)

Re: Archetype looping sort of with Maven 3.2.5

[Stuart McCulloch]

If I get time I can try to debug it this weekend - looking at the line numbers 
in the stack trace, the hang is happening inside the old container:

at 
org.codehaus.plexus.component.discovery.AbstractComponentDiscoverer.findComponents(AbstractComponentDiscoverer.java:78)
https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/component/discovery/AbstractComponentDiscoverer.java#L78
at 
org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:717)
https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/DefaultPlexusContainer.java#L717
at 
org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779)
https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/DefaultPlexusContainer.java#L779
  

at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:121)
https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/PlexusTestCase.java#L121
at 
org.apache.maven.archetype.ui.generation.DefaultArchetypeSelectionQueryerTest.setUp(DefaultArchetypeSelectionQueryerTest.java:44)


Not sure why the old container gets into this state, maybe it’s the newer 
version of classworlds? Or maybe the test classpath needs some additional 
isolation/tweaking?

Also note that if I run the test on its own 
(-Dtest=DefaultArchetypeSelectionQueryerTest) then it only takes a second or so 
with 3.2.5.

--  
Cheers, Stuart


On Friday, 20 February 2015 at 12:22, Benson Margulies wrote:

 org.codehaus.plexus.component.discovery.PlexusXmlComponentDiscoverer#discoverConfiguration
  
 Is 'discovering' 57 copies of
 jar:file:/Users/benson/.m2/repository/org/apache/maven/maven-core/2.2.1/maven-core-2.2.1.jar!/META-INF/plexus/plexus.xml.
  
 Reading it over and over is taking a long time. As previously
 documented, using a newer copy of plexus leads to problems.
  
  
  
 On Fri, Feb 20, 2015 at 6:51 AM, Benson Margulies bimargul...@gmail.com 
 (mailto:bimargul...@gmail.com) wrote:
  What I see is:
   
  Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.071
  sec - in 
  org.apache.maven.archetype.ui.generation.DefaultArchetypeGenerationConfiguratorTest
  Running 
  org.apache.maven.archetype.ui.generation.DefaultArchetypeSelectionQueryerTest
  Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 55.357
  sec - in 
  org.apache.maven.archetype.ui.generation.DefaultArchetypeSelectionQueryerTest
  Running 
  org.apache.maven.archetype.ui.generation.DefaultArchetypeSelectorTest
  ...
   
  So it appears that DefaultArchetypeSelectorTest gets lost in a loop.
  Hervé, have you poked further?
   
  
  
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
 (mailto:dev-unsubscr...@maven.apache.org)
 For additional commands, e-mail: dev-h...@maven.apache.org 
 (mailto:dev-h...@maven.apache.org)
  
  

Re: Archetype looping sort of with Maven 3.2.5

[Stuart McCulloch]

FYI, here’s the two competing classworld dependencies... one is the old 
classworlds:classworlds and the other org.codehaus.plexus:plexus-classworlds:

[INFO] |  +- 
org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-6:compile
[INFO] |  |  \- 
org.codehaus.plexus:plexus-component-api:jar:1.0-alpha-16:compile
[INFO] |  | \- 
org.codehaus.plexus:plexus-classworlds:jar:1.2-alpha-7:compile — 
plexus-classworlds
[INFO] |  +- org.apache.maven:maven-artifact-manager:jar:2.2.1:compile
[INFO] |  |  \- 
backport-util-concurrent:backport-util-concurrent:jar:3.1:compile
[INFO] |  +- org.apache.maven:maven-monitor:jar:2.2.1:compile
[INFO] |  +- org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-6:compile
[INFO] |  |  \- com.jcraft:jsch:jar:0.1.38:compile
[INFO] |  +- classworlds:classworlds:jar:1.1:compile — classworlds
[INFO] |  \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
[INFO] | \- org.sonatype.plexus:plexus-cipher:jar:1.4:compile


Both are brought in as transitive dependencies of maven-core (2.2.1)

If I add a test dependency to classworlds:classworlds:jar:1.1 at the top of the 
dependencies in maven-archetype-plugin/pom.xml, or add a test dependency to 
plexus-container-default (which has a transitive dependency to the old 
classworlds artifact) then the hang doesn’t occur… note that this is testing 
with 3.2.5 without making surefire fork and without adding more memory:

diff --git a/maven-archetype-plugin/pom.xml b/maven-archetype-plugin/pom.xml
index 921fdbb..3b9e0e5 100644
--- a/maven-archetype-plugin/pom.xml
+++ b/maven-archetype-plugin/pom.xml
@@ -51,6 +51,11 @@
  
   dependencies
 dependency
+  groupIdorg.codehaus.plexus/groupId
+  artifactIdplexus-container-default/artifactId
+  scopetest/scope
+/dependency
+dependency
   groupIdorg.apache.maven.archetype/groupId
   artifactIdarchetype-catalog/artifactId
 /dependency



On Friday, 20 February 2015 at 12:48, Benson Margulies wrote:

 Making surefire fork and giving it more memory did the job. Once we make
 the 2.2.1 release we can presumably make archetype use non-antique plexus.
 On Feb 20, 2015 7:46 AM, Stuart McCulloch mccu...@gmail.com 
 (mailto:mccu...@gmail.com) wrote:
  
  If I get time I can try to debug it this weekend - looking at the line
  numbers in the stack trace, the hang is happening inside the old container:
   
  at
  org.codehaus.plexus.component.discovery.AbstractComponentDiscoverer.findComponents(AbstractComponentDiscoverer.java:78)
   
  https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/component/discovery/AbstractComponentDiscoverer.java#L78
  at
  org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:717)
   
  https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/DefaultPlexusContainer.java#L717
  at
  org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779)
   
  https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/DefaultPlexusContainer.java#L779
   
  at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:121)
   
  https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/PlexusTestCase.java#L121
  at
  org.apache.maven.archetype.ui.generation.DefaultArchetypeSelectionQueryerTest.setUp(DefaultArchetypeSelectionQueryerTest.java:44)
   
   
  Not sure why the old container gets into this state, maybe it’s the newer
  version of classworlds? Or maybe the test classpath needs some additional
  isolation/tweaking?
   
  Also note that if I run the test on its own
  (-Dtest=DefaultArchetypeSelectionQueryerTest) then it only takes a second
  or so with 3.2.5.
   
  --
  Cheers, Stuart
   
   
  On Friday, 20 February 2015 at 12:22, Benson Margulies wrote:
   
  org.codehaus.plexus.component.discovery.PlexusXmlComponentDiscoverer#discoverConfiguration

   Is 'discovering' 57 copies of
  jar:file:/Users/benson/.m2/repository/org/apache/maven/maven-core/2.2.1/maven-core-2.2.1.jar!/META-INF/plexus/plexus.xml.

   Reading it over and over is taking a long time. As previously
   documented, using a newer copy of plexus leads to problems.



   On Fri, Feb 20, 2015 at 6:51 AM, Benson Margulies bimargul...@gmail.com 
   (mailto:bimargul...@gmail.com)
  (mailto:bimargul...@gmail.com) wrote:
What I see is:
 
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.071
sec - in
 

   
  org.apache.maven.archetype.ui.generation.DefaultArchetypeGenerationConfiguratorTest
Running

   
  org.apache.maven.archetype.ui.generation.DefaultArchetypeSelectionQueryerTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 55.357
sec

Re: Archetype looping sort of with Maven 3.2.5

[Stuart McCulloch]

I would, but I’m not a committer here ;)

On Friday, 20 February 2015 at 13:15, Benson Margulies wrote:

 I like your fix better than my fix, please feel free to commit the switch.
  
 On Fri, Feb 20, 2015 at 8:14 AM, Stuart McCulloch mccu...@gmail.com 
 (mailto:mccu...@gmail.com) wrote:
  FYI, here’s the two competing classworld dependencies... one is the old 
  classworlds:classworlds and the other 
  org.codehaus.plexus:plexus-classworlds:
   
  [INFO] | +- 
  org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-6:compile
  [INFO] | | \- 
  org.codehaus.plexus:plexus-component-api:jar:1.0-alpha-16:compile
  [INFO] | | \- 
  org.codehaus.plexus:plexus-classworlds:jar:1.2-alpha-7:compile — 
  plexus-classworlds
  [INFO] | +- org.apache.maven:maven-artifact-manager:jar:2.2.1:compile
  [INFO] | | \- 
  backport-util-concurrent:backport-util-concurrent:jar:3.1:compile
  [INFO] | +- org.apache.maven:maven-monitor:jar:2.2.1:compile
  [INFO] | +- org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-6:compile
  [INFO] | | \- com.jcraft:jsch:jar:0.1.38:compile
  [INFO] | +- classworlds:classworlds:jar:1.1:compile — classworlds
  [INFO] | \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
  [INFO] | \- org.sonatype.plexus:plexus-cipher:jar:1.4:compile
   
   
  Both are brought in as transitive dependencies of maven-core (2.2.1)
   
  If I add a test dependency to classworlds:classworlds:jar:1.1 at the top of 
  the dependencies in maven-archetype-plugin/pom.xml, or add a test 
  dependency to plexus-container-default (which has a transitive dependency 
  to the old classworlds artifact) then the hang doesn’t occur… note that 
  this is testing with 3.2.5 without making surefire fork and without adding 
  more memory:
   
  diff --git a/maven-archetype-plugin/pom.xml b/maven-archetype-plugin/pom.xml
  index 921fdbb..3b9e0e5 100644
  --- a/maven-archetype-plugin/pom.xml
  +++ b/maven-archetype-plugin/pom.xml
  @@ -51,6 +51,11 @@
   
  dependencies
  dependency
  + groupIdorg.codehaus.plexus/groupId
  + artifactIdplexus-container-default/artifactId
  + scopetest/scope
  + /dependency
  + dependency
  groupIdorg.apache.maven.archetype/groupId
  artifactIdarchetype-catalog/artifactId
  /dependency
   
   
   
  On Friday, 20 February 2015 at 12:48, Benson Margulies wrote:
   
   Making surefire fork and giving it more memory did the job. Once we make
   the 2.2.1 release we can presumably make archetype use non-antique plexus.
   On Feb 20, 2015 7:46 AM, Stuart McCulloch mccu...@gmail.com 
   (mailto:mccu...@gmail.com) wrote:

If I get time I can try to debug it this weekend - looking at the line
numbers in the stack trace, the hang is happening inside the old 
container:
 
at
org.codehaus.plexus.component.discovery.AbstractComponentDiscoverer.findComponents(AbstractComponentDiscoverer.java:78)
 
https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/component/discovery/AbstractComponentDiscoverer.java#L78
at
org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:717)
 
https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/DefaultPlexusContainer.java#L717
at
org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779)
 
https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/DefaultPlexusContainer.java#L779
 
at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:121)
 
https://github.com/sonatype/plexus-containers/blob/plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/PlexusTestCase.java#L121
at
org.apache.maven.archetype.ui.generation.DefaultArchetypeSelectionQueryerTest.setUp(DefaultArchetypeSelectionQueryerTest.java:44)
 
 
Not sure why the old container gets into this state, maybe it’s the 
newer
version of classworlds? Or maybe the test classpath needs some 
additional
isolation/tweaking?
 
Also note that if I run the test on its own
(-Dtest=DefaultArchetypeSelectionQueryerTest) then it only takes a 
second
or so with 3.2.5.
 
--
Cheers, Stuart
 
 
On Friday, 20 February 2015 at 12:22, Benson Margulies wrote:
 
org.codehaus.plexus.component.discovery.PlexusXmlComponentDiscoverer#discoverConfiguration
  
 Is 'discovering' 57 copies of
jar:file:/Users/benson/.m2/repository/org/apache/maven/maven-core/2.2.1/maven-core-2.2.1.jar!/META-INF/plexus/plexus.xml.
  
 Reading it over and over is taking a long time. As previously
 documented, using a newer copy of plexus leads to problems.
  
  
  
 On Fri, Feb 20, 2015 at 6:51 AM, Benson Margulies 
 bimargul...@gmail.com

Re: Plexus versus maven-artifact-manager

[Stuart McCulloch]

On Monday, 2 February 2015 at 14:43, Benson Margulies wrote:
 I'm attempting to pull archetype up to 2.2.1. I seem to have found a
 disagreement between 2.2.1 of maven-artifact-manager and some version
 of some part of plexus.
  
 Is this a familiar story to anyone; is there, for example, some plexus
 piece I need a different version of?
  
  

The 2.2.1 version of DefaultArtifactTransformationManager (from 
maven-artifact-manager, a transitive dependency of maven-core 2.x) is 
attempting to mutate a managed/read-only collection. You could get away with 
this in Plexus 1.0-alpha-9-stable-1 because it just happened to expose the 
underlying mutable collection. This is not allowed in later versions of both 
Plexus and the Guice-Plexus shim. Ideally it should use its own collection to 
do the local mutation/filtering, but since there won’t be any more releases of 
that particular module then you need to test it with the old container.

Note that the maven-artifact-manager API (a transitive dependency of 
maven-core) is gone in Maven3 - it was moved into the maven-compat module and 
subsequently moved to a different package:

https://github.com/apache/maven/commit/ee5dd78bd1a0b96edf2cc53480b342bb74b9a173

https://jira.codehaus.org/browse/MNG-4221

So this won’t cause any issues at runtime since Maven filters out core 
dependencies, it’s just at test-time that you have to be careful about keeping 
the versions of maven and the container in sync.
 DefaultArtifactTransfomationManager has ...
  
 public void initialize() throws InitializationException {
 // TODO this is a hack until plexus can fix the ordering of the arrays
 ArtifactTransformation transforms[] =
 artifactTransformations.toArray( new ArtifactTransformation[]{} );
 for (int x = 0; x  transforms.length; x++)
 {
 if (transforms[x].getClass().getName().indexOf(Snapshot) != -1) {
 artifactTransformations.remove(transforms[x]);
 artifactTransformations.add(transforms[x]);
 }
 }
 }
  
 Resulting in
  
 Caused by: java.lang.UnsupportedOperationException: You cannot modify
 this list. This list is a requirement of role:
 'org.apache.maven.artifact.transform.ArtifactTransformationManager',
 implementation:
 'org.apache.maven.artifact.transform.DefaultArtifactTransformationManager',
 role hint: 'default' and managed by the container.
 at 
 org.codehaus.plexus.component.collections.ComponentList.remove(ComponentList.java:91)
 at 
 org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.initialize(DefaultArtifactTransformationManager.java:44)
 at 
 org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
 at 
 org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:96)
 at 
 org.codehaus.plexus.component.manager.AbstractComponentManager.start(AbstractComponentManager.java:167)
 at 
 org.codehaus.plexus.component.builder.XBeanComponentBuilder.startComponentLifecycle(XBeanComponentBuilder.java:283)
 at 
 org.codehaus.plexus.component.builder.XBeanComponentBuilder.build(XBeanComponentBuilder.java:129)
 at 
 org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:181)
 at 
 org.codehaus.plexus.component.manager.SingletonComponentManager.getComponent(SingletonComponentManager.java:67)
 at 
 org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:358)
 at 
 org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:178)
 at 
 org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:393)
 at 
 org.codehaus.plexus.component.builder.XBeanComponentBuilder$RequirementRecipe.internalCreate(XBeanComponentBuilder.java:402)
 at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
 at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:167)
 at org.apache.xbean.recipe.ObjectRecipe.setProperty(ObjectRecipe.java:497)
 ... 79 more
  
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
 (mailto:dev-unsubscr...@maven.apache.org)
 For additional commands, e-mail: dev-h...@maven.apache.org 
 (mailto:dev-h...@maven.apache.org)
  
  

Re: Formal verification of thread correctness in maven core

[Stuart McCulloch]

On Monday, 5 January 2015 at 15:00, David Jencks wrote:
 I wonder that too.  
  
 I don't think cglib is maintained
FYI cglib is still maintained and moved recently to 
https://github.com/cglib/cglib … that said, for simple cases asm is often 
enough.
 , AFAIK most people use asm nowadays. I believe it is fairly easy to use asm 
 to add byte code to the beginning and end of every method for e.g. logging 
 method entry/exit. Apache Aries has an asm based thing to enable adding some 
 kind of before/after logic (this is designed for osgi weaving hooks). With 
 this approach you would not need subclasses.
  
 david jencks
  
 On Jan 5, 2015, at 9:51 AM, Igor Fedorenko i...@ifedorenko.com 
 (mailto:i...@ifedorenko.com) wrote:
  
  What kind of changes to the model do you expect? Can you give some
  pointers that explain verification logic you have in mind?
   
  --
  Regards,
  Igor
   
  On 2015-01-05 9:11, Kristian Rosenvold wrote:
   I'd be interested in using cglib to generate a full set of subclasses
   for the entire maven model. These subclasses could assert stuff about
   proper thread correctness wrt the current correct threading model
   for maven. This would be capable of blowing up /immediately/ a plugin
   violates the contract and could be used to make a formal
   verficiation that the entire set of plugins performs to specification
   in a given build.

   I could potentially see this added as a diagnostic mode to core.

   I know how to create the verification logic, but I am totally blank
   when it comes to cglib. Is there anyone who can help me a bit ? Maybe
   even someone who could code the actual cglib bit :) ?

   Kristian

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

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

RE: [VOTE] Release Maven 3.2.5

[Stuart McCulloch]

On 16 Dec 2014 10:45, Sievers, Jan jan.siev...@sap.com wrote:

 I ran all Tycho ITs using the staged version.
 I still see one error related to toolchains.

 The IT is using the toolchains.xml attached and fails the build with
error below.
 Not sure if that's a regression in toolchains or our test needs to be
adapted.

 I have extracted a small standalone sample from our test project [1] and
attached pom.xml and toolchains.xml

 You can build attached pom with attached toolchains

 mvn clean install --toolchains ./toolchains.xml

 this works with maven 3.2.3 but breaks with staged maven 3.2.5.

According to 
http://mail-archives.apache.org/mod_mbox/maven-dev/201412.mbox/2924203.teZphZ8xW9%40herve-desktop
the attached pom.xml configuration is wrong: you need to put the vendor tag
inside jdk.../jdk

Previous releases of toolchain were less strict about this - if you wrap
the vendor inside jdk.../jdk then the test should pass with both
releases.


 Regards,
 Jan

 [1]
https://github.com/eclipse/tycho/tree/master/tycho-its/projects/surefire.toolchains


 

 [INFO] --- maven-toolchains-plugin:1.0:toolchain (default) @ toolchains
---
 [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
ConflictMarker.markTime=1, ConflictMarker.nodeCount=57,
ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0,
ConflictIdSorter.conflictIdCount=24,
ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=1,
ConflictResolver.conflictItemCount=57,
DefaultDependencyCollector.collectTime=80,
DefaultDependencyCollector.transformTime=2}
 [DEBUG] org.apache.maven.plugins:maven-toolchains-plugin:jar:1.0:
 [DEBUG]org.apache.maven:maven-plugin-api:jar:2.0.9:compile
 [DEBUG]org.apache.maven:maven-toolchain:jar:2.0.9:compile
 [DEBUG]   org.apache.maven:maven-core:jar:2.0.9:compile
 [DEBUG]  org.apache.maven:maven-settings:jar:2.0.9:compile
 [DEBUG]
org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.9:compile
 [DEBUG]
org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile
 [DEBUG]
 org.apache.maven.doxia:doxia-sink-api:jar:1.0-alpha-10:compile
 [DEBUG]  org.apache.maven:maven-profile:jar:2.0.9:compile
 [DEBUG]  org.apache.maven:maven-model:jar:2.0.9:compile
 [DEBUG]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
 [DEBUG] junit:junit:jar:3.8.1:compile
 [DEBUG]
org.apache.maven:maven-repository-metadata:jar:2.0.9:compile
 [DEBUG]
org.apache.maven:maven-error-diagnostics:jar:2.0.9:compile
 [DEBUG]  org.apache.maven:maven-project:jar:2.0.9:compile
 [DEBUG]
 org.apache.maven:maven-plugin-registry:jar:2.0.9:compile
 [DEBUG]  commons-cli:commons-cli:jar:1.0:compile
 [DEBUG]
org.apache.maven:maven-plugin-descriptor:jar:2.0.9:compile
 [DEBUG]
org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-4:compile
 [DEBUG]  org.apache.maven:maven-artifact-manager:jar:2.0.9:compile
 [DEBUG]  org.apache.maven:maven-monitor:jar:2.0.9:compile
 [DEBUG]  org.codehaus.plexus:plexus-utils:jar:1.5.1:compile
 [DEBUG]  classworlds:classworlds:jar:1.1:compile
 [DEBUG]   org.apache.maven:maven-artifact:jar:2.0.9:compile
 [DEBUG] Created new class realm
pluginorg.apache.maven.plugins:maven-toolchains-plugin:1.0
 [DEBUG] Importing foreign packages into class realm
pluginorg.apache.maven.plugins:maven-toolchains-plugin:1.0
 [DEBUG]   Imported:   projecttoolchains:toolchains:0.0.1-SNAPSHOT
 [DEBUG] Populating class realm
pluginorg.apache.maven.plugins:maven-toolchains-plugin:1.0
 [DEBUG]   Included:
org.apache.maven.plugins:maven-toolchains-plugin:jar:1.0
 [DEBUG]   Included:
org.apache.maven.reporting:maven-reporting-api:jar:2.0.9
 [DEBUG]   Included: org.apache.maven.doxia:doxia-sink-api:jar:1.0-alpha-10
 [DEBUG]   Included: junit:junit:jar:3.8.1
 [DEBUG]   Included: commons-cli:commons-cli:jar:1.0
 [DEBUG]   Included:
org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-4
 [DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:1.5.1
 [DEBUG]   Excluded: org.apache.maven:maven-plugin-api:jar:2.0.9
 [DEBUG]   Excluded: org.apache.maven:maven-toolchain:jar:2.0.9
 [DEBUG]   Excluded: org.apache.maven:maven-core:jar:2.0.9
 [DEBUG]   Excluded: org.apache.maven:maven-settings:jar:2.0.9
 [DEBUG]   Excluded:
org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.9
 [DEBUG]   Excluded: org.apache.maven:maven-profile:jar:2.0.9
 [DEBUG]   Excluded: org.apache.maven:maven-model:jar:2.0.9
 [DEBUG]   Excluded:
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
 [DEBUG]   Excluded: org.apache.maven:maven-repository-metadata:jar:2.0.9
 [DEBUG]   Excluded: org.apache.maven:maven-error-diagnostics:jar:2.0.9
 [DEBUG]   Excluded: org.apache.maven:maven-project:jar:2.0.9
 [DEBUG]   Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.9
 [DEBUG]   Excluded: org.apache.maven:maven-plugin-descriptor:jar:2.0.9
 [DEBUG]   Excluded: 

Re: Modello Upgrade does not work

[Stuart McCulloch]

FYI, EntityReplacementMap isn't a generated file - looking at plexus-utils
commit history it was added in 3.0.13:

https://github.com/sonatype/plexus-utils/commit/235796a03400472840626cf3195d05932158c71cz

Upgrading to at least that version of plexus-utils should solve the problem.
On 14 Dec 2014 09:07, Karl Heinz Marbaise khmarba...@gmx.de wrote:

 Hi,

 i'm currently trying to upgrade maven-archetype from Modello 1.7 to 1.8.X
 but unfortunately i got failures which means the compile process show that
 a class is not there:

 [ERROR] Failed to execute goal org.apache.maven.plugins:
 maven-compiler-plugin:3.1:compile (default-compile) on project
 archetype-catalog: Compilation failure: Compilation failure:
 [ERROR] /Users/kama/apache-maven/maven-archetype/archetype-
 models/archetype-catalog/target/generated-sources/
 modello/org/apache/maven/archetype/catalog/io/xpp3/
 ArchetypeCatalogXpp3Reader.java:[19,41] cannot find symbol
 [ERROR] symbol:   class EntityReplacementMap
 [ERROR] location: package org.codehaus.plexus.util.xml.pull
 [ERROR] /Users/kama/apache-maven/maven-archetype/archetype-
 models/archetype-catalog/target/generated-sources/
 modello/org/apache/maven/archetype/catalog/io/xpp3/
 ArchetypeCatalogXpp3Reader.java:[549,66] cannot find symbol
 [ERROR] symbol:   variable EntityReplacementMap
 [ERROR] location: class org.apache.maven.archetype.catalog.io.xpp3.
 ArchetypeCatalogXpp3Reader
 [ERROR] - [Help 1]


 This looks like modello does not generate it...Can someone give me hint:

 Is this a known bug or can i fix it somehow ?


 Kind regards
 Karl Heinz Marbaise

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

Re: Modello Upgrade does not work

[Stuart McCulloch]

No worries, btw for those interested, here's the corresponding change in
the 1.8 modello code generator:

https://github.com/sonatype/modello/commit/2c55132415675f36919a1ff0dc6352e715da72f8
 On 14 Dec 2014 12:40, Karl Heinz Marbaise khmarba...@gmx.de wrote:

 Hi Stuart,

 On 12/14/14 11:51 AM, Stuart McCulloch wrote:

 FYI, EntityReplacementMap isn't a generated file - looking at
 plexus-utils commit history it was added in 3.0.13:

 https://github.com/sonatype/plexus-utils/commit/
 235796a03400472840626cf3195d05932158c71cz

 Upgrading to at least that version of plexus-utils should solve the
 problem.


 Hm...looks like this helped...

 I was a little bit puzzled, cause the EntityReplacmentMap was refererenced
 in the generated code...

 So i was on the wrong path...thanks for clearing up that...

 now just a test failed but i can compile it...



 On 14 Dec 2014 09:07, Karl Heinz Marbaise khmarba...@gmx.de
 mailto:khmarba...@gmx.de wrote:

 Hi,

 i'm currently trying to upgrade maven-archetype from Modello 1.7 to
 1.8.X but unfortunately i got failures which means the compile
 process show that a class is not there:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:__maven-compiler-plugin:3.1:__compile
 (default-compile) on project archetype-catalog: Compilation failure:
 Compilation failure:
 [ERROR]
 /Users/kama/apache-maven/__maven-archetype/archetype-__
 models/archetype-catalog/__target/generated-sources/__
 modello/org/apache/maven/__archetype/catalog/io/xpp3/__
 ArchetypeCatalogXpp3Reader.__java:[19,41]
 cannot find symbol
 [ERROR] symbol:   class EntityReplacementMap
 [ERROR] location: package org.codehaus.plexus.util.xml.__pull
 [ERROR]
 /Users/kama/apache-maven/__maven-archetype/archetype-__
 models/archetype-catalog/__target/generated-sources/__
 modello/org/apache/maven/__archetype/catalog/io/xpp3/__
 ArchetypeCatalogXpp3Reader.__java:[549,66]
 cannot find symbol
 [ERROR] symbol:   variable EntityReplacementMap
 [ERROR] location: class
 org.apache.maven.archetype.__catalog.io.xpp3.__
 ArchetypeCatalogXpp3Reader
 [ERROR] - [Help 1]


 This looks like modello does not generate it...Can someone give me
 hint:

 Is this a known bug or can i fix it somehow ?



 Kind regards
 Karl Heinz Marbaise

Re: assembly plugin bug tracker?

[Stuart McCulloch]

FYI you can sign up for a Codehaus account at
http://xircles.codehaus.org/signup - this gives you access to both JIRA and
confluence.

(Not sure why this link doesn't appear on the JIRA login page, perhaps it
can't be customised? One of the Codehaus infra team would know for sure, I
do know that it's been like this for a while.)
On 3 Dec 2014 10:29, Daniel Pocock dan...@pocock.pro wrote:


 The assembly plugin web page[1] has a link to this bug tracker:

 https://jira.codehaus.org/browse/MASSEMBLY

 The login page[2] has text:
 Not a member? To request an account, please contact your JIRA
 administrators. 
 and no link for users to register.

 Could somebody please update the JIRA config to allow bug reporting?

 1.
 http://maven.apache.org/plugins/maven-assembly-plugin/issue-tracking.html

 2.
 https://jira.codehaus.org/login.jsp?os_destination=%2Fbrowse%2FMASSEMBLY

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

Re: assembly plugin bug tracker?

[Stuart McCulloch]

Just noticed that's http (the http site links to the http signup page, even
though https is available for signup)

This link is better: https://xircles.codehaus.org/signup
On 3 Dec 2014 10:42, Stuart McCulloch mccu...@gmail.com wrote:

 FYI you can sign up for a Codehaus account at
 http://xircles.codehaus.org/signup - this gives you access to both JIRA
 and confluence.

 (Not sure why this link doesn't appear on the JIRA login page, perhaps it
 can't be customised? One of the Codehaus infra team would know for sure, I
 do know that it's been like this for a while.)
 On 3 Dec 2014 10:29, Daniel Pocock dan...@pocock.pro wrote:


 The assembly plugin web page[1] has a link to this bug tracker:

 https://jira.codehaus.org/browse/MASSEMBLY

 The login page[2] has text:
 Not a member? To request an account, please contact your JIRA
 administrators. 
 and no link for users to register.

 Could somebody please update the JIRA config to allow bug reporting?

 1.
 http://maven.apache.org/plugins/maven-assembly-plugin/issue-tracking.html

 2.
 https://jira.codehaus.org/login.jsp?os_destination=%2Fbrowse%2FMASSEMBLY

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

Re: Help needed with MPIR-279

[Stuart McCulloch]

On Thursday, 13 November 2014 at 09:43, Michael Osipov wrote:
 Am 2014-11-13 um 01:40 schrieb Hervé BOUTEMY:
  Sorry, I tried but I'm stuck with maven-plugin-testing-harness too...
  
  
 I have committed another changed where I have missed to assigned the  
 localRepository. Though it gives me now:
  
 testReport(org.apache.maven.report.projectinfo.ModulesReportTest) Time  
 elapsed: 0.328 sec  ERROR!
 java.lang.IllegalStateException: Unable to read local module POM
  
  

Both subproject1/pom.xml and subproject2/pom.xml declare the following as their 
parent:

parent
  groupIdorg.apache.maven.plugin.projectinfo.tests/groupId
  artifactIddependency-convergence/artifactId
  version1.0-SNAPSHOT/version
/parent  

While this artifact is located in the parent directory, it’s in a file called 
dependency-convergence-plugin-config.xml so it won't be discovered by the 
normal parent rule of looking for ../pom.xml. Neither is it installed in the 
local repository (test or otherwise) which is why the error occurs about the 
missing dependency-convergence project.

I verified this by adding the following line to the parent config in 
subproject1/pom.xml and subproject2/pom.xml:

relativePath../dependency-convergence-plugin-config.xml/relativePath

I also had to change the packaging of dependency-convergence-plugin-config.xml 
from ‘jar’ to ‘pom’ otherwise it would complain about the parent having the 
wrong packaging.

Once that was done the tests all passed.

I’m not familiar with these tests, so I’m not sure whether these subprojects 
are really meant to have the dependency-convergence artifact as their parent? 
(if not then a simpler fix would be to create a new parent pom at the expected 
location, and perhaps move it and the subproject modules below a ’moduletest’ 
folder to make the hierarchy a bit cleaner).

Anyway, hope this helps...
  
 Thanks for your help.
  
 Maybe someone else has a clue.
  
 Michael
  
  
  
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
 (mailto:dev-unsubscr...@maven.apache.org)
 For additional commands, e-mail: dev-h...@maven.apache.org 
 (mailto:dev-h...@maven.apache.org)
  
  

Re: leakage of old Guava into plugins via sisu-guice

[Stuart McCulloch]

AFAIK none of the Guava packages are exposed from maven core, so I’d be 
interested to know more about where these types are leaking and how to recreate 
this.  

--  
Cheers, Stuart


On Friday, 7 November 2014 at 16:59, Benson Margulies wrote:

 Is there any possible way of insulating 3.0.x pipelines from the old
 version of Guava that leaks in with Sisu-guice? (Other than shading a
 current version of guice and using it?)
  
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
 (mailto:dev-unsubscr...@maven.apache.org)
 For additional commands, e-mail: dev-h...@maven.apache.org 
 (mailto:dev-h...@maven.apache.org)
  
  

Re: leakage of old Guava into plugins via sisu-guice

[Stuart McCulloch]

That should work, or you could remove that transitive dependency from the 
build-time classpath by adding a dependency exclusion.

At runtime the plugin realm is isolated from maven-core except for the specific 
packages exposed by DefaultClassRealmManager.

--  
Cheers, Stuart


On Friday, 7 November 2014 at 17:13, Benson Margulies wrote:

 See https://github.com/benson-basis/github-release-note-maven-plugin.
 IntelliJ is sure that sisu-guava is in the class path. I am now trying
 reordering the pom to see if it works to put real Guava at the head of
 the line.
  
 dependency:tree:
  
 org.apache.maven:maven-plugin-api:jar:3.0.5:provided
 [INFO] | +- org.apache.maven:maven-model:jar:3.0.5:provided
 [INFO] | +- org.apache.maven:maven-artifact:jar:3.0.5:provided
 [INFO] | \- org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:provided
 [INFO] | \- org.sonatype.sisu:sisu-inject-bean:jar:2.3.0:provided
 [INFO] | \- org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0:provided
 [INFO] | \- org.sonatype.sisu:sisu-guava:jar:0.9.9:provided
  
 On Fri, Nov 7, 2014 at 12:08 PM, Benson Margulies bimargul...@gmail.com 
 (mailto:bimargul...@gmail.com) wrote:
  Oh, I thought this was old hat. Stand by ...
   
  On Fri, Nov 7, 2014 at 12:06 PM, Stuart McCulloch mccu...@gmail.com 
  (mailto:mccu...@gmail.com) wrote:
   AFAIK none of the Guava packages are exposed from maven core, so I’d be 
   interested to know more about where these types are leaking and how to 
   recreate this.

   --
   Cheers, Stuart


   On Friday, 7 November 2014 at 16:59, Benson Margulies wrote:

Is there any possible way of insulating 3.0.x pipelines from the old
version of Guava that leaks in with Sisu-guice? (Other than shading a
current version of guice and using it?)
 
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
(mailto:dev-unsubscr...@maven.apache.org)
For additional commands, e-mail: dev-h...@maven.apache.org 
(mailto:dev-h...@maven.apache.org)
 


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

Re: leakage of old Guava into plugins via sisu-guice

[Stuart McCulloch]

I wrote a quick plugin that uses Guava via reflection (so I could try out 
different orderings in the build-time pom) and found the following:  

Depending on maven-plugin-api, etc. with compile scope will bring all their 
transitive dependencies onto the plugin classpath (build and runtime)

At runtime Maven’s DefaultArtifactFilterManager should filter out jars in the 
core+extensions (at least according to the class description)

However while artifacts explicitly listed in DefaultArtifactFilterManager are 
excluded, their transitive dependencies like Guava are left on the plugin 
classpath

The simplest solution to avoid this is to use provided scope when you depend on 
maven-plugin-api etc. so transitive dependencies aren’t automatically pulled in.

Looking ahead I wonder if Maven should also use provided scope to in turn 
depend on container/spec jars? ie. in case people use compile scope in their 
plugin poms

Finally should DefaultArtifactFilterManager consider transitive dependencies of 
excluded artifacts when filtering the plugin classpath?

--  
Cheers, Stuart


On Friday, 7 November 2014 at 20:09, Mirko Friedenhagen wrote:

 I always had to exclude sisu-guava when I wanted to use newer guava
 versions in my plugins.
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/
  
  
 On Fri, Nov 7, 2014 at 6:51 PM, Stuart McCulloch mccu...@gmail.com 
 (mailto:mccu...@gmail.com) wrote:
  That should work, or you could remove that transitive dependency from the 
  build-time classpath by adding a dependency exclusion.
   
  At runtime the plugin realm is isolated from maven-core except for the 
  specific packages exposed by DefaultClassRealmManager.
   
  --
  Cheers, Stuart
   
   
  On Friday, 7 November 2014 at 17:13, Benson Margulies wrote:
   
   See https://github.com/benson-basis/github-release-note-maven-plugin.
   IntelliJ is sure that sisu-guava is in the class path. I am now trying
   reordering the pom to see if it works to put real Guava at the head of
   the line.

   dependency:tree:

   org.apache.maven:maven-plugin-api:jar:3.0.5:provided
   [INFO] | +- org.apache.maven:maven-model:jar:3.0.5:provided
   [INFO] | +- org.apache.maven:maven-artifact:jar:3.0.5:provided
   [INFO] | \- org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:provided
   [INFO] | \- org.sonatype.sisu:sisu-inject-bean:jar:2.3.0:provided
   [INFO] | \- org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0:provided
   [INFO] | \- org.sonatype.sisu:sisu-guava:jar:0.9.9:provided

   On Fri, Nov 7, 2014 at 12:08 PM, Benson Margulies bimargul...@gmail.com 
   (mailto:bimargul...@gmail.com) wrote:
Oh, I thought this was old hat. Stand by ...
 
On Fri, Nov 7, 2014 at 12:06 PM, Stuart McCulloch mccu...@gmail.com 
(mailto:mccu...@gmail.com) wrote:
 AFAIK none of the Guava packages are exposed from maven core, so I’d 
 be interested to know more about where these types are leaking and 
 how to recreate this.
  
 --
 Cheers, Stuart
  
  
 On Friday, 7 November 2014 at 16:59, Benson Margulies wrote:
  
  Is there any possible way of insulating 3.0.x pipelines from the old
  version of Guava that leaks in with Sisu-guice? (Other than shading 
  a
  current version of guice and using it?)
   
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
  (mailto:dev-unsubscr...@maven.apache.org)
  For additional commands, e-mail: dev-h...@maven.apache.org 
  (mailto:dev-h...@maven.apache.org)
   
  
  
 
 



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

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

Re: Assembly plugin duplicate file resolution

[Stuart McCulloch]

On Thursday, 30 October 2014 at 16:41, Kristian Rosenvold wrote:
 O-kay. Now I understand the precedence in question; it is based on
 container type:
 
 The handlers for the different assembly phases are wired in with
 
 @Requirement( role = AssemblyArchiverPhase.class )
 private ListAssemblyArchiverPhase assemblyPhases;
 
 

As observed below, the only guarantee in injected collections is that default 
components will appear before non-default components. Otherwise no guarantee is 
made to the order of entries.
 
 With maven 3.2.3 this will evaluate to an order of repository 
 dependencyset  moduleset  fileitem  fileset
 With maven 2.2.1 it evaluates to moduleSet  repository  FileSet 
 DependencySet  FileItem
 
 The first handler to add the file wins. Now I am unsure of how the
 container decides *order* of elements that are wired into a list like
 this, its certainly different for 2.2.1 and 3.x, and I'm not really
 convinced there is any guarantee of order. It might even differ with
 JDK versions :)
 
 So for 2.2.1 the documented fileset  fileitem precedence seems to
 hold, but not for 3.x.
 
 So it seems safe to assume that currently precedence is busted in any
 way, shape or form and the site documentation only works for 2.2.1. It
 seems like a lot simpler change to modify the handler order
 (container type), to give a precedence like this:
 
 fileitem  fileset  moduleset  dependencySet  repository
 
 From a precedence point of view I assume it makes sense to have the
 most specific items (fileitem) have the highest precedence.
 
 This would have to be done in a 2.6 release, not a minor release; a
 nice notice in the release notes should explain it...
 
 Kristian
 
 
 2014-10-30 13:37 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com 
 (mailto:kristian.rosenv...@gmail.com):
  But I really think the feature is legit; it just doesnt work very
  well, and the precedence in the link I sent seems ill-though through.
  Using order from the assembly specification sounds much more
  understandable. And to be honest, I really dont think anyone can rely
  on this order actually working in the current plugin, there's just too
  much bugs.
  
  Unpack this jar, but always use *this* specific properties file is a
  nice assembly descriptor.
  
  I think it's perfectly reasonable to evaluate
  filsets/depedencyset/file specifications in reverse order, so last
  wins. Achieving repeated items within a single file set is probably an
  error ( easily achievable with duplicate filesfile elements, hard
  otherwise - maybe with hardlinks in the file system).
  
  
  Kristian
  
  
  
  2014-10-30 13:10 GMT+01:00 Dawid Weiss dawid.we...@gmail.com 
  (mailto:dawid.we...@gmail.com):
   I agree with Anders, no surprise principle. Fail early. I spent a good
   while trying to figure out what the heck is happening with this --
   http://jira.codehaus.org/browse/MASSEMBLY-724
   
   Dawid
   
   On Thu, Oct 30, 2014 at 1:05 PM, Anders Hammar and...@hammar.net 
   (mailto:and...@hammar.net) wrote:
Wouldn't it make sense to fail the build in case of this instead? As I 
see
it, there's something wrong in the descriptor and it should be fixed.

Also, doing this change (intead of just altering the algorithm) would 
make
the plugin upgrade better (no suprises in the result). A failed build
with a good message instead.

/Anders

On Thu, Oct 30, 2014 at 12:57 PM, Kristian Rosenvold 
kristian.rosenv...@gmail.com (mailto:kristian.rosenv...@gmail.com) 
wrote:

 There's a truckload of jira issues related to the inclusion algorithm,
 and there just seems to be so many simpler ways of handling this ?
 
 filesets/dependencysets/files processed in descriptor order (or
 reverse descriptor) order, first file wins. Reversing descriptor order
 would make last file win.
 
 Within a single set, first file always wins.
 
 What is the use case being solved by the existing algorithm ?? And why
 does it try to block based on input rather than assembly-output name
 ?
 
 Kristian
 
 
 
 2014-10-30 12:54 GMT+01:00 Kristian Rosenvold 
 kristian.rosenv...@gmail.com (mailto:kristian.rosenv...@gmail.com):
  Reading the instructions on
 
 http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html
  makes me wonder, why on earth has this precedence been chosen for 
  the
  assembly plugin ??? Especially case 2 is odd.
  
  There'
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
 (mailto:dev-unsubscr...@maven.apache.org)
 For additional commands, e-mail: dev-h...@maven.apache.org 
 (mailto:dev-h...@maven.apache.org)
 


   
   
   -
   To unsubscribe, e-mail: 

Re: Cannot Inject MavenRepositorySystem into my Plugin Mojo

[Stuart McCulloch]

The org.apache.maven.bridge package is not currently exposed to plugins from 
maven-core (see importMavenApi in DefaultClassRealmManager) which is why you 
get an exception trying to access it.

Could you use the org.apache.maven.repository.RepositorySystem component 
instead? This would also be more portable since the MavenRepositorySystem 
component was only recently added in 3.2.3

-- 
Cheers, Stuart


On Monday, 6 October 2014 at 12:31, Arnaud Derasse wrote:

 Hello all,
 
 --
 -- Short Version --
 --
 I am tryting to access MavenRepositorySystem from my mojo to
 call buildArtifactRepository()
 When executing the goal, I have a ClassDefNotFound error :
 
 [WARNING] Error injecting:
 com.enyx.maven.plugin.enyx_maven_plugin.EnyxValidate
 java.lang.NoClassDefFoundError:
 Lorg/apache/maven/bridge/MavenRepositorySystem;
 at java.lang.Class.getDeclaredFields0(Native Method)
 at java.lang.Class.privateGetDeclaredFields(Class.java:2436)
 at java.lang.Class.getDeclaredFields(Class.java:1806)
 at
 com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:661)
 []
 Caused by: java.lang.ClassNotFoundException:
 org.apache.maven.bridge.MavenRepositorySystem
 at
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
 at
 org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
 
 [...]
 [ERROR] Failed to execute goal
 com.enyx.maven.plugins:enyx-maven-plugin:0.0.3-SNAPSHOT:validate
 (default-validate) on project libenyxcom: Execution default-validate of
 goal com.enyx.maven.plugins:enyx-maven-plugin:0.0.3-SNAPSHOT:validate
 failed: A required class was missing while executing
 com.enyx.maven.plugins:enyx-maven-plugin:0.0.3-SNAPSHOT:validate:
 Lorg/apache/maven/bridge/MavenRepositorySystem;
 
 
 I am using Maven 3.2.3, the class IS in the maven-core-3.2.3.jar in my lib/
 dir of my maven install.
 I do not understand why I :
 - Can't inject the MavenRepositorySystem instance.
 - Can't even use the static function buildArtifactRepository() from
 MavenRepositorySystem, if I remove this from my mojo class :
 @Component
 private MavenRepositorySystem repoSystem;
 I still get a Class not found error like this :
 
 [INFO] --- enyx-maven-plugin:0.0.3-SNAPSHOT:validate (default-validate) @
 libenyxcom ---
 [INFO] Detected Host System : Debian - Unknown
 [ERROR] This version of your Host Platform does not have Deployment
 Information
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 1.111 s
 [INFO] Finished at: 2014-10-06T13:24:43+02:00
 [INFO] Final Memory: 7M/152M
 [INFO]
 
 [ERROR] Failed to execute goal
 com.enyx.maven.plugins:enyx-maven-plugin:0.0.3-SNAPSHOT:validate
 (default-validate) on project libenyxcom: Execution default-validate of
 goal com.enyx.maven.plugins:enyx-maven-plugin:0.0.3-SNAPSHOT:validate
 failed: A required class was missing while executing
 com.enyx.maven.plugins:enyx-maven-plugin:0.0.3-SNAPSHOT:validate:
 org/apache/maven/bridge/MavenRepositorySystem
 [ERROR] -
 [ERROR] realm =
 plugincom.enyx.maven.plugins:enyx-maven-plugin:0.0.3-SNAPSHOT
 [ERROR] strategy =
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
 [ERROR] urls[0] =
 file:/home/derassea/.m2/repository/com/enyx/maven/plugins/enyx-maven-plugin/0.0.3-SNAPSHOT/enyx-maven-plugin-0.0.3-SNAPSHOT.jar
 [ERROR] urls[1] =
 file:/home/derassea/.m2/repository/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar
 [ERROR] urls[2] =
 file:/home/derassea/.m2/repository/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar
 [ERROR] urls[3] =
 file:/home/derassea/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar
 [ERROR] urls[4] =
 file:/home/derassea/.m2/repository/com/google/guava/guava/10.0.1/guava-10.0.1.jar
 [ERROR] urls[5] =
 file:/home/derassea/.m2/repository/com/google/code/findbugs/jsr305/1.3.9/jsr305-1.3.9.jar
 [ERROR] urls[6] =
 file:/home/derassea/.m2/repository/org/sonatype/sisu/sisu-guice/3.1.0/sisu-guice-3.1.0-no_aop.jar
 [ERROR] urls[7] =
 file:/home/derassea/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar
 [ERROR] urls[8] =
 file:/home/derassea/.m2/repository/org/eclipse/sisu/org.eclipse.sisu.inject/0.0.0.M5/org.eclipse.sisu.inject-0.0.0.M5.jar
 [ERROR] urls[9] =
 file:/home/derassea/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
 [ERROR] urls[10] =
 file:/home/derassea/.m2/repository/org/apache/maven/plugin-tools/maven-plugin-annotations/3.3/maven-plugin-annotations-3.3.jar
 [ERROR] urls[11] =
 file:/home/derassea/.m2/repository/com/googlecode/cmake-maven-project/cmake-maven-plugin/2.8.11-b4/cmake-maven-plugin-2.8.11-b4.jar
 

Re: Maven wagon-http Issue

[Stuart McCulloch]

On 25 Sep 2014, at 03:34, Igor Fedorenko i...@ifedorenko.com wrote:

 No, you are not missing anything. We don't usually use the connector as
 build extension and there appear some sisu/guice related bugs that
 result in the exception you see.

I took a quick look and it’s not actually a bug in sisu/guice causing this - 
basically the issue is that the @Nullable annotation in the connector code is 
not visible when it’s used as an extension (due to Maven realm filtering). This 
means the JVM silently removes the annotation as if it was never there, so the 
code in guice which checks for @Nullable never sees it. Possible solutions 
would be to add that package to the ones exported from maven core, or use a 
different @Nullable annotation that is visible from the extension (the package 
doesn’t matter, guice will honour any annotation named @Nullable as long as its 
visible), or use Provider to defer accessing the value.

 I just released version 0.12.1 of the connector, which appears to work
 with maven 3.2.3 and I assume will work with earlier 3.2.1 versions too.
 You can get the new version from our releases repository [1] or wait
 another 15-20 minutes before the artifacts are synced to central.
 
 Please note that with pom.xml extensions you will still use maven
 default http/https wagon to download the connector itself. This is why
 we normally use the connector as part of custom maven distribution, like
 the one we embed in m2e, for example.
 
 [1] http://repository.takari.io:8081/nexus/content/repositories/releases/
 
 --
 Regards,
 Igor
 
 On 2014-09-24, 22:20, Mark Nelson wrote:
 Same error with 0.12.0 - maybe I am missing some necessary configuration?
 All I did was add a build/extension with the GAV for this wagon.
 Is there anything else I need to do to enable it?
 
 Mark Nelson | Architect | 61.2.9491.1177
 Platform Engineering
 Oracle Development
 http://redstack.wordpress.com/
 
 Oracle BPM Suite 11g: Advanced BPMN Topics
 by Mark Nelson and Tanya Williams
 http://bit.ly/UbNKLD
 
 On 9/25/2014 12:11 PM, Mark Nelson wrote:
 Thanks for the suggestion, but it still gives the same error.
 
 Mark Nelson | Architect | 61.2.9491.1177
 Platform Engineering
 Oracle Development
 http://redstack.wordpress.com/
 
 Oracle BPM Suite 11g: Advanced BPMN Topics
 by Mark Nelson and Tanya Williams
 http://bit.ly/UbNKLD
 
 On 9/25/2014 12:04 PM, Jason van Zyl wrote:
 We updated 0.13.1 of the connector to use Aether 1.0, but 3.2.3 still
 uses 0.9.0.M2 so you'll need to use the 0.13.0 version of the
 connector. There were API changes in Aether.
 
 On Sep 24, 2014, at 9:11 PM, Mark Nelson mark.x.nel...@oracle.com
 wrote:
 
 I tired 3.2.1 and 3.2.3.
 
 Mark Nelson | Architect | 61.2.9491.1177
 Platform Engineering
 Oracle Development
 http://redstack.wordpress.com/
 
 Oracle BPM Suite 11g: Advanced BPMN Topics
 by Mark Nelson and Tanya Williams
 http://bit.ly/UbNKLD
 
 On 9/25/2014 11:09 AM, Igor Fedorenko wrote:
 What maven version do you use?
 
 On September 24, 2014 9:00:00 PM EDT, Mark Nelson
 mark.x.nel...@oracle.com wrote:
 Hi Igor,
 
 I am trying to use this okhttp-based wagon, but it is giving me an
 odd
 error that I have not seen before.
 I tried different versions of Maven and Java (7 and 8), and I went
 through the code to see if I could find any configuration properties
 that I needed to set in a build/plugin/configuration entry, but I
 could
 
 not find anything.
 
 I added the wagon like this:
 
   extension
 groupIdio.takari.aether/groupId
 artifactIdaether-connector-okhttp/artifactId
 version0.13.1/version
   /extension
 
 And the error is below.
 
 Would very much appreciate if you could point out anything I am
 missing/doing wrong.
 
 
 [INFO]
 
 
 [INFO] BUILD FAILURE
 [INFO]
 
 
 [INFO] Total time: 0.595 s
 [INFO] Finished at: 2014-09-25T10:49:50+10:00
 [INFO] Final Memory: 5M/288M
 [INFO]
 
 
 [ERROR] Internal error: com.google.inject.ProvisionException: Guice
 provision errors:
 [ERROR]
 [ERROR] 1) null returned by binding at
 org.eclipse.sisu.wire.LocatorWiring
 [ERROR] but parameter 1 of
 io.takari.aether.connector.AetherRepositoryConnectorFactory.init()
 is
 
 not @Nullable
 [ERROR] while locating javax.net.ssl.SSLSocketFactory
 [ERROR] for parameter 1 at
 io.takari.aether.connector.AetherRepositoryConnectorFactory.init(Unknown
 
 
 Source)
 [ERROR] while locating
 io.takari.aether.connector.AetherRepositoryConnectorFactory
 [ERROR] at
 ClassRealm[extensionio.takari.aether:aether-connector-okhttp:0.13.1,
 parent: sun.misc.Launcher$AppClassLoader@5c647e05]
 [ERROR] at
 ClassRealm[extensionio.takari.aether:aether-connector-okhttp:0.13.1,
 parent: sun.misc.Launcher$AppClassLoader@5c647e05]
 [ERROR] while locating
 

Re: Problem while getting injected parameters from plugin configuration.

[Stuart McCulloch]

On 21 Sep 2014, at 22:54, animator l.gadaw...@gmail.com wrote:

 Thanks for answers! 
 
 I removed reporting section and unfortunately it doesn't work.. (*1)(btw.
 before that I added reporting api and declared InstrumentMojo extends
 AbstractMavenReport but this doesn't work too). 
 
 I suppose may be there is problem with plexus, because when I added
 Component annotations that you suggested (*2) I got following error:

If you want ClojureExecutorImpl to be a Plexus @Component then you should 
provide a no-argument constructor, since Plexus semantics only support setter 
or field injection (using @Requirement to mark the method/field).

To access the Log inside your component, either add a @Requirment annotated 
setter/field or extend AbstractLogEnabled.

 /...
 [WARNING] Error injecting:
 com.gadawski.maven.plugins.cloverage.goals.InstrumentMojo
 com.google.inject.ProvisionException: Guice provision errors:
 
 1) No implementation for
 com.gadawski.maven.plugins.cloverage.ClojureExecutor was bound.
  while locating com.gadawski.maven.plugins.cloverage.goals.InstrumentMojo
 .../
 
 despite adding needed annotations. Do I need any special configuration for
 plexus or anything else?
 
 *1
 https://github.com/lgadawski/test-polyglot-project/commit/ef847f98381adcb1127ab278b84962a201195d7a
 *2
 https://github.com/lgadawski/cloverage-maven-plugin/commit/0f99966fbb965be8c4d79845617e0a4ed748bc54
 
 
 
 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Problem-while-getting-injected-parameters-from-plugin-configuration-tp5805894p5805996.html
 Sent from the Maven Developers mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 


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

Re: Problem while getting injected parameters from plugin configuration.

[Stuart McCulloch]

On 22 Sep 2014, at 23:34, animator l.gadaw...@gmail.com wrote:

 The main problem from the topic finally I managed to resolve. The problem was
 wrong configuration in test-polyglot-project, the groupId of declared plugin
 in pom was wrong and when the goal was executed it was used plugin from
 local repository and any configuration from pom was omitted.. Anyway thanks
 for advices!
 
 Second problem with injecting plexus components still exists.. I added no
 arg constructor and @Requirement annotation but still I get the same
 exceptions.

Hi,

I took a quick look at your project, to get Maven to see ClojureExecutorImpl as 
a Plexus component you need to generate some extra XML metadata for it (this is 
separate to the Maven plugin metadata generation):

plugin
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-component-metadata/artifactId
version1.5.5/version
executions
execution
goals
goalgenerate-metadata/goal
/goals
/execution
/executions
/plugin

This writes a file to target/classes/META-INF/plexus/components.xml” which 
Plexus* will read to discover the components. Maven configures Plexus to only 
use index files, rather than full classpath scanning, so without this metadata 
the component won’t be visible. Note that if you only plan to target Maven 
3.1.x and above then you can use the more modern JSR330 annotations as 
explained in http://maven.apache.org/maven-jsr330.html and 
http://wiki.eclipse.org/Sisu/PlexusMigration - but for maximum Maven 
compatibility its best to stick with Plexus annotations for now (at least wrt 
re-usable components, Maven mojos should use the mojo-specific annotations).

Secondly, ClojureExecutorImpl should inject the Plexus logger 
(org.codehaus.plexus.logging.Logger) because the Maven logger 
(org.apache.maven.plugin.logging.Log) is a special component only visible to 
mojos and is not available for Plexus components - underneath it logs to the 
same place, just gets exposed as a different API according to the injection 
context. The mojo specific injection is handled in a layer built on top of 
Plexus.

BTW if ClojureExecutorImpl is not expected to have injected setters/fields 
(apart from logging), or you plan to only create instances using new, then 
making it a Plexus component is overkill. Looking at other maven plugins they 
typically either have non-injected components that they assemble themselves, or 
they use simple Plexus components and pass any Maven-specific context (that’s 
not visible to the Plexus context) in as method parameters.

Anyway, with these two changes I was able to get the plugin working in the test 
project, so hopefully this explanation helps.

* actually the work is being done by Sisu’s Plexus adapter, which provides 
Plexus API+semantics on top of Guice

 Thanks for answers.
 
 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/Problem-while-getting-injected-parameters-from-plugin-configuration-tp5805894p5806136.html
 Sent from the Maven Developers mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: what is org.apache.maven:standalone-pom:pom:1,standalone-pom?

[Stuart McCulloch]

It’s a stub pom.xml that’s used whenever a MavenExecutionRequest has no 
associated pom.xml file:


https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/DefaultMaven.java#L644


https://github.com/apache/maven/blob/master/maven-core/src/main/resources/org/apache/maven/project/standalone.xml

On 14 Jul 2014, at 06:39, Dan Tran dant...@gmail.com wrote:

 Hi
 
 I am playing with DependencyGraphBuilder and seeing the following  artifact
 sneak into my list
 
 org.apache.maven:standalone-pom:pom:1,standalone-pom
 
 Any idea what it is?
 
 I am also seeing of of this from the build log, mine and from internet, but
 so far no-one seems to care
 
 Thanks
 
 -D

Re: [MJAVADOC-398] pull request

[Stuart McCulloch]

On 2 Jul 2014, at 07:18, Michael Osipov micha...@apache.org wrote:

 Am 2014-07-01 12:59, schrieb Michal Srb:
 Hello,
 
 I filed a bug [1] and opened pull request [2] for maven-javadoc-plugin.
 Please see links below for context. The real problem seems to be in
 javadoc tool, but it can be avoided by not putting compiled project
 classes on javadoc's -classpath. The question is: can such change
 break something? All comments and suggestions are appreciated.
 
 Thanks
 Michal
 
 [1]: http://jira.codehaus.org/browse/MJAVADOC-398
 [2]: https://github.com/apache/maven-plugins/pull/25
 
 For what it's worth, I have asked Michal to do so because this is a change in 
 behavior. If no one opposes, I will perform the merge.

Only thing I can think of are situations where the output directory contains 
code that has no equivalent in the source directory - not adding the output 
directory would then make a difference to javadoc. No idea if this is actually 
an issue in real-life, but IMHO it would be safer to add a new configuration 
option to control whether the output directories are passed to javadoc or not 
(and then default it to add). That way Michal can solve his particular use-case 
without changing the current behaviour (or if you chose to default it to not 
add then people who are affected by this change could still get the original 
behaviour).

( there may also be custom doclets that use class files for additional 
analysis? )

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

Re: Which is the real duplicate?

[Stuart McCulloch]

Looks like they’re both linked as duplicates of 
http://jira.codehaus.org/browse/MNG-5637 - should that issue be marked as fixed 
in 3.2.2?

On 23 May 2014, at 19:24, Paul Benedict pbened...@apache.org wrote:

 Both MNG-5633 http://jira.codehaus.org/browse/MNG-5633 and MNG-5628
 http://jira.codehaus.org/browse/MNG-5628 are listed as fixed in 3.2.2
 and both resolved are duplicates. The real one should be fixed as
 Resolved and the duplicate should be taken out of the 3.2.2 version.
 
 Tips?
 
 Cheers,
 Paul


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

Re: Sonatype plugin question?

[Stuart McCulloch]

On 23 Feb 2014, at 00:08, Martin Gainty mgai...@hotmail.com wrote:
 I *think* the sonatype folk went home for weekend so I'll ask maven gurus

Odd assumption, why didn’t you at least try asking this question on nexus-user 
or nexus-dev?

 Close to getting a plugin working but when i start wrapper.exe the 
 wrapper.log displays this error:
 
 The following plugins were processed:
 jvm 1| ... 
 org.sonatype.nexus.plugins:stagingrules-nexus-plugin:1.0-SNAPSHOT :: 
 action=ACTIVATE result=BROKEN

Is this your own plugin? You should ideally choose a groupId that matches your 
organization/company

 jvm 1|Reason: Plugin artifact 
 com.sonatype.nexus:nexus-core:2.7.0::jar not found!

Looks like your pom.xml has a bad dependency - nexus-core has a groupId of 
org.sonatype.nexus and should be a provided dependency

In fact you should really just depend on nexus-plugin-api as explained in 
http://books.sonatype.com/nexus-book/reference/plugdev.html

 Ideas on where com.sonatype.nexus:nexus-core:2.7.0::jar should be located?
 
 local repo?
 some undisclosed maven repo?
 
 classpath?
 
 HELP!

Best way to get help is to ask this on either of the nexus mailing lists 
(http://www.sonatype.org/nexus/participate) - paste a copy of your plugin 
pom.xml

 Martin 


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

Re: releasing 3.2.1

[Stuart McCulloch]

On 14 Feb 2014, at 04:39, Jason van Zyl ja...@takari.io wrote:

 Ok, everything is in. Just running through my normal set of tests and I'll 
 try to get 3.2.1 staged later tonight or in the morning.

Does that include a fix for the issue Mark found building the dependency graph? 
http://www.mail-archive.com/dev@maven.apache.org/msg99645.html

 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 happiness is like a butterfly: the more you chase it, the more it will
 elude you, but if you turn your attention to other things, it will come
 and sit softly on your shoulder ...
 
 -- Thoreau 
 
 
 
 
 
 
 
 
 

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

Re: Maven Issue - pluginManagement - build Area Plugin

[Stuart McCulloch]

On 14 Feb 2014, at 08:09, Baptiste Mathus m...@batmat.net wrote:

 Seems like this super pom is versioned at github under the sonatype
 organization (?).
 
 Cf. scm tag in
 http://repo1.maven.org/maven2/org/codehaus/codehaus-parent/4/codehaus-parent-4.pom
 But https://github.com/sonatype/codehaus-parent gives a 404...
 
 Anyone?

Looks like it was moved into a general OSS parent pom repo:


https://github.com/sonatype/oss-parents/blob/master/codehaus-parent/pom.xml

 2014-02-14 9:01 GMT+01:00 Karl Heinz Marbaise khmarba...@gmx.de:
 
 Hi Anders,
 
 
 I reported this Codehaus parent issue a long time ago (HAUS-2245 [1]).
 
 Good to know...
 
 
 Unfortunately the codehaus-parent seems to be in a unmaintained state.
 
 
 Who is responsible for the codehaus-parent ? Can we (or i) take the issue
 and fix it ?
 
 
 
 /Anders
 
 [1] http://jira.codehaus.org/i#browse/HAUS-2245
 
 
 On Wed, Feb 12, 2014 at 9:07 PM, Karl Heinz Marbaise khmarba...@gmx.de
 wrote:
 
 Hi,
 i have a question. The following situation. Pom file which uses the
 following parent:
 
 parent
 groupIdorg.codehaus/groupId
 artifactIdcodehaus-parent/artifactId
 version4/version
 /parent
 
 prerequisites
   maven${mavenVersion}/maven
 /prerequisites
 
 and the following part in my pom file:
 
 build
 pluginManagement
 plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-enforcer-plugin/artifactId
 version1.3.1/version
 /plugin
 /plugins
 /pluginManagement
 plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-enforcer-plugin/artifactId
   executions
 execution
   idenforce-maven/id
   goals
   ... The rule does not matter..
 
 
 So if i call (Maven 2.2.1)
 
 mvn clean package I got the following error:
 
 [INFO] [clean:clean {execution: default-clean}]
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to configure plugin parameters for:
 org.apache.maven.plugins:
 maven-enforcer-plugin:1.0
 
 Cause: Class 'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot be
 instantiated
 
 So if i call with Maven 3.0.5:
 
 [ERROR] Failed to execute goal org.apache.maven.plugins:
 maven-enforcer-plugin:1.0:enforce (enforce-maven) on project
 test-enforcer: Unable to parse configuration of mojo
 org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce for parameter
 requireSameVersions: Abstract class or interface
 'org.apache.maven.enforcer.rule.api.EnforcerRule'
 cannot be instantiated - [Help 1]
 
 Maven 3.1.X and Maven 3.2.X tested as well...
 
 So this looks to me that the pluginManagement does not overwrite the
 version 1.0 which is defined in the codehaus-parent. To be honest the
 codehaus-parent does not define it via pluginManagement it just uses the
 following:
 
 build
 plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-enforcer-plugin/artifactId
 version1.0/version
 executions
 execution
 idenforce-maven/id
 goals
 goalenforce/goal
 /goals
 configuration
 rules
 requireMavenVersion
 
 version(,2.1.0),(2.1.0,2.2.0),(2.2.0,)/version
 messageMaven 2.1.0 and 2.2.0
 produce
 incorrect GPG signatures and checksums respectively./message
 /requireMavenVersion
 /rules
 /configuration
 /execution
 /executions
 /plugin
 /plugins
 
 
 First the codehaus-parent seemed to be wrong...so i can't overwrite the
 version of the plugin by using a pluginManagement block in inherited
 project which forces me to define the version explicitly in my pom in the
 build block to get that working like this:
 
 plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-enforcer-plugin/artifactId
   version1.3.1/version
   executions
 
 
 WDYT ? Bug ? Right behaviour ?
 
 
 Kind regards
 Karl-Heinz Marbaise
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 
 
 Mit freundlichem Gruß
 Karl-Heinz Marbaise
 --
 SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
 

Re: Linkage error

[Stuart McCulloch]

On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com 
wrote:

 Stuart,
 
 We're seeing java.lang.LinkageError: loader constraint violation: loader
 (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
 initiated loading for a different type with name
 javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I
 can't really see this seeping through in DefaultClassRealmManager, but
 google shows me https://java.net/jira/browse/GLASSFISH-20802
 
 Is this something you understand ?

DefaultClassRealmManager currently exposes the complete javax.enterprise.inject 
package from CDI-API:

imports.put( javax.enterprise.inject.*, coreRealm );

This package contains annotations, exceptions, and one interface - and it looks 
like the interface pulls in a type from javax.enterprise.util:


http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...)

Which means that while javax.enterprise.inject.Instance is loaded and exposed 
from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core 
but not exposed - this is likely the cause of the constraint violation.

There are two solutions - first we could narrow the exposure in 
DefaultClassRealmManager to:

imports.put( javax.enterprise.inject.Typed, coreRealm );

since that is the only CDI annotation we’re really interested in, and it has no 
dependencies to other types.

Alternatively we could widen the exposure to include the javax.enterprise.util 
package:

imports.put( javax.enterprise.inject.*, coreRealm );
imports.put( javax.enterprise.util.*, coreRealm );

which should also fix the loader constraint while not introducing other issues.

WDYT?

 Kristian


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

Re: Linkage error

[Stuart McCulloch]

On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote:

 I would consider something like SFL4J as something which is now part of our 
 API think it's fine to expose something like that. I'm not sure the same 
 holds true for CDI. Wouldn't it be better just to completely hide it?

As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, the 
@javax.enterprise.inject.Typed annotation can be used to restrict the type 
visibility of components.

Hiding this package means you wouldn’t be able to use this feature outside of 
Maven core - so I guess it depends whether you consider CDI’s @Typed part of 
the component API like JSR330’s @Inject.

The CDI API is at least standardised (one of the reasons why the container 
respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t 
be as portable).

 On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com 
 wrote:
 
 Stuart,
 
 We're seeing java.lang.LinkageError: loader constraint violation: loader
 (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
 initiated loading for a different type with name
 javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I
 can't really see this seeping through in DefaultClassRealmManager, but
 google shows me https://java.net/jira/browse/GLASSFISH-20802
 
 Is this something you understand ?
 
 DefaultClassRealmManager currently exposes the complete 
 javax.enterprise.inject package from CDI-API:
 
   imports.put( javax.enterprise.inject.*, coreRealm );
 
 This package contains annotations, exceptions, and one interface - and it 
 looks like the interface pulls in a type from javax.enterprise.util:
 
  
 http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...)
 
 Which means that while javax.enterprise.inject.Instance is loaded and 
 exposed from the core realm, javax.enterprise.util.TypeLiteral will be 
 loaded from core but not exposed - this is likely the cause of the 
 constraint violation.
 
 There are two solutions - first we could narrow the exposure in 
 DefaultClassRealmManager to:
 
  imports.put( javax.enterprise.inject.Typed, coreRealm );
 
 since that is the only CDI annotation we’re really interested in, and it has 
 no dependencies to other types.
 
 Alternatively we could widen the exposure to include the 
 javax.enterprise.util package:
 
   imports.put( javax.enterprise.inject.*, coreRealm );
   imports.put( javax.enterprise.util.*, coreRealm );
 
 which should also fix the loader constraint while not introducing other 
 issues.
 
 WDYT?
 
 Kristian
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 Selfish deeds are the shortest path to self destruction.
 
 -- The Seven Samuari, Akira Kurosawa
 
 
 
 
 
 
 
 
 


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

Re: Linkage error

[Stuart McCulloch]

On 13 Feb 2014, at 14:43, Jason van Zyl ja...@takari.io wrote:
 On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote:
 
 I would consider something like SFL4J as something which is now part of our 
 API think it's fine to expose something like that. I'm not sure the same 
 holds true for CDI. Wouldn't it be better just to completely hide it?
 
 As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, 
 the @javax.enterprise.inject.Typed annotation can be used to restrict the 
 type visibility of components.
 
 Hiding this package means you wouldn’t be able to use this feature outside 
 of Maven core - so I guess it depends whether you consider CDI’s @Typed part 
 of the component API like JSR330’s @Inject.
 
 I would say I don't consider it part of our API, so I'd be inclined to hide 
 it and strictly stick to JSR330. Will Sisu not load without it?

Hiding this package disables the optional runtime support for @Typed, but does 
not affect other container features - the container will still load without it.

 I think we keep running into these issues with App Servers because people are 
 trying to run their App Server in Maven's runtime environment which doesn't 
 really make sense. For any of these strange conflicts that arise with SLF4J 
 or other APIs I think we should just encourage people to run any sort of test 
 for your App Server with an environment akin to production in that you should 
 fork once with your own classpath and whatever else you need. Maven's APIs 
 and runtime environment are for build related activities. Where we have this 
 cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should 
 just tell people the best thing to do is fork once and do what you like.
 
 The CDI API is at least standardised (one of the reasons why the container 
 respects @Typed rather than creating it’s own ad-hoc annotation which 
 wouldn’t be as portable).
 
 Why would we need it? You have any use cases at hand?

I don’t know if anything in Maven uses it at the moment, it’s mainly to aid 
migration from Plexus (which always restricted a component's type visibility to 
its specific role class) to the new JSR330 model where a component’s type 
visibility is open - ie. it’s visible as any type in its hierarchy - unless you 
use @Typed to limit it to specific roles. I have some examples where it was 
useful in migrating legacy Plexus applications, but nothing specific to Maven.

 On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 On 13 Feb 2014, at 07:28, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
 Stuart,
 
 We're seeing java.lang.LinkageError: loader constraint violation: loader
 (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
 initiated loading for a different type with name
 javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I
 can't really see this seeping through in DefaultClassRealmManager, but
 google shows me https://java.net/jira/browse/GLASSFISH-20802
 
 Is this something you understand ?
 
 DefaultClassRealmManager currently exposes the complete 
 javax.enterprise.inject package from CDI-API:
 
 imports.put( javax.enterprise.inject.*, coreRealm );
 
 This package contains annotations, exceptions, and one interface - and it 
 looks like the interface pulls in a type from javax.enterprise.util:
 

 http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...)
 
 Which means that while javax.enterprise.inject.Instance is loaded and 
 exposed from the core realm, javax.enterprise.util.TypeLiteral will be 
 loaded from core but not exposed - this is likely the cause of the 
 constraint violation.
 
 There are two solutions - first we could narrow the exposure in 
 DefaultClassRealmManager to:
 
imports.put( javax.enterprise.inject.Typed, coreRealm );
 
 since that is the only CDI annotation we’re really interested in, and it 
 has no dependencies to other types.
 
 Alternatively we could widen the exposure to include the 
 javax.enterprise.util package:
 
 imports.put( javax.enterprise.inject.*, coreRealm );
 imports.put( javax.enterprise.util.*, coreRealm );
 
 which should also fix the loader constraint while not introducing other 
 issues.
 
 WDYT?
 
 Kristian
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 Selfish deeds are the shortest path to self destruction.
 
 -- The Seven Samuari, Akira Kurosawa

Re: Linkage error

[Stuart McCulloch]

On 13 Feb 2014, at 17:08, Kristian Rosenvold kristian.rosenv...@gmail.com 
wrote:
 Wouldn't it make more sense to roll our own version of typed then?

Why roll our own when there’s a standard annotation available?  I can always 
add our own version of @Typed under a different package, but that doesn’t seem 
to encourage re-use.

 Leaking ee stuff from core does not seem like nice thing.
 
 Kristian (Who will only touch ee stuff with a pitchfork)
 
 2014-02-13 18:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com:
 
 Please keep @Typed annotation available outside of core.
 
 I use @Typed annotation in one of my (private) core extensions where I
 need a class to implement an interface but not make that interface
 visible for injection in other components.
 
 --
 Regards,
 Igor
 
 
 On 2/13/2014, 9:43, Jason van Zyl wrote:
 
 
 On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote:
 
 I would consider something like SFL4J as something which is now part of
 our API think it's fine to expose something like that. I'm not sure the
 same holds true for CDI. Wouldn't it be better just to completely hide it?
 
 
 As mentioned in http://wiki.eclipse.org/Sisu/
 PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed
 annotation can be used to restrict the type visibility of components.
 
 Hiding this package means you wouldn't be able to use this feature
 outside of Maven core - so I guess it depends whether you consider CDI's
 @Typed part of the component API like JSR330's @Inject.
 
 
 I would say I don't consider it part of our API, so I'd be inclined to
 hide it and strictly stick to JSR330. Will Sisu not load without it? I
 think we keep running into these issues with App Servers because people are
 trying to run their App Server in Maven's runtime environment which doesn't
 really make sense. For any of these strange conflicts that arise with SLF4J
 or other APIs I think we should just encourage people to run any sort of
 test for your App Server with an environment akin to production in that you
 should fork once with your own classpath and whatever else you need.
 Maven's APIs and runtime environment are for build related activities.
 Where we have this cross over like like the 
 jetty/tomcat/wildfly-maven-plugin
 I think we should just tell people the best thing to do is fork once and do
 what you like.
 
 The CDI API is at least standardised (one of the reasons why the
 container respects @Typed rather than creating it's own ad-hoc annotation
 which wouldn't be as portable).
 
 
 Why would we need it? You have any use cases at hand?
 
 On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 On 13 Feb 2014, at 07:28, Kristian Rosenvold 
 kristian.rosenv...@gmail.com wrote:
 
 Stuart,
 
 We're seeing java.lang.LinkageError: loader constraint violation:
 loader
 (instance of org/codehaus/plexus/classworlds/realm/ClassRealm)
 previously
 initiated loading for a different type with name
 javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on
 3.1. I
 can't really see this seeping through in DefaultClassRealmManager, but
 google shows me https://java.net/jira/browse/GLASSFISH-20802
 
 Is this something you understand ?
 
 
 DefaultClassRealmManager currently exposes the complete
 javax.enterprise.inject package from CDI-API:
 
  imports.put( javax.enterprise.inject.*, coreRealm );
 
 This package contains annotations, exceptions, and one interface - and
 it looks like the interface pulls in a type from javax.enterprise.util:
 
http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/
 Instance.html#select(javax.enterprise.util.TypeLiteral,%
 20java.lang.annotation.Annotation...)
 
 Which means that while javax.enterprise.inject.Instance is loaded and
 exposed from the core realm, javax.enterprise.util.TypeLiteral will
 be loaded from core but not exposed - this is likely the cause of the
 constraint violation.
 
 There are two solutions - first we could narrow the exposure in
 DefaultClassRealmManager to:
 
imports.put( javax.enterprise.inject.Typed, coreRealm );
 
 since that is the only CDI annotation we're really interested in, and
 it has no dependencies to other types.
 
 Alternatively we could widen the exposure to include the
 javax.enterprise.util package:
 
  imports.put( javax.enterprise.inject.*, coreRealm );
  imports.put( javax.enterprise.util.*, coreRealm );
 
 which should also fix the loader constraint while not introducing
 other issues.
 
 WDYT?
 
 Kristian
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io

Re: [VOTE][CANCELLED] Release Maven 3.2.0

[Stuart McCulloch]

On 11 February 2014 22:15, Olivier Lamy ol...@apache.org wrote:

 Noticed this non blocking issue when using activemq plugin to start an
 activemq instance:

 [INFO] BUILD SUCCESS

 [INFO]
 

 [INFO] Total time: 17.840s

 [INFO] Finished at: Wed Feb 12 09:12:23 EST 2014

 [INFO] Final Memory: 33M/733M

 [INFO]
 

 [INFO] Apache ActiveMQ 5.9.0 (localhost,
 ID:mb-olamy.local-49682-1392156741632-0:1) is shutting down

 [INFO] Connector tcp://localhost:49681 stopped

 Exception in thread ActiveMQ ShutdownHook
 java.lang.NoClassDefFoundError:
 org/apache/activemq/transport/vm/VMTransportFactory


I suspect this is related to the change in Classworlds 2.4.1+ to use the
new ClassLoader.close() method available in Java7 to forcibly close plugin
ClassLoaders when the plugin/container realm is disposed. This happens
after the Maven build is finished, but before JVM shutdown hooks run.

Any plugin that registers a JVM shutdown hook which tries to load
classes/resources from the original plugin realm will throw a NCDFE -
you'll probably see similar issues if a plugin forks threads that are still
running after the plugin/container realm has been disposed and subsequently
try to load classes.

( note that the same error will likely occur with Maven 3.1.1 since it uses
the same version of Classworlds )


 at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:733)

 at
 org.apache.activemq.broker.BrokerService.containerShutdown(BrokerService.java:2348)

 at org.apache.activemq.broker.BrokerService$6.run(BrokerService.java:2315)

 Caused by: java.lang.ClassNotFoundException:
 org.apache.activemq.transport.vm.VMTransportFactory

 at
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)

 at
 org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)

 at
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)

 at
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)

 ... 3 more

 Not blocker as it work as expected but just a bit annoying

 On 12 February 2014 07:37, Jason van Zyl ja...@takari.io wrote:
  Couple issues cropped up so I'm canceling the vote.
 
  On Feb 10, 2014, at 9:18 PM, Jason van Zyl ja...@takari.io wrote:
 
  Hi,
 
  Time to release Maven 3.2.0!
 
  Here is a link to Jira with 33 issues resolved:
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=15565
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1005/
 
  The distributable binaries and sources for testing can be found here:
 
 https://repository.apache.org/content/repositories/maven-1005/org/apache/maven/apache-maven/3.2.0/
 
  Specifically the zip, tarball, and source archives can be found here:
 
 https://repository.apache.org/content/repositories/maven-1005/org/apache/maven/apache-maven/3.2.0/apache-maven-3.2.0-bin.zip
 
 https://repository.apache.org/content/repositories/maven-1005/org/apache/maven/apache-maven/3.2.0/apache-maven-3.2.0-bin.tar.gz
 
 https://repository.apache.org/content/repositories/maven-1005/org/apache/maven/apache-maven/3.2.0/apache-maven-3.2.0-src.zip
 
 https://repository.apache.org/content/repositories/maven-1005/org/apache/maven/apache-maven/3.2.0/apache-maven-3.2.0-src.tar.gz
 
  Source release checksum(s):
  apache-maven-3.2.0-src.zip sha1:
 4bc1ad352c07eef6e6b92c4923d1578d813bc57b
 
  Staging site:
  http://people.apache.org/~jvanzyl/maven-3.2.0/
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  Thanks,
 
  The Maven Team
  Thanks,
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  A language that doesn't affect the way you think about programming is
 not worth knowing.
 
   -- Alan Perlis
 
 
 
 
 
 
 
 
 



 --
 Olivier Lamy
 Ecetera: http://ecetera.com.au
 http://twitter.com/olamy | http://linkedin.com/in/olamy

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




-- 
Cheers, Stuart

Re: [VOTE][CANCELLED] Release Maven 3.2.0

[Stuart McCulloch]

On 11 February 2014 23:26, Dan Tran dant...@gmail.com wrote:

 Thanks Stuart for this confirmation, I am seeing this exact issue happen on
 both 3.1.x and 3.2. My build uses truezip-maven-plugin


Yep, TrueZip will leave a JVM shutdown hook registered unless you
explicitly unmount the virtual file system after you're done with it - in
most cases this is just an oversight and unmounting will also help conserve
resources, see example in
https://github.com/klieber/phantomjs-maven-plugin/pull/19/files


 [INFO]
 
 [INFO] BUILD SUCCESS
 [INFO]
 
 [INFO] Total time: 19.347s
 [INFO] Finished at: Tue Feb 11 15:24:26 PST 2014
 [INFO] Final Memory: 33M/698M
 [INFO]
 
 java.lang.NoClassDefFoundError: de/schlichtherle/truezip/fs/FsSyncOptions
 at

 de.schlichtherle.truezip.fs.FsSyncShutdownHook$Hook.run(FsSyncShutdownHook.java:93)
 Caused by: java.lang.ClassNotFoundException:
 de.schlichtherle.truezip.fs.FsSyncOptions
 at

 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.ja
 va:50)
 at

 org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:
 259)
 at

 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
 at

 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
 ... 1 more


 On Tue, Feb 11, 2014 at 3:20 PM, Stuart McCulloch mccu...@gmail.com
 wrote:

  On 11 February 2014 22:15, Olivier Lamy ol...@apache.org wrote:
 
   Noticed this non blocking issue when using activemq plugin to start an
   activemq instance:
  
   [INFO] BUILD SUCCESS
  
   [INFO]
  
 
  
   [INFO] Total time: 17.840s
  
   [INFO] Finished at: Wed Feb 12 09:12:23 EST 2014
  
   [INFO] Final Memory: 33M/733M
  
   [INFO]
  
 
  
   [INFO] Apache ActiveMQ 5.9.0 (localhost,
   ID:mb-olamy.local-49682-1392156741632-0:1) is shutting down
  
   [INFO] Connector tcp://localhost:49681 stopped
  
   Exception in thread ActiveMQ ShutdownHook
   java.lang.NoClassDefFoundError:
   org/apache/activemq/transport/vm/VMTransportFactory
  
 
  I suspect this is related to the change in Classworlds 2.4.1+ to use the
  new ClassLoader.close() method available in Java7 to forcibly close
 plugin
  ClassLoaders when the plugin/container realm is disposed. This happens
  after the Maven build is finished, but before JVM shutdown hooks run.
 
  Any plugin that registers a JVM shutdown hook which tries to load
  classes/resources from the original plugin realm will throw a NCDFE -
  you'll probably see similar issues if a plugin forks threads that are
 still
  running after the plugin/container realm has been disposed and
 subsequently
  try to load classes.
 
  ( note that the same error will likely occur with Maven 3.1.1 since it
 uses
  the same version of Classworlds )
 
 
   at
 org.apache.activemq.broker.BrokerService.stop(BrokerService.java:733)
  
   at
  
 
 org.apache.activemq.broker.BrokerService.containerShutdown(BrokerService.java:2348)
  
   at
  org.apache.activemq.broker.BrokerService$6.run(BrokerService.java:2315)
  
   Caused by: java.lang.ClassNotFoundException:
   org.apache.activemq.transport.vm.VMTransportFactory
  
   at
  
 
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
  
   at
  
 
 org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
  
   at
  
 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
  
   at
  
 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
  
   ... 3 more
  
   Not blocker as it work as expected but just a bit annoying
  
   On 12 February 2014 07:37, Jason van Zyl ja...@takari.io wrote:
Couple issues cropped up so I'm canceling the vote.
   
On Feb 10, 2014, at 9:18 PM, Jason van Zyl ja...@takari.io wrote:
   
Hi,
   
Time to release Maven 3.2.0!
   
Here is a link to Jira with 33 issues resolved:
   
  
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=15565
   
Staging repo:
https://repository.apache.org/content/repositories/maven-1005/
   
The distributable binaries and sources for testing can be found
 here:
   
  
 
 https://repository.apache.org/content/repositories/maven-1005/org/apache/maven/apache-maven/3.2.0/
   
Specifically the zip, tarball, and source archives can be found
 here:
   
  
 
 https://repository.apache.org/content/repositories/maven-1005/org/apache/maven/apache-maven/3.2.0/apache-maven-3.2.0-bin.zip
   
  
 
 https://repository.apache.org/content

Re: Problem with transitive Guava dep

[Stuart McCulloch]

On 24 Jan 2014, at 23:49, Igor Fedorenko i...@ifedorenko.com wrote:

 This problem is specific to maven-plugin-testing-harness. You can use
 any version of Guava at runtime, but test classpath is flat so you need
 to use single Guava version that is compatible with all components.
 
 Unfortunately, I don't know how to fix the problem, at least not until
 Maven core is using OSGi ;-)
 
 You have two options in the meantime. Use Guava 14.0.1, which is
 compatible with Sisu or use Verifier-based tests, which are immune to
 this problem.

See also: https://code.google.com/p/google-guice/issues/detail?id=760 (migrate 
Guice to Guava’s new CacheBuilder API)

Fixed in Guice master: 
https://code.google.com/p/google-guice/source/detail?r=8743a0bb0fb49f30117c846880a7df2e7b36657e

and available in sisu-guice 3.1.7 and above (no change needed in Sisu itself).

 --
 Regards,
 Igor
 
 On 1/24/2014, 17:02, Manfred Moser wrote:
 In the Android Maven Plugin we use the maven-plugin-api, which has a
 transitive dependency to guava 10.0.1. Another dependency (android tools
 common) pulls in 13.0.1 and things are fine so far.
 
 However when I now upgrade to the latest version of the android tools I
 get 15.0. Problem is that causes my build to fail with errors related to
 sisu and guice as used by the maven-plugin-api
 
 E.g. java.lang.NoClassDefFoundError: Could not initialize class
 org.eclipse.sisu.wire.ParameterKeys
  at
 org.eclipse.sisu.wire.DependencyAnalyzer.init(DependencyAnalyzer.java:92)
  at org.eclipse.sisu.wire.ElementAnalyzer.init(ElementAnalyzer.java:87)
  at org.eclipse.sisu.wire.WireModule.configure(WireModule.java:74)
  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:477)
  at
 org.codehaus.plexus.DefaultPlexusContainer.init(DefaultPlexusContainer.java:203)
  at
 org.apache.maven.plugin.testing.AbstractMojoTestCase.setupContainer(AbstractMojoTestCase.java:227)
  at
 org.apache.maven.plugin.testing.AbstractMojoTestCase.getContainer(AbstractMojoTestCase.java:261)
  at
 org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:115)
  at
 com.jayway.maven.plugins.android.standalonemojos.UnpackMojoLazyTest.setUp(
 ...
 
 All these test failing extend  AbstractMojoTestCase ...
 
 Are there any plans to upgrade guava in sisu/maven? Any other ideas on
 what I can do to get this stuff to behave?
 
 manfred
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 


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

Re: Inject from multiple interfaces in plexus ?

[Stuart McCulloch]

On 8 Jan 2014, at 20:03, Kristian Rosenvold kristian.rosenv...@gmail.com 
wrote:

 With spring, you can say:
 
 @Component
 class X implements Y,Z
 
 And at call site:
 
 @Inject
 private Y y;
 
 @Inject
 private Z z;
 
 And expect (scope dependent) to get the same instance of X in both y and z.
 
 Can I achieve this in m3.2 core ?

Yes, but you’d need to use JSR330 @Named instead of Plexus @Component:

http://wiki.eclipse.org/Sisu/PlexusMigration

 Kristian


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

Re: 3.2.0 Bug Scrub

[Stuart McCulloch]

On 7 Jan 2014, at 15:39, Stephen Connolly stephen.alan.conno...@gmail.com 
wrote:

 * http://jira.codehaus.org/browse/MNG-4171 The XML resulting from a property 
 of java.util.Properties is a lot more clumsy than that for Map
 
Unsure what the ask is here... seems like it's really a plexus 
 compatibility layer issue

FYI, this alternative form of configuration is already possible - it was 
implemented by Benjamin a few years ago under 
https://issues.sonatype.org/browse/SISU-61


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

Re: Plugin phase awareness...

[Stuart McCulloch]

On 31 Dec 2013, at 12:51, Martin Gainty mgai...@hotmail.com wrote:

 --_d7af7d72-ddaf-4bb4-8989-06a73d80616e_
 Content-Type: text/plain; charset=iso-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 [DEBUG] test:lifecycle-phases-plugin:jar:1.0:
 [DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
 [DEBUG]   org.apache.maven:maven-model:jar:3.0:compile
 [DEBUG]   org.apache.maven:maven-artifact:jar:3.0:compile
 [DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
 [DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
 [DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
 [DEBUG]org.apache.maven:maven-core:jar:3.0:compile
 [DEBUG]   org.apache.maven:maven-settings:jar:3.0:compile
 [DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
 [DEBUG]  org.codehaus.mojo:animal-sniffer:jar:1.6:compile
 [DEBUG] asm:asm-all:jar:3.1:compile
 [DEBUG]  org.codehaus.plexus:plexus-component-metadata:jar:1.5.4:co=
 mpile
 [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.5.4:=
 compile
 [DEBUG]org.apache.xbean:xbean-reflect:jar:3.4:compile
 [DEBUG]   log4j:log4j:jar:1.2.12:compile
 [DEBUG]   commons-logging:commons-logging-api:jar:1.1:compi=
 le
 [DEBUG]com.google.collections:google-collections:jar:1.0:co=
 mpile
 [DEBUG]junit:junit:jar:3.8.2:compile
 [DEBUG] com.thoughtworks.qdox:qdox:jar:1.9.2:compile
 [DEBUG] jdom:jdom:jar:1.0:compile
 [DEBUG] org.apache.maven:maven-project:jar:2.0.9:compile
 [DEBUG]org.apache.maven.plugin-tools:maven-plugin-tools-api=
 :jar:3.0:compile
 [DEBUG]   org.apache.maven:maven-plugin-descriptor:jar:2.2.=
 1:compile
 [DEBUG]org.apache.maven:maven-profile:jar:2.0.9:compile
 [DEBUG]org.apache.maven:maven-artifact-manager:jar:2.0.9:co=
 mpile
 [DEBUG]org.apache.maven:maven-plugin-registry:jar:2.0.9:com=
 pile
 [DEBUG] org.codehaus.plexus:plexus-cli:jar:1.2:compile
 [DEBUG] commons-cli:commons-cli:jar:1.0:compile
 [DEBUG]commons-logging:commons-logging:jar:1.0:compile
 [DEBUG]commons-lang:commons-lang:jar:1.0:compile
 [DEBUG] asm:asm:jar:3.1:compile
 [DEBUG]   org.apache.maven:maven-repository-metadata:jar:3.0:compile
 [DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
 [DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
 [DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
 [DEBUG]  org.apache.maven.plugins:maven-surefire-plugin:jar:2.4.2:c=
 ompile
 [DEBUG] org.apache.maven.surefire:surefire-booter:jar:2.4.2:com=
 pile
 [DEBUG]org.apache.maven.surefire:maven-surefire-common:jar:=
 2.12.4:compile
 [DEBUG]   org.apache.maven.plugin-tools:maven-plugin-annota=
 tions:jar:3.1:compile
 [DEBUG]   org.apache.maven:maven-toolchain:jar:2.0.9:compil=
 e
 [DEBUG]   org.apache.commons:commons-lang3:jar:3.1:compile
 [DEBUG]   org.apache.maven.shared:maven-common-artifact-fil=
 ters:jar:1.3:compile
 [DEBUG]org.apache.maven.surefire:surefire-api:jar:2.4.2:com=
 pile
 [DEBUG] org.apache.maven.surefire:surefire-junit:jar:2.4.2:comp=
 ile
 [DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
 [DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
 [DEBUG]   org.sonatype.aether:aether-util:jar:1.7:compile
 [DEBUG]   org.codehaus.plexus:plexus-interpolation:jar:1.14:compile
 [DEBUG]   org.codehaus.plexus:plexus-utils:jar:2.0.4:compile
 [DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
 [DEBUG]   org.codehaus.plexus:plexus-component-annotations:jar:1.5.5:co=
 mpile
 [DEBUG]   org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
 [DEBUG]  org.sonatype.plexus:plexus-cipher:jar:1.4:compile
 [DEBUG] Created new class realm maven.api
 [DEBUG] Importing foreign packages into class realm maven.api
 [DEBUG]   Imported: org.apache.maven.wagon.events  plexus.core
 [DEBUG]   Imported: org.sonatype.aether.transfer  plexus.core
 [DEBUG]   Imported: org.apache.maven.exception  plexus.core
 [DEBUG]   Imported: org.sonatype.aether.metadata  plexus.core
 [DEBUG]   Imported: org.codehaus.plexus.util.xml.Xpp3Dom  plexus.core
 [DEBUG]   Imported: org.sonatype.aether.collection  plexus.core
 [DEBUG]   Imported: org.sonatype.aether.version  plexus.core
 [DEBUG]   Imported: org.apache.maven.monitor  plexus.core
 [DEBUG]   Imported: org.apache.maven.wagon.repository  plexus.core
 [DEBUG]   Imported: org.apache.maven.repository  plexus.core
 [DEBUG]   Imported: org.apache.maven.wagon.resource  plexus.core
 [DEBUG]   Imported: org.codehaus.plexus.logging  plexus.core
 [DEBUG]   Imported: 

Re: Java 8 update status

[Stuart McCulloch]

On 19 Dec 2013, at 08:08, Kristian Rosenvold kristian.rosenv...@zenior.no 
wrote:

 I figured we could use the wiki page to eventually document for end users
 which versions need to be used to solve known problems etc. While we're
 still fixing them and we're still ea it's probably a good place for just
 sharing knowledge, since general stuff will tend to get hidden in jira.
 jMNG-5551 is good for keeping tabs on what's actually known :)

Just wondering about the comment Current ASM-5 beta not usable” - in what way 
is it not usable and has it been reported upstream?

 Kristian
 
 2013/12/19 Kristian Rosenvold kristian.rosenv...@zenior.no
 
 I just created
 https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade to track
 the status of java 8 migration problems. This includes the bug number for
 the bugs.sun.com bug report I just filed yesterday that makes verifier
 break.
 
 Kristian


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

Re: Java 8 update status

[Stuart McCulloch]

On 19 Dec 2013, at 09:50, Kristian Rosenvold kristian.rosenv...@gmail.com 
wrote:

 That's me being imprecise based on something I picked off google; i changed
 the wiki.
 
 It would appear to me that the ASM based plugins are in for a decent bit of
 work (at least shade seems to be). Some of them are using fairly old
 versions of asm too, and I considered
 porting shade to 4.2 to minimize diff up to 5.0.  Do you know anything
 about the differences between asm 4.2 and 5.0 are significant in terms of
 api breakage ?

One of the key goals in ASM 4 was to improve backwards (binary) compatibility 
of releases going forwards:

http://asm.ow2.org/history.html

So far I’ve found ASM 5 beta to be a drop-in replacement for ASM 4 from a 
client perspective, so +1 on moving those plugins up to 4.2 to begin with.

( then people can always try out ASM 5 beta by adding it as a dependency to the 
plugin declaration in the pom.xml )

 Kristian
 
 2013/12/19 Stuart McCulloch mccu...@gmail.com
 
 On 19 Dec 2013, at 08:08, Kristian Rosenvold kristian.rosenv...@zenior.no
 wrote:
 
 I figured we could use the wiki page to eventually document for end users
 which versions need to be used to solve known problems etc. While we're
 still fixing them and we're still ea it's probably a good place for just
 sharing knowledge, since general stuff will tend to get hidden in jira.
 jMNG-5551 is good for keeping tabs on what's actually known :)
 
 Just wondering about the comment Current ASM-5 beta not usable” - in what
 way is it not usable and has it been reported upstream?
 
 Kristian
 
 2013/12/19 Kristian Rosenvold kristian.rosenv...@zenior.no
 
 I just created
 https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade to
 track
 the status of java 8 migration problems. This includes the bug number
 for
 the bugs.sun.com bug report I just filed yesterday that makes verifier
 break.
 
 Kristian
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 


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

Re: Install question for Maven 3.0 on PPC/10.4.11/ant 1.6.5

[Stuart McCulloch]

Try adding:

mkdir 
dir=bootstrap/target/classes/META-INF/maven/org.apache.maven/maven-core /

before the echo task on line 236

On 7 Nov 2013, at 13:27, Ed Mansky wrote:

 I saw the requirement for Ant 1.8 or later. The encoding option in the echo 
 task is new since Ant 1.7.
 
 To install ant 1.7, 1.8 or 1.8.4 requires JUnit to already be present.
 Unfortunately, to build JUnit you need maven in place.
 
 Hence my attempt to install/build maven.
 
 I found that I was able to build and install maven version 2.2.1 fine on 
 Tiger/ppc.
 
 Apparently there have been a lot of changes in the build.xml file between 
 2.2.1 and 3.x versions of maven.
 
 Now, typing mv install in the Junit folder results in Unable to build 
 project ...junit/pom.xml; it requires Maven version 3.0.4
 
 which is a different issue involving building junit 4 with maven 2.
 
 --Ed
 
 The README.bootstrap.txt from the source tree states the pre-requisites for 
 building the bootstrap code are:
 
  - Java 1.5
  - Ant 1.8 or later
 
 Whereas you're using Ant 1.6.5 - this is likely the problem, because 1.6.5 
 doesn't support the use of an encoding in the echo task (this is what 
 creates that particular pom.properties file)
 
 On 6 Nov 2013, at 14:36, Ed Mansky wrote:
 
 Hi all,
 
 I am trying to install Maven from source code on a PowerMac G4 PPC 7450 
 running 10.4.11 and with
 Java JDK 1.5 and Ant 1.6.5 installed.
 
 I am getting an error from line #236 of build.xml 
 (java.io.FileNotFoundException: ...full path to pom.properties file)
 
 Apparently the pom.properties file that is expected to be the bootstrap 
 area for that target (compile-boot) to run, is missing.
 
 The missing file pom.properties is indeed located in the source code tree 
 in:
 
 maven-core/src/test/resources/META-INF/maven/org.apache.maven/maven-core
 
 I am new to Maven, but it appears that an entry in 
 maven-core/src/main/mdo/toolchains.mdo for this file in META-INF is needed 
 in order to get it copied over to the bootstrap area during the building of 
 the target generate-sources.
 
 My environment variables are set as follows:
 
 JAVA_HOME = /Library/Java/Home
 ANT_HOME   = /Developer/Java/Ant
 M2_HOME = /usr/local/maven-3.0.4
 
 I also set M3_HOME = /usr/local/maven-3.0.4  in case that was needed 
 instead of M2_HOME
 
 I do not have CLASSPATH defined at all.
 
 What am I missing here to get Maven to build?  Any tips or hints would be 
 greatly appreciated!
 
 Thanks,
 
 --Ed
 --
 E. J. Mansky II
 Eikonal Research Institute
 Bend, Oregon
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -- 
 E. J. Mansky II
 Eikonal Research Institute
 Bend, Oregon
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 


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

Re: Install question for Maven 3.0 on PPC/10.4.11/ant 1.6.5

[Stuart McCulloch]

PS. note that JUnit is only required by the Ant tests, you can build a minimal 
distribution of Ant by removing the test-jar dependency from dist-lite and 
running:

ant dist-lite

Alternatively if you want to run the Ant unit tests for sanity checking, you 
can always build a basic JUnit4 distribution with Ant 1.6.5 (it still comes 
with a build.xml)

On 7 Nov 2013, at 14:22, Stuart McCulloch wrote:

 Try adding:
 
   mkdir 
 dir=bootstrap/target/classes/META-INF/maven/org.apache.maven/maven-core /
 
 before the echo task on line 236
 
 On 7 Nov 2013, at 13:27, Ed Mansky wrote:
 
 I saw the requirement for Ant 1.8 or later. The encoding option in the echo 
 task is new since Ant 1.7.
 
 To install ant 1.7, 1.8 or 1.8.4 requires JUnit to already be present.
 Unfortunately, to build JUnit you need maven in place.
 
 Hence my attempt to install/build maven.
 
 I found that I was able to build and install maven version 2.2.1 fine on 
 Tiger/ppc.
 
 Apparently there have been a lot of changes in the build.xml file between 
 2.2.1 and 3.x versions of maven.
 
 Now, typing mv install in the Junit folder results in Unable to build 
 project ...junit/pom.xml; it requires Maven version 3.0.4
 
 which is a different issue involving building junit 4 with maven 2.
 
 --Ed
 
 The README.bootstrap.txt from the source tree states the pre-requisites for 
 building the bootstrap code are:
 
 - Java 1.5
 - Ant 1.8 or later
 
 Whereas you're using Ant 1.6.5 - this is likely the problem, because 1.6.5 
 doesn't support the use of an encoding in the echo task (this is what 
 creates that particular pom.properties file)
 
 On 6 Nov 2013, at 14:36, Ed Mansky wrote:
 
 Hi all,
 
 I am trying to install Maven from source code on a PowerMac G4 PPC 7450 
 running 10.4.11 and with
 Java JDK 1.5 and Ant 1.6.5 installed.
 
 I am getting an error from line #236 of build.xml 
 (java.io.FileNotFoundException: ...full path to pom.properties file)
 
 Apparently the pom.properties file that is expected to be the bootstrap 
 area for that target (compile-boot) to run, is missing.
 
 The missing file pom.properties is indeed located in the source code 
 tree in:
 
 maven-core/src/test/resources/META-INF/maven/org.apache.maven/maven-core
 
 I am new to Maven, but it appears that an entry in 
 maven-core/src/main/mdo/toolchains.mdo for this file in META-INF is needed 
 in order to get it copied over to the bootstrap area during the building 
 of the target generate-sources.
 
 My environment variables are set as follows:
 
 JAVA_HOME = /Library/Java/Home
 ANT_HOME   = /Developer/Java/Ant
 M2_HOME = /usr/local/maven-3.0.4
 
 I also set M3_HOME = /usr/local/maven-3.0.4  in case that was needed 
 instead of M2_HOME
 
 I do not have CLASSPATH defined at all.
 
 What am I missing here to get Maven to build?  Any tips or hints would be 
 greatly appreciated!
 
 Thanks,
 
 --Ed
 --
 E. J. Mansky II
 Eikonal Research Institute
 Bend, Oregon
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -- 
 E. J. Mansky II
 Eikonal Research Institute
 Bend, Oregon
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 


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

Re: Install question for Maven 3.0 on PPC/10.4.11/ant 1.6.5

[Stuart McCulloch]

The README.bootstrap.txt from the source tree states the pre-requisites for 
building the bootstrap code are:

- Java 1.5
- Ant 1.8 or later

Whereas you're using Ant 1.6.5 - this is likely the problem, because 1.6.5 
doesn't support the use of an encoding in the echo task (this is what creates 
that particular pom.properties file)

On 6 Nov 2013, at 14:36, Ed Mansky wrote:

 Hi all,
 
 I am trying to install Maven from source code on a PowerMac G4 PPC 7450 
 running 10.4.11 and with
 Java JDK 1.5 and Ant 1.6.5 installed.
 
 I am getting an error from line #236 of build.xml 
 (java.io.FileNotFoundException: ...full path to pom.properties file)
 
 Apparently the pom.properties file that is expected to be the bootstrap area 
 for that target (compile-boot) to run, is missing.
 
 The missing file pom.properties is indeed located in the source code tree 
 in:
 
 maven-core/src/test/resources/META-INF/maven/org.apache.maven/maven-core
 
 I am new to Maven, but it appears that an entry in 
 maven-core/src/main/mdo/toolchains.mdo for this file in META-INF is needed in 
 order to get it copied over to the bootstrap area during the building of the 
 target generate-sources.
 
 My environment variables are set as follows:
 
 JAVA_HOME = /Library/Java/Home
 ANT_HOME   = /Developer/Java/Ant
 M2_HOME = /usr/local/maven-3.0.4
 
 I also set M3_HOME = /usr/local/maven-3.0.4  in case that was needed instead 
 of M2_HOME
 
 I do not have CLASSPATH defined at all.
 
 What am I missing here to get Maven to build?  Any tips or hints would be 
 greatly appreciated!
 
 Thanks,
 
 --Ed
 -- 
 E. J. Mansky II
 Eikonal Research Institute
 Bend, Oregon
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 


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

Re: Stupid Question about plugin annotations

[Stuart McCulloch]

IIRC those Java5 annotations are only used by the maven-plugin-plugin to 
generate META-INF/maven/plugin.xml and are not used by the core Maven runtime, 
in which case a retention policy of CLASS is ok:

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

The main benefit of using them is that if you extend a Maven plugin then the 
maven-plugin-plugin can see the Java5 annotations retained in the class file, 
whereas javadoc annotations are only in the source.

See http://jira.codehaus.org/browse/MPLUGIN-56 for the original use-case.

On 20 Sep 2013, at 19:34, Martin Gainty wrote:

 looks like we need to hire you to check our code..(provided you work for free)
 
 package org.apache.maven.plugins.annotations;
 
 import java.lang.annotation.RetentionPolicy;
 
 @Documented
 @Retention( RetentionPolicy.CLASS )
 @Target( { ElementType.FIELD } )
 @Inherited
 public @interface Parameter
 
 RetentionPolicy parameters:
 CLASS
 Annotations are to be recorded in the class file by the compiler
 but need NOT be retained by the VM at run time.
 
 
 
 RUNTIME
 Annotations are to be recorded in the class file by the compiler and
 RETAINED by the VM at run time, so they may be read reflectively.
 
 
 
 SOURCE
 Annotations are to be discarded by the compiler. 
 https://jira.codehaus.org/browse/MNG-5520
 
 thanks Robert!
 Martin 
 __ 
 
 
 
 Date: Fri, 20 Sep 2013 00:42:59 -0700
 From: robert.patr...@oracle.com
 To: dev@maven.apache.org
 Subject: RE: Stupid Question about plugin annotations
 
 Thanks.  http://jira.codehaus.org/browse/MNG-5518 submitted with test case.
 
 
 --
 Robert Patrick robert.patr...@oracle.com
 VP, FMW Architects Team: The A-Team  
 Oracle Corporation   Office: +1.940.725.0011
 1148 Triple Crown Court  Fax: +1.940.725.0012
 Bartonville, TX 76226, USA   Mobile: +1.469.556.9450
 
 A-Team Chronicles Blog: http://www.ateam-oracle.com/  
 
 Professional Oracle WebLogic Server
 by Robert Patrick, Gregory Nyberg, and Philip Aston
 with Josh Bregman and Paul Done
 Book Home Page: http://www.wrox.com/
 Kindle Version: http://www.amazon.com/
 
 
 -Original Message-
 From: Anders Hammar [mailto:and...@hammar.net] 
 Sent: Friday, September 20, 2013 2:20 AM
 To: Maven Developers List
 Subject: Re: Stupid Question about plugin annotations
 
 Actually, he needs to sign up on Codehaus Xircles.
 
 /Anders
 
 
 On Fri, Sep 20, 2013 at 9:06 AM, Lennart Jörelid
 lennart.jore...@gmail.comwrote:
 
 You can sign up for a JIRA account on the JIRA welcome page.
 
 You can find the respective JIRAs on
 http://maven.apache.org/issue-tracking.html
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 


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