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
nibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
mannibucau.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 2
> <http://rmannibucau.wordpress.com> | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > <
> > > > > >
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
> >
>
> Ye
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
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
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
]
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.
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
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
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
nly
> 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
gt; 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 quic
mponent? 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.
> > >
> > >
> > >
> > >
>
t
> 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
gt; 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 t
ow 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:
> >
> >
r
> 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 verif
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
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
> &
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
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
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
On Tuesday, 6 February 2018 at 13:25, Romain Manni-Bucau wrote:
> 2018-02-06 12:25 GMT+01:00 Stuart McCulloch <mccu...@gmail.com
> (mailto:mccu...@gmail.com)>:
>
> > The "javax.enterprise.inject" CDI package was explicitly exported as part
> > of the on
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
;>
> > > > >>>
> > > > >>> On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
> > > > >>> stephen.alan.conno...@gmail.com
> > > > >>> (mailto:stephen.alan.conno...@gmail.com)> wrote:
> > > > >>>
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,
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]
ode 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 ForkedLaunche
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.loc
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” direc
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 point
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
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"
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
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
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
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
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 (644ac9c40ad41bf61e3b099918af33b8eb950
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
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
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
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
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
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
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
-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-integrati
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
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 mod
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
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
-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
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
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
://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com
2015-03-05 16:20 GMT+01:00 Stuart McCulloch mccu...@gmail.com
(mailto:mccu...@gmail.com):
I believe that was fixed in https://jira.codehaus.org
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
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)
archetype use non-antique plexus.
On Feb 20, 2015 7:46 AM, Stuart McCulloch mccu...@gmail.com
(mailto:mccu...@gmail.com) wrote:
If I get time I can try to debug it this weekend - looking at the line
numbers in the stack trace, the hang is happening inside the old container
I would, but I’m not a committer here ;)
On Friday, 20 February 2015 at 13:15, Benson Margulies wrote:
I like your fix better than my fix, please feel free to commit the switch.
On Fri, Feb 20, 2015 at 8:14 AM, Stuart McCulloch mccu...@gmail.com
(mailto:mccu...@gmail.com) wrote:
FYI
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
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
On 16 Dec 2014 10:45, Sievers, Jan jan.siev...@sap.com wrote:
I ran all Tycho ITs using the staged version.
I still see one error related to toolchains.
The IT is using the toolchains.xml attached and fails the build with
error below.
Not sure if that's a regression in toolchains or our test
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
, 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
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
Just noticed that's http (the http site links to the http signup page, even
though https is available for signup)
This link is better: https://xircles.codehaus.org/signup
On 3 Dec 2014 10:42, Stuart McCulloch mccu...@gmail.com wrote:
FYI you can sign up for a Codehaus account at
http
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
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
by ...
On Fri, Nov 7, 2014 at 12:06 PM, Stuart McCulloch mccu...@gmail.com
(mailto:mccu...@gmail.com) wrote:
AFAIK none of the Guava packages are exposed from maven core, so I’d be
interested to know more about where these types are leaking and how to
recreate
wanted to use newer guava
versions in my plugins.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Fri, Nov 7, 2014 at 6:51 PM, Stuart McCulloch mccu...@gmail.com
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
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
On 25 Sep 2014, at 03:34, Igor Fedorenko i...@ifedorenko.com wrote:
No, you are not missing anything. We don't usually use the connector as
build extension and there appear some sisu/guice related bugs that
result in the exception you see.
I took a quick look and it’s not actually a bug in
On 21 Sep 2014, at 22:54, animator l.gadaw...@gmail.com wrote:
Thanks for answers!
I removed reporting section and unfortunately it doesn't work.. (*1)(btw.
before that I added reporting api and declared InstrumentMojo extends
AbstractMavenReport but this doesn't work too).
I suppose
On 22 Sep 2014, at 23:34, animator l.gadaw...@gmail.com wrote:
The main problem from the topic finally I managed to resolve. The problem was
wrong configuration in test-polyglot-project, the groupId of declared plugin
in pom was wrong and when the goal was executed it was used plugin from
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
On 2 Jul 2014, at 07:18, Michael Osipov micha...@apache.org wrote:
Am 2014-07-01 12:59, schrieb Michal Srb:
Hello,
I filed a bug [1] and opened pull request [2] for maven-javadoc-plugin.
Please see links below for context. The real problem seems to be in
javadoc tool, but it can be avoided
Looks like they’re both linked as duplicates of
http://jira.codehaus.org/browse/MNG-5637 - should that issue be marked as fixed
in 3.2.2?
On 23 May 2014, at 19:24, Paul Benedict pbened...@apache.org wrote:
Both MNG-5633 http://jira.codehaus.org/browse/MNG-5633 and MNG-5628
On 23 Feb 2014, at 00:08, Martin Gainty mgai...@hotmail.com wrote:
I *think* the sonatype folk went home for weekend so I'll ask maven gurus
Odd assumption, why didn’t you at least try asking this question on nexus-user
or nexus-dev?
Close to getting a plugin working but when i start
On 14 Feb 2014, at 04:39, Jason van Zyl ja...@takari.io wrote:
Ok, everything is in. Just running through my normal set of tests and I'll
try to get 3.2.1 staged later tonight or in the morning.
Does that include a fix for the issue Mark found building the dependency graph?
On 14 Feb 2014, at 08:09, Baptiste Mathus m...@batmat.net wrote:
Seems like this super pom is versioned at github under the sonatype
organization (?).
Cf. scm tag in
http://repo1.maven.org/maven2/org/codehaus/codehaus-parent/4/codehaus-parent-4.pom
But
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
consider CDI’s @Typed part of
the component API like JSR330’s @Inject.
The CDI API is at least standardised (one of the reasons why the container
respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t
be as portable).
On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu
On 13 Feb 2014, at 14:43, Jason van Zyl ja...@takari.io wrote:
On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote:
On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote:
I would consider something like SFL4J as something which is now part of our
API think it's
annotation in one of my (private) core extensions where I
need a class to implement an interface but not make that interface
visible for injection in other components.
--
Regards,
Igor
On 2/13/2014, 9:43, Jason van Zyl wrote:
On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com
On 11 February 2014 22:15, Olivier Lamy ol...@apache.org wrote:
Noticed this non blocking issue when using activemq plugin to start an
activemq instance:
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 17.840s
)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
... 1 more
On Tue, Feb 11, 2014 at 3:20 PM, Stuart McCulloch mccu...@gmail.com
wrote:
On 11 February 2014 22:15, Olivier Lamy ol...@apache.org wrote:
Noticed this non blocking issue when using activemq plugin to start
On 24 Jan 2014, at 23:49, Igor Fedorenko i...@ifedorenko.com wrote:
This problem is specific to maven-plugin-testing-harness. You can use
any version of Guava at runtime, but test classpath is flat so you need
to use single Guava version that is compatible with all components.
On 8 Jan 2014, at 20:03, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:
With spring, you can say:
@Component
class X implements Y,Z
And at call site:
@Inject
private Y y;
@Inject
private Z z;
And expect (scope dependent) to get the same instance of X in both y and z.
On 7 Jan 2014, at 15:39, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
* http://jira.codehaus.org/browse/MNG-4171 The XML resulting from a property
of java.util.Properties is a lot more clumsy than that for Map
Unsure what the ask is here... seems like it's really a plexus
On 31 Dec 2013, at 12:51, Martin Gainty mgai...@hotmail.com wrote:
--_d7af7d72-ddaf-4bb4-8989-06a73d80616e_
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
[DEBUG] test:lifecycle-phases-plugin:jar:1.0:
[DEBUG]
On 19 Dec 2013, at 08:08, Kristian Rosenvold kristian.rosenv...@zenior.no
wrote:
I figured we could use the wiki page to eventually document for end users
which versions need to be used to solve known problems etc. While we're
still fixing them and we're still ea it's probably a good place
to the
plugin declaration in the pom.xml )
Kristian
2013/12/19 Stuart McCulloch mccu...@gmail.com
On 19 Dec 2013, at 08:08, Kristian Rosenvold kristian.rosenv...@zenior.no
wrote:
I figured we could use the wiki page to eventually document for end users
which versions need to be used
Try adding:
mkdir
dir=bootstrap/target/classes/META-INF/maven/org.apache.maven/maven-core /
before the echo task on line 236
On 7 Nov 2013, at 13:27, Ed Mansky wrote:
I saw the requirement for Ant 1.8 or later. The encoding option in the echo
task is new since Ant 1.7.
To
distribution with Ant 1.6.5 (it still comes
with a build.xml)
On 7 Nov 2013, at 14:22, Stuart McCulloch wrote:
Try adding:
mkdir
dir=bootstrap/target/classes/META-INF/maven/org.apache.maven/maven-core /
before the echo task on line 236
On 7 Nov 2013, at 13:27, Ed Mansky wrote
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
IIRC those Java5 annotations are only used by the maven-plugin-plugin to
generate META-INF/maven/plugin.xml and are not used by the core Maven runtime,
in which case a retention policy of CLASS is ok:
http://svn.apache.org/viewvc?view=revisionrevision=1338003
The main benefit of using
1 - 100 of 203 matches
Mail list logo
