You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Carson Gross <ca...@gmail.com> on 2012/01/03 05:21:54 UTC
Detecting current phase in a plugin
I'd like to detect the current phase of a build within a plugin's execute()
method. I dug around in the project object and plugin context, but
couldn't find it. Can anyone point me the right direction?
Cheers,
Carson
Re: Detecting current phase in a plugin
Posted by Brett Porter <br...@apache.org>.
It's not possible, but depending on what you want to do there might be other ways to achieve it.
Take a look at:
http://stackoverflow.com/questions/3746585/determining-maven-execution-phase-within-a-plugin
On 03/01/2012, at 3:21 PM, Carson Gross wrote:
> I'd like to detect the current phase of a build within a plugin's execute()
> method. I dug around in the project object and plugin context, but
> couldn't find it. Can anyone point me the right direction?
>
> Cheers,
> Carson
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Detecting current phase in a plugin
Posted by Carson Gross <ca...@gmail.com>.
Will do, thanks for the references Manfred and Vincent!
Cheers,
Carson
On Tue, Jan 3, 2012 at 9:11 AM, Manfred Moser <ma...@mosabuam.com> wrote:
> For a full working example mapping Maven to a different life cycle with a
> whole bunch of different tasks look at the code of the android maven
> plugin..
>
> manfred
>
>
> On 12-01-03 08:43 AM, Vincent Latombe wrote:
>
>> Hello Carson,
>>
>> you can achieve what you need by defining a new packaging, as described in
>> http://www.sonatype.com/**people/2009/08/create-a-**
>> customized-build-process-in-**maven/<http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/>
>>
>> Vincent
>>
>>
>> 2012/1/3 Carson Gross<ca...@gmail.com>
>>
>> Yes, it appears that I have a different mental model for plugins than
>>> Maven
>>> provides. Let me explain what I'm trying to accomplish, and perhaps a
>>> better high-level approach is available:
>>>
>>> I work on Gosu (http://gosu-lang.org) a small language for the JVM. Me
>>> and
>>> a few other guys are trying to get Gosu to play well with Maven.
>>> Unfortunately for us, Gosu has a slightly different compilation model
>>> than
>>> Java: it is source based and lazily compiled, like many scripting
>>> languages. We don't (currently) generate .class files, rather we compile
>>> and load them dynamically at runtime.
>>>
>>> Our goal with our Maven plugin is to make Gosu participate, as
>>> transparently as possible, with the various Maven phases, given that
>>> constraint. Ideally, we would hook into the compile phase (the
>>> equivalent
>>> in Gosu would be to verify the source), the test phase (sounds like we
>>> the
>>> surefire API may make this easy/possible), etc.
>>>
>>> The way I was thinking about it, I'd prefer the user to not have to
>>> configure our plugin for any phases at all: I'd just want them to say
>>> something like this:
>>>
>>> <plugins>
>>> <plugin>
>>> <groupId>org.gosu-lang</**groupId>
>>> <artifactId>maven-gosu-plugin<**/artifactId>
>>> <version>1.0</version>
>>> <configuration>
>>> <gosuVersion>0.9-SNAPSHOT</**gosuVersion>
>>> </configuration>
>>> </plugin>
>>> </plugins>
>>>
>>> And never have to mention phases or goals at all, and let the plugin wire
>>> itself in to the appropriate places to make gosu work.
>>>
>>> So that's what I'm trying to accomplish, and, as a total Maven noob, I'm
>>> happy to hear suggestions, clarifications of my language or other
>>> thoughts.
>>>
>>> Thanks,
>>> Carson
>>>
>>> On Tue, Jan 3, 2012 at 1:36 AM, Jochen Wiedmann
>>> <jo...@gmail.com>**wrote:
>>>
>>> Sure you really want to do that? It would amount to hard wiring your
>>>> plugin to a certain phase, whereas
>>>> a plugin should typically be able to run in any phase, depending on the
>>>> POM.
>>>>
>>>>
>>>> On Tue, Jan 3, 2012 at 5:21 AM, Carson Gross<ca...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'd like to detect the current phase of a build within a plugin's
>>>>>
>>>> execute()
>>>>
>>>>> method. I dug around in the project object and plugin context, but
>>>>> couldn't find it. Can anyone point me the right direction?
>>>>>
>>>>> Cheers,
>>>>> Carson
>>>>>
>>>>
>>>>
>>>> --
>>>> "Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja
>>>> Buchung."
>>>> Dieter Hildebrandt
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Detecting current phase in a plugin
Posted by Manfred Moser <ma...@mosabuam.com>.
For a full working example mapping Maven to a different life cycle with
a whole bunch of different tasks look at the code of the android maven
plugin..
manfred
On 12-01-03 08:43 AM, Vincent Latombe wrote:
> Hello Carson,
>
> you can achieve what you need by defining a new packaging, as described in
> http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/
>
> Vincent
>
>
> 2012/1/3 Carson Gross<ca...@gmail.com>
>
>> Yes, it appears that I have a different mental model for plugins than Maven
>> provides. Let me explain what I'm trying to accomplish, and perhaps a
>> better high-level approach is available:
>>
>> I work on Gosu (http://gosu-lang.org) a small language for the JVM. Me
>> and
>> a few other guys are trying to get Gosu to play well with Maven.
>> Unfortunately for us, Gosu has a slightly different compilation model than
>> Java: it is source based and lazily compiled, like many scripting
>> languages. We don't (currently) generate .class files, rather we compile
>> and load them dynamically at runtime.
>>
>> Our goal with our Maven plugin is to make Gosu participate, as
>> transparently as possible, with the various Maven phases, given that
>> constraint. Ideally, we would hook into the compile phase (the equivalent
>> in Gosu would be to verify the source), the test phase (sounds like we the
>> surefire API may make this easy/possible), etc.
>>
>> The way I was thinking about it, I'd prefer the user to not have to
>> configure our plugin for any phases at all: I'd just want them to say
>> something like this:
>>
>> <plugins>
>> <plugin>
>> <groupId>org.gosu-lang</groupId>
>> <artifactId>maven-gosu-plugin</artifactId>
>> <version>1.0</version>
>> <configuration>
>> <gosuVersion>0.9-SNAPSHOT</gosuVersion>
>> </configuration>
>> </plugin>
>> </plugins>
>>
>> And never have to mention phases or goals at all, and let the plugin wire
>> itself in to the appropriate places to make gosu work.
>>
>> So that's what I'm trying to accomplish, and, as a total Maven noob, I'm
>> happy to hear suggestions, clarifications of my language or other thoughts.
>>
>> Thanks,
>> Carson
>>
>> On Tue, Jan 3, 2012 at 1:36 AM, Jochen Wiedmann
>> <jo...@gmail.com>wrote:
>>
>>> Sure you really want to do that? It would amount to hard wiring your
>>> plugin to a certain phase, whereas
>>> a plugin should typically be able to run in any phase, depending on the
>>> POM.
>>>
>>>
>>> On Tue, Jan 3, 2012 at 5:21 AM, Carson Gross<ca...@gmail.com>
>>> wrote:
>>>> I'd like to detect the current phase of a build within a plugin's
>>> execute()
>>>> method. I dug around in the project object and plugin context, but
>>>> couldn't find it. Can anyone point me the right direction?
>>>>
>>>> Cheers,
>>>> Carson
>>>
>>>
>>> --
>>> "Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja
>>> Buchung."
>>> Dieter Hildebrandt
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Detecting current phase in a plugin
Posted by Vincent Latombe <vi...@gmail.com>.
Hello Carson,
you can achieve what you need by defining a new packaging, as described in
http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/
Vincent
2012/1/3 Carson Gross <ca...@gmail.com>
> Yes, it appears that I have a different mental model for plugins than Maven
> provides. Let me explain what I'm trying to accomplish, and perhaps a
> better high-level approach is available:
>
> I work on Gosu (http://gosu-lang.org) a small language for the JVM. Me
> and
> a few other guys are trying to get Gosu to play well with Maven.
> Unfortunately for us, Gosu has a slightly different compilation model than
> Java: it is source based and lazily compiled, like many scripting
> languages. We don't (currently) generate .class files, rather we compile
> and load them dynamically at runtime.
>
> Our goal with our Maven plugin is to make Gosu participate, as
> transparently as possible, with the various Maven phases, given that
> constraint. Ideally, we would hook into the compile phase (the equivalent
> in Gosu would be to verify the source), the test phase (sounds like we the
> surefire API may make this easy/possible), etc.
>
> The way I was thinking about it, I'd prefer the user to not have to
> configure our plugin for any phases at all: I'd just want them to say
> something like this:
>
> <plugins>
> <plugin>
> <groupId>org.gosu-lang</groupId>
> <artifactId>maven-gosu-plugin</artifactId>
> <version>1.0</version>
> <configuration>
> <gosuVersion>0.9-SNAPSHOT</gosuVersion>
> </configuration>
> </plugin>
> </plugins>
>
> And never have to mention phases or goals at all, and let the plugin wire
> itself in to the appropriate places to make gosu work.
>
> So that's what I'm trying to accomplish, and, as a total Maven noob, I'm
> happy to hear suggestions, clarifications of my language or other thoughts.
>
> Thanks,
> Carson
>
> On Tue, Jan 3, 2012 at 1:36 AM, Jochen Wiedmann
> <jo...@gmail.com>wrote:
>
> > Sure you really want to do that? It would amount to hard wiring your
> > plugin to a certain phase, whereas
> > a plugin should typically be able to run in any phase, depending on the
> > POM.
> >
> >
> > On Tue, Jan 3, 2012 at 5:21 AM, Carson Gross <ca...@gmail.com>
> > wrote:
> > > I'd like to detect the current phase of a build within a plugin's
> > execute()
> > > method. I dug around in the project object and plugin context, but
> > > couldn't find it. Can anyone point me the right direction?
> > >
> > > Cheers,
> > > Carson
> >
> >
> >
> > --
> > "Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja
> > Buchung."
> > Dieter Hildebrandt
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Detecting current phase in a plugin
Posted by Carson Gross <ca...@gmail.com>.
Yes, it appears that I have a different mental model for plugins than Maven
provides. Let me explain what I'm trying to accomplish, and perhaps a
better high-level approach is available:
I work on Gosu (http://gosu-lang.org) a small language for the JVM. Me and
a few other guys are trying to get Gosu to play well with Maven.
Unfortunately for us, Gosu has a slightly different compilation model than
Java: it is source based and lazily compiled, like many scripting
languages. We don't (currently) generate .class files, rather we compile
and load them dynamically at runtime.
Our goal with our Maven plugin is to make Gosu participate, as
transparently as possible, with the various Maven phases, given that
constraint. Ideally, we would hook into the compile phase (the equivalent
in Gosu would be to verify the source), the test phase (sounds like we the
surefire API may make this easy/possible), etc.
The way I was thinking about it, I'd prefer the user to not have to
configure our plugin for any phases at all: I'd just want them to say
something like this:
<plugins>
<plugin>
<groupId>org.gosu-lang</groupId>
<artifactId>maven-gosu-plugin</artifactId>
<version>1.0</version>
<configuration>
<gosuVersion>0.9-SNAPSHOT</gosuVersion>
</configuration>
</plugin>
</plugins>
And never have to mention phases or goals at all, and let the plugin wire
itself in to the appropriate places to make gosu work.
So that's what I'm trying to accomplish, and, as a total Maven noob, I'm
happy to hear suggestions, clarifications of my language or other thoughts.
Thanks,
Carson
On Tue, Jan 3, 2012 at 1:36 AM, Jochen Wiedmann
<jo...@gmail.com>wrote:
> Sure you really want to do that? It would amount to hard wiring your
> plugin to a certain phase, whereas
> a plugin should typically be able to run in any phase, depending on the
> POM.
>
>
> On Tue, Jan 3, 2012 at 5:21 AM, Carson Gross <ca...@gmail.com>
> wrote:
> > I'd like to detect the current phase of a build within a plugin's
> execute()
> > method. I dug around in the project object and plugin context, but
> > couldn't find it. Can anyone point me the right direction?
> >
> > Cheers,
> > Carson
>
>
>
> --
> "Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja
> Buchung."
> Dieter Hildebrandt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Detecting current phase in a plugin
Posted by Jochen Wiedmann <jo...@gmail.com>.
Sure you really want to do that? It would amount to hard wiring your
plugin to a certain phase, whereas
a plugin should typically be able to run in any phase, depending on the POM.
On Tue, Jan 3, 2012 at 5:21 AM, Carson Gross <ca...@gmail.com> wrote:
> I'd like to detect the current phase of a build within a plugin's execute()
> method. I dug around in the project object and plugin context, but
> couldn't find it. Can anyone point me the right direction?
>
> Cheers,
> Carson
--
"Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung."
Dieter Hildebrandt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org