Menu
▾
▴
springframework-rcp-dev — Spring Rich Client developer list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(37) |
Jun
(141) |
Jul
(111) |
Aug
(91) |
Sep
(79) |
Oct
(151) |
Nov
(161) |
Dec
(93) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(40) |
Feb
(60) |
Mar
(43) |
Apr
(90) |
May
(31) |
Jun
(114) |
Jul
(35) |
Aug
(112) |
Sep
(305) |
Oct
(151) |
Nov
(122) |
Dec
(103) |
| 2006 |
Jan
(65) |
Feb
(57) |
Mar
(475) |
Apr
(276) |
May
(482) |
Jun
(134) |
Jul
(127) |
Aug
(188) |
Sep
(271) |
Oct
(220) |
Nov
(74) |
Dec
(41) |
| 2007 |
Jan
(121) |
Feb
(50) |
Mar
(36) |
Apr
(11) |
May
(31) |
Jun
(12) |
Jul
(73) |
Aug
(41) |
Sep
(59) |
Oct
(33) |
Nov
(60) |
Dec
(111) |
| 2008 |
Jan
(139) |
Feb
(49) |
Mar
(87) |
Apr
(43) |
May
(10) |
Jun
(25) |
Jul
(114) |
Aug
(17) |
Sep
(25) |
Oct
(199) |
Nov
(94) |
Dec
(45) |
| 2009 |
Jan
(36) |
Feb
(14) |
Mar
(29) |
Apr
(32) |
May
(49) |
Jun
(18) |
Jul
(68) |
Aug
(34) |
Sep
(34) |
Oct
(11) |
Nov
(10) |
Dec
(14) |
| 2010 |
Jan
(35) |
Feb
(12) |
Mar
(23) |
Apr
(17) |
May
(4) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
|
Nov
(10) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
(8) |
Apr
(3) |
May
|
Jun
|
Jul
(4) |
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(8) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
(5) |
Jun
(1) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(15) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Kevin D. <ke...@tr...> - 2008-07-07 17:29:54
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>thanks for the explanation on where the service locator pattern came from - that helps a lot. I'm wondering if there may be value in trying to capture the true complexity of the dependency graph that's involved and see what sorts of things maybe could benefit from refactoring, injection by convention perhaps - it sounds like there has been a lot of movement in the Spring web framework to simplify this kind of declarative injection.</DIV>
<DIV> </DIV>
<DIV>I certainly want to minimize the amount of boiler plate/explicit configuration required for consumers of the framework. The configuration-by-convention approach that some web frameworks are beginning to use is quite appealing.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Larry Streepy <A href="mailto:lst...@au..."><FONT color=#0000ff><lst...@au...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Mon, 07 Jul 2008 11:45:49 -0500</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion</U></B></DIV>
<DIV> </DIV></DIV><TT>Hi Everyone,<BR><BR>It's been a long time since I've participated, so hopefully my viewpoints won't be too dated :-)<BR><BR>IOn the issue of OSGi, I would argue along the lines of Jim Moore - do it later when we find a pressing need that can't be solved without it, and work to cleanly modularize our codebase to ensure no cyclic dependencies etc.<BR><BR>To Kevin's question about the decision to not use DI for the core services (and to use a service locator pattern instead), the main reason that it came about was due to the massive amount of XML that would be required to inject the desired services into every object. Additionally, the number of dynamic objects that need access to platform services can be huge, and there was no good way to get the quickly wired in. You either had to resort to intermediate factories that could be DI'd and have the factories wire in the services (and that required extra interfaces on the created objects
to accept the injection), or invent some other similar scenario to get the services into the dynamic objects.<BR><BR>I'm still of the opinion that a service locator singleton (with a pluggable implementation) provides benefits and doesn't require the complexity of having to have a declarative model that knows about every single kind of object that might come into existence during the life of the application. But, I'm always ready to be educated out of any antiquated notions I may hold if someone can show me how the wiring of dynamic objects can be handled in a simple way (very little XML and minimal biolerplate).<BR><BR>Learning curve and the amount of XML you have to write in order to get your application running were two significant factors we faced with the adoption of Spring RCP. I personally feel that requiring new app developers to learn yet another complex piece of machinery (OSGi) in addition to all the rest of Spring Rich (which is significant by itself
) would not be beneficial to the project's uptake.<BR><BR>Just my $.02 worth - boy, I hate how the current economy makes my opinions worth less each month :-)<BR><BR>Thanks,<BR>Larry.<BR><BR>Kevin Day wrote:</TT>
<BLOCKQUOTE cite=mid:REY1UFNUTiZDVDs0Ji0+NTY1Nzg1NzE4@satchel type="cite">
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR><FONT face=Arial size=2>
<DIV>Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox project is the baseline OSGi implementation).</DIV>
<DIV> </DIV>
<DIV>From my perspective, I don't think that OSGi is necessarily appropriate for a lot of GUI apps (although I do think it probably has more applicability than we might give it credit - even a simple music player could benefit greatly from a pluggable codec system). From my perspective, the *module* approach is the important thing. And if we are going to do modules, we might as well do something that is at least upwards compatible with OSGi. Certainly, the full OSGi functionality is not necessary for most apps - I actually a think a very small subset would be appropriate - and this sub-set could be run inside AND outside an OSGi container with a little bit of Spring DI magic.</DIV>
<DIV> </DIV>
<DIV>Here's the basic premise: Because OSGi supports dynamic loading and unloading of modules, they have been forced to address the issue of dynamic dependency management. The core result is that modules do *not* interact directly with each other. Instead, they either locate other modules (using a service locator type pattern), or they have those modules injected (using the whiteboard pattern). Time has shown that the dynamic dependency injection pattern is more reliable, easier to test and results in more flexible systems (allowing modules to be dynamically loaded and unloaded without impacting the operation of the application). In dynamic environments, it also makes service consumers much, much simpler to write (there is almost no boilerplate code - this is all refactored up into the framework).</DIV>
<DIV> </DIV>
<DIV>Most importantly, modularity forces better design practices overall. There are absolutely cases where functionality is so closely tied together that it will always reside in the same module - but I suspect that a lot of that sort of thing is occuring in the current code base because of the use of service locator type patterns instead of dependency injection (could be wrong on that, and I certainly don't want to step on any toes - but sometimes it's healthy to have an outsider question a design decision :-) ).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>This actually raises an interesting question that I hope someone with a deeper history in the Spring-RCP project can answer: How did the original decision to depart from Spring IOC/DI come about in the RCP project? Was it b/c of objection of creating and maintaining tons of Spring xml files, or was there some other reason? I think that maybe by understanding this, we may learn many of the things that need to be considered as we have the current discussion. It's super easy to set back at the end of years of development and question design decisions that were made early on - and in doing so, it's easy to miss some extremely important detail that went into the decision.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT></BLOCKQUOTE><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at http://www.sourceforge.net/community/cca08<BR><BR></DIV></FONT>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML>
|
|
From: Luan O'C. <lua...@gm...> - 2008-07-07 16:56:07
|
Yes please, let's design modularity in from the start, even if it is implemented fully now. 2008/7/7 Kevin Day <ke...@tr...>: > Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox > project is the baseline OSGi implementation). > > From my perspective, I don't think that OSGi is necessarily appropriate for > a lot of GUI apps (although I do think it probably has more applicability > than we might give it credit - even a simple music player could benefit > greatly from a pluggable codec system). From my perspective, the *module* > approach is the important thing. And if we are going to do modules, we > might as well do something that is at least upwards compatible with OSGi. > Certainly, the full OSGi functionality is not necessary for most apps - I > actually a think a very small subset would be appropriate - and this sub-set > could be run inside AND outside an OSGi container with a little bit of > Spring DI magic. > > Here's the basic premise: Because OSGi supports dynamic loading and > unloading of modules, they have been forced to address the issue of dynamic > dependency management. The core result is that modules do *not* interact > directly with each other. Instead, they either locate other modules (using > a service locator type pattern), or they have those modules injected (using > the whiteboard pattern). Time has shown that the dynamic dependency > injection pattern is more reliable, easier to test and results in more > flexible systems (allowing modules to be dynamically loaded and unloaded > without impacting the operation of the application). In dynamic > environments, it also makes service consumers much, much simpler to write > (there is almost no boilerplate code - this is all refactored up into the > framework). > > Most importantly, modularity forces better design practices overall. There > are absolutely cases where functionality is so closely tied together that it > will always reside in the same module - but I suspect that a lot of that > sort of thing is occuring in the current code base because of the use of > service locator type patterns instead of dependency injection (could be > wrong on that, and I certainly don't want to step on any toes - but > sometimes it's healthy to have an outsider question a design decision :-) > ). > > > This actually raises an interesting question that I hope someone with a > deeper history in the Spring-RCP project can answer: How did the original > decision to depart from Spring IOC/DI come about in the RCP project? Was it > b/c of objection of creating and maintaining tons of Spring xml files, or > was there some other reason? I think that maybe by understanding this, we > may learn many of the things that need to be considered as we have the > current discussion. It's super easy to set back at the end of years of > development and question design decisions that were made early on - and in > doing so, it's easy to miss some extremely important detail that went into > the decision. > > - K > > ----------------------- Original Message ----------------------- > > From: Peter Karich <pe...@ya...> > To: spr...@li... > Cc: > Date: Fri, 04 Jul 2008 22:22:50 +0200 > Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas > for theDesktopversion > > Hi Lieven, > > like you, I think that almost all people will use springRC as one bundle. > So it could be that no splitting is necessary (only the traditional way > of jar bundles of course) > But maybe I missed the point you are talking about. > I don't know a lot of OSGi, but is it possible with this library to load > plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of your > program or to offer additional features) > > This would be great for SpringRC and then my vote will be pro OSGi ;-) > > Regards, > Peter. > > > ------------------------------------------------------------------------- > 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/com munity/cca08 > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > ------------------------------------------------------------------------- > 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 > > |
|
From: Larry S. <lst...@au...> - 2008-07-07 16:46:00
|
Hi Everyone, It's been a long time since I've participated, so hopefully my viewpoints won't be too dated :-) IOn the issue of OSGi, I would argue along the lines of Jim Moore - do it later when we find a pressing need that can't be solved without it, and work to cleanly modularize our codebase to ensure no cyclic dependencies etc. To Kevin's question about the decision to not use DI for the core services (and to use a service locator pattern instead), the main reason that it came about was due to the massive amount of XML that would be required to inject the desired services into every object. Additionally, the number of dynamic objects that need access to platform services can be huge, and there was no good way to get the quickly wired in. You either had to resort to intermediate factories that could be DI'd and have the factories wire in the services (and that required extra interfaces on the created objects to accept the injection), or invent some other similar scenario to get the services into the dynamic objects. I'm still of the opinion that a service locator singleton (with a pluggable implementation) provides benefits and doesn't require the complexity of having to have a declarative model that knows about every single kind of object that might come into existence during the life of the application. But, I'm always ready to be educated out of any antiquated notions I may hold if someone can show me how the wiring of dynamic objects can be handled in a simple way (very little XML and minimal biolerplate). Learning curve and the amount of XML you have to write in order to get your application running were two significant factors we faced with the adoption of Spring RCP. I personally feel that requiring new app developers to learn yet another complex piece of machinery (OSGi) in addition to all the rest of Spring Rich (which is significant by itself) would not be beneficial to the project's uptake. Just my $.02 worth - boy, I hate how the current economy makes my opinions worth less each month :-) Thanks, Larry. Kevin Day wrote: > Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's > Equinox project is the baseline OSGi implementation). > > From my perspective, I don't think that OSGi is necessarily > appropriate for a lot of GUI apps (although I do think it probably has > more applicability than we might give it credit - even a simple music > player could benefit greatly from a pluggable codec system). From my > perspective, the *module* approach is the important thing. And if we > are going to do modules, we might as well do something that is at > least upwards compatible with OSGi. Certainly, the full OSGi > functionality is not necessary for most apps - I actually a think a > very small subset would be appropriate - and this sub-set could be run > inside AND outside an OSGi container with a little bit of Spring DI magic. > > Here's the basic premise: Because OSGi supports dynamic loading and > unloading of modules, they have been forced to address the issue of > dynamic dependency management. The core result is that modules do > *not* interact directly with each other. Instead, they either locate > other modules (using a service locator type pattern), or they have > those modules injected (using the whiteboard pattern). Time has shown > that the dynamic dependency injection pattern is more reliable, easier > to test and results in more flexible systems (allowing modules to be > dynamically loaded and unloaded without impacting the operation of the > application). In dynamic environments, it also makes service > consumers much, much simpler to write (there is almost no boilerplate > code - this is all refactored up into the framework). > > Most importantly, modularity forces better design practices overall. > There are absolutely cases where functionality is so closely tied > together that it will always reside in the same module - but I suspect > that a lot of that sort of thing is occuring in the current code base > because of the use of service locator type patterns instead of > dependency injection (could be wrong on that, and I certainly don't > want to step on any toes - but sometimes it's healthy to have an > outsider question a design decision :-) ). > > > This actually raises an interesting question that I hope someone with > a deeper history in the Spring-RCP project can answer: How did the > original decision to depart from Spring IOC/DI come about in the RCP > project? Was it b/c of objection of creating and maintaining tons of > Spring xml files, or was there some other reason? I think that maybe > by understanding this, we may learn many of the things that need to be > considered as we have the current discussion. It's super easy to set > back at the end of years of development and question design decisions > that were made early on - and in doing so, it's easy to miss some > extremely important detail that went into the decision. > > - K > |
|
From: Kevin D. <ke...@tr...> - 2008-07-07 16:15:09
|
<!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>Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox project is the baseline OSGi implementation).</DIV>
<DIV> </DIV>
<DIV>From my perspective, I don't think that OSGi is necessarily appropriate for a lot of GUI apps (although I do think it probably has more applicability than we might give it credit - even a simple music player could benefit greatly from a pluggable codec system). From my perspective, the *module* approach is the important thing. And if we are going to do modules, we might as well do something that is at least upwards compatible with OSGi. Certainly, the full OSGi functionality is not necessary for most apps - I actually a think a very small subset would be appropriate - and this sub-set could be run inside AND outside an OSGi container with a little bit of Spring DI magic.</DIV>
<DIV> </DIV>
<DIV>Here's the basic premise: Because OSGi supports dynamic loading and unloading of modules, they have been forced to address the issue of dynamic dependency management. The core result is that modules do *not* interact directly with each other. Instead, they either locate other modules (using a service locator type pattern), or they have those modules injected (using the whiteboard pattern). Time has shown that the dynamic dependency injection pattern is more reliable, easier to test and results in more flexible systems (allowing modules to be dynamically loaded and unloaded without impacting the operation of the application). In dynamic environments, it also makes service consumers much, much simpler to write (there is almost no boilerplate code - this is all refactored up into the framework).</DIV>
<DIV> </DIV>
<DIV>Most importantly, modularity forces better design practices overall. There are absolutely cases where functionality is so closely tied together that it will always reside in the same module - but I suspect that a lot of that sort of thing is occuring in the current code base because of the use of service locator type patterns instead of dependency injection (could be wrong on that, and I certainly don't want to step on any toes - but sometimes it's healthy to have an outsider question a design decision :-) ).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>This actually raises an interesting question that I hope someone with a deeper history in the Spring-RCP project can answer: How did the original decision to depart from Spring IOC/DI come about in the RCP project? Was it b/c of objection of creating and maintaining tons of Spring xml files, or was there some other reason? I think that maybe by understanding this, we may learn many of the things that need to be considered as we have the current discussion. It's super easy to set back at the end of years of development and question design decisions that were made early on - and in doing so, it's easy to miss some extremely important detail that went into the decision.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Peter Karich <A href="mailto:pe...@ya..."><FONT color=#0000ff><pe...@ya...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Fri, 04 Jul 2008 22:22:50 +0200</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion</U></B></DIV>
<DIV> </DIV></DIV><FONT face=Tahoma size=2>
<DIV>Hi Lieven,<BR><BR>like you, I think that almost all people will use springRC as one bundle.<BR>So it could be that no splitting is necessary (only the traditional way <BR>of jar bundles of course)<BR>But maybe I missed the point you are talking about.<BR>I don't know a lot of OSGi, but is it possible with this library to load <BR>plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of your <BR>program or to offer additional features)<BR><BR>This would be great for SpringRC and then my vote will be pro OSGi ;-)<BR><BR>Regards,<BR>Peter.<BR><BR><BR>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at <A href="http://www.sourceforge.net/community/cca08"><FONT color=#0000ff>http://www.sourceforge.net/com
munity/cca08</FONT></A><BR>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR><A href="mailto:Spr...@li..."><FONT color=#0000ff>Spr...@li...</FONT></A><BR><A href="https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev</FONT></A><BR><BR></DIV></FONT></BODY></HTML>
|
|
From: Lieven D. <lie...@ji...> - 2008-07-07 12:45:21
|
Hi Jim, My thoughts exactly... Basics should go before any other 'convenient stuff', and I'm totally for your approach. I'd really like to see Spring Desktop using some modular design like OSGi, but we can always do it later if we design the way it should, and when more of us have seen OSGi in action and have gotten familiar with the tech. I hope with your post we can put an end to the pro-OSGi vs. doubtful-OSGi camp. As it looks, it's the best of both worlds. Now, let's start focussing on the basics :). Regards, Lieven > ---------------------------------------------------------------------- > --- > 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 |
|
From: Jim M. <moo...@gm...> - 2008-07-07 12:37:34
|
Short summary of the modularity discussion... First premise: Modularity is good. Second premise: OSGi help with modularity. Therefore Spring Desktop needs modularity from a "good design" standpoint, but it's debatable the extent of the benefits OSGi would give relative to the additional complexity (technical and conceptual). There's no reason to over-burden either development of the framework, or what people have to learn to use it. The beautiful thing about Spring DM for the end-user is that it lets you develop your application as a "normal Spring app" (ie, using DI) and not worry about if it's running in an SE or OSGi environment. If they know and want to use OSGi, then they create and consume bundles as normal Spring app-contexts with additional meta-data, otherwise they simply do things the "old" way. On the framework side, as long as we do good, disciplined design (e.g., highly cohesive packages with absolutely no cycles between them, no static singletons, etc) then there's nothing that would prevent us from going for the traditional library modularity approach we all know and love, then upgrade to OSGi when we're feeling more comfortable with the technology. At first, no OSGi. Later someone can start maintaining the OSGi meta-data so end-users that want to use Spring Desktop in an OSGi environment can do so easily. Then, after we've seen/experienced exactly how the technology is being used, we can start adding the cool features of OSGi for those that want to take advantage of them. (This is the path that all the core Spring libraries are taking.) We should go for the simplest solution first, which in this case is a highly modular library (at the package level, not necessarily the src code level) with no OSGi use. When we get to things people are begging for that can't be done except with OSGi, we'll start doing so. But let's get the basics in there first. :-) -Jim Moore |
|
From: Jim M. <moo...@gm...> - 2008-07-07 12:35:13
|
1) The principle reason for the ApplicaionServices singleton was for substantial convenience. For example, creating something like a wizard dialog means calling "new" on it, so it's not coming from Spring, and doing all the DI on it manually could be cumbersome (especially since the calling object would need to know everything that it would need to pass in and get that DIed first). Fortunately, this is not difficult to solve: Spring MVC has the same kinds of issues and solves it very cleanly, if you're familiar with the patterns there. 2) Agreed, but let's go for the "this solves an immediate need" modularity stuff first. 3) Great idea. On Sun, Jul 6, 2008 at 10:38 AM, Arne Limburg <Arn...@ar...> wrote: > Hi to all, > > 1. Of course Lieven is right that we should not use OSGi, if we just > want to remove our service locator singleton. > I wonder why we couldn't simply remove the service locator and directly > inject the needed services to the needing beans?! > > 2. There are at least three use-cases where Spring-Desktop could benefit > from OSGi: > a) OSGi provides a mechanism that could be used to dynamically plug in > business modules into a Spring-Desktop-Application. Spring-Deskop should > provide a mechanism to add and remove menu or toolbar entries > dynamically on startup or shutdown of these business bundles (i.e. > entries in the "New"-submenu. The bundles could register Actions as OSGi > Services. And the menus must be aware of that. > b) OSGi service-resolution may be used to dynamically switch > implementations of the application-services. We could provide a bundle > with default-implementations and if needed someone could register a > bundle with a higher ranking, forcing to use his implementation. > c) With OSGi we could provied an update-mechanism to update parts of the > application without needing to restart it. > > 3. Besides the OSGi debate Spring-Desktop should definitely provide a > Spring bean-scope "window" to be able to configure commands in the > normal application-context (if needed with scope "window") and get rid > of the separate commans-context. > > Regards, > Arne > |
|
From: Rogan D. <li...@da...> - 2008-07-07 12:33:31
|
Lieven Doclo wrote: > Hello Peter, > > Indeed, plugin functionality would be great. But I still don't know whether > OSGi is the way to go there... Perhaps we can find a more KISS method to > do this... > > This weekend I did some research and I've looked at the current applications > of OSGi and where it might fit into Spring Desktop. The main problem I would > have with using OSGi in Spring Desktop's main architecture (for whatever > reason) is that I would not want a user to be obligated to use OSGi just > to create a straight-forward application. The advantages are also clear (better > incremental development, upgrade parts of your app on the fly,...), but don't > outweigh my doubts at the moment. > > If someone can show me an example where a framework uses OSGi transparently > (the user doesn't know OSGi is used and isn't obligated to use OSGi when > he uses the framework), I'm all ears. But I don't think this is possible. > One way or another, OSGi will pop his head up and bother the average Joe > programmer who just wants to make his address book in Spring Desktop... What > I want to say here, it's great to consider enterprise level features such > as OSGi (and features like that should be considered and eventually foreseen), > but when you're burdening the smaller applications with these features you'll > lose a lot of the current RCP users... > > Greetz, > > Lieven I don't think that there necessarily has to be a huge amount of dependency on OSGi to allow Spring Desktop to support it. With reference to the current SRCP, it seems to me that there would need to be a certain amount of OSGi-aware classes that would allow for modules to appear and disappear, but that the core would not necessarily need rewriting. e.g. there would need to be a different way of managing commands/actions, than the current commands-context.xml. So, an equivalent, but OSGi-aware implementation might allow for actions to be registered and deregistered. If the app designer wants to use OSGi, choose the OSGi-aware implementations of classes, much like we have a variety of ApplicationPageFactories supporting SDI/MDI interfaces currently. Rogan |
|
From: Jim M. <jim...@sp...> - 2008-07-07 12:20:36
|
Short summary of the modularity discussion... First premise: Modularity is good. Second premise: OSGi help with modularity. Therefore Spring Desktop needs modularity from a "good design" standpoint, but it's debatable the extent of the benefits OSGi would give relative to the additional complexity (technical and conceptual). There's no reason to over-burden either development of the framework, or what people have to learn to use it. The beautiful thing about Spring DM for the end-user is that it lets you develop your application as a "normal Spring app" (ie, using DI) and not worry about if it's running in an SE or OSGi environment. If they know and want to use OSGi, then they create and consume bundles as normal Spring app-contexts with additional meta-data, otherwise they simply do things the "old" way. On the framework side, as long as we do good, disciplined design (e.g., highly cohesive packages with absolutely no cycles between them, no static singletons, etc) then there's nothing that would prevent us from going for the traditional library modularity approach we all know and love, then upgrade to OSGi when we're feeling more comfortable with the technology. At first, no OSGi. Later someone can start maintaining the OSGi meta-data so end-users that want to use Spring Desktop in an OSGi environment can do so easily. Then, after we've seen/experienced exactly how the technology is being used, we can start adding the cool features of OSGi for those that want to take advantage of them. (This is the path that all the core Spring libraries are taking.) We should go for the simplest solution first, which in this case is a highly modular library (at the package level, not necessarily the src code level) with no OSGi use. When we get to things people are begging for that can't be done except with OSGi, we'll start doing so. But let's get the basics in there first. :-) -Jim Moore |
|
From: Lieven D. <lie...@ji...> - 2008-07-07 11:06:25
|
Hello Peter, Indeed, plugin functionality would be great. But I still don't know whether OSGi is the way to go there... Perhaps we can find a more KISS method to do this... This weekend I did some research and I've looked at the current applications of OSGi and where it might fit into Spring Desktop. The main problem I would have with using OSGi in Spring Desktop's main architecture (for whatever reason) is that I would not want a user to be obligated to use OSGi just to create a straight-forward application. The advantages are also clear (better incremental development, upgrade parts of your app on the fly,...), but don't outweigh my doubts at the moment. If someone can show me an example where a framework uses OSGi transparently (the user doesn't know OSGi is used and isn't obligated to use OSGi when he uses the framework), I'm all ears. But I don't think this is possible. One way or another, OSGi will pop his head up and bother the average Joe programmer who just wants to make his address book in Spring Desktop... What I want to say here, it's great to consider enterprise level features such as OSGi (and features like that should be considered and eventually foreseen), but when you're burdening the smaller applications with these features you'll lose a lot of the current RCP users... Greetz, Lieven > Hi Lieven, > > like you, I think that almost all people will use springRC as one > bundle. > So it could be that no splitting is necessary (only the traditional > way > of jar bundles of course) > But maybe I missed the point you are talking about. > I don't know a lot of OSGi, but is it possible with this library to > load > plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of > your > program or to offer additional features) > This would be great for SpringRC and then my vote will be pro OSGi ;-) > > Regards, > Peter. > ---------------------------------------------------------------------- > --- > 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 |
|
From: Arne L. <Arn...@ar...> - 2008-07-06 14:38:38
|
Hi to all, 1. Of course Lieven is right that we should not use OSGi, if we just want to remove our service locator singleton. I wonder why we couldn't simply remove the service locator and directly inject the needed services to the needing beans?! 2. There are at least three use-cases where Spring-Desktop could benefit from OSGi: a) OSGi provides a mechanism that could be used to dynamically plug in business modules into a Spring-Desktop-Application. Spring-Deskop should provide a mechanism to add and remove menu or toolbar entries dynamically on startup or shutdown of these business bundles (i.e. entries in the "New"-submenu. The bundles could register Actions as OSGi Services. And the menus must be aware of that. b) OSGi service-resolution may be used to dynamically switch implementations of the application-services. We could provide a bundle with default-implementations and if needed someone could register a bundle with a higher ranking, forcing to use his implementation. c) With OSGi we could provied an update-mechanism to update parts of the application without needing to restart it. 3. Besides the OSGi debate Spring-Desktop should definitely provide a Spring bean-scope "window" to be able to configure commands in the normal application-context (if needed with scope "window") and get rid of the separate commans-context. Regards, Arne Lieven Doclo schrieb: > An additional point: > > We shouldn't use OSGi and modularize our framework just because it might > solve our service locator singletons problems... That seems like hitting > a fly with a sledgehammer. I'm sure there are more subtle solutions to that > problem... > > Greetings, > > Lieven > > >> Thanks for the input. I'm starting to see the light... >> >> I understand why you would modularize your application and I can see a >> lot of valid usecases in my daily work too. But you're talking on a >> project/finished product level (of which I already said is a great >> platform for OSGi development). I don't see a case for splitting up >> Spring Desktop's architectures into separate bundles... As I see it, >> most of your project's modules will use Spring RCP as a whole >> anyways... That my main concern. I haven't seen a meaningful for >> split-up of Spring Desktop yet (except for the Beans Binding >> framework, and that's a JDK7 feature...). >> >> That's my main point, as I see it, I don't see us using the same >> amount of split-up as Spring RCP 'just because we can'. The more I >> look at it, I'm convinced we should merge some of the modules (as >> stated in my original post). OSGi or Spring DM enabling those merged >> modules, I'm all for that... That way you can use OSGi or Spring DM on >> a project basis but you don't burden framework developers with that... >> >> As I said, I do see modularizing applications as a good thing, but you >> shouldn't modularize your framework used to build those applications >> too much... >> >> I hope you guys get what I'm saying :). >> >> Kind regards, >> >> Lieven >> >> >>> Take for example a business administration application. You might for >>> example have modules for CRM, HR, Finance, Reporting, MIS etc... >>> >>> You might also modularize the application delivery, separating say >>> the basic windowing (SDI/MDI/Docking) from a common application stub >>> and from the application specific components. >>> >>> An application might also be delivered in several forms for varying >>> usage levels: guest, registered users, administrators etc... >>> >>> The rendering of the application might also vary with a rich/thick >>> client in some instances and a thin client in others. >>> >>> You might have mixins or add-ons like client side caching or even >>> off-line use support. >>> >>> I reckon there are lots of cases for modularizing the client and >>> without support for this the reusability of components drops right >>> off! Most enterprise clients may be built as an 'entire module' as >>> you put it, but I would suggest that that is a major problem with how >>> apps are typically built and it places too much responsibility on to >>> the application developer. >>> >>> Luan >>> >>> 2008/7/4 Lieven Doclo <lie...@ji...>: >>> >>> >>>> Hi guys, >>>> >>>> Been reading all the posts here and been comtemplating on OSGi. And >>>> frankly, >>>> as a business application developers, I really don't see the >>>> additional benefit >>>> of a modular system on a GUI level. Perhaps I'm thick, I don't know, >>>> but >>>> I really can't find a reason to provide a modular system on a GUI >>>> framework >>>> system. >>>> Most application I come in contact with don't have a modular design >>>> (actually, that's incorrect, but not in the modular sense we're >>>> talking about here). Enterprise custom-built application don't need >>>> plugin functionality (although it could be handy on a development >>>> level, granted). They almost always see their thick-client gui as a >>>> entire module (in the sense we're talking about here), which might >>>> be >>>> split up in different modules (in the more traditional way, for >>>> development purposes). >>>> Don't get me wrong, I do see OSGi as a good thing, but for clearly >>>> defined concerns (dao, service, webservice, domain (although >>>> disputable, who would want to take down a POJO layer...) and >>>> webstart GUI as a single module)... Using OSGi for GUI just seems >>>> overkill, could anyone give me an example on how he or she would >>>> split up his GUI application, 'cause that would be great. >>>> >>>> Please enlighten me, let me see the OSGi light :). >>>> >>>> Kind regards, >>>> >>>> Lieven >>>> >>>> >>>>> ------------------------------------------------------------------- >>>>> - >>>>> -- >>>>> --- >>>>> 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-de >>>>> v >>>>> >>>> -------------------------------------------------------------------- >>>> - >>>> ---- >>>> 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 >>>> >>> --------------------------------------------------------------------- >>> - >>> --- >>> 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 >>> >> ---------------------------------------------------------------------- >> --- >> 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 >> > > > > > ------------------------------------------------------------------------- > 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 > |
|
From: Wygand H. <epi...@ho...> - 2008-07-06 03:20:34
|
Ahn nyeong, http://www.capedyinlax[IQ]com And hang me to my barn door! Here am i, i say, by some passing doubt her mind is sick for the from the foot of a mountain. stringing that bow upon that son of pandu, of terrible deeds, like alliance with thee. Protected on all sides by to go almeric somewhat embarrassed. Well, i rather in the santi parva. It is difficult to understand that highsouled one like the deities advancing of it. I observed, however, that on this occasion, or the thing blows over after a short or long does love take away dark thoughts, thenor does the consequence of gift? What of righteousness?. |
|
From: Peter K. <pe...@ya...> - 2008-07-04 20:23:37
|
Hi Lieven, like you, I think that almost all people will use springRC as one bundle. So it could be that no splitting is necessary (only the traditional way of jar bundles of course) But maybe I missed the point you are talking about. I don't know a lot of OSGi, but is it possible with this library to load plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of your program or to offer additional features) This would be great for SpringRC and then my vote will be pro OSGi ;-) Regards, Peter. |
|
From: Jonny W. <jwr...@gm...> - 2008-07-04 17:44:22
|
Lieven, I think the others have echoed my main reasons for wanting a modules/plugin system - separation of functionality and delivery of different functionality to different users is one of my main use cases. In terms of the actual framework, I can see where you're coming from as most of the time you'll use everything. However, maybe aspects that could be potentially replaced by another solution should be modularized? For example, the factories for creating pages and windows now have multiple implementations for basic and various docking solutions, but you only need one. I'm sure there's other aspects of the framework that could have drop in replacements. Jonny On Fri, Jul 4, 2008 at 5:03 AM, Lieven Doclo <lie...@ji...> wrote: > Thanks for the input. I'm starting to see the light... > > I understand why you would modularize your application and I can see a lot > of valid usecases in my daily work too. But you're talking on a > project/finished > product level (of which I already said is a great platform for OSGi > development). > I don't see a case for splitting up Spring Desktop's architectures into > separate > bundles... As I see it, most of your project's modules will use Spring RCP > as a whole anyways... That my main concern. I haven't seen a meaningful for > split-up of Spring Desktop yet (except for the Beans Binding framework, and > that's a JDK7 feature...). > > That's my main point, as I see it, I don't see us using the same amount of > split-up as Spring RCP 'just because we can'. The more I look at it, I'm > convinced we should merge some of the modules (as stated in my original > post). > OSGi or Spring DM enabling those merged modules, I'm all for that... That > way you can use OSGi or Spring DM on a project basis but you don't burden > framework developers with that... > > As I said, I do see modularizing applications as a good thing, but you > shouldn't > modularize your framework used to build those applications too much... > > I hope you guys get what I'm saying :). > > Kind regards, > > Lieven > > > > > Take for example a business administration application. You might for > > example have modules for CRM, HR, Finance, Reporting, MIS etc... > > > > You might also modularize the application delivery, separating say the > > basic windowing (SDI/MDI/Docking) from a common application stub and > > from the application specific components. > > > > An application might also be delivered in several forms for varying > > usage levels: guest, registered users, administrators etc... > > > > The rendering of the application might also vary with a rich/thick > > client in some instances and a thin client in others. > > > > You might have mixins or add-ons like client side caching or even > > off-line use support. > > > > I reckon there are lots of cases for modularizing the client and > > without support for this the reusability of components drops right > > off! Most enterprise clients may be built as an 'entire module' as you > > put it, but I would suggest that that is a major problem with how apps > > are typically built and it places too much responsibility on to the > > application developer. > > > > Luan > > > > 2008/7/4 Lieven Doclo <lie...@ji...>: > > > >> Hi guys, > >> > >> Been reading all the posts here and been comtemplating on OSGi. And > >> frankly, > >> as a business application developers, I really don't see the > >> additional benefit > >> of a modular system on a GUI level. Perhaps I'm thick, I don't know, > >> but > >> I really can't find a reason to provide a modular system on a GUI > >> framework > >> system. > >> Most application I come in contact with don't have a modular design > >> (actually, that's incorrect, but not in the modular sense we're > >> talking about here). Enterprise custom-built application don't need > >> plugin functionality (although it could be handy on a development > >> level, granted). They almost always see their thick-client gui as a > >> entire module (in the sense we're talking about here), which might be > >> split up in different modules (in the more traditional way, for > >> development purposes). > >> > >> Don't get me wrong, I do see OSGi as a good thing, but for clearly > >> defined concerns (dao, service, webservice, domain (although > >> disputable, who would want to take down a POJO layer...) and webstart > >> GUI as a single module)... Using OSGi for GUI just seems overkill, > >> could anyone give me an example on how he or she would split up his > >> GUI application, 'cause that would be great. > >> > >> Please enlighten me, let me see the OSGi light :). > >> > >> Kind regards, > >> > >> Lieven > >> > >>> -------------------------------------------------------------------- > >>> -- > >>> --- > >>> 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 > >> --------------------------------------------------------------------- > >> ---- > >> 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 > > ---------------------------------------------------------------------- > > --- > > 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 > > > > > ------------------------------------------------------------------------- > 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 > |
|
From: luano <lua...@gm...> - 2008-07-04 17:42:20
|
That's a fine point IMO given that there is such a wide range of things a desktop application might do and some of the components one might use are not so trivial. Promoting modularity from the ground up would be a good thing in my eyes (depending on the cost of course). But modularity shouldn't be intrusive and if done right a developer should be able to take a bundle of modules and start to build their application without having to do any module configuration - which perhaps is paraphrasing your intent when you say "you shouldn't modularize .. too much". -Luan Lieven Doclo-2 wrote: > > > As I said, I do see modularizing applications as a good thing, but you > shouldn't > modularize your framework used to build those applications too much... > > I hope you guys get what I'm saying :). > > -- View this message in context: http://www.nabble.com/-Spring-Desktop--ideas-for-the-Desktop-version-tp18064778p18283658.html Sent from the springframework-rcp-dev mailing list archive at Nabble.com. |
|
From: Fritz R. <fr...@wo...> - 2008-07-04 14:17:01
|
Hi together, as I've seen in the forum, there was already a patch for using the spring-security. Is it possible to include the patch into the current version of spring- rich-client? Kind regards Fritz |
|
From: Lieven D. <lie...@ji...> - 2008-07-04 12:55:39
|
An additional point: We shouldn't use OSGi and modularize our framework just because it might solve our service locator singletons problems... That seems like hitting a fly with a sledgehammer. I'm sure there are more subtle solutions to that problem... Greetings, Lieven > Thanks for the input. I'm starting to see the light... > > I understand why you would modularize your application and I can see a > lot of valid usecases in my daily work too. But you're talking on a > project/finished product level (of which I already said is a great > platform for OSGi development). I don't see a case for splitting up > Spring Desktop's architectures into separate bundles... As I see it, > most of your project's modules will use Spring RCP as a whole > anyways... That my main concern. I haven't seen a meaningful for > split-up of Spring Desktop yet (except for the Beans Binding > framework, and that's a JDK7 feature...). > > That's my main point, as I see it, I don't see us using the same > amount of split-up as Spring RCP 'just because we can'. The more I > look at it, I'm convinced we should merge some of the modules (as > stated in my original post). OSGi or Spring DM enabling those merged > modules, I'm all for that... That way you can use OSGi or Spring DM on > a project basis but you don't burden framework developers with that... > > As I said, I do see modularizing applications as a good thing, but you > shouldn't modularize your framework used to build those applications > too much... > > I hope you guys get what I'm saying :). > > Kind regards, > > Lieven > >> Take for example a business administration application. You might for >> example have modules for CRM, HR, Finance, Reporting, MIS etc... >> >> You might also modularize the application delivery, separating say >> the basic windowing (SDI/MDI/Docking) from a common application stub >> and from the application specific components. >> >> An application might also be delivered in several forms for varying >> usage levels: guest, registered users, administrators etc... >> >> The rendering of the application might also vary with a rich/thick >> client in some instances and a thin client in others. >> >> You might have mixins or add-ons like client side caching or even >> off-line use support. >> >> I reckon there are lots of cases for modularizing the client and >> without support for this the reusability of components drops right >> off! Most enterprise clients may be built as an 'entire module' as >> you put it, but I would suggest that that is a major problem with how >> apps are typically built and it places too much responsibility on to >> the application developer. >> >> Luan >> >> 2008/7/4 Lieven Doclo <lie...@ji...>: >> >>> Hi guys, >>> >>> Been reading all the posts here and been comtemplating on OSGi. And >>> frankly, >>> as a business application developers, I really don't see the >>> additional benefit >>> of a modular system on a GUI level. Perhaps I'm thick, I don't know, >>> but >>> I really can't find a reason to provide a modular system on a GUI >>> framework >>> system. >>> Most application I come in contact with don't have a modular design >>> (actually, that's incorrect, but not in the modular sense we're >>> talking about here). Enterprise custom-built application don't need >>> plugin functionality (although it could be handy on a development >>> level, granted). They almost always see their thick-client gui as a >>> entire module (in the sense we're talking about here), which might >>> be >>> split up in different modules (in the more traditional way, for >>> development purposes). >>> Don't get me wrong, I do see OSGi as a good thing, but for clearly >>> defined concerns (dao, service, webservice, domain (although >>> disputable, who would want to take down a POJO layer...) and >>> webstart GUI as a single module)... Using OSGi for GUI just seems >>> overkill, could anyone give me an example on how he or she would >>> split up his GUI application, 'cause that would be great. >>> >>> Please enlighten me, let me see the OSGi light :). >>> >>> Kind regards, >>> >>> Lieven >>> >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>> --- >>>> 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-de >>>> v >>> -------------------------------------------------------------------- >>> - >>> ---- >>> 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 >> --------------------------------------------------------------------- >> - >> --- >> 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 > ---------------------------------------------------------------------- > --- > 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 |
|
From: Lieven D. <lie...@ji...> - 2008-07-04 12:04:12
|
Thanks for the input. I'm starting to see the light... I understand why you would modularize your application and I can see a lot of valid usecases in my daily work too. But you're talking on a project/finished product level (of which I already said is a great platform for OSGi development). I don't see a case for splitting up Spring Desktop's architectures into separate bundles... As I see it, most of your project's modules will use Spring RCP as a whole anyways... That my main concern. I haven't seen a meaningful for split-up of Spring Desktop yet (except for the Beans Binding framework, and that's a JDK7 feature...). That's my main point, as I see it, I don't see us using the same amount of split-up as Spring RCP 'just because we can'. The more I look at it, I'm convinced we should merge some of the modules (as stated in my original post). OSGi or Spring DM enabling those merged modules, I'm all for that... That way you can use OSGi or Spring DM on a project basis but you don't burden framework developers with that... As I said, I do see modularizing applications as a good thing, but you shouldn't modularize your framework used to build those applications too much... I hope you guys get what I'm saying :). Kind regards, Lieven > Take for example a business administration application. You might for > example have modules for CRM, HR, Finance, Reporting, MIS etc... > > You might also modularize the application delivery, separating say the > basic windowing (SDI/MDI/Docking) from a common application stub and > from the application specific components. > > An application might also be delivered in several forms for varying > usage levels: guest, registered users, administrators etc... > > The rendering of the application might also vary with a rich/thick > client in some instances and a thin client in others. > > You might have mixins or add-ons like client side caching or even > off-line use support. > > I reckon there are lots of cases for modularizing the client and > without support for this the reusability of components drops right > off! Most enterprise clients may be built as an 'entire module' as you > put it, but I would suggest that that is a major problem with how apps > are typically built and it places too much responsibility on to the > application developer. > > Luan > > 2008/7/4 Lieven Doclo <lie...@ji...>: > >> Hi guys, >> >> Been reading all the posts here and been comtemplating on OSGi. And >> frankly, >> as a business application developers, I really don't see the >> additional benefit >> of a modular system on a GUI level. Perhaps I'm thick, I don't know, >> but >> I really can't find a reason to provide a modular system on a GUI >> framework >> system. >> Most application I come in contact with don't have a modular design >> (actually, that's incorrect, but not in the modular sense we're >> talking about here). Enterprise custom-built application don't need >> plugin functionality (although it could be handy on a development >> level, granted). They almost always see their thick-client gui as a >> entire module (in the sense we're talking about here), which might be >> split up in different modules (in the more traditional way, for >> development purposes). >> >> Don't get me wrong, I do see OSGi as a good thing, but for clearly >> defined concerns (dao, service, webservice, domain (although >> disputable, who would want to take down a POJO layer...) and webstart >> GUI as a single module)... Using OSGi for GUI just seems overkill, >> could anyone give me an example on how he or she would split up his >> GUI application, 'cause that would be great. >> >> Please enlighten me, let me see the OSGi light :). >> >> Kind regards, >> >> Lieven >> >>> -------------------------------------------------------------------- >>> -- >>> --- >>> 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 >> --------------------------------------------------------------------- >> ---- >> 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 > ---------------------------------------------------------------------- > --- > 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 |
|
From: Luan O'C. <lua...@gm...> - 2008-07-04 10:58:27
|
Take for example a business administration application. You might for example have modules for CRM, HR, Finance, Reporting, MIS etc... You might also modularize the application delivery, separating say the basic windowing (SDI/MDI/Docking) from a common application stub and from the application specific components. An application might also be delivered in several forms for varying usage levels: guest, registered users, administrators etc... The rendering of the application might also vary with a rich/thick client in some instances and a thin client in others. You might have mixins or add-ons like client side caching or even off-line use support. I reckon there are lots of cases for modularizing the client and without support for this the reusability of components drops right off! Most enterprise clients may be built as an 'entire module' as you put it, but I would suggest that that is a major problem with how apps are typically built and it places too much responsibility on to the application developer. Luan 2008/7/4 Lieven Doclo <lie...@ji...>: > Hi guys, > > Been reading all the posts here and been comtemplating on OSGi. And frankly, > as a business application developers, I really don't see the additional benefit > of a modular system on a GUI level. Perhaps I'm thick, I don't know, but > I really can't find a reason to provide a modular system on a GUI framework > system. > > Most application I come in contact with don't have a modular design (actually, > that's incorrect, but not in the modular sense we're talking about here). > Enterprise custom-built application don't need plugin functionality (although > it could be handy on a development level, granted). They almost always see > their thick-client gui as a entire module (in the sense we're talking about > here), which might be split up in different modules (in the more traditional > way, for development purposes). > > Don't get me wrong, I do see OSGi as a good thing, but for clearly defined > concerns (dao, service, webservice, domain (although disputable, who would > want to take down a POJO layer...) and webstart GUI as a single module)... > Using OSGi for GUI just seems overkill, could anyone give me an example on > how he or she would split up his GUI application, 'cause that would be great. > > Please enlighten me, let me see the OSGi light :). > > Kind regards, > > Lieven > >> ---------------------------------------------------------------------- >> --- >> 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 > > > > > ------------------------------------------------------------------------- > 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 > |
|
From: Peter De B. <pet...@gm...> - 2008-07-04 10:34:45
|
I think that if possible, we should support OSGI, because it allows for interesting usecases such as: - a debug module, containing a frontend to interrogate the system state (a basic debug module could even be created by us) - splitting modules according to your business domain (we do this on the functional parts -> interfaces for integration points), so why not on ui level?) -> this is what we do in our struts applications also (one struts module per application module) osgi bundles are also great for controlling your dependencies (limit the exported packages to a minimum, so no dependencies on internal stuff) regards, Peter On Fri, Jul 4, 2008 at 12:25 PM, Lieven Doclo <lie...@ji...> wrote: > Hi guys, > > Been reading all the posts here and been comtemplating on OSGi. And > frankly, > as a business application developers, I really don't see the additional > benefit > of a modular system on a GUI level. Perhaps I'm thick, I don't know, but > I really can't find a reason to provide a modular system on a GUI framework > system. > > Most application I come in contact with don't have a modular design > (actually, > that's incorrect, but not in the modular sense we're talking about here). > Enterprise custom-built application don't need plugin functionality > (although > it could be handy on a development level, granted). They almost always see > their thick-client gui as a entire module (in the sense we're talking about > here), which might be split up in different modules (in the more > traditional > way, for development purposes). > > Don't get me wrong, I do see OSGi as a good thing, but for clearly defined > concerns (dao, service, webservice, domain (although disputable, who would > want to take down a POJO layer...) and webstart GUI as a single module)... > Using OSGi for GUI just seems overkill, could anyone give me an example on > how he or she would split up his GUI application, 'cause that would be > great. > > Please enlighten me, let me see the OSGi light :). > > Kind regards, > > Lieven > > > ---------------------------------------------------------------------- > > --- > > 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 > > > > > ------------------------------------------------------------------------- > 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 > |
|
From: Lieven D. <lie...@ji...> - 2008-07-04 10:25:46
|
Hi guys, Been reading all the posts here and been comtemplating on OSGi. And frankly, as a business application developers, I really don't see the additional benefit of a modular system on a GUI level. Perhaps I'm thick, I don't know, but I really can't find a reason to provide a modular system on a GUI framework system. Most application I come in contact with don't have a modular design (actually, that's incorrect, but not in the modular sense we're talking about here). Enterprise custom-built application don't need plugin functionality (although it could be handy on a development level, granted). They almost always see their thick-client gui as a entire module (in the sense we're talking about here), which might be split up in different modules (in the more traditional way, for development purposes). Don't get me wrong, I do see OSGi as a good thing, but for clearly defined concerns (dao, service, webservice, domain (although disputable, who would want to take down a POJO layer...) and webstart GUI as a single module)... Using OSGi for GUI just seems overkill, could anyone give me an example on how he or she would split up his GUI application, 'cause that would be great. Please enlighten me, let me see the OSGi light :). Kind regards, Lieven > ---------------------------------------------------------------------- > --- > 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 |
|
From: Jim M. <moo...@gm...> - 2008-07-03 02:25:27
|
Kevin, could you please give an example of how we can get rid of the ApplicationServices singleton with the whiteboard pattern allows access to capabilities such as ApplicationObjectConfigurer or RulesSource? (Using the ApplicationContext as the container in lieu of OSGi.) It's not clear to me how that would work. On Wed, Jul 2, 2008 at 1:14 PM, Kevin Day <ke...@tr...> wrote: > BTW - the email archive for this list seems to be dead as of 6/17/08: > http://sourceforge.net/mailarchive/forum.php?forum_name=springframework-rcp-dev - > is something going on? > > > I completely agree on the comments re: modules. > > This is still a rough idea, but I'm thinking that while many apps have no > need for per-module class loaders, hot swappable modules, module life cycle > management, etc... there is still a big advantage from a coding practices > perspective of using modules (JRE 7 is probably going to be introducing > module as a scoping feature). In these types of apps, the only OSGi-type > event that would need to be fired is ServiceEvent.REGISTERED - and this > would all happen at startup (i.e. at the time of dependency injection). > > Maybe there is a way to introduce the module concept, and do it in such a > way that apps that *want* to run in an OSGi container can do so by just > ensuring they have the correct entries in their jar manifests (and using > SpringDM). > > This places a requirement that the Desktop framework be designed in a > manner compatible with SpringDM (keeping sub-systems modularized, not use > global service lookups if at all possible, and possibly add required info to > the jar manifests for apps that do need to run in an OSGi container). > > Interestingly, one of the tenets of the whiteboard pattern is that objects > that are traditionally thought of as services are actually not registered as > global services. Instead, the listeners of those services are registered as > services. As listener objects are registered with the container, the > service is notified about their presence and adds the listener to itself > (instead of the more traditional approach of having the listener look up the > service, and call addListener() ). This, I think, makes a strong case for > not using global service lookup in the traditional sense. > > > Given the above, I wonder if the module break out of the Desktop project > should be aligned along functional lines (and possibly divided with modules > for interface, implementation and possibly GUI). I could see having > separate packages for jdk6 specific stuff (maybe), but a totally separate > module seems to cut across concerns in an odd way. > > - K > > |
|
From: Arne L. <Arn...@ar...> - 2008-07-02 19:00:02
|
Hi Peter, Hi Lieven, I've provided integration for Swing-Docking at http://jira.springframework.org/browse/RCP-561 Regards, Arne Peter Karich schrieb: > 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 > > > ------------------------------------------------------------------------- > 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 > |
|
From: Kevin D. <ke...@tr...> - 2008-07-02 17:14:20
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2> <DIV>BTW - the email archive for this list seems to be dead as of 6/17/08: <A href="http://sourceforge.net/mailarchive/forum.php?forum_name=springframework-rcp-dev">http://sourceforge.net/mailarchive/forum.php?forum_name=springframework-rcp-dev</A> - is something going on?</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>I completely agree on the comments re: modules.</DIV> <DIV> </DIV> <DIV>This is still a rough idea, but I'm thinking that while many apps have no need for per-module class loaders, hot swappable modules, module life cycle management, etc... there is still a big advantage from a coding practices perspective of using modules (JRE 7 is probably going to be introducing module as a scoping feature). In these types of apps, the only OSGi-type event that would need to be fired is ServiceEvent.REGISTERED - and this would all happen at startup (i.e. at the time of dependency injection).</DIV> <DIV> </DIV> <DIV>Maybe there is a way to introduce the module concept, and do it in such a way that apps that *want* to run in an OSGi container can do so by just ensuring they have the correct entries in their jar manifests (and using SpringDM).</DIV> <DIV> </DIV> <DIV>This places a requirement that the Desktop framework be designed in a manner compatible with SpringDM (keeping sub-systems modularized, not use global service lookups if at all possible, and possibly add required info to the jar manifests for apps that do need to run in an OSGi container).</DIV> <DIV> </DIV> <DIV>Interestingly, one of the tenets of the whiteboard pattern is that objects that are traditionally thought of as services are actually not registered as global services. Instead, the listeners of those services are registered as services. As listener objects are registered with the container, the service is notified about their presence and adds the listener to itself (instead of the more traditional approach of having the listener look up the service, and call addListener() ). This, I think, makes a strong case for not using global service lookup in the traditional sense.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>Given the above, I wonder if the module break out of the Desktop project should be aligned along functional lines (and possibly divided with modules for interface, implementation and possibly GUI). I could see having separate packages for jdk6 specific stuff (maybe), but a totally separate module seems to cut across concerns in an odd way.</DIV> <DIV> </DIV> <DIV>- K<BR></DIV> <DIV> </DIV></FONT> <DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma"> <DIV>----------------------- <B>Original Message</B> -----------------------</DIV> <DIV> </DIV> <DIV><B>From:</B> "Jim Moore" <A href="mailto:moo...@gm..."><FONT color=#0000ff><moo...@gm...></FONT></A></DIV> <DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV> <DIV><B>Cc:</B> </DIV> <DIV><B>Date:</B> Tue, 1 Jul 2008 23:20:43 -0400</DIV> <DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version</U></B></DIV> <DIV> </DIV></DIV>Heya, everyone. Sorry for jumping into this discussion late.<BR><BR>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.<BR><BR>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.)<BR><BR>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 Sp ringSource Application Platform (S2AP), for example.<BR><BR>I love the idea of new XML configuration. A couple of comments on the examples:<BR><BR><bean id="someBean" class="foobar"><BR> <property name="prefs"><BR> <desktop:prefs scope="user|system" path="path/to/preferences/node"/><BR> </property><BR></bean><BR><BR>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.<BR><BR><desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView"><BR> <property name="someService" ref="serviceId"/><BR></desktop:view ><BR><BR><desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView" mdi:closable="true" mdi:resizable="false"><BR> <property name="someService" ref="serviceId"/><BR></desktop:view><BR><BR><desktop:view id="yetAnotherView" viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false" docking:draggable="true"><BR> <property name="someService" ref="serviceId"/><BR></desktop:view><BR><BR>In Spring 2.5 ADI style that might be done as<BR><BR><context:component-scan package="com.myco"/><BR><BR>@View<BR>public class SomeView {<BR> @Autowired SomeView(SomeService someService) {..}<BR>}<BR><BR>@View<BR>@MdiConfiguration(closable=true, resizable=false)<BR>public class OtherView {<BR> @Autowired OtherView(SomeService someService) {..}<BR>}<BR><BR>@View<BR>@DockingConfiguration(closable=false, draggable=false)<BR>public class YetAnotherView {<BR> @Autowired YetAnotherView(So meService someService) {..}<BR>}<BR><BR><BR>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.<BR><BR>-Jim Moore<BR> Senior Consultant, SpringSource<BR><BR> <STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE> <FONT face=Tahoma size=2> <DIV>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at http://www.sourceforge.net/community/cca08<BR><BR></DIV></FONT> <STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE> <FONT face=Tahoma size=2> <DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML> |
|
From: Jim M. <moo...@gm...> - 2008-07-02 13:41:24
|
There's already an area created for our use at https://src.springframework.org/svn/spring-desktop Jan, Peter and Lieven, send me your usernames and encrypted pws (via htpasswd) and I'll make sure you have write perms. On Wed, Jul 2, 2008 at 1:27 AM, Peter De Bruycker < pet...@gm...> wrote: > 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. > |
406 messages has been excluded from this view by a project administrator.
