[
http://jira.amdatu.org/jira/browse/AMDATU-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12309#comment-12309
]
Matthijs Hendriks commented on AMDATU-264:
------------------------------------------
The ServiceDependentActivator (I suppose you mean that by JaXSRSpi) is moved to
an other package; see the attached patch. Also, I thought only the core had to
be refactored and AFAAIK the core does not depend on this package. I could, if
you like, refactor auth, cassandra and opensocial to match with the patch/move.
> Deprecate and purge generic utilities library
> ---------------------------------------------
>
> Key: AMDATU-264
> URL: http://jira.amdatu.org/jira/browse/AMDATU-264
> Project: Amdatu
> Issue Type: Improvement
> Reporter: Bram de Kruijff
> Assignee: Matthijs Hendriks
> Fix For: Sprint 2
>
> Attachments: AMDATU-264.patch
>
>
> I noticed some code I wrote for a specific case (fsstorage) was moved to the
> 'utilities' library that is used in several places for several purposes.
> There are several issues with this kind of artifact which is why a propose to
> deprecate and purge it asap. Some arguments against these kind of bag of
> beans libraries are...
> 0) Placing utility code, developed for a specific case under junit tests into
> a generic utility bundle (without test coverage) is pretending it is generic
> code and in some way accepting an implicit contract that people may freely
> use these utilities assuming they are supported for there case.
> 1) Compile time dependecy hell will kick in soon. As different 'utility'
> classes will require different dependencies, stacking up and littering the
> classpath of any depending module. eventually there will obvisouly be a
> circular one.
> 2) Run time follows as more and more dependecies stack up requiring the
> inclusion of irrelevant libraries in bundles and/or even worse imports. I
> already ran into such an issue when depending on the tenant artifact that
> declared a compile scope dep on this very library.
> IMHO a module must have a clear purpose and scope. In this case the code was
> placed in the 'utilities' library to reduce code duplication over mulitple
> modules that re-use the same code. Therefore I now introduced a specific
> fsstorage library (including the specific utilities). This code no longer
> depends on utilities so I say get rid of it!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://jira.amdatu.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
