Re: [Springframework-developer] Spring sub-projects

[Keith D. <kd...@cs...>]

I'm fine with 'spring-rich-client' as the module name... the main reason =
I
suggested 'spring-rcp' initially was to be consistent with the proposed
package name: org.springframework.rcp (to me org.springframework.richclie=
nt
seemed a little wordy.)

'rcp' also seems to be a buzzing acronym these days, not that I am big in=
to
buzzwords or anything (although  I do have a business degree. :-)) Keith

----- Original Message -----=20
From: "Kopylenko, Dmitry" <dko...@su...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 8:09 AM
Subject: RE: [Springframework-developer] Spring sub-projects


> Well, spring-rcp is a bit cryptic. How about spring-rich-client?
>
> -----Original Message-----
> From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
> Sent: Tuesday, February 17, 2004 8:04 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Spring sub-projects
>
>
> Any opinions regarding the new module names? Else, I'll create
"spring-rcp"
> and "spring-eclipse" in the course of this week.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf=
 Of
> j=FCrgen h=F6ller [werk3AT]
> Sent: Monday, February 16, 2004 9:59 AM
> To: spr...@li...
> Subject: [Springframework-developer] Spring sub-projects
>
>
> Everybody,
>
> As recently discussed in private mails, I suggest to keep sub-projects
that
> are close to the Spring core as separate modules in Spring's main CVS. =
The
> first two candidates are:
>
> - Keith Donald's Spring Rich Client Platform
> - Torsten Juergeleit's Spring Eclipse Plugin
>
> Both Keith and Torsten are in favor of hosting them in our main CVS. So=
 if
> noone objects, I will create new CVS modules "spring-rcp" and
> "spring-eclipse", and accordingly give Keith and Torsten commit rights =
for
> the main CVS. As the module names cannot be changed easily, feel free t=
o
> suggest different names!
>
> The rationale is to keep all projects that use "org.springframework" as
> package name in Spring's main CVS. Separate modules make sense to let t=
he
> sub-projects evolve independently; this way, they do not have to be
released
> in direct accordance with the Spring core. Of course, generic classes t=
hat
> emerge can still go into the core.
>
> Consequently, both sub-projects should also get respective sections on =
our
> main website. We should definitely clarify all this before 1.0 final
(March
> 1st), as I expect quite a lot of media coverage at that time - we
shouldn't
> miss that chance!
>
> Juergen
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer