Re: Plugable/Softcoded/Customized Maven Plugins
Lennart; Is there a good solution for having the user-provided implementation *replace* the built-in one ? Kristian 2015-01-15 21:29 GMT+01:00 Lennart Jörelid lennart.jore...@gmail.com: I believe that it is important to let the POM serve as a configuration (for a set of Plugin-clad operations). If we permit the POM to be the host of scripts, I suggest that overall build stability would be compromised. If one wants to implement a chain-of-command or extension pattern within a Plugin, it is simple enough. - Define an interface (say Transformer) holding methods defining a behaviour - Define an array or list of these Transformers within your plugin, as shown below. - In your execute() method, simply call them in order. - You have now defined a behaviour; Maven's standard mechanics permit you to inject several different implementations @Parameter private Transformer[] transformer; with the configuration configuration coffeCooker implementation=your.coffee.ExtensionCooker/ breadBaker implementation=your.bread.Processor/ /configuration This may not be a very obvious way to implement an extension, but it certainly works. The enforcer plugin, which was mentioned above uses this type of mechanics to permit injecting custom rules (of type EnforcerRule). Would this type of extension cover the needs? Or am I missing your point, Tibor? 2015-01-15 21:09 GMT+01:00 Jason van Zyl ja...@takari.io: Ok, stay within what's here. I posit that the default lifecycle and binding to it with mojos provides sufficient means of extension. So we have a lifecycle and at the other extreme in Ant and Gradle we have an arbitrary DAG. Along that spectrum I'm not sure I understand what you think the problem is. I also posit that you can make Java-based extension mechanisms today. Maybe not scriptable ones but you can provide extension points. I gather that the whole issue you're talking about is it extensibility? If so I was only trying to draw attention to facilities that are present you may not be familiar with. On Jan 15, 2015, at 2:54 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Jason; We have been talking at length about what we think is wrong with the plugin model in this thread. I'm happy to hear that you have solved things within the existing model in Takari. From what I've picked up It sounds like you have made an even greater monotlith than what we already have, so it appears you may not consider this whole issue a problem. The solutions you describe are things we know about. I still consider this to be an important problem; maybe the most important problem we are facing. Kristian 2015-01-15 20:36 GMT+01:00 Jason van Zyl ja...@takari.io: What do you think is unclear about the default lifecycle that you augment by adding new executions to a particular phase in the lifecycle? You can also make your own lifecycle if you wish but for the most part the default lifecycle is sufficient. Or even cahnge all the bindings for the default lifecycle. For the Takari Lifecycle which has completely different implementations we didn't need any changes to the default lifecycle we just bound new implementations. There is also nothing stopping you from adding extensions points to plugins. You can do that today, the enforcer plugin being a case in point. This mechanism already exists where you can create an extension point as a collection that gets injected into a plugin, and new implementations of the extension will be loaded dynamically when added as dependencies to that plugin in the POM. We can add this to any plugin today. If you wanted to provide an extension point to the maven-jar-plugin to filter the manifest before writing it into the JAR you can do that now. On Jan 15, 2015, at 5:57 AM, Tibor Digana tibordig...@apache.org wrote: Maybe Jason can bring some light into this discussion. Jason? -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.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 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:
Re: Plugable/Softcoded/Customized Maven Plugins
Because if extensions is true then there could be a custom lifecycle or packaging in the plugin and that *may* affect the build plan before it is constructed. On 15 January 2015 at 05:43, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: 2015-01-15 4:48 GMT+01:00 Igor Fedorenko i...@ifedorenko.com: Although I generally *strongly* discourage resolution of plugins and plugin dependencies from the reactor Why ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
The initial problem was to @Inject user's implementation of client-api (some dependency) in MOJO. No problem if user implements our interfaces in a dependency for surefire plugin - this may modify RunOrder feature for instance. Should work... I am sure that some users will say that they have 1000 modules, the dependencies cannot be configured like plugins, and each of them needs different implementation of our interfaces and thus plenty of new dependencies. The extensions might be a partial solution, however I don't think surefire has an ambition to modify lifecycle, but we will be in the same point where we are now because of new JIRA issues will come to make new configuration entries in the extension plugin. We can do the same what @Lennart mentioned with EnforcerRule coffeCooker implementation=your.coffee.ExtensionCooker/ , but I know that stephenc mentioned in other post that this is not ideal extension style. Some users may come with a wish to have implementation of the interfaces in test classes src/test/java/**/instrumentation/**/*.java, without creating new dependency module and extension plugin. Not creating new modules and extension plugins makes their life easier. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823781.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: Plugable/Softcoded/Customized Maven Plugins
I usually handle the case with replacing default plugin functionality with
non-mandatory (and, hopefully, well-documented) plugin parameters, similar
to the following:
*Within a locally defined AbstractMojo subclass:*
protected abstract ListTransformer getTransformers();
*In the concrete Mojo (which extends the locally defined AbstractMojo
subclass):*
@Parameter
private Transformer[] transformers;
@Override
protected ListTransformer getTransformers() {
if(transformers == null || transformers.length == 0) {
// Fallback to a defined standard of transformers, defined within this
Mojo.
return STANDARD_TRANSFORMERS;
}
// All done.
return Arrays.TransformerasList(transformers);
}
This ensures that the call to getTransformers() always returns a non-null
result, and that any user-supplied configuration fully replaces the
defaults. If user configuration should be treated as an *extension* to the
locally provided STANDARD_TRANSFORMERS, I adjust the logic in the
getTransformers method - and the documentation - accordingly.
This approach is programmatically trivial, but requires updated and
sensible documentation (Which are the standard Transformers? Does
user-supplied configuration replace standards or add to them?). I fully
understand that there are no maven-defined standards for this behaviour -
it is implemented in every plugin that needs it.
2015-01-16 9:36 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com:
Lennart;
Is there a good solution for having the user-provided implementation
*replace* the built-in one ?
Kristian
2015-01-15 21:29 GMT+01:00 Lennart Jörelid lennart.jore...@gmail.com:
I believe that it is important to let the POM serve as a configuration
(for
a set of Plugin-clad operations).
If we permit the POM to be the host of scripts, I suggest that overall
build stability would be compromised.
If one wants to implement a chain-of-command or extension pattern within
a
Plugin, it is simple enough.
- Define an interface (say Transformer) holding methods defining a
behaviour
- Define an array or list of these Transformers within your plugin, as
shown below.
- In your execute() method, simply call them in order.
- You have now defined a behaviour; Maven's standard mechanics permit
you to inject several different implementations
@Parameter
private Transformer[] transformer;
with the configuration
configuration
coffeCooker implementation=your.coffee.ExtensionCooker/
breadBaker implementation=your.bread.Processor/
/configuration
This may not be a very obvious way to implement an extension, but it
certainly works. The enforcer plugin, which was mentioned above uses this
type of mechanics to permit injecting custom rules (of type
EnforcerRule).
Would this type of extension cover the needs? Or am I missing your point,
Tibor?
2015-01-15 21:09 GMT+01:00 Jason van Zyl ja...@takari.io:
Ok, stay within what's here.
I posit that the default lifecycle and binding to it with mojos provides
sufficient means of extension. So we have a lifecycle and at the other
extreme in Ant and Gradle we have an arbitrary DAG. Along that spectrum
I'm
not sure I understand what you think the problem is.
I also posit that you can make Java-based extension mechanisms today.
Maybe not scriptable ones but you can provide extension points.
I gather that the whole issue you're talking about is it
extensibility?
If so I was only trying to draw attention to facilities that are present
you may not be familiar with.
On Jan 15, 2015, at 2:54 PM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
Jason;
We have been talking at length about what we think is wrong with the
plugin model in this thread. I'm happy to hear that you have solved
things within the existing model in Takari. From what I've picked up
It sounds like you have made an even greater monotlith than what we
already have, so it appears you may not consider this whole issue a
problem.
The solutions you describe are things we know about. I still consider
this to be an important problem; maybe the most important problem we
are facing.
Kristian
2015-01-15 20:36 GMT+01:00 Jason van Zyl ja...@takari.io:
What do you think is unclear about the default lifecycle that you
augment by adding new executions to a particular phase in the lifecycle?
You can also make your own lifecycle if you wish but for the most part
the
default lifecycle is sufficient. Or even cahnge all the bindings for the
default lifecycle. For the Takari Lifecycle which has completely
different
implementations we didn't need any changes to the default lifecycle we
just
bound new implementations.
There is also nothing stopping you from adding extensions points to
plugins. You can do that today, the enforcer plugin being a case in
point.
This
Re: Plugable/Softcoded/Customized Maven Plugins
Oh - and I see I forgot the surrounding transformers element within the
configuration, but we all realize that, right? To make this work with
maven's DI, it should have read:
configuration
transformers
coffeCooker implementation=your.coffee.ExtensionCooker/
breadBaker implementation=your.bread.Processor/
/transformers
/configuration
2015-01-16 17:17 GMT+01:00 Lennart Jörelid lennart.jore...@gmail.com:
I usually handle the case with replacing default plugin functionality with
non-mandatory (and, hopefully, well-documented) plugin parameters, similar
to the following:
*Within a locally defined AbstractMojo subclass:*
protected abstract ListTransformer getTransformers();
*In the concrete Mojo (which extends the locally defined AbstractMojo
subclass):*
@Parameter
private Transformer[] transformers;
@Override
protected ListTransformer getTransformers() {
if(transformers == null || transformers.length == 0) {
// Fallback to a defined standard of transformers, defined within
this Mojo.
return STANDARD_TRANSFORMERS;
}
// All done.
return Arrays.TransformerasList(transformers);
}
This ensures that the call to getTransformers() always returns a non-null
result, and that any user-supplied configuration fully replaces the
defaults. If user configuration should be treated as an *extension* to
the locally provided STANDARD_TRANSFORMERS, I adjust the logic in the
getTransformers method - and the documentation - accordingly.
This approach is programmatically trivial, but requires updated and
sensible documentation (Which are the standard Transformers? Does
user-supplied configuration replace standards or add to them?). I fully
understand that there are no maven-defined standards for this behaviour -
it is implemented in every plugin that needs it.
2015-01-16 9:36 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com
:
Lennart;
Is there a good solution for having the user-provided implementation
*replace* the built-in one ?
Kristian
2015-01-15 21:29 GMT+01:00 Lennart Jörelid lennart.jore...@gmail.com:
I believe that it is important to let the POM serve as a configuration
(for
a set of Plugin-clad operations).
If we permit the POM to be the host of scripts, I suggest that overall
build stability would be compromised.
If one wants to implement a chain-of-command or extension pattern
within a
Plugin, it is simple enough.
- Define an interface (say Transformer) holding methods defining a
behaviour
- Define an array or list of these Transformers within your plugin,
as
shown below.
- In your execute() method, simply call them in order.
- You have now defined a behaviour; Maven's standard mechanics permit
you to inject several different implementations
@Parameter
private Transformer[] transformer;
with the configuration
configuration
coffeCooker implementation=your.coffee.ExtensionCooker/
breadBaker implementation=your.bread.Processor/
/configuration
This may not be a very obvious way to implement an extension, but it
certainly works. The enforcer plugin, which was mentioned above uses
this
type of mechanics to permit injecting custom rules (of type
EnforcerRule).
Would this type of extension cover the needs? Or am I missing your
point,
Tibor?
2015-01-15 21:09 GMT+01:00 Jason van Zyl ja...@takari.io:
Ok, stay within what's here.
I posit that the default lifecycle and binding to it with mojos
provides
sufficient means of extension. So we have a lifecycle and at the other
extreme in Ant and Gradle we have an arbitrary DAG. Along that
spectrum I'm
not sure I understand what you think the problem is.
I also posit that you can make Java-based extension mechanisms today.
Maybe not scriptable ones but you can provide extension points.
I gather that the whole issue you're talking about is it
extensibility?
If so I was only trying to draw attention to facilities that are
present
you may not be familiar with.
On Jan 15, 2015, at 2:54 PM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
Jason;
We have been talking at length about what we think is wrong with the
plugin model in this thread. I'm happy to hear that you have solved
things within the existing model in Takari. From what I've picked up
It sounds like you have made an even greater monotlith than what we
already have, so it appears you may not consider this whole issue a
problem.
The solutions you describe are things we know about. I still consider
this to be an important problem; maybe the most important problem we
are facing.
Kristian
2015-01-15 20:36 GMT+01:00 Jason van Zyl ja...@takari.io:
What do you think is unclear about the default lifecycle that you
augment by adding new executions to a particular phase in the
lifecycle?
You can also make
Re: Plugable/Softcoded/Customized Maven Plugins
Ok, stay within what's here. I posit that the default lifecycle and binding to it with mojos provides sufficient means of extension. So we have a lifecycle and at the other extreme in Ant and Gradle we have an arbitrary DAG. Along that spectrum I'm not sure I understand what you think the problem is. I also posit that you can make Java-based extension mechanisms today. Maybe not scriptable ones but you can provide extension points. I gather that the whole issue you're talking about is it extensibility? If so I was only trying to draw attention to facilities that are present you may not be familiar with. On Jan 15, 2015, at 2:54 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Jason; We have been talking at length about what we think is wrong with the plugin model in this thread. I'm happy to hear that you have solved things within the existing model in Takari. From what I've picked up It sounds like you have made an even greater monotlith than what we already have, so it appears you may not consider this whole issue a problem. The solutions you describe are things we know about. I still consider this to be an important problem; maybe the most important problem we are facing. Kristian 2015-01-15 20:36 GMT+01:00 Jason van Zyl ja...@takari.io: What do you think is unclear about the default lifecycle that you augment by adding new executions to a particular phase in the lifecycle? You can also make your own lifecycle if you wish but for the most part the default lifecycle is sufficient. Or even cahnge all the bindings for the default lifecycle. For the Takari Lifecycle which has completely different implementations we didn't need any changes to the default lifecycle we just bound new implementations. There is also nothing stopping you from adding extensions points to plugins. You can do that today, the enforcer plugin being a case in point. This mechanism already exists where you can create an extension point as a collection that gets injected into a plugin, and new implementations of the extension will be loaded dynamically when added as dependencies to that plugin in the POM. We can add this to any plugin today. If you wanted to provide an extension point to the maven-jar-plugin to filter the manifest before writing it into the JAR you can do that now. On Jan 15, 2015, at 5:57 AM, Tibor Digana tibordig...@apache.org wrote: Maybe Jason can bring some light into this discussion. Jason? -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.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 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 - 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 - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
I think that we don't need to fully open up our plugins so that anyone can customize each aspect on the fly. We would too much hide the fact that the execution is highly customized because some special stuff is hidden on the classpath somewhere. Likewise, if we allowed that sort of customization directly as script in the pom, then we'd try to mimic something that other tools like gradle already do - that may be good for some use cases (and then you should use gradle), but it's not what Maven is there for. What especially liked about Maven after years of Ant was, besides the dependency management, the uniformity of all those different maven projects. Maven has still a lot room for improvement, sure. Allowing the complete redefinition of mojos via scripting in the poms is not something that I would see as an improvement (plus, there are all those drawbacks on coding, testing, debugging, as Kristian already pointed out). For the big picture, I think it would suffice if we found and agreed upon a handy mechanism to allow users to hook in at _defined_ places (e.g. for Surefire the processing of the list of tests to execute, reporting, maybe forking, ..). I'd say such a mechanism is handy, if it fulfills the following requirements: * pulling in a client-api does not mean I also get all sorts of other maven-specific stuff on my classpath * it should be possible to pick up the exension from the current reactor (from the classpath - or perhaps we use some new packaging-type or something) * it should be easy and maybe encouraged to publish extensions - that should be a no-brainer in any case, but perhaps there's something we can do to help people find existing extensions - similar to the way you find plugins for Jenkins Andreas 2015-01-15 11:57 GMT+01:00 Tibor Digana tibordig...@apache.org: Maybe Jason can bring some light into this discussion. Jason? -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.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: Plugable/Softcoded/Customized Maven Plugins
Jason; We have been talking at length about what we think is wrong with the plugin model in this thread. I'm happy to hear that you have solved things within the existing model in Takari. From what I've picked up It sounds like you have made an even greater monotlith than what we already have, so it appears you may not consider this whole issue a problem. The solutions you describe are things we know about. I still consider this to be an important problem; maybe the most important problem we are facing. Kristian 2015-01-15 20:36 GMT+01:00 Jason van Zyl ja...@takari.io: What do you think is unclear about the default lifecycle that you augment by adding new executions to a particular phase in the lifecycle? You can also make your own lifecycle if you wish but for the most part the default lifecycle is sufficient. Or even cahnge all the bindings for the default lifecycle. For the Takari Lifecycle which has completely different implementations we didn't need any changes to the default lifecycle we just bound new implementations. There is also nothing stopping you from adding extensions points to plugins. You can do that today, the enforcer plugin being a case in point. This mechanism already exists where you can create an extension point as a collection that gets injected into a plugin, and new implementations of the extension will be loaded dynamically when added as dependencies to that plugin in the POM. We can add this to any plugin today. If you wanted to provide an extension point to the maven-jar-plugin to filter the manifest before writing it into the JAR you can do that now. On Jan 15, 2015, at 5:57 AM, Tibor Digana tibordig...@apache.org wrote: Maybe Jason can bring some light into this discussion. Jason? -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.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 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
On Jan 15, 2015, at 2:29 PM, Andreas Gudian andreas.gud...@gmail.com wrote: I think that we don't need to fully open up our plugins so that anyone can customize each aspect on the fly. We would too much hide the fact that the execution is highly customized because some special stuff is hidden on the classpath somewhere. Likewise, if we allowed that sort of customization directly as script in the pom, then we'd try to mimic something that other tools like gradle already do - that may be good for some use cases (and then you should use gradle), but it's not what Maven is there for. What especially liked about Maven after years of Ant was, besides the dependency management, the uniformity of all those different maven projects. Maven has still a lot room for improvement, sure. Allowing the complete redefinition of mojos via scripting in the poms is not something that I would see as an improvement (plus, there are all those drawbacks on coding, testing, debugging, as Kristian already pointed out). I don't think scripting anything you want is a great idea. But there are already examples of writing plugins inline in a form of a POM: https://github.com/takari/maven-polyglot/blob/master/poms/pom.rb What I described in the in the previous post where you can create extensions points for plugins already could be augmented to allow those extension points to be scriptable. That might be convenient but that still doesn't change the default lifecycle and doesn't require a complete regression to full-on scripting whatever you. For the big picture, I think it would suffice if we found and agreed upon a handy mechanism to allow users to hook in at _defined_ places (e.g. for Surefire the processing of the list of tests to execute, reporting, maybe forking, ..). I'd say such a mechanism is handy, if it fulfills the following requirements: * pulling in a client-api does not mean I also get all sorts of other maven-specific stuff on my classpath * it should be possible to pick up the exension from the current reactor (from the classpath - or perhaps we use some new packaging-type or something) * it should be easy and maybe encouraged to publish extensions - that should be a no-brainer in any case, but perhaps there's something we can do to help people find existing extensions - similar to the way you find plugins for Jenkins You can certainly have Java-based extension points now, and if you wanted to provide some scripting you can but what would you see that actually looking like? And for what? Andreas 2015-01-15 11:57 GMT+01:00 Tibor Digana tibordig...@apache.org: Maybe Jason can bring some light into this discussion. Jason? -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
Conceptually, I believe this is a case bad separation of concerns. Build tools and production code often require different development skills and techniques, have different dependencies. You really need to wear two different hats to work on the tools and production code, and I think many devs have difficulties switching (I certainly do). As a result, collocated build tools tend to be poorly written, with no or very little tests and virtually impossible to refactor. Of course, keeping build tools outside of production codebase does not guarantee anything by itself, but I think it increases the likelihood of maintainable code. Other practical problems * can't run partial lifecycle (as in mvn generate-sources), or at least not always. java annotation processors, for example, must be packages into jars, so really must run mvn package. * no m2e integration -- Regards, Igor On 2015-01-15 0:43, Kristian Rosenvold wrote: 2015-01-15 4:48 GMT+01:00 Igor Fedorenko i...@ifedorenko.com: Although I generally *strongly* discourage resolution of plugins and plugin dependencies from the reactor Why ? 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: Plugable/Softcoded/Customized Maven Plugins
I believe that it is important to let the POM serve as a configuration (for a set of Plugin-clad operations). If we permit the POM to be the host of scripts, I suggest that overall build stability would be compromised. If one wants to implement a chain-of-command or extension pattern within a Plugin, it is simple enough. - Define an interface (say Transformer) holding methods defining a behaviour - Define an array or list of these Transformers within your plugin, as shown below. - In your execute() method, simply call them in order. - You have now defined a behaviour; Maven's standard mechanics permit you to inject several different implementations @Parameter private Transformer[] transformer; with the configuration configuration coffeCooker implementation=your.coffee.ExtensionCooker/ breadBaker implementation=your.bread.Processor/ /configuration This may not be a very obvious way to implement an extension, but it certainly works. The enforcer plugin, which was mentioned above uses this type of mechanics to permit injecting custom rules (of type EnforcerRule). Would this type of extension cover the needs? Or am I missing your point, Tibor? 2015-01-15 21:09 GMT+01:00 Jason van Zyl ja...@takari.io: Ok, stay within what's here. I posit that the default lifecycle and binding to it with mojos provides sufficient means of extension. So we have a lifecycle and at the other extreme in Ant and Gradle we have an arbitrary DAG. Along that spectrum I'm not sure I understand what you think the problem is. I also posit that you can make Java-based extension mechanisms today. Maybe not scriptable ones but you can provide extension points. I gather that the whole issue you're talking about is it extensibility? If so I was only trying to draw attention to facilities that are present you may not be familiar with. On Jan 15, 2015, at 2:54 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Jason; We have been talking at length about what we think is wrong with the plugin model in this thread. I'm happy to hear that you have solved things within the existing model in Takari. From what I've picked up It sounds like you have made an even greater monotlith than what we already have, so it appears you may not consider this whole issue a problem. The solutions you describe are things we know about. I still consider this to be an important problem; maybe the most important problem we are facing. Kristian 2015-01-15 20:36 GMT+01:00 Jason van Zyl ja...@takari.io: What do you think is unclear about the default lifecycle that you augment by adding new executions to a particular phase in the lifecycle? You can also make your own lifecycle if you wish but for the most part the default lifecycle is sufficient. Or even cahnge all the bindings for the default lifecycle. For the Takari Lifecycle which has completely different implementations we didn't need any changes to the default lifecycle we just bound new implementations. There is also nothing stopping you from adding extensions points to plugins. You can do that today, the enforcer plugin being a case in point. This mechanism already exists where you can create an extension point as a collection that gets injected into a plugin, and new implementations of the extension will be loaded dynamically when added as dependencies to that plugin in the POM. We can add this to any plugin today. If you wanted to provide an extension point to the maven-jar-plugin to filter the manifest before writing it into the JAR you can do that now. On Jan 15, 2015, at 5:57 AM, Tibor Digana tibordig...@apache.org wrote: Maybe Jason can bring some light into this discussion. Jason? -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.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 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
Re: Plugable/Softcoded/Customized Maven Plugins
True, Kristian.
But the pains of creating a Maven project A to host dependencies for
plugins in project B seem ... small in comparison to injecting dynamic
elements into the POM. Provided, of course, that one intends to re-use and
unit test the plugin extension.
2015-01-14 16:10 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com
:
It is only inconvenient because maven cannot resolve the artifact from
the current reactor, or at least it was not able to when I made
testcases for this for surefire-providers.
This means the extension has to be in a separate project and
built/deployed entirely separate module; this is an annoyance because
immediacy and user-accessibility is a key value in such stuff. I want
some of these extensions to be in my code base and to actually work
when I attach a debugger. Using modules deployed to central/some other
repo is also cool, but I really think we need to serve the here and
now case.
So if I put the extension in my current project I will have to build
that extension specifically with mvn -N the first time, since it does
not exist somewhere it can be resolved. And I will always be using the
previous version when I build
Kristian
2015-01-14 15:15 GMT+01:00 Benson Margulies bimargul...@gmail.com:
So, I'm confused as to why asking people to add jars to the
dependencies/
of a plugin/ is seen as annoying or inconvenient. Can you deconfuse me?
On Wed, Jan 14, 2015 at 8:19 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
If we additionaly look for a solution that would work straight out of
the box for maven 3.0, the plugin could actually just use some kind of
loader library that would load/detect the supplied artifact into the
plugin classloader and use lazy container lookup logic when resolving
the user-supplied service. In that way you'd end up with something
like this:
DiscoveryService.findExtensions(); // Do something magic which loads
jar in plugin classloader
RunOrderSorter userSupplied = container.lookup(RunOrderSorter.class);
if (userSupplied != null) {
// Use usersupplied
}
Now all we'd have to do was put RunOrderSorter in a client-api
module, and we could load it at will. We just need an implementation
for the Do something magic bit above
This
2015-01-14 13:43 GMT+01:00 Kristian Rosenvold
kristian.rosenv...@gmail.com:
Agreed Benson; I find it very interesting to reduce this problem
initially, then we can grow it afterwards once we sort of understand
what it would take.
We could very well use standard DI to export the service-overrides
from our custom expansions module. plexus annotations should do quite
nicely. This would leave us with how does this get injected problem.
As I mentioned, I don't think dependencies within the plugin section
work straight our of the box.
It would probably be *simplest* to require single-module per extension
since you could then avoid polluting plugin classloaders with stuff
from the wrong plugin. from a users perspective it might make a lot
of sense to put something like maven-assembly-plugin-client-api and
surefire-client-api as s dependency to a single module called
maven-extensions, but then we'd be loading surefire-client-api and
other deps into the maven-assembly-plugin classloader; which sounds
like a very bad idea.
So if we stick with 1:1 extension-plugin, all we'd need is some way
to pick up the impl...
K
2015-01-14 13:18 GMT+01:00 Benson Margulies bimargul...@gmail.com:
yes, let's please decouple 'how do we get more code into the
classspath'
from 'how to we tell a plugin to use the code.'
For the first, we have the plugin's dependencies.
For the second, well, don't we have plexus component injection?
Obviously,
there are more modern alternatives, but shouldn't we bite that bullet
globally if we are going to bite it at all?
-
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
--
--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+
Re: Plugable/Softcoded/Customized Maven Plugins
We have been discussing this in the context of surefire, which uses these extension mechanisms, so both Tibor, Andreas and I are fully aware of what is possible. And as Jason says, there is a spectrum. I'm not sure how the line would be drawn, since ant is very free-form while gradle is opinionated free form; they have an idea of a lifecycle like we do. I think the root problem I personally want to solve is avoiding monolithic plugins that puts every single maintenance need in our hands and makes our mojos increasingly large and overlapping. In such a context I would like a nice mechanism for user extensibility that can be applied in lots of places; I could easily see large plugins like assembly or surefire providing 20-100 extension points each. Maybe maven core would need support for this, maybe just a toolbox plugins can use - I've been pondering various alternatives. On one extreme it would be possible to just keep the consumer pom and move everything else to a scripted file; it would not be too hard and actually fairly compatible. I'm not necessarily advocating such a solution. But I suppose this is where the initial disagreement starts. If you want to keep your users from writing code that interacts with the build or insist that they don the appropriate robes before doing so (require a separate project and all that), we are simply not in the same school of thought. I agree with Igor and others that build tooling is a different mode than end user code, so I also tend to think that just picking up stuff that is littered in test scope in various random projects is not a good idea. There are a ton of different approaches that could be used to do something like this: Making a separate project is only one of them. You could put extensions in src/build/plugin-[execution].[bsh|groovy|fortran||scala] and just have them execute as a post-init script on the plugin. Plugins could even do that themselves without any assistance from core (but it would get better with core support), just a small helper library that invokes the proper language runtime. There might be one or two practical problems with this approach, but nothing unsolvable. I would find it logical that there might be *multiple* strategies for doing this, supporting scripting, in-project module and external-module. m2e is here because of maven, not the other way around. But I do believe in re-using the good stuff we have, which is why in-project module is my personal favourite since it has a very low footprint. I might be several years too late for this whole ordeal. It might even be that I'm just reinventing gradle. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
Maybe Jason can bring some light into this discussion. Jason? -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.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: Plugable/Softcoded/Customized Maven Plugins
Surefire is in a special case, because surefire makes its own classloader, in fact several of them. So theoretically you could dump a blob of smalltalk into the config section of pom.xml and fire up embedded smalltalk inside the plugin (or maybe cobol =:-). For the single case that is surefire, anything can be done. All of this could be implemented in surefire in an afternoon of hacking. I'm not particulary fond of this solution, for several reasons. Firstly it is surefire-only. And we're not leveraging maven's existing strengths very well and we'd be loosing a ton of tool support. I have built a strong dislike for creating lots of micro-contexts that can be used to run particular DSL-code, like the verify-code in maven-in-invoker. What's on that classpath, really ? With a distinct module you leverage all the things we have that are good. The classpath of that module is effectively imported into the plugin, you can yourself control any dependencies. You also control the language in use. If you choose a language with decent tool support you may get intellisense and full IDE support for the available features in the module you have defined; the extension points just roll down with autocomplete and javadocs all at hand. You could also get access to the plugin's configuration section. Possibly you could even just add custom settings for your extension. I don't have all the answers here; I've been thinking about this stuff for several years and it's not entirely clear how this can be improved and still remain the same product; dumping a ton of code into pom.xml will only make us a bad gradle-imitation :) You could dump a plugin-execution.[groovy|scala|clojure] right beside pom.xml and just strap up groovy/scala/clojure for that execution and run it. If you accept that such a script runs in the plugins class realm you could be pretty much done. And that clojure script could contain plexus annotations and those components *could* be made available for late-bound lookup. Hmpf. Kristian 2015-01-14 19:04 GMT+01:00 Tibor Digana tibordig...@apache.org: Kristian, i cannot imaging how will be customizing a dependency extension. For instance each module should change the runOrder differently. Should I then build tons of module extension for each project separately? The extension code should be in src/test/java or another module, but both cases should be supported. As i understood the plugin's classpath does not have test classes, then there must be an additional ClassLoader to proxy the plugin's ClassLoader and to load the MOJO AbstractSurefireMojo.class and make injection of @parameters on new proxy instance again, or? Is it possible to extend the Classworld ClassLoader in plugin runtime? -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823548.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: Plugable/Softcoded/Customized Maven Plugins
, but DSL languages is just only a fancy feature which does not solve our major problem. Basically the users claim that our MOJO plugin parameters should have: + different system properties + different default values + different data format + different handling of MOJO parameters + system properties are empty strings and some users like it and some other want to interpret them as NULL etc. This means that Maven core is setting these parameters and the user should override them. Some users want to modify our code much deeply, even in different class loader or in forked jvm + RunOrder, + classes Streamer, + tests-list processor + TestNG Listener and workaround TestNG 6.0 bugs (reopened bug in GitHub I could not accept because it's not our bug, and therefore changing surefire listener may break other users which is maybe okay for the guy who reported the issue in GitHub. And he is playing the game with me and pushing me with reopened bugs, funny :) ) I am not sure, but to me it looks like the Classworld CL should be parent for another CL creating an instance of plugin MOJO SurefirePlugin.class extended by users class because he should be able to control the injected @Parameter(). I have no idea how to do that and maybe Maven has already some hooks for that. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823565.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: Plugable/Softcoded/Customized Maven Plugins
2015-01-15 4:48 GMT+01:00 Igor Fedorenko i...@ifedorenko.com: Although I generally *strongly* discourage resolution of plugins and plugin dependencies from the reactor Why ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
There's a lot of issues in our issue tracker, not all of them should be solved by such an extension mechanism. So while for instance interpolation to NULL is a commonly requested feature, it'd probably be smarter to just fix the problem in interpolation than to make a whole new feature just so someone can sett a value==null. I'm not looking for a silver bullet to rule them all. I believe this is one of the things gradle got right: A strong project structure and a clear default lifecycle where it's easy to modify behaviour. By making plugins effectively closed for extension I think we are too rigid. While forking a plugin certainly has gotten easier, it's not really what we want either. Kristian 2015-01-14 23:33 GMT+01:00 Tibor Digana tibordig...@apache.org: , but DSL languages is just only a fancy feature which does not solve our major problem. Basically the users claim that our MOJO plugin parameters should have: + different system properties + different default values + different data format + different handling of MOJO parameters + system properties are empty strings and some users like it and some other want to interpret them as NULL etc. This means that Maven core is setting these parameters and the user should override them. Some users want to modify our code much deeply, even in different class loader or in forked jvm + RunOrder, + classes Streamer, + tests-list processor + TestNG Listener and workaround TestNG 6.0 bugs (reopened bug in GitHub I could not accept because it's not our bug, and therefore changing surefire listener may break other users which is maybe okay for the guy who reported the issue in GitHub. And he is playing the game with me and pushing me with reopened bugs, funny :) ) I am not sure, but to me it looks like the Classworld CL should be parent for another CL creating an instance of plugin MOJO SurefirePlugin.class extended by users class because he should be able to control the injected @Parameter(). I have no idea how to do that and maybe Maven has already some hooks for that. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823565.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: Plugable/Softcoded/Customized Maven Plugins
Although I generally *strongly* discourage resolution of plugins and plugin dependencies from the reactor, it is expected to work with maven 3.0+ for regular extensions=false plugins. If you have a testcase when it does not work, I can have a look. -- Regards, Igor On 2015-01-14 10:10, Kristian Rosenvold wrote: It is only inconvenient because maven cannot resolve the artifact from the current reactor, or at least it was not able to when I made testcases for this for surefire-providers. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
On Wed, Jan 14, 2015 at 10:10 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
It is only inconvenient because maven cannot resolve the artifact from
the current reactor, or at least it was not able to when I made
testcases for this for surefire-providers.
OK, now I'm with you.
This means the extension has to be in a separate project and
built/deployed entirely separate module; this is an annoyance because
immediacy and user-accessibility is a key value in such stuff. I want
some of these extensions to be in my code base and to actually work
when I attach a debugger. Using modules deployed to central/some other
repo is also cool, but I really think we need to serve the here and
now case.
So if I put the extension in my current project I will have to build
that extension specifically with mvn -N the first time, since it does
not exist somewhere it can be resolved. And I will always be using the
previous version when I build
Kristian
2015-01-14 15:15 GMT+01:00 Benson Margulies bimargul...@gmail.com:
So, I'm confused as to why asking people to add jars to the
dependencies/
of a plugin/ is seen as annoying or inconvenient. Can you deconfuse me?
On Wed, Jan 14, 2015 at 8:19 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
If we additionaly look for a solution that would work straight out of
the box for maven 3.0, the plugin could actually just use some kind of
loader library that would load/detect the supplied artifact into the
plugin classloader and use lazy container lookup logic when resolving
the user-supplied service. In that way you'd end up with something
like this:
DiscoveryService.findExtensions(); // Do something magic which loads
jar in plugin classloader
RunOrderSorter userSupplied = container.lookup(RunOrderSorter.class);
if (userSupplied != null) {
// Use usersupplied
}
Now all we'd have to do was put RunOrderSorter in a client-api
module, and we could load it at will. We just need an implementation
for the Do something magic bit above
This
2015-01-14 13:43 GMT+01:00 Kristian Rosenvold
kristian.rosenv...@gmail.com:
Agreed Benson; I find it very interesting to reduce this problem
initially, then we can grow it afterwards once we sort of understand
what it would take.
We could very well use standard DI to export the service-overrides
from our custom expansions module. plexus annotations should do quite
nicely. This would leave us with how does this get injected problem.
As I mentioned, I don't think dependencies within the plugin section
work straight our of the box.
It would probably be *simplest* to require single-module per extension
since you could then avoid polluting plugin classloaders with stuff
from the wrong plugin. from a users perspective it might make a lot
of sense to put something like maven-assembly-plugin-client-api and
surefire-client-api as s dependency to a single module called
maven-extensions, but then we'd be loading surefire-client-api and
other deps into the maven-assembly-plugin classloader; which sounds
like a very bad idea.
So if we stick with 1:1 extension-plugin, all we'd need is some way
to pick up the impl...
K
2015-01-14 13:18 GMT+01:00 Benson Margulies bimargul...@gmail.com:
yes, let's please decouple 'how do we get more code into the
classspath'
from 'how to we tell a plugin to use the code.'
For the first, we have the plugin's dependencies.
For the second, well, don't we have plexus component injection?
Obviously,
there are more modern alternatives, but shouldn't we bite that bullet
globally if we are going to bite it at all?
-
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: Plugable/Softcoded/Customized Maven Plugins
It is only inconvenient because maven cannot resolve the artifact from
the current reactor, or at least it was not able to when I made
testcases for this for surefire-providers.
This means the extension has to be in a separate project and
built/deployed entirely separate module; this is an annoyance because
immediacy and user-accessibility is a key value in such stuff. I want
some of these extensions to be in my code base and to actually work
when I attach a debugger. Using modules deployed to central/some other
repo is also cool, but I really think we need to serve the here and
now case.
So if I put the extension in my current project I will have to build
that extension specifically with mvn -N the first time, since it does
not exist somewhere it can be resolved. And I will always be using the
previous version when I build
Kristian
2015-01-14 15:15 GMT+01:00 Benson Margulies bimargul...@gmail.com:
So, I'm confused as to why asking people to add jars to the dependencies/
of a plugin/ is seen as annoying or inconvenient. Can you deconfuse me?
On Wed, Jan 14, 2015 at 8:19 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
If we additionaly look for a solution that would work straight out of
the box for maven 3.0, the plugin could actually just use some kind of
loader library that would load/detect the supplied artifact into the
plugin classloader and use lazy container lookup logic when resolving
the user-supplied service. In that way you'd end up with something
like this:
DiscoveryService.findExtensions(); // Do something magic which loads
jar in plugin classloader
RunOrderSorter userSupplied = container.lookup(RunOrderSorter.class);
if (userSupplied != null) {
// Use usersupplied
}
Now all we'd have to do was put RunOrderSorter in a client-api
module, and we could load it at will. We just need an implementation
for the Do something magic bit above
This
2015-01-14 13:43 GMT+01:00 Kristian Rosenvold
kristian.rosenv...@gmail.com:
Agreed Benson; I find it very interesting to reduce this problem
initially, then we can grow it afterwards once we sort of understand
what it would take.
We could very well use standard DI to export the service-overrides
from our custom expansions module. plexus annotations should do quite
nicely. This would leave us with how does this get injected problem.
As I mentioned, I don't think dependencies within the plugin section
work straight our of the box.
It would probably be *simplest* to require single-module per extension
since you could then avoid polluting plugin classloaders with stuff
from the wrong plugin. from a users perspective it might make a lot
of sense to put something like maven-assembly-plugin-client-api and
surefire-client-api as s dependency to a single module called
maven-extensions, but then we'd be loading surefire-client-api and
other deps into the maven-assembly-plugin classloader; which sounds
like a very bad idea.
So if we stick with 1:1 extension-plugin, all we'd need is some way
to pick up the impl...
K
2015-01-14 13:18 GMT+01:00 Benson Margulies bimargul...@gmail.com:
yes, let's please decouple 'how do we get more code into the classspath'
from 'how to we tell a plugin to use the code.'
For the first, we have the plugin's dependencies.
For the second, well, don't we have plexus component injection?
Obviously,
there are more modern alternatives, but shouldn't we bite that bullet
globally if we are going to bite it at all?
-
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: Plugable/Softcoded/Customized Maven Plugins
Bensons' question should not be forgotten and should be answered, but I would like to remark on Kristian's code because I see OSGi services. I like the osgi principle more than SPI. The SPI is calling client service impl, but here client is calling osgi/surefire service. I know Maven is not on the top of OSGi -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823531.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: Plugable/Softcoded/Customized Maven Plugins
Kristian, i cannot imaging how will be customizing a dependency extension. For instance each module should change the runOrder differently. Should I then build tons of module extension for each project separately? The extension code should be in src/test/java or another module, but both cases should be supported. As i understood the plugin's classpath does not have test classes, then there must be an additional ClassLoader to proxy the plugin's ClassLoader and to load the MOJO AbstractSurefireMojo.class and make injection of @parameters on new proxy instance again, or? Is it possible to extend the Classworld ClassLoader in plugin runtime? -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823548.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: Plugable/Softcoded/Customized Maven Plugins
On Wed, Jan 14, 2015 at 1:04 PM, Tibor Digana tibordig...@apache.org wrote: Kristian, i cannot imaging how will be customizing a dependency extension. For instance each module should change the runOrder differently. Should I then build tons of module extension for each project separately? The extension code should be in src/test/java or another module, but both cases should be supported. As i understood the plugin's classpath does not have test classes, then there must be an additional ClassLoader to proxy the plugin's ClassLoader and to load the MOJO AbstractSurefireMojo.class and make injection of @parameters on new proxy instance again, or? Is it possible to extend the Classworld ClassLoader in plugin runtime? So, I think I'm seeing another consideration here. If I read Tibor correctly, he does not like the need to build a whole java class in a jar file (or maybe just a jar file?) to express some small customization. But, at the same time, some of us would not be happy to be mixing Maven-specific code into the middle of the test source code, since in some environments it has to work in Maven and also in ant or something else. This highlights the Groovy idea -- or at least the idea of a DSL that can be directly typed into the POM, which avoids both. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823548.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: Plugable/Softcoded/Customized Maven Plugins
If we additionaly look for a solution that would work straight out of
the box for maven 3.0, the plugin could actually just use some kind of
loader library that would load/detect the supplied artifact into the
plugin classloader and use lazy container lookup logic when resolving
the user-supplied service. In that way you'd end up with something
like this:
DiscoveryService.findExtensions(); // Do something magic which loads
jar in plugin classloader
RunOrderSorter userSupplied = container.lookup(RunOrderSorter.class);
if (userSupplied != null) {
// Use usersupplied
}
Now all we'd have to do was put RunOrderSorter in a client-api
module, and we could load it at will. We just need an implementation
for the Do something magic bit above
This
2015-01-14 13:43 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com:
Agreed Benson; I find it very interesting to reduce this problem
initially, then we can grow it afterwards once we sort of understand
what it would take.
We could very well use standard DI to export the service-overrides
from our custom expansions module. plexus annotations should do quite
nicely. This would leave us with how does this get injected problem.
As I mentioned, I don't think dependencies within the plugin section
work straight our of the box.
It would probably be *simplest* to require single-module per extension
since you could then avoid polluting plugin classloaders with stuff
from the wrong plugin. from a users perspective it might make a lot
of sense to put something like maven-assembly-plugin-client-api and
surefire-client-api as s dependency to a single module called
maven-extensions, but then we'd be loading surefire-client-api and
other deps into the maven-assembly-plugin classloader; which sounds
like a very bad idea.
So if we stick with 1:1 extension-plugin, all we'd need is some way
to pick up the impl...
K
2015-01-14 13:18 GMT+01:00 Benson Margulies bimargul...@gmail.com:
yes, let's please decouple 'how do we get more code into the classspath'
from 'how to we tell a plugin to use the code.'
For the first, we have the plugin's dependencies.
For the second, well, don't we have plexus component injection? Obviously,
there are more modern alternatives, but shouldn't we bite that bullet
globally if we are going to bite it at all?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
I've always been thinking we'd pick such stuff up from somewhere. For surefire I've always figured test scope. Wouldn't it be better to get it from the classpath of the mojo execution? i.e. it should be added as a dep to the plugin declaration. /Anders A more general solution would perhaps be to permit an entire module in a multi-module build to contain extension mechanisms; so such a module could add dependencies to the public api of the plugin and thereby gain access to a set of extension points. Kristian 2015-01-14 11:58 GMT+01:00 Tibor Digana tibordig...@apache.org: Hi Kristian, Igor, I think i have found the way to inject custom objects into plugin execution without SPI. Look at this example http://docs.codehaus.org/display/GMAVENPLUS/Examples#Examples-ExecuteScripts The user can write a trivial script launched like this and write a RunOrder servis by setting it in to execution property: someScript.groovy hook.set(new RunOrder()); Tha's it, very simple. All we need to do is to provide the execution property 'hook' - the name is just for illustration purposes only. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823467.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: Plugable/Softcoded/Customized Maven Plugins
Hi Kristian, Igor, I think i have found the way to inject custom objects into plugin execution without SPI. Look at this example http://docs.codehaus.org/display/GMAVENPLUS/Examples#Examples-ExecuteScripts The user can write a trivial script launched like this and write a RunOrder servis by setting it in to execution property: someScript.groovy hook.set(new RunOrder()); Tha's it, very simple. All we need to do is to provide the execution property 'hook' - the name is just for illustration purposes only. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823467.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: Plugable/Softcoded/Customized Maven Plugins
You mean putting script code in cdata sections in the pom ? Sounds pretty old-school to me, don't think thats the way to go. I've always been thinking we'd pick such stuff up from somewhere. For surefire I've always figured test scope. A more general solution would perhaps be to permit an entire module in a multi-module build to contain extension mechanisms; so such a module could add dependencies to the public api of the plugin and thereby gain access to a set of extension points. Kristian 2015-01-14 11:58 GMT+01:00 Tibor Digana tibordig...@apache.org: Hi Kristian, Igor, I think i have found the way to inject custom objects into plugin execution without SPI. Look at this example http://docs.codehaus.org/display/GMAVENPLUS/Examples#Examples-ExecuteScripts The user can write a trivial script launched like this and write a RunOrder servis by setting it in to execution property: someScript.groovy hook.set(new RunOrder()); Tha's it, very simple. All we need to do is to provide the execution property 'hook' - the name is just for illustration purposes only. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823467.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: Plugable/Softcoded/Customized Maven Plugins
Adding dependencies to plugin in user's POM is old school for me, because this is static code. Look at Gradle they use script so it cannot be old school. Ask the Maven Users group and give them two things to choose: + static plugin dependencies + dynamic extension via scripts In my f*g company we have surefire plugin and all plugins in top parent POM with configuration stuff and dependencies. This way I cannot customize my project because i don't have rights to change top parent POM. I cannot say this module has this extension, this and this another because the POM is static. But if I had script, I could write a trivial code there, or more complicated code in Java which appears in particular module or elsewhere and the script would becomes a reference to my object. That's flexibility. Even with script is better because the Surefire Users already reported JIRA bug that they want to customize surefire dependencies per execution. With static POM this is not possible. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823485.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: Plugable/Softcoded/Customized Maven Plugins
2015-01-14 12:48 GMT+01:00 Anders Hammar and...@hammar.net: Wouldn't it be better to get it from the classpath of the mojo execution? i.e. it should be added as a dep to the plugin declaration. That's pretty much the way we do it today with providers in surefire. If we exported a distinct client-api module from the plugin you could actually depend on this in a pluginextension module within your own build and implement all kinds of custom features. It might even be possible to depend on multiple client-api definitions within a single module and hence collect extension points to multiple plugins within that single project (maybe - there may be some gotchas). The implementation module itself can be in any language. The only problem with this is that I seem to remember we couldn't build a surefire provider within the same reactor as we actually used it, since the resolution order does not permit this. From a point of view of simple extensibility, that does not work entirely well. And there's still the issue of service discovery. Kristian In a sense, if you make a separate module called pluginextension you coul /Anders A more general solution would perhaps be to permit an entire module in a multi-module build to contain extension mechanisms; so such a module could add dependencies to the public api of the plugin and thereby gain access to a set of extension points. Kristian 2015-01-14 11:58 GMT+01:00 Tibor Digana tibordig...@apache.org: Hi Kristian, Igor, I think i have found the way to inject custom objects into plugin execution without SPI. Look at this example http://docs.codehaus.org/display/GMAVENPLUS/Examples#Examples-ExecuteScripts The user can write a trivial script launched like this and write a RunOrder servis by setting it in to execution property: someScript.groovy hook.set(new RunOrder()); Tha's it, very simple. All we need to do is to provide the execution property 'hook' - the name is just for illustration purposes only. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823467.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
Anders; we are discussing how the maven owl can support /both/ shotgun *and* BFG9000 :) I sense there's small adjustments we could make somewhere that could make the plugin model less monolithic. K 2015-01-14 13:13 GMT+01:00 Anders Hammar and...@hammar.net: In my f*g company we have surefire plugin and all plugins in top parent POM with configuration stuff and dependencies. This way I cannot customize my project because i don't have rights to change top parent POM. I cannot say this module has this extension, this and this another because the POM is static. Sure you can. Just specify the artifact as a dep to the plugin in that module and it will be added to the mojo's classpath (in addition to anything specified in parent). IMHO this is the Maven way. And if you don't follow it the Maven owl will grab it's shotgun and hunt you down...:-) /Anders But if I had script, I could write a trivial code there, or more complicated code in Java which appears in particular module or elsewhere and the script would becomes a reference to my object. That's flexibility. Even with script is better because the Surefire Users already reported JIRA bug that they want to customize surefire dependencies per execution. With static POM this is not possible. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823485.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: Plugable/Softcoded/Customized Maven Plugins
yes, let's please decouple 'how do we get more code into the classspath' from 'how to we tell a plugin to use the code.' For the first, we have the plugin's dependencies. For the second, well, don't we have plexus component injection? Obviously, there are more modern alternatives, but shouldn't we bite that bullet globally if we are going to bite it at all?
Re: Plugable/Softcoded/Customized Maven Plugins
In my f*g company we have surefire plugin and all plugins in top parent POM with configuration stuff and dependencies. This way I cannot customize my project because i don't have rights to change top parent POM. I cannot say this module has this extension, this and this another because the POM is static. Sure you can. Just specify the artifact as a dep to the plugin in that module and it will be added to the mojo's classpath (in addition to anything specified in parent). IMHO this is the Maven way. And if you don't follow it the Maven owl will grab it's shotgun and hunt you down...:-) /Anders But if I had script, I could write a trivial code there, or more complicated code in Java which appears in particular module or elsewhere and the script would becomes a reference to my object. That's flexibility. Even with script is better because the Surefire Users already reported JIRA bug that they want to customize surefire dependencies per execution. With static POM this is not possible. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823485.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: Plugable/Softcoded/Customized Maven Plugins
Agreed Benson; I find it very interesting to reduce this problem initially, then we can grow it afterwards once we sort of understand what it would take. We could very well use standard DI to export the service-overrides from our custom expansions module. plexus annotations should do quite nicely. This would leave us with how does this get injected problem. As I mentioned, I don't think dependencies within the plugin section work straight our of the box. It would probably be *simplest* to require single-module per extension since you could then avoid polluting plugin classloaders with stuff from the wrong plugin. from a users perspective it might make a lot of sense to put something like maven-assembly-plugin-client-api and surefire-client-api as s dependency to a single module called maven-extensions, but then we'd be loading surefire-client-api and other deps into the maven-assembly-plugin classloader; which sounds like a very bad idea. So if we stick with 1:1 extension-plugin, all we'd need is some way to pick up the impl... K 2015-01-14 13:18 GMT+01:00 Benson Margulies bimargul...@gmail.com: yes, let's please decouple 'how do we get more code into the classspath' from 'how to we tell a plugin to use the code.' For the first, we have the plugin's dependencies. For the second, well, don't we have plexus component injection? Obviously, there are more modern alternatives, but shouldn't we bite that bullet globally if we are going to bite it at all? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
So, I'm confused as to why asking people to add jars to the dependencies/
of a plugin/ is seen as annoying or inconvenient. Can you deconfuse me?
On Wed, Jan 14, 2015 at 8:19 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
If we additionaly look for a solution that would work straight out of
the box for maven 3.0, the plugin could actually just use some kind of
loader library that would load/detect the supplied artifact into the
plugin classloader and use lazy container lookup logic when resolving
the user-supplied service. In that way you'd end up with something
like this:
DiscoveryService.findExtensions(); // Do something magic which loads
jar in plugin classloader
RunOrderSorter userSupplied = container.lookup(RunOrderSorter.class);
if (userSupplied != null) {
// Use usersupplied
}
Now all we'd have to do was put RunOrderSorter in a client-api
module, and we could load it at will. We just need an implementation
for the Do something magic bit above
This
2015-01-14 13:43 GMT+01:00 Kristian Rosenvold
kristian.rosenv...@gmail.com:
Agreed Benson; I find it very interesting to reduce this problem
initially, then we can grow it afterwards once we sort of understand
what it would take.
We could very well use standard DI to export the service-overrides
from our custom expansions module. plexus annotations should do quite
nicely. This would leave us with how does this get injected problem.
As I mentioned, I don't think dependencies within the plugin section
work straight our of the box.
It would probably be *simplest* to require single-module per extension
since you could then avoid polluting plugin classloaders with stuff
from the wrong plugin. from a users perspective it might make a lot
of sense to put something like maven-assembly-plugin-client-api and
surefire-client-api as s dependency to a single module called
maven-extensions, but then we'd be loading surefire-client-api and
other deps into the maven-assembly-plugin classloader; which sounds
like a very bad idea.
So if we stick with 1:1 extension-plugin, all we'd need is some way
to pick up the impl...
K
2015-01-14 13:18 GMT+01:00 Benson Margulies bimargul...@gmail.com:
yes, let's please decouple 'how do we get more code into the classspath'
from 'how to we tell a plugin to use the code.'
For the first, we have the plugin's dependencies.
For the second, well, don't we have plexus component injection?
Obviously,
there are more modern alternatives, but shouldn't we bite that bullet
globally if we are going to bite it at all?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
Hoping this is not the end of surefire/failsafe plugin nor Maven. Yeah, my impression from Maven is that it is static however introduced regular practices, the users hit us with many requests. For me it means that I try to handle the request immediately in JIRA and resolve it. It gives me chance to understand the user and to be synchronized with him which is positive but the same work will cut my private time. We decreased the #bug quite a lot, but it's clear to me that it's not very user friendly communication to ask me for making a new hack and therefore my impression is that it was good style 10 years ago, but today the situation is different we should really uncover the API in a convenient way for the users. My impression is same for Maven core and default Maven plugins as well. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823391.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: Plugable/Softcoded/Customized Maven Plugins
Hi Igor, I know that you are working on JDT and you probably want to synchronize your activity with ours, but we don't have access API yet. Everything is in our heads. We have only the standard surefire-api. As we speak via email with Kristian, our current problem problem is the injection and descovery of users classes implementing access interfaces. My proposal was SPI, but it is old after Java 6. We wanted Java 8 enhancements around interfaces, but we cannot make any injection of specific classes from users code to surefire. With SPI it is possible and very easy, but nothing more modern and same simple presents to substitute SPI. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823374.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: Plugable/Softcoded/Customized Maven Plugins
Igor, can we join our visions and design together regarding compiler and surefire ? I guess we need to write a list of requirements. Later we will find possible solutions for each + API. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823378.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: Plugable/Softcoded/Customized Maven Plugins
Do you think you can give a couple of representative examples that explain what you are trying to achieve? -- Regards, Igor On 2015-01-13 9:33, Tibor Digana wrote: Hi All, We want to prepare an experimental release of maven-surefire-plugin customizing the plugin behavior. Basically we want to uncover open API and we expect a feedback from Maven users group. We have received many configuration requests in this plugin which increased JIRA issues. We believe that implementing the open API by a user would decrease the overhead in JIRA because everybody will be able to fix or change the plugin behavior. We should of course reach the goals for new Maven core, this means support for an incremental compiler and partial testing the changed tests and dependencies as well as reordering passed-failed tests. I would like to hear from you what types injections of API implemented by user we should introduce. For instance SPI would be the one, Java EE injections demanding but slow, and OSGi services would be a candidate. From my point of view, designing a typical Java API, maybe based on Java 6 would be a good staring point. Then SPI would be the minimum blocker in order to make the first experimental release. Personally I think that changing the behavior via JavaScript, Bash Shell, Groovy will increase the attention in Maven itself. I can imaging that the test' phase may hold on JavaScipt console till exit which allows you to recompile the classes and retest some test methods/classes without building the project again. Cheers Tibor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugable/Softcoded/Customized Maven Plugins
I think my question was not clear. I do not understand the problem you are trying to solve, i.e. user and/or plugin developer usecases that are not (well) supported with the current APIs. This is why I am asking for some representative examples that highlight the problem. I do not suggest or imply that I have an alternative solution or vision, I just want to understand what you are trying to achieve with the new API. -- Regards, Igor On 2015-01-13 10:50, Tibor Digana wrote: Igor, can we join our visions and design together regarding compiler and surefire ? I guess we need to write a list of requirements. Later we will find possible solutions for each + API. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823378.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: Plugable/Softcoded/Customized Maven Plugins
Historically we have implemented all sorts of stuff into surefire, without giving the user appropriate hooks to control the behaviour for herself. One such very simple example is an extensibility point to allow the user to run tests in a specific order they can decide themselves. Another is opening hooks that would allow custom remoting/forking. There used to be quite a lot of these possible features, but over the years a lot of them have just been implemented/added, increasing the footprint (and feature/bug footprint too !) So we have been discussing (in email) if we could modularize the plugin in such a way that default behaviour is cleanly replacable/supplementable via user-supplied hooks. So far we've just been throwing around ideas, and Tibor just brought this discussion to the mailing list. I am not very happy that the plugin is such a monolith. And the way we are closed for user extensions means we'll continue growing. And it's not just surefire. Surefire is a bit special in the context that we have a scope that belongs to surefire. We can pick up stuff from test scope and run it as part of the plugin. Ideally I would really like to think extensibility in this manner for all kinds of plugins. I'd really like somewhere I can just tack in my java8 lambda/or interface implementation and have maven pick it up Kristian 2015-01-13 17:34 GMT+01:00 Igor Fedorenko i...@ifedorenko.com: I think my question was not clear. I do not understand the problem you are trying to solve, i.e. user and/or plugin developer usecases that are not (well) supported with the current APIs. This is why I am asking for some representative examples that highlight the problem. I do not suggest or imply that I have an alternative solution or vision, I just want to understand what you are trying to achieve with the new API. -- Regards, Igor On 2015-01-13 10:50, Tibor Digana wrote: Igor, can we join our visions and design together regarding compiler and surefire ? I guess we need to write a list of requirements. Later we will find possible solutions for each + API. -- View this message in context: http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823378.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
