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.
Product Version = NetBeans IDE 7.1 (Build 201112071828) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.7.0 Runtime = Java HotSpot(TM) 64-Bit Server VM 21.0-b17 I am getting the following error deploying to Tomcat... NetBeans: Deploying on Apache Tomcat 6.0.26.0 profile mode: false debug mode: true force redeploy: true Checking data source definitions for missing JDBC drivers... Starting Tomcat process... Waiting for Tomcat... Tomcat server started. Deployment error: No archive for deployment See the server log for details. at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:245) at org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:179) at org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:131) at org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:211) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153) Caused by: java.lang.IllegalArgumentException: No archive for deployment at org.netbeans.modules.j2ee.deployment.impl.TargetServer.deploy(TargetServer.java:680) at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:197) ... 4 more I can get around the problem by changing the following line in my POM.. <finalName>${project.artifactId}-${project.version}-r${build.number}</finalName> to... <finalName>${project.artifactId}-${project.version}</finalName> Why the build number matters I don't know. I have the build.number added as a property in the nbactions.xml .... <properties> <netbeans.deploy.debugmode>true</netbeans.deploy.debugmode> <netbeans.deploy>true</netbeans.deploy> <build.number>99999</build.number> </properties> The archive is built correctly and does exist in my target directory. I have tried both Tomcat 6.0.26.0 and 7.022.0 with the same results.
To reproduce this... Create a Maven web application. 1. Pick all the defaults. 2. Open the POM. 3. Add the following to the POM build section... <finalName>${project.artifactId}-${project.version}-r${build.number}</finalName> 4. Right-click on the project -> open properties -> Actions -> Select Debug Project via Deploy 5. Add build.number=99999 to Set Properties. 6. Debug the project.
BaseEEModuleImpl.getArchive() returns the wrong archive. I guess build number is not valuated.
Reproducible. The problem is that you have the build.number located in nbactions.xml instead of having it in pom.xml ..because of that finalName looks in pom model like this: "mavenproject1-1.0-SNAPSHOT-r${build.number}" You can easily correct it by moving build.number to pom.xml properties. I'm not sure yet if the behavior is correct or if we should try to use properties from nbactions.xml as well.
That doesn't appear to be the case this is my nbactions.xml <?xml version="1.0" encoding="UTF-8"?> <actions> <action> <actionName>run</actionName> <preAction>build-with-dependencies</preAction> <goals> <goal>package</goal> </goals> <properties> <netbeans.deploy>true</netbeans.deploy> </properties> </action> </actions> yet i get the same error, it deploys fine using 7.1.2 so this is a regression
For me it doesn't work even in NetBeans 7.1.2 thus it is not a regression. Because easy workaround is described in comment 3 I would recommend to fix it in next release.
Milosi what do you think it's a correct solution here? Is it correct that user can write/paste properties directly in Actions customizer?
(In reply to comment #6) > Milosi what do you think it's a correct solution here? Is it correct that user > can write/paste properties directly in Actions customizer? there's 2 things here: 1. what gets passed to the maven's jvm. For that adding props to nbactions.xml is correct 2. what gets read from the effective pom in IDE's jvm. That's *not* influenced by nbactions.xml but only by pom.xml content and also configurations (which enable profiles and set props) if you are dealing with RunConfig instances (eg. in PrerequisitesChecker instances) then you should not use the MavenProject from Project but from RunConfig. That one will have the props from execution injected. Not sure if that's the case or if it's desirable to setup the project that way.
After off-line discussion with Milos, I'm closing the issue as WONTFIX. It's not possible to simply evaluate properties from nbactions.xml and they should be located either in pom.xml or in nb-configuration.xml.