I'm really, REALLY, glad you have taken an interest in m2 migration
:-) Your experience with other such migrations can surely help us.
Alright so now you can guide us.
:-) I need a buildable server too ;-)
So we shall hardcode the parent <version> in all pom.xml and remove
the <version>. element for that project itself. That should help us do
a single build w/o the -N.
Yup, each module should define the project/parent/version and only
the root pom.xml should define project/version. Leave mgmnt of this
number to the release process, don't try to fix it with properties
now, since it just doesn't work like that in m2 yet.
What else would u advise ?
Well, I'm still assessing what the state of the m2 conversion is.
Offhand I can think of a few things that we should do:
Create some helper modules to carry build configuration.
Specifically, we should create a new module that contains a simple
Log4j configuration that can be shared by all modules. IMO, the
default build should not spit out tons of output when running tests.
It should capture all output into target/test.log and if needed allow
the developer to enable system.out with a property setting. This is
easily done be creating a new module that contains the shared
log4j.properties and then hook it up as a default extension to the
build.
But, to do this, the module needs to be built separately and
downloaded. Not a big deal really, but something needs to be done to
setup/facilitate its build. I recommend that we setup a peer tree
that holds build support modules. Starting out with the logging-
config module... but there are also other reasons to have these
support modules, especially as we add more and more projects that
need to share the same basic configuration.
I also think that we should remove any unneeded properties in the
root pom. I mentioned the reasoning before... basically less is
more. This file is going to get more and more complicated, no reason
to inflate that with unneeded properties.
Drop and configured modules that are not checked in to the tree (ie.
modules/openejb). If this is really needed then it should be checked
in.
* * *
Other thoughts are more about future reorganization of the tree. I
think we may want to split up the tree as it exists now into a few
smaller chunks that represent more functional areas. For example,
I'd like to have all of the core modules grouped up, so that I could
just build everything needed to just get the very basics up. Then
another group for all of the J2EE support, and then another for
thirdparty vendor support, etc.
We should be willing to reorganize the tree after we get the basic
build going, to facilitate separation of concerns from a component
level... meaning that if I am only interested in building the bare
server, then I should not need to bother with all of the other j2EE
and 3rdparty stuff.
But all of this will come in time. I think that once the m2 build it
functional that we should reorganize right away into functional
groups of modules.
If I notice anything that I think is a bit "crazy" I will be sure to
post it to the list.
--jason
