Tooling API model should allow determine the type of a dependency

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.