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.
> 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.
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.
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].
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."
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.
Some of that would matter less if we could treat the DB purely as an index
that could be regenerated from the assetstore [as was discussed years ago] -
but we've been talking more about taking things out of files and into the
database.
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.
> 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).
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
