Denis from JetBrains team also wanted a similar feature for the IDEA plugin. He was interested mostly in the group/name/version

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.

Hey Kris,

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?

Thanks!

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,
them they can pretty much use these as is.

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.

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.

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
is also in the workspace. For this feature the IDE will need to know more about the dependencies than simply its jar location. But it is only one half of the puzzle here. We'd also need a bit of info from projects about the artifacts they publish. When we have this we could know that jar X (identified by group etc.) corresponds to project X. Maven support in eclipse already has a feature like this, and different people who know and like this feature have asked me for ('do you have any plans to do this?').

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.

Hi Szczepan, hi Kris,
maybe it might be useful to add to this discussion some conclusions I made while working recently with Gradle without STS to handle my Eclipse projects:
https://issuetracker.springsource.com/browse/STS-2085?focusedCommentId=59971&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-59971

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.
Mauro.

Hi,
is there any plan to address this? It would be very important to allow STS to improve on Gradle support for Eclipse!

@Mauro, we'd welcome a contribution to add this, if you (or anyone else) is interested in helping out.

Gradle Eclipse tooling has this request: https://issuetracker.springsource.com/browse/STS-3882
In order to fix it 2 things are required:
1) Ability to separate dependencies between runtime and test-runtime
2) Ability to differentiate between runtime source entries and binary output and test-runtime source entries and binary output.

1) should be resolved with this defect fix.
Maven handles this case similarly. M2E acquires a collection of Maven artifacts (dependencies) from the project via the Maven runtime, ietrates through it and filters out artifacts based on their scope. The same should be for Gradle Eclipse tooling support in this JIRA

2) We managed to solve this, but there is still help needed on Gradle tooling api to make it better and more robust.
src/test/resources and src/test/java are considered to be the only 2 source entries for test scope. Test source entries are having a non-default output folder /bin-test (Perhaps Gradle tooling api Eclipse project can have some support such that we could ask it for main vs test sources directly... same for the output folders???). Depending on the launch type class path provider generates the right class path based on runtime vs test project output and source folders.
Some help is needed from Gradle API tooling to distinguish between runtime and test-runtime sources. (Looks like we can specify the output folder for a source entry in Eclipse, but perhaps some convention for that is needed similar to maven's target/classes and target/test-classes)

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:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

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.