Include all JAR packaging types in the default classpathTypes. Fixes #5...

[kscaldef]

...50

These special types need to be recognized in both the POM parser and added to the classpath.
The previous code was not DRY, and eclipse-plugin was in one but not the other. This ensures
new types can be added in the future without risking this type of oversight.

[harrah]

Thanks! Merged into 0.13 branch in 933d5fb.

[kscaldef]

Thanks. I'd love it if this could be backported to the 0.12.1 branch as well.

[harrah]

At the time of a new 0.12.x release, all binary compatible fixes from 0.13 get backported. 0.12.1 is already at RC2, so this wouldn't go in until 0.12.2.

[ebowman]

I sure wish you'd reconsider based on how much this is hurting us: https://groups.google.com/d/topic/simple-build-tool/HReRqxmPE6Y/discussion

[harrah]

An RC becomes final in two weeks unless there are major regressions or major issues with new functionality. This policy is to ensure a new release is as close to being strictly an improvement over the previous release without having a drawn out release process. A new RC requires an additional two weeks and this means users unaffected by the issue must wait at least another two weeks. An efficient RC cycle allows new, drop-in compatible releases every 2 months (ideally of course) so that users regularly get bug fixes quickly.

This pull request only affects the eclipse-plugin packaging, but the linked thread deals with orbit. It also only modifies classpathTypes, which can be done in a build without touching the dependencies. This is neither a regression in old functionality since 0.12.0 nor a flaw that makes new functionality unusable.

[ebowman]

Fair enough. FWIW, we are really struggling through a big rollout of sbt at Gilt, because of what Eclipse are doing with packaging, and how sbt deals with it. The proposed work around with Artifact(...) is not transitive, so this is a huge pain point for us. Waiting months longer when this issue has been known since March is not making it easy to sell the idea of using sbt across our large code base, since we depend heavily on latest jetty, which has this "orbit" mis feature.

Anyhow, I understand hard decisions have to be made, it's just losing the ability to have transitive dependencies is incredibly painful for us at this scale.

Thanks,
Eric

Eric Bowman

On 1 Oct 2012, at 14:19, Mark Harrah notifications@github.com wrote:

An RC becomes final in two weeks unless there are major regressions or major issues with new functionality. This policy is to ensure a new release is as close to being strictly an improvement over the previous release without having a drawn out release process. A new RC requires an additional two weeks and this means users unaffected by the issue must wait at least another two weeks. An efficient RC cycle allows new, drop-in compatible releases every 2 months (ideally of course) so that users regularly get bug fixes quickly.

This pull request only affects the eclipse-plugin packaging, but the linked thread deals with orbit. It also only modifies classpathTypes, which can be done in a build without touching the dependencies. This is neither a regression in old functionality since 0.12.0 nor a flaw that makes new functionality unusable.

—
Reply to this email directly or view it on GitHub.

[ijuma]

Mark, are you saying that Eric can update classpathTypes and get the desired behaviour with 0.12.1?

[harrah]

@ijuma Yes, the immediate impact of this patch is classpathTypes += "eclipse-plugin". It has the longer-term impact of keeping two areas of the code synchronized, of course.

@ebowman I am of course sorry for the trouble. You may be right about the problem being known in March, but the issue that got fixed was #499 and was filed three months ago. It was fixed promptly and is in the 0.12.1 release. (It happens to be that a drawn-out 0.12.0 release candidate cycle is why there wasn't a release containing it until three months later.) A 2 month drop-in compatible release cycle is already fairly aggressive for an open source project with one maintainer.

You are helping yourself and everyone else by submitting patches and again, I understand your situation. We can discuss the bug-fixing process if you want, but I think the release candidate policy itself is reasonable.

[ebowman]

Cool, thanks.
Can you help me understand how the situation is different in 0.12.1? It seems to me like it behaves exactly the same as 0.12.0.

Thanks,
Eric

Eric Bowman

On 1 Oct 2012, at 15:45, Mark Harrah notifications@github.com wrote:

@ijuma Yes, the immediate impact of this patch is classpathTypes += "eclipse-plugin". It has the longer-term impact of keeping two areas of the code synchronized, of course.

@ebowman I am of course sorry for the trouble. You may be right about the problem being known in March, but the issue that got fixed was #499 and was filed three months ago. It was fixed promptly and is in the 0.12.1 release. (It happens to be that a drawn-out 0.12.0 release candidate cycle is why there wasn't a release containing it until three months later.) A 2 month drop-in compatible release cycle is already fairly aggressive for an open source project with one maintainer.

You are helping yourself and everyone else by submitting patches and again, I understand your situation. We can discuss the bug-fixing process if you want, but I think the release candidate policy itself is reasonable.

—
Reply to this email directly or view it on GitHub.

[harrah]

0.12.1 will include orbit depdendencies on the classpath by default and give them the proper extension.

The pull request we are commenting on simply adds dependencies wth eclipse-plugin packaging to the classpath by default.

[ebowman]

Got it. That's not working for us in the latest RC. Should it be? I'll put together a reproduction case if it should

Eric Bowman

On 1 Oct 2012, at 18:42, Mark Harrah notifications@github.com wrote:

0.12.1 will include orbit depdendencies on the classpath by default and give them the proper extension.

The pull request we are commenting on simply adds dependencies wth eclipse-plugin packaging to the classpath by default.

—
Reply to this email directly or view it on GitHub.

[harrah]

Yes, certainly. Test cases are great.