[sakai-pmc] Dec 5 deadline - Re: [cle-release-team] Proposal: Retiring the old ArchiveServiceImpl

[Neal Caidin]

Reminder for folks.

See below. 


Neal Caidin
Sakai Community Coordinator
neal.caidin at apereo.org
Skype: nealkdin
Twitter: ncaidin









On Nov 27, 2013, at 10:17 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:

> Ok, extended until Thursday December 5th.
> 
> 
> On Thu, Nov 28, 2013 at 1:29 AM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
> I agree with this but I think the timing here is problematic. Most
> people in the US will not even see this note until after the
> expiration date because of the thanksgiving holiday. My objection
> therefore is on the date.
> 
> Extend it to Thursday Dec 5th instead so there are a few days for
> people to review it. I doubt anyone will disagree but we should
> generally provide enough time for feedback.
> 
> -AZ
> 
> 
> On Wed, Nov 27, 2013 at 6:56 AM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
> > Hi all,
> >
> > As some of you may be aware, there currently exists two implementations of
> > the ArchiveService API within the common/archive-impl module. The first
> > (BasicArchiveService) was disabled some time ago and remains for historical
> > purposes. The second (ArchiveService2Impl) is the one that is turned on by
> > default and features a pluggable architecture as well as better
> > configuration.
> >
> > From the README in common:
> >
> > "ArchiveService2Impl allows you to customize which entities are imported
> > during the merge process. Previously, the list of allowable services was
> > Hardcoded in the Service itself. All other behaviour, as well as the API,
> > are the same."
> >
> > The new code is identical to the old code but is laid out better, plus as
> > mentioned, it is configurable via Spring rather than hardcoded within the
> > class itself. This means that newer tools like Lessons have been abled to
> > leverage the archive capabilities of the new implementation, but are
> > unsupported in the old implementation without a code change.
> >
> > I have been working in this area a lot recently adding some new features and
> > have extended the ArchiveService API. This means I needed to stub out some
> > methods that do nothing in the old ArchiveService implementation to get
> > things to compile (since it directly implements that interface). This makes
> > code maintenance more difficult and is unnecessary when the code isn’t even
> > in use. I cannot see a reason for anyone to switch on this old
> > implementation when the new implementation is logically identical to the
> > old.
> >
> > To reduce all of this overhead and redundant code, I therefore propose that
> > the old archive service implementation be removed from trunk.
> >
> > A material objection (indicated by a -1 and accompany reasoning) raised by a
> > Sakai PMC member will block this proposal.  Other opinions are welcome,
> > indeed encouraged. Silence equals consent. Discussion should be on the
> > sakai-dev list unless of a private nature in which case I am happy to
> > correspond off list. Objections must be received before Sunday 1st December
> > 2013 (five days from now).
> >
> > regards,
> > Steve
> >
> >
> > _______________________________________________
> > cle-release-team mailing list
> > cle-release-team at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >
> 
> 
> 
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> 
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20131202/8145b837/attachment.html