springframework-rcp-dev — Spring Rich Client developer list

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Luan O'C. <lua...@gm...>]

The XUI framework mentioned earlier is now dead/frozen, however
development is continuing under the banner of the Aria framework
(http://www.sf.net/projects/aria). The framework includes things like
data bindings and automatic form and dialog generation from POJOs with
data binding, validation and caching. Spring integration is possible
and is being enhanced at the moment with support for annotation driven
generation of the UI, client side caching and rule driven coordination
of the UI (updates etc...).

The framework includes docking and other desktop metaphors plus lots
of rich components. The framework also comes with WYSIWYG plugins for
NetBeans and Eclipse. The framework can target various widget sets
including Swing, SWT, AWT and MIDP and JDKs from 1.1.8 to the very
latest.

There is a draft article at http://www.formaria.org/spring/integration
explaining some of the Spring integration.

Some or all of the framework might be of interest to this
project/current discussion and perhaps as the basis for future
development.

Luan

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Peter De B. <pet...@gm...>]

How will we continue from now on? Who will create the projects? The way
things are looking, I'm able to spend more time on spring desktop.

On Wed, Jul 2, 2008 at 5:20 AM, Jim Moore <moo...@gm...> wrote:

> Heya, everyone.  Sorry for jumping into this discussion late.
>
> I prefer Claudio's distinctions for breaking out the modules.  In any case,
> we need to make sure (like Spring) that there's never a circular dependency
> between packages so that things can easily be broken apart later if needed.
>
> Spring 3.0 will also be dropping JDK1.4 support.  Going to Java 5 just
> makes sense -- especially for a desktop app.  (In fact it's arguable that we
> should go to Java 6 given all the desktop improvements they made.)
>
> There's a reason no Spring example shows injecting a Logger.  The nature of
> logging and the logging libraries means there's no real benefit to doing
> so.  Also, in general commons-logging is a bad thing (especially in multiple
> classloader environments), which is why slf4j exists, but you can write to
> the commons-logging API and use slf4j as the implementation.  That's what
> the Spring does on the SpringSource Application Platform (S2AP), for
> example.
>
> I love the idea of new XML configuration.  A couple of comments on the
> examples:
>
> <bean id="someBean" class="foobar">
>     <property name="prefs">
>         <desktop:prefs scope="user|system"
> path="path/to/preferences/node"/>
>     </property>
> </bean>
>
> It's not clear from the example, but Spring already has support for the
> scoping capability (via aop:scoped-proxy) as described in section 3.4 of the
> reference manual.  I assume "user" scope would be defined based on a Spring
> Security SecurityContext and "system" would be a standard singleton?  Having
> the custom XML element would nicely hide those details from the user.
>
> <desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
>     <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
> mdi:closable="true" mdi:resizable="false">
>     <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="yetAnotherView"
> viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
> docking:draggable="true">
>     <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> In Spring 2.5 ADI style that might be done as
>
> <context:component-scan package="com.myco"/>
>
> @View
> public class SomeView {
>   @Autowired SomeView(SomeService someService) {..}
> }
>
> @View
> @MdiConfiguration(closable=true, resizable=false)
> public class OtherView {
>   @Autowired OtherView(SomeService someService) {..}
> }
>
> @View
> @DockingConfiguration(closable=false, draggable=false)
> public class YetAnotherView {
>   @Autowired YetAnotherView(SomeService someService) {..}
> }
>
>
> Modular plugin support is partly for plugins (a-la Eclipse or Netbeans),
> but mostly for making it easier to do good modularity.  Hot-swapping,
> discovery, etc are all just nice side-effects of having better modularity.
> Fortunately, because of Spring Dynamic Modules this can always be added
> later, especially if we follow the SpringDM conventions. (eg,
> /META-INF/spring/application-context.xml)  S2AP can provide the underlying
> support for that if we want.  Otherwise we can keep OSGi use (but not OSGi
> compliance) out for now.  Having JSR-277 support (like WebStart and
> Netbeans) would be awesome so people don't have to download 50 copies of
> log4j and updates can happen faster/easier.
>
> -Jim Moore
>  Senior Consultant, SpringSource
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Peter De B. <pet...@gm...>]

On Wed, Jul 2, 2008 at 5:20 AM, Jim Moore <moo...@gm...> wrote:

> Heya, everyone.  Sorry for jumping into this discussion late.
>
> I prefer Claudio's distinctions for breaking out the modules.  In any case,
> we need to make sure (like Spring) that there's never a circular dependency
> between packages so that things can easily be broken apart later if needed.
>
> Spring 3.0 will also be dropping JDK1.4 support.  Going to Java 5 just
> makes sense -- especially for a desktop app.  (In fact it's arguable that we
> should go to Java 6 given all the desktop improvements they made.)
>
> There's a reason no Spring example shows injecting a Logger.  The nature of
> logging and the logging libraries means there's no real benefit to doing
> so.  Also, in general commons-logging is a bad thing (especially in multiple
> classloader environments), which is why slf4j exists, but you can write to
> the commons-logging API and use slf4j as the implementation.  That's what
> the Spring does on the SpringSource Application Platform (S2AP), for
> example.
>
> I love the idea of new XML configuration.  A couple of comments on the
> examples:
>
> <bean id="someBean" class="foobar">
>     <property name="prefs">
>         <desktop:prefs scope="user|system"
> path="path/to/preferences/node"/>
>     </property>
> </bean>
>


the name scope is not very clear in this context: when you have
java.util.Preferences, you can have preferences at the user (= the current
user) scope, and at the system (= for all users) scope. It's not the bean
scope in the application context.


>
>
> It's not clear from the example, but Spring already has support for the
> scoping capability (via aop:scoped-proxy) as described in section 3.4 of the
> reference manual.  I assume "user" scope would be defined based on a Spring
> Security SecurityContext and "system" would be a standard singleton?  Having
> the custom XML element would nicely hide those details from the user.
>
> <desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
>     <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
> mdi:closable="true" mdi:resizable="false">
>     <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="yetAnotherView"
> viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
> docking:draggable="true">
>     <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> In Spring 2.5 ADI style that might be done as
>
> <context:component-scan package="com.myco"/>
>
> @View
> public class SomeView {
>   @Autowired SomeView(SomeService someService) {..}
> }
>
> @View
> @MdiConfiguration(closable=true, resizable=false)
> public class OtherView {
>   @Autowired OtherView(SomeService someService) {..}
> }
>
> @View
> @DockingConfiguration(closable=false, draggable=false)
> public class YetAnotherView {
>   @Autowired YetAnotherView(SomeService someService) {..}
> }


This is looking great!


>
>
>
> Modular plugin support is partly for plugins (a-la Eclipse or Netbeans),
> but mostly for making it easier to do good modularity.  Hot-swapping,
> discovery, etc are all just nice side-effects of having better modularity.
> Fortunately, because of Spring Dynamic Modules this can always be added
> later, especially if we follow the SpringDM conventions. (eg,
> /META-INF/spring/application-context.xml)  S2AP can provide the underlying
> support for that if we want.  Otherwise we can keep OSGi use (but not OSGi
> compliance) out for now.  Having JSR-277 support (like WebStart and
> Netbeans) would be awesome so people don't have to download 50 copies of
> log4j and updates can happen faster/easier.
>
> -Jim Moore
>  Senior Consultant, SpringSource
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Jim M. <moo...@gm...>]

Heya, everyone.  Sorry for jumping into this discussion late.

I prefer Claudio's distinctions for breaking out the modules.  In any case,
we need to make sure (like Spring) that there's never a circular dependency
between packages so that things can easily be broken apart later if needed.

Spring 3.0 will also be dropping JDK1.4 support.  Going to Java 5 just makes
sense -- especially for a desktop app.  (In fact it's arguable that we
should go to Java 6 given all the desktop improvements they made.)

There's a reason no Spring example shows injecting a Logger.  The nature of
logging and the logging libraries means there's no real benefit to doing
so.  Also, in general commons-logging is a bad thing (especially in multiple
classloader environments), which is why slf4j exists, but you can write to
the commons-logging API and use slf4j as the implementation.  That's what
the Spring does on the SpringSource Application Platform (S2AP), for
example.

I love the idea of new XML configuration.  A couple of comments on the
examples:

<bean id="someBean" class="foobar">
    <property name="prefs">
        <desktop:prefs scope="user|system" path="path/to/preferences/node"/>
    </property>
</bean>

It's not clear from the example, but Spring already has support for the
scoping capability (via aop:scoped-proxy) as described in section 3.4 of the
reference manual.  I assume "user" scope would be defined based on a Spring
Security SecurityContext and "system" would be a standard singleton?  Having
the custom XML element would nicely hide those details from the user.

<desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
    <property name="someService" ref="serviceId"/>
</desktop:view>

<desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
mdi:closable="true" mdi:resizable="false">
    <property name="someService" ref="serviceId"/>
</desktop:view>

<desktop:view id="yetAnotherView"
viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
docking:draggable="true">
    <property name="someService" ref="serviceId"/>
</desktop:view>

In Spring 2.5 ADI style that might be done as

<context:component-scan package="com.myco"/>

@View
public class SomeView {
  @Autowired SomeView(SomeService someService) {..}
}

@View
@MdiConfiguration(closable=true, resizable=false)
public class OtherView {
  @Autowired OtherView(SomeService someService) {..}
}

@View
@DockingConfiguration(closable=false, draggable=false)
public class YetAnotherView {
  @Autowired YetAnotherView(SomeService someService) {..}
}


Modular plugin support is partly for plugins (a-la Eclipse or Netbeans), but
mostly for making it easier to do good modularity.  Hot-swapping, discovery,
etc are all just nice side-effects of having better modularity.
Fortunately, because of Spring Dynamic Modules this can always be added
later, especially if we follow the SpringDM conventions. (eg,
/META-INF/spring/application-context.xml)  S2AP can provide the underlying
support for that if we want.  Otherwise we can keep OSGi use (but not OSGi
compliance) out for now.  Having JSR-277 support (like WebStart and
Netbeans) would be awesome so people don't have to download 50 copies of
log4j and updates can happen faster/easier.

-Jim Moore
 Senior Consultant, SpringSource

Re: [Springframework-rcp-dev] Docking Framework

[Lieven D. <lie...@ji...>]

Hello Peter,

I'll take a look at it this evening (got a deadline to catch today so...). 
TIA for the effort!

Greetz,

Lieven

[Springframework-rcp-dev] Docking Framework

[Peter K. <pe...@ya...>]

Hi Lieven,

I am finished with the mydoggy integration into Spring RC. We talked 
about it in the forum.

Would you take a look at it? See [1] and the screenshot [2].
It uses a slightly changed version of mydoggy (upcoming 1.5) to load and 
save the layout, so you have to use the provided jars within the download.

MyDoggy is really great, but maybe others (like me) would like to see 
another framework like swingdocking?
Arne, do you think that this is possible? I would help.


Regards,
Peter K.

[1]
http://downloads.sourceforge.net/timefinder/timefinder-snapshot-30.06.2008.zip?use_mirror=osdn
[2]
http://karussell.files.wordpress.com/2008/06/mydoggy-layout-springrc.jpg

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Claudio R. <cla...@li...>]

 >  1. Merge some modules
 >
 >  - support + core + forms + binding + jdk5 = core
 >  - retain modules jdk6, sandbox and resources

Hi All!!

I wrote my introduction in the forum :
http://forum.springframework.org/showthread.php?t=55848  :) 

I understand your point of view, looking at the modules as they are
today, it could make sense to merge them.

Nonetheless I think that to have modules with defined dependencies is a
good thing. My proposal for module would be:

Core module:
Contains objects like application lifecycle, security, page, view, and
action stuff. With the core module it should be possible to start an
application with action and views.

Binding/Form module:
I think that binding can be treated separately from the core stuff. Not
every Desktop Application needs bindings. If we separate the core from
the binding it will possible to use your binding of choice in
combination with the Spring Desktop core module.

Application module:
It contains all the rest: dialog, layout, progress, table, text, tree, ...

Sandbox module

Components module

JDK6


Separating the core module from the binding module would converge with
JSR 296 and 295. I think this two JSR's provide a good ground for
richclients. Does it make any sense to delve into this two JSR to check
whether it would make sense to integrate them into Spring Desktop?
Spring-Rich has its own binding, so we really have to be aware of the
pros/cons. To use standards may lead to a bigger acceptance / user base 
for Spring Desktop?

I think Spring Desktop could go further than the JSR 295 does and add 
additional value to it like the formModel stuff (validation), automatic 
binding, form builders and a lot "out of the box" bindings.

 >  7. Try to refactor out the singletons like Application and
ApplicationServices
 >
 >  We might be able to replace those with the Spring 2.5 @Component and
@Autowired
 >  system...

I think it would be great if we could get rid of this singletons. It
would mean a big refactoring of the codebase. The IOC pattern is the
better option in most cases, but of course I understand the reasons for
using the singleton pattern. If we want to replace the singletons we
must provide an easy-to-use-auto-wiring. Without auto wiring facilities
it would lead to a configuration mess.

Kevin Day mentioned other interesting alternatives (whiteboard) which 
maybe could be another direction?


These are just some thoughts…

Regards,
Claudio

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktop version

[Arne L. <Arn...@ar...>]

Hi Peter

Peter Karich schrieb:
>
> This is nice and Apache licensed ;-)
>   
;-)
> Could you provide a screenshot?
>   
It basically uses JInternalFrames. A Screenshot would look like some 
internal frames docked at each other.
> Or an example in the download section?
>   
http://swingdocking.svn.sourceforge.net/viewvc/swingdocking/trunk/samples/src/main/java/net/sf/swingdocking/samples/Sample.java?revision=17&view=markup

You need Java 6 for this.

Maybe I have some time next weekend to make a release, but you really 
can check it out with

svn co 
https://swingdocking.svn.sourceforge.net/svnroot/swingdocking/trunk 
swingdocking

and try it out.

Regards,
Arne

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktop version

[Peter K. <pe...@ya...>]

Hi Arne!

> You may also take a look at the docking framework I wrote some time ago:
> http://sourceforge.net/projects/swingdocking

This is nice and Apache licensed ;-)
Could you provide a screenshot?
Or an example in the download section?

> If someone is interested, I can write the SpringRCP integration.
> It is not much code,
> maybe you can completely take over the code into SpringRCP.

This would be great, I think.
Maybe others would like to see it, too.

Regards,
Peter.

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktop version

[Arne L. <Arn...@ar...>]

Hi All,

You may also take a look at the docking framework I wrote some time ago:

http://sourceforge.net/projects/swingdocking

It uses JInternalFrames as Docking-Panels.
I have not packed a release yet (nor created a web-page), but it is 
ready to use.
And if someone has some questions about it, I'm on this list...

If someone is interested, I can write the SpringRCP integration.
It is not much code,
maybe you can completely take over the code into SpringRCP.

Regards,
Arne

Peter Karich schrieb:
> Hi Lieven! Hi Spring-rich-client members!
>   
> I think, we should give mydoggy a try :-) (or xui). Please look at
> http://lopeathal.wikispaces.com/Open+Source+Docking+Frameworks
>
> Another suggestion from me is to look at other existing frameworks (in 
> the desktop arena):
>
> http://oswing.sourceforge.net
> http://xui.sourceforge.net
> http://www.tentackle.org
> http://sourceforge.net/projects/pendulum (inactive)
> (https://appframework.dev.java.net, https://beansbinding.dev.java.net )
>
>
> Regards,
> Peter (Karich ;-)).
>   

Re: [Springframework-rcp-dev] [Spring Desktop] ideas forthe Desktop version

[Lieven D. <lie...@ji...>]

Hello Benoit,

You're right about the modules, but at the moment, the split-up is just ridiculous. 
There's no code whatsoever in the forms module, a wee bit of code in core 
and binding and all the rest resides in support. Hence my merging proposition.

As for your issues, Jan's working on a new release, I think some of your 
issues are good candidates for inclusion.

Kind regards,

Lieven

> ----------------------------------------------------------------------
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Benoit X. <bx...@ob...>]

I’ll allow myself one comment on the merging of modules.

I agree that SpringRC probably has too many modules but we should keep in
mind that modules should be kept if it is possible that, at some point,
somebody might want to substitute an entire jar.

 

As such, a simple example is “resources” it could stay a module if somebody
want to use totally different icons/images.

(but resources could do with some trimming as a lot of it is not used at
all).

 

If modules are dependent both way then it make it very difficult to
substitute and hence merging them is a good idea.

 

Second suggestion for the refactoring… Do apply suggested patches that are
coming from real-life experience in order to make SpringRC more flexible (eg
JIRA 559, 553, 551, 550, 403, 437).

 

My £0.02 comments.

 

Thanks & best regards

 

Benoit

 

 

------------------------------

IMPORTANT NOTICE 

This communication contains information that is considered confidential and
may also be privileged . It is for the exclusive use of the intended
recipient(s). If you are not the intended recipient(s) please note that any
form of distribution, copying or use of this communication or the
information in it is strictly prohibited and may be unlawful. If you have
received this communication in error please return it to the sender and
delete the original.

 

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Peter De Bruycker
Sent: 24 June 2008 06:55
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the
Desktop version

 

some comments inline...



On Mon, Jun 23, 2008 at 10:29 AM, Lieven Doclo <HYPERLINK
"mailto:lie...@ji..."lie...@ji...> wrote:

Finally,

I've gotten my newsreader to work (again, thanks to Jetbrains :))

So I'll repeat here what I've put on the forum.

1. Merge some modules

- support + core + forms + binding + jdk5 = core
- retain modules jdk6, sandbox and resources

Perhaps we should also merge resources with the core, but only those
resources
directly needed in the core. The rest can be more something like 'skinning'.

I know this is quite controversial, but now we have the situation where no
one knows where something should be put, so it ends up in support. Modules
should also be selfcontained, no point in having a module that needs another
module anyhow for it to work.

My suggestion:

Core = essential Desktop stuff needed to make a simple application (forms,
basic binders and all underlying plumbing)
JDK6 = JDK6 specific stuff
Sandbox = playground for new stuff, should be followed-up on a regular basis
though
Resources = extra resources (do we need to have this in Desktop?)
Components = extra components (Jan, perhaps we can put your components in
here?)



2. Pull up the source level to 1.5

Java5 will give us a lot more leniency when dealing with some problems. For
example, I'd like to introduce generics in the FormModel and ValueModel for
starters. I think they're great candidates and I don't think it'll be a lot
of work. Using enums in certain places may also increase readability.

3. Rename Binder to BindingFactory

Since we're not bound to the RCP codebase, we should finally do this...

4. A lot more out-of-the-box bindings

Bindings are the mainstay of the application. Therefor I find it more than
logical that we include more bindings in the standard Desktop.


integration with Beans Binding?
 


5. Pull useful stuff from the sandbox

Now that we have the opportunity to do so, we should evaluate what's present
in the sandbox and promote it when useful.

6. Upgrade to Spring Security (Spring 2.5 in general)

Spring 2.5 gives us the possibility to do a lot more, so I think this makes
sense


Also custom xml elements, this would allow for less xml
 



7. Try to refactor out the singletons like Application and
ApplicationServices

We might be able to replace those with the Spring 2.5 @Component and
@Autowired
system...

8. Remove VLDocking

It has a GPL license, so it's not compatible with Desktop (unless someone
wants to release Desktop under the GPL?)


Can a GPL licensed project contain Apache licensed jar files? If so, we can
create a separate project to handle the integration.
 




Some stuff that has come up on the forums:

1. Modular plugin support (jwray)

OSGi-like support for plugins. Personally not my favorite, I don't know many
enterprise applications that use a plugin model, but I might be wrong about
this.

2. JIDE integration (jwray)

Great idea to include JIDE OSS into Desktop. It's a great collection of
components
and making binders for those components will raise the quality of the code.
For commercial JIDE components, we can foresee a separate module, if needed.

3. Integrate mydoggy as a docking framework (peatar)

Looking into it, I've gotten the code from peatar, if I find the time I'll
do a thorough test.

4. Replace commons-logging with slf4j (peatar)

Anyone that can make a clear pro-con analysis on this. I've only worked with
commons-logging.


wouldn't do this, as commons-logging is the de-facto standard
 



5. Logger injection (peatar)

PicoContainer has a LogInjector, do know though if this should be a Desktop
feature... Sounds more like Spring-core... Perhaps this already exists in
2.5, I don't know.


Feel free to comment, flame and add suggestions...

Greetz,

Lieven




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
HYPERLINK "http://sourceforge.net/services/buy/index.php"
\nhttp://sourceforge.net/services/buy/index.php
_______________________________________________
Springframework-rcp-dev mailing list
HYPERLINK
"mailto:Spr...@li..."Springframework-rcp-de
v...@li...
HYPERLINK
"https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"
\nhttps://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

 

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.1/1515 - Release Date: 23/06/2008
19:16


No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.4.1/1515 - Release Date: 23/06/2008
19:16
 

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktop version

[Peter K. <pe...@ya...>]

Hi Lieven! Hi Spring-rich-client members!

(I am the peatar from the forum)

I created an example with the beans bindings some times ago. It seems to 
be powerful, but not really active and not well documented.
Although the mailing list was quite helpful.

> As as for the commons-logging, I agree. But it was an idea on the forums, 
> and slf4j can indeed do a bit more than commons-logging. But most of us (I 
> think) work with commons-logging. Correct me if I'm wrong.

Well, then we should work with commons-logging.

> As for the GPL/ASL issue

It is a bit complicated. I think the GPL (version 2!) removes licenses 
(even open source) and make the code GPLed.
See http://www.apache.org/licenses/GPL-compatibility.html
And please look into a conversation with a FSF member and me [1]

So I think, we should give mydoggy a try :-) (or xui). Please look at
http://lopeathal.wikispaces.com/Open+Source+Docking+Frameworks

Another suggestion from me is to look at other existing frameworks (in 
the desktop arena):

http://oswing.sourceforge.net
http://xui.sourceforge.net
http://www.tentackle.org
http://sourceforge.net/projects/pendulum (inactive)
(https://appframework.dev.java.net, https://beansbinding.dev.java.net )


Regards,
Peter (Karich ;-)).



[1]
 > Does this mean that I can't use any GPL library too?

This will depend on whether your project can be argued as a derived work
from the GPL library. If it is, then you must release your project
under the GPL. If it isn't, then you can choose what license to apply
to your work. It can be LGPL, or anything else.

Even if the source-code form of your project is not a derived work of a
GPLed library, its object-code form most certainly is if it is linked
with a GPLed library. So, even though you can choose licensing terms
for the source-code form, it may be that the object-code form must be
licensed under the GPL. In this case, if the choice of license of your
own project, or of any other libraries it is linked with, is
incompatible with the GPL, it won't be possible to distribute this
combined work in object-code form.

If this means it won't be possible at all to distribute your program in
object-code form, odds are that even its source form is a derived work
of the GPLed work, and thus not even the source form can be distributed
under a different license.

 > I want to use db4o as an optional database, which is under the GPL.

In general, if you code any portion of your program specifically to use
a GPLed library, even if optionally, then your program is a derived work
and it must thus be licensed as a whole under the GPL.

There are very rare exceptions to this general rule, but you shouldn't
count on them without talking to a lawyer you trust, ideally one who is
familiar with these issues.

Please bear in mind that this is not to be taken as legal advice, since
I'm not a lawyer.

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktop version

[Peter De B. <pet...@gm...>]

On Tue, Jun 24, 2008 at 9:19 AM, Lieven Doclo <lie...@ji...>
wrote:

> Hello Peter,
>
> Thanks for the input. As for the Beans Binding, we could take a look at
> that
> indeed. Haven't work with the framework yet, but it looks nice. As for
> complexity,
> I'm not entirely sure whether it'll be an improvement, but we'll have to
> find that out, won't we?
>
> As as for the commons-logging, I agree. But it was an idea on the forums,
> and slf4j can indeed do a bit more than commons-logging. But most of us (I
> think) work with commons-logging. Correct me if I'm wrong.
>
> What custom elements do you have in mind? I see a number of candidates :).
>
> As for the GPL/ASL issue, I think it's backwards, can a ASL project
> (Desktop)
> contain GPL jars (VLDocking) ? I don't think so, unless your project is
> also
> GPL. I'm no fan of the GPL license, so I still don't think we should
> provide
> it. We could put it in a separate module, but I'm afraid this'll cause
> confusion
> with the end-users: 'if I use Desktop with this module, I need to be GPL,
> otherwise I don't'...


I meant a complete separate project (hosted somewhere else, on
dev.java.netof sourceforge), that is gpl licensed. That way we don't
have to worry about
licensing, and can leave the choice to the end-user.


>
>
> With your reply, I've got some more ideas:
>
> 9. Remove the closures in RCP (sorry Keith)
>
> As Keith said to me on SpringOne: SIMPLIFY, SIMPLIFY!! Keith's closures
> were
> a great idea (bit over the top though), but I don't think anyone is using
> them. They're easily refactored out of the codebase thanks to some Java5
> improvemenrs and for the sake of readability, I think we're better of
> without
> the code. So I think we should drop that part of the code.
>
> 10. Implement custom namespace elements for Spring configuration
>
> This can simplify the configuration greatly. We could also create Spring
> 2.5 component stereotype annotations for easy configuration using
> <context:component-scan/>.
>

this is what I meant with "custom elements"

candidates:

- java.util.Preferences instances in beans

something like this:

<bean id="someBean" class="foobar">
    <property name="prefs">
        <desktop:prefs scope="user|system" path="path/to/preferences/node"/>
    </property>
</bean>

- view descriptors

<desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
    <property name="someService" ref="serviceId"/>
</desktop:view>

<desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
mdi:closable="true" mdi:resizable="false">
    <property name="someService" ref="serviceId"/>
</desktop:view>

<desktop:view id="yetAnotherView"
viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
docking:draggable="true">
    <property name="someService" ref="serviceId"/>
</desktop:view>

this would allow for shorter xml that's more readable

I'm sure there are a lot more possibilities!

I think we need much closer integration with spring itself (xml support,
custom bean scopes, ...)



>
> WDYT?
>
> Greetz,
>
> Lieven
>
>
> > ----------------------------------------------------------------------
> > ---
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktop version

[Lieven D. <lie...@ji...>]

Hello Peter,

Thanks for the input. As for the Beans Binding, we could take a look at that 
indeed. Haven't work with the framework yet, but it looks nice. As for complexity, 
I'm not entirely sure whether it'll be an improvement, but we'll have to 
find that out, won't we?

As as for the commons-logging, I agree. But it was an idea on the forums, 
and slf4j can indeed do a bit more than commons-logging. But most of us (I 
think) work with commons-logging. Correct me if I'm wrong.

What custom elements do you have in mind? I see a number of candidates :).

As for the GPL/ASL issue, I think it's backwards, can a ASL project (Desktop) 
contain GPL jars (VLDocking) ? I don't think so, unless your project is also 
GPL. I'm no fan of the GPL license, so I still don't think we should provide 
it. We could put it in a separate module, but I'm afraid this'll cause confusion 
with the end-users: 'if I use Desktop with this module, I need to be GPL, 
otherwise I don't'... 

With your reply, I've got some more ideas:

9. Remove the closures in RCP (sorry Keith)

As Keith said to me on SpringOne: SIMPLIFY, SIMPLIFY!! Keith's closures were 
a great idea (bit over the top though), but I don't think anyone is using 
them. They're easily refactored out of the codebase thanks to some Java5 
improvemenrs and for the sake of readability, I think we're better of without 
the code. So I think we should drop that part of the code.

10. Implement custom namespace elements for Spring configuration

This can simplify the configuration greatly. We could also create Spring 
2.5 component stereotype annotations for easy configuration using <context:component-scan/>.

WDYT?

Greetz,

Lieven


> ----------------------------------------------------------------------
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Peter De B. <pet...@gm...>]

some comments inline...


On Mon, Jun 23, 2008 at 10:29 AM, Lieven Doclo <lie...@ji...>
wrote:

> Finally,
>
> I've gotten my newsreader to work (again, thanks to Jetbrains :))
>
> So I'll repeat here what I've put on the forum.
>
> 1. Merge some modules
>
> - support + core + forms + binding + jdk5 = core
> - retain modules jdk6, sandbox and resources
>
> Perhaps we should also merge resources with the core, but only those
> resources
> directly needed in the core. The rest can be more something like
> 'skinning'.
>
> I know this is quite controversial, but now we have the situation where no
> one knows where something should be put, so it ends up in support. Modules
> should also be selfcontained, no point in having a module that needs
> another
> module anyhow for it to work.
>
> My suggestion:
>
> Core = essential Desktop stuff needed to make a simple application (forms,
> basic binders and all underlying plumbing)
> JDK6 = JDK6 specific stuff
> Sandbox = playground for new stuff, should be followed-up on a regular
> basis
> though
> Resources = extra resources (do we need to have this in Desktop?)
> Components = extra components (Jan, perhaps we can put your components in
> here?)


>
> 2. Pull up the source level to 1.5
>
> Java5 will give us a lot more leniency when dealing with some problems. For
> example, I'd like to introduce generics in the FormModel and ValueModel for
> starters. I think they're great candidates and I don't think it'll be a lot
> of work. Using enums in certain places may also increase readability.
>
> 3. Rename Binder to BindingFactory
>
> Since we're not bound to the RCP codebase, we should finally do this...
>
> 4. A lot more out-of-the-box bindings
>
> Bindings are the mainstay of the application. Therefor I find it more than
> logical that we include more bindings in the standard Desktop.
>

integration with Beans Binding?


>
> 5. Pull useful stuff from the sandbox
>
> Now that we have the opportunity to do so, we should evaluate what's
> present
> in the sandbox and promote it when useful.
>
> 6. Upgrade to Spring Security (Spring 2.5 in general)
>
> Spring 2.5 gives us the possibility to do a lot more, so I think this makes
> sense


Also custom xml elements, this would allow for less xml


>
>
> 7. Try to refactor out the singletons like Application and
> ApplicationServices
>
> We might be able to replace those with the Spring 2.5 @Component and
> @Autowired
> system...
>
> 8. Remove VLDocking
>
> It has a GPL license, so it's not compatible with Desktop (unless someone
> wants to release Desktop under the GPL?)


Can a GPL licensed project contain Apache licensed jar files? If so, we can
create a separate project to handle the integration.


>
>
>
> Some stuff that has come up on the forums:
>
> 1. Modular plugin support (jwray)
>
> OSGi-like support for plugins. Personally not my favorite, I don't know
> many
> enterprise applications that use a plugin model, but I might be wrong about
> this.
>
> 2. JIDE integration (jwray)
>
> Great idea to include JIDE OSS into Desktop. It's a great collection of
> components
> and making binders for those components will raise the quality of the code.
> For commercial JIDE components, we can foresee a separate module, if
> needed.
>
> 3. Integrate mydoggy as a docking framework (peatar)
>
> Looking into it, I've gotten the code from peatar, if I find the time I'll
> do a thorough test.
>
> 4. Replace commons-logging with slf4j (peatar)
>
> Anyone that can make a clear pro-con analysis on this. I've only worked
> with
> commons-logging.


wouldn't do this, as commons-logging is the de-facto standard


>
>
> 5. Logger injection (peatar)
>
> PicoContainer has a LogInjector, do know though if this should be a Desktop
> feature... Sounds more like Spring-core... Perhaps this already exists in
> 2.5, I don't know.
>
>
> Feel free to comment, flame and add suggestions...
>
> Greetz,
>
> Lieven
>
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] [Desktop] Opinions on JSR 295 and 296?

[Kevin D. <ke...@tr...>]

I am wondering if anyone has any general thoughts on JSR 295 and 296.  My initial impression from working with 296 is that they have hit the nail directly on the head - but that it doesn't go quite far enough.  I think that 295 still has some details to work out (especially with where they incorporate validation), but their use of EL for certain binding definitions is very elegant in a lot of situations, and the underlying approach seems to be very intuitive (I am a user and fan of JGoodies bindings, but the learning curve can be steep).  

Just curious about where everyone sees this fitting into the Desktop project (if at all).

- K

[Springframework-rcp-dev] [Desktop] - Thoughts on directions for Desktop project

[Kevin D. <ke...@tr...>]

The list seems to be working fine.  I'll put my thoughts and comments here instead of continuing in the forums.

I hope that I have something to add to the conversation!

First comment:  I have done some initial work with MyDoggy, and I have come away quite impressed.  I would very much like to see this be a well supported part of Desktop (perhaps a second alternative to a single window type application).



I agree with the comments in the forum posting about service locator and factory patterns.  There is certainly a place for factory patterns, but I think that they should be approached with a great deal of caution, and all other options exhausted before their use.  My personal experience is that Factory is appropriate in small, relatively well contained contexts.  When it starts being used as a central location for components to access other components, the Factory pattern tends to create artificial dependencies and the problems associated with that (issues with testing, code re-use, etc...).  The use of SL and Factories in NetBeans is one of the prime reasons that we have chosen not to work with that platform - the NB platform works, but it tends to result in messy, messy code - and refactoring of the core architecture is almost impossible.

Before I write the next paragraph (outlining an effective alternate to the Factory pattern), I want to be sure that I state my position on OSGi/modules/etc... so I don't get branded as just another OSGi proponent:

1.  I think that the concept of bundles/code modules is a very good one - it's a discipline that leads to better quality code, and more thoughtful design of large systems.  Even if an app isn't running inside an OSGi type container, the underlying principles of the module idea can still be used and applied (though not necessarily *enforced* by the container).
2.  I do not think that Spring Desktop should be dependent on the use of OSGi
3.  I can easily see projects of mine that would benefit from an OSGi (or equivalent) container, but I also see plenty where that would just be overhead that I'd prefer to avoid.  Equinox can be deployed in less than 1 MB, but if you don't need it, then you don't need it.  I think that the Spring container may be able to provide the required capability to get the same benefit via dependency injection (hopefully while leaving the door open to using OSGi for projects that want it).

OK, with the above caveats in place, here is an alternative to the Factory pattern (or the singleton pattern such as used by Application.instance()):

An alternative approach to factories and lookups is suggested by whiteboarding (and I think that OSGi provides a very nice mechanism for this - esp. when coupled with Spring OSGi).  A couple of articles explaining this approach in OSGi are here (the knopflerfish article is quite good, providing hard code contrasts between the service lookup and whiteboarding approaches):

http://www.knopflerfish.org/osgi_service_tutorial.html
http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf


The difference in the two patterns is subtle (one is pretty much the exact reverse of the other) - but I think that whiteboarding is much more in keeping with the principle of IOC.  The thing that I find most interesting about whiteboarding is that any and all complexity associated with the relationship between two sub-systems is placed on the shoulders of the service *consumer* instead of the service *provider*.  In the case of the Desktop framework, this means that the complexity will be captured in the framework itself, and users of the framework will have minimal (if any) special requirements.  This, I believe, is the purpose of any well designed framework:  to minimize the amount of boilerplate code required by the users of the framework.  To be as unobtrusive as possible, and to create an environment where it is difficult for the user of the framework to shoot themselves in the foot.



One very simple example of where this design decision becomes important is in the development of an Action framework.  Many actions need to work on the current selection of one (or maybe multiple) elements in the GUI.  A simple approach is to have the action, when invoked, grab a some singleton that ultimately holds the current selection and request the current selection from it.  However, this precludes the ability of dynamically disabling the action, etc...  The solution to this is typically to register a listener on the current selection, and update the action state dynamically.  This works (although writing all of the listeners is a total hassle) - But this design is not a good design in the general case - specifically, it creates a nightmare for testing b/c you can't call the action without having the entire 'current selection' infrastructure mocked up and in place.  Also, this approach removes the possibility of having actions that are sensitive to selection in multiple areas of the application.

A different approach is to have a property on the action that accepts a list of objects that it should work on.  The application framework is configured declaritively to define the types of selections/etc... that the action can respond to, and the framework itself takes care of setting that property on the action as the application state changes.  Note that the aspect of the framework that even tracks 'current' selection could be completely different (in a very simple app, it could just be the selection model in a listview.  In other cases, it might be a SelectionList from GlazedLists - or maybe a rule based collection of the above plus others).  The point is that this approach completely separates the concern of performing actions from selection of which objects to act against.

One could envision collections of actions (perhaps via a mechanism similar to JSR 296's approach - if not exactly that approach) that allows for an intelligent ActionMap that is able to respond to changes in current selection to drive when different context menu actions should appear, which command bars should show, etc...




I think that's enough for now - I have a ton of other thoughts on bindings and where it fits into the overall picture (I think there is a tendency to use bindings just in the context of a single form ala the Presentation Model pattern, but I think that the utility of the bindings pattern may be much greater than that), Presentation Model pattern for dialogs, etc...


I look forward to any and all comments and thoughts!

- K


----------------------- Original Message -----------------------
 
From: Jan Hoskens <jh...@sc...>
To: <spr...@li...>
Cc: 
Date: Sat, 21 Jun 2008 12:43:31 +0200 (CEST)
Subject: Re: [Springframework-rcp-dev] Spring RCP/Desktop
 
For some reason, Lieven couldn't get the mail on the dev list. So I'll
post the link to the user forum where he finally put the message:

http://forum.springframework.org/showthread.php?t=56225

Are there any other users experiencing problems with the list?

Kind Regards,
Jan

[Springframework-rcp-dev] [Desktop] Founding principles

[Kevin D. <ke...@tr...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>

<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>I am primarily interested in the Desktop project (I believe that JSR 295 and 296 provide the beginnings of a very solid foundation for a really solid rich client framework).</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am wondering if there are any emails/notes/etc... about what aspects of the RCP project prompted to creation of the Desktop project.&nbsp; I think that if I can get my head around the challenges encountered with the existing implementation, then it will be easier to come up to speed quickly on the conversations pertaining to Desktop.&nbsp; I am also quite interested to hear about the similiarities and differences between RCP/Desktop and the Spring web framework.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I also am a strong believer that capturing design philosophy in writing allows for much easier generation of documentation down the road - as this is a part of most projects where things tend to fall behind, I'm wondering if this shouldn't receive some focus and attention up-front for the next go-around :-)&nbsp; Just having the philosophy written down makes the framework significantly more accessible to many developers, even if there isn't an official tutorial, etc...&nbsp; I would be more than happy to maintain such a document (at least a top-level document - the sub-systems of the framework may need their own philosophies), if I can be made to understand how things came to be, and what the general thinking is that is driving these frameworks.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am coming to this with a very fresh set of eyes, though I have done a lot of work with development of Swing apps using JGoodies binding, PresentationModel, validation, GlazedLists, etc...&nbsp; I have also done a fairly deep review of the NetBeans RCP framework (which I found wanting), and have done some level of review of the Eclipse framework.&nbsp;&nbsp;I am a firm believer that IOC is *the* way to go with app development, and I also think that bindings is a significant part of rich client IOC (not the entirety of it by any means, but a very important one).</DIV>
<DIV>&nbsp;</DIV>
<DIV>From my reading, etc... it seems that there were a couple of areas of the Spring-RCP project where it seemed like IOC was being avoided a bit (specifically, the Application singleton)&nbsp;- understanding that decision, I think, is also very important.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- K</DIV>
<DIV><BR>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV>&nbsp;&nbsp;</DIV>
<DIV><B>From:</B>&nbsp;Jan Hoskens <A href="mailto:jh...@sc..."><FONT color=#0000ff>&lt;jh...@sc...&gt;</FONT></A></DIV>
<DIV><B>To:</B>&nbsp;<A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B>&nbsp;Kevin Day <A href="mailto:ke...@tr..."><FONT color=#0000ff>&lt;ke...@tr...&gt;,</FONT></A> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Johannes Schneider <A href="mailto:joh...@fa..."><FONT color=#0000ff>&lt;joh...@fa...&gt;,</FONT></A> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Ryzhikov, Eugene" <A href="mailto:Eug...@fp..."><FONT color=#0000ff>&lt;Eug...@fp...&gt;</FONT></A></DIV>
<DIV><B>Date:</B>&nbsp;Fri, 20 Jun 2008 10:45:36 +0200</DIV>
<DIV><B>Subject:&nbsp;<U>Spring RCP/Desktop</U></B></DIV>
<DIV>&nbsp;&nbsp;</DIV></DIV><FONT face=Tahoma size=2>
<DIV>Hi all,<BR><BR>It has been a quiet period for Spring RCP/Desktop, but it's time to<BR>shift in gear. As we've been with only two active developers (Peter and<BR>I)?, it immediately shows when times get busy on other fronts, can't<BR>help that. Ok, Jim &amp; Keith, I kinda left you out here, but I'm hoping<BR>you'll get bugged and start mailing/coding right away ;-)<BR><BR>As you may notice, there are some emails in the CC. Kevin, Johannes and<BR>Eugene contacted me or the list in some form to show their interest. As<BR>a first I would like to apologize for the late reply, and as a second I<BR>would like to mention that any help is really appreciated. There are<BR>several ways to get involved. You might have solved some issues or have<BR>some interesting additions to Spring RCP. If so, let me know and I'll<BR>take a peek. If we're completely blown away by the beauty of your coding<BR>(which I'm sure it will do), we'll invite you to join the developer team<BR>and give you 
 commit rights. On the other hand, if you're interested in<BR>the development of the new Spring Desktop, keep an eye on the upcoming<BR>mails on the dev list and join in whenever you want. After wards the<BR>same comment goes as for the coding part. As a third, there's still the<BR>documentation part in which you might have some interest? (yes, I know<BR>it's not the most popular one).<BR><BR>I also want to introduce Lieven, a former colleague of mine who is<BR>already putting his thoughts about Spring Desktop in a mail. He has<BR>gained experience with Spring RCP during his days with me and wants to<BR>continue traveling down that road. Thanks for starting the discussion<BR>Lieven! To make things a bit more clear, I would suggest to add a<BR>subject prefix [Desktop] or [Spring-Desktop] to the mails concerning the<BR>new stuff.<BR><BR>In parallel, I want to set a date to push out a maintenance release of<BR>Spring RCP somewhere mid-July. I'll check Jira and see which issues c
 an<BR>be fixed and included. <BR><BR>That's it for now, any remarks are welcome as usual.<BR><BR>ps: Peter, hope all is well with the family!<BR><BR>ps: I'm not responsible for any accidents occurred during the reading of<BR>this mail.<BR><BR>Kind Regards,<BR>Jan<BR><BR><BR>**** DISCLAIMER ****<BR><A href="http://www.schaubroeck.be/maildisclaimer.htm"><FONT color=#0000ff>http://www.schaubroeck.be/maildisclaimer.htm</FONT></A><BR><BR></DIV></FONT></BODY></HTML>

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktopversion

[Lieven D. <lie...@ji...>]

> 5. Logger injection (peatar)
> 
> PicoContainer has a LogInjector, do know though if this should be a
> Desktop feature... Sounds more like Spring-core... Perhaps this
> already exists in 2.5, I don't know.

Apparently, this can be solved using a @Logger annotation in combination 
with a beanpostprocessor... Again, might not be a Desktop feature, but handy 
nevertheless.

see: http://www.tzavellas.com/techblog/2007/03/31/implementing-seam-style-logger-injection-with-spring/

Greetz,

Lieven

[Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Lieven D. <lie...@ji...>]

Finally,

I've gotten my newsreader to work (again, thanks to Jetbrains :))

So I'll repeat here what I've put on the forum.

1. Merge some modules 

- support + core + forms + binding + jdk5 = core
- retain modules jdk6, sandbox and resources

Perhaps we should also merge resources with the core, but only those resources 
directly needed in the core. The rest can be more something like 'skinning'.

I know this is quite controversial, but now we have the situation where no 
one knows where something should be put, so it ends up in support. Modules 
should also be selfcontained, no point in having a module that needs another 
module anyhow for it to work.

My suggestion:

Core = essential Desktop stuff needed to make a simple application (forms, 
basic binders and all underlying plumbing)
JDK6 = JDK6 specific stuff
Sandbox = playground for new stuff, should be followed-up on a regular basis 
though
Resources = extra resources (do we need to have this in Desktop?)
Components = extra components (Jan, perhaps we can put your components in 
here?)

2. Pull up the source level to 1.5

Java5 will give us a lot more leniency when dealing with some problems. For 
example, I'd like to introduce generics in the FormModel and ValueModel for 
starters. I think they're great candidates and I don't think it'll be a lot 
of work. Using enums in certain places may also increase readability.

3. Rename Binder to BindingFactory

Since we're not bound to the RCP codebase, we should finally do this... 

4. A lot more out-of-the-box bindings

Bindings are the mainstay of the application. Therefor I find it more than 
logical that we include more bindings in the standard Desktop. 

5. Pull useful stuff from the sandbox

Now that we have the opportunity to do so, we should evaluate what's present 
in the sandbox and promote it when useful.

6. Upgrade to Spring Security (Spring 2.5 in general)

Spring 2.5 gives us the possibility to do a lot more, so I think this makes 
sense

7. Try to refactor out the singletons like Application and ApplicationServices

We might be able to replace those with the Spring 2.5 @Component and @Autowired 
system...

8. Remove VLDocking

It has a GPL license, so it's not compatible with Desktop (unless someone 
wants to release Desktop under the GPL?)


Some stuff that has come up on the forums:

1. Modular plugin support (jwray)

OSGi-like support for plugins. Personally not my favorite, I don't know many 
enterprise applications that use a plugin model, but I might be wrong about 
this.

2. JIDE integration (jwray)

Great idea to include JIDE OSS into Desktop. It's a great collection of components 
and making binders for those components will raise the quality of the code. 
For commercial JIDE components, we can foresee a separate module, if needed.

3. Integrate mydoggy as a docking framework (peatar)

Looking into it, I've gotten the code from peatar, if I find the time I'll 
do a thorough test.

4. Replace commons-logging with slf4j (peatar)

Anyone that can make a clear pro-con analysis on this. I've only worked with 
commons-logging.

5. Logger injection (peatar)

PicoContainer has a LogInjector, do know though if this should be a Desktop 
feature... Sounds more like Spring-core... Perhaps this already exists in 
2.5, I don't know.


Feel free to comment, flame and add suggestions... 

Greetz,

Lieven

Re: [Springframework-rcp-dev] Spring RCP/Desktop

[Lieven D. <lie...@ji...>]

Geoffrey De Smet <ge0ffrey.spam <at> gmail.com> writes:

> 
> No problems here, I am looking at it through nntp://news.gmane.org
> 

Through the HTTP view of Gmane it works, I'll post it through this then. 

Greetz,

Lieven

CAPTCHA: congresswomen... must be elections in the US :)

Re: [Springframework-rcp-dev] Spring RCP/Desktop

[Peter De B. <pet...@gm...>]

Jan,

I'm still quite busy for the moment (one week till last deadline), so I'll
be able to spend some time on spring desktop starting next week.

At home, things couldn't be better, thanks for asking!

regards,

Peter

On Fri, Jun 20, 2008 at 10:45 AM, Jan Hoskens <jh...@sc...> wrote:

> Hi all,
>
> It has been a quiet period for Spring RCP/Desktop, but it's time to
> shift in gear. As we've been with only two active developers (Peter and
> I), it immediately shows when times get busy on other fronts, can't
> help that. Ok, Jim & Keith, I kinda left you out here, but I'm hoping
> you'll get bugged and start mailing/coding right away ;-)
>
> As you may notice, there are some emails in the CC. Kevin, Johannes and
> Eugene contacted me or the list in some form to show their interest. As
> a first I would like to apologize for the late reply, and as a second I
> would like to mention that any help is really appreciated. There are
> several ways to get involved. You might have solved some issues or have
> some interesting additions to Spring RCP. If so, let me know and I'll
> take a peek. If we're completely blown away by the beauty of your coding
> (which I'm sure it will do), we'll invite you to join the developer team
> and give you commit rights. On the other hand, if you're interested in
> the development of the new Spring Desktop, keep an eye on the upcoming
> mails on the dev list and join in whenever you want. After wards the
> same comment goes as for the coding part. As a third, there's still the
> documentation part in which you might have some interest (yes, I know
> it's not the most popular one).
>
> I also want to introduce Lieven, a former colleague of mine who is
> already putting his thoughts about Spring Desktop in a mail. He has
> gained experience with Spring RCP during his days with me and wants to
> continue traveling down that road. Thanks for starting the discussion
> Lieven! To make things a bit more clear, I would suggest to add a
> subject prefix [Desktop] or [Spring-Desktop] to the mails concerning the
> new stuff.
>
> In parallel, I want to set a date to push out a maintenance release of
> Spring RCP somewhere mid-July. I'll check Jira and see which issues can
> be fixed and included.
>
> That's it for now, any remarks are welcome as usual.
>
> ps: Peter, hope all is well with the family!
>
> ps: I'm not responsible for any accidents occurred during the reading of
> this mail.
>
> Kind Regards,
> Jan
>
>
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

Re: [Springframework-rcp-dev] Spring RCP/Desktop

[Geoffrey De S. <ge0...@gm...>]

No problems here, I am looking at it through nntp://news.gmane.org

Jan Hoskens schreef:
> For some reason, Lieven couldn't get the mail on the dev list. So I'll
> post the link to the user forum where he finally put the message:
> 
> http://forum.springframework.org/showthread.php?t=56225
> 
> Are there any other users experiencing problems with the list?
> 
> Kind Regards,
> Jan
> 
> 
> 
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php

Re: [Springframework-rcp-dev] Spring RCP/Desktop

[Jan H. <jh...@sc...>]

For some reason, Lieven couldn't get the mail on the dev list. So I'll
post the link to the user forum where he finally put the message:

http://forum.springframework.org/showthread.php?t=56225

Are there any other users experiencing problems with the list?

Kind Regards,
Jan



 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm