For 4.0 Alpha2 we have an updated build, and module structure. Part of the reason for this was to make it easier to develop, release, and build distributions for 4.0.
Note: Distribution == release artifact like .zip files
Note: these are just my proposed layouts, please comment, and we'll finalize at tomorrows team meeting.
Take a look http://community.jboss.org/wiki/RichFaces40BuildDirectoryStructure for the build structure that we are working on completing now.
In this structure we have various modules that need to be combined and built into our release artifacts. Single module artifact assembly can be handled by the modules aggregator. However there are times when multiple modules are required in a single release artifact. This is handled by the various /dist modules, these are responsible for packaging their sibling into a consumable release artifact. The root /dist is responsible for putting all of these things together into our top level release artifacts.
- The creation of these artifacts are separate from the release plugin and releasing the project
- Once setup of these artifacts are complete we need to create these artifacts nightly in hudson
- Releasing ( tagging, update versions, etc… ) will be the next topic discussed.
- Every jar should have its source, and javadoc jar with it.
- Other generated docs should be in /docs along with javadocs I think
- Example: I like the way Weld artifacts are structures - http://seamframework.org/Weld/Downloads
/weld-1.0.1-Final /artifacts /cdi cdi-api.jar (and source/javadoc jars) /weld weld-*.jar (and source/javadoc jars) /docs /apidocs /en-US /examples /<example> /<example> readme.txt build.xml license.txt readme.txt release-notes.txt
- Source code in separate package or combined?
- I think combined is best ( and buildable )
- Single large richfaces-4.0.0.Alpha2 artifact or have them be separate ( main, examples, docs, etc…)?
- I believe a single artifact is best.
- If examples become too large we can separate
Alex is going to be constructing a separate richfaces-cdk-4.0.0.Alpha2 artifact. As we have discussed it will have documentation ( guide, javadocs, schema docs, etc…), binaries, sources, etc… This will be its own download.
Alex please provide some idea's for your structure of that.
The ui /dist is going to be responsible for calling the UI modules and asking them to assemble themselves, then combining into a single artifact. This will require something like the maven shade plugin.
The outcome of this will be several jar files ( api, impl, ui ) that can then be packaged by the root assembler into the final dist.
Open Question: Do we also package the individual module artifacts, or only the combined.
The example/dist will call the assembler of each of the example modules and then package their distribution into single artifacts. Then depending on the answer to the question above about single or multiple artifacts will either be packaged into the main dist, or simply be packaged into its own zip.
/examples /<example 1> /<example 2> readme.txt build.xml ( maybe someday )
Each example should have a pre-built version, and the source code to rebuild the example.
These have there own packaging, and I do not think require their own release artifact, but still need to be packaged by the archetyle/dist into a directory or structure that can be consumed by the root dist.
/archetypes /<archetype 1> /<archetype 2> readme.txt
The root dist will be responsible for packaging the main richfaces distribution. This will either call the assembler/aggregator of single child modules, or the /dist builds from multiple module builds discussed above.
/archetypes /<archetype 1> /<archetype 2> readme.txt /artifacts /framework ( or core not sure ) richfaces-core-api.jar (and source/javadoc jars) richfaces-core-impl.jar (and source/javadoc jars) richfaces-commons-api.jar (and source/javadoc jars) /ui richfaces-ui.jar (and source/javadoc jars) /<module> ( if we break it down ) /docs /apidocs /<other sean docs> /examples ( if we combine ) /<example 1> /<example 2> readme.txt lgpl.txt eula.txt readme.txt release-notes.txt
Version #s are on the various jar files above