Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 215976 - Redeployment doesn't work for maven EAR project.
Redeployment doesn't work for maven EAR project.
Status: RESOLVED FIXED
Product: javaee
Classification: Unclassified
Component: Maven
7.2
PC Windows 7
: P2 (vote)
: 7.2.1
Assigned To: Martin Janicek
issues@javaee
72patch1-verified
:
: 216150 216217 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-26 02:41 UTC by rbento
Modified: 2013-05-03 13:00 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
IDE log (125.03 KB, text/plain)
2012-07-26 02:41 UTC, rbento
Details
Server and Maven logs. (2.81 KB, application/octet-stream)
2012-07-31 09:21 UTC, Jiri Skrivanek
Details
Screenshot to show the messed application name. (250.03 KB, image/png)
2012-08-31 14:50 UTC, rbento
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rbento 2012-07-26 02:41:37 UTC
Product Version = NetBeans IDE 7.2 (Build 201207171143)
Operating System = Windows 7 version 6.1 running on amd64
Java; VM; Vendor = 1.7.0_05
Runtime = Java HotSpot(TM) 64-Bit Server VM 23.1-b03

The simplest test.

Create a simple Maven Web Project. Run Clean/Build. Run > Deploy to GlassFish. Change something in the index page. Notice in the status bar [ index.xhtml saved, index.xhtml deployed ]. Refresh the browser and see the updated page.

Do the same but creating a Maven Enterprise Application with an EJB Module and a Web Module. Deploy it. Change something in the page and notice it says that it was saved, but not deployed. Refresh the browser and see no changes were deployed.

Notice that Deploy on Save option is marked for all modules.

This is a major issue. Renders NB 7.2 unusable for enterprise projects. :(
Comment 1 rbento 2012-07-26 02:41:48 UTC
Created attachment 122381 [details]
IDE log
Comment 2 rbento 2012-07-26 02:56:36 UTC
Comment on attachment 122381 [details]
IDE log

I noticed this in these logs but the server was set under 'properties > run'.

INFO [org.netbeans.modules.j2ee.deployment.impl.DeployOnSaveManager]: No server set for Maven project - Deploy on Save will not be performed

I also noticed this:

INFO [FaceletsLibrarySupport]: Invalidating facelets libraries due to a library descriptor change.

And this:

INFO [org.netbeans.modules.j2ee.deployment.impl.TargetServer]: Cannot incrementally deploy to more than one target


I hope it helps.
Comment 3 Jiri Skrivanek 2012-07-26 11:00:57 UTC
I confirm deploy-on-save doesn't work for Maven EAR project. It works in NB7.1.2 and some changes were done in bug 215089. To reproduce:

- have a GlassFish server registered in IDE
- open new project wizard and select "Maven|Enterprise Application"
- finish wizard with default values (Java EE 6, GlassFish)
- add session bean with business method to mavenproject1-ejb project
- right-click mavenproject1 and choose Build
- right-click mavenproject1-ear and choose Run
- wait until index page is opened in browser at localhost:8080/mavenproject1-web (bug 215454)
- open "mavenproject1-web|Web Pages|index.jsp" and change body
- save file but the project is not redeployed (if you reload page in browser it doesn't change)

Product Version: NetBeans IDE 7.2 (Build 201207171143)
Java: 1.7.0_06-ea; Java HotSpot(TM) 64-Bit Server VM 23.2-b09
System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)
Comment 4 Martin Janicek 2012-07-30 08:07:06 UTC
Fixed together with issue 215454 in: web-main #752b7ed13c51
Comment 5 Quality Engineering 2012-07-31 02:33:21 UTC
Integrated into 'main-golden', will be available in build *201207310001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/752b7ed13c51
User: Martin Janicek <mjanicek@netbeans.org>
Log: #215454 + #215976 - Redeployment doesnt works for maven EAR project.
Comment 6 Martin Janicek 2012-07-31 06:37:38 UTC
*** Bug 216150 has been marked as a duplicate of this bug. ***
Comment 7 Jiri Skrivanek 2012-07-31 09:21:27 UTC
Created attachment 122567 [details]
Server and Maven logs.

Now it is not possible to deploy EAR project.

Product Version: NetBeans IDE Dev (Build 201207310001)
Java: 1.7.0_06-ea; Java HotSpot(TM) 64-Bit Server VM 23.2-b09
System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)
Comment 8 Martin Janicek 2012-07-31 11:52:21 UTC
Looks like Windows specific issue --> works just fine on Ubuntu Linux after the changes. I'll try to fix it tomorrow on Windows 7.
Comment 9 Martin Janicek 2012-08-01 06:32:06 UTC
*** Bug 216217 has been marked as a duplicate of this bug. ***
Comment 10 grafviktor 2012-08-21 10:37:47 UTC
Gents, just to let you know, today i tried to use nightly build to find out if the problem was fixed, unfortunately hot deploy still is not working. Except for this I'm not able to deploy maven EAR Applications to Glassfish Server even manually. When i'm trying to depoy it i'm getting an exception:
========================================
In-place deployment at C:\root\programming\NBProjects\TestMavenProj2\TestMavenProj2-ear\target\TestMavenProj2-ear-1.0-SNAPSHOT
Initializing...
deploy?DEFAULT=C:\root\programming\NBProjects\TestMavenProj2\TestMavenProj2-ear\target\TestMavenProj2-ear-1.0-SNAPSHOT&name=file:_C:_root_programming_NBProjects_TestMavenProj2_TestMavenProj2-ear_&force=true failed on GlassFish Server 3+ 
 Error occurred during deployment: Exception while deploying the app [file:_C:_root_programming_NBProjects_TestMavenProj2_TestMavenProj2-ear_] : Expected to find an expanded directory for submodule TestMavenProj2-ejb-1.0-SNAPSHOT.jar but found a JAR.  If this is a directory deployment be sure to expand all submodules.. Please see server.log for more details.
The module has not been deployed.
See the server log for details.
	at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:210)
	at org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:178)
	at org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:130)
	at org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212)
	at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
========================================
It was tested on NetBeans IDE Dev (Build 201208110001) and 
NetBeans IDE Dev (201208200933)
OS Windows XP SP3
Java 1.7.0_05
GlassFish 3.1.2
Comment 11 daedalus 2012-08-21 13:05:22 UTC
(In reply to comment #10)
> Gents, just to let you know, today i tried to use nightly build to find out if
> the problem was fixed, unfortunately hot deploy still is not working. Except
> for this I'm not able to deploy maven EAR Applications to Glassfish Server even
> manually. When i'm trying to depoy it i'm getting an exception:
> ========================================
> In-place deployment at
> C:\root\programming\NBProjects\TestMavenProj2\TestMavenProj2-ear\target\TestMavenProj2-ear-1.0-SNAPSHOT
> Initializing...
> deploy?DEFAULT=C:\root\programming\NBProjects\TestMavenProj2\TestMavenProj2-ear\target\TestMavenProj2-ear-1.0-SNAPSHOT&name=file:_C:_root_programming_NBProjects_TestMavenProj2_TestMavenProj2-ear_&force=true
> failed on GlassFish Server 3+ 
>  Error occurred during deployment: Exception while deploying the app
> [file:_C:_root_programming_NBProjects_TestMavenProj2_TestMavenProj2-ear_] :
> Expected to find an expanded directory for submodule
> TestMavenProj2-ejb-1.0-SNAPSHOT.jar but found a JAR.  If this is a directory
> deployment be sure to expand all submodules.. Please see server.log for more
> details.
> The module has not been deployed.
> See the server log for details.
>     at
> org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:210)
>     at
> org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:178)
>     at
> org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:130)
>     at
> org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212)
>     at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
> ========================================
> It was tested on NetBeans IDE Dev (Build 201208110001) and 
> NetBeans IDE Dev (201208200933)
> OS Windows XP SP3
> Java 1.7.0_05
> GlassFish 3.1.2

I can confirm this behavior!
Comment 12 Tomas Danek 2012-08-27 13:23:37 UTC
Martine, will you have a chance to look at it soon, so that fix could get to 72patch1? ( Fri 09/31 is boundary for patch backports)
Comment 13 Martin Janicek 2012-08-27 13:33:44 UTC
Sure, I'm on it..
Comment 14 Martin Janicek 2012-08-29 14:39:32 UTC
The regression is caused by the changes made in revision http://hg.netbeans.org/web-main/rev/c0142fef8c9a
Milosi would it be safe to revert the changes?
Comment 15 Martin Janicek 2012-08-29 14:44:37 UTC
Two more issues (217480, 215274) were introduced by that revision.
Comment 16 Milos Kleint 2012-08-29 15:46:36 UTC
(In reply to comment #14)
> The regression is caused by the changes made in revision
> http://hg.netbeans.org/web-main/rev/c0142fef8c9a
> Milosi would it be safe to revert the changes?

It's probably fine to revert changeset that BUT as ProjectInformation's javadoc says: 

"Get a programmatic code name suitable for use in build scripts or other references."

So your code has some sort of assumptions about what will be there and/or you are leaking the name to the user, even though it displayName should be used in such cases. 

So I assume you will fix issue 215274 not just by reverting this changeset but by changing the code not to depend on project name.

same with issue 217480, the name should not be leaked into the UI (in form of persistence unit name)

I'm not very clear why the new name is causing problems in the current issue so I'm leaving that one out..


But once reverting the changeset, we are back at the beginning where loading the model just to get ProjectInformation.getName() is CPU expensive in some cases. The ant project's idea of folder name == project name (more or less) won't scale for hundreds of related projects that are fairly common in maven projects.
Comment 17 Martin Janicek 2012-08-29 16:10:46 UTC
(In reply to comment #16)
> (In reply to comment #14)
> > The regression is caused by the changes made in revision
> > http://hg.netbeans.org/web-main/rev/c0142fef8c9a
> > Milosi would it be safe to revert the changes?
> 
> It's probably fine to revert changeset that BUT as ProjectInformation's javadoc
> says: 
> 
> "Get a programmatic code name suitable for use in build scripts or other
> references."
> 
> So your code has some sort of assumptions about what will be there and/or you
> are leaking the name to the user, even though it displayName should be used in
> such cases. 

Definitely agree, but the code assumptions are made in a different areas (in case of issue 217480 it's Persistence UI and in case of issue 215274 it's Glassfish server UI).

> So I assume you will fix issue 215274 not just by reverting this changeset but
> by changing the code not to depend on project name.
> 
> same with issue 217480, the name should not be leaked into the UI (in form of
> persistence unit name)

Ok, I'll revert the changeset and file new tickets to the areas where the change from getName() to getDisplayName() needs to be done - we should probably make those two things separate so the patch for 7.2.1 will be as small as possible.

> 
> I'm not very clear why the new name is causing problems in the current issue so
> I'm leaving that one out..
> 
> 
> But once reverting the changeset, we are back at the beginning where loading
> the model just to get ProjectInformation.getName() is CPU expensive in some
> cases. The ant project's idea of folder name == project name (more or less)
> won't scale for hundreds of related projects that are fairly common in maven
> projects.

I'm aware of that and in the long term we should probably made the change anyway, but it should be done together with evaluation of the getName() usages (as it looks it's badly use in many cases)..
Comment 18 Martin Janicek 2012-08-30 09:55:02 UTC
Fixed in: web-main #cf6a199bfed4
(actually it's only reverted revision #c0142fef8c9a)

Vlado, could you please verified?
Comment 19 Vladimir Riha 2012-08-30 15:06:41 UTC
verified against case in comment #3

Product Version: NetBeans IDE Dev (Build web-main-8358-on-20120830)
Java: 1.7.0_03; Java HotSpot(TM) Client VM 22.1-b02
System: Windows 7 version 6.1 running on x86; Cp1252; en_US (nb)
Comment 20 Martin Janicek 2012-08-30 15:54:00 UTC
Thanks Vlado for verification!

At the end it looks like the two problems were mixed up. Revision c0142fef8c9a wasn't as a part of the NetBeans 7.2FCS (because of that I think that only the first changeset from comment 5 needs to be transplanted). The second one (from the comment 18) is relevant only for trunk..

I've transplanted revision from comment 5 in:
- http://hg.netbeans.org/releases/rev/e422546e8548

...and increase specification version number + change long description in:
- http://hg.netbeans.org/releases/rev/f3fc5886aa5a

Would be really good to test it again with the release branch sources. I've done that, but only on Ubuntu Linux, because I don't have release72 branch cloned on Windows.
Comment 21 rbento 2012-08-30 18:05:19 UTC
Thanks a lot for this fix.

Is it already available to download from trunk build? I may test it on Windows 7 64 when it is.

Hugs!
Comment 22 Quality Engineering 2012-08-31 02:00:22 UTC
Integrated into 'main-golden', will be available in build *201208310001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/cf6a199bfed4
User: Martin Janicek <mjanicek@netbeans.org>
Log: #215976 - Redeployment doesnt works for maven EAR project.
Comment 23 Martin Janicek 2012-08-31 08:12:02 UTC
Yes rbento, it is available in the todays nighly build (http://bits.netbeans.org/dev/nightly/2012-08-31_00-01-28/). Would be great if you could test it as well. Thanks!
Comment 24 Martin Janicek 2012-08-31 08:46:29 UTC
I've tested it again at home on Windows XP and it works just fine. (again saying that it would be good to test the issue on release branch sources as well)
Comment 25 rbento 2012-08-31 14:50:44 UTC
Created attachment 123782 [details]
Screenshot to show the messed application name.

Please, notice the application name.
Comment 26 rbento 2012-08-31 14:56:19 UTC
I've tested it and the redeployment works but with a caveat.

The application name is still messed up.

There is a thread in GlassFish jira but it seems to be a problem with netbeans when deploying the app to the gfdeploy folder.

What happens is that when the application name is messed up, redeployment works. When it is correct, redeployment doesn't work.

For example, the application is deployed to the gfdeploy folder with name  

   - com.mycompany_mavenproject1-ear_ear_1.0

instead of 

   - com.mycompany.mavenproject1-ear-1.0

It breaks portable JNDI names when finding resources by lookup.

If you deploy the EAR to GlassFish via web console or autodeploy directory the application name is correct.

Could you please take a look?
Comment 28 Petr Jiricka 2012-08-31 16:05:36 UTC
Let's track that as a separate issue. Can you please file a new bug report?
Comment 29 rbento 2012-08-31 16:12:03 UTC
Hello,

I tested again the following scenario and found some issues:

 - Clean Netbeans 201208310001 install without GlassFish
 - Download Glassfish 3.1.2.2 zip.
 - Unzip it to a folder. (C:\Servers\glassfish-3.1.2.2)
 - Used the same application 'mavenproject1'.
 - Select app > Clean/Build > Right click and run on EAR module.
 - The application is deployed but it is not shown under Services > Server >
Your GF Instance > Applications. (Even if you keep refreshing it)
 - Redeployment doesn't work.

Another test case:

 - Have 2 simple apps mavenproject1 and mavenproject2
 - Open both, Clean/Build both, deploy both. Redeployment works.
 - Stop GlassFish.
 - Close one of the apps. Clean/Build the other.
 - Run it. 
 - You will notice that the closed application is deployed even if it is
closed.

Sorry, I was testing deployment now. I will file another issue for the
application name. 

Thanks a lot.
Comment 30 Quality Engineering 2012-09-01 11:10:27 UTC
Integrated into 'releases', will be available in build *201209010822* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/e422546e8548
User: Martin Janicek <mjanicek@netbeans.org>
Log: #215454 + #215976 - Redeployment doesnt works for maven EAR project.
(transplanted from 752b7ed13c511ee8162c89e84718de2b0931dc1f)
Comment 31 Martin Janicek 2012-09-01 16:04:42 UTC
(In reply to comment #28)
> Let's track that as a separate issue. Can you please file a new bug report?

Issue 215274 already exists to track this one. The problem lies in the Glassfish module (see issue 217619 for some details) which is using wrong Maven API method.
Comment 32 Martin Janicek 2012-09-01 16:18:10 UTC
(In reply to comment #29)
> Hello,
> 
> I tested again the following scenario and found some issues:
> 
>  - Clean Netbeans 201208310001 install without GlassFish
>  - Download Glassfish 3.1.2.2 zip.
>  - Unzip it to a folder. (C:\Servers\glassfish-3.1.2.2)
>  - Used the same application 'mavenproject1'.
>  - Select app > Clean/Build > Right click and run on EAR module.
>  - The application is deployed but it is not shown under Services > Server >
> Your GF Instance > Applications. (Even if you keep refreshing it)
>  - Redeployment doesn't work.

Was the application deployed for the first time? I mean you were able to see index.html with "Hello World!" text in the browser, right?
Not sure if the issue is the same as the initial one, that's why I'm asking..

> 
> Another test case:
> 
>  - Have 2 simple apps mavenproject1 and mavenproject2
>  - Open both, Clean/Build both, deploy both. Redeployment works.
>  - Stop GlassFish.
>  - Close one of the apps. Clean/Build the other.
>  - Run it. 
>  - You will notice that the closed application is deployed even if it is
> closed.

Doesn't sound like a bug to me. As far as I know typically you need to undeploy your application manually (NetBeans don't do that when closing the project). Maybe I'm wrong but this behavior seems to me correct.

> 
> Sorry, I was testing deployment now. I will file another issue for the
> application name. 
> 
> Thanks a lot.
Comment 33 Jiri Skrivanek 2012-09-05 11:51:31 UTC
Test case in comment 3 works for me. I can't reproduce other problems mentioned by rbento. Also if project is closed it is not undeployed. Only the clean action does undeploy or you have to undeploy in Services view. I think you agree that redeployment works now. If you encounter a different problem, please file a new bug. Thank you.
Comment 34 athompson 2013-04-30 00:50:22 UTC
Not working again in 7.4 daily, except when you save edits to a module Netbeans claims the ear was deployed in the status bar. To state the obvious, the "target/gfdeploy" folder does not reflect the changes.


Product Version: NetBeans IDE Dev (Build 201304252301)
Updates: Updates available
Java: 1.7.0_21; Java HotSpot(TM) 64-Bit Server VM 23.21-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_21-b12
System: Mac OS X version 10.8.4 running on x86_64; US-ASCII; en_US (nb)
User directory: /Users/alvin/Library/Application Support/NetBeans/dev
Cache directory: /Users/alvin/Library/Caches/NetBeans/dev
Comment 35 Petr Jiricka 2013-04-30 05:53:18 UTC
Could this be a duplicate of bug 226298? Jirko, do you know if this is also a problem in 7.3.1, or only in 7.4? Thanks.
Comment 36 Jiri Skrivanek 2013-04-30 11:03:02 UTC
It works for me in 7.3.1 dev build in Maven EAR EE6 project with GlassFish 4.

Product Version: NetBeans IDE Dev (Build web-main-javaee7-270-on-20130429)
Java: 1.7.0_17; Java HotSpot(TM) 64-Bit Server VM 23.7-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_17-b02
System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)
Comment 37 Martin Janicek 2013-04-30 13:58:36 UTC
Maybe we should create another ticket (with TM = 7.4 and whiteboard containing "731-not-a-stopper") for for the current problem. It is most probably unrelated with respect to the fix, only the steps are identical.
Comment 38 Martin Janicek 2013-05-03 12:57:49 UTC
With respect to the comment 37 (don't like the mess here to be honest:)) I have created identical issue 229328 with correct TM, whiteboard, etc. --> Closing this one. Anyone interested, please follow 229328 instead. Thanks


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