s 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 T
ons 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
>
tp://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
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 :
> > Al
.
>> 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
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 "opinionate
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 Kristia
cies 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 Diga
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
u 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 wrote:
>>
>>> Maybe Jason can bring some light into this discuss
ou see that actually looking
like? And for what?
> Andreas
>
>
> 2015-01-15 11:57 GMT+01:00 Tibor Digana :
>
>> Maybe Jason can bring some light into this discussion.
>> Jason?
>>
>>
>>
>&g
n 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 arc
> 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.
>
> -
eas
2015-01-15 11:57 GMT+01:00 Tibor Digana :
> 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.htm
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
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-tp5823365p582
2015-01-15 4:48 GMT+01:00 Igor Fedorenko :
> 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
F
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
ected
@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 Nabbl
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-Softcod
his 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
>
ossible 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
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.
--
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 yo
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 annoyan
So, I'm confused as to why asking people to add jars to the
of a 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 bo
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 s
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
nicel
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 w
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.
>>
>>
>>
>> --
gt;
>> > and write a RunOrder servis by setting it in to execution property:
>> >
>> > <>
>> > hook.set(new RunOrder());
>> >
>> > Tha's it, very simple.
>> >
> 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/Plugab
IRA
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 l
>
> > 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.n
t; and write a RunOrder servis by setting it in to execution property:
>
> <>
> 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.
>
om/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
m/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
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://
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
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
odern 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 Nabbl
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
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 t
43 matches
Mail list logo
