geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Migrating geronimo-plugins to M2
Date Tue, 21 Mar 2006 17:07:32 GMT

On Mar 21, 2006, at 5:25 AM, Prasad Kashyap wrote:

> Wait a minute ! Wait a minute !
>
> Except for the deployment plugin, who else outside Geronimo uses our
> other plugins ? Why do we need to support those plugins to run in an
> M1 environment even after we have completely m2-ized our uild ?

The packaging plugin is currently the only "offline deployer".  The  
assembly plugin can be used to construct a customized server  
containing your app(s) and just the modules it needs.  While both of  
these could use a lot of improvement, we need to support this  
functionality on m1, m2, and ant as  well as the command line.  We  
need to find a way to use the same code for all of these build  
environments.

thanks
david jencks

>
> Cheers
> Prasad
>
> On 3/20/06, anita kulshreshtha <a_kulshre@yahoo.com> wrote:
>>    M1 plugins are being kept around for people who
>> want to continue using M1.
>> +1 to option 3
>>
>> Cheers
>> Anita
>>
>> --- Prasad Kashyap <goyathlay.geronimo@gmail.com>
>> wrote:
>>
>>> Ah.. gotcha.  So the existing m1 plugins will
>>> continue to exist but be
>>> built using the M2 build process. We should also
>>> migrate the plugin
>>> such that it can e used (invoked) in an M2
>>> environment. That would
>>> mean making mojos out of them.
>>>
>>> Does it also mean leave the old groupid & artifactid
>>> for the m1
>>> plugins as is ? How will that fit in with our
>>> strategy of our pom
>>> restructuring discussed in Geronimo-1755.
>>>
>>> Cheers
>>> Prasad
>>>
>>> On 3/20/06, John Sisson <jrsisson@gmail.com> wrote:
>>>> Jacek Laskowski wrote:
>>>>> 2006/3/20, Prasad Kashyap
>>> <goyathlay.geronimo@gmail.com>:
>>>>>
>>>>>
>>>>>> As we start migrating the plugins, where do we
>>> drop them ?
>>>>>>
>>>>>> [ ] Option 1: create a new directory for m2
>>> plugins. (eg.
>>>>>> geronimo/m2-plugins). Drop m2 plugins here. In
>>> the future, delete
>>>>>> existing geronimo/plugins and rename the
>>> m2-plugins to plugins.
>>>>>>
>>>>>> [ ] Option 2: drop m2 plugins in the same
>>> directories as their m1
>>>>>> counterparts. The m2 code will be in a
>>> different package structure.
>>>>>> The m2 artifact will have a different groupid.
>>> Ensure different  jars
>>>>>> get built. Live with the harmless possibility
>>> of the m1 jar carrying
>>>>>> m2 classes and vice-versa.
>>>>>>
>>>>>>
>>>>>
>>>>> [X] Option 3: It's a mixture of Option 1 and
>>> Option 2, i.e. create a
>>>>> new directory for m2 plugins *and* support them
>>> as well as the m1
>>>>> plugins. Although it's technically possible to
>>> do Option 2, it may not
>>>>> be very user- and developer- friendly. Let's
>>> keep these two plugin
>>>>> flavours separated. I think m2-plugins is good
>>> enough to get us
>>>>> started.
>>>>>
>>>>>
>>>> +1 to Option 3
>>>>
>>>> John
>>>>>> Prasad
>>>>>>
>>>>>
>>>>> Jacek
>>>>>
>>>>> --
>>>>> Jacek Laskowski
>>>>> http://www.laskowski.org.pl
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>


Mime
View raw message