Re: [Springframework-developer] spring modules/spring projects/spring extensions

[Alexandru P. <apo...@ez...>]

From my user point of view - with Spring CVS daily updates though (pls le=
t me know if the discussion
is only between Spring developers) the current Spring codebase organizati=
on seems quite nice. I have
read before the discussion about different artifacts, and again imo the c=
urrent distro seems to me
the most appropriate.

I second Juergen when saying that a single sourcebase is much easier to m=
anage with a `smart=B4 build.

sorry if this is supposed to be developer inhouse discussion,
:alex |.::the_mindstorm::.|


#: by Juergen Hoeller's words the mind was *winged* :#
> I believe that the most important separation at this point of time is
> between different distributions. Each distribution needs to have its ow=
n
> part of the repository, for administration reasons. A distribution
> corresponds more to a project than a module, so "spring-projects" is no=
t
> inappropriate, IMO.
>=20
> Whether we go more fine-granular and create separate modules in the
> repository even for parts of a distribution is still undecided for me. =
There
> is arguably no strong need to do this, at least not at this point of ti=
me -
> in contrast to the separate distributions (Web Flow etc), where we
> absolutely _need_ a separation in the repository.
>=20
> As I already indicated earlier, I'm not a great fan of fine-granular so=
urce
> repositories in general. I tend to prefer a single unified codebase _pe=
r
> distribution_, with a simple and straightforward build, rather than a d=
ozen
> module source trees in my IDE project tree. This has proven to work up =
to
> now, so I wouldn't mind continuing down that road.
>=20
> In my opinion, our real problem was the sandbox, which was used for cod=
e
> that was supposed to end up in separate distributions. The sandbox shou=
ld
> really only be used for stuff that's supposed to end up in the Spring c=
ore
> distribution. That problem has been addressed already through factoring=
 out
> Web Flow and co, so I don't see a strong need to do any further splitti=
ng.
>=20
> Of course, if we decide to do further splits _at the distribution level=
_, a
> need for further splitting of the CVS repository would arise. However, =
there
> are currently no concrete plans to do so...
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Colin Sampaleanu
> Sent: Sunday, June 19, 2005 10:01 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] spring modules/spring
> projects/spring extensions
>=20
>=20
> Keith Donald wrote:
>=20
>> We need to reach a consensus on what to call our *core* =93spring
>> modules=94 repository here at sourceforge and the *extension *=93sprin=
g
>> modules=94 repository over at java.net.
>>
>> Right now we=92re calling the core stuff =93spring projects=94 =96 but=
 I=92m not
>> sure about that usage, =93modules=94 seems like such a better name=85
>>
>> However, having two =93spring modules=94 is obviously confusing.
>>
>> What about calling the core modules =93spring modules=94 and the work
>> happening over at java.net =93spring extensions=94? That seems like an
>> ideal situation. What do you think? Rob? Colin? Juergen? Would it be
>> possible to rename the java.net effort or is it too late for that?
>>
> Well, I have to agree with your suggestion; that's why I gave the
> original CVS module the name spring-modules, despite the java.net
> project having the same name. The name just seems best suited for the
> modules that make up Spring itself, whereas what's at java.net is more
> extensions, integrations, or related projects.
>=20
> Obviously our CVS can go either way. Right now there is both
> spring-modules and spring-projects in it (the former was going to be
> pruned, while the latter has the most current code). I just don't know
> how much work it'd be for somebody (Rob I guess since he's admin there)
> to change the java.net project, and how in agreement he is to make a
> change there. Ultimately I don't feel like a big argument over a name..=
.
>=20
> Colin
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20