4.0.0.ALPHA1 assembler design

[jbalunas]

As 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.

[jbalunas]

For ALPHA1 I propose creating the assembler module and moving the current assembly.xml file to it.

For ALPHA1 this can be very basic and just construct the framework dist & the example dist.

richfaces-4.0.0.ALPHA1
 /lib
 richfaces-api-4.0.0.ALPHA1.jar
 richfaces-impl-4.0.0.ALPHA1.jar
 richfaces-ui-components-4.0.0.ALPHA1.jar
 /source
 -source-xxx.jar ( for each lib above )
 /java-doc
 /xxx
 readme.txt
 lgpl.txt
 contributors.txt

richfaces-examples-4.0.0.ALPHA1
 /components
 /core-demo
 pom.xml
 /src
 readme.txt
 /richfaces-demo (need a better name )
 pom.xml
 /src
 readme.txt
 readme.txt
 lgpl.txt
 contributors.txt

We'll need to wait for Alex regarding the CDK distribution and see if we can get that packaged as well. I would really like to see the CDK in ALPHA1 if possible even a basic dist.

[ilya_shaikovsky]

Choosing from your options I agree that

3) several small self contained distributions - framework, CDK, examples, docs (self contained means binaries, source, java-docs, jars, etc...)

seems the best variant. (seam way not seems optimal because we already heard at forums that customers not want to download our samples because of its size :( )

As for moving forward with that option I think that CDK, docs and examples should be separated for sure and Framework and UI combined as described in option 2.

B.t.w. do we sure that we should pack sources and javadocs with binaries? Maybe them could be also downloadable separatelly? Think that the customers often need just to download CRs or Betas to get issues resolved and has no need to download sources/javadocs artifacts. So maybe we could distribute:
1) framework/ui binaries pack
1.1) framework/ui sources/javadocs pack
2) CDK binaries
2.1) CDK sources/javadocs
3) examples pack.
4) documentation pack.

As for examples I think we have no need to assemble components demos(placed in components) and rf-demo both. It seems that if we will be able to build the rf-demo showcases application till A1 - it will be enough for distibution. I think that components demos which is used during development isn't so informative in order to be distributed. And as I know from our 3.3.x samples - them are changed continously according to include some issues checing and so on.. So them are overloaded with some concrete issues cases and lacks clear usage samples.

Also for richfaces-demo project.. We talked about changing project name. And I already used components-gallery name at all project site. If this name sounds good for the application?

[nbelaevski]

I almost completely agree with Ilya; the only question is about CDK binaries distribution - currently they are tied to Maven and the possibility of manual plugin installation from distribution doesn't seem a valuable option for me.

Also to decrease download size for examples we can put the repeated libraries (JSF + RF binaries) into a separate folder with an instruction/script on:

1. How to install them to local Maven repository manually
2. Where to put them in order to run the application(s)

[nbelaevski]

P.S. I guess "JBossORG-EULA.txt" is missing in the structure.

[alex.kolonitsky]

Where can I find the readme.txt(for the richfaces-4.0.0.ALPHA1, richfaces-examples-4.0.0.ALPHA1, core-demo and richfaces-demo folders) and contributors.txt files?

In the structure above we include pom.xml, readme.txt and /src folder into /richfaces-demo. I think we must also include richfaces-demo.war file. Same question for the core-demo.

[jbalunas]

"nbelaevski" wrote:
P.S. I guess "JBossORG-EULA.txt" is missing in the structure.

Agree

[jbalunas]

"nbelaevski" wrote:
I almost completely agree with Ilya; the only question is about CDK binaries distribution - currently they are tied to Maven and the possibility of manual plugin installation from distribution doesn't seem a valuable option for me.

Also to decrease download size for examples we can put the repeated libraries (JSF + RF binaries) into a separate folder with an instruction/script on:

1. How to install them to local Maven repository manually
2. Where to put them in order to run the application(s)

I still prefer the idea of a single distribution with src/javadocs ( and perhaps TLD doc) in one download. This allows every user to have access to all the related binaries, source, and api docs in one download. We are still talking about a -source.jar file so the size will not be huge.

Nick/Alex as for CDK how to you see that as a distribution, or is that only available via maven? If that is the case we should still have a distribution that contains instructions, source, api docs, etc.. for the CDK - don't you think? @Alex please comment as well

I agree with common libs for examples dist, but must be scripted and easy for users to build deploy from dist. This functionality is not 100% needed for A1.

[jbalunas]

"Alex.Kolonitsky" wrote:
Where can I find the readme.txt(for the richfaces-4.0.0.ALPHA1, richfaces-examples-4.0.0.ALPHA1, core-demo and richfaces-demo folders) and contributors.txt files?

In the structure above we include pom.xml, readme.txt and /src folder into /richfaces-demo. I think we must also include richfaces-demo.war file. Same question for the core-demo.

We have not created these files yet and should create basic ones for A1. Where they go depends on the assembler I believe. If you take a look at web beans http://anonsvn.jboss.org/repos/webbeans/ri/trunk/dist/ they have a special directory for these documents. It is probably worth exploring how they put their dist together - to speed up the process. Where do you think they should go?

As for the war's/ear's for the example I'm not sure I agree - I think that the readme.txt gives basic instructions on how to build the example and what is needed. The issue with providing a pre-built archive could be what container it is targeted for ( tomcat, jboss, etc...)