Community
Participate
Working Groups
Build Identifier: I20110613-1736 Hi, I'm trying to hack in support for mavenized JBoss SAR projects in JBoss Tools (https://issues.jboss.org/browse/JBIDE-9127) So far I've been adding the Utility Facet to such projects, so they can be deployed in EARs. A SAR project can embed dependencies in a lib folder, inside the archive. A loooong time ago, when I tried it on a POC, the fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=298735 made it possible to work. In this use case, I have 2 sample maven-less projects : -sarproject : has a dependency to JUNIT_HOME\junit.jar in the module assembly page. The resulting org.eclipse.wst.common.component contains : <project-modules id="moduleCoreId" project-version="1.5.0"> <wb-module deploy-name="sarproject"> <wb-resource deploy-path="/" source-path="/src"/> <dependent-module archiveName="junit.jar" deploy-path="/lib" handle="module:/classpath/var/JUNIT_HOME/junit.jar"> <dependency-type>uses</dependency-type> </dependent-module> </wb-module> </project-modules> -earproject : needed so sarproject can be a Module project. I've manually tweaked org.eclipse.wst.common.component so sarproject will have the .sar extension when deployed. Here is the end result : <project-modules id="moduleCoreId" project-version="1.5.0"> <wb-module deploy-name="earproject"> <wb-resource deploy-path="/" source-path="/EarContent"/> <dependent-module archiveName="sarproject.sar" deploy-path="/" handle="module:/resource/sarproject/sarproject"> <dependency-type>uses</dependency-type> </dependent-module> </wb-module> </project-modules> Unfortunately, it seems a regression has crept in, because using these projects, the embedded jar (junit.jar) is no longer present inside the sarproject.sar, when earproject is deployed on (any) JBoss AS (https://issues.jboss.org/browse/JBIDE-9496). I know that, since it's a hack, you might be tempted to not fix it but, if you export the ear project, everything works fine. So you have an inconsistent behaviour between export and deployment AHAAAAH!!! And, I might have other use cases where this whole Utility facet + embedded jars might be useful, so I think it should be fixed :-) Reproducible: Always
Created attachment 201220 [details] Sample projects to reproduce the issue
Quoting Rob Stryker from https://issues.jboss.org/browse/JBIDE-9496 : "The utility project is being identified as a "single root" project. There seems to be a bug in the single root handler (an efficient handler for specific cases) where it ignores references that are not child modules. Workaround is to make your project NOT single root. Steps to do that include: 1) Adding a new folder to your project called "garbage" or some other irrelevant name 2) Adding a folder mapping from "garbage" to "/" via the module assembly page. At this point your project is no longer single root and this bug is worked around."
*** Bug 354469 has been marked as a duplicate of this bug. ***
Created attachment 201370 [details] Patch to ensure such jars are included Bringing patch over from 354469
Rob, you removed yourself as the owner here, but attached a patch. That confuses me. I am assigning this to Roberto, and targeting it to WTP 3.4.0... if that is incorrect, please modify this as appropriate.
Hey Chuck: Seeking a review for 3.3.2. I assume I do not need a review for 3.4.0 yet?
Rob - will get to this soon... but because this is targeted to 3.3.2, it may be next week
Hey Chuck: Gotta ping on this pal
I have tested this change, and it looks reasonable.. Can you add a new junit with your sample? Need to fill in these holes. - Let me know if you need some help setting up
Just for curiosity, was the array of delegates in this class (SingleRootExportParticipant) reviewed to see if one of them should consider this reference as a child module, or maybe add a new delegate? I think that this patch is bypassing completely the verification made by the delegates, so I wonder if that is what we want (but it is just a comment, I'm fine with the patch)
> was the array of delegates in this class (SingleRootExportParticipant) reviewed to see if one of them should consider this reference as a child module Yes, they are still checked ;) addChildModules still calls isChildModule, which iterates through the delegates to find out.
Created attachment 209605 [details] Test case for attached project
Um... the changes to AllTests were just to speed up my testing. Those obviously don't need to be in the patch.
Committed and released to 3.3.2 and head with test
