Dojo discussion - opensourcing the jsf dojo components project

[Werner Punz-2]

Hello everyone

as some know, I have been working semi silently the last months in my
opensource time on a jsf dojo layer which is rather extensive, it is a
thin layer on top of dojo currently encapsulating around 23-25 of the
existing dijit components
(around 98% of the dijit components)

I am reaching the state of being able to opensource the codebase, it
still is not done yet, but the core is rather stable and a lot of
components work well enough already so that I am not ashamed of it
anymore showing it publicly although it is still major road ahead till beta.

One thing, it was planned as tomahawk extension to get dojo out of
tomahawk, but it is very extensive and the tomahawk dependencies are not
that much so getting tomahawk out entirely would be possible.

Following:

a) It uses weblets and tomahawk for resource loading and relocation
(weblets for resource loading, tomahawk for resource relocation)

b) It has its own codegen, which was derived out of the need of having
to have something fast, and the old ones were very undocumented and the
new ones not ready. The codegens basically build up a data structure in
groovy with the component descriptors and then send the data structures
down into specialized velocity templates. I know we now have a working
codegen infrastructure, but moving all this over is not my biggest
priority since my own self rolled parserless solution works very well
for the scope of the complib and the component descriptors are very tight.

As for jsf currently JSF 1.1 is still the sourcebase, although I test it
with JSF 1.2, a direct adjustment towards JSF 1.2 can be done thanks to
the codegens.

Have in mind the codebase I am dropping down is rather huge, with around
30.000 - 40.000 locs (Excluding the table) of the components alone most
of the code being generated, and for now also 1-2 dojo versions in the
sourcebase until we can move the dojo builds into a separate maven repo
and load it during the build process.

Also have in mind that currently I drop all generated code into the
java/src hierarchy in its own dirs with clear comments in the files
that they should not be added! An approach which would make sense in my
opinion but others have opposed in the past (I simply love to have the
sources in one place as much as possible)

Also the table which will be added also will have a large codebase, the
customer we have developed the table for, has cleared all the apache
legal stuff, and it is just a matter of getting clearance of the code
from the legal departement to be able to add it.

A demo of the components will be shown in 1-2 weeks, some people in the
list have seen some of the components in action already last week.

So my question is, are we going to host it inside of myfaces as its own
subproject or as part of the sandbox or maybe I can move the codebase
over to its own project outside of apache (jsfcomp for instance might be
a perfect place until the entire complib is matured enough)

[Ernst Fastl]

Hi Werner,

I think it would be good to have it in MyFaces either as a subproject
or for starter
if anyone feels it might not be mature enough yet in the sandbox. It
would be great
to have it around in tomahawk seeing we could really use some "new fancy"
Web 2.0 components to make tomahawk again more attractive for the end user
in times of RichFaces, ICEFaces, ...

just my 2 cents

Ernst


On 7/7/08, Werner Punz <werner.punz@...> wrote:

> Hello everyone
>
> as some know, I have been working semi silently the last months in my
> opensource time on a jsf dojo layer which is rather extensive, it is a
> thin layer on top of dojo currently encapsulating around 23-25 of the
> existing dijit components
> (around 98% of the dijit components)
>
> I am reaching the state of being able to opensource the codebase, it
> still is not done yet, but the core is rather stable and a lot of
> components work well enough already so that I am not ashamed of it
> anymore showing it publicly although it is still major road ahead till beta.
>
> One thing, it was planned as tomahawk extension to get dojo out of
> tomahawk, but it is very extensive and the tomahawk dependencies are not
> that much so getting tomahawk out entirely would be possible.
>
> Following:
>
> a) It uses weblets and tomahawk for resource loading and relocation
> (weblets for resource loading, tomahawk for resource relocation)
>
> b) It has its own codegen, which was derived out of the need of having
> to have something fast, and the old ones were very undocumented and the
> new ones not ready. The codegens basically build up a data structure in
> groovy with the component descriptors and then send the data structures
> down into specialized velocity templates. I know we now have a working
> codegen infrastructure, but moving all this over is not my biggest
> priority since my own self rolled parserless solution works very well
> for the scope of the complib and the component descriptors are very tight.
>
> As for jsf currently JSF 1.1 is still the sourcebase, although I test it
> with JSF 1.2, a direct adjustment towards JSF 1.2 can be done thanks to
> the codegens.
>
> Have in mind the codebase I am dropping down is rather huge, with around
> 30.000 - 40.000 locs (Excluding the table) of the components alone most
> of the code being generated, and for now also 1-2 dojo versions in the
> sourcebase until we can move the dojo builds into a separate maven repo
> and load it during the build process.
>
> Also have in mind that currently I drop all generated code into the
> java/src hierarchy in its own dirs with clear comments in the files
> that they should not be added! An approach which would make sense in my
> opinion but others have opposed in the past (I simply love to have the
> sources in one place as much as possible)
>
> Also the table which will be added also will have a large codebase, the
> customer we have developed the table for, has cleared all the apache
> legal stuff, and it is just a matter of getting clearance of the code
> from the legal departement to be able to add it.
>
> A demo of the components will be shown in 1-2 weeks, some people in the
> list have seen some of the components in action already last week.
>
> So my question is, are we going to host it inside of myfaces as its own
> subproject or as part of the sandbox or maybe I can move the codebase
> over to its own project outside of apache (jsfcomp for instance might be
> a perfect place until the entire complib is matured enough)
>
>
>
>

[Werner Punz-2]

Ernst Fastl schrieb:

> Hi Werner,
>
> I think it would be good to have it in MyFaces either as a subproject
> or for starter
> if anyone feels it might not be mature enough yet in the sandbox. It
> would be great
> to have it around in tomahawk seeing we could really use some "new fancy"
> Web 2.0 components to make tomahawk again more attractive for the end user
> in times of RichFaces, ICEFaces, ...
>
> just my 2 cents
>
> Ernst
>

Ok adding it to the sandbox would mean that we break the existing dojo
based components a mixing of dojo 0.4 components and 1.1 components
would not work in the same page.
We can move over the existing ones anyway, but that would take some time
also the removal of the dojo codebase out of core tomahawk.
I would add a comment in the demo that mixing both codebases for now is
not possible until we have moved the codebase over.
That would be the way for the sandbox.

(Moving over the sandbox comoponents is on my todo list ones I have all
dojo components working reasonably well)

[Ernst Fastl]

If moving to sandbox complicates the process a lot then maybe it would
be the better idea to, as you initially suggested, start a "tomahawk-dojo"
migrate and move the dojo stuff in the sandbox to there and get rid of dojo
in the sandbox. Has there already been a decision if we want to have
the dojo stuff in a separate module? If not - would that be subject for a vote?

On 7/7/08, Werner Punz <werner.punz@...> wrote:

> Ernst Fastl schrieb:
>> Hi Werner,
>>
>> I think it would be good to have it in MyFaces either as a subproject
>> or for starter
>> if anyone feels it might not be mature enough yet in the sandbox. It
>> would be great
>> to have it around in tomahawk seeing we could really use some "new fancy"
>> Web 2.0 components to make tomahawk again more attractive for the end user
>> in times of RichFaces, ICEFaces, ...
>>
>> just my 2 cents
>>
>> Ernst
>>
>
> Ok adding it to the sandbox would mean that we break the existing dojo
> based components a mixing of dojo 0.4 components and 1.1 components
> would not work in the same page.
> We can move over the existing ones anyway, but that would take some time
> also the removal of the dojo codebase out of core tomahawk.
> I would add a comment in the demo that mixing both codebases for now is
> not possible until we have moved the codebase over.
> That would be the way for the sandbox.
>
> (Moving over the sandbox comoponents is on my todo list ones I have all
> dojo components working reasonably well)
>
>
>

[Werner Punz-2]

No decision yet...

I would call it extensions, or something alike not really dojo
maybe we add other frameworks as well in the long run.

Werner


Ernst Fastl schrieb:

> If moving to sandbox complicates the process a lot then maybe it would
> be the better idea to, as you initially suggested, start a "tomahawk-dojo"
> migrate and move the dojo stuff in the sandbox to there and get rid of dojo
> in the sandbox. Has there already been a decision if we want to have
> the dojo stuff in a separate module? If not - would that be subject for a vote?
>
> On 7/7/08, Werner Punz <werner.punz@...> wrote:
>> Ernst Fastl schrieb:
>>> Hi Werner,
>>>
>>> I think it would be good to have it in MyFaces either as a subproject
>>> or for starter
>>> if anyone feels it might not be mature enough yet in the sandbox. It
>>> would be great
>>> to have it around in tomahawk seeing we could really use some "new fancy"
>>> Web 2.0 components to make tomahawk again more attractive for the end user
>>> in times of RichFaces, ICEFaces, ...
>>>
>>> just my 2 cents
>>>
>>> Ernst
>>>
>> Ok adding it to the sandbox would mean that we break the existing dojo
>> based components a mixing of dojo 0.4 components and 1.1 components
>> would not work in the same page.
>> We can move over the existing ones anyway, but that would take some time
>> also the removal of the dojo codebase out of core tomahawk.
>> I would add a comment in the demo that mixing both codebases for now is
>> not possible until we have moved the codebase over.
>> That would be the way for the sandbox.
>>
>> (Moving over the sandbox comoponents is on my todo list ones I have all
>> dojo components working reasonably well)
>>
>>
>>
>

[Matthias Wessendorf-4]

> So my question is, are we going to host it inside of myfaces as its own
> subproject or as part of the sandbox or maybe I can move the codebase over
> to its own project outside of apache (jsfcomp for instance might be a
> perfect place until the entire complib is matured enough)

since it was developed outside of the Apache community,
this is something that needs

a) incubation
OR
b) software grant

Since that is a complete lib, perhaps a) is needed.
This is pretty similar to the "flex" offerings that was
discussed here recently.

Perhaps I am wrong, but my feelings indicate that.

-Matthias

>
>
>
>



--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Werner Punz-2]

Matthias Wessendorf schrieb:

>> So my question is, are we going to host it inside of myfaces as its own
>> subproject or as part of the sandbox or maybe I can move the codebase over
>> to its own project outside of apache (jsfcomp for instance might be a
>> perfect place until the entire complib is matured enough)
>
> since it was developed outside of the Apache community,
> this is something that needs
>
> a) incubation
> OR
> b) software grant
>

Not sure if the development is outside of the apache community
the I wrote basically every single line of code so far myself.
(Except for dojo)

The extensive table component which is pending, is a shared work
with all people involved having committer rights or having
at least signed the the apache contributors license agreement.

The only thing not done yet is basically that it is not committed
into the core codebase but hosted privately.

[Matthias Wessendorf-4]

> Not sure if the development is outside of the apache community
> the I wrote basically every single line of code so far myself.

but not under an Apache umbrella.

> (Except for dojo)
>
> The extensive table component which is pending, is a shared work
> with all people involved having committer rights or having
> at least signed the the apache contributors license agreement.

I don't understand that.

>
> The only thing not done yet is basically that it is not committed
> into the core codebase but hosted privately.

so, it's not part of the Apache umbrella, yet.

So, IMO the best is to give a heads-up on the general@incubator list.
So see, what their feeling is about this. They deal with these type of
things more frequently than everybody of us.

Generally, I think it is a good project.

-M
>
>



--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Werner Punz-2]

Matthias Wessendorf schrieb:

>> Not sure if the development is outside of the apache community
>> the I wrote basically every single line of code so far myself.
>
> but not under an Apache umbrella.
>
>> (Except for dojo)
>>
>> The extensive table component which is pending, is a shared work
>> with all people involved having committer rights or having
>> at least signed the the apache contributors license agreement.
>
> I don't understand that.
>

Well there will be a table component added to the project
which can do much more than the dojo table but is similar in its dynamic
nature.
The code was developed for a customer who gave the agreement to
opensource it as soon as it has passed the legal departement.
The contributors license agreements all were signed of all the people
involved in the devlopment.
This component hasnt made it into the codebase yet but will be added
as soon as possible.
This is basically the only codebase so far which I did not have fully
developed myself, the rest of the code outside of dojo was 100% written
by me and can be confirmed by checkin logs!


>> The only thing not done yet is basically that it is not committed
>> into the core codebase but hosted privately.
>
> so, it's not part of the Apache umbrella, yet.
>
Well best probably is to ask there, but I dont think there should
be too much of a problem of getting it in directly without
having to go through the incubator, due to the nature of the code being
developed 100% by me.


> So, IMO the best is to give a heads-up on the general@incubator list.
> So see, what their feeling is about this. They deal with these type of
> things more frequently than everybody of us.
>
> Generally, I think it is a good project.
>

Thanks a lot...

:-)

[Matthias Wessendorf-4]

> Well best probably is to ask there, but I dont think there should
> be too much of a problem of getting it in directly without
> having to go through the incubator, due to the nature of the code being
> developed 100% by me.

I am fine with that. But I just want to make sure everything is fine
and correct with the Apache guidelines. Since the scope of the
contribution is a (to my understanding) separate project. Perhaps
a software grant is pretty fine. Perhaps even that is not needed.

Don't get me wrong. I am not against this
(I was pinged offline already asking "why").
So, again I am not against it. I just want to make sure
we follow the right way.

-M

>
>
>> So, IMO the best is to give a heads-up on the general@incubator list.
>> So see, what their feeling is about this. They deal with these type of
>> things more frequently than everybody of us.
>>
>> Generally, I think it is a good project.
>>
>
> Thanks a lot...
>
> :-)
>
>

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Martin Marinschek]

Yes, definitely incubator should be kept in the loop. But I feel a
Grant should be enough, if it is part of the sandbox.

regards,

Martin

On 7/7/08, Matthias Wessendorf <matzew@...> wrote:

>> Well best probably is to ask there, but I dont think there should
>> be too much of a problem of getting it in directly without
>> having to go through the incubator, due to the nature of the code being
>> developed 100% by me.
>
> I am fine with that. But I just want to make sure everything is fine
> and correct with the Apache guidelines. Since the scope of the
> contribution is a (to my understanding) separate project. Perhaps
> a software grant is pretty fine. Perhaps even that is not needed.
>
> Don't get me wrong. I am not against this
> (I was pinged offline already asking "why").
> So, again I am not against it. I just want to make sure
> we follow the right way.
>
> -M
>
>>
>>
>>> So, IMO the best is to give a heads-up on the general@incubator list.
>>> So see, what their feeling is about this. They deal with these type of
>>> things more frequently than everybody of us.
>>>
>>> Generally, I think it is a good project.
>>>
>>
>> Thanks a lot...
>>
>> :-)
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>

--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[Werner Punz-2]

Ok I dropped a mail in the incubator mailing list lets wait
for the answers.

Werner


Martin Marinschek schrieb:

> Yes, definitely incubator should be kept in the loop. But I feel a
> Grant should be enough, if it is part of the sandbox.
>
> regards,
>
> Martin
>
> On 7/7/08, Matthias Wessendorf <matzew@...> wrote:
>>> Well best probably is to ask there, but I dont think there should
>>> be too much of a problem of getting it in directly without
>>> having to go through the incubator, due to the nature of the code being
>>> developed 100% by me.
>> I am fine with that. But I just want to make sure everything is fine
>> and correct with the Apache guidelines. Since the scope of the
>> contribution is a (to my understanding) separate project. Perhaps
>> a software grant is pretty fine. Perhaps even that is not needed.
>>
>> Don't get me wrong. I am not against this
>> (I was pinged offline already asking "why").
>> So, again I am not against it. I just want to make sure
>> we follow the right way.
>>
>> -M
>>
>>>
>>>> So, IMO the best is to give a heads-up on the general@incubator list.
>>>> So see, what their feeling is about this. They deal with these type of
>>>> things more frequently than everybody of us.
>>>>
>>>> Generally, I think it is a good project.
>>>>
>>> Thanks a lot...
>>>
>>> :-)
>>>
>>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> further stuff:
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> mail: matzew-at-apache-dot-org
>>
>
>

It's great that people are thinking carefully about the right way to
handle this new code. But after some pondering, I'm happy for it to go
directly into a sandbox here and not through the incubator.

My reasons are:

Incubation is necessary when a brand-new project is created, in order to
be sure that a new non-apache development group learn to use
apache-style collaboration. But that's not relevant in this case; Werner
is familiar with all this and I'l confident he will make sure everything
happens in the open.

Incubation is also necessary when the code is for an existing project
but that existing project doesn't have committers that will
review/commit patches for the new code and doesn't want to grant new
unknown people commit rights immediately. But again that's not relevant
here; Werner will presumably be acting as reviewer for patches.

So all we need to be concerned about here is that the code is legally
unencumbered (a grant should do that), and that there is enough of a
community to maintain it long term (which some time in the sandbox can
test). And of course that we're all happy with the architecture etc. But
for that we need to see the code :-)

I can't see any other reasons for requiring incubation...

Definitely worth asking the incubator group their opinion too, but
hopefully they just push it back to us..

Regards, Simon

Martin Marinschek schrieb:

> Yes, definitely incubator should be kept in the loop. But I feel a
> Grant should be enough, if it is part of the sandbox.
>
> regards,
>
> Martin
>
> On 7/7/08, Matthias Wessendorf <matzew@...> wrote:
>  
>>> Well best probably is to ask there, but I dont think there should
>>> be too much of a problem of getting it in directly without
>>> having to go through the incubator, due to the nature of the code being
>>> developed 100% by me.
>>>      
>> I am fine with that. But I just want to make sure everything is fine
>> and correct with the Apache guidelines. Since the scope of the
>> contribution is a (to my understanding) separate project. Perhaps
>> a software grant is pretty fine. Perhaps even that is not needed.
>>
>> Don't get me wrong. I am not against this
>> (I was pinged offline already asking "why").
>> So, again I am not against it. I just want to make sure
>> we follow the right way.
>>
>> -M
>>
>>    
>>>      
>>>> So, IMO the best is to give a heads-up on the general@incubator list.
>>>> So see, what their feeling is about this. They deal with these type of
>>>> things more frequently than everybody of us.
>>>>
>>>> Generally, I think it is a good project.
>>>>
>>>>        

[Martin Marinschek]

Hi Simon,

On 7/7/08, simon.kitching@... <simon.kitching@...> wrote:
> It's great that people are thinking carefully about the right way to
> handle this new code. But after some pondering, I'm happy for it to go
> directly into a sandbox here and not through the incubator.

I would say so as well - a grant should perfectly be alright.

regards,

Martin

[Matthias Wessendorf-4]

Hi,

I think it is fine here. My main reason for the incubator list was
just b/c this project
was completely developed offline. So, it is (to me) a new project. That's all.

For me, a software grant would be pretty much enough.

-M

On Mon, Jul 7, 2008 at 5:03 PM, simon.kitching@...
<simon.kitching@...> wrote:

> It's great that people are thinking carefully about the right way to handle
> this new code. But after some pondering, I'm happy for it to go directly
> into a sandbox here and not through the incubator.
>
> My reasons are:
>
> Incubation is necessary when a brand-new project is created, in order to be
> sure that a new non-apache development group learn to use apache-style
> collaboration. But that's not relevant in this case; Werner is familiar with
> all this and I'l confident he will make sure everything happens in the open.
>
> Incubation is also necessary when the code is for an existing project but
> that existing project doesn't have committers that will review/commit
> patches for the new code and doesn't want to grant new unknown people commit
> rights immediately. But again that's not relevant here; Werner will
> presumably be acting as reviewer for patches.
>
> So all we need to be concerned about here is that the code is legally
> unencumbered (a grant should do that), and that there is enough of a
> community to maintain it long term (which some time in the sandbox can
> test). And of course that we're all happy with the architecture etc. But for
> that we need to see the code :-)
>
> I can't see any other reasons for requiring incubation...
>
> Definitely worth asking the incubator group their opinion too, but hopefully
> they just push it back to us..
>
> Regards, Simon
>
> Martin Marinschek schrieb:
>>
>> Yes, definitely incubator should be kept in the loop. But I feel a
>> Grant should be enough, if it is part of the sandbox.
>>
>> regards,
>>
>> Martin
>>
>> On 7/7/08, Matthias Wessendorf <matzew@...> wrote:
>>
>>>>
>>>> Well best probably is to ask there, but I dont think there should
>>>> be too much of a problem of getting it in directly without
>>>> having to go through the incubator, due to the nature of the code being
>>>> developed 100% by me.
>>>>
>>>
>>> I am fine with that. But I just want to make sure everything is fine
>>> and correct with the Apache guidelines. Since the scope of the
>>> contribution is a (to my understanding) separate project. Perhaps
>>> a software grant is pretty fine. Perhaps even that is not needed.
>>>
>>> Don't get me wrong. I am not against this
>>> (I was pinged offline already asking "why").
>>> So, again I am not against it. I just want to make sure
>>> we follow the right way.
>>>
>>> -M
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> So, IMO the best is to give a heads-up on the general@incubator list.
>>>>> So see, what their feeling is about this. They deal with these type of
>>>>> things more frequently than everybody of us.
>>>>>
>>>>> Generally, I think it is a good project.
>>>>>
>>>>>
>
>

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Matthias Wessendorf-4]

On general@... Craig Russel (SUN)
agreed that a software grant is fine.

-M

On Mon, Jul 7, 2008 at 5:29 PM, Matthias Wessendorf <matzew@...> wrote:

> Hi,
>
> I think it is fine here. My main reason for the incubator list was
> just b/c this project
> was completely developed offline. So, it is (to me) a new project. That's all.
>
> For me, a software grant would be pretty much enough.
>
> -M
>
> On Mon, Jul 7, 2008 at 5:03 PM, simon.kitching@...
> <simon.kitching@...> wrote:
>> It's great that people are thinking carefully about the right way to handle
>> this new code. But after some pondering, I'm happy for it to go directly
>> into a sandbox here and not through the incubator.
>>
>> My reasons are:
>>
>> Incubation is necessary when a brand-new project is created, in order to be
>> sure that a new non-apache development group learn to use apache-style
>> collaboration. But that's not relevant in this case; Werner is familiar with
>> all this and I'l confident he will make sure everything happens in the open.
>>
>> Incubation is also necessary when the code is for an existing project but
>> that existing project doesn't have committers that will review/commit
>> patches for the new code and doesn't want to grant new unknown people commit
>> rights immediately. But again that's not relevant here; Werner will
>> presumably be acting as reviewer for patches.
>>
>> So all we need to be concerned about here is that the code is legally
>> unencumbered (a grant should do that), and that there is enough of a
>> community to maintain it long term (which some time in the sandbox can
>> test). And of course that we're all happy with the architecture etc. But for
>> that we need to see the code :-)
>>
>> I can't see any other reasons for requiring incubation...
>>
>> Definitely worth asking the incubator group their opinion too, but hopefully
>> they just push it back to us..
>>
>> Regards, Simon
>>
>> Martin Marinschek schrieb:
>>>
>>> Yes, definitely incubator should be kept in the loop. But I feel a
>>> Grant should be enough, if it is part of the sandbox.
>>>
>>> regards,
>>>
>>> Martin
>>>
>>> On 7/7/08, Matthias Wessendorf <matzew@...> wrote:
>>>
>>>>>
>>>>> Well best probably is to ask there, but I dont think there should
>>>>> be too much of a problem of getting it in directly without
>>>>> having to go through the incubator, due to the nature of the code being
>>>>> developed 100% by me.
>>>>>
>>>>
>>>> I am fine with that. But I just want to make sure everything is fine
>>>> and correct with the Apache guidelines. Since the scope of the
>>>> contribution is a (to my understanding) separate project. Perhaps
>>>> a software grant is pretty fine. Perhaps even that is not needed.
>>>>
>>>> Don't get me wrong. I am not against this
>>>> (I was pinged offline already asking "why").
>>>> So, again I am not against it. I just want to make sure
>>>> we follow the right way.
>>>>
>>>> -M
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> So, IMO the best is to give a heads-up on the general@incubator list.
>>>>>> So see, what their feeling is about this. They deal with these type of
>>>>>> things more frequently than everybody of us.
>>>>>>
>>>>>> Generally, I think it is a good project.
>>>>>>
>>>>>>
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org