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