[Mulgara-dev] Comments solicited

[Paul Gearon]

On Tue, Aug 5, 2008 at 1:03 PM, Alex Hall <alexhall at revelytix.com> wrote:
> First off, I wholeheartedly support any efforts to improve the current build
> system.  I agree that the current situation, with dozens of sub-components and
> hundreds of build targets, is too complex and fragile, and likely to be a real
> impediment to future development.

Can I vote to agree with you when I've already been trying to make
this point?  :-)

> I also think that merging directory structures is a good idea for another
> reason: the current structure does not always line up very well with the package
> structure.  I consider myself pretty familiar with the structure of Mulgara, and
> even I sometimes have trouble locating the source for a given class.  I can only
> imagine how difficult it is for people less familiar with the project.

This was one of my reasons for moving to Eclipse from my previous
development platform of Vim/Exuberant-ctags. I know that ctags does a
lot of the work, but Eclipse made it easier for me. But I still have
difficulties.

A point worth making here is that Java allows classes to reference
each other, making for circular dependencies. In C++ you do it by
pre-declaring a class, which lets you reference it even though the
compiler hasn't seen it yet. Java does it automatically. I'm sure most
of the developers here know how useful this is.

Unfortunately, the Java compiler can only do this mutual reference
resolution when it has access to both classes at the same time.
However, the separate modules are compiled by Ant making separate
invocations on the compiler. This means that there is no way for
mutual references of classes across modules. This isn't needed all
that often, but it DOES come up. To date, we get around it by defining
an interface for the class that gets created second, and have the
first class use reflection to get hold of the appropriate instance of
that interface. This is horribly clunky (and I usually go through
amazing lengths to avoid it).

The frustrating thing about using Eclipse is that it works with all
the sources as once, and has a common class path. This means that
everything "just works" in Eclipse, but when you try to make it
compile with the Ant script you find that you have to go back to some
reflection solution.

> The "further suggestions" are both ideas that I think would be nice, but
> certainly aren't essential.  Using mulgara-config.xml to locate external modules
> for inclusion in the jar file would make it trivial to re-package Mulgara with
> optional modules.  As it stands right now, you must hack the embedded-jar target
> to include any additional components that are not part of the default
> distribution.  Using a custom class-loader would allow anybody developing their
> own Resolver to deploy without having to re-package Mulgara.  I don't know if
> that's important to anybody right now, but it could be in the future.

I've never had a need to do hot deployment, and I've always been able
to include any components I want in Mulgara. I also hate chasing down
Jars (and other libs) when trying to make something run, so I prefer
doing monolithic deployment. But this may be important for anyone
creating a custom resolver or content handler.

Ronald.... you have a custom resolver. Do you have an opinion on this?

> More specific comments about the core/optional modules:
>
> 1. I think a good rule of thumb is, if a component is called out by name in
> mulgara-config.xml then it belongs in its own module.  Granted you can't really
> run Mulgara without a store implementation, and since there's only one available
> at the moment I think it makes sense to relax that rule.

That makes sense. Which makes me think that many of the things being
called out at the moment are "unnecessarily configurable". I was
already about to merge Krule in as the system rules engine. I'm not
averse to configuring something that overrides, or supplements the
system modules, but I think the system modules can be hard coded.

Does anyone have thoughts, agreement, or violent dissent on this?

> 2. I don't see any of the store-* modules in either list.  Are they meant to be
> listed under the core modules?

Yes. I should mention that.

> 3. I've never been able to figure out what doclet/doclet141 are used for.  Are
> these modules still used?

Not really. They are Javacod extensions. Have you noticed the extra
javadoc tags? The code in the doclet package handles the tags for
@modified and @maintenanceAuthor, and then overrides the output of
@version. The (completely unreferenced) code in the doclet141 package
handles the @copyright, @created, @license, @modified tags.

I just realized that this package was completely unreferenced, because
the directory and filenames still say "kowari" (even though the
scripts did manage to update the contents of the files).  :-)

Those javadoc tags were considered important back when Kowari was
being produced by a commercial company who still wanted to assert
copyright. I'm not removing them from existing files, but nothing new
keeps them.

Anyway... we can remove the packages, yes.

> 4. The resolver-test component is a bit of a special case.  It shouldn't be
> packaged with the core distribution, but it exists entirely to test the
> Annotation mechanism which is an important part of the core module.  That brings
> up the issue of creating a separate source tree for test code, but I'm not sure
> I want to open that can of worms.

Actually, this is the default setup in Maven. You keep a parallel
directory structure under a root of "test" with the same packages in
it. This way you can build the main tree easily, and afterward you can
build the testing tree, with a dependency on the main distribution.
You're still in the same package, so testing is not impeded.

At the moment we mix it all in to the same directory. The way we keep
the testing classes out of the distribution is to have a filter on the
files that go into the Jar. Ant lets you filter out files with
expressions like exclude="**/*Test.java".

I think I prefer the Maven way.

> 5. I'm in favor of dropping, or at least deprecating, the SOFA interface. A
> quick Google search indicates that it's been 2 years since there was any
> activity on the SOFA mailing list, and 3 years since there was a new release.
> For all intents and purposes it appears to be a dead project, and if we want to
> improve ontology or inference support there are much better candidates for our
> development efforts.

Agreed.

We need to do something with OWL, but SOFA isn't the way. Besides
that, it was never finished.

Paul