| Summary: | EllipseAnchor and FanRouter can't be used together | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | aimd liu <aimdlau> |
| Component: | GEF-Legacy GEF (MVC) | Assignee: | Alexander Nyßen <nyssen> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ahunter.eclipse, nyssen |
| Version: | 3.2 | ||
| Target Milestone: | 3.7.2 (Indigo SR2) | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| URL: | http://aimd.cnblogs.com | ||
| Whiteboard: | |||
|
Description
aimd liu
Workaround would be to extend EllipseAnchor and provide your own hashMap / equals implementations. Added equals() and hashCode() implementations to EllipseAnchor. Testes with a manually tweaked Shapes Example that FanRouter and EllipseAnchor now work well with each other. Committed changes to cvs HEAD and 3.7 maintenance branch. Why are we moving this to 3.7.1 now? We are at RC3, this is too late for 3.7.1 no? Oops, I wasn't aware about this. There is no API-incompatible change related to this (I just implemented equals() and hashCode(), but I could revert this in 3.7.1 and only leave it in the HEAD branch. (In reply to comment #4) > Oops, I wasn't aware about this. There is no API-incompatible change related to > this (I just implemented equals() and hashCode(), but I could revert this in > 3.7.1 and only leave it in the HEAD branch. Or do we want to leave it in place? Your decision... Actually we are past RC3, this change has to be removed from the maintenance stream. Actually, just leave it, it will go in 3.7.2. (In reply to comment #7) > Actually, just leave it, it will go in 3.7.2. How that? Our RC2 build is the final 3.7.1 build. This change already in the maintenance stream will be in 3.7.2. Ok, fine. |