> Ideally not. It's already going to be painful to split up the core-library > package (which now produces several JAR files) into separate modules solely > because Maven likes one artifact per module. > > Shale publishes information on API stability ( > http://struts.apache.org/struts-shale/api-stability.html) that also includes > a column describing who should be using the APIs in each package ... > application developers or those wanting to extend the framework. That is > the basis on which I would want to split the javadocs, but they would also > be based on combining back together all the application-related APIs and all > the framework-related APIs back together again.
With MyFaces we ran into a similar problem (at least it sounds similar.) We have one subproject for the JSF implementation but two artifacts (myfaces-api.jar and myfaces-impl.jar.) So we have core/pom.xml, core/api/pom.xml and core/impl/pom.xml. The top level pom has the version, scm, and issue management sections but it basically serves as a placeholder for the two modles: api and impl. For our release builds (and nightly builds), we want a single zip file for both jar files. So we have a little bit of custom maven magic to pull this off. Checkout the core and try: svn clean install -Pgenerate-assembly Then change to the assembly dir and do: mvn assembly:assembly We don't merge the javadocs and each module gets its own section in the website. This is hard to avoid with maven but in our case the javadoc split is actually desirable and makes things easier to navigate. Sean > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
