Jorg Heymans wrote:
Ralph Goers wrote:
/src
/blocks
/cforms
/api
pom.xml
/impl
pom/xml
/samples
pom.xml
/test
pom.xml
Why would they be explicitly excluded? From my experience that only
happens when you specify -Dmaven.test.skip.
That's only true when the tests are inside of the module.
Given above structure, you would have to run "mvn package" 4 times, once
in each directory, to package everything in the module. If you keep the
tests inside of the module, they will get run automatically when
packaging the module *unless* specified otherwise.
There are easy ways to deal with that. Again, I am speaking from a
Maven 1 perspective since that is what I am very familiar with. My
understanding is that Maven 2 can do what Maven 1 can and more.
One way is to have each block have a pom which just does a multiproject
build. In this case you would just run maven package from the block
directory and it will build all the subpackages and run the tests. The
irony of your argument against this is that this is exactly what you
want; you ultimately want an api artifact, an impl artifiact, a samples
artifact and tests. Furthermore, if you need new artifacts it is pretty
easy to add them to this structure as they are new submodules. For
example, you might create a dbschema module if you wanted each block to
provide its own database schema, if it has one, and then you had a
dbschema plugin to aggregate all the dbschema artifacts together when
installing the product.
However, you do not want to use that pom if you are the Cocoon core and
all the blocks as the dependencies won't necessarily be right. But it is
easy to set things up to have them not be used in that kind of build.
OK. Does that mean that the core has to have all the dependencies that
all the blocks have even if it doesn't use them directly? That would be
silly.
That would be silly indeed. The cocoon-core module has all the modules
that the cocoon "core" needs. All blocks depend on cocoon-core, and in
addition to that they declare their own dependencies.
Now it is entirely possible that block A relies on version 1.0 of a
library, whereas block B relies on 0.9a , I think this was your point.
Yes, that was my point.
Now when you package these together in a war, maven has to choose. I
think ATM it just picks whatever came first during dependency scanning,
but I'ld have to check this. After osgi we won't even care about this
case anymore.
Yes, OSGi should solve this. Until then I'd rather not deal with that,
so each "release" of Cocoon would contain specific releases of blocks
which are all built using the same dependency versions.
I will start a page in Daisy, [Mavenization], explaining the current
structure.
Jorg
