On 11 May 2011 08:12, Mark Diggory <mdigg...@atmire.com> wrote:
> Until you create addons that have dependencies on other addons, then you
> need to add more than one jar and make sure your versions are correct, part
> of the reason they use OSGi.
>
This isn't really the right thread for a cost/benefit analysis of OSGi. I'm
just making the point that you don't need it to be able to install add ons
into an application without rebuilding it (even if you have more than one
jar to add).
And really, with the assembly project, even using Maven we aren't really
rebuilding anything.
At one level, I still find it curious that asking people to run:
mvn packge
or
ant fresh_install
can be considered to be more confusing/harder than running 'install-dspace'.
Admittedly, I don't like that we are asking people to do a combination of
Maven and Ant tasks. I don't like that we've made our Maven configuration
more complex than it needs to be.
But I'm interested in seeing more of Tim's installer, as I don't know what
approach has been taken. But there is nothing that prevents us bundling a
tested Maven and/or Ant distribution in our install package - we can
certainly ease some of the issues by pushing this behind a facade, rather
than substituting it wholesale. And that would be better for people to be
able to pick it apart as they start to require more advanced changes.
Quite true they have a well specified API and the plugin/bundles implement
> ver specific service endpoints/providers. Again something we should work to
> make more easily possible in dspace (currently the spring appication context
> gives us a poor mans version of this.
>
Yep, although there isn't always anything wrong with being a poor mans
version - not everyone will be able to afford to eat caviar :). At least, I
would say that it is a sensible evolution step - move towards service points
and where people need to they can wire these things in Spring. And at a
later stage we could bring in Spring DM to handle add ons.
Its hosted, they want to control what you use there because its their
> environment.
>
I'm not saying it as a bad thing, but it reflects on how much we should
choose to expose in DSpace, and to whom.
Should a DSpace admin [librarian] really have the ability to shoot their
repository in the foot by installing an OSGi bundle over the web interface?
How will their IT department take to that?
I realize that this should be something that is a local policy - and I'm not
saying that we should make an arbitrary decision on behalf of the
institutions. But we do need to think about the right balance between
development effort, complexity and actual benefit.
> I thought this was what we were discussing a DSpace instance you could
> download and start. If you want more complex configuration or to do a
> production deployment, you need to complete such steps to make it so.
>
Yes, but we should make it sufficiently clear what steps should be taken. If
we don't, we'll just end up with unhappy people at a different stage.
G
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
