search

spring-attic / eclipse-integration-gradle

Gradle Tooling for Eclipse
Eclipse Public License 1.0
298 stars 108 forks source link

Remap Jars to Gradle Projects ignores version #94

Closed MBurchard closed 9 years ago

MBurchard commented 9 years ago

I had to deactivate the Remap Jars to Gradle Projects because it ignores the version of the project.

Main project has to branches. The v1.7 brunch depends on other project v0.5 and the v1.8 brunch depends on other project v0.6. In v0.6 a constructor has changed and when I switch to brunch v1.7 it complains about a Java failure. Without "Remap Jars" it uses the right dependencies from local repositories and ignores the open projects in Eclipse.

kdvolder commented 9 years ago

This is actually 'as designed'. As it was suggested to me that that made most sense by one user. It actually used to take the version into account as well but that was changed. I suppose we really should make this a configurable preference as obviously not everyone agrees on whether or not the version should be taken into account.

On the other hand, if you didn't want to work with a particular project dependency in your workspace... can't you simply close that project? (Or if you do want it as a dependency, then you should probably make sure to check out the right branch / version of that project).

MBurchard commented 9 years ago

I prefer a configurable solution. In my opinion it is not practical for every member of a team to checkout the right version of a dependency in the Eclipse workspace. That's why we have versions... I also don't see where it makes most sense to ignore the version or an open project. Can you explain that to me? My expectation is, that it checks the current version of on open project X, that is a dependency for project Y. It the current open version does not fit to the dependency defined in project Y, it resolves the dependency by looking into the other defined repositories like maven.

kdvolder commented 9 years ago

Can you explain that to me?

Not really, I only followed the feedback from a user who leads a team of developers. And he told me that when his developers use m2e that they all have it's workspace resolution configured to ignore the version.

If I have to try and explain it to you... I'd say... maybe the reasoning is that if you have it in your workspace you probably wanted to use it. I agree it should be configurable, the only reason that it isn't is that it takes effort to implement UI for the preference pages.

On Tue, Aug 4, 2015 at 8:59 AM, Martin Burchard notifications@github.com wrote:

I prefer a configurable solution. In my opinion it is not practical for every member of a team to checkout the right version of a dependency in the Eclipse workspace. That's why we have versions... I also don't see where it makes most sense to ignore the version or an open project. Can you explain that to me? My expectation is, that it checks the current version of on open project X, that is a dependency for project Y. It the current open version does not fit to the dependency defined in project Y, it resolves the dependency by looking into the other defined repositories like maven.

— Reply to this email directly or view it on GitHub https://github.com/spring-projects/eclipse-integration-gradle/issues/94#issuecomment-127658674 .

MBurchard commented 9 years ago

I slept on it and now I disagree. ;) I thing Gradle itself has everything we need. We are working in a team, and best on Gradle is, that you have all your common settings for projects in the build.gradle. Why putting a flag somewhere else? Then one person sets it, the other not. Gradle itself allows us to steer if we want to work with a version or not.

Defining a dependency this way compile 'group:project:1.0.2' should lead to exactly using this version.

If a team like to switch of usage of a specific version, or always likes to use the latest, it can be achieved by compile 'group:project:1+' or compile 'group:project:[1,)'

Without a specific Eclipse Flag you can have everything you need and in addition it will also behave the same way if you use Gradle outside Eclipse...

What about that?

kdvolder commented 9 years ago

I am probably not going to be supporting this kind of version matching in the IDE. I'd have to re-implement gradle's patterns for matching version and implement the resolution algorithm to essentially resolved agains workspace projects. Moreover, I'd have to implement that without even having a complete model of the project (because tooling API just doesn't expose very detailed information to the IDE).

So... if your script uses 'fuzzy' versions like these then the best you are going to get is the IDE ignoring version on the project instead of matching it to a complex expression matching a range of versions.

Conclusion, maybe we are best to leave it as is.