Skip to main content

Maven and API changes

3 replies [Last post]
kschaefe
Offline
Joined: 2006-06-08

Part of the move to Maven was to allow us to build smaller modules. For instance, Painters are handy and easily usable and would be great as a standalone item.

I began working on that change and as I expected encountered some difficulty with circular dependencies. To make a Painter POM, we need to move the Direction enum from JXBusyLabel to BusyPainter. There is no way to make this change without breaking backward compatibility. However, I think it is the correct change. Direction should be part of the BusyPainter that JXBusyLabel reuses and not the other way around.

Opening for comments, questions, and consideration.

Karl

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kleopatra
Offline
Joined: 2003-06-11

> Part of the move to Maven was to allow us to build
> smaller modules. For instance, Painters are handy
> and easily usable and would be great as a standalone
> item.
>
> I began working on that change and as I expected

great!

> encountered some difficulty with circular
> dependencies. To make a Painter POM, we need to move
> the Direction enum from JXBusyLabel to BusyPainter.
> There is no way to make this change without breaking
> backward compatibility. However, I think it is the
> correct change. Direction should be part of the
> BusyPainter that JXBusyLabel reuses and not the
> other way around.
>

maybe I wasn't clear enough in our mail exchange and/or I'm still as blind as yesterday - so to clarify: code-breaking or not, moving the enum is A-GOOD-THING, a clear +1 from here :-)

What's not so good is to do it against SwingX gentle migration rules - which is to add the new stuff, use it internally but keep the old stuff around for a while (as deprecated members). What puzzled me (here my blindness may hit me ;-) was your remark that "Deprecating does nothing as the deprecated API is unusable." Still don't see it, so some code snippet of what I think should work:

[code]

// application code currently using the JXBusyLabel

myBusyLabel.setDirection(JXBusyLabel.RIGHT)

// now deprecate the enum and the method

public class JXBusyLabel ...
/**
* @deprecated replaced by BusyPainter.Direction
*/
public enum Direction {
...
}
/**
* @deprecated replaced by setDirection(BusyPainter.Direction)
*/
public void setDirection(JXBusyPainter.Direction direction) {
// internally use the new method
setDirection(RIGHT == direction ? BusyPainter.RIGHT : BusyPainter.LEFT)
}

// new method
public void setDirection(BusyPainter.Direction direction) {
//.... do real setting here
}
[/code]

sure that's code-breaking in the longer run - but gentle to existing apps. There would be one problem if the api were well-formed in that the getter couldn't cohabitate in the same way - right now there is no getter (And - a side note - direction is not a bound property as it should), so we get away with simply adding a getter for the new BusyPainter.Direction

Hmm ... what am I missing?

Another side-note: while we are at breaking code, maybe we can think of a better name as well? Direction/Left/Right sound very linear to me. Would prefer something more indicative of its circular nature, like SpinDirection/clockwise/counter-clockwise or similar. Ideas?

Cheers
Jeanette

kschaefe
Offline
Joined: 2006-06-08

Hmm, not as problematic as it should have been! There's no getter; it's a write-only property. So, I can perform the change as you suggest, making it non-breaking. It was my bad for not fully investigating and assuming that the property was bidirectional.

Karl

kleopatra
Offline
Joined: 2003-06-11

no bad - had been my assumption as well. Sometimes - very rarely, though - old mistakes have good side-effects

CU
Jeanette