You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/11/12 09:37:21 UTC
[PROPOSAL] Avalon Components project
Niclas Hedhman wrote:
>On Tuesday 11 November 2003 19:48, Eric Pugh wrote:
>
>
>>And, since I have lots of ideas for components that all have licensing
>>issues, why not have a sf.net site? Maybe instead of Avalonia, just call
>>it avalon-components..
>>
>>
>
>I, for one, agree... I think the only issue with the more hard core Apache
>guys (I'm not pointing a big finger at you Stephen) is the "endorsement",
>implied or otherwise, that Avalonia or avalon-components, is given.
>
IM[HC]O, there are a number of different subjects
(a) the barrier to entry
(b) licensing
(c) endorcement
The barrier to entry is a pure policy decision that can be made by the
entity that is asserting oversite - this should not be used as an
argument for or against ASF versus SF. Equally components using non-ASF
compatible resources should not impact a ASF/SF decision bacause this is
simply a question of development time downloading (and seperate from
deployment). Lastly - the question of endorcement - AFAICS, endorcement
by Avalon requires oversite by Avalon which leads me to an alternative
proposition.
The proposal is a Avalon Component project here at Apache - seperate but
aligned with Avalon. The project would establish policies that
facilitated a lower barrier to entry of new component iniatives
(typically micro-projects dealing with a specific component
implementation) much in the same way that common manages new projects.
We could bootstrap the thing by transfering the current
avalon-components cvs to the new project and possibly well as
incorporation of iniative such the FTP project.
In this scenario - the new project would establish a PMC responsible for
oversite, content would be licensed under ASL, and the relationship
between Avalon and the new project would include our focus on the tools
and technologies dealing with aspects such as technical complicance,
validation test suites, component repository tools, etc.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 12 November 2003 16:37, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> >On Tuesday 11 November 2003 19:48, Eric Pugh wrote:
> >>And, since I have lots of ideas for components that all have licensing
> >>issues, why not have a sf.net site? Maybe instead of Avalonia, just call
> >>it avalon-components..
> >
> >I, for one, agree... I think the only issue with the more hard core Apache
> >guys (I'm not pointing a big finger at you Stephen) is the "endorsement",
> >implied or otherwise, that Avalonia or avalon-components, is given.
>
> IM[HC]O, there are a number of different subjects
>
> (a) the barrier to entry
> (b) licensing
> (c) endorcement
Agree.
> The barrier to entry is a pure policy decision that can be made by the
> entity that is asserting oversite[sic!].
Ok... "Contribute a component -> Committer status" ?
> Equally components using non-ASF
> compatible resources should not impact a ASF/SF decision bacause this is
> simply a question of development time downloading (and seperate from
> deployment).
I think Cocoon have gone down that road and are a bit confused over what
constitutes "derived work" in the GPL license. To compile against GPLd code,
you need the JAR (or source), which you can't host/distribute. OTOH, if you
make dummy classes just for the compilation, and if needed at deployment, the
user have to pick up the GPLd elsewhere, then wouldn't the mock classes be
"derived work"? GPL is also a very "weird" license, and open to a lot of
interpretations, and I think that's the reason why ASF board decided to
exclude all (L)GPL code dependency from the codebases.
> Lastly - the question of endorcement - AFAICS, endorcement
> by Avalon requires oversite by Avalon which leads me to an alternative
> proposition.
That is arguable. Comparison, Tiger Woods endorse Nike products, but don't
oversee the product development ;o)
Or more closer to home, MySQL officially endorsed the JDBC driver from (forgot
who) long before it became an official driver.
It is a matter of "to which level"... But never mind.
> The proposal is a Avalon Component project here at Apache - seperate but
> aligned with Avalon. The project would establish policies that
> facilitated a lower barrier to entry of new component iniatives
> (typically micro-projects dealing with a specific component
> implementation) much in the same way that common manages new projects.
OK.
> In this scenario - the new project would establish a PMC responsible for
> oversite, content would be licensed under ASL, and the relationship
> between Avalon and the new project would include our focus on the tools
> and technologies dealing with aspects such as technical complicance,
> validation test suites, component repository tools, etc.
Ok.
Back to Eric's questions;
If we can make them "yes", I'm also in favour...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> The proposal is a Avalon Component project here at Apache - seperate
>> but aligned with Avalon.
>
<snip/>
> Seriously, I think a smart plan is to see what flows from the
> repository@apache.org discussion, see what kind of code we want to
> have in merlin based on that, and perhaps decouple a large part of
> that and combine it with other code efforts in a new project that
> starts off in the incubator.
>
> A possible destination for that would be under ant, under maven, under
> avalon, or TLP.
I don't see the repository@ iniative doing much more than defining a
protocol. After that there is the question of tools and services on
either end of the repository - and about the only thing that seems to be
clear is that there is very little interest in anything more than
plumbing. That means (IMVHO) that the smart stuff will be done here at
Avalon. Secondly - the management of a component repository project is
much more about people, community and focus - and honestly - that's not
going to come out of any of the things being discussed externally.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> The proposal is a Avalon Component project here at Apache - seperate but
> aligned with Avalon.
<snip/>
> In this scenario - the new project would establish a PMC responsible for
> oversite, content would be licensed under ASL, and the relationship
> between Avalon and the new project would include our focus on the tools
> and technologies dealing with aspects such as technical complicance,
> validation test suites, component repository tools, etc.
overhead! I've got no time for another PMC :D
Seriously, I think a smart plan is to see what flows from the
repository@apache.org discussion, see what kind of code we want to have
in merlin based on that, and perhaps decouple a large part of that and
combine it with other code efforts in a new project that starts off in
the incubator.
A possible destination for that would be under ant, under maven, under
avalon, or TLP.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Merlin Lookup versus ECM Lookup
Posted by Eric Pugh <ep...@upstate.com>.
Stephen (and other Avalon guru's)...
I have committed the merlin friendly (merlinized?) version of Configuation.
I ditched the api section as commons-configuration really provides that.
anyone want to review it and let me know?
http://cvs.apache.org/viewcvs/jakarta-turbine-fulcrum/configuration/
Ignore the configuration/src directory.. gotta figure out what I did..
Thought I deleted it, but apparently not..
Eric
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, November 12, 2003 10:49 AM
> To: Avalon Developers List
> Subject: Re: Merlin Lookup versus ECM Lookup
>
>
>
>
> Eric Pugh wrote:
>
> >I am looking at code that Stephen worked over from Fulcrum.
> In the past we
> >always had on the API a ROLE. So, like this:
> >
> > /** Avalon role - used to id the component within the manager */
> > String ROLE = Config.class.getName();
> >
>
> Confession - I have never liked the ROLE notion. It simply
> does not make
> sense to me. Other Avalon guys disagree with me on the
> grounds that ROLE
> can be changed to be something other than class.getName() and
> that this
> is somehow benefitial.
>
> >Is ROLE purely there for use in ECM/Fortress containers?
> Because in the
> >Merlin testcase, instead of a lookup using ROLE, we use:
> >
> >config = (Config) this.resolve( "conf" );
> >
>
> This is different. The abstract testcase has an embedded container
> within it. As such it has access to the appliance managing
> the component
> type. To do someting like the lookup of a component by
> interface name
> can be done in the abstruct unit test code (and I'm lazy so I
> just using
> the existing facilities on block to pull in a component ny name).
>
> However, getting a component relative to a service is
> something we need
> to provide where a component is acting as a component and container
> (whic is the case in the xmlrpc component). Towards that end
> I'm been
> doing so refactoring of the block implementation to make it easier to
> provide different styles of blocks:
>
> * compositional (the current approach)
> * factory
> * finder
>
> In the xmlrpc case and in the unit test case the finder style is the
> most appropriate.
>
> >Because we defined this:
> > <component name="conf"
> >
> class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
> >
> >We could have resolved it as FooBAR if we did this:
> >
> > <component name="FooBAR"
> >
> class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
> >
> >So, should we just leave ROLE on for old users? This code
> really hasn't
> >been 1.0 released yet, so I would rather ditch anything old.
> After all you
> >can look up in your code by anything, not just ROLE in ECM..
> >
>
> In the case of the conf sub-project I would dump the entire API. But
> this gets back to the question - is it actually needed if you run the
> compoent in ECM or Fortress - I don't know! Berin?
>
> >My other question is that in the block.xml we have:
> > <services>
> > <service type="org.apache.fulcrum.configuration.Config">
> > <source>config</source>
> > </service>
> > </services>
> >
> >Now, the only reason to have that is to declare that we export this
> >"service" so that others can use it without writing their
> own block.xml,
> >correct?
> >
>
> Yep.
>
> >So, as long as you lookup 'config/conf' you get back the right
> >object. So I can, in my code do either of these calls:
> >
> >config = (Config) this.resolve( "conf" );
> >
> >or
> >
> >config = (Config) this.resolve( "config/conf" );
> >
>
> Yes - but only if you code is container-side code.
>
> >
> >I just don't quite understand why I could do "conf" versus
> "config/conf", is
> >it because my default container was already called "config"?
> >
>
> Because the container established by the test case is is named as
> whatever the name of the block is named. In the stuff I did
> I typically
> named the containers with the same name as the project.
> Secondly, the
> unit test sets the default block for resolution of names to
> be the block
> that was loader to hold the test compoenents - that's just a
> convinience
> factor. What actually happens when you do a "/config/conf"
> is that the
> request is forwarded to the root container which forwards the
> request to
> the child config container which resolved the conf component.
>
> Stephen.
>
> >
> >
> >Eric Pugh
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> >For additional commands, e-mail: dev-help@avalon.apache.org
> >
> >
> >
> >
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merlin Lookup versus ECM Lookup
Posted by Stephen McConnell <mc...@apache.org>.
Eric Pugh wrote:
>I am looking at code that Stephen worked over from Fulcrum. In the past we
>always had on the API a ROLE. So, like this:
>
> /** Avalon role - used to id the component within the manager */
> String ROLE = Config.class.getName();
>
Confession - I have never liked the ROLE notion. It simply does not make
sense to me. Other Avalon guys disagree with me on the grounds that ROLE
can be changed to be something other than class.getName() and that this
is somehow benefitial.
>Is ROLE purely there for use in ECM/Fortress containers? Because in the
>Merlin testcase, instead of a lookup using ROLE, we use:
>
>config = (Config) this.resolve( "conf" );
>
This is different. The abstract testcase has an embedded container
within it. As such it has access to the appliance managing the component
type. To do someting like the lookup of a component by interface name
can be done in the abstruct unit test code (and I'm lazy so I just using
the existing facilities on block to pull in a component ny name).
However, getting a component relative to a service is something we need
to provide where a component is acting as a component and container
(whic is the case in the xmlrpc component). Towards that end I'm been
doing so refactoring of the block implementation to make it easier to
provide different styles of blocks:
* compositional (the current approach)
* factory
* finder
In the xmlrpc case and in the unit test case the finder style is the
most appropriate.
>Because we defined this:
> <component name="conf"
> class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
>
>We could have resolved it as FooBAR if we did this:
>
> <component name="FooBAR"
> class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
>
>So, should we just leave ROLE on for old users? This code really hasn't
>been 1.0 released yet, so I would rather ditch anything old. After all you
>can look up in your code by anything, not just ROLE in ECM..
>
In the case of the conf sub-project I would dump the entire API. But
this gets back to the question - is it actually needed if you run the
compoent in ECM or Fortress - I don't know! Berin?
>My other question is that in the block.xml we have:
> <services>
> <service type="org.apache.fulcrum.configuration.Config">
> <source>config</source>
> </service>
> </services>
>
>Now, the only reason to have that is to declare that we export this
>"service" so that others can use it without writing their own block.xml,
>correct?
>
Yep.
>So, as long as you lookup 'config/conf' you get back the right
>object. So I can, in my code do either of these calls:
>
>config = (Config) this.resolve( "conf" );
>
>or
>
>config = (Config) this.resolve( "config/conf" );
>
Yes - but only if you code is container-side code.
>
>I just don't quite understand why I could do "conf" versus "config/conf", is
>it because my default container was already called "config"?
>
Because the container established by the test case is is named as
whatever the name of the block is named. In the stuff I did I typically
named the containers with the same name as the project. Secondly, the
unit test sets the default block for resolution of names to be the block
that was loader to hold the test compoenents - that's just a convinience
factor. What actually happens when you do a "/config/conf" is that the
request is forwarded to the root container which forwards the request to
the child config container which resolved the conf component.
Stephen.
>
>
>Eric Pugh
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Merlin Lookup versus ECM Lookup
Posted by Eric Pugh <ep...@upstate.com>.
I am looking at code that Stephen worked over from Fulcrum. In the past we
always had on the API a ROLE. So, like this:
/** Avalon role - used to id the component within the manager */
String ROLE = Config.class.getName();
Is ROLE purely there for use in ECM/Fortress containers? Because in the
Merlin testcase, instead of a lookup using ROLE, we use:
config = (Config) this.resolve( "conf" );
Because we defined this:
<component name="conf"
class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
We could have resolved it as FooBAR if we did this:
<component name="FooBAR"
class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
So, should we just leave ROLE on for old users? This code really hasn't
been 1.0 released yet, so I would rather ditch anything old. After all you
can look up in your code by anything, not just ROLE in ECM..
My other question is that in the block.xml we have:
<services>
<service type="org.apache.fulcrum.configuration.Config">
<source>config</source>
</service>
</services>
Now, the only reason to have that is to declare that we export this
"service" so that others can use it without writing their own block.xml,
correct? So, as long as you lookup 'config/conf' you get back the right
object. So I can, in my code do either of these calls:
config = (Config) this.resolve( "conf" );
or
config = (Config) this.resolve( "config/conf" );
I just don't quite understand why I could do "conf" versus "config/conf", is
it because my default container was already called "config"?
Eric Pugh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 12 November 2003 17:32, Stephen McConnell wrote:
>
>>Niclas Hedhman wrote:
>
>
>>>LGPL is probably compatible with ASL, BUT ASF has said NO on being
>>>involved, I think largely due to unclarities of what the license actually
>>>demands from Apache _users_, more than ASF itself !!
>>
>>This is a point that I didn't think about earlier. Just to absolutely
>>clear - in the case of the Hibernate Component - at is using LGPL it is
>>subject to the LGPL by viral virtue - hense the requirement to license
>>the Hibernate Component under the LGPL and not under ASL. Therefore the
>>requirement is created for a place to put this LGPL Hibernate Component
>>outside of ASF space pending an explicit release of the viral
>>association by the licensor. However - this means that anything using
>>the LPGL Hibernate Component is by default pushed out as well. Ummm, I
>>starting to understand the religous impliciations and the reason for
>>zero-tolerance on LGPL.
>
>
> Confusing, isn't it??
>
> For us, I think it is just a matter of accepting the decision. Those guys have
> argued over this for months, I'm sure...
Since forever. THere is a lot of good software out there that we can't use
because of a stupid license. That sucks. With every new version of the (L)GPL
licenses someone tries to make an opening in their interpretation of the
legalese to allow us to use it...
No luck.
>
> Your conclusion is probably correct, the Hibernate component need to isolate
> itself from Apache source. The best would be that Hibernate published a set
> of interfaces under BSD-style, and we could compile/distribute against those
> interfaces, and the end-users download from Hibernate.
If the interface is ASL, and packaged separately, then we might could get around
some of the licensing issues. The problem is the implementation.
>
> If that is not acheivable, I don't see any other choice than an SF-based
> sidearm of the ASF-based one. I think it could be doable...
There is still the issue of each SF community being required to sort out its
licensing. All we are doing is saying "here, you worry about it".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Wednesday 12 November 2003 17:32, Stephen McConnell wrote:
>
>
>>Niclas Hedhman wrote:
>>
>>
>
>
>
>>>LGPL is probably compatible with ASL, BUT ASF has said NO on being
>>>involved, I think largely due to unclarities of what the license actually
>>>demands from Apache _users_, more than ASF itself !!
>>>
>>>
>>This is a point that I didn't think about earlier. Just to absolutely
>>clear - in the case of the Hibernate Component - at is using LGPL it is
>>subject to the LGPL by viral virtue - hense the requirement to license
>>the Hibernate Component under the LGPL and not under ASL. Therefore the
>>requirement is created for a place to put this LGPL Hibernate Component
>>outside of ASF space pending an explicit release of the viral
>>association by the licensor. However - this means that anything using
>>the LPGL Hibernate Component is by default pushed out as well. Ummm, I
>>starting to understand the religous impliciations and the reason for
>>zero-tolerance on LGPL.
>>
>>
>
>Confusing, isn't it??
>
>For us, I think it is just a matter of accepting the decision. Those guys have
>argued over this for months, I'm sure...
>
>Your conclusion is probably correct, the Hibernate component need to isolate
>itself from Apache source. The best would be that Hibernate published a set
>of interfaces under BSD-style, and we could compile/distribute against those
>interfaces, and the end-users download from Hibernate.
>
Going lateral .... if a ASL Hiberate component API was written together
with a block definition. Then, with the service based resolution via a
repository - the repository is doing the selection of an implementation
based on the requested service - and know implementations. I'm not a
lawyer - but I would imagine that it would be very difficult to show
viral rights on either the service broker or the consumer component.
Why - because neither are built against a viral product.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Wednesday 12 November 2003 17:32, Stephen McConnell wrote:
>
>
>>Niclas Hedhman wrote:
>>
>>
>
>
>
>>>LGPL is probably compatible with ASL, BUT ASF has said NO on being
>>>involved, I think largely due to unclarities of what the license actually
>>>demands from Apache _users_, more than ASF itself !!
>>>
>>>
>>This is a point that I didn't think about earlier. Just to absolutely
>>clear - in the case of the Hibernate Component - at is using LGPL it is
>>subject to the LGPL by viral virtue - hense the requirement to license
>>the Hibernate Component under the LGPL and not under ASL. Therefore the
>>requirement is created for a place to put this LGPL Hibernate Component
>>outside of ASF space pending an explicit release of the viral
>>association by the licensor. However - this means that anything using
>>the LPGL Hibernate Component is by default pushed out as well. Ummm,
>>I'm starting to understand the religous impliciations and the reason
>>for zero-tolerance on LGPL.
>>
>>
>
>Confusing, isn't it??
>
>For us, I think it is just a matter of accepting the decision. Those guys have
>argued over this for months, I'm sure...
>
>Your conclusion is probably correct, the Hibernate component need to isolate
>itself from Apache source. The best would be that Hibernate published a set
>of interfaces under BSD-style, and we could compile/distribute against those
>interfaces, and the end-users download from Hibernate.
>
>If that is not acheivable, I don't see any other choice than an SF-based
>sidearm of the ASF-based one. I think it could be doable...
>
Yep, its doable.
The question is - is it desirable? For the moment - I don't know.
Stephen.
>
>Niclas
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 12 November 2003 17:32, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> >LGPL is probably compatible with ASL, BUT ASF has said NO on being
> > involved, I think largely due to unclarities of what the license actually
> > demands from Apache _users_, more than ASF itself !!
>
> This is a point that I didn't think about earlier. Just to absolutely
> clear - in the case of the Hibernate Component - at is using LGPL it is
> subject to the LGPL by viral virtue - hense the requirement to license
> the Hibernate Component under the LGPL and not under ASL. Therefore the
> requirement is created for a place to put this LGPL Hibernate Component
> outside of ASF space pending an explicit release of the viral
> association by the licensor. However - this means that anything using
> the LPGL Hibernate Component is by default pushed out as well. Ummm, I
> starting to understand the religous impliciations and the reason for
> zero-tolerance on LGPL.
Confusing, isn't it??
For us, I think it is just a matter of accepting the decision. Those guys have
argued over this for months, I'm sure...
Your conclusion is probably correct, the Hibernate component need to isolate
itself from Apache source. The best would be that Hibernate published a set
of interfaces under BSD-style, and we could compile/distribute against those
interfaces, and the end-users download from Hibernate.
If that is not acheivable, I don't see any other choice than an SF-based
sidearm of the ASF-based one. I think it could be doable...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Wednesday 12 November 2003 16:49, Eric Pugh wrote:
>
>
>>Okay... But, can I transfer my Hibernate component over to this new
>>repository? Remember, Hibernate is LGPL, and I couldn't host it in
>>Fulcrum.
>>
>>
>
>I think there are problems...
>
>LGPL is probably compatible with ASL, BUT ASF has said NO on being involved, I
>think largely due to unclarities of what the license actually demands from
>Apache _users_, more than ASF itself !!
>
This is a point that I didn't think about earlier. Just to absolutely
clear - in the case of the Hibernate Component - at is using LGPL it is
subject to the LGPL by viral virtue - hense the requirement to license
the Hibernate Component under the LGPL and not under ASL. Therefore the
requirement is created for a place to put this LGPL Hibernate Component
outside of ASF space pending an explicit release of the viral
association by the licensor. However - this means that anything using
the LPGL Hibernate Component is by default pushed out as well. Ummm, I
starting to understand the religous impliciations and the reason for
zero-tolerance on LGPL.
>
>
>
>
>>Secondly, can I have committer access?
>>
>>
>
>I most certainly would assume so.
>Stephen was touching on the idea of micro-projects, but I would like to point
>out that "community is more important than code", all according to Apache
>itself, so I think it is counter-productive of letting each committer fool
>around in his own pond.
>
Sorry I should have been clearer - I didn't want to suggest seperate
sub-communites. ASAIAC is about one community - many components - joint
and several responsibility - the community is the important thing.
Stephen.
>
>
>
>>If either of those are no, then that points out the need for another site.
>>If both are yes, then I'm all for it as it solves my problem.
>>
>>
>
>Agree.
>
>Niclas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 12 November 2003 16:49, Eric Pugh wrote:
> Okay... But, can I transfer my Hibernate component over to this new
> repository? Remember, Hibernate is LGPL, and I couldn't host it in
> Fulcrum.
I think there are problems...
LGPL is probably compatible with ASL, BUT ASF has said NO on being involved, I
think largely due to unclarities of what the license actually demands from
Apache _users_, more than ASF itself !!
>Secondly, can I have committer access?
I most certainly would assume so.
Stephen was touching on the idea of micro-projects, but I would like to point
out that "community is more important than code", all according to Apache
itself, so I think it is counter-productive of letting each committer fool
around in his own pond.
> If either of those are no, then that points out the need for another site.
> If both are yes, then I'm all for it as it solves my problem.
Agree.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] Avalon Components project
Posted by Stephen McConnell <mc...@apache.org>.
Eric Pugh wrote:
>Okay... But, can I transfer my Hibernate component over to this new
>repository? Remember, Hibernate is LGPL, and I couldn't host it in Fulcrum.
>Secondly, can I have committer access?
>
>If either of those are no, then that points out the need for another site.
>If both are yes, then I'm all for it as it solves my problem.
>
The Hibernate component could be transfered *if* the component code was
donated to the ASF. Remember that we are not talking about the Hibernate
sources - instead we are talking about code that is using Hibernate as
part of a component implementation. This is no different to the James
project using Javamail. As to yourself as a committer - absolutely yes!
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PROPOSAL] Avalon Components project
Posted by Eric Pugh <ep...@upstate.com>.
Okay... But, can I transfer my Hibernate component over to this new
repository? Remember, Hibernate is LGPL, and I couldn't host it in Fulcrum.
Secondly, can I have committer access?
If either of those are no, then that points out the need for another site.
If both are yes, then I'm all for it as it solves my problem.
Eric
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, November 12, 2003 9:37 AM
> To: Avalon Developers List
> Subject: [PROPOSAL] Avalon Components project
>
>
>
>
> Niclas Hedhman wrote:
>
> >On Tuesday 11 November 2003 19:48, Eric Pugh wrote:
> >
> >
> >>And, since I have lots of ideas for components that all
> have licensing
> >>issues, why not have a sf.net site? Maybe instead of
> Avalonia, just call
> >>it avalon-components..
> >>
> >>
> >
> >I, for one, agree... I think the only issue with the more
> hard core Apache
> >guys (I'm not pointing a big finger at you Stephen) is the
> "endorsement",
> >implied or otherwise, that Avalonia or avalon-components, is given.
> >
>
> IM[HC]O, there are a number of different subjects
>
> (a) the barrier to entry
> (b) licensing
> (c) endorcement
>
> The barrier to entry is a pure policy decision that can be
> made by the
> entity that is asserting oversite - this should not be used as an
> argument for or against ASF versus SF. Equally components
> using non-ASF
> compatible resources should not impact a ASF/SF decision
> bacause this is
> simply a question of development time downloading (and seperate from
> deployment). Lastly - the question of endorcement - AFAICS,
> endorcement
> by Avalon requires oversite by Avalon which leads me to an
> alternative
> proposition.
>
> The proposal is a Avalon Component project here at Apache -
> seperate but
> aligned with Avalon. The project would establish policies that
> facilitated a lower barrier to entry of new component iniatives
> (typically micro-projects dealing with a specific component
> implementation) much in the same way that common manages new
> projects.
> We could bootstrap the thing by transfering the current
> avalon-components cvs to the new project and possibly well as
> incorporation of iniative such the FTP project.
>
> In this scenario - the new project would establish a PMC
> responsible for
> oversite, content would be licensed under ASL, and the relationship
> between Avalon and the new project would include our focus on
> the tools
> and technologies dealing with aspects such as technical complicance,
> validation test suites, component repository tools, etc.
>
> Stephen.
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org