(In reply to comment #0)
> This should be next logical step of
> http://wiki.netbeans.org/J2eeCommonRefactoring right? 

Agreement. This will refactor out and move project specific classes into exclusive module. I suppose, on such a module should depend only project modules. As a side-effect it will clean up the list of classes unrelated to j2ee.common (it still depends whether the j2ee.common will survive as the Util's module or not).

> This is just a proposal. What do you think?

I agree with all described! I didn't study all classes in detail, but I suppose that all of them have similar purpose - be shared project's class.

I thought that we did not want to do this because moving UI code with a lot of bundle files is risky, but of course if it gets done, it will speed up the much needed refactoring of j2ee.common!

(In reply to comment #0)
> This should be next logical step of
> http://wiki.netbeans.org/J2eeCommonRefactoring right?

I'm 100% for it! Only thing I would like to discuss is whether we should try to make the module "build-system independent" or not.

Most of the classes you have listed are Ant-dependent but there are some unrelated to any build system.

Ant-dependent (these are typically used by j2ee.clientproject, j2ee.ejbjarproject, j2ee.earproject and web.project):
o.n.m.j.c.SharabilityUtility
o.n.m.j.c.project.ArtifactCopyOnSaveSupport
o.n.m.j.c.project.ui.AbstractLogicalViewProvider
o.n.m.j.c.project.ui.ExtraLibrariesNode
o.n.m.j.c.project.ui.J2EEProjectProperties
o.n.m.j.c.project.ui.ProjectImportLocationPanel
o.n.m.j.c.project.ui.ProjectImportLocationWizardPanel
o.n.m.j.c.project.ui.ProjectLocationPanel
o.n.m.j.c.project.ui.ProjectLocationWizardPanel

Build-system independent: 
o.n.m.j.c.project.JavaEEProjectSettings
o.n.m.j.c.project.spi.JavaEEProjectSettingsImplementation
o.n.m.j.c.project.BaseClientSideDevelopmentSupport
o.n.m.j.c.project.ui.J2eePlatformUiSupport
o.n.m.j.c.project.ui.UserProjectSettings
o.n.m.j.c.project.WhiteListUpdater (this one is currently Ant-related but I'm going to rewrite it using JavaEEProjectSettings to be independent)

..I would like to see these two categories logically spited somehow. Simplest seems to be to create javaee.project.ant sub-package which will contains all of these. What do you think David?

> I thought that we did not want to do this because moving UI code with a lot of
> bundle files is risky

It is an extra work but it would be beneficial I think.

Re. "ant" versus "maven" - we could do that

I'm also thinking that despite most of the packages being API packages we should include "api" in the package names. Here are proposed package names:

api.BaseClientSideDevelopmentSupport
api.ui.utils.J2eePlatformUiSupport
api.ui.UserProjectSettings
api.WhiteListUpdater
api.JavaEEProjectSettings
spi.JavaEEProjectSettingsImplementation

api.ant.ArtifactCopyOnSaveSupport
api.ant.SharabilityUtility
api.ant.ui.logicalview.AbstractLogicalViewProvider
api.ant.ui.logicalview.ExtraLibrariesNode
api.ant.ui.J2EEProjectProperties
api.ant.ui.wizard.ProjectImportLocationWizardPanel
api.ant.ui.wizard.ProjectLocationWizardPanel
api.ant.ui.wizard.ProjectServerWizardPanel

Integrated into 'main-golden', will be available in build *201306242301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/c2e792e7c7d1
User: David Konecny <dkonecny@netbeans.org>
Log: #231687 - removing deprecated or unused APIs

(In reply to comment #4)
> I'm also thinking that despite most of the packages being API packages we
> should include "api" in the package names.

Awesome, I was thinking about the same.

> Here are proposed package names:

Like it!

BTW: I'm going to vacation on Thursday and won't be online for a week and a half, so I can help with the implementation only if the agreement about the final state will be by tomorrow

(In reply to comment #4)
> I'm also thinking that despite most of the packages being API packages we
> should include "api" in the package names. Here are proposed package names:

Great idea guys! I was a little bit worry about making the base package as the API one (although in case of purely API modules it can be probably OK), but this will be solved by your proposal too.

Sounds like we have an agreement.

Enjoy your holiday MartinJ. I would not worry about this issue much before your holiday but if you want to do some work on it I will not stop you. :-) When I have a spare moment at the end of the day I usually try to delete something from j2ee.common. :-) So I may do some work on this issue too.

web-main#592a97c1d8cc - module established with some API/SPI. More classes to be moved later.

38415bc59ad0 - moving WhiteListUpdater

web-main#9e0807914a1d - most of remaining project APIs were moved

be03937df357 - module layer were not updated properly

I think this issue is *overall* resolved. I can imagine there might be few small things to be improved. Feel free to file them here or as a new issues or in the wiki page. I updated it little bit to reflect current state: http://wiki.netbeans.org/J2eeCommonRefactoring

Integrated into 'main-silver', will be available in build *201307102300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/592a97c1d8cc
User: David Konecny <dkonecny@netbeans.org>
Log: #231687 - create javaee.project module; first part; TBC