Skip to main content

SwingX roadmap?

39 replies [Last post]
Anonymous

Hi,

Is there a well defined roadmap for SwingX?

I would like to have a stable basis of JavaBean components to start my
projects with.

Thanks,
Antonio

---------------------------------------------------------------------
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.
Kleopatra

>
>>* unreviewed: freely added to the code-base, that's
>>the current status
>>of everything
>>* RC: the hardcore of stable components
>>* temp1.5: the classes which will be dropped when
>>going mustang (because
>>the core jdk will take over)
>>* future-RC: the components that are not yet ripe for
>>the limelight, but
>>are expected to be done in a later version
>>* experimental: components where it's not known if
>>they will ever make it
>
>
> +1. I was thinking that we should add a javadoc tag like "@status" which could have the names you proposed. We'd tag all code, and update that tag as we go.
>
>

what I was musing about was to have two tags (just for the process time)

@status: unreviewed
@targetStatus:

when the process is passed, @status is changed to review result - which
may be the initially expected or not. It's allowed to add targetStatus
tags as we like, but the status tag can be changed only after the
review. And yes, I agree, we shouldn't overdo it with formalism, it's
more a mental image of classifying objectives.

It get's important when dependencies come into play: it's clear that
code with (end) status RC cannot depend on code with (end) status future
or experimental, but it can depend on code with temp1.5 - at least
that's my opionion. F.i. we would rip out more than half the heart of
JXTable if it couldn't depend on the SwingX-way of sorting.

CU
Jeanette

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

rbair
Offline
Joined: 2003-07-08

> > +1. I was thinking that we should add a javadoc tag
> like "@status" which could have the names you
> proposed. We'd tag all code, and update that tag as
> we go.
>
> what I was musing about was to have two tags (just
> for the process time)
>
> @status: unreviewed
> @targetStatus:
>
> when the process is passed, @status is changed to
> review result - which
> may be the initially expected or not. It's allowed to
> add targetStatus
> tags as we like, but the status tag can be changed
> only after the
> review. And yes, I agree, we shouldn't overdo it with
> formalism, it's
> more a mental image of classifying objectives.

I'm not sure the second tag makes sense. Instead, couldn't we just keep a list in the wiki of the rough-approximation of target status?

> It get's important when dependencies come into play:
> it's clear that
> code with (end) status RC cannot depend on code with
> (end) status future
> or experimental, but it can depend on code with
> temp1.5 - at least
> that's my opionion. F.i. we would rip out more than
> half the heart of
> JXTable if it couldn't depend on the SwingX-way of
> sorting.

Yes, RC code cannot _publicly_ depend on future/experimental code, but it can internally. Its the public API I care about. The reviews will not be covering the actual code implementation (which we can change at any time), just the API. Of course, if RC code's implementation relies on future/experimental code, then that future/experimental code should be made package private so it is not exposed to the world.

In the case of temp1.5 code, the best case scenario would be for public API of RC to not explicitly depend on temp1.5, but have an interface or something to shield it from the temp1.5 code. But that's just in the ideal case. In real life we may have to allow a dependency between RC and temp1.5.

Richard

Kleopatra

Hi Adam,

>
> I don't think tagging will work as nice for you. Tagging just takes a "snapshot" of the code. It keeps it in the same branch. It will make future development more difficult.

sorry had been sloppy: as Richard assumed, I meant one of the informal
"tagging" solutions as suggested by Jesse ;-)

>
>>And I
>>wouldn't be very happy with the third (switching to
>>Subversion - Eclipse
>>doesn't support it out-of-the-box :)
>
>
> FYI, the Subclipse plugin is working fantastic for me, as good as the CVS support. It works exactly the same way and is better with refactorings (mostly because Subversion handles moving/renaming files better).
>

Weeelll .. at the basis of my reluctance is my absolute hate to change
tools as long as I can work reasonably nicely with the old (I was
probably one of the last dinosaurias on earth to switch to any IDE at
all). That said, just got a notification from javalobby about a
step-by-step how to use subclipse in Eclipse (didn't read it yet, though
- that's left for later on the beach ) In case somebody is interested:

Cheers
Jeanette

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

thiagol
Offline
Joined: 2006-06-29

Hello,

I was just wondering if I decision has been made on the roadmap? I guess I'm just asking Antonio's initial question again. I felt like the discussion got a little bit carried away and I'm not sure a decision was actually made.

I think it would be really nice if a road map got posted on the website so that everyone can see.

We are looking to use swingx in our product and it would be helpful to see that this project has a direction and goals. I'm sure other people considering using the library would find this helpful too.

Thanks,

Thiago

rbair
Offline
Joined: 2003-07-08

> I think it would be really nice if a road map got
> posted on the website so that everyone can see.

Sure. Here's the overview:

SwingX as it now stands is "feature complete". Some additional features may be added as we scrub each SwingX component to get it ready for 1.0, but that is the exception rather than the rule.

SwingX components/frameworks need to go through an API review process before final release. Each component/framework in SwingX will go through this process, which consists of two reviews: an internal review and a public review. Review notes for both will be available on http://wiki.java.net/bin/view/Javadesktop/SwingLabsAPIReview. A much more detailed description of the review process and rationale is also included on the above referenced page.

As a SwingX component successfuly passes the review process and is documented (both javadocs and tutorials), tested, and complete it will be marked "RC". RC components are considered stable. When we've finished the process, we'll be ready to declare a 1.0 build.

So that's the basic idea. Do you have a recommendation as to how to write that up as a roadmap? Or is this description complete enough?

Thanks
Richard

thiagol
Offline
Joined: 2006-06-29

Hi Richard,

I think this info is pretty much sufficient. A few suggestions of other information that could be added:

* Maybe time estimates could be added just to give us a timeframe idea, and also it would show progress as things get done.

* To give a more detailed information, maybe we could show where each component/framework is in the review/RC process.

* And also, I would add long-term goals...."After release 1.0, what's next? "...."what won't make release 1.0? but will be in next releases"...stuff like that...really just to give an idea of where the project is going.

Not sure if this info is on the website already, but I think that would be very interesting for the project.

Thanks for the reply!

Thiago

Kleopatra

Hi Thiago,

>
> * Maybe time estimates could be added just to give us a timeframe idea, and also it would show progress as things get done.
>
> * To give a more detailed information, maybe we could show where each component/framework is in the review/RC process.
>

good points! The decision to revolutionary idea to "go and prepare for
review now" is very young, its age measured in days So currently
everything has pre-review state with no idea about how long it will take
us. The process is meant to be very visible: steps to take/taken,
status, progress or obstacles will be documented in the wiki.

> * And also, I would add long-term goals...."After release 1.0, what's next? "...."what won't make release 1.0? but will be in next releases"...stuff like that...really just to give an idea of where the project is going.
>

that's a good one, too. Actually I stumbled across it when trying to
set-up a work-plan and finding out what should be done first. I think
the DEV/RC doesn't fully capture the possible states and the transitions
between them. Trying something more fine grained:

* unreviewed: freely added to the code-base, that's the current status
of everything
* RC: the hardcore of stable components
* temp1.5: the classes which will be dropped when going mustang (because
the core jdk will take over)
* future-RC: the components that are not yet ripe for the limelight, but
are expected to be done in a later version
* experimental: components where it's not known if they will ever make it

IMO, the "expected target status" will influence the review process, at
least facilitate any prioritizing: evolution on temp1.5 is stopped
anyway, so there's no reason to put too much work in a review
preparation, they could be delivered as-is with a clear indication of
being temporary. The experimental might even require less review work
(except documentation about what they intended to do and decide to give
them that status). Then work can concentrate on the other two, the
future-RC more relaxed than the hardcore RC.

So the first step would be tag all components with the expected status -
which I expect to be controversial . Some examples (neither complete
nor fixed) from my perspective:

RC: the collection views, revised Highlighter, translucency, Painter
future-RC: everything around TreeTable, everything around,
frame/rootpane/statusbar
temp1.5: the sorting/filtering support
experimental: everything around TargetManager, the default context menu
support

Jeanette

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

rbair
Offline
Joined: 2003-07-08

> > * Maybe time estimates could be added just to give
> us a timeframe idea, and also it would show progress
> as things get done.
> >
> > * To give a more detailed information, maybe we
> could show where each component/framework is in the
> review/RC process.
> >
>
> good points! The decision to revolutionary idea to
> "go and prepare for
> review now" is very young, its age measured in days
> So currently
> everything has pre-review state with no idea about
> how long it will take
> us. The process is meant to be very visible: steps to
> take/taken,
> status, progress or obstacles will be documented in
> the wiki.

Exactly. There isn't much there yet, but what I have will be added.

> * unreviewed: freely added to the code-base, that's
> the current status
> of everything
> * RC: the hardcore of stable components
> * temp1.5: the classes which will be dropped when
> going mustang (because
> the core jdk will take over)
> * future-RC: the components that are not yet ripe for
> the limelight, but
> are expected to be done in a later version
> * experimental: components where it's not known if
> they will ever make it

+1. I was thinking that we should add a javadoc tag like "@status" which could have the names you proposed. We'd tag all code, and update that tag as we go.

> So the first step would be tag all components with
> the expected status -
> which I expect to be controversial .

I don't see any problems here. We just tag everything as a starting point with someting (just not RC :-)). As we crawl through the codebase, if we don't agree on the status then we'll talk and vote on it. I don't think we should spend a lot of time figuring out what the "current" status of everything is. The review process will sort things out.

What do you think?
Richard

thiagol
Offline
Joined: 2006-06-29

Would it make sense to NOT tag anything now, and then only tag a component, when it has passed the review process and is ready for RC?

I'm just thinking that it will keep people from making mistakes in terms of what has been tagged, wrong tags, etc...

No tags means not reviewed, RC (or whatever) tag means review complete and ready to go...

I guess I'm just afraid too many tags might add too much complexity...

Thiago

rbair
Offline
Joined: 2003-07-08

> Would it make sense to NOT tag anything now, and then
> only tag a component, when it has passed the review
> process and is ready for RC?

I think it makes sense to keep a list somewhere so that those of us working on the project have a general idea of what each bit of code is destined for. However, I think you are right, and this list should be kept on a wiki rather than tagged in the source code.

bobsledbob
Offline
Joined: 2005-03-25

> I prefer the tagging approach magnitude-fold over
> branching.

I don't think tagging will work as nice for you. Tagging just takes a "snapshot" of the code. It keeps it in the same branch. It will make future development more difficult.

What has been discussed would work best with a branch. The HEAD will be your stable release. A new branch would be your DEV. This is how it will need to be sometime in the future, why not now?

http://www.psc.edu/~semke/cvs_branches.html

Just from my POV, you need to either branch or do what Richard suggested originally and have an extra folder for the unstable classes. I think a branch would be best, but that's just me.

> And I
> wouldn't be very happy with the third (switching to
> Subversion - Eclipse
> doesn't support it out-of-the-box :)

FYI, the Subclipse plugin is working fantastic for me, as good as the CVS support. It works exactly the same way and is better with refactorings (mostly because Subversion handles moving/renaming files better).

Plus, as an outside tool (explorer shell based), TortoiseSVN is amazing.

I don't know about Netbeans, too bad it doesn't support SVN out of the box. It should.

Adam

rbair
Offline
Joined: 2003-07-08

> > I prefer the tagging approach magnitude-fold over
> > branching.
>
> I don't think tagging will work as nice for you.
> Tagging just takes a "snapshot" of the code. It
> t keeps it in the same branch. It will make future
> development more difficult.

By "tagging", I don't think Jeanette is referring to the CVS tag operation, but rather noting each class that is dev/rc in a build file or in the file's javadoc.

Richard

Kleopatra

Hi Richard,

thanks for your clarifications about the process, they really helped to
understand what you are driving at.

> The one critical element to all this is the API review process.

What I'm still not quite clear about is what are the criteria for an
"api review"? I'm not familiar with the concept - what are reviewers
expected to look for, what's the metric of Sun/Swing reviews?

>
> Reviews can be lengthy.

yeah, one part of SwingLabs went through it last year - and in the end
died ;-)

So the question is - what can we do to a) speed up and b) getting
unscarred (that is without too many major changes, though I'm well aware
of the divers construction sites around) through the review?

>
> While this process will require a fair amount of work, it will also put us in a stable position and will be significantly easier for future additions than for this review process encompassing all our old code. Further, it gives a more straightforward path for outside contributors who want to get their code committed to the main swingx tree.
>

indeed, it will be quite some work - but agree that the project needs
more stability. Hopefully, this will not strangulate innovation.

Cheers
Jeanette

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

rbair
Offline
Joined: 2003-07-08

Hi Jeanette,

> thanks for your clarifications about the process,
> they really helped to
> understand what you are driving at.

Cool! Thanks for your patience.

> > The one critical element to all this is the API
> review process.
>
> What I'm still not quite clear about is what are the
> criteria for an
> "api review"? I'm not familiar with the concept -
> what are reviewers
> expected to look for, what's the metric of Sun/Swing
> reviews?

The first requirement is a piece of code that is ready to be defended. What we don't want to do is to devolve into a design-by-committee review, which is what happens to poorly or incompletely thought out API. It's ok to go into it with a few open questions, but we also need to have a suggested solution to think about.

Also, expect that even the most trivial code (like JXPanel) is going to be revised during the process. In a successful review a year and a half ago (or thereabouts) Bino brought in the authentication framework. It looked different afterward, but has essentially been stable since.

Be prepared to defend why a certain design was taken. Why not one of several alternative designs? What makes the proposed solution better? More complicated API needs to be more rigorously defended, particularly with why the complicated API was chosen. Are the use cases enabled by the more complex API worth it?

Of course a list of requirements up front is critical. What are we trying to achieve with this API? If the requirements are off, the review will most likely be postponed until the requirements are refined and API refined as necessary.

First thing in the morning, that's all I can come up with :-). Next week we'll get the first review (or two) done and hopefully opened up for public review. So, yes, we'll start with something easy so it doesn't get bogged down and so everybody can see what the process is like. And so we can work out any kinks that might exist.

> > Reviews can be lengthy.
>
> yeah, one part of SwingLabs went through it last year
> - and in the end
> died ;-)
>
> So the question is - what can we do to a) speed up
> and b) getting
> unscarred (that is without too many major changes,
> though I'm well aware
> of the divers construction sites around) through the
> review?

Preparation is key. All the details need to be thought through as much as possible. For some API such as JXPanel this is a mostly trivial job (requiring a day or two of documentation and thought), but for others like Highlighters or Painters, it will be quite a bit more work to really have thought out the design.

> > While this process will require a fair amount of
> work, it will also put us in a stable position and
> will be significantly easier for future additions
> than for this review process encompassing all our old
> code. Further, it gives a more straightforward path
> for outside contributors who want to get their code
> committed to the main swingx tree.
> >
>
> indeed, it will be quite some work - but agree that
> the project needs
> more stability. Hopefully, this will not strangulate
> innovation.

I believe that with a stable foundation, it will actually increase innovation and participation because there will be a clear roadmap for adding new components to the project. In addition, I plan on giving more developer rights to folks who've been around helping us out for a while.

Cheers
Richard

Kleopatra

Hi Richard,

> First thing in the morning, that's all I can come up with :-).

quite impressive, thanks!

> Next week we'll get the first review (or two) done and hopefully opened up for public review. So, yes, we'll start with something easy so it doesn't get bogged down and so everybody can see what the process is like. And so we can work out any kinks that might exist.
>

cool, I love to learn by example. Do you already have a planned on the
order of api to review? Most of them need lots of work to be make shiny
(mine for sure :)

>
> I believe that with a stable foundation, it will actually increase innovation and participation because there will be a clear roadmap for adding new components to the project.

could well be, we'll see.

>In addition, I plan on giving more developer rights to folks who've been around helping us out for a while.
>

great, we need every helping hand!

Jeanette

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

rbair
Offline
Joined: 2003-07-08

> Do you already have
> a planned on the
> order of api to review? Most of them need lots of
> work to be make shiny
> (mine for sure :)

No, I don't have an order, but we need to have something of a pipeline built up so that getting code ready to review isn't the bottleneck. I'll start a wiki page where we'll list each of the components as they are ready for review. Each will link to a page containing information regarding that component (the review notes, pdf document of the slides, etc). When I get the first review docs ready to go I'll post them there too.

I was going to hit all the easy ones first :-). JXErrorDialog, JXLoginPanel, JXPanel, JXHeader, JXGraph, JXMultiSplitPane (Hans wrote it, should be easy to get him to ok it :-)), JXTitledPanel, JXTitledSeparator, and probably a few others (like the utils) and JXStatusBar. They should be relatively easy to do, and provide enough material and experience with the process.

Richard

Antonio

Some comments inline

Jesse Wilson wrote:

> It looks like what you really need to do is
> tag files as being RC or Dev, and you mght
> want to try options other than moving the files
> from one directory to another to get these tags.
>
> One problem with moving them around on the
> filesystem is that it's a pain whenever you want
> to graduate a file from 'rc' to 'dev'. This will cause
> pain with CVS patches, revision history, and
> collaborative development. What happens if one
> person moves a file and the other person edits it?

I agree with this (and some other replies as well).

>
> Some alternative ways to tag your source code:
> - list the 'rc' files in a text file called rc.txt, which you can
> use with your Ant compile to compile only those.

This makes a lot of sense. In fact I'd propose generating two different
deliverables for the two options.

- A design-time jar file, with all the BeanInfo stuff. This one is
targetted for inclusion inside IDEs, to make SwingX components available
into the component palette for visual design.

- And a run-time jar file, without all those useless BeanInfo class
files. This could be a stripped-down version of the previous one, where
all BeanInfo and "package.html" files have been removed. After all, the
smaller the jar file is the fastest to download through Java Web Start.

As an example: I've downloaded latest CVS sources and found out that
dist/swingx.jar is about 1.9Mb. A stripped down version (without the
BeanInfo and html stuff) is around 1Mb. Space reduction is important for
Java Web Start-ed apps.

So maybe it's a good idea to work out a little bit the build script, as
Jesse suggests. You could then generate two files for the RC files
(swingx-design.jar and swingx.jar) and two other files for the DEV files
(swingx-dev-design.jar and swingx-dev.jar).

Would it be useful to have a graph of dependencies between classes in
SwingX? I may be able to create one, if anyone is interested.

Cheers,
Antonio

> - move to Subversion, use its built in metadata
> system
> - Java 5 annotations. This is less visible to Ant
> but more fun. You could then write some code to
> select classes with a particular annotation
> @Tags("RC") or @Tags("Dev") or @Tags("Legacy")
> - A Javadoc comment. The nice thing about this is
> you can see which is which in the generated Javadoc.
>
> Cheers,
> Jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>

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

rbair
Offline
Joined: 2003-07-08

> > It looks like what you really need to do is
> > tag files as being RC or Dev, and you mght
> > want to try options other than moving the files
> > from one directory to another to get these tags.
> >
> > One problem with moving them around on the
> > filesystem is that it's a pain whenever you want
> > to graduate a file from 'rc' to 'dev'. This will
> cause
> > pain with CVS patches, revision history, and
> > collaborative development. What happens if one
> > person moves a file and the other person edits it?
>
> I agree with this (and some other replies as well).

Sounds like good advice.

> > Some alternative ways to tag your source code:
> > - list the 'rc' files in a text file called rc.txt,
> which you can
> > use with your Ant compile to compile only those.
>
>
> This makes a lot of sense. In fact I'd propose
> generating two different
> deliverables for the two options.
>
> - A design-time jar file, with all the BeanInfo
> stuff. This one is
> targetted for inclusion inside IDEs, to make SwingX
> components available
> into the component palette for visual design.
>
> - And a run-time jar file, without all those useless
> BeanInfo class
> files. This could be a stripped-down version of the
> previous one, where
> all BeanInfo and "package.html" files have been
> removed. After all, the
> smaller the jar file is the fastest to download
> through Java Web Start.

That was what I was driving at by putting all the BeanInfo into its own source tree -- makes it easy to exclude in an ant build when creating the runtime jar. I guess I just haven't done it yet :-).

As for tagging which files are "dev" and which are "rc", there have been two suggestions. The first is to use the build system to do the work (via a dev.txt file, or some such manual list of classes/packages), the second is to use a branch. Of the two I think I favor the first, just because our use of branches in the past was very confusing to people coming into the project. I want to use branches for doing new development, but for this current task I think it would be more confusion than benefit.

What do you all think?

Richard

Kleopatra

jdnc-interest@javadesktop.org wrote:
>
> As for tagging which files are "dev" and which are "rc", there have been two suggestions. The first is to use the build system to do the work (via a dev.txt file, or some such manual list of classes/packages), the second is to use a branch. Of the two I think I favor the first, just because our use of branches in the past was very confusing to people coming into the project. I want to use branches for doing new development, but for this current task I think it would be more confusion than benefit.
>

I prefer the tagging approach magnitude-fold over branching. And I
wouldn't be very happy with the third (switching to Subversion - Eclipse
doesn't support it out-of-the-box :)

Jeanette

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

rbair
Offline
Joined: 2003-07-08

> I prefer the tagging approach magnitude-fold over
> branching. And I
> wouldn't be very happy with the third (switching to
> Subversion - Eclipse
> doesn't support it out-of-the-box :)

Neither does NetBeans :-)

Kleopatra

Hi Richard,

playing a little fun game of

> I need to be convinced of the necessity of all these classes :-).

you want to rip them out, it's your turn to convince :-).

> They're good stuff :-)

maybe - what for? :-)

Obviously we could go on forever without getting anywhere - plus it's
beside the point I tried to make (probably shaded by a certain
grumpiness ;-) I'll repeat what I meant as the important section of my
previous post:


* for the components define the "X"-ness - what's at its heart to make
it worthwhile, compare design goals with what we actually have, see if
it's useful at all
* the same for each part of the infrastructure, with special attention
the dependencies from inside swingx
* define criteria to characterize "DEV"-state vs. "RC"-state
* decide how much DEV-ness we can/are willing to/must tolerate to not
cripple the release

What else to think about? How do we best organize that work?

The output of such a process should be

a) a better understanding of where the project wants to go (per
component, per cross-component support, per utility feature maybe?)

b) a status description: where are we, what needs to be done, how much
time do we reckon it will take

c) clear criteria for the dev --> rc transition

There's still much leeway for disagreement But then we have a sound
basis to argue on.

Currently I'm musing a bit about the "what" and the "how" - it should be
as lightweight as possible and as heavyweight as needed to be useful.
For the "final 1.0 swingx" of last summer, I had a simple html table -
which nobody except myself was interested in Plus it wasn't too
expressive ...

Here's a raw bunch of "status info" properties which might be useful to
characterize the maturity of a component (where "component" is not
necessary taken literally, can be a support class or concept as well):

for each component
- a list of committed features: they will be done in 1.0
for each committed feature
- status: ready, tbd
- ready means: implemented + tested + demo'ed + documented
- tbd:
* obstacles (none, known, expected);
* time estimate to do;
* priority;
* whodunnit;
* emergency brake (postpone to future, consequences)
- a list of approved features: they are planned to be done, but post1.0
- a rough estimate of its "conceptual weight" (the expression is wrong,
something like usefulness, expected/known contexts/use-cases ...)

Hmm .. looks like a common work to do (except that in "normal", more
ordered environments this is done more continually), are there any
tools, spread-sheets, "best practices" ... ?

CU
Jeanette

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

rbair
Offline
Joined: 2003-07-08

Hey Jeanette,

> > I need to be convinced of the necessity of all
> l these classes :-).
>
> you want to rip them out, it's your turn to convince
> :-).

In a previous post I said "Even for those that are listed RC, they will not be put back into the root src tree until after they have had a thorough code review". I should have said "API review" instead of "code review", but the spirit of it is the same.

More below...

> a) a better understanding of where the project wants
> to go (per
> component, per cross-component support, per utility
> feature maybe?)
>
> b) a status description: where are we, what needs to
> be done, how much
> time do we reckon it will take
>
> c) clear criteria for the dev --> rc transition
[snip]
> for each component
> - a list of committed features: they will be done in
> 1.0
> for each committed feature
> - status: ready, tbd
> - ready means: implemented + tested + demo'ed +
> d + documented
> - tbd:
> * obstacles (none, known, expected);
> * time estimate to do;
> * priority;
> * whodunnit;
> * emergency brake (postpone to future,
> uture, consequences)
> - a list of approved features: they are planned to be
> done, but post1.0
> - a rough estimate of its "conceptual weight" (the
> expression is wrong,
> something like usefulness, expected/known
> contexts/use-cases ...)

The one critical element to all this is the API review process. It is through this process that these things will shake out. Roughly, everything we have in SwingX now I'm interested in keeping (roughly). The API may change as a consequence of reviews, entire pieces may be removed for more work later, and so forth. Generally, I'm not interested in adding any new features at this point. I'd like to firm up what we have first.

Reviews can be lengthy. Due to this, what I suggest is that we'll do a review here at Sun, and publish the materials and findings to that review in the wiki. We'll then hold a second review externally. The idea is that all minor issues will shake out during the internal review and make for a more expeditious public review.

I like to use two sources of material for reviews: the javadoc and a set of powerpoint slides. This means that javadoc must be written for components to be reviewed :-). More importantly, it makes it easier on reviewers. I like to use powerpoint to exhibit code samples, design decisions, use cases, and other supporting documentation. For the purpose of being web-friendly, I'd rather publish these slides as .pdf files rather than powerpoint.

Once reviewed and approved by both internal and public review "boards" (comprising committers -- of course everyone is free to chime in) the code is marked as RC.

All the RC/DEV listings at the beginning maybe were not very helpful -- they were intended as a rough starting point for what code is ready for review and what code isn't -- not as a stamp of "goodness". As an example, I was going through the JXPanel (since it should be simple to review, right?) and found certain rough edges and API (the gradient background stuff) that really doesn't belong anymore. So even something simple like JXPanel with it's "RC" status will undoubtedly go through revision during the review process.

In summary, the process is to tag everything as "dev" to begin with. Then take components through the review process (first internal, then public). Finally, change to "rc" for the component once approved. Every component, package, and class will pass through this process (some quicker than others). At the end of this process, comprehensive unit tests, javadocs, and tutorial documentation must be written for the component.

What "comprehensive" means is: the unit tests must pass Jeanettes muster (our resident Unit Test advocate :-)). JavaDocs must be complete (all tags where the belong, written according to the guidelines posted here http://java.sun.com/j2se/javadoc/writingdoccomments/). Tutorial docs must exist on swinglabs.org according to Josh Marinacci's standards (our resident writer :-)).

While this process will require a fair amount of work, it will also put us in a stable position and will be significantly easier for future additions than for this review process encompassing all our old code. Further, it gives a more straightforward path for outside contributors who want to get their code committed to the main swingx tree.

I don't want to encumber the project with process, but something more formal than what we've been following is necessary. As always, free form code lives happily in the incubator.

Cheers
Richard

coxcu
Offline
Joined: 2003-06-11

> What "comprehensive" means is: the unit tests must
> pass Jeanettes muster (our resident Unit Test
> advocate :-)). JavaDocs must be complete (all tags
> where the belong, written according to the guidelines
> posted here

In the ideal build system, developers just check in code. Whenever all of the quality metrics are met, the build system spits out another build. This is tough to achieve in practice. Still, there are tools to detect gaps in test coverage and Javadoc.

- Curt

david_hall
Offline
Joined: 2003-06-12

> In the ideal build system, developers just check in
> code. Whenever all of the quality metrics are met,
> the build system spits out another build. This is
> tough to achieve in practice. Still, there are tools
> to detect gaps in test coverage and Javadoc.
>
> - Curt

... but knowing that the code is reasonably well written and tested isn't nearly good enough. All that tells you is that the developer has probably done what he set out to do: it isn't until users start pounding on it that you find out if where you are is where you ought to be.

I don't believe that we can automate acceptance criteria, particularly in an area that has as many subjective criteria as GUI components.

dave

Romain Guy

I was seeing this split as two source directories within the SwingX
project: src-rc and src-dev for instance. src-rc can be shipped without
src-dev, but not the contrary.

The idea is to have a clear and clean separation between what works and
what's in the works. As for releasing a 1.0 it's high time it happened.
People have been wanting one since the early days of JDNC and I keep
getting dozens of requests every time I give a talk where I use some
SwingX classes.

Marketing is part of a successful project, even if it's "just" an open
source one. As of today, it's hard for many people to settle on the
half-baked 0.8 release or to go use the CVS directly. We're not working
for us only, but for all the potential users. If that's a 1.0 they want,
that's a 1.0 we have to give them.

By the way, java.net lets you choose between CVS and Subversion...

jdnc-interest@javadesktop.org wrote:
> Richard,
>
> Are you suggesting a literal split in the source and/or project? Ie. One CVS tree becomes two? One swingx project becomes two, swingx and swingx-dev? Like how jdnc-incubator, for example, is a separate project with potential swingx classes?
>
> Or, are you suggesting braching the current CVS tree with "stable" and "unstable" classes.
>
> I know this is an outsider's POV, but speaking as one who has done more release management than I care to admit, actually splitting the source tree up is a mistake.
>
> If the goal is to create swingx-stable-1.0.jar, then let that be a build function. Though I'm no ant expert, I'd suppose it wouldn't be hugely difficult to copy only certain classes into a jar. Mark your API stable classes and have ant put them into a package. You could branch in CVS too and accommplish the same. You'd really only need the binary class files too for the stable jar, not the source.
>
> By splitting the actual tree, you're really making it difficult on yourself to migrate and promote a "dev" class to a "rc" class, to a "stable" class, etc. Let CVS do the work for you. By branching in the same tree, you can use the CVS merge tools to get your branched code back into the HEAD (stable) line.
>
> It's better, again in my opinion, to keep all your code together and just develop. Absolutely identify certain classes as being stable, yes, but don't split up the tree just for the sake of making some "1.0" release. A 1.0 release, afterall, is more for the marketdroids than anything else really.
>
> If you really have components that are just needing tons of work, then maybe they should be pushed down to the incubator. Other than that, keep your source code together. Document stable and unstable apis. Don't discount interdependancies.
>
> Adam
>
> p.s. This is the whole reason why Linus merged the dev and stable Linux kernel together starting in 2.6. It gets real tiring and difficult to manage two separate source trees, while its more productive without losing any stability to keep the source in one tree (with good testing and a stable api).
>
> p.p.s. It's unfortuneate that dev.java.net uses CVS. Subversion is so much nicer for this kind of stuff. It "just works" without all the CVS annoyances. Too bad.
> [Message sent by forum member 'bobsledbob' (bobsledbob)]
>
> http://forums.java.net/jive/thread.jspa?messageID=134009
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Romain GUY
http://jroller.com/page/gfx
http://weblogs.java.net/blog/gfx/
http://www.progx.org
http://www.jext.org

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

rbair
Offline
Joined: 2003-07-08

> PS: nearly forget - for the record an incomplete
> spontaneous list of my
> vetos against

...

> - dev status rollover infrastructure

This is listed as dev because I never got those warm fuzzies about the rollover infrastructure that I need to be feeling. The last time we talked about it there was some work you were going to do (experimentation if I remember correctly). This needs to be addressed again.

> search infrastructure

I have some pretty serious reservations with regards to this code. We have:

* AbstractSearchable
* JXFindBar
* JXFindPanel
* JXSearchPanel
* SearchFactory
* Searchable
* PatternModel
* AbstractPatternPanel

I need to be convinced of the necessity of all these classes :-).

> - (not very hard, need to be convinced of their
> usefulness :-) rc status
> of JXStatusBar, JXGraph, JXImagePanel

They're good stuff :-)

Richard

Jesse Wilson

It looks like what you really need to do is
tag files as being RC or Dev, and you mght
want to try options other than moving the files
from one directory to another to get these tags.

One problem with moving them around on the
filesystem is that it's a pain whenever you want
to graduate a file from 'rc' to 'dev'. This will cause
pain with CVS patches, revision history, and
collaborative development. What happens if one
person moves a file and the other person edits it?

Some alternative ways to tag your source code:
- list the 'rc' files in a text file called rc.txt, which you can
use with your Ant compile to compile only those.
- move to Subversion, use its built in metadata
system
- Java 5 annotations. This is less visible to Ant
but more fun. You could then write some code to
select classes with a particular annotation
@Tags("RC") or @Tags("Dev") or @Tags("Legacy")
- A Javadoc comment. The nice thing about this is
you can see which is which in the generated Javadoc.

Cheers,
Jesse

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

Patrick Wright

For the record, there are tools to migrate from CVS to Subversion
while retaining history; see the Subversion website. There are at
least two, I believe.

Patrick

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

bobsledbob
Offline
Joined: 2005-03-25

Richard,

Are you suggesting a literal split in the source and/or project? Ie. One CVS tree becomes two? One swingx project becomes two, swingx and swingx-dev? Like how jdnc-incubator, for example, is a separate project with potential swingx classes?

Or, are you suggesting braching the current CVS tree with "stable" and "unstable" classes.

I know this is an outsider's POV, but speaking as one who has done more release management than I care to admit, actually splitting the source tree up is a mistake.

If the goal is to create swingx-stable-1.0.jar, then let that be a build function. Though I'm no ant expert, I'd suppose it wouldn't be hugely difficult to copy only certain classes into a jar. Mark your API stable classes and have ant put them into a package. You could branch in CVS too and accommplish the same. You'd really only need the binary class files too for the stable jar, not the source.

By splitting the actual tree, you're really making it difficult on yourself to migrate and promote a "dev" class to a "rc" class, to a "stable" class, etc. Let CVS do the work for you. By branching in the same tree, you can use the CVS merge tools to get your branched code back into the HEAD (stable) line.

It's better, again in my opinion, to keep all your code together and just develop. Absolutely identify certain classes as being stable, yes, but don't split up the tree just for the sake of making some "1.0" release. A 1.0 release, afterall, is more for the marketdroids than anything else really.

If you really have components that are just needing tons of work, then maybe they should be pushed down to the incubator. Other than that, keep your source code together. Document stable and unstable apis. Don't discount interdependancies.

Adam

p.s. This is the whole reason why Linus merged the dev and stable Linux kernel together starting in 2.6. It gets real tiring and difficult to manage two separate source trees, while its more productive without losing any stability to keep the source in one tree (with good testing and a stable api).

p.p.s. It's unfortuneate that dev.java.net uses CVS. Subversion is so much nicer for this kind of stuff. It "just works" without all the CVS annoyances. Too bad.

rbair
Offline
Joined: 2003-07-08

Hey Adam,

> Are you suggesting a literal split in the source
> and/or project? Ie. One CVS tree becomes two? One
> swingx project becomes two, swingx and swingx-dev?
> Like how jdnc-incubator, for example, is a separate
> e project with potential swingx classes?
>
> Or, are you suggesting braching the current CVS tree
> with "stable" and "unstable" classes.

Neither. The idea is:

[pre]
swingx
/lib
/dist
/src
/java
/beaninfo
/dev
/test
...etc
[/pre]

So it is literally a source tree, but within the same project. Everything would continue as it is. All the files are included in the same jar by default. Files in one src tree can refer to classes in the other (but shouldn't!). My thinking is that it is the simpliest way to clearly separate stable and unstable code.

In the future, development work will always be done on a branch. The trunk should only house completed, tested, documented code. Of course between releases this code is not guaranteed to be stable API, but to the best of our knowledge it would be complete.

> If the goal is to create swingx-stable-1.0.jar, then
> let that be a build function. Though I'm no ant
> expert, I'd suppose it wouldn't be hugely difficult
> to copy only certain classes into a jar.

This is the basic idea I'm advocating. Its just that instead of maintaining a huge list of classes in the build file I'm using directory structure as the separator.

If we can't find a good way to move files without losing revision history, then we'll probably have to maintain a huge list of files in the build file, denoting which is RC and which is still DEV.

> If you really have components that are just needing
> tons of work, then maybe they should be pushed down
> to the incubator.

Some things may need to be pushed to the incubator. Good point.

Richard

> p.p.s. It's unfortuneate that dev.java.net uses CVS.
> Subversion is so much nicer for this kind of stuff.
> . It "just works" without all the CVS annoyances.
> Too bad.

java.net now supports subversion, but I don't know if they support migrating from cvs to subversion. I wouldn't mind migrating down the road, but one thing at a time :-)

Message was edited by: rbair

bobsledbob
Offline
Joined: 2005-03-25

Richard / Romain,

Ok, that clarifies. Thanks.

Just a thought on this comment...

> > If the goal is to create swingx-stable-1.0.jar,
> then
> > let that be a build function. Though I'm no ant
> > expert, I'd suppose it wouldn't be hugely
> difficult
> > to copy only certain classes into a jar.
>
> This is the basic idea I'm advocating. Its just that
> instead of maintaining a huge list of classes in the
> build file I'm using directory structure as the
> separator.

Then you should seriously consider branching at this point. Keep all the RC files in the HEAD, and then push all the DEV into a new branch. Then, get your HEAD stabalized for your 1.0 release.

Procedure would be: a) branch now (in essence, copies all existing code into new branch). b) delete DEV/Unstable classes out of HEAD. c) Get HEAD ready for 1.0 release. d) When 1.0 is ready, you'll have to merge all the changes back into the DEV branch to keep it current, but that's not too hard.

With branching, you won't even have any build.xml wizardry, since the HEAD branch would not even include the DEV unstable classes. And, of course, you don't have to literally move the source code around.

> If we can't find a good way to move files without
> losing revision history, then we'll probably have to
> maintain a huge list of files in the build file,
> denoting which is RC and which is still DEV.

You shouldn't lose history if you decide to move source (under your current plan). It'll just be a bit harder to get at (ie. in the Attic).

To Romain WRT 1.0 release: I hear you and agree. Having a stable API is critical. If by marking the stable code as "1.0" appeases the masses, then that's ok. But, again, this is a marketing function. It could as easily be marked "0.8.1.2.3" or "Some Cool Animal Name" or "Some Obscure African Country" as anything.

Cheers,

Adam

Kleopatra

Hi Richard,

+1 for the separation, if we can keep history - which is really really
really important.

-1 for several crucial details of the list (BTW, nice that you guys
at least informed me of your "decision").

There's a tension between the ideal to separate DEV-grade and RC-grade
components into distinct source trees and the real-world where RC-grade
components depend on DEV-grade parts. The latter is true for most of the
"rich" components (gadgets are less likely to be effected ;-). As the
RC-source tree must not depend on the DEV-source tree, there are two
options: a) move the RC-grade components into DEV as well, b) remove the
dependency.

a) wouldn't leave much in the 1.0 release
b) is lots of work (those changes must be newly tested!), surely will
introduce new bugs and in the end will leave crippled RCs

both lead to a release which is not worth the effort - for drama, of
course . The way out is to find the balance. That's work, it involves
- in no particular order and not independent from each other:

* for the components define the "X"-ness - what's at its heart to make
it worthwhile, compare design goals with what we actually have, see if
it's useful at all
* the same for each part of the infrastructure, with special attention
the dependencies from inside swingx
* define criteria to characterize "DEV"-state vs. "RC"-state
* decide how much DEV-ness we can/are willing to/must tolerate to not
cripple the release

What else to think about? How do we best organize that work? Which as a
side-effect probably will lead to a better documentation of what we want
to achieve ;-)

Cheers
Jeanette

PS: nearly forget - for the record an incomplete spontaneous list of my
vetos against
- dev status of JXList, JXTree, rollover infrastructure, search
infrastructure, parts of action which are used internally
- (not very hard, need to be convinced of their usefulness :-) rc status
of JXStatusBar, JXGraph, JXImagePanel

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

rbair
Offline
Joined: 2003-07-08

> There's a tension between the ideal to separate
> DEV-grade and RC-grade
> components into distinct source trees and the
> real-world where RC-grade
> components depend on DEV-grade parts.

Going over the list I see JXTable is listed RC -- it should be listed DEV until we get the details sorted out. We [b]will not ship[/b] a 1.0 release until JXTable and [b]all[/b] public API related to JXTable are finalized. The same goes for JXList. See below.

> a) wouldn't leave much in the 1.0 release

I want to point out, just to make sure we're all on the same page, that DEV does _not_ mean that it won't make it into a 1.0 release. It is simply a way of clearly defining which bits are done and which aren't. Clearly, JXTable and JXList API are not done. Hence, DEV.

Even for those that are listed RC, they will not be put back into the root src tree until after they have had a thorough code review. The RC tag is more stating that the API is stable and ready for said review. We may have mistagged a few things, we'll see as we review them.

The core point is that in order to have a stable codebase that people can rely on we have to review, document, test, and finish the components in our core tree.

> PS: nearly forget - for the record an incomplete
> spontaneous list of my
> vetos against
> - dev status of JXList, JXTree, rollover
> infrastructure, search
> infrastructure, parts of action which are used
> internally

noted

dmouse
Offline
Joined: 2003-06-09

> org.jdesktop.swingx.calendar: RC (pending Josh O's
> approval)
> move JXMonthView to swingx package
> move resources to plaf packages

Most definitely. Who has access to log into the CVS server and move these so we don't lose revision history?

Josh

rbair
Offline
Joined: 2003-07-08

> Most definitely. Who has access to log into the CVS
> server and move these so we don't lose revision
> history?

That's a good question: I didn't even know this was an option with CVS. Do you know if this is possible with CVS? I can ask Roger Brinkley if he knows who inside java.net has the rights...

Richard

Romain Guy

Roger should have the rights I think.

jdnc-interest@javadesktop.org wrote:
>> Most definitely. Who has access to log into the CVS
>> server and move these so we don't lose revision
>> history?
>
> That's a good question: I didn't even know this was an option with CVS. Do you know if this is possible with CVS? I can ask Roger Brinkley if he knows who inside java.net has the rights...
>
> Richard
> [Message sent by forum member 'rbair' (rbair)]
>
> http://forums.java.net/jive/thread.jspa?messageID=133683
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Romain GUY
http://jroller.com/page/gfx
http://weblogs.java.net/blog/gfx/
http://www.progx.org
http://www.jext.org

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

rbair
Offline
Joined: 2003-07-08

I've started the wiki page to keep track of the reviews in progress. It can be found here http://wiki.java.net/bin/view/Javadesktop/SwingLabsAPIReview.

Bookmark it!

I'll be posting the JXPanel, JXErrorDialog, etc review documents over the next few days, as I complete them. Material will be posted [i]prior[/i] to the internal reviews as well, so you can see what is going on.

Cheers
Richard

rbair
Offline
Joined: 2003-07-08

Hey Antonio,

I was planning on bringing this topic up next week, but since you asked it, here it is.

One of the issues we've had with SwingX is to define which components are finished (where finished means 1.0 quality), which are a work in progress, and which are experimental. Arguably we should have done this when we split JDNC up and created SwingX. Also, as much as we'd liek to continue adding new features forever it's time to get a 1.0 release out the door (timeframe not yet determined) so that developers have a stable base to work on. To that end, Romain and Josh and I have drafted a plan we want to discuss which will give us a beta release quickly, but will require some CVS changes.

Since our goal is to have a stable base for other developers to build upon we have decided to move components which aren't ready for 1.0 to a different source tree within the SwingX project.

* move all classes from src to src-dev
* move the components chosen for RC back into src (along with support classes)
* test all RC components extensively
* finish all javadocs and update the website docs

I want to stress that we aren't dumping the components which aren't marked as ready for 1.0. In fact, by providing a separate source tree within the project, we ensure that we can still build and provide swingx.jar files that are identical to the current jar. We'd also provide a swingx-stable.jar which would contain only the stable code.

What we are saying is that we can't guarantee that the API for components in src-dev won't change in the future. We also don't want unstable components to hold back the release of the stable components. By having two trees there will be a clear distinction between which components are stable and which aren't, making conditional builds easier.

Below is a list of each component, whether it will be in the main source tree src (also known as release candidate tree RC) or in development(DEV) and any package changes that will happen at the same time. After a couple of days of discussion I'll warn everyone to commit their changes and then move things around.

Of course, I'm posting this as a form of dicussion. It is the opinion of myself, Josh and Romain that this will be the easiest and quickest way to get from here to a 1.0 release.

Richard

[pre]
JXCollapsiblePane: RC
ErrorReporter and IncidentInfo: RC, move to 'error' subpackage
JXDatePicker: RC
JXComboBox: deleted, has no current purpose
JXEditorPane: DEV
JXErrorDialog: RC
JXFindBar, FindPanel: DEV
JXFrame: DEV
JXGlassBox: DEV
JXGradientChooser: RC (still needs doc work and layout fixes)
JXGraph: RC (needs minor cleanups and a future feature list)
JXHeader: RC
JXHyperLink: RC, needs to be refactored to it can stand alone.
JXImagePanel: RC, Josh M is actively working on this one
JXList: DEV
JXLoginDialog: delete
JXLoginPanel: RC
JXMultiSplitPane: RC
JXMultiThumbSlider: RC, Josh M is actively working on this one
JXPanel: RC, (need to remove all gradient stuff, just use Painters now)
JXRadioGroup: DEV
JXRootPane: DEV
JXSearchPanel: DEV
JXStatusBar: RC (need to make layout code be private and check the plaf stuff)
JXTable: RC
JXTableHeader: RC
JXTaskPane, JXTaskPaneContainer: RC
JXTipOfTheDay: RC
JXTitledPanel, JXTitledSeparator: RC
JXTree, DEV
JXTreeTable: DEV
JavaBean: RC
LabelProperties: hide, remove from public API
LinkModel, LinkRenderer: DEV
MailErrorReporter: RC, move to 'error' package
MouseMessagingHandler: DEV
MultiSplitLayout: RC
PatternModel: DEV
RepaintManatgerX: RC, make package private, rename to RepaintManagerExt
RolloverController, RolloverProducer, RolloverRenderer: DEV
SearchFactory, Searchable: DEV
StackLayout: RC
TargetableSupport: DEV
TranslucentRepaintManager: RC, turn into an annotation
UIAction: RC, make package private
VerticalLayout: RC
modify package.html to only reference stuff that is RC

org.jdesktop.swingx.action:
AbstractActionExt: RC: make all props use map
all other classes in the 'action' package are DEV
org.jdesktop.swingx.auth: RC
needs a package.html
move resources to plaf packages
org.jdesktop.swingx.autocomplete: RC
org.jdesktop.swingx.border: RC
org.jdesktop.swingx.calendar: RC (pending Josh O's approval)
move JXMonthView to swingx package
move resources to plaf packages
org.jdesktop.swingx.color: RC
needs docs, package.html, and plaf packages
make support code be inner classes of JXGradientPicker
org.jdesktop.swingx.combobox: DEV
org.jdesktop.swingx.decorator: RC
org.jdesktop.swingx.event: DEV
org.jdesktop.swingx.Icon: RC
move ColumControlIcon and Sort arrow icon to plaf packages
org.jdesktop.swingx.multislider: RC
still needs significant refactoring by Josh M
org.jdesktop.swingx.painter: RC
org.jdesktop.swingx.plaf: RC
RC for all components which are RC
These implementations may change, however, and are
not considered public API!
org.jdesktop.swingx.resources: RC
org.jdesktop.swingx.table: RC
org.jdesktop.swingx.tips: RC
org.jdesktop.swingx.tree: DEV
org.jdesktop.swingx.treetable: DEV
org.jdesktop.swingx.util:
AccumlativeRunnable, SwingWorker, SwingPropertyChangeSupport:
these classes should be in a separate SwingWorker.jar that we
co-bundle
JVM & OS: RC
MailTransport: move to error package
PaintUtils: RC (make sure all methods are actually used,
and doc'ed)
UIManagerUtil: RC (make sure we still need it)
Resize: RC
WindowUtils: RC
[/pre

Romain Guy

+462

jdnc-interest@javadesktop.org wrote:
> Hey Antonio,
>
> I was planning on bringing this topic up next week, but since you asked it, here it is.
>
> One of the issues we've had with SwingX is to define which components are finished (where finished means 1.0 quality), which are a work in progress, and which are experimental. Arguably we should have done this when we split JDNC up and created SwingX. Also, as much as we'd liek to continue adding new features forever it's time to get a 1.0 release out the door (timeframe not yet determined) so that developers have a stable base to work on. To that end, Romain and Josh and I have drafted a plan we want to discuss which will give us a beta release quickly, but will require some CVS changes.
>
> Since our goal is to have a stable base for other developers to build upon we have decided to move components which aren't ready for 1.0 to a different source tree within the SwingX project.
>
> * move all classes from src to src-dev
> * move the components chosen for RC back into src (along with support classes)
> * test all RC components extensively
> * finish all javadocs and update the website docs
>
> I want to stress that we aren't dumping the components which aren't marked as ready for 1.0. In fact, by providing a separate source tree within the project, we ensure that we can still build and provide swingx.jar files that are identical to the current jar. We'd also provide a swingx-stable.jar which would contain only the stable code.
>
> What we are saying is that we can't guarantee that the API for components in src-dev won't change in the future. We also don't want unstable components to hold back the release of the stable components. By having two trees there will be a clear distinction between which components are stable and which aren't, making conditional builds easier.
>
> Below is a list of each component, whether it will be in the main source tree src (also known as release candidate tree RC) or in development(DEV) and any package changes that will happen at the same time. After a couple of days of discussion I'll warn everyone to commit their changes and then move things around.
>
> Of course, I'm posting this as a form of dicussion. It is the opinion of myself, Josh and Romain that this will be the easiest and quickest way to get from here to a 1.0 release.
>
> Richard
>
> [pre]
> JXCollapsiblePane: RC
> ErrorReporter and IncidentInfo: RC, move to 'error' subpackage
> JXDatePicker: RC
> JXComboBox: deleted, has no current purpose
> JXEditorPane: DEV
> JXErrorDialog: RC
> JXFindBar, FindPanel: DEV
> JXFrame: DEV
> JXGlassBox: DEV
> JXGradientChooser: RC (still needs doc work and layout fixes)
> JXGraph: RC (needs minor cleanups and a future feature list)
> JXHeader: RC
> JXHyperLink: RC, needs to be refactored to it can stand alone.
> JXImagePanel: RC, Josh M is actively working on this one
> JXList: DEV
> JXLoginDialog: delete
> JXLoginPanel: RC
> JXMultiSplitPane: RC
> JXMultiThumbSlider: RC, Josh M is actively working on this one
> JXPanel: RC, (need to remove all gradient stuff, just use Painters now)
> JXRadioGroup: DEV
> JXRootPane: DEV
> JXSearchPanel: DEV
> JXStatusBar: RC (need to make layout code be private and check the plaf stuff)
> JXTable: RC
> JXTableHeader: RC
> JXTaskPane, JXTaskPaneContainer: RC
> JXTipOfTheDay: RC
> JXTitledPanel, JXTitledSeparator: RC
> JXTree, DEV
> JXTreeTable: DEV
> JavaBean: RC
> LabelProperties: hide, remove from public API
> LinkModel, LinkRenderer: DEV
> MailErrorReporter: RC, move to 'error' package
> MouseMessagingHandler: DEV
> MultiSplitLayout: RC
> PatternModel: DEV
> RepaintManatgerX: RC, make package private, rename to RepaintManagerExt
> RolloverController, RolloverProducer, RolloverRenderer: DEV
> SearchFactory, Searchable: DEV
> StackLayout: RC
> TargetableSupport: DEV
> TranslucentRepaintManager: RC, turn into an annotation
> UIAction: RC, make package private
> VerticalLayout: RC
> modify package.html to only reference stuff that is RC
>
> org.jdesktop.swingx.action:
> AbstractActionExt: RC: make all props use map
> all other classes in the 'action' package are DEV
> org.jdesktop.swingx.auth: RC
> needs a package.html
> move resources to plaf packages
> org.jdesktop.swingx.autocomplete: RC
> org.jdesktop.swingx.border: RC
> org.jdesktop.swingx.calendar: RC (pending Josh O's approval)
> move JXMonthView to swingx package
> move resources to plaf packages
> org.jdesktop.swingx.color: RC
> needs docs, package.html, and plaf packages
> make support code be inner classes of JXGradientPicker
> org.jdesktop.swingx.combobox: DEV
> org.jdesktop.swingx.decorator: RC
> org.jdesktop.swingx.event: DEV
> org.jdesktop.swingx.Icon: RC
> move ColumControlIcon and Sort arrow icon to plaf packages
> org.jdesktop.swingx.multislider: RC
> still needs significant refactoring by Josh M
> org.jdesktop.swingx.painter: RC
> org.jdesktop.swingx.plaf: RC
> RC for all components which are RC
> These implementations may change, however, and are
> not considered public API!
> org.jdesktop.swingx.resources: RC
> org.jdesktop.swingx.table: RC
> org.jdesktop.swingx.tips: RC
> org.jdesktop.swingx.tree: DEV
> org.jdesktop.swingx.treetable: DEV
> org.jdesktop.swingx.util:
> AccumlativeRunnable, SwingWorker, SwingPropertyChangeSupport:
> these classes should be in a separate SwingWorker.jar that we
> co-bundle
> JVM & OS: RC
> MailTransport: move to error package
> PaintUtils: RC (make sure all methods are actually used,
> and doc'ed)
> UIManagerUtil: RC (make sure we still need it)
> Resize: RC
> WindowUtils: RC
> [/pre
> [Message sent by forum member 'rbair' (rbair)]
>
> http://forums.java.net/jive/thread.jspa?messageID=133611
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Romain GUY
http://jroller.com/page/gfx
http://weblogs.java.net/blog/gfx/
http://www.progx.org
http://www.jext.org

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