> -----Original Message-----
> From: Steve Downey [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 17, 2002 3:07 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Proposal] Scamp: Source Control Abstraction
>
>
> I think it's a great idea. There's a lot of commonality
> between the various
> SCM systems, from the client point of view. There's just one thing.
>
> Could it have a less interesting name?
It probably could, and probably should. The Commons guidelines say:
"The packages should have boring functional names. Implementations may
choose more 'exciting' designations."
Of course, it's not always easy to come up with an appropriate short and
boring name... ;-)
--
Martin Cooper
>
> When looking through commons, I think we need more names like
> cli, discovery,
> collections and logging.
>
> Trying to figure out what betwixt, latka, and jelly do is a
> challenge. And
> that's a barrier to entry that isn't good in a library code
> repository.
>
> Just my $0.02.
>
>
> On Tuesday 17 September 2002 01:53 pm, Weber, Lance wrote:
> > Following some interesting discussions on the Maven list,
> I'd like to
> > propose starting an SCM abstraction project, tentatively
> named Scamp.
> >
> > Proposed Goal:
> > Scamp is a Source Control Manager abstraction layer. It
> provides a standard
> > interface to SCM systems allowing common source control
> operations such as
> > checkin/checkout, labelling/tagging, reading changelogs and diffs.
> >
> > Initial design goals:
> > -- expose a stable SCM interface contract for consuming applications
> > (Maven, Ant, etc).
> > -- provide extensible infrastructure for specific SCM
> implementations.
> > -- configuration driven implementations
> > -- file system independent
> > -- supports multiple projects, multiple/distributed source providers
> >
> > Architecture:
> > My initial thoughts are to utilize a combination of
> AbstractSCMFactory and
> > a SourceControlManager interface with concrete
> implementations of both. We
> > might possible need some secondary classes representing projects,
> > connections, and filesystems, but I'm not sure on those yet.
> >
> > 0.1 Release Goals/Requirements:
> > -- First version of SCM Interface, focused on primary/core
> SCM operations
> > -- AbstractSCMFactory
> > -- Stubbed concrete factories for cvs/vss/vfs?
> > -- exception infrastructure
> >
> > Any thoughts, feedback, requirements, design, existing code
> pointers, etc
> > very welcome. Potential participants more than welcome!!
> >
> > Thanks, Lance
> >
> >
> > Lance Weber
> > Chief Architect
> > CareEnhance Services & Systems
> > McKesson Health Solutions
> >
> >
> >
> >
> >
> >
> ______________________________________________________________
> _____________
> > CONFIDENTIALITY NOTICE: This e-mail message, including any
> attachments, is
> > for the sole use of the intended recipient(s) and may
> contain confidential
> > and privileged information. Any unauthorized review, use,
> disclosure or
> > distribution is prohibited. If you are not the intended
> recipient, please
> > contact the sender by reply e-mail and destroy all copies
> of the original
> > message.
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
