> I don't think we want to use org.apache.geronimo for everything... Can you supply a concrete use case?
Sure, I believe that we will eventually get G split up into a few smaller chunks. Probably, one tree of modules, that represents the very core of G, none of the J2EE bits at all. Then another that provides the J2EE behaviors and then another that provides different flavors of J2EE bits that can be plugged in. org.apache.geronimo = core org.apache.geronimo.j2ee = j2ee ... Maven groupId's are very useful to organize components that work together. So, for example, if you just needed the basic core to run your non-j2ee application on, then you would know that you just need all of the org.apache.geronimo artifacts, and you would know that something is starting to creep in if org.apache.geronimo.j2ee start to pop up. BTW, I do not believe that groupId's need to be 100% related to the package names of classes that they contain either. They should be mostly related though...
> I think it is premature to be talking about changing groupId's right now. I don't agree. Unless I'm missing something, there's no point in waiting.
The reason why I think that it is premature is that we have not really even begun to discus how to best restructure the source tree. I do believe that we really should do this once we move to m2. The current structure was designed around how m1 worked and the limitations of how the reactor found projects. Now that m2 has a better view on how this works, we are free to nest modules into more domain specific groups. While we could re-groupId now, we will probably end up doing it again once we've restructured w/m2... so, I think that it would probably have less impact to delay any major groupId changes until we get m2 support in place. --jason
