Almost all the team members used Eclipse IDE with wtp. So only that IDE will be considered in that document. However any other one (like Idea for example) is suitable for the development too for sure.
1) In order to download and install IDE visit:
- Eclipse IDE for Java EE developers (more lightweight setup)
- Jboss Developer Studio (more convenient environment for creating samples)
2) Configure IDE with
2) In order to work with RichFaces SVN repo visit http://www.collab.net/downloads/subversion/. There are set of IDE-targetted(Including Eclipse) and command-line clients for all kind of environments.
TBD section should be updated after migration to Git.
3) RichFaces build is Maven based so visit http://maven.apache.org/download.html and download (better latest) Maven distribution. RichFaces 4 requires Maven 2.0.10? minimal version. It's recommended to use Maven 3.
- Configure maven as described at Maven Getting Started - Developers wiki page.
- Additionally you may want to instal m2eclipse Eclipse plugin in order to work with samples more easilly. If you choose not to use plugin you will need to generate eclipse project descriptors using mvn eclipse:eclipse
<TBD check what could be added additionally>
Other helpfull tools
1) In order to work more convenient with the jira (working on the project requires a lot of jira's tracking) you may want to install some jira plugin which allows to work offline:
- Jira Client from almworks - was activelly used by us last time.
- jira plugin from tigris.org(not sure how active is)
2) Diagrams creations during component architecture/requirements development could be created using dia - GTK based diagramm creation tool.
Workflow for component, core, and CDK development
Article which describes jira tasks and their workflow really conatins of most important info related to that. I would just add some notes there.
1) design subtask.
During component design make sure you:
- checked all available alternative implementations for that component(if exist)
- check not only JSF libraries but .Net, flash, JS widgets from jQuery/Y! ui/... for similar ones.
- Looked though the forum in order to gather all the request for the component and details of the features asked.
- Make sure you highlighted all the base functionality.
- It's the best to discuss any questionable functionality at forum in order to get feedback from most important guys for RF project - its community.
- Avoid intoruducing too complex/questionable functionality in first version. It's really better to introduce the base and then go through users feedback before implementing some extensions.
- Any component should have really simple definition from the user point of view. At least for just quickly checking it. It's looks not bad if the component requires dozen of attributes + some visual model or some properties files or something like that in order to work in most optimal way. But it's inadmissible if the component requires complex definitions in order just to try it.
- All attributes where possible should have reasonable defaults
- All the models should have default impl for just exploration
- All the config/localization properties should also have defaults bundled and used if not defined.
2) design markup and skinning subtasks
Make sure that you alwas have good balance of "Semantic" markups and component functionality while creting markup for new component.
Sometimes usage of semantic markup introduces set of limitations. All of them should be reasonable and you should be sure that them not blocker for real applications.
Example: currently dataScroller rendered with set of spans. And when we will implement task "Add pages facet" - we need to redesign it as I believe. The users could use table/div based markups there frequently. It will cause not-valid html to be rendered. But the users will not be happy to have inline-component only limitations I believe.
Consider that skinning document:
3) Actual development.
Make sure that next things not getting lost from process:
- tests creation
- code reviews
- comments both for JavaDoc and for important/complex methods or even pieces of code for some methods.
Consider next documents:
Now when CDK is stabilized and mostly finished in base we had pretty simple workflow for CDK features development.
Developers just identifies repeating and routine tasks which still can't be performed during new components development. Then all the team discussing how them want to see that simplified by CDK. Then it's getting implemented in CDK accordingly.
We have not much community attention to the CDK (comparing to library itself). However it's still important to monitor knowledgebases and forums for external write-up's with any issues or feature requests. Them also should be put to jira and discussed for impl.
Most Important: as we discussed after the 4.0 final relase it's important to achieve CDK independency from RF itself. That will allow the developers to use it without digging in RF internals and could greatly increase popularity of the tool.
Really had no official "workflow" there. We just identified problematic places in JSF (e.g. impl-dependent stuff, lack of api and so on) or features which not available in JSF 2 at all but required by our component development and made extensions corerspondingly.
It should be good practice to review all the stuff which getting implemented in framework and rise issues/discussions to JSF EG in order to have them standartized in future. That will help to achieve best interoperability in future.
Testing and test best practices for RichFaces component
TBD - provide public links when availble.
Setup for debugging/developing with various JSF impls
RichFaces 4.0 Build Options document describes set of profiles which allows to use different JSF impls and versions. When sample imported with corresponding profile (no matter using eclipse maven plugin or just project generation usign eclipse:eclipse) - it will be bundled with needed JSF impl version and sources.
NOTE: if importing custom users application without m2eclipse do not forget to add two important parameters to eclipse:eclipse command line:
mvn eclipse:eclipse -DdownloadSources=true -Dwtpversion=2.0
(them will be added automatically for our samples in examples folder as included in pom but will not be added if will generate eclipse project stuff for custom apps or apps generated with archetype for example)
That way looks more prefferable instead of option to checkout JSF sources.
tools used in Browsers:
FF - Firebug
For all the other browsers used built-in debuggers.
To inspect http request in details in case of checking caches problems or complex problems which reques to inspect request/responce data we used Fiddler web debuger
Setup for CSS
As for JavasScript we never used any specific tools for CSS development. All the modifications were done just in simple Eclipse CSS editor.
For debug/bugfixing purposes we used the same fireBug for FF and built-in debuggers for other browsers.
Example of creating a component end to end
TBD - need to make it public.