Candidates to refactor out of the J2EE domain

Classes which were just copy pasted from J2SE project type and which may have several copies withing J2EE project types.

  • ClasspathProviderImpl
  • CompiledSourceForBinaryQuery
  • JavadocForBinaryQuery
  • UnitTestForSourceQuery
  • SourceLevelQuery
  • FileBuiltQuery
  • FileEncodingQuery
  • ProjectClassapathModifier
  • PlatformUISupport
  • Java Library node in logical view
  • SharabilityQuery

Common things in J2EE projects

  • brokens server reference (dialog moved to j2ee/utilities, !BrokenServerAction's can be probably moved too)
  • looking for sources in Project from Existing Sources wizard

Common things for all project types (including J2SE project)

  • libraries manager and the Libraries node (issue 85790)
  • javadoc panel in project properties
  • support for the Projects/Actions folder in the default FS (issue 57874) and for badging of the project root node (issue 57776)
  • classpath parsing (parts of ClassPathSupport) -- not in the EAR project

Vince Kraemer says...

a long time ago... I haven't run CPD for quite some time... Hopefully, the situation has improved since then.
Here is some data that I collected by running cpd (a subproject of pmd.sourceforge.net) over: j2ee/ejbjarproject, j2ee/earproject and web/project.:

  • CPD found 196 suspected copy-paste code "snippets".
  • The largest was over 300 lines in !PlatformUiSupport.java - ejbjarproject and web/project.
  • The average size for a suspected cp snippet was 61 lines.
  • That is a lot of duplicated code that would need to be maintained.

RadkoNajman says... (20 May 2005)

  • the Enterprise Application and the Web Application project share the ability to "include" additional projects, jars and libraries. So, both have an extended "Packaging" customizer. Note: a resource adapter project would probably use a similar capability and UI.
  • I think all the projects have a copy of the form/java file that implements the "root pane" of the project properties dialog. This should probably be available as a utility.
  • Implementations of org.netbeans.api.project.Sources duplicate some code. Would an abstract helper class help? Currently there is the org.netbeans.spi.project.support.GenericSources class, but that may not be much helpful. See also issue 63679 (and 63359).


Generally try to work with project like usual - change its properties, use code-completion, create & run unit tests and so on. More specifically, focus on these operations (all the testing has to be done for all the project types - J2SE, Web, AppClient, EJB projects):

  • Find source for class file
  • Generate Javadoc
  • Jump from source to its unit test and vice versa
  • Source level of Java files (even with broken platform)
  • File encoding of files
  • Customizer - changing project JDK (Source/Binary format)
  • Create project, add to SCM, verify that everything is ok (sources are in SCM, binary files not etc.)
  • Create WS client and try whether code-completion works
  • Open project created in NB 5.5 (or earlier) and try to change its properties, investigate whether the dialog about upgrading appears, whether the upgrade process succeeds if user selects Yes and nothing changes if user selects No
  • Verify some specific issue: IZ#126863
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo