Skip to main content

proposal to uplevel JDNC project structure

29 replies [Last post]
Anonymous

As I hinted at in a separate thread, we'd like to propose a slight project restructuring to the java.net JDNC project.

Proposal:

We'd like to uplevel jdnc.dev.java.net so that it's more of an uber-project (aka "Swing Labs") which contains a myriad of subprojects which can be used either individually or together. Under this master project we would create an individual project for each of JDNC's 3 layers: Swing Extensions, JDNC Components, JDNC Markup. Each would have their own CVS module, forum, & mailing lists, but they would share the JCA/licensing. We would provide a site where all subprojects could be downloaded together as a convenience and possibly provide a site with integrated documentation (javadoc).

Upsides:

1. It would allow us to add additional subprojects in the spirit of exploring extensions to Swing which may not fit into JDNC's currently defined scope. Such projects would be easier for us to initiate because they could leverage the JDNC project infrastructure (e.g. JCA, license, lawyers, etc)

2. It makes it easier for the community to pick and choose their areas of interest without having to grok/download the entire thing. (e.g. it's clear many folks JUST want JDNC's Swing Extensions layer).

3. It would make it easier to evolve each subproject at its own pace.

4. It will help minimize dependencies and spaghetti-library syndrome.

Downsides:

- It would break existing cvs repositories

- It may have some API impact, although this should be minimal since we strove to keep the 3 layers clearly separated to begin with.

- It may require re-subscribing membership to subprojects, though perhaps by default we would transfer membership to at least the Swing Extensions project automatically.

We're curious what you think of this concept. If this causes more trouble than its worth then obviously we can keep the project structured as-is.

Aim

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rbair
Offline
Joined: 2003-07-08
Points: 0

> +1 for that.
> Another +1 for refactoring the
> sorting/filtering-mechanism of JDNC.
[snip]
> And maybe another +1 for serializing a DataModel to
> XML.

Wow, them's a lot of plus ones :)

Thanks for the feedback. As for serializing a DataModel to XML, if we haven't started a thread for that yet (and I don't think we have), then feel free to start a new thread so we can discuss it more.

Thanks
Richard

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> > +1 for that.
> > Another +1 for refactoring the
> > sorting/filtering-mechanism of JDNC.
> > [snip]
> > And maybe another +1 for serializing a DataModel
> > to XML.
>
> Wow, them's a lot of plus ones :)
>

Filters, sorters, and highlighters are meant to be used with SwingX components, and are already in a separate *package*. I don't think it makes sense to put them in a separate *layer*.

Ramesh

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

> I wanted to get some community feedback. I'm thinking
> of possibly breaking the DataModel/binding framework
> out of the "swingx" layer and creating a new layer.
> Essentially, it would be the bottom most layer, so it
> would go binding->swingx->jdnc->markup.
>

The young wilds just chuckling :-)

Generally, I agree that it's a good idea to pull out swing independent classes into its own layer. The DataModel is the obvious candidate, even if we currently don't know all its details, it's clear that it will be independent of UI, be it Swing or whatever. I see a subtle problem, though: there will be DataModels adapting to/from Swing models - where to put them? (No, not in the Binding implementation )

Some Swing models themselves are in the "candidate" state for being pulled out off Swing for years. If they were outside then the adapters as well would reside in the new layer, otherwise in Swingx ... hmmm.

As to the Binding - that's a different story: we don't know yet enough about the abstraction to decide where to put which parts of it, we don't even have defined different parts At some point a binding needs to have intimate contact to the concrete widget toolkit. Without knowing where exactly that is it makes little sense to pull out anything. IMO.

Without any ui-independent binding the layer will not have much weight compared to the others, introducing an imbalance.

On the whole, I'm not sure if it's worth the effort right now. And usually I follow the "When in doubt - don't change". My 2 (Euro- ) cents.

Jeanette

mikeazzi
Offline
Joined: 2003-08-11
Points: 0

>
> As to the Binding - that's a different story: we
> don't know yet enough about the abstraction to decide
> where to put which parts of it, we don't even have
> defined different parts At some point a binding
> needs to have intimate contact to the concrete widget
> toolkit. Without knowing where exactly that is it
> makes little sense to pull out anything. IMO.
>

Is it a fair thing to say though, that the Binding layer, for all intents and purposes, is for the most part functionally equivalent, or similar to the DataModel layer? One (Binding) operates on the MetaData, and the other on the actual data. Of course with obvious caveats that the MetaData does not change as often as the data.
The reason why I'm saying this is maybe then we can model the Binding layer by leveraging some of the lessons, and best patterns learned from the existing Swing DataModel layer.

So if you were to draw those layers again, the DataModel and Binding modules would be sitting vertically adjacent to each other in the block diagram. Whether those can/should be combined into one module or not is a implementation detail.

Just some thoughts.

Mike

> Without any ui-independent binding the layer will not
> have much weight compared to the others, introducing
> an imbalance.
>
> On the whole, I'm not sure if it's worth the effort
> right now. And usually I follow the "When in doubt -
> don't change". My 2 (Euro- ) cents.
>
> Jeanette

lorson
Offline
Joined: 2006-02-17
Points: 0

> I wanted to get some community feedback. I'm thinking
> of possibly breaking the DataModel/binding framework
> out of the "swingx" layer and creating a new layer.
> Essentially, it would be the bottom most layer, so it
> would go binding->swingx->jdnc->markup.
>
> There is some decent refactoring involved. Obviously
> a lot of packages are going to change.
>
> The idea was spawned from the earlier thread
> regarding binding code for j2me. Or, gasp, for
> binding to other frameworks than swing (who in their
> right mind would want to??? Oh, you mean, like AWT
> :)). To show this, and also to show the logical
> separation between swing and the binding api, I'm
> thinking about moving it to its own "layer".
>
> Rich

+1 for that.
Another +1 for refactoring the sorting/filtering-mechanism of JDNC.

I'd like to have a possiblilty to sort/filter a DataModel without involving GUI-widgets. The current mechanism of sorting/filtering is strictly component-orientated. So if you want to use or manipulate a DataModel programmatically you should have a possiblity to filter and sort.

And maybe another +1 for serializing a DataModel to XML.

dhall
Offline
Joined: 2006-02-17
Points: 0

>> I'd like to have a possiblilty to sort/filter a DataModel without involving GUI-widgets. The current mechanism of sorting/filtering is strictly component-orientated. So if you want to use or manipulate a DataModel programmatically you should have a possiblity to filter and sort.

There are a number of general purpose algorithm packages that will handle that for you -- if you want to do it programatically, you can already find what you need with a little googling.

Dave Hall
http://jga.sf.net/
http://jroller.com/page/dhall/

Patrick Wright

Rich

>From what I understand, it seems that "stable" has a stronger connotations
in FOSS circles than just "it passed our unit tests". Debian stable, for
example, should be completely reliable, having been tested extensively by
developers in actual use.

Another idea for naming might be
- automated/unstable (no testing)
- nightly (unit-tested)
- stable (unit, smoke and hand-tested, reliable)

This would mean that "stable" is actually a cut/snapshot of some point of
development, with frozen APIs, and is released less often. It could be
given a point (0.02, 0.03) increment.

As for naming the project/subprojects, my (unvarnished) opinions
- Java is already swimming in acronyms, we dont need another one; move
away from JDNC (except maybe on the mailing list and internally)

- Agree that name should not be swing-specific (though maybe SwingX could
be Swing Labs, naming just that subproject and experimental stuff)

- It seems that JDNC is focusing on "rich" client apps, not server stuff,
so "client" or "application" should be in there

- Could have a cool but unrepresentative name, like Smooth

- I like the word "Labs" :) (weird word, isnt English wonderful?)

- SmartApp Labs? PowerApp Labs? Extend Labs?

Just riffing.
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
Points: 0

Hey Patrick,

> >From what I understand, it seems that "stable" has a
> stronger connotations
> in FOSS circles than just "it passed our unit tests".
> Debian stable, for
> example, should be completely reliable, having been
> tested extensively by
> developers in actual use.
>
> Another idea for naming might be
> - automated/unstable (no testing)
> - nightly (unit-tested)
> - stable (unit, smoke and hand-tested, reliable)

Good call. I'll definately use something other than "stable".

> This would mean that "stable" is actually a
> cut/snapshot of some point of
> development, with frozen APIs, and is released less
> often. It could be
> given a point (0.02, 0.03) increment.

These would be the milestone, release candidate and full releases.

> - Agree that name should not be swing-specific
> (though maybe SwingX could
> be Swing Labs, naming just that subproject and
> experimental stuff)
>
> - It seems that JDNC is focusing on "rich" client
> apps, not server stuff,
> so "client" or "application" should be in there
>
> - Could have a cool but unrepresentative name, like
> Smooth
>
> - I like the word "Labs" :) (weird word, isnt English
> wonderful?)
>
> - SmartApp Labs? PowerApp Labs? Extend Labs?
>

Another point to consider is that perhaps JDNC/Swing Labs (whatever) *should* focus on the swing aspects, and allow other things to find a home in other java.net/sourceforge/jakarta projects. If Swing Labs (or whatnot) is too general, then it starts to infringe on the territory already owned by java.net/javadesktop.org.

Or is the Rich Client App space significantly different from the javadesktop space?

Would we prefer to see Swing Labs (or whatever) be a jakarta like project, or a jakarta-commons like project? We may be better off as a project, and as a community, with a more narrowly defined charter than one that is particularly broad.

Thoughts?

Richard

Nicola Ken Barozzi

jdnc-interest@javadesktop.org wrote:
...
> Another point to consider is that perhaps JDNC/Swing Labs (whatever)
> *should* focus on the swing aspects, and allow other things to find a
> home in other java.net/sourceforge/jakarta projects. If Swing Labs (or
> whatnot) is too general, then it starts to infringe on the territory
> already owned by java.net/javadesktop.org.

My 2 cents worth, having done Swing development + my own framework for
some time now and having just joined.

The package structure is quite neat overall, and conceptually it seems
natural to me to consider this division:

- swingx (extra swing widgets)
- binding (the form and widget binding framework)
- jndc (the markup stuff)

It just feels evident that swing needs extra widgets, like a calendar
control, an outlook bar, etc. It also looks normal that they would all
belong to the same project.

The binding would be a project that makes it easy to bind data models to
swing widgets. A new and easy way to use Swing.

JNDC: all the markup and novel app generation system based on xml

> Or is the Rich Client App space significantly different from the
> javadesktop space?

I think that "Rich Client App" is an abused, overloaded and almost
meaningless catchphrase. I'd not emphasize the "rich" part, as client
apps are usually more "rich" than server-side apps in any case.

> Would we prefer to see Swing Labs (or whatever) be a jakarta like
> project, or a jakarta-commons like project? We may be better off as a
> project, and as a community, with a more narrowly defined charter than
> one that is particularly broad.

From what I think I have understood from my participation in the Apache
Incubator http://incubator.apache.org/ , dividing up projects too early
is not going to do them good.

Given the current state of development, I would be happy to see the
project renamed to a more generic "Swing Labs", with a single repository
containing swingx, binding, and jndc.

Community division at this phase IMHO may disperse efforts too much, and
create synchronizations problems. There is no need to divide communities
just to divide code compilation units.

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

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

James Todd

I'll throw in my $.02 and second this perspective. I do like "Swing Labs" as a
generic name as well. Simple yet expansive as needed.

Nice writeup.

- james

James Todd :: blogs.sun.com/gonzo

Java == platform independence
XML == application independence
JXTA == network independence

Secure End-to-End Computing

Nicola Ken Barozzi wrote:
>
> jdnc-interest@javadesktop.org wrote:
> ...
>
>> Another point to consider is that perhaps JDNC/Swing Labs (whatever)
>
> > *should* focus on the swing aspects, and allow other things to find a
>
>> home in other java.net/sourceforge/jakarta projects. If Swing Labs (or
>> whatnot) is too general, then it starts to infringe on the territory
>> already owned by java.net/javadesktop.org.
>
>
> My 2 cents worth, having done Swing development + my own framework for
> some time now and having just joined.
>
> The package structure is quite neat overall, and conceptually it seems
> natural to me to consider this division:
>
> - swingx (extra swing widgets)
> - binding (the form and widget binding framework)
> - jndc (the markup stuff)
>
> It just feels evident that swing needs extra widgets, like a calendar
> control, an outlook bar, etc. It also looks normal that they would all
> belong to the same project.
>
> The binding would be a project that makes it easy to bind data models to
> swing widgets. A new and easy way to use Swing.
>
> JNDC: all the markup and novel app generation system based on xml
>
>> Or is the Rich Client App space significantly different from the
>> javadesktop space?
>
>
> I think that "Rich Client App" is an abused, overloaded and almost
> meaningless catchphrase. I'd not emphasize the "rich" part, as client
> apps are usually more "rich" than server-side apps in any case.
>
>> Would we prefer to see Swing Labs (or whatever) be a jakarta like
>> project, or a jakarta-commons like project? We may be better off as a
>> project, and as a community, with a more narrowly defined charter than
>> one that is particularly broad.
>
>
> From what I think I have understood from my participation in the Apache
> Incubator http://incubator.apache.org/ , dividing up projects too early
> is not going to do them good.
>
> Given the current state of development, I would be happy to see the
> project renamed to a more generic "Swing Labs", with a single repository
> containing swingx, binding, and jndc.
>
> Community division at this phase IMHO may disperse efforts too much, and
> create synchronizations problems. There is no need to divide communities
> just to divide code compilation units.
>

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

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> I've always kind of balked at the JDNC name
> because it has no character, and nobody knows what
> the project is for just by reading the name. Even
> knowing the full name is a little ambiguous, IMO.

We've already had numerous debates on the name. I remember, somebody once suggested SledgeHammer, or JackHammer, or something like it! For better or worse, the JDNC name has stuck. I don't think it is a good idea to mess with the brand name at this point.

Ramesh

rbair
Offline
Joined: 2003-07-08
Points: 0

Hey Ramesh,

> The outline looks good, altough "Swing Labs" as the
> name of the uber project does not properly reflect
> its full scope. SwingX is just a small part of what
> the whole project is about -- a grab bag of
> everything needed to build rich internet application
> (including things that have nothing to do with
> Swing). A lot of web app developers might simply tune
> out this project based on the Swing Labs monicker.
> How about calling it "JDNC Labs" instead?

Maybe since the goal here is to have Rich Client apps, that could form the basis for a name? Maybe Rich Swing? Rich Java? Rich Labs? (I know it sounds like a self aggrandizing name, but I can't help it :)). I've always kind of balked at the JDNC name because it has no character, and nobody knows what the project is for just by reading the name. Even knowing the full name is a little ambiguous, IMO.

> >
> > Now for the heavy part, the build cycle.
> >
> > Builds will happen many times a day [snip]
> > A history of these builds is not kept [snip]
> >
> > Once nightly there will be another build.
> > This build may or may not contain errors. [snip]
> > A history of a weeks worth of these builds will be
> kept
> >
> > Whenever a nightly build completes without any
> > errors, it will be uploaded to the web server as
> the
> > latest “stable integration build”. A history of
> these
> > builds is not kept.
>
> I tried to parse the two previous paragraphs multiple
> times, and got a feeling that something is amiss here
> :-) as they seem to say that we'd keep a history of
> nightly builds even though they might contain errors,
> but won't keep a history of successful nightly
> builds! Is that right?

[ducks] ya? Boy, when you put it like that it sounds kinda dumb :). The idea was that the latest "stable integration build" is nothing more than a pointer to the last nightly build that worked. If you want to pick a different build from history, then you can look at the weeks worth of nightly builds and pick one. If the last weeks worth of builds are all bad, then the "stable" build will still point to the last good build, even if it was months ago.

Maybe I should call it the "last known good", or "stable nightly" or "last stable nightly" or something?

> You might also want to clarify that "stable" is a
> relative term, in this case indicating only that a
> build has passed the automated JUnit tests, but
> nothing more.

That's a good point. Is there another name that could be used so that it is obvious to people trying to figure out which jar to download? Or should I just note that in the documentation, and perhaps provide a description on the download site with each build category describing what they are?

> Rest of the proposal sounds good to me! You made no
> mention of Maven, but I'm assuming that each
> subproject will track its dependence on other
> projects using Maven.

I'm not sure at this point, actually. I've been talking a little bit with the Jakarta guys (check out their archives here for the messages -- there are only 4 of 'em), and browsing their CVS to see how they manage their projects. They actually let each project decide for themselves how to build their project etc.

I'd rather have a specified build process that everybody could just follow, and use Maven for it. At least, for all of the top level projects we'd have this more structured approach. The incubator would be free form and anybody could do as they please.

I guess if the core JDNC developers manage all of the top level projects, then we can impose that structure without hurting anybodies feelings, but if we have top level projects where JDNC developers are not the developers for the project, then perhaps some degree of autonomy would be good.

I don't know. What do you think?

Richard

PS> Thanks for the thought-out feedback!

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> Maybe since the goal here is to have Rich Client
> apps, that could form the basis for a name? Maybe
> Rich Swing? Rich Java? Rich Labs? (I know it sounds
> like a self aggrandizing name, but I can't help it :))

Great sense of humor!
Who knows, "Rich Labs" might even bring riches to us paupers someday ;-)

Ramesh

rbair
Offline
Joined: 2003-07-08
Points: 0

Hey Everybody,

As promised I'm here with a basic outline of the kinds of things I'm thinking about doing to the JDNC build process. These findings are relevant whether JDNC is "upleveled" to Swing Labs or not. To avoid any confusion, I'm going to use the name Swing Labs for now.

Here's the basic outline. Swing Labs will be comprised of two different types of sub-projects: top level projects and incubator projects. Top level projects are those projects which are considered a supported part of the Swing Labs project. These projects are direct sub-projects of Swing Labs. Incubator projects, on the other hand are all sub-projects of the “incubator” project. The Incubator project is itself a subproject of Swing Labs. The following diagram illustrates the project organization:
[PRE]
Swing Labs
|
--- SwingX
|
--- JDNC
|
--- Markup
|
--- Binding
|
--- Incubator
|
--- PDF Renderer
|
--- Docking Framework
|
--- HTML Renderer
|
--- JScrollUp
|
--- etc.
[/PRE]
Developers may download the incubator source code, or the compiled Jars for use in their applications. However, the incubator jar will be separate from the normal Swing Labs Jars, and will contain a README specifying the experimental nature of the incubator code. Incubator code will also use a different source code package structure than the core swing labs projects.

As for the project bylaws, I'm thinking about following the basic charter & guidelines of our friends over at Jakarta. See http://jakarta.apache.org/commons/charter.html, and http://jakarta.apache.org/site/guidelines.html.

Now for the heavy part, the build cycle.

Builds will happen many times a day by means of CruiseControl or perhaps Gump. CruiseControl allows for “continuous integration” which is a fancy way of saying that a build is done whenever changes are committed to CVS. This build will be immediately uploaded to the webserver for distribution as the latest “snapshot build”. These builds may contain errors, but represent the latest state of the project. A history of these builds is not kept, the old version of the file is replaced by the most recent version.

Once nightly there will be another build. This build may or may not contain errors. This build represents the current state of the project at 12:00am Pacific time. A history of a weeks worth of these builds will be kept on the web server.

Whenever a nightly build completes without any errors, it will be uploaded to the web server as the latest “stable integration build”. A history of these builds is not kept.

When a milestone or release is reached, a special build will be made. This build will be tested against a variety of operating systems before being uploaded to the webserver. Once certified and uploaded, these builds will be listed as the latest milestone (M1-M4) or release (R1.0). These builds are never removed from the web server.

Between the final milestone and a release may be any number of release candidates (called RC1, RC2, etc). These RC's are believed to be stable release quality builds, and follow all of the normal build rules as a Milestone. They are kept on the web server indefinately.

Finally, the build process will construct a Jar for each of the top level projects, and a single swinglabs jar which is an aggregate of all of the individual top level jars. The incubator code is not built by the automatic build process. Ant and/or Maven tasks will exist for easily creating incubator jars, and incubator projects may wish to construct and post their own jar files, but the swing labs build server/process will not be involved in this task.

If anybody has any experience doing these kinds of builds, I'd love to get your input. What we're trying to accomplish with this build process is pretty ambitious, and hopefully useful enough for the community.

We also hope to get some new sections on the website up before too long, showing CVS activity and reports as well as recent fixes, changelogs, etc.

Any feedback is greatly appreciated!

Thanks,
Richard

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> As promised I'm here with a basic outline of the
> kinds of things I'm thinking about doing to the JDNC
> build process. These findings are relevant whether
> JDNC is "upleveled" to Swing Labs or not. To avoid
> any confusion, I'm going to use the name Swing Labs
> for now.
>

Richard,

The outline looks good, altough "Swing Labs" as the name of the uber project does not properly reflect its full scope. SwingX is just a small part of what the whole project is about -- a grab bag of everything needed to build rich internet application (including things that have nothing to do with Swing). A lot of web app developers might simply tune out this project based on the Swing Labs monicker. How about calling it "JDNC Labs" instead?

[snip]

>
> Now for the heavy part, the build cycle.
>
> Builds will happen many times a day [snip]
> A history of these builds is not kept [snip]
>
> Once nightly there will be another build.
> This build may or may not contain errors. [snip]
> A history of a weeks worth of these builds will be kept
>
> Whenever a nightly build completes without any
> errors, it will be uploaded to the web server as the
> latest “stable integration build”. A history of these
> builds is not kept.

I tried to parse the two previous paragraphs multiple times, and got a feeling that something is amiss here :-) as they seem to say that we'd keep a history of nightly builds even though they might contain errors, but won't keep a history of successful nightly builds! Is that right?

You might also want to clarify that "stable" is a relative term, in this case indicating only that a build has passed the automated JUnit tests, but nothing more.

Rest of the proposal sounds good to me! You made no mention of Maven, but I'm assuming that each subproject will track its dependence on other projects using Maven.

Ramesh

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> You made no
> mention of Maven, but I'm assuming that each
> subproject will track its dependence on other
> projects using Maven.

Sorry, you did mention Maven!

rbair
Offline
Joined: 2003-07-08
Points: 0

I was just going over the orignal post, and noticed this under the "upsides" section:

> 3. It would make it easier to evolve each subproject
> at its own pace.

This depends on what is considered a sub project. For example, you will want Binding/Swingx/JDNC/Markup to move forward as a single unit, since otherwise you will have to specify that version X.Y.Z of JDNC only works with version A.B.C and greater of SwingX. Obviously, these kinds of dependencies will be a nightmare to maintain.

On the other hand, the PDF-Renderer subproject doesn't need to move in lockstep with the "normal" JDNC components, so it could very well benefit from having its own release cycle.

Richard

Nicola Ken Barozzi

jdnc-interest@javadesktop.org wrote:
> I was just going over the orignal post, and noticed this under the "upsides" section:
>
>>3. It would make it easier to evolve each subproject
>>at its own pace.
>
> This depends on what is considered a sub project. For example, you
> will want Binding/Swingx/JDNC/Markup to move forward as a single unit,
> since otherwise you will have to specify that version X.Y.Z of JDNC only
> works with version A.B.C and greater of SwingX. Obviously, these kinds
> of dependencies will be a nightmare to maintain.

+1

> On the other hand, the PDF-Renderer subproject doesn't need to move
> in
> lockstep with the "normal" JDNC components, so it could very well
> benefit from having its own release cycle.

Release early, release often. And keep the codebase always functional
and compiling.

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

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

scottdelap
Offline
Joined: 2004-04-21
Points: 0

I agree that JDNC should be upleveled. It has become a catch all for Swing advancements not related to JDIC. I like the idea of creating a Swing Labs type name and rebranding JDNC as a part of it.

rbair
Offline
Joined: 2003-07-08
Points: 0

I wanted to get some community feedback. I'm thinking of possibly breaking the DataModel/binding framework out of the "swingx" layer and creating a new layer. Essentially, it would be the bottom most layer, so it would go binding->swingx->jdnc->markup.

There is some decent refactoring involved. Obviously a lot of packages are going to change.

The idea was spawned from the earlier thread regarding binding code for j2me. Or, gasp, for binding to other frameworks than swing (who in their right mind would want to??? Oh, you mean, like AWT :)). To show this, and also to show the logical separation between swing and the binding api, I'm thinking about moving it to its own "layer".

Rich

wsnyder6
Offline
Joined: 2004-04-20
Points: 0

That makes sense from an architecture standpoint. (If you abstract out the datamodel/binding layer, are there other JDNC layers that should be abstracted as well??)

I think I'd agree with what Jeanette said on that earlier thread - 'the devil would be in the details' of supporting the various frameworks.

--Bill

dhall
Offline
Joined: 2006-02-17
Points: 0

+1

Exposing a couple of API dependencies is a good thing, and the resubscription is a minor hassle.

It's better to get this kind of thing out of the way early.

Dave Hall
http://jga.sf.net/
http://jroller.com/page/dhall

netsql
Offline
Joined: 2004-03-07
Points: 0

It be nice if JDIC was under JDNC.

.V

Andy Freeman

+1

I agree with this!

On Sat, 20 Nov 2004 08:51:17 EST, jdnc-interest@javadesktop.org
wrote:
> It be nice if JDIC was under JDNC.
>
> .V
> ---
> [Message sent by forum member 'netsql' (Vic Cekvenich)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=39269&#39269
>
>
>
> ---------------------------------------------------------------------
> 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

Patrick Wright

Hi

+1 on the proposal.

Would be nice if the download/integration was relatively simplified;
perhaps Maven? Or Antmod? So that if I am working with the Extensions
project, I can update the Markup project easily and make sure the latest
build is on my classpath. How were you thinking of distributing the
jars--would we need to pull from each project, or would they be
cross-distributed? Maven or something like it could take care of that on
the developer's end.

Patrick

jdnc-interest@javadesktop.org wrote:
> As I hinted at in a separate thread, we'd like to propose a slight project restructuring to the java.net JDNC project.
>
> Proposal:
>
> We'd like to uplevel jdnc.dev.java.net so that it's more of an uber-project (aka "Swing Labs") which contains a myriad of subprojects which can be used either individually or together. Under this master project we would create an individual project for each of JDNC's 3 layers: Swing Extensions, JDNC Components, JDNC Markup. Each would have their own CVS module, forum, & mailing lists, but they would share the JCA/licensing. We would provide a site where all subprojects could be downloaded together as a convenience and possibly provide a site with integrated documentation (javadoc).
>
> Upsides:
>
> 1. It would allow us to add additional subprojects in the spirit of exploring extensions to Swing which may not fit into JDNC's currently defined scope. Such projects would be easier for us to initiate because they could leverage the JDNC project infrastructure (e.g. JCA, license, lawyers, etc)
>
> 2. It makes it easier for the community to pick and choose their areas of interest without having to grok/download the entire thing. (e.g. it's clear many folks JUST want JDNC's Swing Extensions layer).
>
> 3. It would make it easier to evolve each subproject at its own pace.
>
> 4. It will help minimize dependencies and spaghetti-library syndrome.
>
> Downsides:
>
> - It would break existing cvs repositories
>
> - It may have some API impact, although this should be minimal since we strove to keep the 3 layers clearly separated to begin with.
>
> - It may require re-subscribing membership to subprojects, though perhaps by default we would transfer membership to at least the Swing Extensions project automatically.
>
> We're curious what you think of this concept. If this causes more trouble than its worth then obviously we can keep the project structured as-is.
>
> Aim
> ---
> [Message sent by forum member 'Aim' (Amy Fowler)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=39207&#39207
>
> ---------------------------------------------------------------------
> 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

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> Hi
>
> +1 on the proposal.
>
> Would be nice if the download/integration was
> relatively simplified; perhaps Maven? Or Antmod?
> So that if I am working with the Extensions project,
> I can update the Markup project easily and make
> sure the latest build is on my classpath.
>

Patrick,

The JDNC team has discussed the use of Maven for tracking cross-project dependencies (between JDNC and OpenMarkup, for example). We agreed that this is the direction we want to take, but the task remained on the back burner. With the partitioning of JDNC itself into smaller, more autonomous projects, this will become more important.

Ramesh

rbair
Offline
Joined: 2003-07-08
Points: 0

Just wanted to keep everyone up to date with where we are at. I'm currently looking at Maven and defining a general project structure that we can use here. After doing some homework I'll post my findings to get some feedback on the design and structure of the build, and of the project.

Richard

James Todd

ooohhhhhhh ... maven rocks!

w/ my projects i have multiple src dirs which are tough to
manage. i'd love to have a good solution for that at which
point we'll cut over to maven in a heartbeat.

as such, i'd love to hear lessons learned.

rock on,

- james

James Todd :: blogs.sun.com/gonzo

Java == platform independence
XML == application independence
JXTA == network independence

Secure End-to-End Computing

jdnc-interest@javadesktop.org wrote:
> Just wanted to keep everyone up to date with where we are at. I'm currently looking at Maven and defining a general project structure that we can use here. After doing some homework I'll post my findings to get some feedback on the design and structure of the build, and of the project.
>
> Richard
> ---
> [Message sent by forum member 'rbair' (Richard Bair)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=41205&#41205
>
> ---------------------------------------------------------------------
> 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
Points: 0

Sup James,

> ooohhhhhhh ... maven rocks!
>
> w/ my projects i have multiple src dirs which are
> tough to
> manage. i'd love to have a good solution for that at
> which
> point we'll cut over to maven in a heartbeat.
>
> as such, i'd love to hear lessons learned.

So far its been exhilaration followed by depression, followed by respect. Or something like that :)

One of the really, really cool things about maven is the website generation stuff. Its pretty easy to get a website for your project generated in no time. Modifying that website so it looks decent ... well that's a little tougher :)

The difficult thing for me so far has been to find out how to set up the multi-project structure. I mean, I could be a total brute and write some jelly scripts to do everything, but I kind of want to use as much built in functionality as possible.

However, the build releases that we want to do (including integration builds, nightly builds, stable builds, milestones, release candidates and releases) are pretty complex. I'm fairly certain I'll be writing a new plugin for this. I might be able to contribute back to maven -- we'll see.

>
> rock on,

Now that's the attitude I like to hear :)

-Rich