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 Cs

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 ba

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

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 Ma

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

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 dupli

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

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 inte

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 

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
>

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

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
> 

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) @
> &

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&search=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&page=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
> > >> >
> > >>
> >
> com.google.inject.internal.InternalInjectorCreator.initializeStat

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  (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 annotation.
&

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)>:
> > >  
> > > > Changing the package would not be possible in 3.x.
> > >  
> > 

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  (mailto:rfscho...@apache.org)> wrote:
> > Cool
> >  
> >  
> > On Wed, 30 Aug 2017 23:22:14 +0200, Stephen Connolly 
> > 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  > > (mailto:rfscho...@apache.org)> wrote:
> > >  
> > > > But can you access classes via the ServiceLoader?
> > > >  
> > > > On Wed, 30 Aug 2017 22:48:40 +0200, Stephen Connolly
> > > >  > > > (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  > > > > (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 
> > > > >>> (mailto:stephen.alan.conno...@gmail.com)> wrote:
> > > > >>>
> > > > >>> H

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)
> > > > > > at com.google.inject.internal.InjectorImpl.callI

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(
> > MojoExecutor.java:208)
> > 
> > at
> > or

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

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 1

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&node=5898384&i=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 

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&node=5898384&i=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&node=5898384&i=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
> > > > >  
> > > > >  
> > > > > ---

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&id=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&breadcrumbs=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 

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 a/maven-core/src/main/java/org/apache/maven/repository/
DelegatingLoc

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_

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


  true
   

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&search=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&search=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&version=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]

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]

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  
> mailto:rory.odonn...@oracle.com)>:
>  
> >  
> > 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 existing libraries and applicati

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

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  
> mailto:rfscho...@apache.org)>:
>  
> > 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  
> > mailto:ol...@apache.org)>:
> >  
> > > 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:
> > >  
> > > >  
> > > > https://github.com/codehaus-plexus/plexus-compiler/blob/

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 (http://web.asm.Cla

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

Re: libs in mavens /lib folder

[Stuart McCulloch]

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  | Blog
>  | Github  |
> LinkedIn  | Tomitriber
> 
> 
> 2015-03-05 16:01 GMT+01:00 Jason van Zyl  (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  > (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 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
> > > 
> > > 
> > > 41123 7. Mai 20

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]

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  (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 @@
> >  
> > 
> > 
> > + org.codehaus.plexus
> > + plexus-container-default
> > + test
> > + 
> > + 
> > org.apache.maven.archetype
> > archetype-catalog
> > 
> >  
> >  
> >  
> > 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"  > > (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/

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 @@
  
   
 
+  org.codehaus.plexus
+  plexus-container-default
+  test
+
+
   org.apache.maven.archetype
   archetype-catalog
 



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"  (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  > > (mailto:bimargul...@gmail.com)
> > (mailto:bimargul...@gmail.com)> wrote:
> > > > What I see is:
> > > >  
> > > >

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  (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: 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  (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"  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 ...

Previous releases of toolchain were less strict about this - if you wrap
the vendor inside ... 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
plugin>org.apache.maven.plugins:maven-toolchains-plugin:1.0
> [DEBUG] Importing foreign packages into class realm
plugin>org.apache.maven.plugins:maven-toolchains-plugin:1.0
> [DEBUG]   Imported:  < project>toolchains:toolchains:0.0.1-SNAPSHOT
> [DEBUG] Populating class realm
plugin>org.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]   Exclud

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"  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" > <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: 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"  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: 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"  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"  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]

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


  org.apache.maven.plugin.projectinfo.tests
  dependency-convergence
  1.0-SNAPSHOT
  

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:

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

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]

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  (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  > > (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  > > > (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: 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  (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  > (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]

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: 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 List 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  (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  elements, hard
> > otherwise - maybe with hardlinks in the file system).
> > 
> > 
> > Kristian
> > 
> > 
> > 
> > 2014-10-30 13:10 GMT+01:00 Dawid Weiss  > (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  > > (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...@mav

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 =
> plugin>com.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/g

Re: Maven wagon-http Issue

[Stuart McCulloch]

On 25 Sep 2014, at 03:34, Igor Fedorenko  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  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 
 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
>>  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:
>>> 
>>>   
>>> io.takari.aether
>>> aether-connector-okhttp
>>> 0.13.1
>>>   
>>> 
>>> 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.()
>>> is
>>> 
>>> not @Nullable
>>> [ERROR] while locating javax.net.ssl.SSLSocketFactory
>>> [ERROR] for parameter 1 at
>>> io.takari.aether.connector.AetherRepositoryConnectorFactory.(Unknown
>>> 
>>> 
>>

Re: Problem while getting injected parameters from plugin configuration.

[Stuart McCulloch]

On 22 Sep 2014, at 23:34, animator  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):


org.codehaus.plexus
plexus-component-metadata
1.5.5



generate-metadata





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: Problem while getting injected parameters from plugin configuration.

[Stuart McCulloch]

On 21 Sep 2014, at 22:54, animator  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: Analysis of apache-maven-3.2.3's dependency on JDK-Internal APIs

[Stuart McCulloch]

Just to clarify, Sisu has _never_ used any Guava APIs directly, the use of 
Guava comes from its use of Guice.

In Guice 3.0 Guava was shaded in under an internal package, since then Guava is 
now an external dependency:


https://github.com/google/guice/commit/3236b100a95b739577dfcd117c24615370a1d0af

Guice also moved from using the makeComputingMap method (removed in Guava 15.0) 
to the CacheBuilder API (first introduced in Guava 10.0):


https://github.com/google/guice/commit/8743a0bb0fb49f30117c846880a7df2e7b36657e

This is why upgrading the version of Guice (specifically the frequent-release 
build used by Maven) was recommended if you wanted to use a more recent version 
of Guava (independent of any reasons to upgrade Sisu).

Regarding the use of ‘sun.misc.Unsafe’ in Guava, looking at the code I believe 
this comes from the Striped64 class which is used by Cache statistics. This 
code was changed in Guava 14.0 to fall back to the public API if 
‘sun.misc.Unsafe’ was unavailable:

https://code.google.com/p/guava-libraries/issues/detail?id=1228

https://code.google.com/p/guava-libraries/source/detail?r=d6da7d86a2cab91bb3d33d983ccf5b07de14cc20

Hope that helps.

—
Cheers, Stuart

On 15 Sep 2014, at 12:24, Igor Fedorenko  wrote:

> We can move to the newer version of guava. This was one of the reasons I
> updated to the latest sisu, I was told it did not depend on any internal
> guava apis any more. Of course, somebody will have to check what guava
> version is compatible with JDK 9 before we upgrade.
> 
> --
> Regards,
> Igor
> 
> On 2014-09-15, 7:15, Kristian Rosenvold wrote:
>> So if I read your report correctly, our code uses guava, which
>> contains references to sun.misc.Unsafe. Actually it's sisu that uses
>> guava, not maven core itself.
>> 
>> Not too much we can do about that, other than consider throwing guava
>> out of sisu. As long as we're on a sub-1.8 minimum language level I
>> assume guava stays in sisu.
>> 
>> So "these are not the droids you're looking for" :)
>> 
>> Kristian
>> 
>> 
>> 
>> 
>> 2014-09-15 12:17 GMT+02:00 Rory O'Donnell Oracle, Dublin Ireland
>> :
>>> Hi Stephen,
>>> 
>>> One more time, hope this is ok.
>>> 
>>> Rgds,Rory
>>> 
>>> 
>>>  JDK Internal API Usage Report for apache-maven-3.2.3
>>> 
>>> The OpenJDK Quality Outreach campaign has run a compatibility report to
>>> identify usage of JDK-internal APIs. Usage of these JDK-internal APIs could
>>> pose compatibility issues, as the Java team explained in 1996
>>> . We
>>> have created this report to help you identify which JDK-internal APIs your
>>> project uses, what to use instead, and where those changes should go. Making
>>> these changes will improve your compatibility, and in some cases give better
>>> performance.
>>> 
>>> Migrating away from the JDK-internal APIs now will give your team adequate
>>> time for testing before the release of JDK 9. If you are unable to migrate
>>> away from an internal API, please provide us with an explanation below to
>>> help us understand it better. As a reminder, supported APIs are determined
>>> by the OpenJDK's Java Community Process and not by Oracle.
>>> 
>>> This report was generated by jdeps
>>> 
>>> through static analysis of artifacts: it does not identify any usage of
>>> those APIs through reflection or dynamic bytecode. You may also run jdeps on
>>> your own
>>> 
>>> if you would prefer.
>>> 
>>> Summary of the analysis of the jar files within apache-maven-3.2.3:
>>> 
>>>  * Numer of jar files depending on JDK-internal APIs: 1
>>>  * Internal APIs that have known replacements: 0
>>>  * Internal APIs that your team should migrate away: 1
>>> 
>>> 
>>>  APIs that have known replacements
>>> 
>>> :
>>> 
>>> ID  Replace Usage ofWithInside
>>> 
>>> 
>>>  JDK-internal APIs without supported replacements:
>>> 
>>> ID  Internal APIs (do not use)  Used by
>>> 1   sun.misc.Unsafe
>>> 
>>>  * lib/guava-14.0.1.jar
>>> 
>>> Explanation...
>>> 
>>> 
>>>  Identify External Replacements
>>> 
>>> You should use a separate third-party library that performs this
>>> functionality.
>>> 
>>> ID  Internal API (grouped by package)   Used By Identify
>>> External Replacement
>>> 
>>> 
>>> On 15/09/2014 10:22, Stephen Connolly wrote:
 
 I think the mailing list stripped the attachment
 
 On Monday, 15 September 2014, Rory O'Donnell Oracle, Dublin Ireland <
 rory.odonn...@oracle.com> wrote:
 
> Hi Robert,Kristian,
> 
> As part of the preparations for JDK 9, Oracle's engineers have been
> analyzing open source projects like yours to understand usage.
> One area of concern invo

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

> Both MNG-5633  and 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  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: Maven Issue - pluginManagement - build Area Plugin

[Stuart McCulloch]

On 14 Feb 2014, at 08:09, Baptiste Mathus  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 :
> 
>> 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 >>> wrote:
>>> 
>>> Hi,
 i have a question. The following situation. Pom file which uses the
 following parent:
 
 
 org.codehaus
 codehaus-parent
 4
 
 
 
   ${mavenVersion}
 
 
 and the following part in my pom file:
 
 
 
 
 
 org.apache.maven.plugins
 maven-enforcer-plugin
 1.3.1
 
 
 
 
 
   org.apache.maven.plugins
   maven-enforcer-plugin
   
 
   enforce-maven
   
   ... 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:
 
 
 
 
 org.apache.maven.plugins
 maven-enforcer-plugin
 1.0
 
 
 enforce-maven
 
 enforce
 
 
 
 
 
 (,2.1.0),(2.1.0,2.2.0),(2.2.0,)
 Maven 2.1.0 and 2.2.0
 produce
 incorrect GPG signatures and checksums respectively.
 
 
 
 
 
 
 
 
 
 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:
 
 
 
   org.apache.maven.plugins
   maven-enforcer-plugin
   1.3.1
   
 
 
 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
>> Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
>> Hauptstrasse 177   

Re: releasing 3.2.1

[Stuart McCulloch]

On 14 Feb 2014, at 04:39, Jason van Zyl  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: Linkage error

[Stuart McCulloch]

On 13 Feb 2014, at 17:08, Kristian Rosenvold  
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 :
> 
>> 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  wrote:
>>> 
>>> On 13 Feb 2014, at 13:30, Jason van Zyl  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  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 p

Re: Linkage error

[Stuart McCulloch]

On 13 Feb 2014, at 14:43, Jason van Zyl  wrote:
> On Feb 13, 2014, at 8:44 AM, Stuart McCulloch  wrote:
> 
>> On 13 Feb 2014, at 13:30, Jason van Zyl  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  wrote:
>>> 
>>>> On 13 Feb 2014, at 07:28, Kristian Rosenvold 
>>>>  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 

Re: Linkage error

[Stuart McCulloch]

On 13 Feb 2014, at 13:30, Jason van Zyl  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  wrote:
> 
>> On 13 Feb 2014, at 07:28, Kristian Rosenvold  
>> 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 07:28, Kristian Rosenvold  
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: [VOTE][CANCELLED] Release Maven 3.2.0

[Stuart McCulloch]

On 11 February 2014 23:26, Dan Tran  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 
> wrote:
>
> > On 11 February 2014 22:15, Olivier Lamy  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 

Re: [VOTE][CANCELLED] Release Maven 3.2.0

[Stuart McCulloch]

On 11 February 2014 22:15, Olivier Lamy  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  wrote:
> > Couple issues cropped up so I'm canceling the vote.
> >
> > On Feb 10, 2014, at 9:18 PM, Jason van Zyl  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=10500&version=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: Problem with transitive Guava dep

[Stuart McCulloch]

On 24 Jan 2014, at 23:49, Igor Fedorenko  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.(DependencyAnalyzer.java:92)
>>  at org.eclipse.sisu.wire.ElementAnalyzer.(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.(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  
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  
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  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]   Impo

Re: Java 8 update status

[Stuart McCulloch]

On 19 Dec 2013, at 09:50, Kristian Rosenvold  
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 
> 
>> On 19 Dec 2013, at 08:08, Kristian Rosenvold 
>> 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 
>>> 
>>>> 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: Java 8 update status

[Stuart McCulloch]

On 19 Dec 2013, at 08:08, Kristian Rosenvold  
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 
> 
>> 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: 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:
> 
>dir="bootstrap/target/classes/META-INF/maven/org.apache.maven/maven-core" />
> 
> before the  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]

Try adding:



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