Skip to main content

When SwingX and other JDNC will be part of JDK

43 replies [Last post]
Anonymous

Hi,

Are there any plans for SwingX and the other JDNC projects to be
included as part in JDK ? If Yes, when and in which JDK version?

Regards,
Miro.
[miro.vcf]
---------------------------------------------------------------------
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

Noel, Patrick,

admit it - you read my mind

Cheers
Jeanette

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

Patrick Wright

> admit it - you read my mind

Great minds live in Berlin :)

Patrick

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

Thanks for your input. We have a meeting tomorrow to discuss this feedback. Especially with the JDK becoming open source, how and in what manner things are done between SwingLabs and Swing need to be worked out again. I suspect there are some solutions less drastic than punting on reviews entirely for the release, but we'll see and consider all the options presented.

Richard

kleopatra
Offline
Joined: 2003-06-11

Just to move this thread on center stage again :-)

> Thanks for your input. We have a meeting tomorrow to
> discuss this feedback. Especially with the JDK
> becoming open source, how and in what manner things
> are done between SwingLabs and Swing need to be
> worked out again.

and the outcome waaas...?

Thanks
Jeanette

rbair
Offline
Joined: 2003-07-08

> Just to move this thread on center stage again :-)
>
> > Thanks for your input. We have a meeting tomorrow
> to
> > discuss this feedback. Especially with the JDK
> > becoming open source, how and in what manner
> things
> > are done between SwingLabs and Swing need to be
> > worked out again.
>
> and the outcome waaas...?

Yet another meeting!

mario_cesar
Offline
Joined: 2006-11-30

And I'm just waiting to know the results of that meeting. :)

Regards,
Mario Cesar

sumitkishore
Offline
Joined: 2003-06-10

Given historical evidence, there's not that much movement in the SwingLabs -> JDK direction, so laying the SL plan hostage to that possibility is not very productive. SL's scope too has grown. I'd prefer if you dissociated SL a bit more from JDK inclusion, if that helped release it earlier. I'm prefectly okay with bundling an extra jar for GUI goodies.

rbair
Offline
Joined: 2003-07-08

> Given historical evidence, there's not that much
> movement in the SwingLabs -> JDK direction, so laying
> the SL plan hostage to that possibility is not very
> productive. SL's scope too has grown. I'd prefer if
> you dissociated SL a bit more from JDK inclusion, if
> that helped release it earlier. I'm prefectly okay
> with bundling an extra jar for GUI goodies.

I understand what you are asking for Sumit. Just for clarity, though, the reason there wasn't a lot of SwingX stuff added to Java 6 has to do with timing. The way we usually work is to spec out what is going into the next release of Java months before the workspace is actually opened. We first brainstorm in several Swing meetings. We then pick our top few features. These get passed higher up the chain where a planning committee finalizes which high level features are going to be included in the release.

I wasn't there for the 1.6 planning meeting, but I suspect they looked at what JDNC had at the time (filtering, sorting, highlighting) and went with it. I know we are planning for JXDatePicker and JXTreeTable (after a much needed refactoring) to be in Java 7.

This is why the review process is so important. A reviewed component has a much greater chance of making it into the JDK.

That said, I wouldn't suggest everything go into the JDK, reviewed or not. I'd rather that the most widely useful components (such as a tree table or date picker) went in, and other more specific components (such as JXGraph) be available as an additional jar.

Richard

Joshua Marinacci

I believe that other large open source projects like Apache have
something similar to the JCA. It ensures that Apache has the freedom
to change the license and add/remove code without needing to contact
all of the original contributors (which could be *huge*).

- Josh

On Nov 22, 2006, at 11:43 AM, jdnc-interest@javadesktop.org wrote:

> "What is preventing you or any other participant here from helping
> out in this regard? The SwingLabs projects require you sign the JCA
> to contribute, and accept the project license when submitting code.
> That allows any of us to submit bug fixes, patches, improvements,
> documentation, demos, what have you."
>
> Perhaps the JCA is unavoidable, but it's not a very common model.
> It limits participation.
> [Message sent by forum member 'coxcu' (coxcu)]
>
> http://forums.java.net/jive/thread.jspa?messageID=177961
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

- Blasting forth in three part harmony!

[att1.html]

coxcu
Offline
Joined: 2003-06-11

Why not have a click-through license to join the project?

Most open-source projects start with the philosophy that it is easier to obtain forgiveness than permission. If and when they get to the point of needing to limit participation, they adjust accordingly.

The JCA says:

"1. You own, and have sufficient rights to contribute, all past, present and future source code and related material which You deliver to the Project ("Contribution"), and which have been accepted by Sun.
2. You hereby assign to Sun joint ownership in all worldwide common law and statutory rights associated with the copyrights, copyright application, copyright registration and moral rights in Your Contribution to the extent allowable under applicable local laws and copyright conventions.
You agree that this assignment may be submitted by Sun to register a copyright in the Contribution. Except for the rights granted herein, You retain all right, title and interest in and to Your Contributions and may use the Contribution for Your own purposes. This Assignment
supersedes and replaces all prior copyright assignments made by You to Sun for this Project.
Neither party has any duty whatsoever to render an accounting to the other party for any use of
the Contribution.
3. You represent that You are legally entitled to grant the above assignment. If Your employer(s) have rights to intellectual property that You create, You represent that You have received permission to make the Contribution on behalf of that employer, or that Your employer has
waived such rights for Your Contributions."

The idea is that if somebody signs that then it is true. I'm not sure how many problems it really solves. If somebody later decides that they own some Swing Labs code, the fact that it came through a JCA isn't going to make a lot of difference.

It may be required to get Sun legal to sign off on things, so that Sun employees can get paid to work on it. It may be the best way of doing things, but it is not the only way.

Patrick Wright

> It may be required to get Sun legal to sign off on things, so that Sun employees can get paid to work on it. It may be the best way of doing things, but it is not the only way.
> [Message sent by forum member 'coxcu' (coxcu)]

You can try and search the mail/forum archives on the topic. As I
recall, it's required and not an open topic at this point. I believe
for the newly GPL'd components something similar is required.

Patrick

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

coxcu
Offline
Joined: 2003-06-11

"What is preventing you or any other participant here from helping out in this regard? The SwingLabs projects require you sign the JCA to contribute, and accept the project license when submitting code. That allows any of us to submit bug fixes, patches, improvements, documentation, demos, what have you."

Perhaps the JCA is unavoidable, but it's not a very common model. It limits participation.

kirillcool
Offline
Joined: 2004-11-17

> Perhaps the JCA is unavoidable, but it's not a very
> common model. It limits participation.

I understand the need for JCA, since the original intent was to move the code from this project to JDK. But looking back, how much of that has happened to SwingLabs (and i'm not talking about the original JDNC code such as Desktop and TrayIcon). The only thing i can name is various sort stuff for tables (correct me if i'm wrong), and that was added to the existing components. Just imagine the impact Mustang could have with all the JX* components in it. And it's not like there wasn't enough time to put it there. Now it seems (like Patrick says) that the core effort has been sidelined by the more shiny stuff (like painters and animations), which is completely understandable (hey, we all love shiny stuff). The problem is that without a rigorous planned release schedule people don't have any real incentive to work on the core components. I can only speak from my own open-source experience, but i find that having a 10-week release schedule puts quite a pressure on me. It's hard to justify the release to have only bug fixes, so i [b]have[/b] to continue adding new features with each release. And, since it's a short release cycle, this requires me to put some creative thought into finding these new features (otherwise it couldn't be called a release). Then, when the cutoff date comes, all the rest gets postponed to the next release, but with each new release i have a lot to show. Anyway, my 2 cents.

Patrick Wright

> I understand the need for JCA, since the original intent was to move the code from this project to JDK. But looking back, how much of that has happened to SwingLabs (and i'm not talking about the original JDNC code such as Desktop and TrayIcon). The only thing i can name is various sort stuff for tables (correct me if i'm wrong), and that was added to the existing components. Just imagine the impact Mustang could have with all the JX* components in it. And it's not like there wasn't enough time to put it there. Now it seems (like Patrick says) that the core effort has been sidelined by the more shiny stuff (like painters and animations), which is completely understandable (hey, we all love shiny stuff). The problem is that without a rigorous planned release

Hmm. Tricky. The word on the street :) was always that the "Swing
Team" (shifty, in-the-shadows, seldom-seen, suspicious political
leanings) "might" "decide" "at some point" to include "some, all or
none" of what came out of SwingLabs. They do have a much harder
problem of trying to fit any of it in to the JDK without breaking
compatibility or making Swing still more complicated.

That said, there is also a bit of a built-in (read: structural)
problem here, in that, in order for the components to be "worthy" of
being in the main branch, and "worthier" yet of being "release
quality" there's a review period required. For *each* component, some
sucker has to clean up the JavaDoc, figure out what the hell the
component was supposed to do, figure out how to spin it to make it
look worthwhile, then drag the little lamb out in front of the "Swing
Team", who, once located somewhere in the south of France, tending to
their wine, cheese, and sheep, will engage themselves, their only job
in this context (it seems) is to spit on such proposals, laugh
mightily, and order another draft (so to speak).

In other words, there's this sort of high bar set for release-quality
SwingX components, and it adds a rather expensive, time-consuming
layer to the process of getting a 1.0 release out. That's
understandable for a number of reasons, but it also makes the process
much, much slower than it should be. Add to that that since JDNC was
originally released, the number of SwingX components in HEAD has
grown, not shrunk, and we can see the size of the problem.

It would be nice if we could speed this up, but I'm not sure how. As
we all witnessed in the last few months, just getting a status bar
through the gauntlet was an unexpected amount of effort. I imagine
Richard is not sleeping at night, imagining exactly what circle of
hell it will be like to walk the JXTreeTable up to the altar.

If anyone has ideas about how to speed that process up while still
maintaining quality and involvement, seems to me would be ideal.

That said, there have certainly been some false starts and mistakes
made along the way.

Patrick
Sorry about the ". (remember that "Sun" is the ' in '' :)

---------------------------------------------------------------------
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 imagine
> Richard is not sleeping at night, imagining exactly
> what circle of
> hell it will be like to walk the JXTreeTable up to
> the altar.

LOL. You got that right!

rbair
Offline
Joined: 2003-07-08

[Kirill]
> That pretty much sums up two of the biggest problems
> with SwingX right now: unstable APIs and insufficient
> documentation.

[Noel]
> But SwingX is not acting like a real open-source project.
> A real open-source project has release versions and development versions.
> This is important so that we generate stable, reliable components for
> people to program against, while we push forward with improvements.

> But when it takes 6 months and some public whinging to even get a
> response on a bug (when I included a fully commented patch)......

> You ask what keeps the community away from contributing. It's exactly
> the lack of a definite release plan and a roadmap, this lack of coherence,
> that keeps people away. You gain contributors by having happy
> consumers first.

These are all fair criticisms. I agree!

[Noel]
>> If Sun does not have resources to do this, perhaps it should consider
>> letting some members of the community help out in this regard?

[Patrick]
> What is preventing you or any other participant here from helping out
> in this regard? The SwingLabs projects require you sign the JCA to
> contribute, and accept the project license when submitting code. That
> allows any of us to submit bug fixes, patches, improvements,
> documentation, demos, what have you. Doing any or all of those would
> take pressure off of Richard, for example, who can work on internal
> infrastructure of releases. And without signing the JCA you can still
> send in patches, or work on the Wiki, for example.

Thanks Patick, that's right on.

Kirill's critique was regarding "unstable APIs and insufficient documentation". We are addressing the problem of unstable APIs by using a rigorous, documented API review process that includes both internal reviews with the Swing team and external reviews by the community.

Insufficient documentation: this is an area where participation would be the most helpful. I've documented (http://forums.java.net/jive/thread.jspa?forumID=73&threadID=19489) how to help contribute to the website.

A couple days ago I updated the website with more (hopefully better) descriptions of the various sub projects, contributors, and links to lots of documentation and blogs (on the docs page).

If you have patches for the website, submit them, and we'll get the website updated! I could *really* use some screenshots, as the screenshots page right now is broken. If somebody would like to write the HTML/JSP for the screenshots page, that would rock too.

If you're more into API design, we've put out the call before for contributors who'd like to champion a component (or framework) through the review process. It's a lot of work, but the only way I know of for having stable APIs.

And there are of course opportunities for bug fixes, demos, test cases, and all the rest. And if you love ant or have a lot of experience in build processes, I've got work for you.

For JavaPolis I'm in the middle of writing slides that describe the contribution process in detail, and I was planning on putting the same content on the website for reference.

Thanks for the interest and passion.

Richard

rbair
Offline
Joined: 2003-07-08

> For JavaPolis I'm in the middle of writing slides
> that describe the contribution process in detail, and
> I was planning on putting the same content on the
> website for reference.

Here's the first draft:

https://swinglabs.dev.java.net/source/browse/swinglabs/website/web/docs/...

I'll be able to update the website on Monday (after the Thanksgiving holiday here in the US). There are a couple items I haven't finished yet on this list. If you can think of any additions, changes, links, etc please let me know.

Richard

kirillcool
Offline
Joined: 2004-11-17

That pretty much sums up two of the biggest problems with SwingX right now: unstable APIs and insufficient documentation. I'm not saying that having too many cooks is the problem here, but it doesn't help. The release schedule is non-existing (except "any time soon", of course), constant refactorings break demoes and applications and 1.0 is nowhere in sight.

All this, of course, doesn't really bother me personally (and are not intended to be attack on anybody personally or on the project in general), and i have no problems with all of the above, but if Sun is serious with its commitment to this project, it needs to throw a little more resources at it. The "we're still working on the best API that we can get at and until then we don't feel that we can release it" is too old now to be a valid reason. Is it perpetually stuck in the beta? This may work for web applications (gmail and friends) that don't expose anything besides HTML, but for a serious project like this...

Noel Grandin

Hi

I second this. I'm using swingx in one current production project, but
to be honest, I won't do it again.

I think SwingX has a lot of promise - I was really hoping it would grow
into a central place where people could develop swing components for
re-use, instead of having various small unmaintained components
scattered around dozens of mailing lists and websites.

But SwingX is not acting like a real open-source project.
A real open-source project has release versions and development versions.
This is important so that we generate stable, reliable components for
people to program against, while we push forward with improvements.

If Sun does not have resources to do this, perhaps it should consider
letting some members of the community help out in this regard?

Regards,
Noel Grandin.

jdnc-interest@javadesktop.org wrote:
> That pretty much sums up two of the biggest problems with SwingX right now: unstable APIs and insufficient documentation. I'm not saying that having too many cooks is the problem here, but it doesn't help. The release schedule is non-existing (except "any time soon", of course), constant refactorings break demoes and applications and 1.0 is nowhere in sight.
>
> All this, of course, doesn't really bother me personally (and are not intended to be attack on anybody personally or on the project in general), and i have no problems with all of the above, but if Sun is serious with its commitment to this project, it needs to throw a little more resources at it. The "we're still working on the best API that we can get at and until then we don't feel that we can release it" is too old now to be a valid reason. Is it perpetually stuck in the beta? This may work for web applications (gmail and friends) that don't expose anything besides HTML, but for a serious project like this...
> [Message sent by forum member 'kirillcool' (kirillcool)]
>
> http://forums.java.net/jive/thread.jspa?messageID=177436
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
>

NOTICE: This email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html

If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com

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

Patrick Wright

Hi

(note: I don't work for Sun and never have)

> I think SwingX has a lot of promise - I was really hoping it would grow
> into a central place where people could develop swing components for
> re-use, instead of having various small unmaintained components
> scattered around dozens of mailing lists and websites.

Agreed!

> But SwingX is not acting like a real open-source project.
> A real open-source project has release versions and development versions.
> This is important so that we generate stable, reliable components for
> people to program against, while we push forward with improvements.

Agreed as well.

> If Sun does not have resources to do this, perhaps it should consider
> letting some members of the community help out in this regard?

What is preventing you or any other participant here from helping out
in this regard? The SwingLabs projects require you sign the JCA to
contribute, and accept the project license when submitting code. That
allows any of us to submit bug fixes, patches, improvements,
documentation, demos, what have you. Doing any or all of those would
take pressure off of Richard, for example, who can work on internal
infrastructure of releases. And without signing the JCA you can still
send in patches, or work on the Wiki, for example.

We can't expect that many externals will be given remote access to
setup/work with the servers that will host release code or the
website. But Richard has already set it up that we can contribute
documentation, we all have access to the build files (so can help with
the improving build process)--I don't see what the issue is here.

I personally don't expect Sun Microsystems to throw more money at this
project, given the (large) number of pots they already have on the
stove (it's a pretty huge stack they are already throwing resources
at). The only mistake in retrospect IMO is that too much was released
into one bucket ("SwingLabs") without either a standard release
process and without waiting for a solid community development model to
develop. But just as a reminder--apart from dedicating staff resources
to this project *during* the development of Java 6 and the
open-sourcing of Java, Sun originally committed several people to
JDNC, which started this effort off and which was a pretty impressive
toolkit.

Honestly, I think the "community" needs to just start joining in and
helping out and stop complaining as much. And since I say it so
bluntly, in case you are wondering, in the past couple of years,
non-code contributions from me include JavaDoc for SwingX and
databinding components, Wiki writing, fixing references for the (now
defunct) Markup subproject. So, when I had time, I followed my own
advice. It's possible to help out in small ways, but we all have to do
it. Small contributions help out.

Most non-software community projects I've seen or participated in end
up with a "key players burn out" model, where everyone is enthusiastic
about the idea of community but only a few key players actually do
most of the work, and they burn out. Our model has to be more like
Amish barn-raising (at least the way ABR looks in the movies), and
that means everyone tries to do their own little bit.

So, don't mean to be rude to anyone in particular, but honestly, this
is all *our* own project. Of course, all of us who aren't paid to work
on this have other tasks. The next time I get time to work on
something other than work (or posting to mailing lists) I have Flying
Saucer, then databuffer to work on. At least DB is ostensibly still
part of SWL :). What I do know is that I, among other non-Sunners on
the list, have contributed and that if *you* dear reader, do as well,
these projects will be a great resource for Java developers.

Cheers
Patrick

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

Noel Grandin

Hi

And people like me have been contributing patches and code improvements.
Even to the extent of fixing things that don't impact me in any way
whatsoever.

But when it takes 6 months and some public whinging to even get a
response on a bug (when I included a fully commented patch)......

Now that doesn't mean I don't like and/or respect the people involved.
Richard/Jeanette/et. al. are doing a fantastic job, and I applaud Sun
for taking this step.

But if this project is regarded by Sun as purely a beta-test zone for
next-gen Swing stuff and a playground for other Swing developers, then
it's utility is severely diminished.

And unfortunately, this is an area where people like me CANNOT help.
Creating stable branches and release points is a process that requires
the leaders of the project to make a choice and create the necessary CVS
branches.

I would be happy to help out with backporting fixes to a stable branch
and testing builds - but what do I backport to? Where is the stable
branch? Where is some sign of release management?

Regards,
Noel Grandin

Patrick Wright wrote:
> Hi
>
> (note: I don't work for Sun and never have)
>
>> I think SwingX has a lot of promise - I was really hoping it would grow
>> into a central place where people could develop swing components for
>> re-use, instead of having various small unmaintained components
>> scattered around dozens of mailing lists and websites.
>
> Agreed!
>
>> But SwingX is not acting like a real open-source project.
>> A real open-source project has release versions and development
>> versions.
>> This is important so that we generate stable, reliable components for
>> people to program against, while we push forward with improvements.
>
> Agreed as well.
>
>> If Sun does not have resources to do this, perhaps it should consider
>> letting some members of the community help out in this regard?
>
> What is preventing you or any other participant here from helping out
> in this regard? The SwingLabs projects require you sign the JCA to
> contribute, and accept the project license when submitting code. That
> allows any of us to submit bug fixes, patches, improvements,
> documentation, demos, what have you. Doing any or all of those would
> take pressure off of Richard, for example, who can work on internal
> infrastructure of releases. And without signing the JCA you can still
> send in patches, or work on the Wiki, for example.
>
> We can't expect that many externals will be given remote access to
> setup/work with the servers that will host release code or the
> website. But Richard has already set it up that we can contribute
> documentation, we all have access to the build files (so can help with
> the improving build process)--I don't see what the issue is here.
>
> I personally don't expect Sun Microsystems to throw more money at this
> project, given the (large) number of pots they already have on the
> stove (it's a pretty huge stack they are already throwing resources
> at). The only mistake in retrospect IMO is that too much was released
> into one bucket ("SwingLabs") without either a standard release
> process and without waiting for a solid community development model to
> develop. But just as a reminder--apart from dedicating staff resources
> to this project *during* the development of Java 6 and the
> open-sourcing of Java, Sun originally committed several people to
> JDNC, which started this effort off and which was a pretty impressive
> toolkit.
>
> Honestly, I think the "community" needs to just start joining in and
> helping out and stop complaining as much. And since I say it so
> bluntly, in case you are wondering, in the past couple of years,
> non-code contributions from me include JavaDoc for SwingX and
> databinding components, Wiki writing, fixing references for the (now
> defunct) Markup subproject. So, when I had time, I followed my own
> advice. It's possible to help out in small ways, but we all have to do
> it. Small contributions help out.
>
> Most non-software community projects I've seen or participated in end
> up with a "key players burn out" model, where everyone is enthusiastic
> about the idea of community but only a few key players actually do
> most of the work, and they burn out. Our model has to be more like
> Amish barn-raising (at least the way ABR looks in the movies), and
> that means everyone tries to do their own little bit.
>
> So, don't mean to be rude to anyone in particular, but honestly, this
> is all *our* own project. Of course, all of us who aren't paid to work
> on this have other tasks. The next time I get time to work on
> something other than work (or posting to mailing lists) I have Flying
> Saucer, then databuffer to work on. At least DB is ostensibly still
> part of SWL :). What I do know is that I, among other non-Sunners on
> the list, have contributed and that if *you* dear reader, do as well,
> these projects will be a great resource for Java developers.
>
>
> Cheers
> Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>

NOTICE: This email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html

If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com

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

Patrick Wright

Hi

I agree it's frustrating! And I also realize you are among those who
have contributed, both in code/patches, and in discussions.

I'm trying to look at this creatively. There are some tasks that are
natural for, say, Richard, like leading a review of components (both
with the Swing team and with members of SWL). There are some tasks
which I'd rather have him, Jeanette or other specialists spend time on
(complexities of components' internals). In the last few months, I
know both Richard and Jeanette have worked on website, documentation,
JavaDoc--can't we find some way to help out with that? How can we each
other focus on the tasks to which they are best suited so that we get
stable releases?

Every time Richard, say, has to crawl through the same questions in
the mailing lists, he's not spending time reviewing code, patches,
etc. Many of the questions that pop up just need to be in a FAQ. So,
let's find some people in the community who will maintain a FAQ and
point people to it when appropriate.

Ditto for JavaDoc, demos, sample code. All of these are things we can
help out with, doesn't take much time, and would let everybody do the
task they are best at or assigned to do.

That's a more positive way of stating what I said before.
Patrick

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

sumitkishore
Offline
Joined: 2003-06-10

Patrick, you're so very wrong. You ask what keeps the community away from contributing. It's exactly the lack of a definite release plan and a roadmap, this lack of coherence, that keeps people away. You gain contributors by having happy consumers first.

It's been, what, 2.5 years now since JDNC was announced at a JavaOne. In the years since, the JDNC intiative and the XML layout have been taken out of scope and don't seem to be returning anytime. There's no release and no fixed plans. Beyond table sorting, there's little evidence of what and how do things move between SwingLabs and JDK. Being picked up for a JCP moves a project into a black hole. SwingLabs has essentially become a hobbyist hangout.

I would see the same attitude on the NetBeans forums in 4.X days. The standard retort to any complaint was why don't you contribute, and we as power users are happy with the way things are in NetBeans. It took an acknowledgement of the market slipping away and focussed work on the core team's part to turn things around (a bit). Contributors will contribute, but the core team has to lead.

Patrick Wright

Hi Sumit

Right now there is a plan and map, and that involves reviewing each
and every SwingX component, finalizing and approving the API. That's
what's in-progress.

One problem right now is that
a) I believe only Richard is leading those reviews (he's asked others
to step forward, but no one has, to my knowledge)
b) Other SwingLabs tasks are taking up his time, when he actually finds time

People here can help with a) by picking up any of the components and
getting it ready for review. They can help with b) by taking some of
those tasks (website, builds, documentation, etc.) off of Richard's
plate.

JDNC is a the wrong thing to focus on. It simply wasn't a shippable
(e.g. 1.0, or near 1.0) toolkit. Since it was released as open-source,
binding was rewritten and then dropped in favor of a JSR, XML binding
attracted 0 interest and was found to be hard to maintain (I should
know, I got it to compile again at one point) and the whole JN
approach was found to lack clarity and focus. It had a whole lot of
great ideas and approaches, though, which is why we are still here.
Anyway, those problems have been addressed, but a lot of time went by
in the meantime.

What I would agree with, as a sort of implicit criticism, is that the
project needs to focus. I'm very excited by what I'm seeing in Painter
development, and in SwingX-WS, but these are distracting us from
getting anything shipped, e.g. they are delaying what is arguably the
core at the moment, SwingX. I can't tell others what to do with their
time, but I'd argue we need to re-focus on the core task, which is
getting the core shipped. No more playing around while at work!

I don't want to start (or continue) a fight with you, Sumit, or Noel,
or Kirill or whomever. I'm just trying to point out what seem to be
the real problems, which, in my view, are simply that there are too
many tasks for too few resources. While some tasks can be trimmed, we
need some more active help, and that means IMO community members, not
Sun. More community involvement is healthy, anyway, otherwise Sun
carries too much weight in these discussions.

Best regards
Patrick

btw--I didn't mention Jeanette, because (apart from the fact that she
lives in wonderful Berlin!) she is doing in my eyes an awesome job
tracking down bugs and fixing them.

On 11/22/06, jdnc-interest@javadesktop.org
wrote:
> Patrick, you're so very wrong. You ask what keeps the community away from contributing. It's exactly the lack of a definite release plan and a roadmap, this lack of coherence, that keeps people away. You gain contributors by having happy consumers first.
>
> It's been, what, 2.5 years now since JDNC was announced at a JavaOne. In the years since, the JDNC intiative and the XML layout have been taken out of scope and don't seem to be returning anytime. There's no release and no fixed plans. Beyond table sorting, there's little evidence of what and how do things move between SwingLabs and JDK. Being picked up for a JCP moves a project into a black hole. SwingLabs has essentially become a hobbyist hangout.
>
> I would see the same attitude on the NetBeans forums in 4.X days. The standard retort to any complaint was why don't you contribute, and we as power users are happy with the way things are in NetBeans. It took an acknowledgement of the market slipping away and focussed work on the core team's part to turn things around (a bit). Contributors will contribute, but the core team has to lead.
> [Message sent by forum member 'sumitkishore' (sumitkishore)]
>
> http://forums.java.net/jive/thread.jspa?messageID=177873
>
> ---------------------------------------------------------------------
> 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

Kleopatra

Patrick Wright wrote:
>
> btw--I didn't mention Jeanette, because (apart from the fact that she
> lives in wonderful Berlin!) she is doing in my eyes an awesome job
> tracking down bugs and fixing them.
>

sounds like - "oh, before I forget it - there's that gal who brews a
wonderful coffee" ;-) Which I do - compared to american style dark water

Cheers
Jeanette

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

Patrick Wright

> sounds like - "oh, before I forget it - there's that gal who brews a
> wonderful coffee" ;-) Which I do - compared to american style dark water

WAIT! You make *coffee*, too? Man.

Actually, no, Richard was the sacrificial lamb on this thread, hence I
didn't want to drag you in (no need to waste a lamb, as they say). :)

Patrick

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

coxcu
Offline
Joined: 2003-06-11

"Start by looking at the docs, source, or post on the forums."

That's not nearly adequate for something so visual. Demo applications and component galleries are needed. Just imagine how much effective the police would be if they used written descriptions instead of mug shots.

evickroy
Offline
Joined: 2004-07-23

> That's not nearly adequate for something so visual.
> Demo applications and component galleries are
> e needed. Just imagine how much effective the police
> would be if they used written descriptions instead of
> mug shots.

lol That's true. In the past, there have been extremely well done demos of the components. Unfortunately, some of them have been broken with the recent project restructuring. I believe there is a discussion on another thread to try and correct the problems with the demos. Also, the swinglabs.org website has some good info, but does need to be updated. Again, the big problem is available resources, so I'm sure any help will be welcome here.

Erik

Miroslav Nachev

I am busy, but I can try to help. Can you give a list with tasks to
determine what is suitable for me and the my time?

Miro.

jdnc-interest@javadesktop.org wrote:
>> That's not nearly adequate for something so visual.
>> Demo applications and component galleries are
>> e needed. Just imagine how much effective the police
>> would be if they used written descriptions instead of
>> mug shots.
>>
>
> lol That's true. In the past, there have been extremely well done demos of the components. Unfortunately, some of them have been broken with the recent project restructuring. I believe there is a discussion on another thread to try and correct the problems with the demos. Also, the swinglabs.org website has some good info, but does need to be updated. Again, the big problem is available resources, so I'm sure any help will be welcome here.
>
> Erik
> [Message sent by forum member 'evickroy' (evickroy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=177311
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
>
>

[att1.html]

Patrick Wright

Hi Miro

On 11/21/06, Miroslav Nachev wrote:
>
> I am busy, but I can try to help. Can you give a list with tasks to
> determine what is suitable for me and the my time?

Richard is the project lead, and he probably has a big list to hand
off, but here are a couple of ideas.

If you like coding, you could get the current demo (demos HEAD) to
compile and work against the SwingX HEAD, removing or putting to one
side things that don't work.

If you like coding a lot of little small things, you might scour the
demos package for things we could use in small web-startable demos,
then start posting those (with a link from one of our pages).

If you like writing, you could start documenting how to use any of the
components that interest you, on the Wiki. Just create one page per
component, link to it from the main Wiki, and write notes, code
samples, whatever you learn.

Most important is what interests *you*, maybe a particular type of
problem (painting, event handling) or a component (JXTable,
JXDatePicker). If you can figure that out, it will probably make the
effort more fun overall.

Others will have more feedback, I'm sure.

Thanks for the offer to help!
Patrick

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

Patrick Wright

> From the above I see that the Sun is owner of the JDNC source code.
> Also the license is GNU LGPL. The license of JDK6 is GPL also. So, I can
> not understand where is the problem JDNC to be included as part of JDK6 ?

Here's how I understand it. SwingLabs (including what used to be JDNC)
is an independent project led by members of the Swing team. While the
license is LGPL for SwingX (all SwingLabs is open-source, but under
varying licenses), by signing the JCA we contributors grant shared
copyright to Sun. That means that programmers at Sun can, if they
want, include parts of these libraries into the JDK--I'm not sure
under what conditions, but anyway, they can.

SwingLabs is not the JCP, though, so it's not an official process for
extending the JDK. Rather, it's a low-overhead way for us Java
programmers to participate, develop, and debug components which are of
general use. It's up to Sun if they decide to use/port/copy/merge any
parts of SwingLabs into the JDK. Just because a component exists here
doesn't mean it will ever be in the JDK. But it will still be
available.

Thus there is no "problem", it's just not what these projects are
intended for, as I understand it. By making inclusion into the JDK
optional, this lets the community play around with good components
which, for one reason or another, maybe don't belong in the standard
libraries.

Patrick

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

Kleopatra

Jumping in - at the top is as good as anywhere else :-)

I spent a couple of hours with carefully reading and thinking about this
thread, very interesting! To much of it boils down to one central question:

What's the goal/driving force of SwingLabs?

Looks like two main perspectives (paraphrasing):

- SwingLabs originally (and still today) is meant to be included
(partially at least) into jdk

pros:
* no duplication of effort
* clear project boundaries/constraints
* safety of investment for early adopters/contributors

- SwingLabs is the central location for the Swing community to work
_together_ on exploring/improving (new) ideas

pros:
* increased community control
* fast response times
* relaxed constraints as to backward compatibility, dependencies

It's not necessarily a one-or-other question (though my gut tells me
they are mutually exclusive to a large extent) but leaning more to the
one-or-other influences the priority of our action items.

What both do have in common is the need for a clearly visible and
bounded (the output should appear in the order of weeks to a small
number of months instead of "soon") release control. Though I'm not sure
if we can possibly throw out a 1.0 with enough weight in that time
frame ;-)

Currently, we have two boundary conditions for the content of such a
release:

- all contained classes must be reviewed
- must fulfil the release criteria as outline in our old release
strategy draft: http://wiki.java.net/bin/view/Javadesktop/ReleaseStrategy

The bottleneck seems to be the first (we have 5 classes meeting that
criterion). Which don't meet the second, being more or less untested and
relative new, that is neither real-world-tested by usage. And the other
way round - well-tested, widely used rich components which are not
reviewed (and only partly in the vicinity of review-ready - you might
have followed my agony to bring JXTable near

Hmm ... any ideas how to solve that dilemma?

As always at this time of the day - I need some food now -)
Jeanette

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

Noel Grandin

Hi

Excellent summary Jeanette.

The central problem here appears to be the "review" criteria, because
that seems to depend on access to resources outside of the project's
community.

I suggest that we decouple the release criteria from the reviewing
criteria. This whole review thing may well be appropriate for the JDK,
but is simply too high a bar for an open-source community project. The
whole point of being a community project is freedom to modify and change.

I suggest that that we allow components to go into a release before they
are reviewed.
The component will be maintained on that release branch in it's current
form.

Then, when a component has been reviewed, it can be changed on
trunk/HEAD/NextMajorRelease.

This is acceptable because it is understood in open-source projects that
things will change from major release to major release.

That way, we get the best of both worlds - Sun gets "reviewed"
components, and we get a release process that is manageable from within
the community, and operates within timeframes that we have some control
over.

Regards,
Noel Grandin

Kleopatra wrote:
>
> Jumping in - at the top is as good as anywhere else :-)
>
> I spent a couple of hours with carefully reading and thinking about
> this thread, very interesting! To much of it boils down to one central
> question:
>
> What's the goal/driving force of SwingLabs?
>
> Looks like two main perspectives (paraphrasing):
>
> - SwingLabs originally (and still today) is meant to be included
> (partially at least) into jdk
>
> pros:
> * no duplication of effort
> * clear project boundaries/constraints
> * safety of investment for early adopters/contributors
>
> - SwingLabs is the central location for the Swing community to work
> _together_ on exploring/improving (new) ideas
>
> pros:
> * increased community control
> * fast response times
> * relaxed constraints as to backward compatibility, dependencies
>
> It's not necessarily a one-or-other question (though my gut tells me
> they are mutually exclusive to a large extent) but leaning more to the
> one-or-other influences the priority of our action items.
>
> What both do have in common is the need for a clearly visible and
> bounded (the output should appear in the order of weeks to a small
> number of months instead of "soon") release control. Though I'm not
> sure if we can possibly throw out a 1.0 with enough weight in that
> time frame ;-)
>
> Currently, we have two boundary conditions for the content of such a
> release:
>
> - all contained classes must be reviewed
> - must fulfil the release criteria as outline in our old release
> strategy draft: http://wiki.java.net/bin/view/Javadesktop/ReleaseStrategy
>
> The bottleneck seems to be the first (we have 5 classes meeting that
> criterion). Which don't meet the second, being more or less untested
> and relative new, that is neither real-world-tested by usage. And the
> other way round - well-tested, widely used rich components which are
> not reviewed (and only partly in the vicinity of review-ready - you
> might have followed my agony to bring JXTable near
>
> Hmm ... any ideas how to solve that dilemma?
>
> As always at this time of the day - I need some food now -)
> Jeanette
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>

NOTICE: This email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html

If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com

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

Patrick Wright

Noel,


> I suggest that we decouple the release criteria from the reviewing
> criteria. This whole review thing may well be appropriate for the JDK,
> but is simply too high a bar for an open-source community project. The
> whole point of being a community project is freedom to modify and change.

After thinking about this and what's been discussed in the thread, I
tend to agree that something like this has to be done.

I think we have a situation where most of the decisions made and
principles we're following make sense individually, but as a whole
lead to an undesirable outcome: no release 1.0. Given the manpower
currently assigned or volunteering on the project(s), it seems
reasonable that a 1.0 release is a long way away.

I think we need some feedback from the Swing team leads (not sure who
this is, whether Hans, Shannon, Scott or ?) as to whether a compromise
is possible. Obviously we all want top-quality stuff in the JDK and in
Swing, and the Swing team are the people who decide what that
constitutes. They obviously have an interest in a thorough internal
review, discussion, planning, etc. That seems to me to be outside the
scope of the SwingLabs projects.

So let's start by saying that a full-point (1.0, 2.0) release of any
SwingLabs project does not imply in *any* way that the components
therein are accepted for Swing, or will be, or even that they will
influence what goes into Swing at some point in the future. How and
whether that merge happens is up to the Swing team, and takes place on
their own schedule.

At the same time we would say that SwingLabs has the freedom to
implement components in ways that would not be acceptable for
inclusion into the JDK. A great example is Thomas' famous
combobox/table, which I think everyone was very excited about when it
was released but which has languished in the incubator ever since. I
completely understand the reasons why this would need a rewrite for
the JDK (summary: it needs to be a full-fledged component), but would
argue that it's of great use to the community as it is.

This lack of a "high bar" for the project would allow us to move
forward more quickly and give people a production release earlier.
Because the libraries are under the JCA, Sun can, at any time in the
future, use all or some of the code to improve the JDK. But they don't
have to. At the same time, we would commit to no more and no less than
any other FOSS library--well thought-out, well-tested components. Not
"official" Swing extensions. Just a good component library.

How or what the Swing team does with the code is their own issue.
Certainly everybody here would appreciate their feedback. And of
course, Sun can ask its own engineers to lead reviews of the code to
search for useful stuff and good ideas. Maybe the best thing is that
the Swing team branches off of HEAD at the 1.0 release and reviews
that, suggesting possible changes to the main trunk and see what
everyone thinks of it.

We have to be realistic about what we can accomplish. We're currently
organized under a master plan for which we just don't have the
resources. That seems to be a fact, and it's sapping the energy of
this community.

Let's see if we can shift things around a bit to get some movement going again.

Noel, thanks for suggesting an alternative--hope I am not too far off
from where you were heading with this.

Regards
Patrick

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

Noel Grandin

Hi

Thanks Patrick, that explains in much greater clarity what I was aiming for.

Regards, Noel

Patrick Wright wrote:
> Noel,
>
>
> Noel, thanks for suggesting an alternative--hope I am not too far off
> from where you were heading with this.
>
> Regards
> Patrick

NOTICE: This email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html

If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com

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

Patrick Wright

Hi Miro

Just reporting as a community member, here's what has been said
before: the Swing team may, by their own choice, decide to incorporate
ideas or code from SwingLabs into the JDK Swing libraries. This is why
contributors sign the JCA, as this gives Sun joint copyright on the
material. When and if they do this is up to them, and there are no
guarantees as to whether they will. #

I believe filtering and sorting in Java 6 were based on ideas developed in JDNC.

There may be more specifics forthcoming, but this is the general
policy as I understand it.

Regards
Patrick

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

Miroslav Nachev

It is strange because everywhere in the JDNC source code is written:
Copyright 2004 Sun Microsystems, Inc., 4150 Network Circle,
* Santa Clara, California 95054, U.S.A. All rights reserved.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.

From the above I see that the Sun is owner of the JDNC source code.
Also the license is GNU LGPL. The license of JDK6 is GPL also. So, I can
not understand where is the problem JDNC to be included as part of JDK6 ?

Regards,
Miro.

Patrick Wright wrote:
> Hi Miro
>
> Just reporting as a community member, here's what has been said
> before: the Swing team may, by their own choice, decide to incorporate
> ideas or code from SwingLabs into the JDK Swing libraries. This is why
> contributors sign the JCA, as this gives Sun joint copyright on the
> material. When and if they do this is up to them, and there are no
> guarantees as to whether they will. #
>
> I believe filtering and sorting in Java 6 were based on ideas
> developed in JDNC.
>
> There may be more specifics forthcoming, but this is the general
> policy as I understand it.
>
> Regards
> Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
>

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

Patrick Wright

> From the above I see that the Sun is owner of the JDNC source code.
> Also the license is GNU LGPL. The license of JDK6 is GPL also. So, I can
> not understand where is the problem JDNC to be included as part of JDK6 ?

Here's how I understand it. SwingLabs (including what used to be JDNC)
is an independent project led by members of the Swing team. While the
license is LGPL for SwingX (all SwingLabs is open-source, but under
varying licenses), by signing the JCA we contributors grant shared
copyright to Sun. That means that programmers at Sun can, if they
want, include parts of these libraries into the JDK--I'm not sure
under what conditions, but anyway, they can.

SwingLabs is not the JCP, though, so it's not an official process for
extending the JDK. Rather, it's a low-overhead way for us Java
programmers to participate, develop, and debug components which are of
general use. It's up to Sun if they decide to use/port/copy/merge any
parts of SwingLabs into the JDK. Just because a component exists here
doesn't mean it will ever be in the JDK. But it will still be
available.

Thus there is no "problem", it's just not what these projects are
intended for, as I understand it. By making inclusion into the JDK
optional, this lets the community play around with good components
which, for one reason or another, maybe don't belong in the standard
libraries.

Patrick

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

Miroslav Nachev

I understand.
My desire these ("org.jdesktop.jdnc.form", "org.jdesktop.binding",
"org.jdesktop.dataset", "org.jdesktop.swingx",
"org.jdesktop.jdnc.table", etc.) and other interesting and useful
components to be part of JDK is because in this way and only in this way
they can be normalized and integrated. The other reason is that there
are more than 2 projects where the same things are done in similar or
different way, but the final result is the same. And here is the questions:
- Why so much programmers to lose time to do the same too many times?
- Which project to use developer for the current project?
- Which is better and where are the differences?

I think that one organization like Sun (because the Sun is originator of
Java) must handle all goods ideas and projects and to integrate to JDK
releases.

Regards,
Miro.

Patrick Wright wrote:
>> From the above I see that the Sun is owner of the JDNC source code.
>> Also the license is GNU LGPL. The license of JDK6 is GPL also. So, I can
>> not understand where is the problem JDNC to be included as part of
>> JDK6 ?
>
> Here's how I understand it. SwingLabs (including what used to be JDNC)
> is an independent project led by members of the Swing team. While the
> license is LGPL for SwingX (all SwingLabs is open-source, but under
> varying licenses), by signing the JCA we contributors grant shared
> copyright to Sun. That means that programmers at Sun can, if they
> want, include parts of these libraries into the JDK--I'm not sure
> under what conditions, but anyway, they can.
>
> SwingLabs is not the JCP, though, so it's not an official process for
> extending the JDK. Rather, it's a low-overhead way for us Java
> programmers to participate, develop, and debug components which are of
> general use. It's up to Sun if they decide to use/port/copy/merge any
> parts of SwingLabs into the JDK. Just because a component exists here
> doesn't mean it will ever be in the JDK. But it will still be
> available.
>
> Thus there is no "problem", it's just not what these projects are
> intended for, as I understand it. By making inclusion into the JDK
> optional, this lets the community play around with good components
> which, for one reason or another, maybe don't belong in the standard
> libraries.
>
>
> Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
>

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

evickroy
Offline
Joined: 2004-07-23

I believe that is what Swinglabs is intended for. It gives a central location for the developer community to work together on new ideas that "may" one day make it into the core libraries. In my opinion, a developer with new ideas should contribute to Swinglabs instead of starting off on a seperate project, if it's Swing related. Then no one is wasting time developing the same thing and everything is being developed under the Sun. ;)

One question came up quite some time ago concerning whether it was better for the Swinglabs classes to actually go into the core or not. The main point being that the community would have better control and faster response if left outside of the core. Maybe it was one of Richard's blogs, but it had some very interesting points to tihnk about.

Erik

coxcu
Offline
Joined: 2003-06-11

"In my opinion, a developer with new ideas should contribute to Swinglabs instead of starting off on a seperate project, if it's Swing related."

What would be the procedure for that? I have developed a few potentially reusable components over the years, but I don't think they should be taken without being reviewed. I'm sure there are thousands of people like me.

Ignoring that problem for a moment, how do you make it easier to find existing code within Swinglabs than writing new code?

evickroy
Offline
Joined: 2004-07-23

> What would be the procedure for that? I have
> developed a few potentially reusable components over
> the years, but I don't think they should be taken
> without being reviewed. I'm sure there are thousands
> of people like me.

The same as it has been. Sign the JCA, develop your ideas in the incubator, and present it to the Swinglabs community. Normally, you'll get feedback and possibly contributions or suggestions. If the community likes what you have proposed, then it might make it into a Swinglabs project, or become a sub-project on its own. If not, the code is in the incubator for use if anyone wants to use it. Eventually, some of the ideas in the incubator will be packaged in an "optional" jar, but lack of resources have slowed this task down, unfortunately. The more people that contribute, the better the code will be.

>
> Ignoring that problem for a moment, how do you make
> it easier to find existing code within Swinglabs than
> writing new code?
The Swinglabs projects are all Swing/Desktop related, so if what you are looking for isn't related to Swing/Desktop, then it probably isn't here. Start by looking at the docs, source, or post on the forums.

It wouldn't make since to decide today that you want to start work on a really cool component that looks just like a Windows task pane, for instance. Just contribute to JXTaskPane if it doesn't do everything that you want it to. If you have already built a task pane yourself, then compare the components. Are they both exactly the same, or does one have strengths over the other? Combine the efforts into one component to make one really good TaskPane. You win and the community wins. That's what these Open Source project are all about.

Erik

Patrick Wright

> The same as it has been. Sign the JCA, develop your ideas in the incubator, and present it to the Swinglabs community. Normally, you'll get feedback and possibly contributions or suggestions. If the community likes what you have proposed, then it might make it into a Swinglabs project, or become a sub-project on its own. If not, the code is in the incubator for use if anyone wants to use it. Eventually, some of the ideas in the incubator will be packaged in an "optional" jar, but lack of resources have slowed this task down, unfortunately. The more people that contribute, the better the code will be.

I second all this. Unless you have a really good reason for doing it
on your own, you gain a lot by sharing with SwingLabs. There are a
bunch of smart people who hang out on this list, with wide experience
in Swing and Java, plus members of the Swing team follow it as well.
Believe me, you'll get feedback, and it will usually be thorough.

Under the JCA, you still have copyright so can use or develop the
component on your own or for your own purposes. Under the LGPL, you're
free to use it as you wish.

I'm in favor of people experimenting, branching off on their own, etc.
but we have a good thing going here and we just need to build up the
community and (non-verbal :) activity.

Jump in, the weather's fine!
Patrick

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