In Flexmojos you have to run the build twice (The first with "minimal" profile 
turned on), because otherwise maven will complain about the plugin not being 
available.
As soon as there is any artifact with that name I am able to build with only 
one run, because the build replaces/updates the plugin in my repo and from then 
on the updated plugin is used.

So I think you are all right.

Chris

-----Ursprüngliche Nachricht-----
Von: Benson Margulies [mailto:bimargul...@gmail.com] 
Gesendet: Dienstag, 11. September 2012 12:17
An: Maven Developers List
Betreff: Re: the simplest possible maven plugin, sort of

On Tue, Sep 11, 2012 at 3:19 AM, Anders Hammar <and...@hammar.net> wrote:
> Switch to Maven 3 and this should work. Try it and report back!

I did and it did.

>
> /Anders
>
> On Mon, Sep 10, 2012 at 11:22 PM, David Jencks <david_jen...@yahoo.com> wrote:
>> Our experience in geronimo has always been that maven does not support this, 
>> and I thought for maven 3 it was announced that it never ever would.
>>
>> We have a proflie to build up through the plugin, then you can do the full 
>> build.
>>
>> Releasing is a pain as you have to do the manual profile build with the 
>> release-version code to get the plugin available in the local maven repo 
>> before running the actual release.
>>
>> If I'm wrong for any version of maven I'd love to know how :-)
>>
>> thanks
>> david jencks
>>
>> On Sep 10, 2012, at 1:45 PM, Daniel Kulp wrote:
>>
>>>
>>> Interesting…  I wonder how I've managed to do CXF releases for all 
>>> these years then.  :-)
>>>
>>> Seriously, for CXF <=2.5.x, I use Maven 2.2.1 and it "just works".   Parts 
>>> of the build certainly do use the plugins that are built as part of the 
>>> reactor.
>>>
>>> That said, we use "install" as the default target and not test or anything. 
>>>   I'm fairly certain it wouldn't work if we didn't use install as the 
>>> target, but I'm not sure if that would work with 3.x either.
>>>
>>> The "clean" target doesn't work if the plugin is part of the reactor and 
>>> not in .m2/repository.   I'll give you that.
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>> On Sep 10, 2012, at 2:59 PM, Anders Hammar <and...@hammar.net> wrote:
>>>
>>>> I'm fairly sure this didn't work in Maven 2.x. It was one of the 
>>>> unsolvable Maven 2.x bugs which was fixed in Maven 3. The 
>>>> workaround would be to use an older released version of the plugin. 
>>>> Don't think running a build twice is/was a workable workaround as I 
>>>> can't see how that would work in a release process.
>>>>
>>>> /Anders
>>>>
>>>> On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier <aherit...@gmail.com> 
>>>> wrote:
>>>>> On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies 
>>>>> <bimargul...@gmail.com>wrote:
>>>>>
>>>>>> On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp <dk...@apache.org> wrote:
>>>>>>>
>>>>>>> On Sep 10, 2012, at 11:14 AM, Benson Margulies 
>>>>>>> <bimargul...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> In Maven 2.x, the following was true; the reactor could not 
>>>>>>>> apply a plugin it had just built. So, if a particular problem 
>>>>>>>> required a plugin (e.g., for generating code), the plugin has 
>>>>>>>> to be an independent project that is built in advance. Is this 
>>>>>>>> still true in 3.x?
>>>>>>>
>>>>>>> I don't think this is/was true.   CXF has always used it's own codegen
>>>>>> plugins within its reactor build, even with Maven 2.x.
>>>>>>
>>>>>> Dan, I'll try it again, but I could have sworn that this only 
>>>>>> works by running 'mvn' twice, so that there's a SNAPSHOT in 
>>>>>> ~/.m2/repository.
>>>>>>
>>>>>
>>>>>
>>>>> I'm almost sure I had the same experience like Benson.
>>>>> It doesn't work in one step because maven reads all projects in 
>>>>> the reactor, then tries to resolve the plugin where you are using 
>>>>> it and cannot because it was built.
>>>>>
>>>>> Arnaud
>>>>
>>>> -------------------------------------------------------------------
>>>> -- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
>>>> additional commands, e-mail: dev-h...@maven.apache.org
>>>>
>>>
>>> --
>>> Daniel Kulp
>>> dk...@apache.org - http://dankulp.com/blog Talend Community Coder - 
>>> http://coders.talend.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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional 
commands, e-mail: dev-h...@maven.apache.org

Reply via email to