-
Notifications
You must be signed in to change notification settings - Fork 935
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include all JAR packaging types in the default classpathTypes. Fixes #5... #551
Conversation
…550 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.
Thanks! Merged into 0.13 branch in 933d5fb. |
Thanks. I'd love it if this could be backported to the 0.12.1 branch as well. |
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. |
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 |
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 |
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 Bowman On 1 Oct 2012, at 14:19, Mark Harrah notifications@github.com wrote:
|
Mark, are you saying that Eric can update classpathTypes and get the desired behaviour with 0.12.1? |
@ijuma Yes, the immediate impact of this patch is @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. |
Cool, thanks. Thanks, Eric Bowman On 1 Oct 2012, at 15:45, Mark Harrah notifications@github.com wrote:
|
0.12.1 will include The pull request we are commenting on simply adds dependencies wth |
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:
|
Yes, certainly. Test cases are great. |
...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.