geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Migrating geronimo-plugins to M2
Date Tue, 21 Mar 2006 15:16:54 GMT
Sorry if this has been mentioned.  Would it make sense to put out an 
informational message in the M1 plugins announcing deprecation so people could 
consider moving up or at least get them thinking about it.

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 ?
> 
> 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