On 26/12/09 9:42 PM, Andrus Adamchik wrote:
The group vs. actual location mismatch is because we have public modules, in which we don't want to expose any odd group ids to the end users.
I don't understand that. If we only had one group id, there wouldn't be any 'odd' group ids. But I don't understand what a maven group id actually represents: it looks a bit like a namespace, in which case we really should only have one namespace for the whole project.
We may try to improve things in 3.1. The addition of extra "unpublished" modules in 3.1 has made things less comprehensible again, so some reorg (invisible to the end users) may be a good thing. Maybe separate public aggregated modules in a their own location (hmm... still putting them at the root of the checkout to ensure the folder structure follows maven guidelines would crowd the root folder ... need to think about it).
There doesn't seem to be anything wrong with the current folder structure. Only that the modules inside the framework folder should reference a parent which is the framework pom itself. And the names of each module should match exactly the folder names. If we did just that, would anything break?
Also I wanted to play a bit with maven-release-plugin that may clean up publicly visible structure: http://maven.apache.org/plugins/maven-release-plugin/index.html In the past the fact that it alters SVN from Maven gave me an uneasy feeling. The plugin behavior still looks a little odd. But since it is next to impossible to permanently break things in SVN, I guess I may give it a try one day.
That plugin just seems too odd. And one day it would be nice to be able to release out of Hudson. That is, to ensure the build environment is always reproducible, just pick an artifact Hudson builds and name it with a release version. That's what we've been doing at my company and it helps a lot. Ari -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
