Is JPA another option? Niall
On 5/3/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
this is good stuff, I also have one suggestion, while we do jackrabbit, to become agnostic of a DB, getting a user up to speed is still important. To remove the step of having to install and configure an external database, my idea would be to use Apache Derby. It's a Java Database, and the beauty of it, is that you can bundle it into your project. So when you download a lokahi release, it could already come with a bundled database, all ready to go. Licensing is not an issue, Derby is an ASF project. any thoughts? Filip Ruth DeBardeleben wrote: > Hi all, > > I've enjoyed learning about community building here at Apachecon -- > we've had some good conversations we really ought to recap here on the > list. > > One of the things I picked up from Aaron Farr's talk on community > building is how Lokahi needs to have a clear roadmap for what we're > trying to accomplish in this podling -- so potential > users/contributors can understand what we're about, where we're going, > and how they can get involved. > > I am a Lokahi user, and can contribute documentation, website content > and testing, but I'm not involved in the actual code development. I'd > like to write content for the website, but I can't do that until we've > had the discussions on where we want to go. > > The below is NOT a list of what the Lokahi community has *agreed* to > work on -- it's my informal notes on ideas that came out of > happyhours/brainstorming. > > > > Ideas: (no particular order) > > Idea I: change the backend to use JCR/Jackrabbit (see Steve Toback's > initial message in this thread) > Benefits: > - database-agnostic -- Oracle no longer required, increases the > "market" of potential users > - object versioning (eventually be able to provide an "undo my > latest change" feature, and an archive of what a given httpsd.conf > file contained at a point in time) > - run the whole Lokahi application + repository in a JVM (as > opposed to having to install/manage oracle) > - easier for interested people to set up / try out --- lowers the > barrier to contribution > > I completely agree that a JCR backend would make Lokahi even more > valuable than it is now, and that JCR may have the added benefit of > reducing the community-building difficulties we're facing. From > in-person discussions here at Apachecon, the JCR work sounds like it's > the first priority. > > Idea J: develop a scripting interface (suggested by Noel Bergman) to > get around GUI limitations (rationale: why develop a GUI for tasks > that people don't frequently perform? -- just script against the > repository/database in a way that also records the audit trail of > who-made-what-changes-and-when) > > Idea K: manage www.apache.org infrastructure with Lokahi (eat own dog > food -- don't remember whose idea this was.. Steve's or Noel's?) > Benefits: > - more visibility, more credibility for Lokahi if it manages > *.apache.org > Challenges: > - need to keep Lokahi continually up-to-date with latest Apache & > mod_jk releases -- (would these take priority over the JCR project?) > > Idea L: patch for latest version of mod_jk > > Idea M: investigate using Lokahi to help manage Felix/OSGi > configurations on mobile devices > > My question is: which of these ideas should the community tackle > first? Are we agreed that it's going to be JCR for sure? > > Ruth > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve >> Toback >> Sent: Wednesday, April 25, 2007 5:06 PM >> To: [email protected] >> Subject: Lokahi - Status >> >> Hey guys >> Sorry I have had not a lot of time to commit to this project lately. >> >> I wanted to outline some of the thoughts I have had about the project. >> To start a direction sort of conversation. First to outline some of >> the problems with the application: >> >> Install is complicated. (sql scripts are nasty, in my opinion), but >> it currently works. The ant build script could be improved upon, and >> the app itself could be improved. >> >> >> Database support is limited. We support Oracle (and most of mysql is >> the mysql branch) >> >> The support of apache/tomcat for configs is limited. more >> specifically if you use mod_jk, there's a few things that are >> hard-coded that really shouldn't be. Same goes for tomcat server.xml >> files. (Velocity templating of config files?) >> >> There's been small but infrequent conversations about adding in >> modular support for other application servers. >> >> There is no automated test system. >> >> Basically, I think a lot of the focus should be on giving this podling >> a fighting chance to survive the incubator. >> >> >> I had talked at the last Apachecon about porting the code to use a jsr >> 170 back-end, ie jackrabbit. This would allow 2 major features - more >> database support, and a transactional rollback system for >> configuration changed. Both which are not currently included. This >> is no small undertaking however. And I'd like to start a discussion >> around that. >> >> This would also work to solve a little bit of the first issue I >> mentioned - some of the complexity in setting up the app is in fact >> the database setup itself. >> >> >> When the app was originally designed - the concept was to have two >> types of modules. One for the application servers, one for 'connector >> - type' modules. That is something that is roughly followed >> currently. And could be improved upon. >> >> >> Steve > >
