On Jun 30, 2006, at 11:12 AM, Jeff Genender wrote:
Jason Dillon wrote:
Jason Dillon wrote:
FYI, we should be using ${pom.version} anywhere the project
version is
needed. No need for a custom property.
I think its by coincidence that we have 1.2-SNAPSHOT for both the
plugin
and the G codebase...if its not coincidence, then it shouldn't be.
IMHO, the plugin should be versioned differently. In fact...I may
even
go as far as to say, the packaging plugin can be useful outside of
geronimo itself (people building their own packages, etc) and
probably
should be in its own tree or even be a mojo. I am personally
against
locking the G verison to the plugin version...I would like to see
them
seperated.
All modules that are part of the build should share the same
version to
simply the release process and make effective use of the m2
release plugin.
I agree that the plugins should probably be moved to their own
project
and have independent versioning... and we will get there, but
right now
the easiest/best thing to do is to use the same version for all
modules.
I'm not sure I agree that this is easiest or best. I think I would be
interested in getting others' input on this as well. One of the
problems we have now is the chicken/egg issue with the plugin being in
the build itself. I think this would be alleviated by moving the
plugin
to its own project and push it out as a reliable dependency for the
geronimo project. I have tried the internal plugin thing on a few
projects, and it always ended up making life easier having the
plugin as
its own project.
Aren't all these problems due to maven not handling this rather
obvious and important use case of building a plugin and then using it
in the same build? If a tool is broken you have to do something to
fix it.... but often fixing the tool works best.
thanks
david jencks
--jason
