DualBuildAnalysis

This idea appears to have been implemented to optimize the build process for situation where a Java EE project would be built/deployed stand-alone and in the context of an EAR. It also appears to have been implemented without considering its effect on directory deployment, especially in the EAR deployment case.

After initial consultation with others, I was assured that there should be no issue with unifying the two directories... confirmation one confirmation two

When the first person that I consulted about this issue started to provide conflicting feedback, I decided I had better dig into this a bit further.

Here is some of the questions that the expert raised...

Here are two use cases which I can think of right now. Do we know how the IDE should
and will behave?

1. Build a standalone module. Build the whole EAR application the standalone module
is part of.

Problem: the standalone module's libraries might end up in both the standalone module
and also in the EAR application

2. Build an EAR application and then deploy one of its standalone modules.

Problem: the module might miss some of its libraries

Testing and analysis

Methodology

I created an Enterprise Application Project with a Web Project sub project. I added the Struts framework to the web app. I created another jsp page to the web app; two.jsp. I added a link from welcomeStruts.jsp to two.jsp. I made welcomeStruts.jsp the welcome-page. Then I followed the steps described in the sections below and recorded the results.

Current situation

Web apps are directory deployed from the project's build/web directory. Enterprise applications are built from ear-module "versions" of modules. An archive is used for deployment.

Results of first test

step action result details
1 Run web app stand-alone the welcome page appears in the browser build/web is populated. struts.jar and supporting jara are in WEB-INF/lib
2 Run ent app am able to open the welcome page in the browser build/ear-module is populated. struts.jar is in WEB-INF/lib. supporting jars are not. They are in the "root" of the ear.
3 clean web project N/A this will have a bad effect on the stand alone web project.
4 follow the link to two.jsp (the ear "version" of the web app is currently displayed) the page two.jsp appears not a surprise
5 reload the stand-alone web app's welcome page the page does not appear not a surprise... the web app was cleaned in step 3.
6 rerun the stand alone web project the welcome page appears not a surprise
7 create a page three.jsp, and add a link to it on the welcome-page N/A N/A
8 reload the welcome page of the web app page reloads with new content thanks to directory deployment
9 reload welcome page of ent app the page reloads but there isn't any new content no surprise
10 clean ent app project N/A N/A
11 follow link on stand-alone web app error page appears this is due to the fact that the web project's build directory is cleared. A bit of a surprise.
12 run the ent app the index page reloads with new content not a surprise
13 press back from the error page displayed at step 11 the stand-alone web app welcome page appears cached....
14 follow the link from step 11 error page reappears not a surprise
15 clean ent app N/A N/A
16 clean web project N/A N/A
17 undeploy ent app N/A N/A
18 undeploy web app N/A N/A
19 run ent app welcome page is loadable build/ear-module is populated. EB-INF/lib has the struts.jar... none of the "supporting" libraries are present.
20 run web app welcome page loads build/web is populated. WEB-INF/lib gets populated with all the libraries


Proposed changes

Web apps remain directory deployed from a web project's build/web directory. Enterprise applications are directory deployed, by copying the content of a sub-projects build/web (or build/jar) to match the layout required for an exploded EAR (this is server dependent). EAR projects are directory deployed.

Results of second test

step action result details
1 Run web app stand-alone the welcome page appears in the browser build/web is populated. struts.jar and supporting jars are in WEB-INF/lib
2 Run ent app am able to open the welcome page in the browser build/web remains populated. struts.jar and supporting jars are in WEB-INF/lib of exploded ear. The supporting jars are also in the exploded ear's root directory.
3 clean web project N/A N/A
4 follow the link to two.jsp (the ear "version" of the web app is currently displayed) page two displays same as before
5 reload the stand-alone web app's welcome page error page appears not a surprise since we cleaned it... same as previous behavior.
6 rerun the stand alone web project welcome page reloads same as before
7 create a page three.jsp, and add a link to it on the welcome-page N/A N/A
8 reload the welcome page of the web app page reloads with new content same as before. thanks to directory deployment
9 reload welcome page of ent app the page reloads but there isn't any new content same as before. jsp change is not synchronized to ear yet.
10 clean ent app project N/A N/A
11 follow link on stand-alone web app error page appears same as before. this is due to the fact that the web project's build directory is cleared. A bit of a surprise.
12 run the ent app the index page reloads with new content same as before. not a surprise
13 press back from the error page displayed at step 11 the stand-alone web app welcome page appears same as before. cached....
14 follow the link from step 11 the page appears NEW BEHAVIOR. better than before
15 clean ent app N/A N/A
16 clean web project N/A N/A
17 undeploy ent app N/A N/A
18 undeploy web app N/A N/A
19 run ent app welcome page is loadable build/ear-module is populated. WEB-INF/lib has the struts.jar... none of the "supporting" libraries are present there. they are in the root of the ear.
20 reload the welcome page of the stand-alone web app error page appears expected, since the web app ins't deployed.
21 run web app welcome page loads build/web is populated. WEB-INF/lib gets populated with all the libraries and the struts jar.


Analysis

Converting to a single build directory appears to be safe. There are some cases where the user sees a new successful result because the build directory has become combined.

There does appear to be one danger: the directory deployed EAR may end up having additional content (like duplicated jars). These duplicated jars do not appear to affect the iterative development experience.. They may be problematic when a user redistributes the ear, IF they have been mixing the run the ear/run the stand-alone module in their development cycle.

The work-around to prevent this is to only "ship" the archives that are the result of doing a 'clean and build'. This is already the advised process, since the incremental nature of the ant build may result in old classes being shipped in the archive anyway... Existing issue

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