Hi Igor
On 2014-05-04 14:08, Igor Fedorenko wrote:
> If all compiler delegates have the same groupId/artifactId but different
> versions, then you can use standard maven plugin dependency resolution
> to achieve something very similar. Specify the default delegate
> groupId/artifactId/version as direct plugin dependency, but the user
> will still be able to specify different version with
> <plugin>/<dependency> in their pom.xml files. Maybe not as convenient as
> "sbtVersion" parameter, but way simpler to implement.
This is a little different. The compiler delegates have different
artifactIds.
Their dependencies have the same groupId+artifactId pairs
(com.typesafe.zinc:zinc).
For example:
<plugin>
<groupId>com.google.code.sbt-compiler-maven-plugin</groupId>
<artifactId>sbt-compiler-maven-plugin</artifactId>
<version>1.0.0-beta3</version>
<dependencies>
<dependency> <!-- depends on
com.typesafe.zinc:zinc:0.2.5 -->
<groupId>com.google.code.sbt-compiler-maven-plugin</groupId>
<artifactId>sbt-compiler-sbt012</artifactId>
<version>1.0.0-beta3</version>
</dependency>
<dependency> <!-- depends on
com.typesafe.zinc:zinc:0.3.0 -->
<groupId>com.google.code.sbt-compiler-maven-plugin</groupId>
<artifactId>sbt-compiler-sbt013</artifactId>
<version>1.0.0-beta3</version>
</dependency>
</dependencies>
</plugin>
Dependency conflict is with "com.typesafe.zinc:zinc" (and its dependencies).
>
> If you really want to have "sbtVersion", I don't believe you'll be able
> to use dependency injection or at least this will be super messy. Plugin
> class realm is fully setup before plugin code runs (obviously), so you
> won't be able to use standard maven plugin component discovery for sure.
> What may work is this : resolve compiler delegate dependencies, filter
> anything that must be provided by maven core and your plugin, create new
> child classrealm with the filtered depenedncies as classpath , then
> discover components in the new realm with
> DefaultPlexusContainer#discoverComponents, then set thread context
> classloader to the new realm and hopefully be able to do
> PlexusContainer#lookup. You will almost certainly want to cache the
> new realm so your plugin performs reasonably well during multimodule
> build and will need to discard the realm at the end of the build.
I didn't try to understand class realms. I found no documentation and
this is too complicated for me.
I'm creating URLClassloaders, and this solution works. I'm cache'ing
these classloaders to improve
performace (I asked about releasing them some time ago, and you answered).
I want to improve [4]. Look at this line. This works, but I don't like
the way I implemented it.
I would prefer to use Plexus to discover component implementation in the
artifact.
Regards
Grzegorz
>
> --
> Regards,
> Igor
>
> On 2014-05-04, 5:36, Grzegorz Słowikowski wrote:
>> Hi Jason
>>
>> Thanks for your response. I will try to describe, what I need.
>>
>> I'm developing sbt-compiler-maven-plugin [1]. This plugin is similar to
>> maven-compiler-plugin.
>> It compiles Java and Scala sources using SBT (Scala Build Tool)
>> delegates.
>> There are different delegates for different, not compatible, SBT
>> versions.
>> This is similar to Plexus compilers idea. There is one important
>> difference though.
>> In maven-compiler-plugin there is default compiler, Javac, added as
>> plugin's dependency.
>> If you want another compiler, you add it as plugin dependency and set
>> compilerId parameter.
>> Javac compiler has no dependencies, so it will never cause dependency
>> conflict with other compilers.
>>
>> In my case different delegates/compilers depend on different versions of
>> the same artifacts,
>> so there never can be more than one compiler in plugin's classpath. The
>> consequence is, user has always! add the compiler he needs to plugin's
>> dependencies.
>> To avoid this, I implemented compiler autoselection mechanism. If there
>> is no compiler added to plugin's dependencies,
>> plugin automatically detects and resolves one based on "sbtVersion"
>> parameter.
>>
>> This is very similar to Surefire providers detection mechanism [2].
>> Surefire has delegates called providers, for example for different JUnit
>> versions.
>> The user doesn't need to configure a provider, Surefire does it
>> automatically based on test framework dependecy in a project and some
>> plugin's parameters.
>> Because different junit providers depend on different versions of junit
>> artifact, only one provider at a time can be used (just like in my
>> plugin).
>>
>> Surefire uses standard Java services mechanism to resolves a provider
>> class, for example [3]. It does not use Plexus DI.
>>
>> I want to use Plexus in my plugin, but I don't know how to find provider
>> class inside an artifact jar. I want to replace this [4] ugly code.
>>
>> [1]
>> https://sbt-compiler-maven-plugin.googlecode.com/svn/mavensite/1.0.0-beta3/index.html
>>
>> [2]
>> http://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html
>>
>> [3]
>> https://github.com/apache/maven-surefire/blob/c8858944ca1409ae368f217cc2f7ca039651bd98/surefire-providers/surefire-junit3/src/main/resources/META-INF/services/org.apache.maven.surefire.providerapi.SurefireProvider
>>
>> [4]
>> https://sbt-compiler-maven-plugin.googlecode.com/svn/mavensite/1.0.0-beta3/sbt-compiler-maven-plugin/xref/com/google/code/sbt/compiler/plugin/AbstractSBTCompileMojo.html#L694
>>
>>
>> Regards
>> Grzegorz
>>
>> On 2014-05-01 16:51, Jason van Zyl wrote:
>>> What are you trying to do from a high level.
>>>
>>> Much of what Maven does to resolve, load and configure plugins
>>> dynamically can likely be reused, but if you tell me what you want I
>>> can point you at code you can lift. At a high level Maven:
>>>
>>> 1. Looks at some configuration and determines what the plugin is
>>> 2. Downloads the plugin into the local repository
>>> 3. Creates a class loader with the plugin artifact and its dependencies
>>> 4. Scans the class loader for component implementations (the mojos,
>>> and any ancillary components)
>>> 5. Instantiates the plugin
>>> 6. Applies configuration to the plugin
>>> 7. Executes the plugin
>>>
>>> On May 1, 2014, at 5:07 AM, Grzegorz Słowikowski
>>> <gslowikow...@gmail.com> wrote:
>>>
>>>> Hi
>>>>
>>>> I need to read "implementation" value of a component with specified
>>>> "role" and "role-hint"
>>>> from "META-INF/plexus/components.xml" resource of dynamically resolved
>>>> artifact.
>>>>
>>>> In other words I want to do the same thing Maven does configuring mojo
>>>> attributes
>>>> with @Component( role = AnInterface.class hint = "foo") annotation.
>>>> Maven finds implementation in the classpath, initializes
>>>> implementation
>>>> object
>>>> and assigns to mojo attribute.
>>>>
>>>> In my case I find and resolve an artifact containing the class
>>>> implementing "AnInterface.class" role
>>>> with "foo" hint (a have a well known pool of artifacts with different
>>>> implementations).
>>>> Now I need to get this implementation class name.
>>>>
>>>> How can I do this?
>>>>
>>>> Regards
>>>> Grzegorz Slowikowski
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>> ---------------------------------------------------------
>>>
>>> I never make the mistake of arguing with people for whose opinions I
>>> have no respect.
>>>
>>> -- Edward Gibbon
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
