myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <>
Subject Re: Sandbox
Date Wed, 11 May 2005 23:12:27 GMT
What about the sourceforge project that has already been set up?

Is there any action there right now?

Can those components come right in without going through incubator?

As I understand things, a sandbox and the incubator are entirely
different - so for a component developed outside of the ASF, it has
first to clear through the incubator and then through the sandbox to
finally get in to the components subproject.

isn't that too much of an overhead?

How about having the sandbox directly in the incubator?



On 5/11/05, Grant Smith <> wrote:
>  Sean Schofield wrote: 
>  I'd like to kick off the whole sandbox debate again. Yes, I'm a sucker
> for punishment..
>  We need to start talking about this. I was going to start a thread on
> this myself ;-)
>  If I recall correctly, the consensus was to have a "sandbox subproject"
> for new components. I would like to propose a simpler solution: Why not
> have the sandbox as a subdirectory of the existing project. Then we can
> just specify all "s:" components as sandbox components until they are
> completely accepted by the community. At that time they can become "x:"
> components.
>  This suggestion has a few drawbacks. I prefer a separate subproject
> for SVN for the sandbox along with a separate build file and resulting
> jar file. This way when a component is promoted out of the sandbox
> there are no changes to the TLD and more importantly users do not have
> to change their JSF.
>  That's a good point.
>  Also, its important to be able to build and release the components
> project at any time (nightlies plus regular releases.) I'm assuming
> that the components project (Tomahawk) will be released on its own as
> well but we should also discuss that further. You don't want the
> sandbox junk cluttering up the jar file, TLD, etc. The simplest way
> to do that is to have a separate subproject.
>  The only downside that I can see right now with having a separate
> subproject is in maintaining code that is common to both. If someone patches
> code that is used in both projects, it will have to be changed in two
> places. I guess if we minimize the need for common code, this problem goes
> away. We could do that by simply requiring the myfaces.jar to be in the
> component subproject's classpath... and of course beat and torture anyone
> who tries to re-invent something that exists in the trunk :-)
>  Would this satisfy the ASF's requirement for "All New Components Must Go
> Through the Incubator" ? Hopefully...
>  I think Ted's concern regarding this (from the myfaces-pmc thread) is
> that code that is *already developed* outside of ASF should not go
> straight into the project. So for components that grow out of
> discussions on this board would not apply. Hopefully that is what he
> meant anyways.
>  I hope so too. I'd hate to have to beat or torture Ted.
>  sean
> .

View raw message