Community
Participate
Working Groups
Build ID: I20090528-2000 Steps To Reproduce: 1. create a dynamic Web Project 2. set "WebContent/WEB-INF/classes" as Java output folder 3. add a classpath container (user library, for instance) to the Java classpath of the project 4. add the classpath container to the project using the Java EE Module dependencies preference page 5. deploy the project to some server 6. no one library from the container created in step 4 is deployed More information: J2EEFlexProjDeployable.isSingleRootStructure() returns true for this project; the members method skips adding libraries from a classpath container. Attached is a patch. A workaround is to change the Java output folder, open, close and redeploy the project
Created attachment 138492 [details] a patch
Note: this is easy to bump into if you use tools like m2eclipse or ivy which uses classpath containers to provide libraries.
Moving to JEE team, believe this might be a dup.
I think this is related to bug 249044 - assigning it to Jason Sholl for initial investigation.
This was mentioned in Bug 277482 but had not been given its own bug ID yet. > 5) You can add classpath variable entries.... however if I made a > variable that pointed directly to /home/rob/tmp/some2.jar, and apply > the change, the following gets added to the component xml file: > > <dependent-module deploy-path="/" > handle="module:/classpath/var/some2"> > <dependency-type>uses</dependency-type> > > But upon a publish this file is not included. Upon an export, this > file *is* included, but it's name is "some2" and it lacks a file > extension. Therefore I don't believe Snjezana's patch is complete as it only addresses the publish instance and not the export.
> Therefore I don't believe Snjezana's patch is complete as it only addresses the publish instance and not the export. The problem that I described doesn't happen when exporting.
I like Snjezana's patch as it looks like it would work properly... however, better question is should isSingleRootStructure return true at all if there are references? javadoc says the following: * In a single root structure, all files that are contained within the root folder * are part of the module, and are already in the correct module structure. No * module resources exist outside of this single folder. The key part being "No module resources exist outside of this single folder". So is a project with classpath / var / lib references outside the project "single root" ?
After finding some more comments, I don't think this patch is the right way to go. isSingleRootStructure() must be modified to check for virtual component variable references. Note the comments below /** * This method is added for performance reasons. It can ONLY be called when the project is single root. * @see isSingleRootStructure(). If the project has an output folder that is also a source folder then, * it assumes the virtual component is not using any flexible features and is in a standard J2EE format * with one component root folder and an output folder the same as its content folder. This will bypass * the virtual component API and just return the module resources as they are on disk. * * @return array of ModuleResources * @throws CoreException */ private IModuleResource[] getOptimizedMembers() throws CoreException { if (component != null) { if (isSingleJavaOutputNonSource) { // We determined when testing for a single root structure that this project has // one output folder and that output folder is not a source folder. Since the // output folder (for example, classes or bin) is not a source folder, JDT copies all files // (including non Java files) to this folder, so every resource needed at runtime is located // in that single output directory. return getModuleResources(Path.EMPTY, getJavaOutputFolders()[0]); } // For J2EE modules, we use the contents of the content root else { IVirtualFolder vFolder = component.getRootFolder(); return getModuleResources(Path.EMPTY, vFolder.getUnderlyingFolder()); } } return new IModuleResource[] {}; } I would conjecture that if there are any references to external jars, then it is *not* in the single root structure.
We're going to be addressing isSingleRoot() in WTP 3.2, and will back-port as much as possible to 3.1.2.
Snjezana, a lot of work has been done in this area for WTP 3.2... is this still a problem?
In response to comment number 5 the reason this was not working for export is because you needed to extend the variable. It was not working for deploy because we never computed the variable and external jar entries for a single root project. However, I recently addressed in issue with this in bug 306534 and now variables and external jars will be returned as child modules as long as they qualify. However, it is up to server tools to get these child modules and process them properly. Not sure if this is happening in all cases. Classpath containers, which get added into the classpath file with the dependency attribute, are now checked in the single root util. If found it now returns false.
(In reply to comment #11) > In response to comment number 5 the reason this was not working for export is > because you needed to extend the variable. You do not, and should not, need to extend a variable which references a jar. If the variable references a folder, then of course you need to extend it. However if the variable just references a single jar, it doesn't need to be extended. In comment 5, I believe it was just against a jar (like rt.jar or something). So lets just make sure thats a tested usecase too ;)
