The current LCF standard deployment model requires a number of moving parts,
which are probably necessary in some cases, but simply introduce complexity in
others. It has occurred to me that it may be possible to provide an alternate
deployment model involving Jetty, which would reduce the
(b) The alternative starting point should probably autocreate the
database,
and should also autoregister all connectors. This will require a list,
somewhere,
of the connectors and authorities that are included, and their preferred
UI
names for that installation. This could come from the
You forget that building lcf in its entirety requires that you supply
proprietary client components from third-party vendors. So i think it is
unrealistic to expect canned builds that contain everything that you just
deploy. For lcf i think the build cycle will thus be very common.
Getting
But for a basic, early evaluation, test drive, just the file system and
web repository connectors should be sufficient. And if there is a clean
database abstraction, a basic database package (e.g., derby) should be
sufficient for such a basic evaluation.
Are there technical reasons why
I've been fighting with Derby for two days. It's missing a significant amount
of important functionality, and its user and database model are radically
different from all other databases I know of. (I'm also getting nonsense
exceptions from it, but that's another matter.) So regardless of
The use cases I was considering for database issues are:
1) Desire for a very simple evaluation install process. See the Solr
tutorial.
2) Desire for less complex and faster application deployment install
process. PostgreSQL has a reputation for having a large footprint.
Now, as machines and
Dump and restore functionality already exists, but the format is not xml.
Providing and xml dump and restore is straightforward. Making such a file
operate like a true config file is not.
This, by the way, has nothing to do with registering connectors, which is a
datatbase initialization
I already posted a response to this, but since it didn't seem to appear I'm
going to try again.
LCF already has dump and restore commands, but they don't currently write XML,
they write binary data. Providing a way to write and read XML would be
relatively straightforward. But this is *not*
I meant the lcf.agents.RegisterOutput org.apache.lcf.agents.output.* and
lcf.crawler.Register org.apache.lcf.crawler.connectors.* types of operations
that are currently executed as standalone commands, as well as the
connections created using the UI. So, you would have config file entries for
