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.
How to reproduce: 1. Create a webapp 2. Use the Library Manager to create a "Class Library": in the Classpath tab add a folder and not a JAR. I added a dir which contained a com/foo/bar/ hierarchy. 3. Add this Class Library to the Compilation classpath of the project in Project Properties/Build/Compiling Sources You will see that compilation works. This meas you can import com.foo.bar and use the classes in the added library. Now try to run the webapp. You'll see that the used classes of the lib are not found BECAUSE your deployment puts the com/foo/bar/ hierarchy in /WEB-INF/lib which does not work, becuase tomcat only loads JARs from this directory! A fix would be to copy com/foo/bar/ instead to /WEB-INF/classes where tomcat accepts those hierarchies. Or JAR them together before putting them in /WEB-INF/lib.
I agree this is a problem. Not sure I will be able to solve it as suggested. A library can consist of a mix of jar files and folders. I will have to implement parsing of library path (see 50676) and maybe then I can test if each entry is a file or jar and generate zip (or copy to classpath).
See issue 56420 for similar problem with Folders on classpath.
fixed the problem with libraries containing folders. Now when there is at least one folder in a library a <path-in-war-classes>WEB-INF/classes</path-in-war-classes> element is created under the library element in project.xml and then the buildscript copies all directories into this location. Checking in classpath/ClassPathSupport.java; /cvs/web/project/src/org/netbeans/modules/web/project/classpath/ClassPathSupport.java,v <-- ClassPathSupport.java new revision: 1.9; previous revision: 1.8 done Checking in resources/build-impl.xsl; /cvs/web/project/src/org/netbeans/modules/web/project/resources/build-impl.xsl,v <-- build-impl.xsl new revision: 1.87; previous revision: 1.86 done
Can you put it in the Update Center?
It will be in next published daily build (in couple of days). We don't plan to put it on Update Center - Update Center is for finished releases and 4.1 is not finished yet.
Marku, I see 2 problems with the way you solved this. First, there is a regression - you cannot package additional content into another folder, it always ends up in WEB-INF/classes. Second, path-in-war-classes is not in xml schema for web project. I do not understand why you need this tag. The correct solution would be test the combination when you are in web-module-libraries tag and you have a folder to copy - then copy it into WEB-INF/classes.
Pavle, I admin that introducing the <path-in-war-classes> tag wasn't the best idea, I just wanted to be consistent with <path-in-war> and didn't want to hardcode WEB-INF/classes into the buildscript. Now when I thought through deeply I must agree with you - I will remove it and hardcode the WEB-INF/classes into the script. Sometimes less is more ;-) As for the regression, I cannot reproduce - it works for me. Whatever I fill in the path in war in the project customizre is copied there. Nevermind, I will rewrite the code anyway. I appreciate your comments Pavle. Thanks.
to make sure I made myself clear, the regression is (at least what I see): 1. create a web project (X) 2. create a library (Y), add a jar file and a non empty folder 3. open project X's properties, goto Build | Packaging, Add Library Y, set Path in War to 'aaa' 4. Build the project, what I see is that the jar file in Y is copied into web\aaa but the content of the folder in Y gets copied into WEB-INF/classes If this works for you can QE confirm it also works for them? Thanks.
I reverted the changes done to ClassPathSupport and build-impl.xml and fixed in again only in build-impl.xml. Now it should be OK. I had a very bad day yesterday :-). I am sorry for the complications. Now both folders directly added to compilation libraries and folders within a user defined library are copied into WEB-INF/classes. The additional content libraries are not affected at all - they are always copied into location defined in path-in-war. Checking in build-impl.xsl; /cvs/web/project/src/org/netbeans/modules/web/project/resources/build-impl.xsl,v <-- build-impl.xsl new revision: 1.89; previous revision: 1.88 done The fix is only one line fix :-) See the diff: 849c849 < <xsl:with-param name="target" select="concat('${build.web.dir.real}/',$copyto)"/> --- > <xsl:with-param name="target" select="concat('${build.web.dir.real}/','WEB-INF/classes')"/>
Verified in build 200503172015.