Will do, thanks for the references Manfred and Vincent! Cheers, Carson
On Tue, Jan 3, 2012 at 9:11 AM, Manfred Moser <[email protected]> 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<[email protected]> >> >> 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 >>> <[email protected]>**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<[email protected]> >>>> 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: >>>> [email protected].**org<[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
