Re: [PR] Bump org.apache.maven.extensions:maven-extensions from 42 to 43 [maven-xinclude-extension]

slachiewicz merged PR #2: URL: https://github.com/apache/maven-xinclude-extension/pull/2 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...

[PR] Bump org.apache.maven.extensions:maven-extensions from 42 to 43 [maven-xinclude-extension]

dependabot[bot] opened a new pull request, #2: URL: https://github.com/apache/maven-xinclude-extension/pull/2 Bumps [org.apache.maven.extensions:maven-extensions](https://github.com/apache/maven-parent) from 42 to 43. Release notes Sourced from https://github.com/apache/maven

[DISCUSS][MSC] "How to write extensions" documentation

Hi all, as already mentioned, I will create a mail thread for each epic that we defined for the “Support & Care for Apache Maven” initiative (https://open-elements.com/support-care-maven/). All information about this specific epic can be found at https://github.com/OpenElements/maven-support-c

Re: Do we plan to support extensions with java 17?

Hmm, technically you can use most of guice without asm and replace its visitors by reflection/meta read and proxying by build time generation in the custom annot proc. Not saying it is one liner but it would be what sounds more long term to me...we can also drop guice for v4/v5 since we dont expos

Re: Do we plan to support extensions with java 17?

Howdy, Plexus-shim is built on top of Sisu, and Sisu is built on top of Guice. Maven is tied to plexus-shim very much. Guice shades ASM as well (current version 5.1.0 has support for Java17: https://github.com/google/guice/wiki/Guice510 ) Hence, our stack is pretty much tied to Guice. I hope Gui

Re: Do we plan to support extensions with java 17?

Again: cause the PR which is not merged is already not sufficient for the LTS of september. Asm version is a running forward game and technically we don't need it _there_ so if we can make it effortless I think it could only have a positive impact on the project. Concretely the 9.4 (the PR) does no

Re: Do we plan to support extensions with java 17?

Howdy, Why again? There is ongoing effort (master is already updated), but also to raise whole Java level of Sisu, see https://github.com/eclipse/sisu.inject/pull/72 Hopefully soon new sisu release will happen that will contain updated ASM and allow using Java11+ bytecode. Thanks T On Tue, Jan

Do we plan to support extensions with java 17?

Hi all, We are hit again by sisu asm, we cant write a component using sisu Named SPI if compiled with java 17 (since then it will be visited with a too old asm - exception at the end), do we want to upgrade asm there, do we want to plan drop it - guess we can using the annot processor to collect m

Re: Maven 4.0: Migration path for plugins and extensions?

to break existing > > > plugins. > > > > Could you be more specific about the exact breaking changes ? > > > > > > > > Le mar. 4 oct. 2022 à 12:42, Marc Philipp a écrit : > > > > > > > > Hi everyone, > > > > > > > > >

Re: Maven 4.0: Migration path for plugins and extensions?

t > > > > > > snapshots. After the merge of https://github.com/apache/maven/pull/703 > > our > > > > > > tests started failing because of breaking API changes. I see there are > > PRs > > > > > > to core Maven plugins link

Re: Maven 4.0: Migration path for plugins and extensions?

> PRs > > > > to core Maven plugins linked from there. If I understood it correctly, > this > > > > change will break all/most existing Maven plugins. > > > > > > Maven 4.0 is a major new version and as such is obviously allowed to make > > > > b

Re: Maven 4.0: Migration path for plugins and extensions?

allowed to make > > breaking changes to its API. However, I was wondering if there’s any > > guidance or a migration path for (third-party) Maven plugins and > > extensions? Is the idea that they’ll also have to publish new major > > versions that are compatible with 4.x? If

Re: Maven 4.0: Migration path for plugins and extensions?

t; Maven 4.0 is a major new version and as such is obviously allowed to make > breaking changes to its API. However, I was wondering if there’s any > guidance or a migration path for (third-party) Maven plugins and > extensions? Is the idea that they’ll also have to publish new major > ve

Re: Maven 4.0: Migration path for plugins and extensions?

ing Maven plugins. > > > > > > Maven 4.0 is a major new version and as such is obviously allowed to > make > > > breaking changes to its API. However, I was wondering if there’s any > > > guidance or a migration path for (third-party) Maven plugins and > &

Re: Maven 4.0: Migration path for plugins and extensions?

ll/most existing Maven plugins. > > > > Maven 4.0 is a major new version and as such is obviously allowed to make > > breaking changes to its API. However, I was wondering if there’s any > > guidance or a migration path for (third-party) Maven plugins and > > extensions?

Re: Maven 4.0: Migration path for plugins and extensions?

all/most existing Maven plugins. > > Maven 4.0 is a major new version and as such is obviously allowed to make > breaking changes to its API. However, I was wondering if there’s any > guidance or a migration path for (third-party) Maven plugins and > extensions? Is the idea that they’ll also

Maven 4.0: Migration path for plugins and extensions?

correctly, this change will break all/most existing Maven plugins. Maven 4.0 is a major new version and as such is obviously allowed to make breaking changes to its API. However, I was wondering if there’s any guidance or a migration path for (third-party) Maven plugins and extensions? Is the idea that

[GitHub] [maven-site] olamy merged pull request #271: Update "Maven/ Available Extensions", add OpenTelemetry Maven Extension

olamy merged pull request #271: URL: https://github.com/apache/maven-site/pull/271 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...

[GitHub] [maven-site] olamy merged pull request #271: Update "Maven/ Available Extensions", add OpenTelemetry Maven Extension

olamy merged pull request #271: URL: https://github.com/apache/maven-site/pull/271 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...

[GitHub] [maven-site] cyrille-leclerc opened a new pull request #271: Update "Maven/ Available Extensions", add OpenTelemetry Maven Extension

cyrille-leclerc opened a new pull request #271: URL: https://github.com/apache/maven-site/pull/271 Update "[Maven/ Available Extensions](https://maven.apache.org/extensions/index.html)", add the [OpenTelemetry Maven Extension](https://github.com/open-telemetry/opentelemetry-ja

[GitHub] [maven-site] michael-o merged pull request #255: Update extensions index.md

michael-o merged pull request #255: URL: https://github.com/apache/maven-site/pull/255 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubsc

[GitHub] [maven-site] mbenson opened a new pull request #255: Update extensions index.md

mbenson opened a new pull request #255: URL: https://github.com/apache/maven-site/pull/255 Correct project URL -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscri

Re: Maven Assembly Plugin resolves extensions of dependencies -- is this intentional?

> > > > Here is an example project: > > https://github.com/cstamas/mvn-md-bug > > > > Just add new dependency in POM, jackson for example that uses extensions > in > > it's own build (copy paste into POM): > > > > > > com.fasterxml.jackson

Re: Maven Assembly Plugin resolves extensions of dependencies -- is this intentional?

despite not using it. > > > > So, what and why is maven-assembly-plugin doing this? > > > > === > > > > Here is an example project: > > https://github.com/cstamas/mvn-md-bug > > > > Just add new dependency in POM, jackson for example that uses extensions >

Re: Maven Assembly Plugin resolves extensions of dependencies -- is this intentional?

gin, that > maven 3.6.3 resolves at one moment in my build, despite not using it. > > So, what and why is maven-assembly-plugin doing this? > > === > > Here is an example project: > https://github.com/cstamas/mvn-md-bug > > Just add new dependency in POM, jackson for example

Maven Assembly Plugin resolves extensions of dependencies -- is this intentional?

, what and why is maven-assembly-plugin doing this? === Here is an example project: https://github.com/cstamas/mvn-md-bug Just add new dependency in POM, jackson for example that uses extensions in it's own build (copy paste into POM): com.fasterxml.jackson.core jackson-dat

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

Guess we can do something like that or more js like http://tomee.apache.org/developer/classloading/index.html but specific to maven, mojo classloading is almost obvious but core and extension ones are not IMHO. Then we can just mention that for the IoC + it uses Guice with a custom registration imp

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

OK, my bad, I thought we were talking about Maven's internals for itself. Classloader trees, hidden implementations, security policies for the JVM are stand out features that they nailed in 1995/6/7. I once drew a pretty pic of Tomcat's classloader setup - https://paulhammant.com/images/tomcat_cl

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

@Paul: not really, none define any behavior (note that the class loader tree implementation is a vendor choice, several certified EE servers do handle singleton per tree or per loader of the tree and it is compliant). Only @inject tests are https://github.com/eclipse-ee4j/injection-tck/blob/2ef97bf

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

> > JSR 330 has a TCK that defines a lot. A system that purports to facilitate > injection into contained components (plugins or lesser) doesn’t have to > implement all facets of that TCK but could do so out of the box by just > using (say) guice or dagger in a class loader tree implementation.

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

@Tamas, right but this page https://maven.apache.org/maven-jsr330.html does say the opposite for example, this is why I think we should create a ticket to revise the doc which is misleading as of today Romain Manni-Bucau @rmannibucau | Blog

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

When I read "jsr330" (in maven context), I always "replace it" with SISU in my head, as Maven is SISU powered. So there is nothing undefined for me, as SISU defines all the "blind spots" IMO. Maven, while it may look so, will NOT work with any other JSR330 implementation, just SISU. Maven 3 was ma

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

Issue with JSR330 is that it is a standard "nothing" since it does not define any behavior behind the annotations so it is pointless to have this standard since all the behavior is vendor dependent and therefore we must fix that by a good doc. Wonder if we should define more explicitly and not accr

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

CDI came after JSR330 I think. I was on the JSR330 experts group. I could be wrong there. Back history of dependency injection - it was an antidote to classic GoF service-locator being used everywhere in Javaland. When we co-created PicoContainer we were careful to avoid Singleton as a term or idi

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

In CDI there is a definition which sounds like "an instance is a singleton in its context", context being the bean lookup definition. In maven it means calling Guice for current ClassRealm (the classloader of currently executed component - plugin for ex) so it matches. Long story short "singleton"

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

Just add few cents to Stuart superb answer: the singleton scope depends on the "realm" (no idea how to call it better) where it is singleton, as the "lifespan" of realm may not be same/aligned. Core and Core Extension lifespan vs Mojo/Plugin lifespan is clearly not the same... Also, take a peek at

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

Thank you Stuart for the detailed reply. On Fri, Feb 5, 2021 at 12:02 AM Stuart McCulloch wrote: > 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 g

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

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

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

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

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

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

JSR330 in extensions and plugins, Singleton or not Singleton

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 prin

Re: Classloader hierarchy with extensions

I remember working with Stephen on this. I think the related issues were MNG-6209, MNG-6275 Stephen wrote a small integration test to show which extensions were visible to who and in which order. It showed there are some edge cases that didn't work as expected. However, I can't find th

Re: Classloader hierarchy with extensions

Have you seen [1]? Not sure how much Maven 3.x changed since I wrote that page, but multi-artifact extensions needed META-INF/maven/extension.xml descriptor to defined what artifacts are part of the extension and what are exported to the plugins. [1] http://takari.io/book/91-maven

Classloader hierarchy with extensions

Folks, hopefully someone of you is able to make me understand the following: Maven 3 class loading [1] says that extensions are available to plugins. E.g., Wagon FTP should be available to Maven Deploy Plugin oder Wagon Maven Plugin. While working on MNG-6965 I came across this MNG-4381

Revisiting MNG-6209 (inconsistent activation of components from multiple extensions=true plugins) revisited

This was the issue reverted after 3.5.1, which should deserve a revisit. Stephen created a sample project[1] to show the effects when working with extensions I've created a matrix[2] with the changes of behavior between 3.5.0 and 3.5.1 There's also documentation about th

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

needs >> > an update methinks. If only Apache had a wiki :-P >> >> >> cwiki.apache.org has a Maven space >> >> >> > >> > - Paul >> > >> > On Thu, Jun 1, 2017 at 9:22 AM, Paul Hammant wrote: >> > >> > > OK, than

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

s/maven-3-lifecycle-extensions.html > needs > > an update methinks. If only Apache had a wiki :-P > > > cwiki.apache.org has a Maven space > > > > > > - Paul > > > > On Thu, Jun 1, 2017 at 9:22 AM, Paul Hammant wrote: > > > > > OK, thanks. >

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

, 2017 at 9:22 AM, Paul Hammant wrote: > > > OK, thanks. > > > > I'll kill the /build/extensions element of the pom, and try > > .mvn/extensions.xml > > > > - Paul > > > > On Thu, Jun 1, 2017 at 7:26 AM, Igor Fedorenko > > wrote: > > &g

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

aster https://maven.apache.org/examples/maven-3-lifecycle-extensions.html needs an update methinks. If only Apache had a wiki :-P - Paul On Thu, Jun 1, 2017 at 9:22 AM, Paul Hammant wrote: > OK, thanks. > > I'll kill the /build/extensions element of the pom, and try > .mvn/ext

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

OK, thanks. I'll kill the /build/extensions element of the pom, and try .mvn/extensions.xml - Paul On Thu, Jun 1, 2017 at 7:26 AM, Igor Fedorenko wrote: > Build extensions are loaded too late to contribute event spies, see how > EventSpyDispatcher makes a copy of spies when it

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

Build extensions are loaded too late to contribute event spies, see how EventSpyDispatcher makes a copy of spies when it's created. And even if EventSpyDispatcher didn't make the copy, I think build extensions are not in scope to capture all events, i.e. things that happen before/after

Is the Maven 3 lifecycle extensions documentation page up to date?

ut that's not the problem). ... com.paulhammant buildradiatorextension 1.1-SNAPSHOT ... ^ exception that doesn't do anything. Worse, if I go back to the old way with the post-diff version (dropping the jar into ext/) if doesn't work either. TL;DR - EventSpy

Extensions

Hi, Maven supports an own extension mechanism described in https://maven.apache.org/pom.html#Extensions. I was under the expresseion that it can be used to inject new components into the Plexus container that are available for any other plugin (as long as they set the extensions flag to true

Re: Is there a reason extensions in ".mvn/extensions.xml" don't seem to support configuration?

Oh, well I would have a use case for it. I am currently working on bringing more and more parts of Apache Flex from Ant to Maven. Here in a lot of places I have dependencies that are not yet available as Maven artifacts. While I managed to get in contact with quite some of the people maintaini

Re: Is there a reason extensions in ".mvn/extensions.xml" don't seem to support configuration?

https://issues.apache.org/jira/browse/MNG-5897 Tycho also has a scenario where configuration would be helpful https://bugs.eclipse.org/bugs/show_bug.cgi?id=492819 Regards Jan On 05/07/16 18:48, "Igor Fedorenko" wrote: The latter. My original prototype had configuration support (may still have

Re: Is there a reason extensions in ".mvn/extensions.xml" don't seem to support configuration?

The latter. My original prototype had configuration support (may still have the code somewhere, not sure) but we took it out because we didn't have immediate usecase and didn't want to commit to any specific format and api without clear understanding how it was going to be used.. -- Regards, Igor

Is there a reason extensions in ".mvn/extensions.xml" don't seem to support configuration?

Hi, I just noticed that the extensions.xml doesn't seem to support configuring an extension. Is this intentional because it would break things or is it simply that none needed or implemented that functionality yet? Chris

Re: Maven Embedder and Lifecycle extensions

On 15 Jun 2016, at 23:30, Igor Fedorenko wrote: extensions.xml was meant for "non-functional" extensions, things like Takari SmartBuilder, which improves multi-threaded build scheduling but does not affect overall build results. If your extensions change build behaviour in non-tr

Re: Maven Embedder and Lifecycle extensions

extensions.xml was meant for "non-functional" extensions, things like Takari SmartBuilder, which improves multi-threaded build scheduling but does not affect overall build results. If your extensions change build behaviour in non-trivial ways, your build is not Maven any more and you sho

Maven Embedder and Lifecycle extensions

know what part of the problem might be the right place to chase up a fix in? Maven or IntelliJ ( or, possibly my code even ). Cheers Mark [1] https://intellij-support.jetbrains.com/hc/en-us/community/posts/207603265-Importing-Maven-Projects-using-Lifecycle-Extensions -- Mark Derricutt h

Re: Maven extensions

User extensions could be used for something like logging maybe and that would be fine. User extensions that may knock out project extensions that are required to build are is an issue. A user installs a extension to colour the log output, so what. But the first binding discovered is what works

Re: Maven extensions

+0 in general, but I think we should first check how multiple extensions will/may work, and see, what actually, was the original intention of extensions. We might miss some important reasons to NOT do this (maybe due to some technical reason?) For example, I use Takari smart builder, Takari

Re: Maven extensions

the target use: with this user > extensions > feature, each user can customize its own extensions without doing a full > Maven > installation > > Regards, > > Hervé > > Le mardi 12 janvier 2016 08:14:28 Anders Hammar a écrit : > > > Then I think we are missing

Re: Maven extensions

installation level need to point to user space, in a per-user location (~, or ${user.home} if you prefer this syntax): then the user space is filled or not, user per user multi-user installation is exactly the target use: with this user extensions feature, each user can customize its own

Re: Maven extensions

> > Then I think we are missing *user* extensions, that would be added in > ${maven.home}/bin/m2.conf the same way as installation extensions, but > pointing to ~/.m2/ext/*.jar > What would the benefit be of configuring this on installation level but keep the jar in user space?

Re: Maven extensions

+1 Le mardi 12 janvier 2016, Hervé BOUTEMY a écrit : > there are discussions lately on extensions, with 2 different meanings on > this: > > - either *project* extensions, with the .mvn feature added in Maven 3.3.0 > > - or more generic extension, like classical *installatio

Maven extensions

there are discussions lately on extensions, with 2 different meanings on this: - either *project* extensions, with the .mvn feature added in Maven 3.3.0 - or more generic extension, like classical *installation* extensions jars in ${maven.home}/lib/ext/ as configured in ${maven.home}/bin/m2

[SUREFIRE] Extensions

I have pushed a proposal of Surefire Extensions in new branch https://github.com/apache/maven-surefire/tree/s1 Added new module maven-surefire-extensions <https://github.com/apache/maven-surefire/tree/s1/maven-surefire-extensions> and extended the existing module maven-surefire-common

Re: 3.3.1 extensions loader & smart builder

i...@ifedorenko.com wrote on 03/31/2015 05:16:12 PM: > Yes, it is probably a good idea to file a bug report, but I am not sure > when I'll have time to look into this. http://jira.codehaus.org/browse/MNG-5795

Re: 3.3.1 extensions loader & smart builder

Yes, it is probably a good idea to file a bug report, but I am not sure when I'll have time to look into this. -- Regards, Igor On Tue, Mar 31, 2015, at 05:02 PM, Jeffrey E Care wrote: > i...@ifedorenko.com wrote on 03/31/2015 04:46:06 PM: > > > We assumed extensions will

Re: 3.3.1 extensions loader & smart builder

i...@ifedorenko.com wrote on 03/31/2015 04:46:06 PM: > We assumed extensions will be available from repositories that do not > require authentication and never tested with password protected > repositories. Just looking at the code, I think it should work with > clear-text

Re: 3.3.1 extensions loader & smart builder

We assumed extensions will be available from repositories that do not require authentication and never tested with password protected repositories. Just looking at the code, I think it should work with clear-text password in settings.xml, but most likely won't work when credentials are encr

Re: 3.3.1 extensions loader & smart builder

gt;> Make sure that if you're using a settings.xml pointing at a >> repository manager that your pluginRepositories are configured. Core >> extensions are loaded from plugin repositories not application > repositories. >> >> On Mar 31, 2015, at 2:55 PM, Jeffr

Re: 3.3.1 extensions loader & smart builder

Jason van Zyl wrote on 03/31/2015 03:09:40 PM: > Make sure that if you're using a settings.xml pointing at a > repository manager that your pluginRepositories are configured. Core > extensions are loaded from plugin repositories not application repositories. > > On Mar

Re: 3.3.1 extensions loader & smart builder

Here's an example project: https://github.com/takari/core-extensions-example You also want the concurrent safe local repo and you might to also have a maven.config to set the smart builder option and thread count. On Mar 31, 2015, at 2:55 PM, Jeffrey E Care wrote: > Has anyone

Re: 3.3.1 extensions loader & smart builder

Make sure that if you're using a settings.xml pointing at a repository manager that your pluginRepositories are configured. Core extensions are loaded from plugin repositories not application repositories. On Mar 31, 2015, at 2:55 PM, Jeffrey E Care wrote: > Has anyone had any succe

3.3.1 extensions loader & smart builder

tent/groups/pub lic/io/takari/maven/takari-smart-builder/0.4.0/takari-smart-builder-0.4.0.pom [WARNING] Failed to read extensions descriptor /home/carej/sandbox/sccStandalone/solutions-root/.mvn/extensions.xml: Plugin io.takari.maven:takari-smart-builder:0.4.0 or one of its dependencies could

Re: maven git commit: better plugin/extensions realm parent classloader

ng of >which, that documentation is somewhat outdated and does not mention core >extensions realm, for example. I meant to update it some time ago, but >could not find the sources of the diagram. Does anyone know where they are? if you look at attachements, there is a svg associated with the pn

Re: maven git commit: better plugin/extensions realm parent classloader

n is integrated > Speaking of > which, that documentation is somewhat outdated and does not mention core > extensions realm, for example. I meant to update it some time ago, but > could not find the sources of the diagram. Does anyone know where they are? if you look at attachements, th

Re: maven git commit: better plugin/extensions realm parent classloader

ntion core extensions realm, for example. I meant to update it some time ago, but could not find the sources of the diagram. Does anyone know where they are? I do not believe this change deserves dedicated integration test, at least not in maven. There is only so many ways you can access system classloa

Re: maven git commit: better plugin/extensions realm parent classloader

https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Class+Loading Le jeudi 8 janvier 2015 13:09:10 ifedore...@apache.org a écrit : > Repository: maven > Updated Branches: > refs/heads/master 5f71f9789 -> bb4988496 > > > better plugin/extensions realm parent classloader > &g

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

LifeCycleParticipant#afterProjectsRead is called after projects pom.xml are read and MavenProject instances created but *before* actual build starts. It is called for entire session and not any reactor project in particular. -- Regards, Igor On 2014-05-23, 21:03, William Ferguson wrote: Thanks

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

Argh .. I think I finally get it - thanks Igor. On Sat, May 24, 2014 at 11:03 AM, William Ferguson < william.fergu...@xandar.com.au> wrote: > Thanks Igor. > > >> A correct LifeCycleParticipant implementation should always scope >> component lookups to the current project's classloader and should

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

Thanks Igor. > A correct LifeCycleParticipant implementation should always scope > component lookups to the current project's classloader and should use > the original classloader to allow lookup of the core components only. But in a multi-module build the LifeCycleParticipant is only ever call

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

ClassRealm. Is that expected? Shouldn't the top level project always have some ClassRealm? Should all projects? Yes, this is expected. MavenProject.getClassRealm() returns project extensions realm. If project does not have build extensions or plugin elements with extensions=true, there is no exten

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

, Jason van Zyl wrote: > For why it fixes it you may want to take a look at the detailed > documentation Benjamin wrote while working on Maven 3: > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Class+Loading > > Extensions A and B in the diagrams are your case exac

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

é Le mercredi 21 mai 2014 07:51:56 Igor Fedorenko a écrit : > I am absolutely certain that all project build extensions are loaded by > the time participant#afterProjectsRead is called, and this is the > callback used in William's example. Setting correct TCCL makes his > example work

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

For why it fixes it you may want to take a look at the detailed documentation Benjamin wrote while working on Maven 3: https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Class+Loading Extensions A and B in the diagrams are your case exactly. The PlexusWagonProvider in Aether injects

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

I am absolutely certain that all project build extensions are loaded by the time participant#afterProjectsRead is called, and this is the callback used in William's example. Setting correct TCCL makes his example work. You are correct, however, that participant#afterSessionStart is in

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

aware of from setting the Thread#contextClassloader to MaveProject#classReam at that point in the lifecycle? William On Wed, May 21, 2014 at 11:20 AM, Igor Fedorenko wrote: MavenLifecycleParticipant comes from a build extension, so build extensions are loaded for sure. Most likely the problem has

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

ild extension, so build > extensions are loaded for sure. > > Most likely the problem has to do with thread context classloader, you > need to set it to project extensions realm (as returned by > MavenProject.getClassRealm) to be able to lookup project build > extensions. And don't

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

no, extension are not loaded on this precise method: there is a TODO in the interface about this, and when you read DefaultMaven, you see the reason why this method can't have extensions = too early = the TODO comment Regards, Hervé Le mardi 20 mai 2014 21:20:36 Igor Fedorenko a

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

MavenLifecycleParticipant comes from a build extension, so build extensions are loaded for sure. Most likely the problem has to do with thread context classloader, you need to set it to project extensions realm (as returned by MavenProject.getClassRealm) to be able to lookup project build

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

Hi Herve, I am using MLCP#afterProjectsRead. Unfortunately the extensions don't seem to be loaded at that point either. William On Wed, May 21, 2014 at 10:03 AM, Hervé BOUTEMY wrote: > if you look at AbstractMavenLifecycleParticipant source file: > > /** >

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

if you look at AbstractMavenLifecycleParticipant source file: /** * Invoked after MavenSession instance has been created. * * This callback is intended to allow extensions to inject execution properties, * activate profiles and perform similar tasks that affect

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

ow to get the > >> external wagon deps to resolve from the MLCP? > >> > >> William > >> > >> > >> On Fri, May 16, 2014 at 1:22 AM, William Ferguson < > >> william.fergu...@xandar.com.au> wrote: > >> > >>> No on

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

t the >> external wagon deps to resolve from the MLCP? >> >> William >> >> >> On Fri, May 16, 2014 at 1:22 AM, William Ferguson < >> william.fergu...@xandar.com.au> wrote: >> >>> No one on the user's list wanted to have a go at t

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

2014 at 1:22 AM, William Ferguson < > william.fergu...@xandar.com.au> wrote: > >> No one on the user's list wanted to have a go at this. How about someone >> from the Dev list? >> >> William >> >> >> -- Forwarded mess

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

gt; > -- Forwarded message -- > From: William Ferguson > Date: Mon, May 12, 2014 at 8:58 PM > Subject: Wagon extensions not available from > AbstractMavenLifecycleParticipant or maven-dependency-tree? > To: Maven Users List > > > I have a MavenLifecycl

Fwd: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

No one on the user's list wanted to have a go at this. How about someone from the Dev list? William -- Forwarded message -- From: William Ferguson Date: Mon, May 12, 2014 at 8:58 PM Subject: Wagon extensions not available from AbstractMavenLifecycleParticipant or

  1   2   3   >