On May 10, 2011, at 11:21 PM, Graham Triggs wrote:
> On 11 May 2011 01:48, Mark Diggory <mdigg...@atmire.com> wrote:
> Yes, but you need to realize that confluence has certain standards it
> maintains.
>
> 1.) Its just one webapplication and only one webapplication
>
> A good thing.
agreed
>
> 5.) An OSGi implementation mounts a secondary directory to run plugins as
> OSGi Bundles and runs the OSGi container within the webapplication itself
> (unlike the way that DuraCloud runs it)
> 6.) Provides a UI and other tools to add/remove bundles from that OSGi
> container at runtime.
>
> So its important to note that technologically, they solved the development of
> plugins by smartly adopting a popular third party solution for modularity
> rather than creating their own. That you don't need to build "confluence nor
> your "plugins" to deploy them. Pretty smart folks there.
>
> You don't necessarily need to build DSpace nor a plugin to install the plugin
> - drop the JAR into the classpath(s), adjust the configuration, and restart
> the application. Of course, it's generally less manual/technical effort with
> Confluence's system.
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.
>
> But it's also worth noting that you don't get carte blanche to alter
> Confluence's behaviour in every weird way that you can think of. There is a
> distinct API to interact with, and distinct service hooks that plugins attach
> to. Our biggest barrier is how few hooks we have, not the lack of a
> technology for bundling code.
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.
>
> As a user of a hosted Confluence service (as part of JIRA Studio), it's also
> quite telling that they don't allow end users to install their own plugins.
> Rather, you have to make a support request, and they install it for you. So,
> it isn't really that safe / reliable to install plugins [not that you should
> expect it to be - plugins are 3rd party code that could be doing all sorts of
> crazy things].
Its hosted, they want to control what you use there because its their
environment.
> With very minimal effort (no code changes), we have done a standalone
> deployment of DSpace with an embedded tomcat instance such that all
> configuration was relative to the current working directory (meaning it
> doesn't care where its located in the file system). if someone were savvy
> enough to get a native java db fired up with a schema installed and available
> as the DataSource by default... we'd pretty much have accomplished a
> standalone DSpace that could be started just by unzipping it and navigating
> bin and calling "catalina.sh start".
>
> And from the Confluence documentation:
>
> "Select an External Database: This step is optional for users evaluating
> Confluence. However, if you are installing Confluence for production
> purposes, this step is mandatory."
No doubt
>
> Yes, they bundle a java db. But ONLY for evaluation purposes. Similarly, the
> built-in backup tasks are marked as being OK up to a few thousands pages, but
> not as scalable, nor as robust as using the native backup facilities of your
> database.
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.
>
> I'm not saying that what we currently have is easy enough, but imho (and
> leaving aside the issues of explicit Maven versions that have cropped up
> recently), I think we have a bigger issue with people simply not reading the
> documentation that is provided, than what is required of you to do being too
> hard. Which suggests that we shouldn't start doing things like bundling
> native java dbs without also making any statements we want to make about it's
> reliability / suitability very clear.
Well, I get that have a low barrier to installing a barebones / demo dspace
instance without having to do all the maven/ant build would increase adoption.
What I've gotten from Tim and others in DCAT is that, for some, they just want
to make it so you don't need to do maven/ant to reach that point of testing out
the platform.
>
> The problem is... its approaching 300Mb to download the package due to the
> replicated jars in all the webapps and lib So if you want to distribute in
> such a manner, something needs to happen to reduce the size of the
> application. Consolidating webapps, shared lib in tomcat, using webapp lib
> for cli lib, etc...
>
> I would vote for consolidating webapps. Shared lib is ok for a bundled
> distribution, but a dangerous precedent to set for people that are installing
> their own application servers, and possibly problematic for people developing
> and installing to the directory later on.
>
> Although it sounds like the packaging isn't particularly efficient if
> multiple copies of the same file is causing the package to balloon in size
> (not that I'm suggesting having replicated jars is a desirable solution).
>
I do agree, and that is partially why I point it out.
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Technologielaan 9 - 3001 Heverlee - Belgium
------------------------------------------------------------------------------
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
