Either they need to go into geronimo-javamail and geronimo-activation, or they both need to go into geronimo-spec.
There has also been interest in the JavaMail APIs from the James end, which was why I think it was originally put into its own artifact group; thus, people who want to experiment with JavaMail on its own can do so.
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.
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 ...
Alex.
On Saturday, Aug 16, 2003, at 13:17 Europe/London, Jason Dillon wrote:
I am not in favor of creating artifact groups for each module or spec, but only for high-level organization. Specs go into the geronimo-spec group and everything else goes into the geronimo group.
--jason
On Saturday, August 16, 2003, at 06:59 PM, Alex Blewitt wrote:
On Saturday, Aug 16, 2003, at 12:52 Europe/London, Jason Dillon wrote:
Please, lets not worry about moving things out of geronimo at this time.
I wasn't worrying about moving them out now, but I don't think it's sensible for geronimo-javamail to be built as a separate unit that then depends on geronimo-spec. I think it's sensible to move it out to a separate build in any case, or failing that fold the geronimo-javamail back into the geronimo-spec module (which I would not prefer).
Alex.
Modified activation to be in separate geronimo-activation package instead of geronimo-spec (to support easier refactoring into commons-activation at a future stage).
Modified javamail to maintain relationship.
