-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SkinnyWar Support issue #27
Comments
Hi @fbricon hope you are doing well. Matt's group above is looking at the source to investigate a patch for this functionality. We know this project doesn't release too often, but any assistance if/when a PR is possible would be welcome. Obviously any proposed change will be sent to you for review. Thanks! - Chuck |
@cbridgha a PR is always welcome, m2e has no "freeze" period or similar and you can always use the snapshot repository until a new release is made (usually we do at least one per eclipse release sometimes even more often). If there are customer demands a good way for speeding things up is offering a sponsoring for those working on their free time on this project (or of course working on the issue directly). |
@mattcolegate @cbridgha there are 2 ways to implement a solution, the right one and the wrong one (a.k.a the hacky one).
Reasons why the wrong approach is wrong:
|
I forgot to mention you need to rewrite the MANIFEST.MF of the web projects and .war archives as well |
Hi, I have a couple of questions on that:
|
@fbricon Hi would you be able to take a peek at my above questions? |
I would probably set a skinnyWars=true metadata in the EAR's IVirtualComponent, from EarProjectConfigurator, then expect whatever WTP deployment implementation that handles Ear components to do exactly what the Maven Ear plugin does: strip war (projects/archives) from dependencies already in the EAR, rewrite manifests before actual deployment
Yeah if you take the wrong route, then you can forget about single war deployment or exporting as war, since the manifest would be covering skinny war enabled EARs only On a side note, anyone manually exporting a maven war project using Eclipse buttons is doing it wrong. In Maven world, "mvn package" is the one and only truth |
I think there might be a 3rd way to get skinny war support working, without having to change WTP, and without screwing single wars, or wars in multiple EARs. Basically, you would create a new custom IVirtualComponent, let's call it SkinnyWarVirtualComponent, akin to the IOverlayVirtualComponent I made to handle war overlays. Then, a custom reference resolver would be able to do all the skinny war magic (exclude jars, rewrite custom manifest), a bit like OverlayReferenceResolver Basically, EarProjectConfigurator would do something similar to what OverlayConfigurator does, and create SkinnyWarVirtualComponent for every web project dependency it finds in m2e-wtp/org.eclipse.m2e.wtp/src/org/eclipse/m2e/wtp/EarProjectConfiguratorDelegate.java Lines 203 to 213 in c67a347
|
Similar to the Overlay virtual component, a new skinny war component (+resolver) would need no reference to Maven/m2e at all (that's why it's in a separate plugin) |
Tests for Overlays, as a reference, exist in the separate m2e-wtp-tests repo : https://github.com/jbosstools/m2e-wtp-tests/blob/master/org.eclipse.m2e.wtp.tests/src/org/eclipse/m2e/wtp/tests/OverlayTest.java |
Thanks @fbricon I will go and dig deeper into option 3, it sounds promising but I need to get my head around it |
Hi @fbricon I've taken a peek at it today (I've been away for a week). I think I have a bit of understanding. I assume we'd need to register an extension point in Eclipse for the SkinnyWarResolver (in the plugin.xml)? Were you suggesting that EarProjectConfiguratorDelegate should create another component for each web project on top of the components it already creates (J2EEModuleVirtualComponent)? I tried getting EarProjectConfiguratorDelegate to create a new SkinnyWarCompopnent as well as the existing one (and saw it did update the .component file to create 2 entries) but my resolver was not invoked, presumably as my component was a very basic class extending org.eclipse.wst.common.componentcore.internal.resources.VirtualComponent and another resolver was able to resolve it. If using just the new component to replace the existing depComponent I was wondering if the new Resolver could first delegate to the existing resolver (I've not found out which one that is yet) and then modify the results? |
First of all, given maven-ear-plugin 3.2.0 expanded the concept of skinny wars to other modules, from now on we should speak about skinny modules. So yes you'd have a resolver like <plugin>
<extension
point="org.eclipse.wst.common.modulecore.referenceResolver">
<resolver
class="org.eclipse.m2e.wtp.skinnymodules.modulecore.SkinnyModuleReferenceResolver"
id="org.eclipse.m2e.wtp.skinnymodules.modulecore.SkinnyModuleReferenceResolver">
</resolver>
</extension>
</plugin> and in EarProjectConfiguratorDelegate, when iterating over Ear modules:
So you want 1 component entry only per artifact. I don't think delegating to regular resolver applies here. But for sure the Skinny components should generate something very close to the regular components (minus some jars + manifest rewrite) |
Hi, I cannot say for certain that I understood everything that was said since I do not know much about the design and the internals of how m2e works. I do know a lot more about skinny wars (or as @fbricon said correctly skinny modules). I wanted to note something that may have been forgotten when building skinny modules. Currently, when maven builds a multi-module project that contains a skinny WAR, when the WAR module is built there is no impact, i.e. the WAR module is built as a fat module with all the required dependencies in WEB-INF/lib and no MANIFEST references in the class-path entry. This is how it should always work as the WAR should be deployable on its own to an application server (i.e. tomcat) or a JEE container. The skinny module should only have an effect when it is packaged inside an EAR module. This is how maven currently does it and this is how M2E should also reflect it. This means that the EAR always needs to reference a skinnied module, not the fat module that the maven build would create. I apologize if I stated the obvious but to me it appeared that this was not reflected in some of the prior comments. If someone was willing to guide me I would be willing to help in fixing this issue. You can contact me if interested |
Hi, I'm a developer for Websphere Developer Tools. We have a customer who is using true in his EAR's POM.xml and it's not importing properly when we pull it into our Eclipse environment using m2e-wtp.
There are sample projects available for recreation purposes from our customer at https://github.com/marioja/sample-tests. There are prereq setup details at https://github.com/marioja/sample-tests/tree/LOOSECONFIG_CLASSPATH_ISSUE/simple-jee, and the main problems are detailed at https://github.com/marioja/sample-tests/tree/SKINNY-FAILS/simple-jee and https://github.com/marioja/sample-tests/tree/SKINNY-WORKS/simple-jee.
By default, it assumes that the shared libraries are being deployed in the WAR and we would like them to point to the libraries in the EAR.
We think that some of the changes are likely to start in the org.eclipse.m2e.wtp.EarPluginConfiguration package but would appreciate being shown round!
The text was updated successfully, but these errors were encountered: