-
1. Re: Build structure redesign: UI modules
Actually, best structure would depend from developer habits.
I'm using Mylin that perfectly filter workspace for classes and files involved in my work, so actual place doesn't matter. On the other hand, each additional project takes resources from IDE and command-line builds, and requires additional goals for distribution, so I prefer to have as little projects as possible. Also, if you take a look to existing api projects, they contains a few classes only - does it make sense to have separate project for just 2/3 classes ?
-
2. Re: Build structure redesign: UI modules
- /parent is not needed. The richfaces-parent is the only parent with the new system. Although there is a possibility of a ui BOM. Although now that I think of it the only thing that should have its own BOM is CDK (different runtime). At some point we might want to have core have its own BOM, but it is not needed now.
- Personally I really think that the private version is the way to go. As Nick said it will make it easier to isolate, and is much easier to partition work, dependencies, etc… Not to mention easier to grasp for new people.
- However that does not mean that we need each <component-type> ( core, validation, iteration, etc…) to have sub-projects. I think if the component set is simple enough ( as Alex said ) it could just be:
/validation pom.xml /src /<api & ui source>
- While complex component types like iteration could maintain separate projects like this:
/iteration /pom.xml /api pom.xml /src /ui pom.xml /src
- However - it is likely much easier to generate the project jars if api is kept separate. In either case we will be using shade plugin to generate our component jars
- One thing not covered here is java packaging, although it should follow suit.
org.richfaces.components.iteration.api…. org.richfaces.components.iteration.ui….
- The only question there is - do we break this out to component name?
-
3. Re: Build structure redesign: UI modules
- /parent is not needed. The richfaces-parent is the only parent with the new system. Although there is a possibility of a ui BOM. Although now that I think of it the only thing that should have its own BOM is CDK (different runtime). At some point we might want to have core have its own BOM, but it is not needed now.
I've placed parent for ui module to keep independent shared plugin settings, e.g. CDK or Checktyle configuration. If we don't need this, it can be removed.
- Personally I really think that the private version is the way to go. As Nick said it will make it easier to isolate, and is much easier to partition work, dependencies, etc… Not to mention easier to grasp for new people.
- However that does not mean that we need each <component-type> ( core, validation, iteration, etc…) to have sub-projects. I think if the component set is simple enough ( as Alex said ) it could just be:
/validation pom.xml /src /<api & ui source>- While complex component types like iteration could maintain separate projects like this:
/iteration /pom.xml /api pom.xml /src /ui pom.xml /src- However - it is likely much easier to generate the project jars if api is kept separate. In either case we will be using shade plugin to generate our component jars
Ok, let's go with private API. Also I'm for unified package structure (the one where package name is the same in every ui submodule), so here is the structure outlined in more details:
- dist - api - ui - parent (?) - common - api - ui - input - api - src/main/java - org.richfaces.component - InputOrientation.java - SuggestionEvent.java - SuggestionListener.java - CalendarEvent.java - CalendarListener.java - ... - ui - src/main/java - org.richfaces.component - AbstractAutocomplete.java - AbstractCalendar.java - AbstractNumberInput.java - ... - org.richfaces.renderkit - AutocompleteRendererBase.java - CalendarRendererBase.java - NumberInputRendererBase.java - ... - output - api - ui - misc - api - ui - src/main/java - org.richfaces.function - RichfacesFunction.java - org.richfaces.component - AbstractDrag.java - AbstractDrop.java - AbstractJQuery.java - ... - org.richfaces.renderkit - DragRendererBase.java - DropRendererBase.java - JQueryRendererBase.java - ... - iteration - api - ui - core - api - ui - validation (?) - api - ui
-
4. Re: Build structure redesign: UI modules
Nick Belaevski wrote:
- /parent is not needed. The richfaces-parent is the only parent with the new system. Although there is a possibility of a ui BOM. Although now that I think of it the only thing that should have its own BOM is CDK (different runtime). At some point we might want to have core have its own BOM, but it is not needed now.
I've placed parent for ui module to keep independent shared plugin settings, e.g. CDK or Checktyle configuration. If we don't need this, it can be removed.
That is a good point. Lets leave the ui specific parent ( assuming it's parent is richfaces-parent)