This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 213960 - Maven WAR plugin "packagingExcludes" rules are ignored configuration in "gfdeploy" Folder
Summary: Maven WAR plugin "packagingExcludes" rules are ignored configuration in "gfde...
Status: NEW
Alias: None
Product: javaee
Classification: Unclassified
Component: Maven (show other bugs)
Version: 7.2
Hardware: PC All
: P2 normal (vote)
Assignee: Martin Janicek
URL: http://maven.apache.org/plugins/maven...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-11 11:16 UTC by daedalus
Modified: 2015-06-01 12:44 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Example Project (3.17 KB, application/x-7z-compressed)
2012-06-18 11:25 UTC, daedalus 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description daedalus 2012-06-11 11:16:28 UTC 
I noticed, that Netbeans ignores the "packagingExcludes" configuration parameter from the Maven WAR plugin if it is responsable for deploying the application.  

We have an EAR Project with multiple WAR files. To avoid multiple packaging of our libraries we have enabled the skinny war feature. All our libraries are packed in the ear file and removed from the  "WEB-INF/lib" Folder of the WAR files. 

To archive this we have our WAR Projects configured like this: 
<build>
   <plugins>
      <plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-war-plugin</artifactId>
            <configuration>
            <!-- Remove all *.jar Files from the war projects (skinny wars) -->
              <packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>
            </configuration>
      </plugin>
   </plugins>
</build>

This works without problems if we build the the project and deploy the generated EAR archive by ourself. 

However if we let Netbeans deploy the Application, Netbeans is generating a folder "gfdeploy". In this folder all excluded libraries are back in the "WEB-INF/lib" Folder of every WAR Project. This causes class loading errors and our application cannot be deployed anymore.
Comment 1 Martin Janicek 2012-06-14 12:47:15 UTC 
Actually, I don't think we have ever supporting skinny war feature --> Changing to enhancement and setting TM = Next, since we are already after code freeze for 7.2.

Anyway I can imagine that it might be annoying and I'll try to do this for the next version (hopefully there will be enough of time). Daedalus would it be possible to attach your project (or create a simple one if the original one is closed-source) ?.. I don't have any project configured like this and would be good to have one for testing.
Thanks in advance
Comment 2 Petr Jiricka 2012-06-14 13:15:39 UTC 
One idea, would an acceptable solution for you be to declare the jar files as dependencies with the "provided" scope in the web module project? That way, you can compile against them, but they are not copied to WEB-INF/lib. This is the approach NetBeans generally recommends when developing EAR projects.
Comment 3 daedalus 2012-06-18 11:25:34 UTC 
Created attachment 120975 [details]
Example Project

Sorry it took me a while. 

This example Project is build correctly by Maven. If the ear file is deployed by copying the  SkinnyWar-ear-1.0-SNAPSHOT.ear in my Glassfish "autodeploy" folder the project will deploy and work as excepted. 

If I deploy the Project with Netbeans the library will be duplicated and the project cannot be deployed to Glassfish.

Here the exception: 

 WELD-001409 Ambiguous dependencies for type [CDIClass] with qualifiers [@Default] at injection point [[field] @Inject private com.mycompany.SomeWarClass.cdiExample]. Possible dependencies [[Managed Bean [class com.mycompany.skinnywarlibrary.CDIClass] with qualifiers [@Any @Default], Managed Bean [class com.mycompany.skinnywarlibrary.CDIClass] with qualifiers [@Any @Default]]]
org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [CDIClass] with qualifiers [@Default] at injection point [[field] @Inject private com.mycompany.SomeWarClass.cdiExample]. Possible dependencies [[Managed Bean [class com.mycompany.skinnywarlibrary.CDIClass] with qualifiers [@Any @Default], Managed Bean [class com.mycompany.skinnywarlibrary.CDIClass] with qualifiers [@Any @Default]]]
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:277)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:243)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:126)
	at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:345)
	at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:330)
	at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:366)
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:199)
	at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:313)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
	at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
	at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
	at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
	at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
	at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
	at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
	at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
	at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
	at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
	at java.lang.Thread.run(Thread.java:722)
Comment 4 the_noid 2015-06-01 12:44:11 UTC 
I've just ran into a similar issue deploying a maven (war) project to Wildfly, with Netbeans 8.0.2.

When deploying to a local JBoss 7 installation, Netbeans copies the war file. 

However, when deploying to a local Wildfly 8 installation, Netbeans seems to copy the maven Assembling directory. This directory still contains files that are excluded from the war by the Maven war plugin using the packagingExcludes.