[Mulgara-general] Multi Module Mulgara Maven Mission

[Mark]

Hi

I was kind of surprised at the number of modules. In fact I wrote a
recursive search to copy all .java files under a single source tree.

>From there I copied them into maven module (mulgara-all) of a parent mulgra
project. The parent at the moment defines all the dependencies, however some
jar libraries are not in public repositories. Also the auto-generated (cc)
files will require a bit of attention.

I guess now with spring or guice IOC isn't very hard either. Finally if I
want to go the whole hog I could OSGi each module to achieve modularity in
the purest sense.

If there is a single entry point to an application, then you can simple walk
the DAG of dependencies to understand the internal coupling of an
application. In fact why not model the DAG of dependencies with Mulgara!!!
There are tools to do this e.g. Stan (free license for open source projects
as is jprofiler, intellij ...etc) do we have this for Mulgara?

Anyhow, I guess right now I should produce documentation rather than cutting
code.

Regards

Mark

On 25 February 2010 18:51, Paul Gearon <gearon at ieee.org> wrote:

> Hi,
>
> On Thu, Feb 25, 2010 at 12:31 PM, Mark <javamark at gmail.com> wrote:
> > Hello all,
> >
> > If anyone is interested I have decided to port the latest version
> (2.1.7) of
> > Mulgara to a multi-module maven project.
> >
> > I have got an initial attempt working (1 module or artifact so far
> > mulgara-all). More work is needed to split the project into sensible
> modules
> > such as server, query, rest....etc
> >
> > Thoughts?
>
> As it stands, the module breakup isn't entirely logical, but there
> seems to have been some sort of plan behind it. I didn't really agree
> with it at the time (circa 2003) but it's water under the bridge now.
>
> The idea was for different distribution targets to be built from
> various modules. So a client library is built from different modules
> than a complete server, for instance. Also, each resolver and content
> handler is standalone (and loaded through the XML configuration file),
> and so they form their own modules as well. This includes the main
> resolver (XA) since it can be replaced by any other other read-write
> resolver.
>
> All the same, I have noticed a lot of modules that seem to have been
> created gratuitously. I've spent a little time trying to group some of
> these together. As a result, a number of server-side modules got
> merged into "query". This represents a raw triplestore with a query
> processing engine.  The "querylang" module could almost go in there,
> but it represents a set of interfaces for talking to the server
> engine, and could theoretically be completely replaced, not that this
> is likely.
>
> Anyway, I hope that sheds a little light.
>
> Regards,
> Paul Gearon
> _______________________________________________
> Mulgara-general mailing list
> Mulgara-general at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-general/attachments/20100225/02d19198/attachment.htm>