[GRADLE-1777] Tooling API model should allow determine the type of a dependency Created: 31/Aug/11 Updated: 10/Feb/17 Resolved: 10/Feb/17
|Reporter:||Kris De Volder||Assignee:||Unassigned|
In particular, when we get the classpath for a EclipseProject we essentially get a list of jars, but no information on the 'origin' of the jar.
There are many bits of potentially useful information such as the info that was used in resolving it (group artfecat id etc.).
However, the most pressing at the moment is that to implement proper WTP support for the Gradle Classpath container I need to be able to determine the type(configuration?) of dependency as in 'compile', 'test', 'providedCompile' etc.
This is important because this info is needed to properly configure the WTP deployment assembly and exclude some dependencies from it (test and provided)
If this isn't done properly then the web application will not run properly on the server because of class loader errors.
So what is needed is a way to distinguish the jars based on configuration-type (compile, test, ...).
A possible solution would be to add a method to
to determine this.
|Comment by Szczepan Faber [ 01/Sep/11 ]|
Denis from JetBrains team also wanted a similar feature for the IDEA plugin. He was interested mostly in the group/name/version
|Comment by Kris De Volder [ 24/Jan/12 ]|
Well we would also be interested in 'group/name/version'. If you think it could be implemented all at once under the same ticket. That would be great. If you rather consider these two separate issues, that be fine as well.
About this issue (knowing whether something is 'provided', 'test', etc.) Just today we had another problem where WTP deployment gets messed up because we are not able to properly exclude dependencies like 'provided' and 'test' from the deployment.
So based on the number of people that have hit this problem. I think this is really an issue that should get some attention soon, if possible.
|Comment by Szczepan Faber [ 17/Apr/12 ]|
My understanding is that to achieve WTP support the STS is using the metadata generated by the regular eclipse plugin. This metadata should already contain information on what should be deployed and what shouldn't (specifically, the wtp component files). Can you tell us a little bit more what is driving the requirement of knowing the configuration name?
|Comment by Kris De Volder [ 17/Apr/12 ]|
The requirement essentially stems from before I started providing more support for working with the generated config files.
If users of STS have 'Dependency management' enabled then STS will manage the dependencies by creating a 'classpath container' which is dynamically populated with the dependencies/jars returned from the tooling API. If users are using STS in this way then the dependencies there won't be correctly configure re deployment.
Now there is also a mode of working with STS where users turn of 'Dependency management'. Then STS will switch to working on the assumption that the tools should mostly use the generated config files and interfere with the generated configs as little as possible. In this mode reliance on the tooling API is minimal (essentially it is just used for running tasks and discovering project hierarchy). The 'cleanEclips' and 'eclipse' tasks are executed to generate/refresh eclipse configs. Then we trigger a workspace/project refresh so Eclipse becomes aware of changes in these configs.
So yes, if working with 'Depency management' disable we don't need any of this information from the tooling API. And maybe that is the way to go for the future. The advantage is that it uses/needs little support from the tooling API, and if people already have 'finely tuned' build scripts that they used before to generate the configs offline and then import,
The disadvantage is that there is much less tighter integration between the tooling and Gradle, and the tooling doesn't truly understand the projects (essentially the tooling go in a 'hands off' mode just execute some tasks, without knowing what these tasks actually do. The assumption is that the build script works, or if not, its up to the user themselves to fix any problems by tweaking their build scripts).
If we want to move to tighter integration and 'real' support for WTP, this would be one step in the right direction. But like I said, there are good arguments for the more 'hands-off' approach. And there may be more important things to work on.
|Comment by Szczepan Faber [ 24/Apr/12 ]|
Kris, thanks a lot for info1
Can you tell me a bit more what's the use case behind providing group,name,version info with dependencies? It's not that we don't want to provide it - it's just I'd like to understand better what's the driver.
|Comment by Kris De Volder [ 24/Apr/12 ]|
The main reason why I originally raised it is to be able to correctly determine which jars to exclude from wtp deployment. I'm really not an expert on the WTP stuff, but users have told me that 'provided' dependencies aren't meant to be deployed. The way I understand it is that this is because they are already provided by the server.
They still need to be on the classpath to compile the code of the webapp however.
But if they also get added to the deployment assembly then it results in conflicts at runtime causing the app to crash with classloader errors.
Similarly 'test' dependencies aren't typically supposed to be deployed. Usually these don't lead to serious problem (except that some extra jars get added to classpath that shouldn't be there).
As you already observed, this is not a problem when we just let the gradle eclipse plugin generate the configuration for the deployment assembly.
The version group etc. info could also be useful in implementing support for a feature that replaces jar level dependencies with project dependencies if the project that the jar is build-by
Anyway, anything we want to implement where the IDE gets more involved in managing / mapping dependencies in a smart way will need more detailed information about dependencies than just a pointer to a jar.
|Comment by Mauro Molinari [ 11/May/12 ]|
Hi Szczepan, hi Kris,
I think there are some thoughts that may give Szczepan some cues on why enabling IDEs to gather more detailed information on dependencies might be important to solve some problems that I think the "plain Gradle" alone can't.
I hope this constitutes a contribution to the discussion.
|Comment by Mauro Molinari [ 16/Jul/13 ]|
|Comment by Adam Murdoch [ 16/Jul/13 ]|
@Mauro, we'd welcome a contribution to add this, if you (or anyone else) is interested in helping out.
|Comment by Alex Boyko [ 10/Oct/14 ]|
Gradle Eclipse tooling has this request: https://issuetracker.springsource.com/browse/STS-3882
1) should be resolved with this defect fix.
2) We managed to solve this, but there is still help needed on Gradle tooling api to make it better and more robust.
|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.