4.0.0.ALPHA1 assembler design
jbalunas Aug 19, 2009 4:58 PMAs per our meeting today http://www.jboss.org/community/wiki/RichFaces40TeamMeetingMinutes8-19-2009. I wanted to create an assembler forum post to discuss how we are going to package 4.0.0.ALPHA1 ( and a little on future assembler plans). For reference here is the build system wiki for 4.0 - http://www.jboss.org/community/wiki/RichFaces40BuildSystem.
I think it is important to know what our plans are so we do not just have throw away code for A1.
There are a few options:
1) one big distribution ( framework, ui, source, cdk, docs, examples) aka Seam 2.X
2) one binary dist, one source dist for CDK, framework, docs,examples combined.
3) several small self contained distributions - framework, CDK, examples, docs (self contained means binaries, source, java-docs, jars, etc...)
4) many distributions CDK source & bin, framework source & bin, examples source & bin, etc....
Personally I think that options #3 follows our modular model best and allows users to pull what they want and modules to define their own distributions ( following conventions for the project ). It also allows for a master assembler that can put together a combined distribution if we wish.
If we go with #3 then the next logical question is what modules constitute distributions. Again here we have some options:
1) Each module in build - CDK, Framework, UI, examples, doc
2) CDK, doc, examples + a combined framework & UI
3) TBD
I'm on the fence on this one. 1) is clean and true to module form but 2) is more likely how users will be be using our distributions. I'd be curious on others opinions?
The next question and the one most relevant to ALPHA1 is where will these assemblers live. In the original build system wiki we discussed an assembly module that coordinated the construction of the various assemblers. This assembler could either build things itself, or call module assemblers to construct distributions. I prefer this approach as it can give us the best of both worlds - a common assembly location & the ability to have modules define their own if needed.
This is where we need to agree and discuss in more detail so we can continue with ALPHA1 assembly and not have it be complete throw away code.