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.
Summary: | Maven WAR plugin "packagingExcludes" rules are ignored configuration in "gfdeploy" Folder | ||
---|---|---|---|
Product: | javaee | Reporter: | daedalus |
Component: | Maven | Assignee: | Martin Janicek <mjanicek> |
Status: | NEW --- | ||
Severity: | normal | CC: | mkleint, mmirilovic, pjiricka |
Priority: | P2 | ||
Version: | 7.2 | ||
Hardware: | PC | ||
OS: | All | ||
URL: | http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: | Example Project |
Description
daedalus
2012-06-11 11:16:28 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 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. 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)
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. |