You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Carman <ja...@carmanconsulting.com> on 2005/08/04 16:51:01 UTC
Project Proposal?
All,
I have a project that I would like to maybe put into the Sandbox, but I
couldn't find any instructions on how to go about doing that. Can anyone
point me in the right direction?
Thanks,
James
RE: Incubator WAS: Project Proposal?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Brett Porter wrote:
> given Noel's email on commons-exec, I think it would be good to
> talk about the similarities of the sandbox and the incubator and
> determine if both are needed and how they can help each other.
They are probably both needed, since the sandbox is typically used for
internal projects that are just not ready for prime time. But the sandbox
cannot be used as a stand-in for the Incubator.
I think that everyone realizes that new communities must be come through the
Incubator, but it may not be as widely understood that external codebases
imported into existing projects must still be recorded in the Incubator.
See:
http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects/
ip-clearance-template.html
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Incubator WAS: Project Proposal?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Torsten Curdt wrote:
> ...I just wanted to point out that incubator not only exists
> due to legal reasons. (actually I am not sure if that was the
> main in reason in the first place at all) If it was, we would
> not need it for internally started projects.
Actually, we don't need to use it for internally started projects. But we
most certainly have to use it for things coming in from the outside.
> But to my understanding it is also about establishing a healthy community.
Absolutely. When we are bringing in external projects, we need to make sure
that they become a healthy community following ASF practices.
However, when we are bringing in external codebases into an existing
project, we still need to use the Incubator. Rule of thumb: if you need a
Software Grant, you should be recording it in the Incubator as per the IP
template.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Incubator WAS: Project Proposal?
Posted by Torsten Curdt <tc...@vafer.org>.
>> Well, AFAIU the incubator is also about establishing a community
>> not only about legal safety - so that would apply here as well.
>>
>> ...but the whole progress might be a bit too much for a little
>> library project. That's why the commons sandbox still makes
>> sense. It's about smaller components NOT on the project level.
>>
>
> Well, I think the point was that this particular project wasn't a
> library project, so not suited for commons.
Sorry my writing was misleading
...I just wanted to point out that
incubator not only exists due to
legal reasons. (actually I am not
sure if that was the main in reason
in the first place at all)
If it was, we would not need it
for internally started projects.
But to my understanding it is also
about establishing a healthy community.
So it does also make sense for
internally sponsored projects.
...given they have a reasonable
size.
So coming back to the original
topic of the thread
So it's a framework?
Yeah - incubator does make sense (to me)
...altough there are no legal issues.
cheers
--
Torsten
Re: Incubator WAS: Project Proposal?
Posted by Brett Porter <br...@apache.org>.
Torsten Curdt wrote:
>
> Well, AFAIU the incubator is also about establishing a community
> not only about legal safety - so that would apply here as well.
>
> ...but the whole progress might be a bit too much for a little
> library project. That's why the commons sandbox still makes
> sense. It's about smaller components NOT on the project level.
Well, I think the point was that this particular project wasn't a
library project, so not suited for commons.
However, given Noel's email on commons-exec, I think it would be good to
talk about the similarities of the sandbox and the incubator and
determine if both are needed and how they can help each other.
>
> But maybe it would be worth discussing the whole internally
> sponsored projects idea over at incubator. WDTY?
I'm pretty sure that this can happen, and has happenened before. It is
not always necessary, as the committers may be able to start it under
their current project and later if it grows a community of its own look
for promotion to Jakarta of Apache (such as what Maven did from Turbine,
or Ant from Tomcat).
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Project Proposal?
Posted by Torsten Curdt <tc...@apache.org>.
>> I thought the established process was to use the incubator,
>> promoting to
>> Jakarta when community strength and diversity was clear. This is what
>> recently happened with Derby to DB, for example.
>
> That's for projects external to Apache.
>
> Are we saying that if 1, 2 or 3 ASF committers have an idea, they
> should either develop it externally or work through the incubator
> before creating it?
Well, AFAIU the incubator is also about establishing a community
not only about legal safety - so that would apply here as well.
...but the whole progress might be a bit too much for a little
library project. That's why the commons sandbox still makes
sense. It's about smaller components NOT on the project level.
But maybe it would be worth discussing the whole internally
sponsored projects idea over at incubator. WDTY?
cheers
--
Torsten
Re: Project Proposal?
Posted by Henri Yandell <fl...@gmail.com>.
On 8/5/05, Brett Porter <br...@apache.org> wrote:
> I thought the established process was to use the incubator, promoting to
> Jakarta when community strength and diversity was clear. This is what
> recently happened with Derby to DB, for example.
>
> - Brett
That's for projects external to Apache.
Are we saying that if 1, 2 or 3 ASF committers have an idea, they
should either develop it externally or work through the incubator
before creating it?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Project Proposal?
Posted by Brett Porter <br...@apache.org>.
I thought the established process was to use the incubator, promoting to
Jakarta when community strength and diversity was clear. This is what
recently happened with Derby to DB, for example.
- Brett
Henri Yandell wrote:
>On 8/5/05, James Carman <ja...@carmanconsulting.com> wrote:
>
>
>>Since it is a framework, would I have to submit a "Jakarta PMC TLP
>>Application" if I wanted to eventually move this project to Apache? Is
>>there no real "incubator" inside Jakarta for projects such as this? Sounds
>>like I may have chosen the right place for this project for now.
>>
>>
>
>I agree, we lack a Jakarta Sandbox.
>
>Could the Commons Sandbox enlarge its scope to cover all of Jakarta?
>
>Hen
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Project Proposal?
Posted by Henri Yandell <fl...@gmail.com>.
On 8/5/05, James Carman <ja...@carmanconsulting.com> wrote:
>
> Since it is a framework, would I have to submit a "Jakarta PMC TLP
> Application" if I wanted to eventually move this project to Apache? Is
> there no real "incubator" inside Jakarta for projects such as this? Sounds
> like I may have chosen the right place for this project for now.
I agree, we lack a Jakarta Sandbox.
Could the Commons Sandbox enlarge its scope to cover all of Jakarta?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Project Proposal?
Posted by James Carman <ja...@carmanconsulting.com>.
The Syringe API lends itself to setting things up with code. The HiveMind
API wasn't really meant for that. It was written with the hivemodule.xml
file syntax in mind and with everybody chanting "less XML is good", we've
had some folks requesting a more API-based approach. So, you're right,
Siringe is indeed a framework, but it's a lower-level framework. Something
like HiveMind would sit on top of syringe (as painful as that may sound). I
would like, someday, to port HiveMind to use the Syringe API underneath, but
that would be quite an undertaking and there are quite a few folks out there
already using HiveMind (anyone using the newest Tapestry, for example). I
wanted to start something fresh with no limitations of backward
compatibility and see what I came up with. Hopefully folks with think that
Syringe is easy to use/extend. I'm working on an example application right
now to see how really easy it is (eat my own dog food). Hopefully the
example will serve as documentation and an opportunity to figure out how to
make Syringe that much more usable.
Since it is a framework, would I have to submit a "Jakarta PMC TLP
Application" if I wanted to eventually move this project to Apache? Is
there no real "incubator" inside Jakarta for projects such as this? Sounds
like I may have chosen the right place for this project for now.
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Friday, August 05, 2005 8:39 AM
To: Jakarta Commons Developers List
Subject: RE: Project Proposal?
While interesting, this would have caused issues in
commons. The commons charter explicitly avoids
frameworks, and this is definitely a framework.
Longer term though, with Spring, Hivemind and Pico
already in this space, and EJB3 making some moves
there must be a limit on having a new injection
framework. So, why not just improve Hivemind?
Stephen
--- James Carman <ja...@carmanconsulting.com> wrote:
> I guess I wanted a little more freedom/control over
> the project at this
> phase. Also, I wasn't too sure about licensing
> issues with putting stuff in
> the codebase that depends upon code outside Apache
> (the build file
> automatically downloads its dependencies from
> Ibiblio).
>
> It is early on right now, but I think there are some
> sound ideas there...
>
> 1. Proxy Factories - All proxies in Syringe are
> created using a proxy
> factory (an interface). Using syringe, you never
> have to write the proxying
> logic code yourself anymore. Furthermore, since
> it's abstracted out, it's
> easy to switch between (or mix and match for that
> matter) proxying
> strategies, simply by supplying a different
> implementation class. I
> currently have implementations using JDK proxies and
> CGLIB.
>
> 2. Object Providers - Objects are provided to
> Syringe through
> ObjectProviders. There are two different types of
> ObjectProviders now, core
> object providers and wrapper/decorator providers.
> The core providers would
> be responsible for constructing/finding the actual
> implementation object.
> It might be a simple JavaBean, or it could be some
> sort of remote object
> (EJB, JAX-RPC, RMI, Burlap, etc.). The
> wrapper/decorator providers
> supplement these core providers with additional
> functionality. For example,
> in Syringe, all dependency injection is done using a
> decorator provider.
> So, it's easy for you to extend Syringe with your
> own providers and still
> support DI. This has been somewhat of a problem in
> HiveMind. All of the
> dependency injection logic is buried inside the
> BuilderFactory's
> implementation.
>
> 3. Method Interceptors - Syringe only supports the
> MethodInterceptor
> interface (a proxy factory must know how to create a
> proxy which goes
> through a MethodInterceptor) from the AOP Alliance
> API. Since this is
> somewhat of a "standard" API, I don't really see it
> as a limitation. If we
> see the need to support other mechanisms, maybe we
> can provide adapter
> classes to bridge the gap.
>
>
>
> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com]
> Sent: Friday, August 05, 2005 2:37 AM
> To: Jakarta Commons Developers List
> Subject: Re: Project Proposal?
>
> Out of interest, why java.net and not sandbox? :)
>
> Before that sounds like a witch-hunt, I'm as guilty
> in that I start
> all my stuff at osjava.org and I can definitely list
> some reasons why.
>
> Some may be bad:
> * Embaressment for dumb ideas :)
> * Don't want to be weighed down by a weighty release
> system.
> * Big painful website.
> * Might compete with another Commons component.
>
> Some may be good:
> * Does the ASF want single-person codebases when an
> idea doesn't pan out.
> * If it fails, I'd then be forking it elsewhere
> which feels worse than
> just starting elsewhere.
>
> What if we had a location within which ASF
> committers can bring their
> half-cocked component ideas? Try to encourage
> migration to the ASF and
> its benefits:
>
> * bandwidth, though sf.net and java.net can solve
> that too. So can
> building your own system to the level of Codehaus.
> * legal protection.
> * better user acceptance.
> * community.
>
> If we couple this with:
>
> * much better management of the sandbox, and
> components that have failed.
> * a plan for mature components.
>
> could we pick things up in terms of vibrancy? My
> biggest worry would
> be whether the mailing list becomes a bottleneck.
>
> Half-baked idea (it's late): Each component has its
> own mail alias
> which gets forwarded to particular lists. These
> lists could represent
> the state of maturity of a component. Probably crap,
> just throwing it
> out.
>
> One question I'd like to ask is whether we would
> accept mature components.
>
> Take http://www.osjava.org/norbert/, HttpClient said
> they were
> interested in using it and the thought was to put it
> in Commons. My
> only concern is that I can't see a lot more to do
> with it code-wise,
> so I'm hesitant to dump it in Commons, and yet I
> think it's a good
> tiny component that could do with being more open.
>
> Hen
>
> On 8/4/05, James Carman <ja...@carmanconsulting.com>
> wrote:
> > Well, I went ahead and started the project over at
> java.net, but we can
> move
> > it later if need be. It's a dependency injection
> framework called
> > "syringe." The project uses the Apache License,
> Version 2.0. It's still
> > "pending approval" at java.net, so you guys won't
> be able to see anything
> > yet. It should be approved soon though.
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Project Proposal?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
While interesting, this would have caused issues in
commons. The commons charter explicitly avoids
frameworks, and this is definitely a framework.
Longer term though, with Spring, Hivemind and Pico
already in this space, and EJB3 making some moves
there must be a limit on having a new injection
framework. So, why not just improve Hivemind?
Stephen
--- James Carman <ja...@carmanconsulting.com> wrote:
> I guess I wanted a little more freedom/control over
> the project at this
> phase. Also, I wasn't too sure about licensing
> issues with putting stuff in
> the codebase that depends upon code outside Apache
> (the build file
> automatically downloads its dependencies from
> Ibiblio).
>
> It is early on right now, but I think there are some
> sound ideas there...
>
> 1. Proxy Factories - All proxies in Syringe are
> created using a proxy
> factory (an interface). Using syringe, you never
> have to write the proxying
> logic code yourself anymore. Furthermore, since
> it's abstracted out, it's
> easy to switch between (or mix and match for that
> matter) proxying
> strategies, simply by supplying a different
> implementation class. I
> currently have implementations using JDK proxies and
> CGLIB.
>
> 2. Object Providers - Objects are provided to
> Syringe through
> ObjectProviders. There are two different types of
> ObjectProviders now, core
> object providers and wrapper/decorator providers.
> The core providers would
> be responsible for constructing/finding the actual
> implementation object.
> It might be a simple JavaBean, or it could be some
> sort of remote object
> (EJB, JAX-RPC, RMI, Burlap, etc.). The
> wrapper/decorator providers
> supplement these core providers with additional
> functionality. For example,
> in Syringe, all dependency injection is done using a
> decorator provider.
> So, it's easy for you to extend Syringe with your
> own providers and still
> support DI. This has been somewhat of a problem in
> HiveMind. All of the
> dependency injection logic is buried inside the
> BuilderFactory's
> implementation.
>
> 3. Method Interceptors - Syringe only supports the
> MethodInterceptor
> interface (a proxy factory must know how to create a
> proxy which goes
> through a MethodInterceptor) from the AOP Alliance
> API. Since this is
> somewhat of a "standard" API, I don't really see it
> as a limitation. If we
> see the need to support other mechanisms, maybe we
> can provide adapter
> classes to bridge the gap.
>
>
>
> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com]
> Sent: Friday, August 05, 2005 2:37 AM
> To: Jakarta Commons Developers List
> Subject: Re: Project Proposal?
>
> Out of interest, why java.net and not sandbox? :)
>
> Before that sounds like a witch-hunt, I'm as guilty
> in that I start
> all my stuff at osjava.org and I can definitely list
> some reasons why.
>
> Some may be bad:
> * Embaressment for dumb ideas :)
> * Don't want to be weighed down by a weighty release
> system.
> * Big painful website.
> * Might compete with another Commons component.
>
> Some may be good:
> * Does the ASF want single-person codebases when an
> idea doesn't pan out.
> * If it fails, I'd then be forking it elsewhere
> which feels worse than
> just starting elsewhere.
>
> What if we had a location within which ASF
> committers can bring their
> half-cocked component ideas? Try to encourage
> migration to the ASF and
> its benefits:
>
> * bandwidth, though sf.net and java.net can solve
> that too. So can
> building your own system to the level of Codehaus.
> * legal protection.
> * better user acceptance.
> * community.
>
> If we couple this with:
>
> * much better management of the sandbox, and
> components that have failed.
> * a plan for mature components.
>
> could we pick things up in terms of vibrancy? My
> biggest worry would
> be whether the mailing list becomes a bottleneck.
>
> Half-baked idea (it's late): Each component has its
> own mail alias
> which gets forwarded to particular lists. These
> lists could represent
> the state of maturity of a component. Probably crap,
> just throwing it
> out.
>
> One question I'd like to ask is whether we would
> accept mature components.
>
> Take http://www.osjava.org/norbert/, HttpClient said
> they were
> interested in using it and the thought was to put it
> in Commons. My
> only concern is that I can't see a lot more to do
> with it code-wise,
> so I'm hesitant to dump it in Commons, and yet I
> think it's a good
> tiny component that could do with being more open.
>
> Hen
>
> On 8/4/05, James Carman <ja...@carmanconsulting.com>
> wrote:
> > Well, I went ahead and started the project over at
> java.net, but we can
> move
> > it later if need be. It's a dependency injection
> framework called
> > "syringe." The project uses the Apache License,
> Version 2.0. It's still
> > "pending approval" at java.net, so you guys won't
> be able to see anything
> > yet. It should be approved soon though.
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Project Proposal?
Posted by James Carman <ja...@carmanconsulting.com>.
I guess I wanted a little more freedom/control over the project at this
phase. Also, I wasn't too sure about licensing issues with putting stuff in
the codebase that depends upon code outside Apache (the build file
automatically downloads its dependencies from Ibiblio).
It is early on right now, but I think there are some sound ideas there...
1. Proxy Factories - All proxies in Syringe are created using a proxy
factory (an interface). Using syringe, you never have to write the proxying
logic code yourself anymore. Furthermore, since it's abstracted out, it's
easy to switch between (or mix and match for that matter) proxying
strategies, simply by supplying a different implementation class. I
currently have implementations using JDK proxies and CGLIB.
2. Object Providers - Objects are provided to Syringe through
ObjectProviders. There are two different types of ObjectProviders now, core
object providers and wrapper/decorator providers. The core providers would
be responsible for constructing/finding the actual implementation object.
It might be a simple JavaBean, or it could be some sort of remote object
(EJB, JAX-RPC, RMI, Burlap, etc.). The wrapper/decorator providers
supplement these core providers with additional functionality. For example,
in Syringe, all dependency injection is done using a decorator provider.
So, it's easy for you to extend Syringe with your own providers and still
support DI. This has been somewhat of a problem in HiveMind. All of the
dependency injection logic is buried inside the BuilderFactory's
implementation.
3. Method Interceptors - Syringe only supports the MethodInterceptor
interface (a proxy factory must know how to create a proxy which goes
through a MethodInterceptor) from the AOP Alliance API. Since this is
somewhat of a "standard" API, I don't really see it as a limitation. If we
see the need to support other mechanisms, maybe we can provide adapter
classes to bridge the gap.
-----Original Message-----
From: Henri Yandell [mailto:flamefew@gmail.com]
Sent: Friday, August 05, 2005 2:37 AM
To: Jakarta Commons Developers List
Subject: Re: Project Proposal?
Out of interest, why java.net and not sandbox? :)
Before that sounds like a witch-hunt, I'm as guilty in that I start
all my stuff at osjava.org and I can definitely list some reasons why.
Some may be bad:
* Embaressment for dumb ideas :)
* Don't want to be weighed down by a weighty release system.
* Big painful website.
* Might compete with another Commons component.
Some may be good:
* Does the ASF want single-person codebases when an idea doesn't pan out.
* If it fails, I'd then be forking it elsewhere which feels worse than
just starting elsewhere.
What if we had a location within which ASF committers can bring their
half-cocked component ideas? Try to encourage migration to the ASF and
its benefits:
* bandwidth, though sf.net and java.net can solve that too. So can
building your own system to the level of Codehaus.
* legal protection.
* better user acceptance.
* community.
If we couple this with:
* much better management of the sandbox, and components that have failed.
* a plan for mature components.
could we pick things up in terms of vibrancy? My biggest worry would
be whether the mailing list becomes a bottleneck.
Half-baked idea (it's late): Each component has its own mail alias
which gets forwarded to particular lists. These lists could represent
the state of maturity of a component. Probably crap, just throwing it
out.
One question I'd like to ask is whether we would accept mature components.
Take http://www.osjava.org/norbert/, HttpClient said they were
interested in using it and the thought was to put it in Commons. My
only concern is that I can't see a lot more to do with it code-wise,
so I'm hesitant to dump it in Commons, and yet I think it's a good
tiny component that could do with being more open.
Hen
On 8/4/05, James Carman <ja...@carmanconsulting.com> wrote:
> Well, I went ahead and started the project over at java.net, but we can
move
> it later if need be. It's a dependency injection framework called
> "syringe." The project uses the Apache License, Version 2.0. It's still
> "pending approval" at java.net, so you guys won't be able to see anything
> yet. It should be approved soon though.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Project Proposal?
Posted by Henri Yandell <fl...@gmail.com>.
Out of interest, why java.net and not sandbox? :)
Before that sounds like a witch-hunt, I'm as guilty in that I start
all my stuff at osjava.org and I can definitely list some reasons why.
Some may be bad:
* Embaressment for dumb ideas :)
* Don't want to be weighed down by a weighty release system.
* Big painful website.
* Might compete with another Commons component.
Some may be good:
* Does the ASF want single-person codebases when an idea doesn't pan out.
* If it fails, I'd then be forking it elsewhere which feels worse than
just starting elsewhere.
What if we had a location within which ASF committers can bring their
half-cocked component ideas? Try to encourage migration to the ASF and
its benefits:
* bandwidth, though sf.net and java.net can solve that too. So can
building your own system to the level of Codehaus.
* legal protection.
* better user acceptance.
* community.
If we couple this with:
* much better management of the sandbox, and components that have failed.
* a plan for mature components.
could we pick things up in terms of vibrancy? My biggest worry would
be whether the mailing list becomes a bottleneck.
Half-baked idea (it's late): Each component has its own mail alias
which gets forwarded to particular lists. These lists could represent
the state of maturity of a component. Probably crap, just throwing it
out.
One question I'd like to ask is whether we would accept mature components.
Take http://www.osjava.org/norbert/, HttpClient said they were
interested in using it and the thought was to put it in Commons. My
only concern is that I can't see a lot more to do with it code-wise,
so I'm hesitant to dump it in Commons, and yet I think it's a good
tiny component that could do with being more open.
Hen
On 8/4/05, James Carman <ja...@carmanconsulting.com> wrote:
> Well, I went ahead and started the project over at java.net, but we can move
> it later if need be. It's a dependency injection framework called
> "syringe." The project uses the Apache License, Version 2.0. It's still
> "pending approval" at java.net, so you guys won't be able to see anything
> yet. It should be approved soon though.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Project Proposal?
Posted by Simon Kitching <sk...@apache.org>.
The sandbox is available to any apache committer - but only to apache
committers.
So if an existing apache project is factoring out some code into a
module that other projects can take advantage of then the sandbox is a
good place for that; the existing committers on that project can all
work in the sandbox then promote the result to commons proper when it's
stable. In fact, this scenario is one of the main reasons commons and
the sandbox were created AFAIK.
When working on an experimental refactoring/rewrite of an existing
commons project, the sandbox might be appropriate too - though now we
are using subversion with branch management than CVS a branch of the
base project might be a better choice.
When starting a project where 3 or more apache committers are already
interested in being involved, the sandbox may also be a reasonable place
to do it.
But if a project is being started where the initial development
community contains non-apache members, or a project which hopes to draw
contributors from outside Apache, then I think the sandbox is an awkward
place to work as those new contributors can't be granted commit access.
Somewhere external is probably a better choice. If the project is
successful it could then be brought back to apache if the development
team want that later. Of course in the latter case things are much
easier if the APL is used for the code.
Regards,
Simon
On Thu, 2005-08-04 at 22:21 -0400, James Carman wrote:
> Well, I went ahead and started the project over at java.net, but we can move
> it later if need be. It's a dependency injection framework called
> "syringe." The project uses the Apache License, Version 2.0. It's still
> "pending approval" at java.net, so you guys won't be able to see anything
> yet. It should be approved soon though.
>
>
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, August 04, 2005 7:43 PM
> To: Jakarta Commons Developers List
> Subject: Re: Project Proposal?
>
> Brett Porter wrote:
> > http://jakarta.apache.org/commons/charter.html
> >
> > As far as I understand, as a Jakarta committer, you are entitled to just
> > start something in the sandbox - however I guess you are much more
> > likely to have the component succeed if you gather up some people who
> > want to work on it in advance.
>
> True. Also, its often good to open an email discussion, or a more formal
> proposal document (as found in each commons project) to hone your idea.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Project Proposal?
Posted by James Carman <ja...@carmanconsulting.com>.
Well, I went ahead and started the project over at java.net, but we can move
it later if need be. It's a dependency injection framework called
"syringe." The project uses the Apache License, Version 2.0. It's still
"pending approval" at java.net, so you guys won't be able to see anything
yet. It should be approved soon though.
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Thursday, August 04, 2005 7:43 PM
To: Jakarta Commons Developers List
Subject: Re: Project Proposal?
Brett Porter wrote:
> http://jakarta.apache.org/commons/charter.html
>
> As far as I understand, as a Jakarta committer, you are entitled to just
> start something in the sandbox - however I guess you are much more
> likely to have the component succeed if you gather up some people who
> want to work on it in advance.
True. Also, its often good to open an email discussion, or a more formal
proposal document (as found in each commons project) to hone your idea.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Project Proposal?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Brett Porter wrote:
> http://jakarta.apache.org/commons/charter.html
>
> As far as I understand, as a Jakarta committer, you are entitled to just
> start something in the sandbox - however I guess you are much more
> likely to have the component succeed if you gather up some people who
> want to work on it in advance.
True. Also, its often good to open an email discussion, or a more formal
proposal document (as found in each commons project) to hone your idea.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Project Proposal?
Posted by Brett Porter <br...@apache.org>.
http://jakarta.apache.org/commons/charter.html
As far as I understand, as a Jakarta committer, you are entitled to just
start something in the sandbox - however I guess you are much more
likely to have the component succeed if you gather up some people who
want to work on it in advance.
Cheers,
Brett
James Carman wrote:
>All,
>
>
>
>I have a project that I would like to maybe put into the Sandbox, but I
>couldn't find any instructions on how to go about doing that. Can anyone
>point me in the right direction?
>
>
>
>Thanks,
>
>
>
>James
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org