On Oct 2, 2006, at 12:38 PM, Jason Dillon wrote:
IMO there is no "best" way to handle this problem. There is only
good and bad for each solution, but there is no smoking gun to
solve everyones issues.
I already sent out that itty bitty note about the release being jar
+ pom(s) but I wanted to clarify that even more...
If you take the current specs build... all of the versions of the
specs are defined in the top-level pom, which means that whenever
any module need to change, that its parent will also need to
change, and that change to its parent may cause other specs to need
to be changed (if they depend on the spec that has been
versioned). Those dependent modules really should be released in
the same process too, but there is no easy mechanism to automate
that in the multi-versioned build. Which leaves that task up to
process... and as I have mentioned before, will almost certainly
result in problems due to lack of insight into maven and how the
multi-version spec build functions.
If we have each spec in its own tree, that means that nothing is
shared and all referenced version numbers are hardcoded, which
means that when a dependency module is released that it is up to
the process again to make sure that each dependent module gets
updated and then released... which is even more problematic for
keeping things in-sync and now users need to have even more insight
into how the specs related to each other and will almost certainly
end up in disaster, especially as more specs are added and more so
when developers come and go.
What are the interdependencies between spec jars? I don't think
there are many. GIven this fact, I'm not sure that there needs to be
a root POM, _in specs_, that binds all the versions together.
Regards,
Alan
