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 ?

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

/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:

/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)