You are viewing a plain text version of this content. The canonical link for it is here.
Posted to lokahi-dev@incubator.apache.org by Ruth DeBardeleben <ru...@gmail.com> on 2007/05/03 12:47:11 UTC
Re: Lokahi - Status
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: drtobes@gmail.com [mailto:drtobes@gmail.com] On Behalf Of Steve
> Toback
> Sent: Wednesday, April 25, 2007 5:06 PM
> To: lokahi-dev@incubator.apache.org
> 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
Re: Lokahi - Status
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
drtobes wrote:
> On 5/3/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>> 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.
>
> JCR to bundled derby or JCR to even a filestore could be out of the
> box configurations. Unless you're talking about skipping the jcr
> completely and going directly to Derby, in which case you would lose
> versioning...
either way, as long as what I download, can be "kickstarted" ie, I don't
need any other external steps to get up to speed
Filip
>
> Steve
>
>
Re: Lokahi - Status
Posted by drtobes <dr...@gmail.com>.
On 5/3/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> 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.
JCR to bundled derby or JCR to even a filestore could be out of the
box configurations. Unless you're talking about skipping the jcr
completely and going directly to Derby, in which case you would lose
versioning...
Steve
Re: Lokahi - Status
Posted by Niall Pemberton <ni...@gmail.com>.
Is JPA another option?
Niall
On 5/3/07, Filip Hanik - Dev Lists <de...@hanik.com> 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: drtobes@gmail.com [mailto:drtobes@gmail.com] On Behalf Of Steve
> >> Toback
> >> Sent: Wednesday, April 25, 2007 5:06 PM
> >> To: lokahi-dev@incubator.apache.org
> >> 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
> >
> >
>
>
Re: Lokahi - Status
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: drtobes@gmail.com [mailto:drtobes@gmail.com] On Behalf Of Steve
>> Toback
>> Sent: Wednesday, April 25, 2007 5:06 PM
>> To: lokahi-dev@incubator.apache.org
>> 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
>
>
RE: Lokahi - Status
Posted by "Lega, Peter Z" <pe...@merck.com>.
Great idea. This sort of structure will help us get developers to see
where their work sits
In the big picture
-----Original Message-----
From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
Sent: Thursday, May 03, 2007 4:50 PM
To: lokahi-dev@incubator.apache.org
Subject: Re: Lokahi - Status
On 5/3/07, Ruth DeBardeleben <ru...@gmail.com> 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 agree this is a good idea - one option is to use Jira for this. I
think in general its good practive to create Jira tickets for most
changes and then you can:
- Use it to produce a roadmap by assigning tickets to version numbers
- See the descriptive rationale for the change along with the actual
svn commits (by referencing the Jira ticket # in the commit log
- get it to produce release notes
From looking through the mailing list archives seems that
contributions to date have be posted as patches to the list (or
elsewhere). Its much easier (IMO) if people are encouraged to attach
such things to Jira tickets. That way they don't get lost/forgotten in
the mailing list. Also importantly - Jira has an explicit option
"Grant license to ASF for inclusion in ASF works" for patches - so
there is no doubt that the contributor has given their permisson for
their contribution to be included.
> 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.
I agree that the website needs to be improved to make it easier for
people to get into the project - mostly just minor changes, but
anything that reduces the barrier to entry has to be a good thing.
Initially I couldn't find anywhere to download (since noticed the link
was at the bottom of the front page) - also links (that you can click)
to browse the svn repository, join the mailing list(s) and view the
mailing list archives would be good.
Anyway - just my 2cents as an outsider.
Niall
> 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: drtobes@gmail.com [mailto:drtobes@gmail.com] On Behalf Of
Steve
> > Toback
> > Sent: Wednesday, April 25, 2007 5:06 PM
> > To: lokahi-dev@incubator.apache.org
> > 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
>
------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then
delete it from your system.
------------------------------------------------------------------------------
Re: Lokahi - Status
Posted by Niall Pemberton <ni...@gmail.com>.
On 5/3/07, Ruth DeBardeleben <ru...@gmail.com> 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 agree this is a good idea - one option is to use Jira for this. I
think in general its good practive to create Jira tickets for most
changes and then you can:
- Use it to produce a roadmap by assigning tickets to version numbers
- See the descriptive rationale for the change along with the actual
svn commits (by referencing the Jira ticket # in the commit log
- get it to produce release notes
From looking through the mailing list archives seems that
contributions to date have be posted as patches to the list (or
elsewhere). Its much easier (IMO) if people are encouraged to attach
such things to Jira tickets. That way they don't get lost/forgotten in
the mailing list. Also importantly - Jira has an explicit option
"Grant license to ASF for inclusion in ASF works" for patches - so
there is no doubt that the contributor has given their permisson for
their contribution to be included.
> 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.
I agree that the website needs to be improved to make it easier for
people to get into the project - mostly just minor changes, but
anything that reduces the barrier to entry has to be a good thing.
Initially I couldn't find anywhere to download (since noticed the link
was at the bottom of the front page) - also links (that you can click)
to browse the svn repository, join the mailing list(s) and view the
mailing list archives would be good.
Anyway - just my 2cents as an outsider.
Niall
> 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: drtobes@gmail.com [mailto:drtobes@gmail.com] On Behalf Of Steve
> > Toback
> > Sent: Wednesday, April 25, 2007 5:06 PM
> > To: lokahi-dev@incubator.apache.org
> > 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
>