maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "christofer.dutz@c-ware.de" <christofer.d...@c-ware.de>
Subject AW: the simplest possible maven plugin, sort of
Date Tue, 11 Sep 2012 10:43:49 GMT
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:bimargulies@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 <anders@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_jencks@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 <anders@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 <aheritier@gmail.com>
wrote:
>>>>> On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies <bimargulies@gmail.com>wrote:
>>>>>
>>>>>> On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp <dkulp@apache.org>
wrote:
>>>>>>>
>>>>>>> On Sep 10, 2012, at 11:14 AM, Benson Margulies 
>>>>>>> <bimargulies@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-unsubscribe@maven.apache.org For 
>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - 
>>> http://coders.talend.com
>>>
>>>
>>> --------------------------------------------------------------------
>>> - 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
>>
>
> ---------------------------------------------------------------------
> 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

Mime
View raw message