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 "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/09/12 00:11:55 UTC
Participant Status?
-- project status --
The last word of discussion some 3 months ago was about infra, the
creation of the lokahi wiki site. It has since been unused. Some
banter on the tail end of ApacheCon EU/07 included ideas about docs
and deployment help, and some ideas about DB backends.
The last commit activity in the same timeframe were the beginnings
of a jackrabbit connector, no other activity for commits@ since then.
There has been no activity on private.
-- commentary --
Of course it was summer, nobody at the ASF expects measurable milestones
etc in the development of open source. Things move at the speed of the
project participants. Heathy/dead project definitions hide the fact
that the code is there for people to use, and there may be either little
to change in the current code (it just works), or things are just clear.
However, there is identified a need to provide a non-proprietary database
backend before the project graduates. There's also an identified need to
add documentation of how to at least deploy and get started using/testing
lokahi.
Once those are done there really isn't a big reason to be in the incubator,
except that the community is very small, which gives the IPMC and the board
concern that it doesn't have enough interest to be maintained or overseen.
The incubator PMC really needs some folks to speak up on this thread of
their intent to remain (return to being) active at this project. It's
amazing how the positive reception ("That's exactly what we we've been
looking for!" or "That's what we were attempting to implement" or simply
"Wow, you mean there actually is one out there???") There's a need, there
is an audience. There's even (good) code. Are there participants?
Bill
RE: Participant Status?
Posted by "Lega, Peter Z" <pe...@merck.com>.
There was some talk of using the oracle personal version (the name
escapes me) which has no cost. Although I think the quick-win short term
solution is a quick port to MySQL or Derby, and the longer term might be
a jackrabbit repository (there are data model recasting issues).
The other think we are fighting is the perception that
Management/Enterprise tools are not as compelling to work on as other
types of projects. (Although was have some very compelling usage data,
as we control our entire Java runtime).
Could it be that individual contributors don't have a personal need to
use it, and that larger companies who do need it already have some
ad-hoc tooling?
Pete
-----Original Message-----
From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
Sent: Tuesday, September 18, 2007 12:40 PM
To: lokahi-dev@incubator.apache.org
Subject: Re: Participant Status?
On 9/18/07, Toback, Steve <st...@merck.com> wrote:
> This brings some questions to mind - namely what is causing this
project
> to not gather continued attention.
>
> What's preventing adoption or continued improvement? (other than me
> lack of personal time to work on this, this summer)
>
> Is the database really the halting factor? Or is there something else
-
> Lack of apache 2.2 support? I honestly don't know.
Perhaps not having a binary version of the release?
Niall
> Steve
>
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Tuesday, September 11, 2007 8:12 PM
> To: lokahi-dev@incubator.apache.org
> Subject: Participant Status?
>
> -- project status --
>
> The last word of discussion some 3 months ago was about infra, the
> creation of the lokahi wiki site. It has since been unused. Some
> banter on the tail end of ApacheCon EU/07 included ideas about docs
> and deployment help, and some ideas about DB backends.
>
> The last commit activity in the same timeframe were the beginnings
> of a jackrabbit connector, no other activity for commits@ since then.
>
> There has been no activity on private.
>
> -- commentary --
>
> Of course it was summer, nobody at the ASF expects measurable
milestones
> etc in the development of open source. Things move at the speed of
the
> project participants. Heathy/dead project definitions hide the fact
> that the code is there for people to use, and there may be either
little
> to change in the current code (it just works), or things are just
clear.
>
> However, there is identified a need to provide a non-proprietary
> database
> backend before the project graduates. There's also an identified need
> to
> add documentation of how to at least deploy and get started
> using/testing
> lokahi.
>
> Once those are done there really isn't a big reason to be in the
> incubator,
> except that the community is very small, which gives the IPMC and the
> board
> concern that it doesn't have enough interest to be maintained or
> overseen.
>
> The incubator PMC really needs some folks to speak up on this thread
of
> their intent to remain (return to being) active at this project. It's
> amazing how the positive reception ("That's exactly what we we've been
> looking for!" or "That's what we were attempting to implement" or
simply
> "Wow, you mean there actually is one out there???") There's a need,
> there
> is an audience. There's even (good) code. Are there participants?
>
> Bill
>
>
>
>
>
>
>
------------------------------------------------------------------------
------
> 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.
>
>
------------------------------------------------------------------------
------
>
------------------------------------------------------------------------------
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: Participant Status?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> a requirement of Oracle...
Almost certainly a killer. MySQL, PostGre, or even better, Derby embedded.
Even before, of course, moving to JCR.
--- Noel
Re: Participant Status?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
drtobes wrote:
>
> But even with a binary release - and a requirement of Oracle...
The later is the primary obstacle to my hauling around a copy to
show off from my laptop, any of the suggested alternatives would
solve this nicely.
Re: Participant Status?
Posted by drtobes <dr...@gmail.com>.
On 9/18/07, Niall Pemberton <ni...@gmail.com> wrote:
>
> Perhaps not having a binary version of the release?
>
> Niall
Perhaps -
Shame on me for not asking how to package a binary release without all
the dependent jar files... and not doing so earlier...
But even with a binary release - and a requirement of Oracle...
Re: Participant Status?
Posted by Niall Pemberton <ni...@gmail.com>.
On 9/18/07, Toback, Steve <st...@merck.com> wrote:
> This brings some questions to mind - namely what is causing this project
> to not gather continued attention.
>
> What's preventing adoption or continued improvement? (other than me
> lack of personal time to work on this, this summer)
>
> Is the database really the halting factor? Or is there something else -
> Lack of apache 2.2 support? I honestly don't know.
Perhaps not having a binary version of the release?
Niall
> Steve
>
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Tuesday, September 11, 2007 8:12 PM
> To: lokahi-dev@incubator.apache.org
> Subject: Participant Status?
>
> -- project status --
>
> The last word of discussion some 3 months ago was about infra, the
> creation of the lokahi wiki site. It has since been unused. Some
> banter on the tail end of ApacheCon EU/07 included ideas about docs
> and deployment help, and some ideas about DB backends.
>
> The last commit activity in the same timeframe were the beginnings
> of a jackrabbit connector, no other activity for commits@ since then.
>
> There has been no activity on private.
>
> -- commentary --
>
> Of course it was summer, nobody at the ASF expects measurable milestones
> etc in the development of open source. Things move at the speed of the
> project participants. Heathy/dead project definitions hide the fact
> that the code is there for people to use, and there may be either little
> to change in the current code (it just works), or things are just clear.
>
> However, there is identified a need to provide a non-proprietary
> database
> backend before the project graduates. There's also an identified need
> to
> add documentation of how to at least deploy and get started
> using/testing
> lokahi.
>
> Once those are done there really isn't a big reason to be in the
> incubator,
> except that the community is very small, which gives the IPMC and the
> board
> concern that it doesn't have enough interest to be maintained or
> overseen.
>
> The incubator PMC really needs some folks to speak up on this thread of
> their intent to remain (return to being) active at this project. It's
> amazing how the positive reception ("That's exactly what we we've been
> looking for!" or "That's what we were attempting to implement" or simply
> "Wow, you mean there actually is one out there???") There's a need,
> there
> is an audience. There's even (good) code. Are there participants?
>
> Bill
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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: Participant Status?
Posted by Steve Toback <to...@apache.org>.
Hi Ludovic,
On 9/18/07, Ludovic Maitre <lu...@free.fr> wrote:
> Hi Steve, all
>
> As an old contributor which still follow the mailing list, i would like
> to explain why i doesn't contribute nor use anymore Lokahi. It's because
> at work we use (and i have contributed to develop) another system to
> deploy j2ee webapps, a homegrown ant-remote solution with xml based
> descriptors to describe the platforms/farms and the
> products/applications to install [perhaps this is similar to what
> smartfrog want to achieve or at least describe?]. Initially, i was
> planning to use Lokahi to maintain the apache and tomcat servers, but
> finally i do it with a combination of ant remote (to deploy binary and
> config files) and a homegrown Java xml rpc API which call webmin rpc,
> because i feel that i can control more things with this system.
Good to hear you solved your problem - even though Lokahi wasn't the
turnkey solution for you. What extra control does you solution allow?
I'd love to hear :)
>
> Toback, Steve a écrit :
> > This brings some questions to mind - namely what is causing this project
> > to not gather continued attention.
> >
> > What's preventing adoption or continued improvement? (other than me
> > lack of personal time to work on this, this summer)
> >
> >
> I have contributed some code some time ago to support MySQL i would say
> that i haven't been able to keep up with the code changes in order to
> maintain this port. Also the mysql code has been put on a side svn
> branch and IIRC there is ongoing work in trunk to have a ORM framework,
> so basically my contributions will be useless after this work will be
> done. I would have continued to contribute or at least improve my code
> if it would have been useful but this has not been the case and i
> believe (but haven't checked) that the refactoring with the ORM
> framework has not been finished --> i'm reluctant to work again on the
> project until the devs which had began to contribute this code have
> finished it.
The refactoring for ORM (jackrabbit) was started in a completely
separate branch (sandbox if you will) - knowing full well that I would
break quite a few things, and take a long time doing so... The intent
was to prove that it worked - and honestly I had thought I would have
a lot more time to work on it.
The mysql patches you contributed (Thank you) were put into a separate
branch with the intention of merging them back to trunk quickly and
after proving that it all still worked - shipping a release that
worked on mysql & oracle.
AFAIK there are only a few small issues remaining with the MySQL
branch. I believe one of the things that needed to be still ported
was the job scheduling thread. But without running it through a full
set of tests - I am not sure.
Steve
Re: Participant Status?
Posted by Ludovic Maitre <lu...@free.fr>.
Hi Peter,
Lega, Peter Z a écrit :
> So maybe a binary release with derby or mysql ported?
>
>
The code is located here :
http://svn.apache.org/repos/asf/incubator/lokahi/lokahi/branches/mysql/
But this is not really tested code! it is just a proof of concept port
of Lokahi with MySQL, i guess this could be easily derivated for other
DBs [postgresql, ms sql (i have some code if you want)].
However i guess that the better will eventually be to use a java content
repository like this is done on the jackrabbit branch
(http://svn.apache.org/repos/asf/incubator/lokahi/lokahi/branches/jackrabbit/),
also it will perfectly match the storage system i use for my homegrowns
systems management softwares ;-)
> -----Original Message-----
> From: Ludovic Maitre [mailto:ludovic.maitre@free.fr]
> Sent: Tuesday, September 18, 2007 2:20 PM
> To: lokahi-dev@incubator.apache.org
> Subject: Re: Participant Status?
>
> Hi Steve, all
>
> As an old contributor which still follow the mailing list, i would like
> to explain why i doesn't contribute nor use anymore Lokahi. It's because
> at work we use (and i have contributed to develop) another system to
> deploy j2ee webapps, a homegrown ant-remote solution with xml based
> descriptors to describe the platforms/farms and the
> products/applications to install [perhaps this is similar to what
> smartfrog want to achieve or at least describe?]. Initially, i was
> planning to use Lokahi to maintain the apache and tomcat servers, but
> finally i do it with a combination of ant remote (to deploy binary and
> config files) and a homegrown Java xml rpc API which call webmin rpc,
> because i feel that i can control more things with this system. But like
> i've said i still follow the project, servers managment is an
> interesting area and there is still a lot of room for Lokahi (and java
> based oss in this domain) to evolve and perhaps integrate some of my own
> requirements.
>
> Toback, Steve a écrit :
>
>> This brings some questions to mind - namely what is causing this project
>> to not gather continued attention.
>>
>> What's preventing adoption or continued improvement? (other than me
>> lack of personal time to work on this, this summer)
>>
>>
>>
> I have contributed some code some time ago to support MySQL i would say
> that i haven't been able to keep up with the code changes in order to
> maintain this port. Also the mysql code has been put on a side svn
> branch and IIRC there is ongoing work in trunk to have a ORM framework,
> so basically my contributions will be useless after this work will be
> done. I would have continued to contribute or at least improve my code
> if it would have been useful but this has not been the case and i
> believe (but haven't checked) that the refactoring with the ORM
> framework has not been finished --> i'm reluctant to work again on the
> project until the devs which had began to contribute this code have
> finished it.
>
>> Is the database really the halting factor? Or is there something else -
>> Lack of apache 2.2 support? I honestly don't know.
>>
>>
>>
> IMHO, supporting only Oracle is a hurdle and it is very important to
> support other databases. As an illustration of this, i hope this is not
> off topic, i was considering using Ofbiz , a open source ERP, since a
> long time ago (i'm aware of it since sometinhg like 5/6 years), but i
> wasn't able to pay a oracle license for it and it was only supporting
> this type of db. It's only this year that i have eventually decided to
> use (and develop) it because it now support any db (since one or 2 years
> i believe). I believe that since it support many dbs ofbiz has been used
> by far more peoples than before. (but i have no evidences of this :-)
>
> I also think that a binary distribution would be a good thing. And a
> trivials bugs free release too, labeled 1.0 ready for prod :-) , in
> order to be installed in corporate environments.
>
> So many thanks for doing Lokahi, keep up the good work (but finish it :-),
> My 2 cents,
>
> PS: Sorry for my english and lack of nuances in my wording, i'm not
> really good at this.
>
>> Steve
>>
>> -----Original Message-----
>> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
>> Sent: Tuesday, September 11, 2007 8:12 PM
>> To: lokahi-dev@incubator.apache.org
>> Subject: Participant Status?
>>
>> -- project status --
>>
>> The last word of discussion some 3 months ago was about infra, the
>> creation of the lokahi wiki site. It has since been unused. Some
>> banter on the tail end of ApacheCon EU/07 included ideas about docs
>> and deployment help, and some ideas about DB backends.
>>
>> The last commit activity in the same timeframe were the beginnings
>> of a jackrabbit connector, no other activity for commits@ since then.
>>
>> There has been no activity on private.
>>
>> -- commentary --
>>
>> Of course it was summer, nobody at the ASF expects measurable milestones
>> etc in the development of open source. Things move at the speed of the
>> project participants. Heathy/dead project definitions hide the fact
>> that the code is there for people to use, and there may be either little
>> to change in the current code (it just works), or things are just clear.
>>
>> However, there is identified a need to provide a non-proprietary
>> database
>> backend before the project graduates. There's also an identified need
>> to
>> add documentation of how to at least deploy and get started
>> using/testing
>> lokahi.
>>
>> Once those are done there really isn't a big reason to be in the
>> incubator,
>> except that the community is very small, which gives the IPMC and the
>> board
>> concern that it doesn't have enough interest to be maintained or
>> overseen.
>>
>> The incubator PMC really needs some folks to speak up on this thread of
>> their intent to remain (return to being) active at this project. It's
>> amazing how the positive reception ("That's exactly what we we've been
>> looking for!" or "That's what we were attempting to implement" or simply
>> "Wow, you mean there actually is one out there???") There's a need,
>> there
>> is an audience. There's even (good) code. Are there participants?
>>
>> Bill
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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.
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>>
>
>
>
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
RE: Participant Status?
Posted by "Lega, Peter Z" <pe...@merck.com>.
So maybe a binary release with derby or mysql ported?
-----Original Message-----
From: Ludovic Maitre [mailto:ludovic.maitre@free.fr]
Sent: Tuesday, September 18, 2007 2:20 PM
To: lokahi-dev@incubator.apache.org
Subject: Re: Participant Status?
Hi Steve, all
As an old contributor which still follow the mailing list, i would like
to explain why i doesn't contribute nor use anymore Lokahi. It's because
at work we use (and i have contributed to develop) another system to
deploy j2ee webapps, a homegrown ant-remote solution with xml based
descriptors to describe the platforms/farms and the
products/applications to install [perhaps this is similar to what
smartfrog want to achieve or at least describe?]. Initially, i was
planning to use Lokahi to maintain the apache and tomcat servers, but
finally i do it with a combination of ant remote (to deploy binary and
config files) and a homegrown Java xml rpc API which call webmin rpc,
because i feel that i can control more things with this system. But like
i've said i still follow the project, servers managment is an
interesting area and there is still a lot of room for Lokahi (and java
based oss in this domain) to evolve and perhaps integrate some of my own
requirements.
Toback, Steve a écrit :
> This brings some questions to mind - namely what is causing this project
> to not gather continued attention.
>
> What's preventing adoption or continued improvement? (other than me
> lack of personal time to work on this, this summer)
>
>
I have contributed some code some time ago to support MySQL i would say
that i haven't been able to keep up with the code changes in order to
maintain this port. Also the mysql code has been put on a side svn
branch and IIRC there is ongoing work in trunk to have a ORM framework,
so basically my contributions will be useless after this work will be
done. I would have continued to contribute or at least improve my code
if it would have been useful but this has not been the case and i
believe (but haven't checked) that the refactoring with the ORM
framework has not been finished --> i'm reluctant to work again on the
project until the devs which had began to contribute this code have
finished it.
> Is the database really the halting factor? Or is there something else -
> Lack of apache 2.2 support? I honestly don't know.
>
>
IMHO, supporting only Oracle is a hurdle and it is very important to
support other databases. As an illustration of this, i hope this is not
off topic, i was considering using Ofbiz , a open source ERP, since a
long time ago (i'm aware of it since sometinhg like 5/6 years), but i
wasn't able to pay a oracle license for it and it was only supporting
this type of db. It's only this year that i have eventually decided to
use (and develop) it because it now support any db (since one or 2 years
i believe). I believe that since it support many dbs ofbiz has been used
by far more peoples than before. (but i have no evidences of this :-)
I also think that a binary distribution would be a good thing. And a
trivials bugs free release too, labeled 1.0 ready for prod :-) , in
order to be installed in corporate environments.
So many thanks for doing Lokahi, keep up the good work (but finish it :-),
My 2 cents,
PS: Sorry for my english and lack of nuances in my wording, i'm not
really good at this.
> Steve
>
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Tuesday, September 11, 2007 8:12 PM
> To: lokahi-dev@incubator.apache.org
> Subject: Participant Status?
>
> -- project status --
>
> The last word of discussion some 3 months ago was about infra, the
> creation of the lokahi wiki site. It has since been unused. Some
> banter on the tail end of ApacheCon EU/07 included ideas about docs
> and deployment help, and some ideas about DB backends.
>
> The last commit activity in the same timeframe were the beginnings
> of a jackrabbit connector, no other activity for commits@ since then.
>
> There has been no activity on private.
>
> -- commentary --
>
> Of course it was summer, nobody at the ASF expects measurable milestones
> etc in the development of open source. Things move at the speed of the
> project participants. Heathy/dead project definitions hide the fact
> that the code is there for people to use, and there may be either little
> to change in the current code (it just works), or things are just clear.
>
> However, there is identified a need to provide a non-proprietary
> database
> backend before the project graduates. There's also an identified need
> to
> add documentation of how to at least deploy and get started
> using/testing
> lokahi.
>
> Once those are done there really isn't a big reason to be in the
> incubator,
> except that the community is very small, which gives the IPMC and the
> board
> concern that it doesn't have enough interest to be maintained or
> overseen.
>
> The incubator PMC really needs some folks to speak up on this thread of
> their intent to remain (return to being) active at this project. It's
> amazing how the positive reception ("That's exactly what we we've been
> looking for!" or "That's what we were attempting to implement" or simply
> "Wow, you mean there actually is one out there???") There's a need,
> there
> is an audience. There's even (good) code. Are there participants?
>
> Bill
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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.
>
> ------------------------------------------------------------------------------
>
>
>
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
------------------------------------------------------------------------------
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: Participant Status?
Posted by Ludovic Maitre <lu...@free.fr>.
Hi Steve, all
As an old contributor which still follow the mailing list, i would like
to explain why i doesn't contribute nor use anymore Lokahi. It's because
at work we use (and i have contributed to develop) another system to
deploy j2ee webapps, a homegrown ant-remote solution with xml based
descriptors to describe the platforms/farms and the
products/applications to install [perhaps this is similar to what
smartfrog want to achieve or at least describe?]. Initially, i was
planning to use Lokahi to maintain the apache and tomcat servers, but
finally i do it with a combination of ant remote (to deploy binary and
config files) and a homegrown Java xml rpc API which call webmin rpc,
because i feel that i can control more things with this system. But like
i've said i still follow the project, servers managment is an
interesting area and there is still a lot of room for Lokahi (and java
based oss in this domain) to evolve and perhaps integrate some of my own
requirements.
Toback, Steve a écrit :
> This brings some questions to mind - namely what is causing this project
> to not gather continued attention.
>
> What's preventing adoption or continued improvement? (other than me
> lack of personal time to work on this, this summer)
>
>
I have contributed some code some time ago to support MySQL i would say
that i haven't been able to keep up with the code changes in order to
maintain this port. Also the mysql code has been put on a side svn
branch and IIRC there is ongoing work in trunk to have a ORM framework,
so basically my contributions will be useless after this work will be
done. I would have continued to contribute or at least improve my code
if it would have been useful but this has not been the case and i
believe (but haven't checked) that the refactoring with the ORM
framework has not been finished --> i'm reluctant to work again on the
project until the devs which had began to contribute this code have
finished it.
> Is the database really the halting factor? Or is there something else -
> Lack of apache 2.2 support? I honestly don't know.
>
>
IMHO, supporting only Oracle is a hurdle and it is very important to
support other databases. As an illustration of this, i hope this is not
off topic, i was considering using Ofbiz , a open source ERP, since a
long time ago (i'm aware of it since sometinhg like 5/6 years), but i
wasn't able to pay a oracle license for it and it was only supporting
this type of db. It's only this year that i have eventually decided to
use (and develop) it because it now support any db (since one or 2 years
i believe). I believe that since it support many dbs ofbiz has been used
by far more peoples than before. (but i have no evidences of this :-)
I also think that a binary distribution would be a good thing. And a
trivials bugs free release too, labeled 1.0 ready for prod :-) , in
order to be installed in corporate environments.
So many thanks for doing Lokahi, keep up the good work (but finish it :-),
My 2 cents,
PS: Sorry for my english and lack of nuances in my wording, i'm not
really good at this.
> Steve
>
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Tuesday, September 11, 2007 8:12 PM
> To: lokahi-dev@incubator.apache.org
> Subject: Participant Status?
>
> -- project status --
>
> The last word of discussion some 3 months ago was about infra, the
> creation of the lokahi wiki site. It has since been unused. Some
> banter on the tail end of ApacheCon EU/07 included ideas about docs
> and deployment help, and some ideas about DB backends.
>
> The last commit activity in the same timeframe were the beginnings
> of a jackrabbit connector, no other activity for commits@ since then.
>
> There has been no activity on private.
>
> -- commentary --
>
> Of course it was summer, nobody at the ASF expects measurable milestones
> etc in the development of open source. Things move at the speed of the
> project participants. Heathy/dead project definitions hide the fact
> that the code is there for people to use, and there may be either little
> to change in the current code (it just works), or things are just clear.
>
> However, there is identified a need to provide a non-proprietary
> database
> backend before the project graduates. There's also an identified need
> to
> add documentation of how to at least deploy and get started
> using/testing
> lokahi.
>
> Once those are done there really isn't a big reason to be in the
> incubator,
> except that the community is very small, which gives the IPMC and the
> board
> concern that it doesn't have enough interest to be maintained or
> overseen.
>
> The incubator PMC really needs some folks to speak up on this thread of
> their intent to remain (return to being) active at this project. It's
> amazing how the positive reception ("That's exactly what we we've been
> looking for!" or "That's what we were attempting to implement" or simply
> "Wow, you mean there actually is one out there???") There's a need,
> there
> is an audience. There's even (good) code. Are there participants?
>
> Bill
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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.
>
> ------------------------------------------------------------------------------
>
>
>
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
RE: Participant Status?
Posted by "Toback, Steve" <st...@merck.com>.
This brings some questions to mind - namely what is causing this project
to not gather continued attention.
What's preventing adoption or continued improvement? (other than me
lack of personal time to work on this, this summer)
Is the database really the halting factor? Or is there something else -
Lack of apache 2.2 support? I honestly don't know.
Steve
-----Original Message-----
From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
Sent: Tuesday, September 11, 2007 8:12 PM
To: lokahi-dev@incubator.apache.org
Subject: Participant Status?
-- project status --
The last word of discussion some 3 months ago was about infra, the
creation of the lokahi wiki site. It has since been unused. Some
banter on the tail end of ApacheCon EU/07 included ideas about docs
and deployment help, and some ideas about DB backends.
The last commit activity in the same timeframe were the beginnings
of a jackrabbit connector, no other activity for commits@ since then.
There has been no activity on private.
-- commentary --
Of course it was summer, nobody at the ASF expects measurable milestones
etc in the development of open source. Things move at the speed of the
project participants. Heathy/dead project definitions hide the fact
that the code is there for people to use, and there may be either little
to change in the current code (it just works), or things are just clear.
However, there is identified a need to provide a non-proprietary
database
backend before the project graduates. There's also an identified need
to
add documentation of how to at least deploy and get started
using/testing
lokahi.
Once those are done there really isn't a big reason to be in the
incubator,
except that the community is very small, which gives the IPMC and the
board
concern that it doesn't have enough interest to be maintained or
overseen.
The incubator PMC really needs some folks to speak up on this thread of
their intent to remain (return to being) active at this project. It's
amazing how the positive reception ("That's exactly what we we've been
looking for!" or "That's what we were attempting to implement" or simply
"Wow, you mean there actually is one out there???") There's a need,
there
is an audience. There's even (good) code. Are there participants?
Bill
------------------------------------------------------------------------------
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 and Smartfrog
Posted by Steve Loughran <st...@apache.org>.
Noel J. Bergman wrote:
> Steve,
>
>>> I think that there appears to be a very natural synergy between
>>> Lokahi and Smartfrog, beneficial to both communities, if HP
>>> would relicense Smartfrog under a suitable license.
>
>> 1. getting hp to OSS it at all was hard enough
>
> :-)
>
>> 3. We dont consider linking, bundling the JAR or extending existing
>> classes as LPGL derivative activites
>
> AIUI from comments by Roy, HP would have to add that to the license, since HP doesn't own the LGPL, the FSF does. One of the dangers of using someone else's license that they feel entitled to enforce.
The FSF owns everything with a GPL license Noel, you know that :)
One thing we are going to have to do in SmartFrog is create a GPL
repository on sourceforge to host pure GPL stuff, the moment we go
deeper into MySQL configuration. To date I'm just starting/stopping
mysql with different arguments, and my extended mysql JDBC driver uses
their extra ping() method by introspecting and binding to any JDBC
driver with a ping() method; no preference for mysql in there. But the
mysql rules are quite complex and it would be cleaner to isolate it.
And that is where SmartFrog does have something else to offer lokahi, as
if you are trying to use mysql for the CMDB, then you have the problem
of starting/stopping and configuring that little toy, which is not
something you can easily do in apache code at all.
>
> In any event, isn't the real issue --- as you say, LGPL notwithstanding --- how do we see the synergies, and how can we leverage the community efforts?
Better App server support would be excellent. To date we support
-any app server with drag/drop deployment, starting them using Java.
There's no detailed configuration here though, other than what can be
done with properties on the JVM
-Jetty. This is very good to work with as it lets us bring up servlets
in-VM. It may not people want to run their apps on, but it is how we
normally host our own HTTP stuff. It also lets us bypass creating WAR
files at all; doing all servlet configuration in .sf files.
-Cactus. Starting and stopping stuff.
-apache httpd. Including load monitoring, which can plug in to services
that allocate new physical/virtual machines on demand
-lots of really good system testing tools. We can deploy different
configurations then run junit tests against them, collecting the
results. Want to host the httpclient/selenium tests on different
machines from your app server? Just change one line of the smartfrog file.
What I'd like for the www libraries is far better control of things like
security, and any other stuff you set up in the app server config files,
rather than the war/ear XML Files.
> You mentioned:
>
>> come up with an API for decoupling configurable things from
>> the runtimes that configure them.
>
> What about a common schema? Etc.?
We have pretty good MX4J integration with JMX, though since we moved to
Java5+ only last month, could switch to 'classic' JMX, which may be a
starting point. Then theres things like
-an API to read/write attributes. We dont have a classic single CMDB,
just a graph of deployed things that have their own attributes and
children (and can implement their own accessors to both). Maybe JNDI
would work here, even though its a pretty painful API to implement and use.
-providing an API to do logging. We have a bridge to commons-logging
at the front, and Log4J at the back, but our internal logging stuff is
more complex as it is designed to give you different logs per instance,
rather than just per class, and route log info across the network when
needed.
-common lifecycle.
>
>> We could do this in apache-land and have smartfrog an implementation.
>
> I'm happy to have played an instigator role here. Are you and others interested in pushing forward, and is there a perceived value?
I'll get on the lokahi-dev mail list and discuss things there. For us,
something we can wrap easily is best. For you, you should think about
how you'd use lokahi under smartfrog, both in testing lokahi, and in a
production system.
-steve
RE: Lokahi and Smartfrog
Posted by "Noel J. Bergman" <no...@devtech.com>.
Steve,
> > I think that there appears to be a very natural synergy between
> > Lokahi and Smartfrog, beneficial to both communities, if HP
> > would relicense Smartfrog under a suitable license.
> 1. getting hp to OSS it at all was hard enough
:-)
> 3. We dont consider linking, bundling the JAR or extending existing
> classes as LPGL derivative activites
AIUI from comments by Roy, HP would have to add that to the license, since HP doesn't own the LGPL, the FSF does. One of the dangers of using someone else's license that they feel entitled to enforce.
In any event, isn't the real issue --- as you say, LGPL notwithstanding --- how do we see the synergies, and how can we leverage the community efforts?
You mentioned:
> come up with an API for decoupling configurable things from
> the runtimes that configure them.
What about a common schema? Etc.?
> We could do this in apache-land and have smartfrog an implementation.
I'm happy to have played an instigator role here. Are you and others interested in pushing forward, and is there a perceived value?
--- Noel
Re: Lokahi and Smartfrog
Posted by Steve Loughran <st...@apache.org>.
Noel J. Bergman wrote:
> Has anyone/everyone seen Smartfrog (http://www.smartfrog.org)? I think that there appears to be a very natural synergy between Lokahi and Smartfrog, beneficial to both communities, if HP would relicense Smartfrog under a suitable license.
>
> --- Noel
>
> cc: Steve Loughran
>
>
1. getting hp to OSS it at all was hard enough
2. at least HP didnt make up its own OSI compatible license
3. We dont consider linking, bundling the JAR or extending existing
classes as LPGL derivative activites
4. There is a branch (not the main branch, but we're planning it), that
uses OSGI as the classloading, binding framework.
5. Similarly, there's some stuff that uses introspection, so that
smartfrog classes dont need to be extended to make an SF component.
That's not complete yet, but its a starting point.
6. We could always work together for me to produce a wrapper for Lokahi
in the SF codebase, or even we could create an open BSD-licensed corner
of sourceforge, so that the Apache interpretation of LPGL and Java
inheritance wouldnt kick in, yet I could give others write access to the
repository.
One thing we could do, LGPL notwithstanding, is come up with an API for
decoupling configurable things from teh runtimes that configure them.
That actually makes a lot of sense, because if your product commits to a
single config infrastructure, then you are rejecting anyone who wants to
use you in different ways.
Something on the lines of
-commons-logging for logging
-JNDI for data lookup
-some other set of interfaces API for lifecycle callbacks and operations
We could do this in apache-land and have smartfrog an implementation.
-steve
Lokahi and Smartfrog
Posted by "Noel J. Bergman" <no...@devtech.com>.
Has anyone/everyone seen Smartfrog (http://www.smartfrog.org)? I think that there appears to be a very natural synergy between Lokahi and Smartfrog, beneficial to both communities, if HP would relicense Smartfrog under a suitable license.
--- Noel
cc: Steve Loughran