[
http://jira.amdatu.org/jira/browse/AMDATU-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12310#comment-12310
]
Bram de Kruijff commented on AMDATU-264:
----------------------------------------
{quote}
The ServiceDependentActivator (I suppose you mean that by JaXSRSpi) is moved to
an other package; see the attached patch
{quote}
The patch isn't committed yet right? In that case resolving this with a svn
move of the utilities lib leaves us without it.
{quote}
I thought only the core had to be refactored and AFAAIK the core does not
depend on this package
{quote}
Scope it platform. Also if we decide to provide users of the platform with this
class it must be present even if we ourselves do not depend on it.
{quote}
I could, if you like, refactor auth, cassandra and opensocial to match with
the patch/move.
{quote}
Scope is platform. Project wont break as they do not depend on platform trunk
> 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
