Matt Hogstrom wrote: > 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. >
This is a good idea. > 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 <[EMAIL PROTECTED]> wrote: >> >>> M1 plugins are being kept around for people who >>> want to continue using M1. >>> +1 to option 3 >>> >>> Cheers >>> Anita >>> >>> --- Prasad Kashyap <[EMAIL PROTECTED]> >>> 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 <[EMAIL PROTECTED]> wrote: >>>> >>>>> Jacek Laskowski wrote: >>>>> >>>>>> 2006/3/20, Prasad Kashyap >>>> >>>> <[EMAIL PROTECTED]>: >>>> >>>>>> >>>>>>> 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 >>> >> >> >> >>
