Using Server JARs in project

There is several examples where application server provides JARs which may or may not be needed for user's project in order to successfully:

  • compile project; and/or
  • execute unit tests; and/or
  • deploy project

For example in Ant project a server may provide JARs which are necessary for:

  • project compilation (JEE API jars)
  • execution of project's unit tests (JEE API jars)
  • execution of misc tools during project build (jars necessary to run wscompile, wsimport, ...)
  • execution of EJB unit tests in Embeddable EJB container (jars with server specific implementation of standalone EJB container)
  • deployment of project (jars which comes with the server and which must be used instead of generic ones; eg. Weblogic requires its own build of JSF jars)

In Maven project the situation only differs that Maven artefacts are used instead of JAR files directly but in principle the concept is the same.

From server perspective these jars are dynamic - their list, versions, number of supported tools, etc. can change any time.

Project requirements on the other hand are to be always compilable, runnable and testable. Project which was freshly checked out from VCS should just compile, run and test regardless of whether it was opened in IDE or in command line. It may perhaps ask for location of a server installation but nothing else should be required.

At the moment we have two solutions in place: 'sharable server library' and 'server library'.

'Server Library' addresses deployment and libraries available on server. At the moment project compilation and sharability of server libraries is still under construction.

'Sharable Server Library' addresses compilation and execution of project. All server jars are copied outside of server and stored in VCS along the project sources. The biggest limitation is that list of classpaths to export is hardcoded and they all have to be exported at once (and in advance) regardless of whether project will ever need that classpath or not. Which is problem for embeddable EJB container which classpath can be larger then 50MB yet it is very rarely used at the moment.

Solution idea: "Back to the Basics - J2SE Library"

A server provides its JARs as several regular IDE J2SE libraries - single library for compilation of JEE code, single library for wscompile tool, single library for embeddable EJB container, single library for each server library, etc. When server is registered in the IDE it would register all its libraries to global libraries catalogue (prefixed with server name and version for better navigation). Unregistering the server from IDE would cause removal of the libraries from global catalogue. This allows server and 3rd party server extensions like WS support to manage libraries dynamically according to their needs. Any project (or 3rd party project extension) could use these libraries on as needed basis and once the library is added to project nothing extra would need to be done for library sharability or for resolving of broken library references - it would behave as regular J2SE library. Deployment code could examine list of project libraries and treat some of them differently, for example if project uses Weblogic-v10.1-jsf library it could omit deployment of this library and use one on Weblogic server instead.

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