[MAGNOLIA-1342] magnolia-gui does not compile under JVM 1.6 and 1.7 Created: 05/Feb/07 Updated: 23/Jan/13 Resolved: 05/Feb/07 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 3.0 Final |
| Fix Version/s: | 3.0.5 |
| Type: | Bug | Priority: | Trivial |
| Reporter: | Nicolas Modrzyk | Assignee: | Nicolas Modrzyk |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 1m | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | 1m | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
build failing with: |
| Comments |
| Comment by Nicolas Modrzyk [ 05/Feb/07 ] |
|
in svn |
| Comment by Magnolia International [ 05/Feb/07 ] |
|
how could changing the order of dependencies fix anything? |
| Comment by Nicolas Modrzyk [ 06/Feb/07 ] |
|
interesting question and asked in a really friendly way. (^ ^)/ It was not compiling on my two machines (osx, linux) under 1.6 and not under linux in 1.7. Given that the junit dependency was working in other modules, I just decided to put it at the same place, and it worked. |
| Comment by Magnolia International [ 06/Feb/07 ] |
|
Nico, don't be offended by such questions, they're just naïve. I guessed it didn't really have an answer. Would be nice if in such cases Jira could serve as a "knowledge base", though. |
| Comment by Nicolas Modrzyk [ 06/Feb/07 ] |
|
no offense at all. I really do not have an answer as for the why it's working by just changing the order, I just know it does work. |
| Comment by Jörg Schaible [ 06/Feb/07 ] |
|
Because the transitive dependency resolution of Maven often relies on the processed sequence if two deps are equal in term of "near". Since the sequence seems to rely somehow on an iterator returned from a hash map, it may change by adding a new dep, by changing the version of an existing, or by changing the dependency sequence in the declaration. In case of junit we observed this often in our own builds when any transitive artifact declare junit in compile scope and it was therefore excluded (e.g. globally in a master POM). Why does this affect JDK 6? Since the internal algorithm used in the HashMap has changed and elements are returned in a different sequence (which should not affect anything though - it simply marks a brittle implementation). Should be gone with M2.0.5 though. Can hardly await that. |
| Comment by Magnolia International [ 06/Feb/07 ] |
|
thanks mucho for the insight Jörg ! |