RE: [stellation-res] Svcadmin

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Fri, 2003-01-03 at 03:26, Jonathan Gossage wrote: 
> > >--Original Message--
> > >From: stellation-res-admin@xxxxxxxxxxxxxxx
> > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> > >Chu-Carroll
> > >Sent: January 2, 2003 2:42 PM
> > >To: Stellation-res
> > >Subject: Re: [stellation-res] Svcadmin
> > >
> > >
> > >On Fri, 2003-01-03 at 00:29, Jonathan Gossage wrote:
> > >> It was mentioned recently that we are going to want to install Svcadmin
> > >> independently of other Stellation components. If this is the
> > >case should the
> > >> Svcadmin classes be moved into a package of their own with an
> > >independent
> > >> Eclipse project?
> > >
> > >I don't think so. There's just not enough to it for it to make sense
> > >creating another project. Really, svcadmin is *one* source file, which
> > >calls a few things from other places. There's just not enough there to
> > >justify a separate package. I think it's fine with the CLI stuff; when
> > >we put together a nice installer, we can provide options for whether or
> > >not to install svcadmin.
> > >
> > >	-Mark
> > >
> 
> However, if you fold the database configuration stuff I proposed, it will
> get a bit larger. Also, independent packaging makes for lower coupling
> between sub-systems. I don't feel that the number of classes is a necessary
> determinant for package partitioning.

I don't object to the package separation; it's the idea of introducing
yet another project, for a very small suite that's part of the set of
command-line tools. It gets awkward dealing with lots of projects in
Eclipse, when each one gets versioned individually. Maintaining a notion
of consistency between versions of different packages becomes difficult.

This is actually going to become worse, not better, as we transition
into Stellation, because we don't have subproject support in Stellation
yet. So the distinct plugins will be distinct projects, and we don't
have any equivalent of a "tag" that applies across projects. (We never
built that, because our intention is to support versioned subprojects,
and then everything that a tag that can cross projects does gets
subsumed by the notion of the enclosing project.)

I did forget about the expansion that's going to go on to support
the database configuration stuff. And that does create a new
configuration/naming component which crosses a lot of boundaries: it'll
be used by the command line, the remote-access, and the Eclipse client. 
So it probably does make sense for their to be a new project for it. I'm
just worried about overproliferating, so I feel obligated to play devils
advocate against more subprojects.

If no one else objects, then I'd say go ahead and make that separation
when you add your database configuration code.

	-Mark


-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  -- Personal Email: markcc@xxxxxxxxxxx