The initial build put the geronimo-javamail in its own holder, presumably so that it would be easier to migrate into commons-javamail at a later stage.
Changing the group id of the artifact is minor and does not make it any more difficult to migrate. Again lets not worry about migration... it is way to early to think about this.
At present, though, the situation is less than ideal: activation -> geronimo-spec and javamail -> geronimo-javamail. That means you'd need both the geronimo-spec and geronimo-javamail in order to use the JavaMail APIs.
What? You referring to groups when you should be referring to artifacts as dependencies. Groups only serve as organizational tools.
So I wasn't doing it just because they were their own modules, but because of the reusability of those generic components. I'd concur that you wouldn't want (say) javax.servlet or javax.ejb outside of a J2EE server, but JavaMail you might ...
They are already in there own modules and it does not matter to an external project what the end id of the dependency is. Putting the JavaMail spec into the geronimo-javamail group does not make it any more (or less) difficult for a project to depend on it. So for now everything under specs/ gets released in the geronimo-spec group.
Finally, I am not in favor of moving the JavaMail specs to Commons at this time and I believe that we should not even be thinking about it right now. Sure someday another project might be created to hold all sorts of ASL impls of Sun specs, that does not mean that Commons will be the place.
It is too early to be thinking about moving anything to another project, so please lets drop it.
--jason
