On Mar 21, 2006, at 7:16 AM, 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.
I don't see why this would be a good idea. If someone is using the
packaging and assembly plugins to construct a custom server, I am not
really interested in telling them they should be using m2 rather than
m1. I think it will be pretty obvious our position on a desirable
build system when we remove our m1 build: we still need m1 plugins.
thanks
david jencks
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
