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.
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.
--
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 <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
