Skip to main content

All SwingX: Removal of deprecated code looming!

35 replies [Last post]
Anonymous

SwingX is happy enough to allow for the actual removal of deprecated
stuff - and we'll do it (we promised since ages :-). It will happen any
time between the end of the Berlinale and the release of milestone
0.9.2. Or with other words:

NONE of the deprecated code, methods, classes will be part of the next
milestone.

Be happy!
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Reply viewing options

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

I did wonder what the significance of /project was and the properties files hidden under there. An Eclipse project perhaps?

Got as far as this at one point:
[code]
$ ant -Djava.net.id=kleopatra -Dlibs.junit.classpath=lib/share/junit-4.0.jar -propertyfile project/kleopatra.properties -propertyfile project/_project.properties -f _build-kleopatra.xml run-AlbumBrowser
[/code]

Missed the fact your build under project isn't using the main project build, so the private properties don't seem to have any effect. For a 'not a Netbeans project file' (comments) it looks a lot like a Netbeans build file to me. However your build seems to process those /project properties files itself somewhere, and doesn't use the java.net.id as it defines its own variation member.id.. so just:

[code]
$ ant -Dlibs.junit.classpath=lib/share/junit-4.0.jar -f _build-kleopatra.xml run-AlbumBrowser
[/code]

Worked yey! but the selection doesn't (as expected). Haven't looked into how the run/compile classpaths are constructed, but that'll be the issue. Thought it odd a dump of paths appears to include bits of lib/shared but not junit & co..?

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> I did wonder what the significance of /project was and the properties files hidden under there. An Eclipse project perhaps?
>
>

haha .. no. Just a distinct (from nbproject) location, mostly c&p'ed.
that's why the internals still look so netbeanish. It has always been a
quick and dirty job, mixture of different people at different times
making it barely workable. Changes welcome (as long as I don't have to
update my local build too much ---- Maven, that'll probably involve lots
of changes?) Anyway, my part can be build via ant with
_kleopatra-build.xml (or should, if it doesn't something's broken) using
the properties (base and my member specific) the project folder.

> Got as far as this at one point:
> [code]
> $ ant -Djava.net.id=kleopatra -Dlibs.junit.classpath=lib/share/junit-4.0.jar -propertyfile project/kleopatra.properties -propertyfile project/_project.properties -f _build-kleopatra.xml run-AlbumBrowser
> [/code]
>
> Missed the fact your build under project isn't using the main project build, so the private properties don't seem to have any effect. For a 'not a Netbeans project file' (comments) it looks a lot like a Netbeans build file to me. However your build seems to process those /project properties files itself somewhere, and doesn't use the java.net.id as it defines its own variation member.id.. so just:
>
> [code]
> $ ant -Dlibs.junit.classpath=lib/share/junit-4.0.jar -f _build-kleopatra.xml run-AlbumBrowser
> [/code]
>
>

wow ... never did that manually: Eclipse has some tabs and checkboxes
and ... in the ant specific "run external" :-) Which I point to my build
file and click the tasks I want to have done, lazy me.
> Worked yey! but the selection doesn't (as expected). Haven't looked into how the run/compile classpaths are constructed, but that'll be the issue. Thought it odd a dump of paths appears to include bits of lib/shared but not junit & co..?
>

yeah, there are oddities On the other hand, junit shouldn't be
necessary outside of the test hierarchy, do we agree on that? Just
noticed that the jar now is in the shared lib, what's missing is a field
pointing there. Probably got lost somewhere along the c&p.

@Jan, good to have the automatic copy of the swingx-head.jar back -
pleading again: I want to have that automaticm for the plain lib/share
as well (not only that under the www).

CU
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rah003
Offline
Joined: 2004-05-26

> @Jan, good to have the automatic copy of the swingx-head.jar back -
> pleading again: I want to have that automaticm for the plain lib/share
> as well (not only that under the www).

I bet it was fewer characters to change the build file then to write the paragraph above ;)
Done (effective as of next build).

Kleopatra

jdnc-interest@javadesktop.org schrieb:
>> @Jan, good to have the automatic copy of the swingx-head.jar back -
>> pleading again: I want to have that automaticm for the plain lib/share
>> as well (not only that under the www).
>>
>
> I bet it was fewer characters to change the build file then to write the paragraph above ;)
>

sure - but I wouldn't dare to touch the build file ;-) Now, what is the
name of the jar? Should be the same for both locations or not?

Thanks
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rah003
Offline
Joined: 2004-05-26

> sure - but I wouldn't dare to touch the build file ;-) Now, what is the

Oh well, if you put it that way ... tho I would not be offended if you changed that. ;)

> name of the jar? Should be the same for both locations or not?

Should it, or not? That's the question. I guess yes, so I changed the build file again.

Kleopatra

jdnc-interest@javadesktop.org schrieb:
>> sure - but I wouldn't dare to touch the build file ;-) Now, what is the
>>
>
> Oh well, if you put it that way ... tho I would not be offended if you changed that. ;)
>
>

haha ... good try :-) No way I'll fiddle with admin tasks - simply not
my world.
>> name of the jar? Should be the same for both locations or not?
>>
>
> Should it, or not? That's the question. I guess yes, so I changed the build file again.
>

great - thanks
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

osbald
Offline
Joined: 2003-06-13

What does your jdnc-incubator\nbproject\private\private.properties look like? getting a sense of deja-vu as Ant is now unable to find JUnit TestCase. For jdnc-incubator mine only contains:

[code]
libs.junit.classpath=lib/share/junit-4.0.jar
[/code]

Although in this case I notice JUnit is being used in jdnc-incubator\src\kleopatra\java\org\jdesktop\swingx\table\treetable\TreeTableModelIssues.java among others. i.e. not under a test directory if that makes a difference? could just about follow the build script up until the macrodefs were called (and its late now).

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> What does your jdnc-incubator\nbproject\private\private.properties look like?

don't have that - not even the nbproject. The (my?) per-member incubator
builds build-memberid.xml point to the memberid.properties in the
/project folder.
> getting a sense of deja-vu as Ant is now unable to find JUnit TestCase. For jdnc-incubator mine only contains:
>
> [code]
> libs.junit.classpath=lib/share/junit-4.0.jar
> [/code]
>
>

hmm ... we don't have the junit jar there, as far as I can tell
> Although in this case I notice JUnit is being used in jdnc-incubator\src\kleopatra\java\org\jdesktop\swingx\table\treetable\TreeTableModelIssues.java among others. i.e. not under a test directory if that makes a difference?

got me, that must have crept in behind my back . Moved over to the
/test - so hopefully now the my /java doesn't depend on junit nor on the
swingx test packages. It it still does somewhere please let me know,
it's a bug not a feature.

Reason my local ant build doesn't bark is that I have the junit in all
jre extension dirs, so it's on the classpath. Too lazy to change that ...

yeah, sequence might be at the root of the albumbrowser selection
problem - don't know how to change that (I really hate build problems,
did I ever mention how much so?).

As to the calendar related problems: building fine here and Eclipse
tells me it's in synch with cvs. Hmm ... did you pick up the latest
kleopatra.properties? One slight quirk in the base
_properties.properties is that the swingx field points to swingx.jar
while the newest build is swingx-head.jar (don't remember when we
switched that - probably should remove the swingx.jar altogether?)

problems, problems, problems ... all before my second cup of coffee, sigh

CU
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:

forgot ...
>
> As to the calendar related problems: building fine here and Eclipse
> tells me it's in synch with cvs. Hmm ... did you pick up the latest
> kleopatra.properties? One slight quirk in the base
> _properties.properties is that the swingx field points to swingx.jar
> while the newest build is swingx-head.jar (don't remember when we
> switched that - probably should remove the swingx.jar altogether?)
>
... that I mentioned the kleopatra specific properties because they
point to the swingx-head.jar ...

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rah003
Offline
Joined: 2004-05-26

you just made it to 20K posting on swinglabs forum. Congrats :)

BTW, swingx-head.jar in incubator is again updated automatically since this morning.

As for the per member builds ... I planned to do this with maven, have whole incubator as a one reactor and each member would be able to have his/her subproject there that would be invoked (when found), what I failed to achieve in this scenario was not to fail the build when one of the subprojects fail ... but i think it's just a configuration issue which can be solved.

osbald
Offline
Joined: 2003-06-13

Jan - I seemed to remember you saying something about naming & shaming developers with failing code but wasn't sure how you were going to approach this. We might be working along similar themes.

I was trying to get to a point where I could express a jar built from a selection of incubator classes against as much as possible versioned dependencies like swingx-0.9.2 etc.. the shared swingx/swing-head libs are a bit too woolly for me. Need to be sure the classes work against the swingx my code uses rather than the last one that happened to be checked into jdnc (or even working out what dependancies each contributor is using). Tricky if they put jars into their jre/ext dirs! tut tut

I'd probably use Apache Ivy to get at the Jars from the maven repo as I've not gotten deep into maven myself. The differences in directory structure from the maven standard appears to require customizing maven (archtypes?). Which is a bit like running before you can walk, maybe its actually quite easy? but mavens rep so far has made diving in off-putting. Given the recent support for poms as an alternative project definition in Netbeans and IDEA maybe it would offer a more standardized (IDE neutral)? approach.

rah003
Offline
Joined: 2004-05-26

I think customization should not be a problem ... and since this is incubator i would be even willing to impose standard maven project structure to those who wants to have their code in the incubator to have build against latest swingx code. The reason why i'm looking into maven is that it would allow me to build all the possible projects without having to upload and sync tons of libraries into the project and could just pull it from maven repo. I might commit what I have so far over weekend to the incubator and we can try to make it work all together. Again, I would like to have snapshots of swingx in java.net repo before that.
As for Ivy ... I know even less about it then about maven so I guess I stick with maven, unless someone else is going to put whole thing together and just tell me how to run it from hudson. ;)

osbald
Offline
Joined: 2003-06-13

> since this is incubator i would be even willing to impose standard maven project structure
> to those who wants to have their code in the incubator .. I might commit what I have so
> far over weekend to the incubator and we can try to make it work all together

Just another tangential thought on how we might approach changing the incubator structure & formal builds. What about creating a new swingx-incubator project for the new stuff? jdnc-incubator is a bit of a throwback and we need to shuffle-off the accumulated cruft somehow. Contributors would have to migrate, which ought to ensure their code was functional with the head (and they're still active).

I wouldn't complain too much if a newer project offered java.nets svn access either

rah003
Offline
Joined: 2004-05-26

> I wouldn't complain too much if a newer project offered java.nets svn access either

I was just about to reply this when i read your last line. :)
New incubator might be the best solution, tho I would prefer to call it either swinglabs-incubator or jdesktop-incubator ... not restricted to swingx only.

osbald
Offline
Joined: 2003-06-13

>I was just about to reply this when i read your last line.

..and I thought I was being ever so sneaky didn't think too hard about the name.. might rename my local hudson project. Just been to http://swinglabs.org/hudson/ which gave me a fright for a moment ;) looking at the list makes me wonder if you've ever tried clicking on the [+] tab from the hudson dashboard? ref:

Took 25 minutes to get at jdnc-incubator (swing-incubator) from java.net.

rah003
Offline
Joined: 2004-05-26

> hudson project. Just been to
> http://swinglabs.org/hudson/ which gave me a fright
> for a moment ;) looking at the list makes me wonder
> if you've ever tried clicking on the [+] tab from the
> hudson dashboard? ref:

I personally find views more confusing then having everything on single page (as long as there is no more then 20 or so builds).

What surprises me is the fact that old server was restored and is up and running, Because this is what you see ... so now we have two separate instances of hudson running ... someone should clean up this mess.

osbald
Offline
Joined: 2003-06-13

I quite like the views. It lets me partition jobs into areas of interest. In the above case nobody else will care about the 3rd party builds (and swingx-incubator fails most of the time - its an art not a process). Those who don't care can continue looking at a view for just the core product. I also stage testing into jobs for unit tests (every change), functional tests (several a day) , acceptance tests (overnight) etc.. so devs can have views on just their immediate concerns/customers. The feeds (I like feeds - hate email) also work with views.

You lose nothing adding views as the default is All so your if you don't choose to use a view hudson remains unchanged. Thought you might be migrating more projects over to the newer hudson, and might want to hide the utility jobs like update libs.

BTW swinglabs.org still points to the reanimated hudson. Even though I knew my bookmarks were out-of-date I'd expected the dns routing to have changed (or a 404).

PS The tray widget plugin sounds funky: http://www.nabble.com/Hudson-Tray-Application---Alpha-Available-ts162526...

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> all I promised was ..\kleopatra\java That's what gets compiled by _build-kleopatra.xml (which hopefully still works, didn't try for a while). Excluding the test should be okay ... need to check against a recent swingx.jar, though. Could well be that references to the swingx/test crept in recently (that would be any dependencies on AncientSwingTeam and PropertyChangeReport).
>
>

just checked - the kleopatra builds fine (after updating the swingx-head
in the shared lib and retargeting my build properites to the
swingx-head.jar ;-) What's weird is that indeed the selection in the
list (of the BAlbumBrowser) doesn't work reliably if run from the build
task, but looks okay if run directly by Eclipse in my workspace.
Suspected the manifest/services - but they are in the
kleopatra-incubator.jar as expected. Any ideas?

So my ghetto is a clean as I care about

CU
Jeanette

PS: thanks for the links, will take a look soon

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

osbald
Offline
Joined: 2003-06-13

I guess I'm seeing the opposite then running directly from IDEA and the selection doesn't work.. Ah but the services probably weren't being used. Changed my run configuration to include kleopatra\java\ (for META-INF) explicitly on the classpath and it appears to work again from my IDE.

Suspect the ant build must be missing or reordering the jars so the wrong adapters get picked up?

osbald
Offline
Joined: 2003-06-13

Wondering if you committed those changes? ant run-AlbumBrowser seems to bomb trying to compile the calender stuff I had to exclude from IDEA. Might be that the java.net CVS is just so very slow..

kschaefe
Offline
Joined: 2006-06-08

> Some of this is partly an IDEA issue, I can exclude
> whole packages/folders, but not individual classes
> from a package.
Hmm, Eclipse allows you to kick out classes individually.

> So for example Karls
> org.jdesktop.swingx.JXToolBar that wasn't compiling
> (background painters are defined as Painter > JXButton> not Painter) meant I had to
> exclude to whole of his swingx package that almost
> everything else hangs off. Not the only issue the
> duplicate org.jdesktop.swingx.JXTable(s) also wont
> compile :- if swingx dependencies were expressed as
> source code rather than jar/class. Oh and Karl
> definitely likes his 6.0 ;)
I've tried with my later code to provide base folders that contain everything relavant to the example at hand. My JXComboBox, for example, is in a new area. I'll try to remove some dead code from my area and provide a little more fine-grain packaging. Is there anything in particular, you'd like me to clean up?

6.0 wave of the future. ;)

Karl

osbald
Offline
Joined: 2003-06-13

> Hmm, Eclipse allows you to kick out classes individually.

Ahhh, Wondered how others are surviving. The latest Netbeans can exclude based on regular expressions too (I think). Terrifying. I'd like to think that tells me more about the state of Eclipses & Netbeans code bases than is good for my state of mind. With IDEA I find It's one of those limitations thats actually quite useful in forcing developers to do-the-right-thing and clean up after themselves (or at least think in terms of modules). Probably makes me a bit of a zealot too, not that I need any help with that ;)

> Is there anything in particular, you'd like me to clean up?

No not really picking on you, it just you were in my default list of useful contributions (up until the compile failed;). Mostly I was wanting to look at the combo, column highlighters but having to wrangle dependancies and deprecations (and their causes) all the time tends to put me off trying out the examples.

kschaefe
Offline
Joined: 2006-06-08

> > Is there anything in particular, you'd like me to
> clean up?
>
> No not really picking on you, it just you were in my
> default list of useful contributions (up until the
> compile failed;). Mostly I was wanting to look at the
> combo, column highlighters but having to wrangle
> dependancies and deprecations (and their causes) all
> the time tends to put me off trying out the examples.
To be warned, the column-highlighting code and some other code that has made it into SwingX is going to be removed from my incubator soon; no need for two copies. I am also reorganizing to make it easier to pick and choose pieces of my incubator code.

Karl

kleopatra
Offline
Joined: 2003-06-11

>
> actually the tag for the death-bound api is
> "@deprecated (pre-0.9.2)" - and most of those right
> now have a life expectancy of a week or so. [ Obvious
> advice skipped ... ]
>

mostly done (not completed yet due to not fully detangled internal code .. lazy me ;-) for

- calendar widgets and -ui
- renderer/highlighter related

Cheers
Jeanette

kleopatra
Offline
Joined: 2003-06-11

> - "versioning": not particularly interested in
> procedures - but would like to establish a rule like
> "keep a deprecated something for exactly one
> release". Combined with the rule "don't deprecate
> without alternative" this should allow for smooth
> enough (for a Labs project) migration.
>

done. All current deprecation (in javadoc) now looks like

@deprecated (since release 0.9.2)

So we can easily distinguish them from newer deprecation (which have just the normal @deprecated tag) and remove any time between now and the next release.

CU
Jeanette

kleopatra
Offline
Joined: 2003-06-11

Yet another sequel in the alerts:

>
> @deprecated (since release 0.9.2)
>
> So we can easily distinguish them from newer
> deprecation (which have just the normal @deprecated
> tag) and remove any time between now and the next
> release.
>

actually the tag for the death-bound api is "@deprecated (pre-0.9.2)" - and most of those right now have a life expectancy of a week or so. [ Obvious advice skipped ... ]

Jeanette

osbald
Offline
Joined: 2003-06-13

Will that include updating your ghetto incubator code ? spent an age trying to get your bindings demos going. Had to exclude all the calendar stuff and you've also used javax.swing.GroupLayout somewhere which meant swapping over to 1.6 to compile..

Guess you're not big on clever IDEs trying to validate all of your src folders all the time?

Oh the selection on the beansbindings demo doesn't work.. but you've not updated it in an age either. Funny how the beansbindings version feels a little more sluggish than the JGoodies one, or is it me?

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> Will that include updating your ghetto incubator code ? spent an age trying to get your bindings demos going. Had to exclude all the calendar stuff and you've also used javax.swing.GroupLayout somewhere which meant swapping over to 1.6 to compile..
>
>

GroupLayout - me??
> Guess you're not big on clever IDEs trying to validate all of your src folders all the time?
>

Don't confound me with NetBeans users Everything under
kleopatra/java should be fine - no red warnings from my clever Eclipse.
> Oh the selection on the beansbindings demo doesn't work.. but you've not updated it in an age either. Funny how the beansbindings version feels a little more sluggish than the JGoodies one, or is it me?
>
hmmm ... last time I looked (which was not recently as you noticed ;-)
selection was okay. And yeah, me too: feels more sluggish right from the
start. But improved somewhere along the 1.0 release of beansbinding.

You know it, but I'll spell it out anyway: the incubator isn't in any
way guaranteed to be maintained - though I try my best. If you have
suggestions to change any code, please let me know - I might be inclined
to leave it to you to actually do it (in my ghetto )

CU
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

osbald
Offline
Joined: 2003-06-13

> GroupLayout - me??

Ok after tracking the offender down you might be in the clear (based on package name), but it's not under your foreign code either : jdnc-incubator\src\kleopatra\test\org\jdesktop\swingx\treetable\bolsover\multicell\MultiCellDemo.java

> If you have suggestions to change any code, please let me know

Well, it would've helped if the bindings demos were a little more self contained. It needs your swingx src folder as it picks some version of Scotts extreme render and some funky TexPainter (from memory). But the calendar stuff under here doesn't fly with the current swingx code. Speaking of which I needed the current swingx code in full because it wanted AcientSwingTeam and ProgressChangeReport from swingx/test (memory again) so the swingx jar under jdnc/lib/share wouldn't cut it.

It also helps having contained mini-project folders when they're not workable anymore its easy to ignore the whole directory.. or remember to occasionally shuffle stuff out of src/swingx to an old bytes home..?

Some of this is partly an IDEA issue, I can exclude whole packages/folders, but not individual classes from a package. So for example Karls org.jdesktop.swingx.JXToolBar that wasn't compiling (background painters are defined as Painter not Painter) meant I had to exclude to whole of his swingx package that almost everything else hangs off. Not the only issue the duplicate org.jdesktop.swingx.JXTable(s) also wont compile :- if swingx dependencies were expressed as source code rather than jar/class. Oh and Karl definitely likes his 6.0 ;)

kleopatra
Offline
Joined: 2003-06-11

Thought you got me, but...
>
> Ok after tracking the offender down you might be in
> the clear (based on package name), but it's not under
> your foreign code either :
> jdnc-incubator\src\kleopatra\test\

all I promised was ..\kleopatra\java That's what gets compiled by _build-kleopatra.xml (which hopefully still works, didn't try for a while). Excluding the test should be okay ... need to check against a recent swingx.jar, though. Could well be that references to the swingx/test crept in recently (that would be any dependencies on AncientSwingTeam and PropertyChangeReport).

>
> Well, it would've helped if the bindings demos were a
> little more self contained. It needs your swingx src
> folder as it picks some version of Scotts extreme
> render and some funky TexPainter (from memory). But
> the calendar stuff under here doesn't fly with the
> current swingx code.

interesting ... sounds like I don't have my complete code base in the top of my head

>
> It also helps having contained mini-project folders
> when they're not workable anymore its easy to ignore
> the whole directory.. or remember to occasionally
> shuffle stuff out of src/swingx to an old bytes
> home..?
>

yeah, in an ideal world ;-) No offence meant, naturally, but if you want to change my priority list from caring about SwingX to caring about the incubator, feel free to drum up support.

CU
Jeanette

osbald
Offline
Joined: 2003-06-13

> yeah, in an ideal world ;-) No offence meant, naturally, but if you want to change my
> priority list from caring about SwingX to caring about the incubator

No No No, Just winging and letting you know people are still interested in your experiments. Was partly self-serving as I worried about how much this deprecation will break the next time I dig into the incubator.

> feel free to drum up support.

Yeah right. Talk about kicking a guy when he's down

Much rather seeing Sun drum up support for beansbings, appframework and swing itself for that matter. Still no word from Shannon despite the bellyaching? http://today.java.net/pub/a/2008/03/20/synchronizing-properties-with-bea...
, http://www.pushing-pixels.org/?p=282 , nice to see, but no follow ups? https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1445

kleopatra
Offline
Joined: 2003-06-11

oookaaayy ... it's underway:

- code base tagged with jw_before_deprecation_cleanup
- the plan is to remove everything that has been deprecated in version 0.9.1 while keeping those deprecated later: this gives the milestone users a chance for a smooth migration (more or less ;-)

Will notify you when the cleanup is complete.

CU
Jeanette

kleopatra
Offline
Joined: 2003-06-11

done.

Couple of comments/questions:

- "versioning": not particularly interested in procedures - but would like to establish a rule like "keep a deprecated something for exactly one release". Combined with the rule "don't deprecate without alternative" this should allow for smooth enough (for a Labs project) migration.

- to ease the effort of removing (had to manually compare against the last release for those I couldn't remember when they were added ;-) I would like to add like a "version tag" to the deprecation so we can search for it. As an example, all those added after the current release would now get an "@deprecated before 0.9.2" This way we could happily add new deprecations after the 0.9.2 release and before the next, easily find all which are older.

- javadoc @deprecated vs. @Deprecated annotation: which to use? most Swingx is javadoc only, some are (in fact, had been - just added the javadoc recently) annotation only, some have both. Personally, I prefer the javadoc: we can (and should ;-) add a "use some-alternative" comment and (in future) something like a version tag, see above

Thoughts?

Jeanette

kschaefe
Offline
Joined: 2006-06-08

The code should be deprecated using the annotation and the deprecation should be documented in the JavaDoc. In other words, we should do both.

Karl

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> The code should be deprecated using the annotation and the deprecation should be documented in the JavaDoc. In other words, we should do both.
>
>

sounds good - so changed my eclipse settings to alert for missing
@deprecated annotations and let it fix the problem . Committed.

CU
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net