Skip to main content

Breeding a monster?

5 replies [Last post]
kleopatra
Offline
Joined: 2003-06-11
Points: 0

Hi gals and guys,

just noticed that it looks like the code from the swinglabs-demos project was folded into SwingX - if so, when/who/where/why was that done?

As you might guess I'm opposed to doing so:

- While the demos are based on SwingX they are not part of it. F.i. there is no maintenance nor quality guarantee for that part, neither for the swingxset nor for the actual demos.

- they are intended to demo not only SwingX but other (least theoretically ;-) SwingLabs subs as well.

- they have external dependencies which shouldn't be smeared into this (maven or not, it's dirty)

- ...

Opinions please?

Cheers

Jeanette

 

 

 

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kschaefe
Offline
Joined: 2006-06-08
Points: 0

I did it. Nothing of it is in the 1.6.3 release, BTW. I was testing the idea locally, but did not feel bold enough to add a demos 1.6.3 release cycle right now.

kleopatra wrote:
- While the demos are based on SwingX they are not part of it. F.i. there is no maintenance nor quality guarantee for that part, neither for the swingxset nor for the actual demos.

No one ever said there would be. Just being housed in the same area doesn't mean that there is the same quality guarantee. However, it is now much easier to determine, which changes are API breaking. Some such changes are subtle.

kleopatra wrote:
- they are intended to demo not only SwingX but other (least theoretically ;-) SwingLabs subs as well.

Possibly, but I'll sight two things: first, no one has in years; two, we're the only active SwingLabs project. Furthermore, if people wish to create new demos against SwingXSet, it is possible by grabbing the jar from the SwingX site or eventually from Maven central.

kleopatra wrote:
- they have external dependencies which shouldn't be smeared into this (maven or not, it's dirty)

This makes no sense whatsoever. We have external dependencies in SwingX that exist only for testing and no one has ever complained about those. They don't make it into client releases, in the same way that the demos stuff would not.

To my mind, we gain several advantages:

1. Easy to keep the demos in sync.

2. Additional code checks enabled by the demos. With tighter integration (some codespace), it is easier to run the demos with the latest code.

3. Better SVN history for files that get ported from demo space to real, SwingX space. We'd done this plenty and lost track of changes every time.

4. Maven isolates, so there is no code contamination, no dependency leakage.

5. Provides in situ, real world usage of components. Clients do not need a second repo that shows them how to use the SwingX code.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

[quote=kschaefe]

I did it.  Nothing of it is in the 1.6.3 release, BTW. 

thought so much, shouldn't have added the "who" :-) That's good news, leaves some time for a thorough discussion, hopefully getting tons of opinions.

Have to think a bit about your arguments, some sound more convincing then others. Will be back next week.

Have a nice weekend

Jeanette

 

 

 

kschaefe
Offline
Joined: 2006-06-08
Points: 0

Having seen you flurry of post-1.6.4 check-ins to keep the demos up to date, I thought I would circle back around on this idea? What are your and everyone elses thoughts here? Should we go forward with maintaining the demo code in the swingx space? With Maven to isolate the code, we have nothing to worry about as far as demo code becoming intertwined with "real" SwingX code. We can also configure Maven to release the demo code to Maven Central and (I think) automatically update our demo JNLP, which would be nice.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

still don't like it ;-)

One part of it could well be my personal disgust whenever I have to touch maven (which admittedly isn't often, and seeing you as the expert struggle with it for months isn't really an incentive for me to jump deeper into it).

The other part, though, is that I still think we should keep SwingX-the-framework separated from SwingDemos-the-application-using-swingx-and-others, boundaries not only set up by a tool as f.i. maven but by project boundaries provided by the hosting at java.net. They are simply different beasts, in content, scope, quality, maintenance, ...

I don't weigh the advantages you see as high as you do: don't see much of a problem in manual synching (1, 2); don't know what clients want (5), releasing the demo code to maven central might give a wrong signal (strenghten expectations as expressed in http://java.net/jira/browse/SWINGX-1501). No longer loosing history (3) sounds like the strongest point: only ... it's trading loosing _all, once_ against loosing _some, once_, not as good a deal as it sounds, IMO.

So currently I tend to -1, thumbs-down, don't .. nothing graved into granite, though, just in moderately strong rock :-)

curious on further feedback
Jeanette

kschaefe
Offline
Joined: 2006-06-08
Points: 0

kleopatra wrote:
One part of it could well be my personal disgust whenever I have to touch maven (which admittedly isn't often, and seeing you as the expert struggle with it for months isn't really an incentive for me to jump deeper into it).

I only struggle when we try to get Maven to do something that it is not intended to do...like create aggregate jars in the way we are doing.

kleopatra wrote:
The other part, though, is that I still think we should keep SwingX-the-framework separated from SwingDemos-the-application-using-swingx-and-others, boundaries not only set up by a tool as f.i. maven but by project boundaries provided by the hosting at java.net. They are simply different beasts, in content, scope, quality, maintenance, ...

That also means that no SwingX developer ever *needs* to do any work there. We cannot make the proper functioning of demos and SwingXSet be part of the release requirements. I guess the question is why do we have this demo in the first place, if we don't really want to support it and vet our code with it?

It sounds like you're telling me that I should put the demos on the pay-no-attention list and be on my way.

Karl

wzberger
Offline
Joined: 2004-08-31
Points: 0

I totally agree - don't make things more complicated as they are.

Cheers

Wolfgang