On Mon, Aug 1, 2011 at 8:44 AM, Richard Rodgers <[email protected]> wrote:
> Hi all:
>
> I have a few remarks inline, but my bottom line: I think this whole area
> needs more analysis before leaping into any solution, esp. right before a
> release.
> The Domain Model work is interesting and creative, but I'm not convinced we
> understand our use-cases well enough yet to judge it's applicability.
>
> Richard
> On Jul 29, 2011, at 5:53 PM, Tim Donohue wrote:
>
> > What results is a chicken-or-egg issue, where 'dspace-replicate' cannot
> > be included in the full packaged DSpace release unless it's released
> > *first*, but it cannot be released first as it depends on dspace-api.
>
> I guess I don't really understand this point - I see no reason why the
> dependency here is of special concern, or why there is a problematic
> chicken-and-egg situation.
> You say "include replicate in full packaged release", but I see no
> requirement for this at all. Replicate is a good example of
> of a candidate for 'asynchronous' release, which means precisely *not* at
> the same time as the packaged release. Why is it a good idea to require that
> all add-ons be synchronized?
>
My original proposal for Asyncronous release was not "post-release", but was
"pre-release". This means that addons were released separately prior to the
official release and that a set of "sanctioned" addons were to be packaged
together and called "dspace". Post release addition or upgrade is an
additional feature, but not the original intent. Finally, the Domain Model
recommendation is there to assist in support this "post release" addon
capability and reduce the pain in maintaining addons across DSpace releases.
> I'm imagining this is the sort of thing (cloud replication) that one would
> not immediately decide on, but could elect to add to one's system later.
I"m fine with that, release it later and depend on DSpace 1.8.0 after its
come out.
So I see a third option: do nothing (for the moment). I had no problem
> compiling the replicate code from the pom (including it's dependency on
> dspace-api, and 3rd party libraries), and deploying the jar artifacts,
> and configuration files to a DSpace installation. So I think we should be
> clear that not doing option 1 or 2 below will not *prevent* the use of the
> replication module. Of course, we could add scripting or other tooling to
> make it easier, but it is not a complicated process as is.
>
TBH, I'm concerned the dialog and original intent of the email thread is
getting derailed by "dspace-replicate".
Tim said...
> > Option 2: Move more towards refactoring the Domain Model (like Mark
> mentions below), which allows modules like 'dspace-replicate' to be
> changed to just depend on 'dspace-core-api' (which is just a series of
> Java Interfaces). This allows some out-of-the-box DSpace modules to sit
> outside of Trunk (like in /svn/repo/modules). It also does enable the
> ability to perform asynchronous releases for those external modules
> (though, to be clear, we don't *have* to release all external modules
> asynchronously -- it's just available as an option).
One of the reasons this is appealing is that it abstracts the DSpace API
to interfaces. But that is a quite distinct concern, and I'm worried that
> that aspect colors our judgement about the module/release issues. Consider
> the strategy here, which I think is more general than dspace-api. Suppose I
> want to publish a new add-on that depends on our new 'business tier' library
> (or even, since that doesn't exist yet, on dspace-xmlui-api). If I
> understand the issues here, I would have to *first* refactor that latter
> into 'dspace-xmlui-api-api' and 'dspace-xmlui-api-impl', and have my add-on
> depend on the former. This model does not seem particularly
> developer-friendly or scalable.
This is an important point to correct you on:
That is not how we would do it, note there are just a few interfaces of
interest in the xmlui that we would want to have the ability to extend. So
yes, there could eventually be an "api" for those cases, but we need to
remember that while we want to stick "addons" inbetween dspace-api and an
addon to DSpace XMLUI, there is not a need yet to put an addon "between"
dspace-xmlui and some other addon further downstream in the dependency
chain. So the scalability issue describe doesn't exist because there are
only "two levels" in the DSpace hierarchy.
Also note that the "module" naming convention is the problem here and why
your example looks so ugly.
1.) use of the suffix "-api" has been abused. dspace-xmlui-api contains an
implementation, not an api. If I could go back 5 years and redo the
mavenization, the projects would have looked like:
/dspace <-- assembly of dspace application
/core/api <-- just interfaces and support for plugins/addons
/core/impl <-- implementation of core classes
/xmlui/api <-- just interfaces and support for plugins/addons
/xmlui/webapp <--- implementation and webapp
Many parts of what are in dspace-api would have been pushed out to separate
addons/modules which would reduce the amount change that happens to
"dspace-api" across releases and allow for the more stable "api" to properly
emerge. Then the progression to the Domain model would have been much more
natural.
TBH, I see that Tim and Richard are moving away from the Domain solution
because they think its not tractable to rewrite "replicate" prior to the 1.8
freeze. I actually agree with their concern here, but not including it
further delays any opportunity to begin working with it for everyone else
int he community who has an interest. I still implore the community to
consider its addition and continue to try to clear any FUD around the topic
below.
The addition of a domain api library and the classpath signatures is written
in a manner explicitly to reduce any chance of disruption to anyone who is
using an altered dspace-api. Its important to recognize that the following
characteristics of the proposal accomplish this:
a.) The DSpaceObject changes are to only alter the class signatures and thus
will support being easily merged into customized dspace-api that already
exist, we can easly document and alert endusers to the the fact that these
changes are happening int he release notes and prepare them with
documentation in the wiki and at conferences on how to adjust their code to
easily deal with the changes.
b.) There are improvements to provide DSpace "Context Awareness" to specific
parts of DCValue and MetadataValue and to make these classes more
equivalent, which will ease further deprecation efforts around DCValue
c.) The Use of Generic interfaces assures that return types and parameters
in the method signatures do not need to change or be cast. To clarify, for
existing customized dspace users the methods exposed in the DSpace core
classes will not change "at all".
d.) Providing only the interfaces in a separate module does not provide any
further complexity to runtime startup of the application, the "legacy
bridge" dspace-core-impl module would not be distributed with DSpace.
e.) only the API would be distributed, in the same manner as the
dspace-services.
Extending on this last point, I now feel the best home for the domain model
api classes is to place them in the dspace-services api library.
dspace-services/api/src/main/org/dspace/content/<http://scm.dspace.org/svn/repo/modules/dspace-services/trunk/api/src/main/java/org/dspace/>and
so on... This would not require any dependency changes to dspace poms,
we already know we need to release the next version of dspace-services prior
to the dspace 1.8 release, an thus it is most fitting to be there.
In fact, this is actually more in line with the original design intent of
the DSpace 2.0 design / developer team. Originally, the domain model for
DSpace 2.0 was to reside in the same location.
Mark
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
