[
http://jira.amdatu.org/jira/browse/AMDATU-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthijs Hendriks updated AMDATU-264:
-------------------------------------
Attachment: AMDATU-264.patch
This patch adds the ServiceDependentActivator to the library project, in a new
package, being org.amdatu.libraries.osgi. This library its sole purpose is to
contain this class and no other class(es) should be added.
Regarding the generic utilities library, it can be moved to the attic and live
there happily ever after. The few projects inlining the library (see
http://jira.amdatu.org/jira/browse/AMDATU-515) can still do so as this package
will be 'unreleased' as of version 1.0.0 and will still exist in earlier
versions.
> 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
> Fix For: Backlog
>
> 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
