[GRADLE-1637] Support "skinny" deployed ears, where transitive dependencies of deployed modules are automatically put in the earlib Created: 23/Jun/11 Updated: 10/Feb/17 Resolved: 10/Feb/17 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 1.0-milestone-3 |
Fix Version/s: | None |
Type: | Bug | ||
Reporter: | David Gileadi | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 22 |
Description |
Currently in the ear plugin you need to specify all dependencies that are to go into the ear's lib dir manually via the earlib configuration. A popular deployment model is the "skinny" deploy model, where dependencies in (for instance) a war file aren't put into the war file's WEB-INF/lib dir but are instead put into the ear's lib dir. To exclude dependencies from a war file's WEB-INF/lib dir you simply use the war plugin's providedCompile and/or providedRuntime configurations. However there is no mechanism for automatically putting these dependencies into the ear file's lib dir. I have code ready that does this. The current property name on the ear plugin is "skinnyDeploy". Setting ear.skinnyDeploy to true will cause the ear plugin to gather all the transitive dependencies of everything in the "deploy" configuration and include them all in the generated ear file's lib dir. Feel free to suggest a better property name. |
Comments |
Comment by David Gileadi [ 23/Jun/11 ] |
Created a pull request: https://github.com/gradle/gradle/pull/39 Note that in the pull request I used "includeDeployDependencies" as the property name instead of "skinnyDeploy". |
Comment by Leonard Brünings [ 02/Aug/11 ] |
What is the current status of this feature, when is it going to be included in gradle? |
Comment by Szczepan Faber [ 03/Aug/11 ] |
I'll have a look at the skinny deploy at some point. The implementation suggested in the pull request is not what we would like to pull at the moment (sorry for this weak feedback - I'll write some more when I have time). |
Comment by Aleksey Lagoshin [ 17/May/12 ] |
Any news on this? Manually adding dependencies is not easy work for large projects... |
Comment by Szczepan Faber [ 18/May/12 ] |
Hey Aleksey, We're busy on other fronts I'm afraid. We keep in mind that this feature is popular and will get to it at some point. Thanks for the reminder! |
Comment by Damien Coraboeuf [ 14/Mar/14 ] |
Is there some hope of resolution on this subject? For the moment, we have to use workarounds in order to get proper skinny WAR when this is quite a common pattern in enterprises using EAR files. |
Comment by Adam Murdoch [ 06/Apr/14 ] |
Damien Coraboeuf, we do intend to fix this, but we want to get some dependency management improvements in place first, which we are working on. If you're interested, you (or anyone else who is interested in this issue) could help out with improvements to the war and ear plugins. Let us know if you're interested on the dev mailing list and we can come up with a bit of an implementation plan. |
Comment by Alexander Furer [ 22/May/14 ] |
Please support the ejb module dependencies in ear's libDirName as well |
Comment by eric vantillard [ 07/Oct/14 ] |
maybe it can be implemented as a custom plugin ? is this an exotic request ? |
Comment by Damien Coraboeuf [ 11/Mar/15 ] |
Does anybody know if any progress has been made on this issue? |
Comment by Benjamin Muschko [ 15/Nov/16 ] |
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub. We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to. Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle! |
Comment by Benjamin Muschko [ 10/Feb/17 ] |
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved. |