[cle-release-team] Proposal: Retiring the old ArchiveServiceImpl

[Aaron Zeckoski]

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