oor wrote:
1)
The following problem is a part problem of the problem in 2)
I have three projects:
projectSpec_1
projectSpec_2
projectCommon
projectSpec_1 depends on projectCommon during all phases
projectSpec_2 depends on projectCommon during all phases
projectCommon has its own tests, using general test utilities contained in
its test sources
projectSpec_1 has its own tests, using general test utilities contained in
projectCommon's test sources
projectSpec_2 has its own tests, using general test utilities contained in
projectCommon's test sources
This gave me problems when running tests in projectSpec_1 and projectSpec_2:
Their test sources could not be compiled,
as projectCommon's test sources were not
available for the test compile.
Package your general test utilities in a separate project and make all
the others depend on it with test scope.
[...]
2)
The same projects as above, with the additional information:
I have two "super-projects in addition to 1):
ProjectSuper_1 consists of projectSpec_1, projectSpec_2 and projectCommon
projectSpec_1 depends on projectCommon during all phases
projectSpec_2 depends on projectCommon during all phases
projectCommon
ProjectSuper_2 consists of projectSpec_1, projectSpec_3 and projectCommon
projectSpec_1 depends on projectCommon during all phases
projectSpec_3 depends on projectCommon during all phases
projectCommon
I am not convinced parent-child inheritage is part of a correct solution,
as a project can only have one parent.
projectCommon cannot inherit ProjectSuper_1 and ProjectSuper_2
projectSpec_1 cannot inherit ProjectSuper_1 and ProjectSuper_2
Project inheritance and project aggregation serve two different purposes
and confusing them is in my opinion a mistake. Inheritance helps you
factor together properties that are common to multiple projects,
aggregation helps you build several projects at the same time and
possibly handle them together, e.g. for packaging. While I'm convinced
that multiple inheritance could be useful in avoiding needless
repetition, it's much more important for me to be able to build specific
projects as part of different combinations. You should be able to use a
single parent project for all your project, in which you could put
versions of common dependencies, JDK version, etc. and two different
aggregator projects for your different development environments.
3)
I also experience inconveniences when doing the coding, as organized just
now.
When working on ProjectSuper_1 (or ProjectSuper_2 for that sake), I code in
source belonging
to projectSpec_1, projectSpec_2 and projectCommon at the same time. To
compile projectSpec_1,
I then first have to compile and install projectCommon, to expose its
correct snapshot for projectSpec_1.
To achieve this, I have made som DOS bat files, that first installs
projectCommon
and thereafter compiles (and possibly installs) projectSpec_1. Using command
files to
help me out of the problems occur to me as a defeat.
I don't know which IDE / editor you're using. I'm using Eclipse with the
m2eclipse plugin and I keep a different Eclipse workspace for each of my
aggregator projects.
Conclusion:
===========
I am fairly new to Maven2, so I have not quite got learned how to
adhere to the Maven2 "best practices".
Please give me a hint (or better: more than just a hint) what I should do
differently
to origanize my projects better.
I don't know if mine could be considered "best practices", they seem to
fit our needs reasonably well.
Cheers,
Nicola Musatti
P.S. Read a good Maven book, if you haven't already done so. I have read
"Maven - The Definitive Guide" and I liked it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
