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.
In 'normal' netbeans Web Projects there is an option to NOT create a .war, during deployment to the server, since this takes quite some time to deploy on the server. Please provide this option in the maven web project as well.
well, "mvn install" always creates the war file. not to create the war file, one would have to run something like "mvn compile war:exploded" or "mvn compile war:inplace" and map it to "Build/Run" action in the IDE. The j2ee maven support shall be able to get away without the war file. It's even capable of figuring out that you use war:inplace and redirect the deployment there. There's just no UI for that and hardly will in 6.0 timeframe. However please not that not all app server are capable of deploying without a war file.. AFAIK at least.
Thats true, but developing for testing purposes without a war file in debug mode is IMHO the only viable option, since bugfixing is in this way just fastest. Also the pure waiting time to deploy a project is reduced enormously. Most of my collegues usually use eclipse with the tomcat plugin together with a plugin called DevLoader, which instantly changes the ClassLoader for tomcat when a source file changed. This works also perfectly in a 'normal' webproject under NB by disabling the checkbox for 'Create War' under Packaging. I think just for consistency and for easy of development this should also be possible for maven projects :)
as I said mapping "war:inline" instead of the default "mvn install" will not use the war file but the expanded webapp, at least on the servers that support it, (see http://jira.codehaus.org/browse/MEVENIDE-451) a simple checkbox in project customizer is a post 6.0 feature. I'm not 100% positive on what the algorithm is by which the war deployment or expanded web app deployment is chosen. Stepane, can you clear that up for me? thanks.
It depends on the server plugin which way of deployment it uses. As far as I know the current server plugins support these deployment modes Tomcat - in-place AppServer/GlassFish: local - in-place and archive, remote - archive JBoss - archive WebLogic - archive The following method can be used to determine which way the given module can be deployed to the given server: org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.canFileDeploy
see issue #97118 (http://www.netbeans.org/issues/show_bug.cgi?id=97118)
There really should be a fix to this problem. For my current project it takes about 1-1 1/2 mins to start the server (with the project). During jsf/jsp development there is vertually no other option but to develop in debug mode with hot code replacement. Restarting the server everytime after I changed something in the look and feel is no alternativ. And usually I need just tomcat for testing locally, deployment happens on jboss, where i don't need in-place functionality. Sadly for that reason I need to develop in eclipse right now, since you can do that with a maven project. I'd much more enjoy coming back to Nb.
jsp files shall be copied over to deployment area immediately after you save them (or anything under src/main/webapp for that matter. if the server supports in place deployment, it works fine for me. What I did: create new maven webapp. add glassfish as server, set the maven project to deploy on gf. deploy. open the index.jsp file and change "Hello world" to "bye world". save the file. hit refresh in the browser. "Bye world" appears.
Yes - thats true, for some reason I thought this was not working. Still: .) It seems that facelet tags (eg. mytag.xhtml) that I created in in src/main/resources/META-INF/facelets/tags with a mytag.taglib.xml in src/main/resources/META-INF/ are not being updated if I change them. .) It is not possible to 'Apply Code Changes' if for example I change the backing bean... Or is this just not working for me?
changes in src/main/resources are now copied over to deployed area upon modification.
Great! Thanx! I know it is bad programming style to put resources files elsewhere, but .) what if resource files are somewhere else (src/main/java)? .) or 'src/otherJavaFolder', configured under <build>/<sourceDirectory>? .) what if under <build>/<resources> in the pom file you configured other resources folders? But maybe this request belongs to a new feature request, since this request is about not creating a .war file while deployment. Shall I also open a separate enhancement request for the 'Apply changes' feature while debugging?
my previous comment was wrong, I actually use the resource definition from pom.xml HOWEVER I don't take include/excludes into accound, nor do I take <targetDirectory> or filtering into account. But that's indeed a different issue then.
Does the watching of resources under src/main/resources also work in subdirectories ? I have a package structure corresponding to the java packages (e.g. src/main/resources/foo/bar/baz for classes in package foo.bar.baz) and a Index.tml file in it ( a Tapestry 5 template). Changes to the tml file are not reflected in the running app until I run a build that copies them over. Also, is there a restriction on the extension of the files that do get copied over when they're changed ? On the same token, when I place the .tml in the web context folder, they are automatically copied into the running application when they change.
well, I was wrong. The copying of resources only happens in docbase (thus under src/main/webapp), not for any resources root.
Can we add an option to copy the files out of the resources area to the deployment area as well ? Is there a technical hurdle to doing so ( I think you had mentioned somewhere else that because of Maven filtering, one might need to call the resources plugin). I'll probably check out the maven plugin sources, as I want to do too many things that are not yet supported... The beauty of open source !!! :-)
I was looking at the source of J2eeLookupProvider in the Maven J2EE Bridge model and looking at the source, it looks like it is attempting to handle resources living in subdirectories under resources. Is this something that was recently added to address this issue, or maybe am I just misreading the code ?
akochnev: findAppropriateResourceRoots() in CopyOnSave.java seems to check resources, however the resource roots are taken into account when listening of filesystem changes. We listen on the whole filesystem though so it should not matter much, only if you don't have the document root at src/main/webapp, then the listener is not attached and no changes are fired. see smallinitialize() in CopyOnSave. That would be a separate issue I guess.
See the code below to address an issue w/ the current CopyOnSave. In its current state, the resources from src/main/resources (e.g. package foo.bar.baz) get copied into [project_home]/target/[web_app_name]/foo/bar/baz, instead of [project_home]/target/[web_app_name]/WEB-INF/classes/foo/bar/baz. The code below also copies the resources into the output directory (e.g. [project_home]/target/classes/foo/bar/baz). --------------- FileObject webAppClassesDir = webBuildBase.getFileObject("WEB-INF/classes"); FileObject destFile = ensureDestinationFileExists(webAppClassesDir, path, fo.isFolder()); copySrcToDest(fo, destFile); String projClassesPath = mavenproject.getMavenProject().getBuild().getOutputDirectory(); ileObject targetClasses = FileUtil.toFileObject(new File(projClassesPath)); destFile = ensureDestinationFileExists(targetClasses, path, fo.isFolder()); copySrcToDest(fo, destFile);
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss