Gradle

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
To raise new issues or bugs against Gradle, please use forums.gradle.org.
  • Gradle
  • GRADLE-2323

eclipseWtpComponent task does not remove JARs not needed anymore

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Open Open
  • Resolution: Unresolved
  • Affects Version/s: 1.0-rc-3
  • Fix Version/s: None

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?

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • History
  • Activity
  • TeamCity
  • Commits
  • Source
  • Reviews
Hide
Permalink
Szczepan Faber added a comment - 05/Jun/12 2:13 PM

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?

Show
Szczepan Faber added a comment - 05/Jun/12 2:13 PM 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?
Hide
Permalink
Mauro Molinari added a comment - 06/Jun/12 1:42 AM

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.

Show
Mauro Molinari added a comment - 06/Jun/12 1:42 AM 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.

People

  • Assignee:
    Unassigned
    Reporter:
    Mauro Molinari
Vote (0)
Watch (2)

Dates

  • Created:
    23/May/12 4:50 AM
    Updated:
    06/Jun/12 1:42 AM
  • Atlassian JIRA (v5.0.3#729-sha1:bf569e4)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Gradle. Try JIRA - bug tracking software for your team.