[GRADLE-2323] eclipseWtpComponent task does not remove JARs not needed anymore Created: 23/May/12  Updated: 27/Jan/17  Resolved: 26/Jan/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-rc-3
Fix Version/s: None

Type: Bug
Reporter: Mauro Molinari Assignee: Unassigned
Resolution: Fixed Votes: 0


 Description   

I'm in the following situation. I have a configuration property in gradle.properties that lets me choose whether to pick up dependencies from a remote Maven repository or from the local filesystem. Whenever I switch from one setting to the other and I run "gradlew eclipse", while the .classpath is correctly updated (removing the JARs that are not in the dependencies any more and adding the JARs that are now in the depencencies), the .settings/org.eclipse.wst.common.component file is updated so that only the new JARs are added, but those that are not in the dependencies any more are kept.
The net result in my use case is that I have all the JARs in the Web App Libraries container twice (both coming from the local filesystem and from the remote Maven repository), while I should have them just once, coming from the local filesystem or from the remote Maven repository depending on the property value I mentioned before.

Apart from my particular use case, my feeling is that if I remove a dependency from my project and I run "gradlew eclipse", that dependency will still be kept in the .settings/org.eclipse.wst.common.component file, unless I do a "gradlew cleanEclipseWtpComponent" before.

So, is there a reason for this different update strategy between .classpath and .settings/org.eclipse.wst.common.component files?

 Comments   
Comment by Szczepan Faber [ 05/Jun/12 ]

I don't think that there is a reason for it. I consider it as a bug (do you mind submitting a pull request?.

I assume that running 'cleanWtpComponent' is a reasonable workaround for the time being?

Comment by Mauro Molinari [ 06/Jun/12 ]

Sorry Szczepan, what's a pull request? :-P

Running "gradlew cleanWtpComponent eclipse" is a workaround unless you have edited .settings/org.eclipse.wst.common.component because you need to apply some other custom changes to the Eclipse project. In this case (and in complex projects setups it may be essential!) it can't be considered a workaround.

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:

  • 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!

Comment by Mauro Molinari [ 15/Nov/16 ]

I think this is still an issue, see for example: https://bugs.eclipse.org/bugs/show_bug.cgi?id=506627

Comment by Benjamin Muschko [ 26/Jan/17 ]

The issue has been fixed with Buildship 2.0.0.

Comment by Mauro Molinari [ 27/Jan/17 ]

This bug was not about Buildship, but about the Gradle Eclipse WTP plugin (which Buildship relies on). Unless something else has been done, the last thing that Donat said was that they were going to workaround this issue by calling cleanEclipseWtp before eclipseWtp to refresh the component file.
In 2012 Szczepan suggested that the current behaviour may not be the desired one.
Hence, I think that this should be reopened or rather closed as "won't fix" if you now think that the current behaviour is the desired one.

Generated at Wed Jun 30 12:18:49 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.