You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Grant Smith <gr...@marathon-man.com> on 2005/05/11 20:41:30 UTC
Sandbox
I'd like to kick off the whole sandbox debate again. Yes, I'm a sucker
for punishment..
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.
Would this satisfy the ASF's requirement for "All New Components Must Go
Through the Incubator" ? Hopefully...
Re: Java 5 code in Sandbox ?
Posted by Sean Schofield <se...@gmail.com>.
Because it makes things more complicated. We've got enough on our
plate now. At some point when J2SE 5.0 becomes the standard we will
switch to it.
sean
On 9/7/05, Nadeem Bitar <na...@shinzui.org> wrote:
> Why not have a separate module for jdk 5.0 stuff? The Spring framework
> and acegi security both build things differently depending on the
> detected jdk allowing the project to take advantage of jdk 5.0 features
> without penalizing the people stuck with older jdks.
>
> Nadeem
>
> On Tue, 2005-09-06 at 18:38 -0400, Sylvain Vieujot wrote:
> > Well doing a branch for the few classes I have right now really isn't
> > worth it.
> >
> > Maybe it's better to hold on this until we start JSF 1.2.
> >
> > On Wed, 2005-09-07 at 00:21 +0200, Bruno Aranda wrote:
> > > I do not thing that including JDK5.0 code in the sandbox and not in
> > > the rest is a good idea. It might create confusion... maybe we could
> > > add a JDK5.0 branch to the sandbox SVN tree and then we would keep
> > > your need code, but, IMO valid JDK1.4 code should be everywhere...
> > >
> > > Bruno
> > >
> > > P.S Currently, I am developing all my projects in JDK5.0. I have to
> > > think twice when programming for myfaces! ;-)
> > >
> > > 2005/9/7, Sylvain Vieujot <sv...@apache.org>:
> > > > I didn't mean to include it in the sandbox and hope to refactor it later.
> > > > I meant to add it to the sandbox, and to move it to tomahawk only when we
> > > > accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm not
> > > > wrong).
> > > > The point is that be refactoring those classes, we lose a lot of safety, so
> > > > I would prefer to either commit them to the sandbox if we accept JSE5 code
> > > > into it, or just hold them until we do.
> > > >
> > > > It's not crucial anyway, as those cases are still limited right now.
> > > >
> > > >
> > > > On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
> > > > IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
> > > > but chance it to 1.4 when moving to tomahawk? What would be the point
> > > > of that?
> > > > Why not refactor before adding to sandbox if this is the eventual plan?
> > > >
> > > > I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
> > > > but I definitely don't think we should add stuff and hope to refactor
> > > > it later.
> > > >
> > > > sean
> > > >
> > > > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > > Hello,
> > > > >
> > > > > I was about to commit the few Maps util classes I have when I realized
> > > > it's
> > > > > all Java 5 code (with many generics and a few annotations).
> > > > > Removing the generics would really be bad as those classes needs to be
> > > > > extended, and the generics add a lot of safety.
> > > > >
> > > > > For me it would be ok to add Java 5, and later to move it to tomahawk when
> > > > > we move to JSF 1.2, but I would need the approval of the others to do
> > > > that,
> > > > > as it would break the sandbox compilation on Java 1.4.
> > > > >
> > > > > What do you think ?
> > > > >
> > > > > Sylvain.
> > > > >
> > > > > On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> > > > > Yes...
> > > > >
> > > > > Let's put it there, and go on from this!
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > > > Hello Martin,
> > > > > >
> > > > > > No, I never committed it.
> > > > > > I think a new package would be great, but where do you want to put it ?
> > > > > > The logic would be to have it first in the sandbox, and then move it
> > > > class
> > > > > > by class tomahawk.
> > > > > >
> > > > > > Maybe a better package name would be org.apache.myfaces.utils
> > > > > > as jsfutils is redundant with myfaces. I also dropped the tomahawk part
> > > > as
> > > > > > it would be in the sandbox first, but I'm not sure about this.
> > > > > >
> > > > > > If you agree, I can commit those classes to the sandbox's
> > > > > > org.apache.myfaces.utils package, and we can start from here.
> > > > > >
> > > > > > Sylvain.
> > > > > >
> > > > > >
> > > > > > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > > > > > Sylvain,
> > > > > >
> > > > > > did you ever get around to commit this stuff? I didn't find it in the
> > > > > > sources...
> > > > > >
> > > > > > I'd like to use that as an example for something I am writing on -
> > > > > > would be great if I could just point to the MyFaces sourcebase.
> > > > > >
> > > > > > How about a new package
> > > > > >
> > > > > > org apache myfaces tomahawk jsfutils
> > > > > >
> > > > > > We could also have the user contributions like the message-remembering
> > > > > > facilities and the newly added remember request-bean over redirect
> > > > > > facilities there...
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > > > > I'm fine with that and find it simpler to have it in the trunk.
> > > > > > >
> > > > > > > I have a related question.
> > > > > > >
> > > > > > > Right now, I have done 2 little utilities that help me resolve small
> > > > > > > problems.
> > > > > > > They are 2 abstract implementations of Map : ActionMap and TestMap,
> > > > and
> > > > > I
> > > > > > > find them handy to use in many common cases.
> > > > > > >
> > > > > > > Here are 2 examples :
> > > > > > > 1) ActionMap : For example, when you have a list of file, and want to
> > > > > have
> > > > > > > a checkbox to delete a file, you just add the following code in your
> > > > > page
> > > > > > :
> > > > > > > <h:column>
> > > > > > > <h:selectBooleanCheckbox
> > > > value="#{pageFace.removeFileName[file.name]}"/>
> > > > > > > <h:outputText value="delete"/>
> > > > > > > </h:column>
> > > > > > >
> > > > > > >
> > > > > > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > > > > > return new ActionsMap(){
> > > > > > > @Override
> > > > > > > public void performAction(String fileName) {
> > > > > > > getFiles().remove( fileName );
> > > > > > > }
> > > > > > > };
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > > > > > getting a boolean result.
> > > > > > > For example, if you want to render a component if a user is in 2
> > > > roles,
> > > > > > the
> > > > > > > visibleOnUserRole isn't enough.
> > > > > > > So, in my backing bean, I have this method :
> > > > > > >
> > > > > > > public TestsMap getUserInRole(){
> > > > > > > return new TestsMap(){
> > > > > > > @Override
> > > > > > > public boolean getTest(String roleName) {
> > > > > > > return getHttpServletRequest().isUserInRole( roleName
> > > > > );
> > > > > > > }
> > > > > > > };
> > > > > > > }
> > > > > > >
> > > > > > > And now, I can do any test I want in EL :
> > > > > > > #{myBean.isUserInRole['Accountant'] &&
> > > > > myBean.isUserInRole['CountryUnit']}
> > > > > > >
> > > > > > > It's quite limited now, but due to the limitations of the EL, small
> > > > > > > utilities like that can help.
> > > > > > > My suggestion is to do a utilities library (similar to commons.lang,
> > > > > with
> > > > > > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > > > > > emerge.
> > > > > > >
> > > > > > > So, I wonder first if you guys feels this is of any use to include
> > > > this
> > > > > in
> > > > > > > MyFaces, and if so, how do we handle that ?
> > > > > > > Those aren't components, but should we do a sandbox for libraries to,
> > > > or
> > > > > > > just an additional myfaces-utilities.jar ????
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Sylvain.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > Would this satisfy the ASF's requirement for "All New Components Must
> > > > Go
> > > > > > > Through the Incubator" ? Hopefully...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
>
>
Re: Java 5 code in Sandbox ?
Posted by Martin Marinschek <ma...@gmail.com>.
yes, ok, let's wait!
JDK 1.5 in the sandbox right now is not a good idea, I think.
regards,
Martin
On 9/7/05, Sylvain Vieujot <sv...@apache.org> wrote:
> Well doing a branch for the few classes I have right now really isn't worth
> it.
>
> Maybe it's better to hold on this until we start JSF 1.2.
>
>
> On Wed, 2005-09-07 at 00:21 +0200, Bruno Aranda wrote:
> I do not thing that including JDK5.0 code in the sandbox and not in
> the rest is a good idea. It might create confusion... maybe we could
> add a JDK5.0 branch to the sandbox SVN tree and then we would keep
> your need code, but, IMO valid JDK1.4 code should be everywhere...
>
> Bruno
>
> P.S Currently, I am developing all my projects in JDK5.0. I have to
> think twice when programming for myfaces! ;-)
>
> 2005/9/7, Sylvain Vieujot <sv...@apache.org>:
> > I didn't mean to include it in the sandbox and hope to refactor it later.
> > I meant to add it to the sandbox, and to move it to tomahawk only when we
> > accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm not
> > wrong).
> > The point is that be refactoring those classes, we lose a lot of safety,
> so
> > I would prefer to either commit them to the sandbox if we accept JSE5 code
> > into it, or just hold them until we do.
> >
> > It's not crucial anyway, as those cases are still limited right now.
> >
> >
> > On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
> > IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
> > but chance it to 1.4 when moving to tomahawk? What would be the point
> > of that?
> > Why not refactor before adding to sandbox if this is the eventual plan?
> >
> > I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
> > but I definitely don't think we should add stuff and hope to refactor
> > it later.
> >
> > sean
> >
> > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > Hello,
> > >
> > > I was about to commit the few Maps util classes I have when I realized
> > it's
> > > all Java 5 code (with many generics and a few annotations).
> > > Removing the generics would really be bad as those classes needs to be
> > > extended, and the generics add a lot of safety.
> > >
> > > For me it would be ok to add Java 5, and later to move it to tomahawk
> when
> > > we move to JSF 1.2, but I would need the approval of the others to do
> > that,
> > > as it would break the sandbox compilation on Java 1.4.
> > >
> > > What do you think ?
> > >
> > > Sylvain.
> > >
> > > On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> > > Yes...
> > >
> > > Let's put it there, and go on from this!
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > Hello Martin,
> > > >
> > > > No, I never committed it.
> > > > I think a new package would be great, but where do you want to put it
> ?
> > > > The logic would be to have it first in the sandbox, and then move it
> > class
> > > > by class tomahawk.
> > > >
> > > > Maybe a better package name would be org.apache.myfaces.utils
> > > > as jsfutils is redundant with myfaces. I also dropped the tomahawk
> part
> > as
> > > > it would be in the sandbox first, but I'm not sure about this.
> > > >
> > > > If you agree, I can commit those classes to the sandbox's
> > > > org.apache.myfaces.utils package, and we can start from here.
> > > >
> > > > Sylvain.
> > > >
> > > >
> > > > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > > > Sylvain,
> > > >
> > > > did you ever get around to commit this stuff? I didn't find it in the
> > > > sources...
> > > >
> > > > I'd like to use that as an example for something I am writing on -
> > > > would be great if I could just point to the MyFaces sourcebase.
> > > >
> > > > How about a new package
> > > >
> > > > org apache myfaces tomahawk jsfutils
> > > >
> > > > We could also have the user contributions like the message-remembering
> > > > facilities and the newly added remember request-bean over redirect
> > > > facilities there...
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > > I'm fine with that and find it simpler to have it in the trunk.
> > > > >
> > > > > I have a related question.
> > > > >
> > > > > Right now, I have done 2 little utilities that help me resolve small
> > > > > problems.
> > > > > They are 2 abstract implementations of Map : ActionMap and TestMap,
> > and
> > > I
> > > > > find them handy to use in many common cases.
> > > > >
> > > > > Here are 2 examples :
> > > > > 1) ActionMap : For example, when you have a list of file, and want
> to
> > > have
> > > > > a checkbox to delete a file, you just add the following code in your
> > > page
> > > > :
> > > > > <h:column>
> > > > > <h:selectBooleanCheckbox
> > value="#{pageFace.removeFileName[file.name]}"/>
> > > > > <h:outputText value="delete"/>
> > > > > </h:column>
> > > > >
> > > > >
> > > > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > > > return new ActionsMap(){
> > > > > @Override
> > > > > public void performAction(String fileName) {
> > > > > getFiles().remove( fileName );
> > > > > }
> > > > > };
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > > > getting a boolean result.
> > > > > For example, if you want to render a component if a user is in 2
> > roles,
> > > > the
> > > > > visibleOnUserRole isn't enough.
> > > > > So, in my backing bean, I have this method :
> > > > >
> > > > > public TestsMap getUserInRole(){
> > > > > return new TestsMap(){
> > > > > @Override
> > > > > public boolean getTest(String roleName) {
> > > > > return getHttpServletRequest().isUserInRole(
> roleName
> > > );
> > > > > }
> > > > > };
> > > > > }
> > > > >
> > > > > And now, I can do any test I want in EL :
> > > > > #{myBean.isUserInRole['Accountant'] &&
> > > myBean.isUserInRole['CountryUnit']}
> > > > >
> > > > > It's quite limited now, but due to the limitations of the EL, small
> > > > > utilities like that can help.
> > > > > My suggestion is to do a utilities library (similar to commons.lang,
> > > with
> > > > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > > > emerge.
> > > > >
> > > > > So, I wonder first if you guys feels this is of any use to include
> > this
> > > in
> > > > > MyFaces, and if so, how do we handle that ?
> > > > > Those aren't components, but should we do a sandbox for libraries
> to,
> > or
> > > > > just an additional myfaces-utilities.jar ????
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Sylvain.
> > > > >
> > > > >
> > > > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > > > >
> > > > > 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.
> > > > >
> > > > > Would this satisfy the ASF's requirement for "All New Components
> Must
> > Go
> > > > > Through the Incubator" ? Hopefully...
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: Java 5 code in Sandbox ?
Posted by Nadeem Bitar <na...@shinzui.org>.
Why not have a separate module for jdk 5.0 stuff? The Spring framework
and acegi security both build things differently depending on the
detected jdk allowing the project to take advantage of jdk 5.0 features
without penalizing the people stuck with older jdks.
Nadeem
On Tue, 2005-09-06 at 18:38 -0400, Sylvain Vieujot wrote:
> Well doing a branch for the few classes I have right now really isn't
> worth it.
>
> Maybe it's better to hold on this until we start JSF 1.2.
>
> On Wed, 2005-09-07 at 00:21 +0200, Bruno Aranda wrote:
> > I do not thing that including JDK5.0 code in the sandbox and not in
> > the rest is a good idea. It might create confusion... maybe we could
> > add a JDK5.0 branch to the sandbox SVN tree and then we would keep
> > your need code, but, IMO valid JDK1.4 code should be everywhere...
> >
> > Bruno
> >
> > P.S Currently, I am developing all my projects in JDK5.0. I have to
> > think twice when programming for myfaces! ;-)
> >
> > 2005/9/7, Sylvain Vieujot <sv...@apache.org>:
> > > I didn't mean to include it in the sandbox and hope to refactor it later.
> > > I meant to add it to the sandbox, and to move it to tomahawk only when we
> > > accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm not
> > > wrong).
> > > The point is that be refactoring those classes, we lose a lot of safety, so
> > > I would prefer to either commit them to the sandbox if we accept JSE5 code
> > > into it, or just hold them until we do.
> > >
> > > It's not crucial anyway, as those cases are still limited right now.
> > >
> > >
> > > On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
> > > IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
> > > but chance it to 1.4 when moving to tomahawk? What would be the point
> > > of that?
> > > Why not refactor before adding to sandbox if this is the eventual plan?
> > >
> > > I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
> > > but I definitely don't think we should add stuff and hope to refactor
> > > it later.
> > >
> > > sean
> > >
> > > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > Hello,
> > > >
> > > > I was about to commit the few Maps util classes I have when I realized
> > > it's
> > > > all Java 5 code (with many generics and a few annotations).
> > > > Removing the generics would really be bad as those classes needs to be
> > > > extended, and the generics add a lot of safety.
> > > >
> > > > For me it would be ok to add Java 5, and later to move it to tomahawk when
> > > > we move to JSF 1.2, but I would need the approval of the others to do
> > > that,
> > > > as it would break the sandbox compilation on Java 1.4.
> > > >
> > > > What do you think ?
> > > >
> > > > Sylvain.
> > > >
> > > > On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> > > > Yes...
> > > >
> > > > Let's put it there, and go on from this!
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > > Hello Martin,
> > > > >
> > > > > No, I never committed it.
> > > > > I think a new package would be great, but where do you want to put it ?
> > > > > The logic would be to have it first in the sandbox, and then move it
> > > class
> > > > > by class tomahawk.
> > > > >
> > > > > Maybe a better package name would be org.apache.myfaces.utils
> > > > > as jsfutils is redundant with myfaces. I also dropped the tomahawk part
> > > as
> > > > > it would be in the sandbox first, but I'm not sure about this.
> > > > >
> > > > > If you agree, I can commit those classes to the sandbox's
> > > > > org.apache.myfaces.utils package, and we can start from here.
> > > > >
> > > > > Sylvain.
> > > > >
> > > > >
> > > > > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > > > > Sylvain,
> > > > >
> > > > > did you ever get around to commit this stuff? I didn't find it in the
> > > > > sources...
> > > > >
> > > > > I'd like to use that as an example for something I am writing on -
> > > > > would be great if I could just point to the MyFaces sourcebase.
> > > > >
> > > > > How about a new package
> > > > >
> > > > > org apache myfaces tomahawk jsfutils
> > > > >
> > > > > We could also have the user contributions like the message-remembering
> > > > > facilities and the newly added remember request-bean over redirect
> > > > > facilities there...
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > > > I'm fine with that and find it simpler to have it in the trunk.
> > > > > >
> > > > > > I have a related question.
> > > > > >
> > > > > > Right now, I have done 2 little utilities that help me resolve small
> > > > > > problems.
> > > > > > They are 2 abstract implementations of Map : ActionMap and TestMap,
> > > and
> > > > I
> > > > > > find them handy to use in many common cases.
> > > > > >
> > > > > > Here are 2 examples :
> > > > > > 1) ActionMap : For example, when you have a list of file, and want to
> > > > have
> > > > > > a checkbox to delete a file, you just add the following code in your
> > > > page
> > > > > :
> > > > > > <h:column>
> > > > > > <h:selectBooleanCheckbox
> > > value="#{pageFace.removeFileName[file.name]}"/>
> > > > > > <h:outputText value="delete"/>
> > > > > > </h:column>
> > > > > >
> > > > > >
> > > > > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > > > > return new ActionsMap(){
> > > > > > @Override
> > > > > > public void performAction(String fileName) {
> > > > > > getFiles().remove( fileName );
> > > > > > }
> > > > > > };
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > > > > getting a boolean result.
> > > > > > For example, if you want to render a component if a user is in 2
> > > roles,
> > > > > the
> > > > > > visibleOnUserRole isn't enough.
> > > > > > So, in my backing bean, I have this method :
> > > > > >
> > > > > > public TestsMap getUserInRole(){
> > > > > > return new TestsMap(){
> > > > > > @Override
> > > > > > public boolean getTest(String roleName) {
> > > > > > return getHttpServletRequest().isUserInRole( roleName
> > > > );
> > > > > > }
> > > > > > };
> > > > > > }
> > > > > >
> > > > > > And now, I can do any test I want in EL :
> > > > > > #{myBean.isUserInRole['Accountant'] &&
> > > > myBean.isUserInRole['CountryUnit']}
> > > > > >
> > > > > > It's quite limited now, but due to the limitations of the EL, small
> > > > > > utilities like that can help.
> > > > > > My suggestion is to do a utilities library (similar to commons.lang,
> > > > with
> > > > > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > > > > emerge.
> > > > > >
> > > > > > So, I wonder first if you guys feels this is of any use to include
> > > this
> > > > in
> > > > > > MyFaces, and if so, how do we handle that ?
> > > > > > Those aren't components, but should we do a sandbox for libraries to,
> > > or
> > > > > > just an additional myfaces-utilities.jar ????
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Sylvain.
> > > > > >
> > > > > >
> > > > > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > Would this satisfy the ASF's requirement for "All New Components Must
> > > Go
> > > > > > Through the Incubator" ? Hopefully...
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
Re: Java 5 code in Sandbox ?
Posted by Sylvain Vieujot <sv...@apache.org>.
Well doing a branch for the few classes I have right now really isn't
worth it.
Maybe it's better to hold on this until we start JSF 1.2.
On Wed, 2005-09-07 at 00:21 +0200, Bruno Aranda wrote:
> I do not thing that including JDK5.0 code in the sandbox and not in
> the rest is a good idea. It might create confusion... maybe we could
> add a JDK5.0 branch to the sandbox SVN tree and then we would keep
> your need code, but, IMO valid JDK1.4 code should be everywhere...
>
> Bruno
>
> P.S Currently, I am developing all my projects in JDK5.0. I have to
> think twice when programming for myfaces! ;-)
>
> 2005/9/7, Sylvain Vieujot <sv...@apache.org>:
> > I didn't mean to include it in the sandbox and hope to refactor it later.
> > I meant to add it to the sandbox, and to move it to tomahawk only when we
> > accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm not
> > wrong).
> > The point is that be refactoring those classes, we lose a lot of safety, so
> > I would prefer to either commit them to the sandbox if we accept JSE5 code
> > into it, or just hold them until we do.
> >
> > It's not crucial anyway, as those cases are still limited right now.
> >
> >
> > On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
> > IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
> > but chance it to 1.4 when moving to tomahawk? What would be the point
> > of that?
> > Why not refactor before adding to sandbox if this is the eventual plan?
> >
> > I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
> > but I definitely don't think we should add stuff and hope to refactor
> > it later.
> >
> > sean
> >
> > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > Hello,
> > >
> > > I was about to commit the few Maps util classes I have when I realized
> > it's
> > > all Java 5 code (with many generics and a few annotations).
> > > Removing the generics would really be bad as those classes needs to be
> > > extended, and the generics add a lot of safety.
> > >
> > > For me it would be ok to add Java 5, and later to move it to tomahawk when
> > > we move to JSF 1.2, but I would need the approval of the others to do
> > that,
> > > as it would break the sandbox compilation on Java 1.4.
> > >
> > > What do you think ?
> > >
> > > Sylvain.
> > >
> > > On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> > > Yes...
> > >
> > > Let's put it there, and go on from this!
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > Hello Martin,
> > > >
> > > > No, I never committed it.
> > > > I think a new package would be great, but where do you want to put it ?
> > > > The logic would be to have it first in the sandbox, and then move it
> > class
> > > > by class tomahawk.
> > > >
> > > > Maybe a better package name would be org.apache.myfaces.utils
> > > > as jsfutils is redundant with myfaces. I also dropped the tomahawk part
> > as
> > > > it would be in the sandbox first, but I'm not sure about this.
> > > >
> > > > If you agree, I can commit those classes to the sandbox's
> > > > org.apache.myfaces.utils package, and we can start from here.
> > > >
> > > > Sylvain.
> > > >
> > > >
> > > > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > > > Sylvain,
> > > >
> > > > did you ever get around to commit this stuff? I didn't find it in the
> > > > sources...
> > > >
> > > > I'd like to use that as an example for something I am writing on -
> > > > would be great if I could just point to the MyFaces sourcebase.
> > > >
> > > > How about a new package
> > > >
> > > > org apache myfaces tomahawk jsfutils
> > > >
> > > > We could also have the user contributions like the message-remembering
> > > > facilities and the newly added remember request-bean over redirect
> > > > facilities there...
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > > I'm fine with that and find it simpler to have it in the trunk.
> > > > >
> > > > > I have a related question.
> > > > >
> > > > > Right now, I have done 2 little utilities that help me resolve small
> > > > > problems.
> > > > > They are 2 abstract implementations of Map : ActionMap and TestMap,
> > and
> > > I
> > > > > find them handy to use in many common cases.
> > > > >
> > > > > Here are 2 examples :
> > > > > 1) ActionMap : For example, when you have a list of file, and want to
> > > have
> > > > > a checkbox to delete a file, you just add the following code in your
> > > page
> > > > :
> > > > > <h:column>
> > > > > <h:selectBooleanCheckbox
> > value="#{pageFace.removeFileName[file.name]}"/>
> > > > > <h:outputText value="delete"/>
> > > > > </h:column>
> > > > >
> > > > >
> > > > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > > > return new ActionsMap(){
> > > > > @Override
> > > > > public void performAction(String fileName) {
> > > > > getFiles().remove( fileName );
> > > > > }
> > > > > };
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > > > getting a boolean result.
> > > > > For example, if you want to render a component if a user is in 2
> > roles,
> > > > the
> > > > > visibleOnUserRole isn't enough.
> > > > > So, in my backing bean, I have this method :
> > > > >
> > > > > public TestsMap getUserInRole(){
> > > > > return new TestsMap(){
> > > > > @Override
> > > > > public boolean getTest(String roleName) {
> > > > > return getHttpServletRequest().isUserInRole( roleName
> > > );
> > > > > }
> > > > > };
> > > > > }
> > > > >
> > > > > And now, I can do any test I want in EL :
> > > > > #{myBean.isUserInRole['Accountant'] &&
> > > myBean.isUserInRole['CountryUnit']}
> > > > >
> > > > > It's quite limited now, but due to the limitations of the EL, small
> > > > > utilities like that can help.
> > > > > My suggestion is to do a utilities library (similar to commons.lang,
> > > with
> > > > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > > > emerge.
> > > > >
> > > > > So, I wonder first if you guys feels this is of any use to include
> > this
> > > in
> > > > > MyFaces, and if so, how do we handle that ?
> > > > > Those aren't components, but should we do a sandbox for libraries to,
> > or
> > > > > just an additional myfaces-utilities.jar ????
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Sylvain.
> > > > >
> > > > >
> > > > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > > > >
> > > > > 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.
> > > > >
> > > > > Would this satisfy the ASF's requirement for "All New Components Must
> > Go
> > > > > Through the Incubator" ? Hopefully...
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
Re: Java 5 code in Sandbox ?
Posted by Bruno Aranda <br...@gmail.com>.
I do not thing that including JDK5.0 code in the sandbox and not in
the rest is a good idea. It might create confusion... maybe we could
add a JDK5.0 branch to the sandbox SVN tree and then we would keep
your need code, but, IMO valid JDK1.4 code should be everywhere...
Bruno
P.S Currently, I am developing all my projects in JDK5.0. I have to
think twice when programming for myfaces! ;-)
2005/9/7, Sylvain Vieujot <sv...@apache.org>:
> I didn't mean to include it in the sandbox and hope to refactor it later.
> I meant to add it to the sandbox, and to move it to tomahawk only when we
> accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm not
> wrong).
> The point is that be refactoring those classes, we lose a lot of safety, so
> I would prefer to either commit them to the sandbox if we accept JSE5 code
> into it, or just hold them until we do.
>
> It's not crucial anyway, as those cases are still limited right now.
>
>
> On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
> IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
> but chance it to 1.4 when moving to tomahawk? What would be the point
> of that?
> Why not refactor before adding to sandbox if this is the eventual plan?
>
> I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
> but I definitely don't think we should add stuff and hope to refactor
> it later.
>
> sean
>
> On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > Hello,
> >
> > I was about to commit the few Maps util classes I have when I realized
> it's
> > all Java 5 code (with many generics and a few annotations).
> > Removing the generics would really be bad as those classes needs to be
> > extended, and the generics add a lot of safety.
> >
> > For me it would be ok to add Java 5, and later to move it to tomahawk when
> > we move to JSF 1.2, but I would need the approval of the others to do
> that,
> > as it would break the sandbox compilation on Java 1.4.
> >
> > What do you think ?
> >
> > Sylvain.
> >
> > On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> > Yes...
> >
> > Let's put it there, and go on from this!
> >
> > regards,
> >
> > Martin
> >
> > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > Hello Martin,
> > >
> > > No, I never committed it.
> > > I think a new package would be great, but where do you want to put it ?
> > > The logic would be to have it first in the sandbox, and then move it
> class
> > > by class tomahawk.
> > >
> > > Maybe a better package name would be org.apache.myfaces.utils
> > > as jsfutils is redundant with myfaces. I also dropped the tomahawk part
> as
> > > it would be in the sandbox first, but I'm not sure about this.
> > >
> > > If you agree, I can commit those classes to the sandbox's
> > > org.apache.myfaces.utils package, and we can start from here.
> > >
> > > Sylvain.
> > >
> > >
> > > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > > Sylvain,
> > >
> > > did you ever get around to commit this stuff? I didn't find it in the
> > > sources...
> > >
> > > I'd like to use that as an example for something I am writing on -
> > > would be great if I could just point to the MyFaces sourcebase.
> > >
> > > How about a new package
> > >
> > > org apache myfaces tomahawk jsfutils
> > >
> > > We could also have the user contributions like the message-remembering
> > > facilities and the newly added remember request-bean over redirect
> > > facilities there...
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > I'm fine with that and find it simpler to have it in the trunk.
> > > >
> > > > I have a related question.
> > > >
> > > > Right now, I have done 2 little utilities that help me resolve small
> > > > problems.
> > > > They are 2 abstract implementations of Map : ActionMap and TestMap,
> and
> > I
> > > > find them handy to use in many common cases.
> > > >
> > > > Here are 2 examples :
> > > > 1) ActionMap : For example, when you have a list of file, and want to
> > have
> > > > a checkbox to delete a file, you just add the following code in your
> > page
> > > :
> > > > <h:column>
> > > > <h:selectBooleanCheckbox
> value="#{pageFace.removeFileName[file.name]}"/>
> > > > <h:outputText value="delete"/>
> > > > </h:column>
> > > >
> > > >
> > > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > > return new ActionsMap(){
> > > > @Override
> > > > public void performAction(String fileName) {
> > > > getFiles().remove( fileName );
> > > > }
> > > > };
> > > > }
> > > >
> > > >
> > > >
> > > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > > getting a boolean result.
> > > > For example, if you want to render a component if a user is in 2
> roles,
> > > the
> > > > visibleOnUserRole isn't enough.
> > > > So, in my backing bean, I have this method :
> > > >
> > > > public TestsMap getUserInRole(){
> > > > return new TestsMap(){
> > > > @Override
> > > > public boolean getTest(String roleName) {
> > > > return getHttpServletRequest().isUserInRole( roleName
> > );
> > > > }
> > > > };
> > > > }
> > > >
> > > > And now, I can do any test I want in EL :
> > > > #{myBean.isUserInRole['Accountant'] &&
> > myBean.isUserInRole['CountryUnit']}
> > > >
> > > > It's quite limited now, but due to the limitations of the EL, small
> > > > utilities like that can help.
> > > > My suggestion is to do a utilities library (similar to commons.lang,
> > with
> > > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > > emerge.
> > > >
> > > > So, I wonder first if you guys feels this is of any use to include
> this
> > in
> > > > MyFaces, and if so, how do we handle that ?
> > > > Those aren't components, but should we do a sandbox for libraries to,
> or
> > > > just an additional myfaces-utilities.jar ????
> > > >
> > > > Thanks,
> > > >
> > > > Sylvain.
> > > >
> > > >
> > > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > > >
> > > > 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.
> > > >
> > > > Would this satisfy the ASF's requirement for "All New Components Must
> Go
> > > > Through the Incubator" ? Hopefully...
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
Re: Java 5 code in Sandbox ?
Posted by Sylvain Vieujot <sv...@apache.org>.
I didn't mean to include it in the sandbox and hope to refactor it
later.
I meant to add it to the sandbox, and to move it to tomahawk only when
we accept JSE5 code in tomahawk (which is required for JSF 1.2 if I'm
not wrong).
The point is that be refactoring those classes, we lose a lot of safety,
so I would prefer to either commit them to the sandbox if we accept JSE5
code into it, or just hold them until we do.
It's not crucial anyway, as those cases are still limited right now.
On Tue, 2005-09-06 at 17:34 -0400, Sean Schofield wrote:
> IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
> but chance it to 1.4 when moving to tomahawk? What would be the point
> of that?
> Why not refactor before adding to sandbox if this is the eventual plan?
>
> I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
> but I definitely don't think we should add stuff and hope to refactor
> it later.
>
> sean
>
> On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > Hello,
> >
> > I was about to commit the few Maps util classes I have when I realized it's
> > all Java 5 code (with many generics and a few annotations).
> > Removing the generics would really be bad as those classes needs to be
> > extended, and the generics add a lot of safety.
> >
> > For me it would be ok to add Java 5, and later to move it to tomahawk when
> > we move to JSF 1.2, but I would need the approval of the others to do that,
> > as it would break the sandbox compilation on Java 1.4.
> >
> > What do you think ?
> >
> > Sylvain.
> >
> > On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> > Yes...
> >
> > Let's put it there, and go on from this!
> >
> > regards,
> >
> > Martin
> >
> > On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > Hello Martin,
> > >
> > > No, I never committed it.
> > > I think a new package would be great, but where do you want to put it ?
> > > The logic would be to have it first in the sandbox, and then move it class
> > > by class tomahawk.
> > >
> > > Maybe a better package name would be org.apache.myfaces.utils
> > > as jsfutils is redundant with myfaces. I also dropped the tomahawk part as
> > > it would be in the sandbox first, but I'm not sure about this.
> > >
> > > If you agree, I can commit those classes to the sandbox's
> > > org.apache.myfaces.utils package, and we can start from here.
> > >
> > > Sylvain.
> > >
> > >
> > > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > > Sylvain,
> > >
> > > did you ever get around to commit this stuff? I didn't find it in the
> > > sources...
> > >
> > > I'd like to use that as an example for something I am writing on -
> > > would be great if I could just point to the MyFaces sourcebase.
> > >
> > > How about a new package
> > >
> > > org apache myfaces tomahawk jsfutils
> > >
> > > We could also have the user contributions like the message-remembering
> > > facilities and the newly added remember request-bean over redirect
> > > facilities there...
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > > I'm fine with that and find it simpler to have it in the trunk.
> > > >
> > > > I have a related question.
> > > >
> > > > Right now, I have done 2 little utilities that help me resolve small
> > > > problems.
> > > > They are 2 abstract implementations of Map : ActionMap and TestMap, and
> > I
> > > > find them handy to use in many common cases.
> > > >
> > > > Here are 2 examples :
> > > > 1) ActionMap : For example, when you have a list of file, and want to
> > have
> > > > a checkbox to delete a file, you just add the following code in your
> > page
> > > :
> > > > <h:column>
> > > > <h:selectBooleanCheckbox value="#{pageFace.removeFileName[file.name]}"/>
> > > > <h:outputText value="delete"/>
> > > > </h:column>
> > > >
> > > >
> > > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > > return new ActionsMap(){
> > > > @Override
> > > > public void performAction(String fileName) {
> > > > getFiles().remove( fileName );
> > > > }
> > > > };
> > > > }
> > > >
> > > >
> > > >
> > > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > > getting a boolean result.
> > > > For example, if you want to render a component if a user is in 2 roles,
> > > the
> > > > visibleOnUserRole isn't enough.
> > > > So, in my backing bean, I have this method :
> > > >
> > > > public TestsMap getUserInRole(){
> > > > return new TestsMap(){
> > > > @Override
> > > > public boolean getTest(String roleName) {
> > > > return getHttpServletRequest().isUserInRole( roleName
> > );
> > > > }
> > > > };
> > > > }
> > > >
> > > > And now, I can do any test I want in EL :
> > > > #{myBean.isUserInRole['Accountant'] &&
> > myBean.isUserInRole['CountryUnit']}
> > > >
> > > > It's quite limited now, but due to the limitations of the EL, small
> > > > utilities like that can help.
> > > > My suggestion is to do a utilities library (similar to commons.lang,
> > with
> > > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > > emerge.
> > > >
> > > > So, I wonder first if you guys feels this is of any use to include this
> > in
> > > > MyFaces, and if so, how do we handle that ?
> > > > Those aren't components, but should we do a sandbox for libraries to, or
> > > > just an additional myfaces-utilities.jar ????
> > > >
> > > > Thanks,
> > > >
> > > > Sylvain.
> > > >
> > > >
> > > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > > >
> > > > 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.
> > > >
> > > > Would this satisfy the ASF's requirement for "All New Components Must Go
> > > > Through the Incubator" ? Hopefully...
> > >
> > >
> > >
> > >
> >
> >
> >
> >
Re: Java 5 code in Sandbox ?
Posted by Sean Schofield <se...@gmail.com>.
IMO that's a bad idea. Why would you add it with JSE 5 to the sandbox
but chance it to 1.4 when moving to tomahawk? What would be the point
of that?
Why not refactor before adding to sandbox if this is the eventual plan?
I'm not sure how I feel about requiring JSE 5 (I don't use it myself)
but I definitely don't think we should add stuff and hope to refactor
it later.
sean
On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> Hello,
>
> I was about to commit the few Maps util classes I have when I realized it's
> all Java 5 code (with many generics and a few annotations).
> Removing the generics would really be bad as those classes needs to be
> extended, and the generics add a lot of safety.
>
> For me it would be ok to add Java 5, and later to move it to tomahawk when
> we move to JSF 1.2, but I would need the approval of the others to do that,
> as it would break the sandbox compilation on Java 1.4.
>
> What do you think ?
>
> Sylvain.
>
> On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> Yes...
>
> Let's put it there, and go on from this!
>
> regards,
>
> Martin
>
> On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > Hello Martin,
> >
> > No, I never committed it.
> > I think a new package would be great, but where do you want to put it ?
> > The logic would be to have it first in the sandbox, and then move it class
> > by class tomahawk.
> >
> > Maybe a better package name would be org.apache.myfaces.utils
> > as jsfutils is redundant with myfaces. I also dropped the tomahawk part as
> > it would be in the sandbox first, but I'm not sure about this.
> >
> > If you agree, I can commit those classes to the sandbox's
> > org.apache.myfaces.utils package, and we can start from here.
> >
> > Sylvain.
> >
> >
> > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > Sylvain,
> >
> > did you ever get around to commit this stuff? I didn't find it in the
> > sources...
> >
> > I'd like to use that as an example for something I am writing on -
> > would be great if I could just point to the MyFaces sourcebase.
> >
> > How about a new package
> >
> > org apache myfaces tomahawk jsfutils
> >
> > We could also have the user contributions like the message-remembering
> > facilities and the newly added remember request-bean over redirect
> > facilities there...
> >
> > regards,
> >
> > Martin
> >
> > On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > I'm fine with that and find it simpler to have it in the trunk.
> > >
> > > I have a related question.
> > >
> > > Right now, I have done 2 little utilities that help me resolve small
> > > problems.
> > > They are 2 abstract implementations of Map : ActionMap and TestMap, and
> I
> > > find them handy to use in many common cases.
> > >
> > > Here are 2 examples :
> > > 1) ActionMap : For example, when you have a list of file, and want to
> have
> > > a checkbox to delete a file, you just add the following code in your
> page
> > :
> > > <h:column>
> > > <h:selectBooleanCheckbox value="#{pageFace.removeFileName[file.name]}"/>
> > > <h:outputText value="delete"/>
> > > </h:column>
> > >
> > >
> > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > return new ActionsMap(){
> > > @Override
> > > public void performAction(String fileName) {
> > > getFiles().remove( fileName );
> > > }
> > > };
> > > }
> > >
> > >
> > >
> > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > getting a boolean result.
> > > For example, if you want to render a component if a user is in 2 roles,
> > the
> > > visibleOnUserRole isn't enough.
> > > So, in my backing bean, I have this method :
> > >
> > > public TestsMap getUserInRole(){
> > > return new TestsMap(){
> > > @Override
> > > public boolean getTest(String roleName) {
> > > return getHttpServletRequest().isUserInRole( roleName
> );
> > > }
> > > };
> > > }
> > >
> > > And now, I can do any test I want in EL :
> > > #{myBean.isUserInRole['Accountant'] &&
> myBean.isUserInRole['CountryUnit']}
> > >
> > > It's quite limited now, but due to the limitations of the EL, small
> > > utilities like that can help.
> > > My suggestion is to do a utilities library (similar to commons.lang,
> with
> > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > emerge.
> > >
> > > So, I wonder first if you guys feels this is of any use to include this
> in
> > > MyFaces, and if so, how do we handle that ?
> > > Those aren't components, but should we do a sandbox for libraries to, or
> > > just an additional myfaces-utilities.jar ????
> > >
> > > Thanks,
> > >
> > > Sylvain.
> > >
> > >
> > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > >
> > > 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.
> > >
> > > Would this satisfy the ASF's requirement for "All New Components Must Go
> > > Through the Incubator" ? Hopefully...
> >
> >
> >
> >
>
>
>
>
Java 5 code in Sandbox ?
Posted by Sylvain Vieujot <sv...@apache.org>.
Hello,
I was about to commit the few Maps util classes I have when I realized
it's all Java 5 code (with many generics and a few annotations).
Removing the generics would really be bad as those classes needs to be
extended, and the generics add a lot of safety.
For me it would be ok to add Java 5, and later to move it to tomahawk
when we move to JSF 1.2, but I would need the approval of the others to
do that, as it would break the sandbox compilation on Java 1.4.
What do you think ?
Sylvain.
On Tue, 2005-09-06 at 13:09 +0200, Martin Marinschek wrote:
> Yes...
>
> Let's put it there, and go on from this!
>
> regards,
>
> Martin
>
> On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > Hello Martin,
> >
> > No, I never committed it.
> > I think a new package would be great, but where do you want to put it ?
> > The logic would be to have it first in the sandbox, and then move it class
> > by class tomahawk.
> >
> > Maybe a better package name would be org.apache.myfaces.utils
> > as jsfutils is redundant with myfaces. I also dropped the tomahawk part as
> > it would be in the sandbox first, but I'm not sure about this.
> >
> > If you agree, I can commit those classes to the sandbox's
> > org.apache.myfaces.utils package, and we can start from here.
> >
> > Sylvain.
> >
> >
> > On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> > Sylvain,
> >
> > did you ever get around to commit this stuff? I didn't find it in the
> > sources...
> >
> > I'd like to use that as an example for something I am writing on -
> > would be great if I could just point to the MyFaces sourcebase.
> >
> > How about a new package
> >
> > org apache myfaces tomahawk jsfutils
> >
> > We could also have the user contributions like the message-remembering
> > facilities and the newly added remember request-bean over redirect
> > facilities there...
> >
> > regards,
> >
> > Martin
> >
> > On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > > I'm fine with that and find it simpler to have it in the trunk.
> > >
> > > I have a related question.
> > >
> > > Right now, I have done 2 little utilities that help me resolve small
> > > problems.
> > > They are 2 abstract implementations of Map : ActionMap and TestMap, and I
> > > find them handy to use in many common cases.
> > >
> > > Here are 2 examples :
> > > 1) ActionMap : For example, when you have a list of file, and want to have
> > > a checkbox to delete a file, you just add the following code in your page
> > :
> > > <h:column>
> > > <h:selectBooleanCheckbox value="#{pageFace.removeFileName[file.name]}"/>
> > > <h:outputText value="delete"/>
> > > </h:column>
> > >
> > >
> > > And in your backing bean : public ActionsMap getRemoveFileName(){
> > > return new ActionsMap(){
> > > @Override
> > > public void performAction(String fileName) {
> > > getFiles().remove( fileName );
> > > }
> > > };
> > > }
> > >
> > >
> > >
> > > 2) TestMap : I use it to pass parameters to methods using a map, and
> > > getting a boolean result.
> > > For example, if you want to render a component if a user is in 2 roles,
> > the
> > > visibleOnUserRole isn't enough.
> > > So, in my backing bean, I have this method :
> > >
> > > public TestsMap getUserInRole(){
> > > return new TestsMap(){
> > > @Override
> > > public boolean getTest(String roleName) {
> > > return getHttpServletRequest().isUserInRole( roleName );
> > > }
> > > };
> > > }
> > >
> > > And now, I can do any test I want in EL :
> > > #{myBean.isUserInRole['Accountant'] && myBean.isUserInRole['CountryUnit']}
> > >
> > > It's quite limited now, but due to the limitations of the EL, small
> > > utilities like that can help.
> > > My suggestion is to do a utilities library (similar to commons.lang, with
> > > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> > emerge.
> > >
> > > So, I wonder first if you guys feels this is of any use to include this in
> > > MyFaces, and if so, how do we handle that ?
> > > Those aren't components, but should we do a sandbox for libraries to, or
> > > just an additional myfaces-utilities.jar ????
> > >
> > > Thanks,
> > >
> > > Sylvain.
> > >
> > >
> > > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> > >
> > > 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.
> > >
> > > Would this satisfy the ASF's requirement for "All New Components Must Go
> > > Through the Incubator" ? Hopefully...
> >
> >
> >
> >
>
>
Re: Sandbox
Posted by Martin Marinschek <ma...@gmail.com>.
Yes...
Let's put it there, and go on from this!
regards,
Martin
On 9/6/05, Sylvain Vieujot <sv...@apache.org> wrote:
> Hello Martin,
>
> No, I never committed it.
> I think a new package would be great, but where do you want to put it ?
> The logic would be to have it first in the sandbox, and then move it class
> by class tomahawk.
>
> Maybe a better package name would be org.apache.myfaces.utils
> as jsfutils is redundant with myfaces. I also dropped the tomahawk part as
> it would be in the sandbox first, but I'm not sure about this.
>
> If you agree, I can commit those classes to the sandbox's
> org.apache.myfaces.utils package, and we can start from here.
>
> Sylvain.
>
>
> On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> Sylvain,
>
> did you ever get around to commit this stuff? I didn't find it in the
> sources...
>
> I'd like to use that as an example for something I am writing on -
> would be great if I could just point to the MyFaces sourcebase.
>
> How about a new package
>
> org apache myfaces tomahawk jsfutils
>
> We could also have the user contributions like the message-remembering
> facilities and the newly added remember request-bean over redirect
> facilities there...
>
> regards,
>
> Martin
>
> On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > I'm fine with that and find it simpler to have it in the trunk.
> >
> > I have a related question.
> >
> > Right now, I have done 2 little utilities that help me resolve small
> > problems.
> > They are 2 abstract implementations of Map : ActionMap and TestMap, and I
> > find them handy to use in many common cases.
> >
> > Here are 2 examples :
> > 1) ActionMap : For example, when you have a list of file, and want to have
> > a checkbox to delete a file, you just add the following code in your page
> :
> > <h:column>
> > <h:selectBooleanCheckbox value="#{pageFace.removeFileName[file.name]}"/>
> > <h:outputText value="delete"/>
> > </h:column>
> >
> >
> > And in your backing bean : public ActionsMap getRemoveFileName(){
> > return new ActionsMap(){
> > @Override
> > public void performAction(String fileName) {
> > getFiles().remove( fileName );
> > }
> > };
> > }
> >
> >
> >
> > 2) TestMap : I use it to pass parameters to methods using a map, and
> > getting a boolean result.
> > For example, if you want to render a component if a user is in 2 roles,
> the
> > visibleOnUserRole isn't enough.
> > So, in my backing bean, I have this method :
> >
> > public TestsMap getUserInRole(){
> > return new TestsMap(){
> > @Override
> > public boolean getTest(String roleName) {
> > return getHttpServletRequest().isUserInRole( roleName );
> > }
> > };
> > }
> >
> > And now, I can do any test I want in EL :
> > #{myBean.isUserInRole['Accountant'] && myBean.isUserInRole['CountryUnit']}
> >
> > It's quite limited now, but due to the limitations of the EL, small
> > utilities like that can help.
> > My suggestion is to do a utilities library (similar to commons.lang, with
> > StringUtils, ...) for EL, and maybe for JSF if more good candidates
> emerge.
> >
> > So, I wonder first if you guys feels this is of any use to include this in
> > MyFaces, and if so, how do we handle that ?
> > Those aren't components, but should we do a sandbox for libraries to, or
> > just an additional myfaces-utilities.jar ????
> >
> > Thanks,
> >
> > Sylvain.
> >
> >
> > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> >
> > 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.
> >
> > Would this satisfy the ASF's requirement for "All New Components Must Go
> > Through the Incubator" ? Hopefully...
>
>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: Sandbox
Posted by Sylvain Vieujot <sv...@apache.org>.
Hello Martin,
No, I never committed it.
I think a new package would be great, but where do you want to put it ?
The logic would be to have it first in the sandbox, and then move it
class by class tomahawk.
Maybe a better package name would be org.apache.myfaces.utils
as jsfutils is redundant with myfaces. I also dropped the tomahawk part
as it would be in the sandbox first, but I'm not sure about this.
If you agree, I can commit those classes to the sandbox's
org.apache.myfaces.utils package, and we can start from here.
Sylvain.
On Tue, 2005-09-06 at 07:48 +0200, Martin Marinschek wrote:
> Sylvain,
>
> did you ever get around to commit this stuff? I didn't find it in the sources...
>
> I'd like to use that as an example for something I am writing on -
> would be great if I could just point to the MyFaces sourcebase.
>
> How about a new package
>
> org apache myfaces tomahawk jsfutils
>
> We could also have the user contributions like the message-remembering
> facilities and the newly added remember request-bean over redirect
> facilities there...
>
> regards,
>
> Martin
>
> On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > I'm fine with that and find it simpler to have it in the trunk.
> >
> > I have a related question.
> >
> > Right now, I have done 2 little utilities that help me resolve small
> > problems.
> > They are 2 abstract implementations of Map : ActionMap and TestMap, and I
> > find them handy to use in many common cases.
> >
> > Here are 2 examples :
> > 1) ActionMap : For example, when you have a list of file, and want to have
> > a checkbox to delete a file, you just add the following code in your page :
> > <h:column>
> > <h:selectBooleanCheckbox value="#{pageFace.removeFileName[file.name]}"/>
> > <h:outputText value="delete"/>
> > </h:column>
> >
> >
> > And in your backing bean : public ActionsMap getRemoveFileName(){
> > return new ActionsMap(){
> > @Override
> > public void performAction(String fileName) {
> > getFiles().remove( fileName );
> > }
> > };
> > }
> >
> >
> >
> > 2) TestMap : I use it to pass parameters to methods using a map, and
> > getting a boolean result.
> > For example, if you want to render a component if a user is in 2 roles, the
> > visibleOnUserRole isn't enough.
> > So, in my backing bean, I have this method :
> >
> > public TestsMap getUserInRole(){
> > return new TestsMap(){
> > @Override
> > public boolean getTest(String roleName) {
> > return getHttpServletRequest().isUserInRole( roleName );
> > }
> > };
> > }
> >
> > And now, I can do any test I want in EL :
> > #{myBean.isUserInRole['Accountant'] && myBean.isUserInRole['CountryUnit']}
> >
> > It's quite limited now, but due to the limitations of the EL, small
> > utilities like that can help.
> > My suggestion is to do a utilities library (similar to commons.lang, with
> > StringUtils, ...) for EL, and maybe for JSF if more good candidates emerge.
> >
> > So, I wonder first if you guys feels this is of any use to include this in
> > MyFaces, and if so, how do we handle that ?
> > Those aren't components, but should we do a sandbox for libraries to, or
> > just an additional myfaces-utilities.jar ????
> >
> > Thanks,
> >
> > Sylvain.
> >
> >
> > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> >
> > 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.
> >
> > Would this satisfy the ASF's requirement for "All New Components Must Go
> > Through the Incubator" ? Hopefully...
>
>
Re: Sandbox
Posted by Martin Marinschek <ma...@gmail.com>.
Sylvain,
did you ever get around to commit this stuff? I didn't find it in the sources...
I'd like to use that as an example for something I am writing on -
would be great if I could just point to the MyFaces sourcebase.
How about a new package
org apache myfaces tomahawk jsfutils
We could also have the user contributions like the message-remembering
facilities and the newly added remember request-bean over redirect
facilities there...
regards,
Martin
On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> I'm fine with that and find it simpler to have it in the trunk.
>
> I have a related question.
>
> Right now, I have done 2 little utilities that help me resolve small
> problems.
> They are 2 abstract implementations of Map : ActionMap and TestMap, and I
> find them handy to use in many common cases.
>
> Here are 2 examples :
> 1) ActionMap : For example, when you have a list of file, and want to have
> a checkbox to delete a file, you just add the following code in your page :
> <h:column>
> <h:selectBooleanCheckbox value="#{pageFace.removeFileName[file.name]}"/>
> <h:outputText value="delete"/>
> </h:column>
>
>
> And in your backing bean : public ActionsMap getRemoveFileName(){
> return new ActionsMap(){
> @Override
> public void performAction(String fileName) {
> getFiles().remove( fileName );
> }
> };
> }
>
>
>
> 2) TestMap : I use it to pass parameters to methods using a map, and
> getting a boolean result.
> For example, if you want to render a component if a user is in 2 roles, the
> visibleOnUserRole isn't enough.
> So, in my backing bean, I have this method :
>
> public TestsMap getUserInRole(){
> return new TestsMap(){
> @Override
> public boolean getTest(String roleName) {
> return getHttpServletRequest().isUserInRole( roleName );
> }
> };
> }
>
> And now, I can do any test I want in EL :
> #{myBean.isUserInRole['Accountant'] && myBean.isUserInRole['CountryUnit']}
>
> It's quite limited now, but due to the limitations of the EL, small
> utilities like that can help.
> My suggestion is to do a utilities library (similar to commons.lang, with
> StringUtils, ...) for EL, and maybe for JSF if more good candidates emerge.
>
> So, I wonder first if you guys feels this is of any use to include this in
> MyFaces, and if so, how do we handle that ?
> Those aren't components, but should we do a sandbox for libraries to, or
> just an additional myfaces-utilities.jar ????
>
> Thanks,
>
> Sylvain.
>
>
> On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
>
> 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.
>
> Would this satisfy the ASF's requirement for "All New Components Must Go
> Through the Incubator" ? Hopefully...
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: Sandbox
Posted by Sylvain Vieujot <sv...@apache.org>.
Yes, @Override is JSE5.
It just make sure you didn't make a spelling error, and that the methods
really overrides a similar method from the super class.
I'll wait until there is a real sandbox stuff to see if it makes sense
to add it there.
Sylvain.
On Wed, 2005-05-11 at 15:41 -0400, Sean Schofield wrote:
> Sylvain,
>
> Something like this could definitely be useful although I'm not sure
> where the proper home should be. I agree the EL is a bit constraining
> right now and I have some tricks similar to this myself. BTW, what is
> @Override? Never seen that before. I'm assuming its a SE5 feature?
>
> As for the specifics of your idea, we should probably discuss on a
> separate thread (and after we have resolved sandbox, etc.) My gut
> reaaction is that this would go in the "Tomahawk" (components +
> goodies project.)
>
> sean
>
> On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > I'm fine with that and find it simpler to have it in the trunk.
> >
> > I have a related question.
> >
> > Right now, I have done 2 little utilities that help me resolve small
> > problems.
> > They are 2 abstract implementations of Map : ActionMap and TestMap, and I
> > find them handy to use in many common cases.
> >
> > Here are 2 examples :
> > 1) ActionMap : For example, when you have a list of file, and want to have
> > a checkbox to delete a file, you just add the following code in your page :
> > <h:column>
> > <h:selectBooleanCheckbox value="#{pageFace.removeFileName[file.name]}"/>
> > <h:outputText value="delete"/>
> > </h:column>
> >
> >
> > And in your backing bean : public ActionsMap getRemoveFileName(){
> > return new ActionsMap(){
> > @Override
> > public void performAction(String fileName) {
> > getFiles().remove( fileName );
> > }
> > };
> > }
> >
> >
> >
> > 2) TestMap : I use it to pass parameters to methods using a map, and
> > getting a boolean result.
> > For example, if you want to render a component if a user is in 2 roles, the
> > visibleOnUserRole isn't enough.
> > So, in my backing bean, I have this method :
> >
> > public TestsMap getUserInRole(){
> > return new TestsMap(){
> > @Override
> > public boolean getTest(String roleName) {
> > return getHttpServletRequest().isUserInRole( roleName );
> > }
> > };
> > }
> >
> > And now, I can do any test I want in EL :
> > #{myBean.isUserInRole['Accountant'] && myBean.isUserInRole['CountryUnit']}
> >
> > It's quite limited now, but due to the limitations of the EL, small
> > utilities like that can help.
> > My suggestion is to do a utilities library (similar to commons.lang, with
> > StringUtils, ...) for EL, and maybe for JSF if more good candidates emerge.
> >
> > So, I wonder first if you guys feels this is of any use to include this in
> > MyFaces, and if so, how do we handle that ?
> > Those aren't components, but should we do a sandbox for libraries to, or
> > just an additional myfaces-utilities.jar ????
> >
> > Thanks,
> >
> > Sylvain.
> >
> >
> > On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> >
> > 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.
> >
> > Would this satisfy the ASF's requirement for "All New Components Must Go
> > Through the Incubator" ? Hopefully...
Re: Sandbox
Posted by Sean Schofield <se...@gmail.com>.
Sylvain,
Something like this could definitely be useful although I'm not sure
where the proper home should be. I agree the EL is a bit constraining
right now and I have some tricks similar to this myself. BTW, what is
@Override? Never seen that before. I'm assuming its a SE5 feature?
As for the specifics of your idea, we should probably discuss on a
separate thread (and after we have resolved sandbox, etc.) My gut
reaaction is that this would go in the "Tomahawk" (components +
goodies project.)
sean
On 5/11/05, Sylvain Vieujot <sv...@apache.org> wrote:
> I'm fine with that and find it simpler to have it in the trunk.
>
> I have a related question.
>
> Right now, I have done 2 little utilities that help me resolve small
> problems.
> They are 2 abstract implementations of Map : ActionMap and TestMap, and I
> find them handy to use in many common cases.
>
> Here are 2 examples :
> 1) ActionMap : For example, when you have a list of file, and want to have
> a checkbox to delete a file, you just add the following code in your page :
> <h:column>
> <h:selectBooleanCheckbox value="#{pageFace.removeFileName[file.name]}"/>
> <h:outputText value="delete"/>
> </h:column>
>
>
> And in your backing bean : public ActionsMap getRemoveFileName(){
> return new ActionsMap(){
> @Override
> public void performAction(String fileName) {
> getFiles().remove( fileName );
> }
> };
> }
>
>
>
> 2) TestMap : I use it to pass parameters to methods using a map, and
> getting a boolean result.
> For example, if you want to render a component if a user is in 2 roles, the
> visibleOnUserRole isn't enough.
> So, in my backing bean, I have this method :
>
> public TestsMap getUserInRole(){
> return new TestsMap(){
> @Override
> public boolean getTest(String roleName) {
> return getHttpServletRequest().isUserInRole( roleName );
> }
> };
> }
>
> And now, I can do any test I want in EL :
> #{myBean.isUserInRole['Accountant'] && myBean.isUserInRole['CountryUnit']}
>
> It's quite limited now, but due to the limitations of the EL, small
> utilities like that can help.
> My suggestion is to do a utilities library (similar to commons.lang, with
> StringUtils, ...) for EL, and maybe for JSF if more good candidates emerge.
>
> So, I wonder first if you guys feels this is of any use to include this in
> MyFaces, and if so, how do we handle that ?
> Those aren't components, but should we do a sandbox for libraries to, or
> just an additional myfaces-utilities.jar ????
>
> Thanks,
>
> Sylvain.
>
>
> On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
>
> 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.
>
> Would this satisfy the ASF's requirement for "All New Components Must Go
> Through the Incubator" ? Hopefully...
Re: Sandbox
Posted by Sylvain Vieujot <sv...@apache.org>.
I'm fine with that and find it simpler to have it in the trunk.
I have a related question.
Right now, I have done 2 little utilities that help me resolve small
problems.
They are 2 abstract implementations of Map : ActionMap and TestMap, and
I find them handy to use in many common cases.
Here are 2 examples :
1) ActionMap : For example, when you have a list of file, and want to
have a checkbox to delete a file, you just add the following code in
your page :
<h:column>
<h:selectBooleanCheckbox value="#{pageFace.removeFileName[file.name]}"/>
<h:outputText value="delete"/>
</h:column>
And in your backing bean :
public ActionsMap getRemoveFileName(){
return new ActionsMap(){
@Override
public void performAction(String fileName) {
getFiles().remove( fileName );
}
};
}
2) TestMap : I use it to pass parameters to methods using a map, and
getting a boolean result.
For example, if you want to render a component if a user is in 2 roles,
the visibleOnUserRole isn't enough.
So, in my backing bean, I have this method :
public TestsMap getUserInRole(){
return new TestsMap(){
@Override
public boolean getTest(String roleName) {
return getHttpServletRequest().isUserInRole( roleName );
}
};
}
And now, I can do any test I want in EL : #{myBean.isUserInRole
['Accountant'] && myBean.isUserInRole['CountryUnit']}
It's quite limited now, but due to the limitations of the EL, small
utilities like that can help.
My suggestion is to do a utilities library (similar to commons.lang,
with StringUtils, ...) for EL, and maybe for JSF if more good candidates
emerge.
So, I wonder first if you guys feels this is of any use to include this
in MyFaces, and if so, how do we handle that ?
Those aren't components, but should we do a sandbox for libraries to, or
just an additional myfaces-utilities.jar ????
Thanks,
Sylvain.
On Wed, 2005-05-11 at 11:41 -0700, Grant Smith wrote:
> 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.
>
> Would this satisfy the ASF's requirement for "All New Components Must
> Go
> Through the Incubator" ? Hopefully...
Re: Sandbox
Posted by Martin Cooper <ma...@apache.org>.
On Wed, 11 May 2005, Grant Smith wrote:
> I'd like to kick off the whole sandbox debate again. Yes, I'm a sucker for
> punishment..
>
> 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.
This depends on what your expected model is for contributions to the
sandbox and for inclusion of sandbox components in releases. If the set of
committers to the sandbox will be the same as to the rest of the project,
and you expect to include sandbox components in your releases, then this
is probably fine. Otherwise, you might want to give some thought to
keeping the sandbox outside of trunk.
--
Martin Cooper
> 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.
>
> Would this satisfy the ASF's requirement for "All New Components Must Go
> Through the Incubator" ? Hopefully...
>
>
>
Re: Sandbox
Posted by Martin Marinschek <ma...@gmail.com>.
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?
regards,
Martin
On 5/11/05, Grant Smith <gr...@marathon-man.com> 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
>
> .
>
>
>
>
Re: Sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
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
>
>.
>
>
>
Re: Sandbox
Posted by Ted Husted <te...@gmail.com>.
Craig, Martin, and I can and do disagree, but this is not one of those times :)
Craig said *committers* sometimes work on code outside an ASF
repository and then donate it. That's very different from
non-committers working on a signficant codebase elsewhere and then
donating it to the ASF.
If a signficant codebase is developed by non-committers, who do not
have a CLA on file, then the "standard procedure" is to have the
developers file a software grant and pass the codebase through the
Incubator. Derby, for example.
If the code or documentation being developed is not signficant, the
PMC might exercise discretion and bring it directly into the Project.
I'm not going to try and define "signficant". :)
Regardless of whether the code is being donated via the Project or via
the Incubator,
* the developers making the donation should still a CLA or a software grant.
You don't have to be a commtter to file a CLA. If the code or
documentation being donated is not a simple patch to an existing
codebase, then do get a CLA on file before accepting the donation. If
the individual can't file a CLA, then we can't accept the donation. :(
Note that there's a pattern here: We don't require a CLA for simple
patches to existing functionality. We do require a CLA for donations
of new code or documentation. We do not require a trivial donation to
go through the Incubator . We do require a significant donation to go
through the Incubator.
Of course, there are grey areas of where a patch ends and new code
begins, and where trivial ends and significant begins. The PMC will
have to exercise its best judgment. When you do exercise your
judgment, please remember that you are representing the interests of
the ASF -- not just the MyFaces Project. Err on the side of doing
what's best for the Foundation.
:) Welcome to the jungle :)
Whether the PMC brings a donation into the trunk or a "sandbox"
doesn't matter, it's still in the ASF repository. I think part of the
confusion with this thread is that the terms "Incubator" and "sandbox"
and being muddled.
-Ted.
On 5/15/05, Martin Marinschek <ma...@gmail.com> wrote:
> No there we have Ted and Craig saying something differently - now who
> of the two experts is right?
>
> is it possible to develop something on Sourceforge (by non-commiters)
> and have it checked in to the ASF codebase by an ASF committer without
> going through the incubator?
>
> Craig says yes - the committer has to take responsibility for sorting
> out the legal issues and everything
>
> Ted says no - everything has to go through incubator.
>
> May I suggest that it depends on the size and the clarity of the legal
> situation of the contribution with respect to the existing codebase -
> one component of one developer who puts the component into public
> domain might be okay, several would need to go through incubator?
>
> regards,
>
> Martin
Re: Sandbox
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Martin,
I don't have a problem with the incubator - remember that we came in
quite the same way and I think we did quite well. Additionally, we
might have a smaller community than struts, but I think with respect
to the average Apache project, we do have a fairly large community. I
hope that our community doesn't feel insulted by you calling it small
;)
The only question was if we have many components coming in, and that
might happen quite often JSF being a standardized platform, if we have
to setup an incubator project for that everytime.
I asked at the incubator mailing list if we could have our sandbox in
the incubator, and vote out components as appropriate, and I didn't
even suggest to get around incubator at all or doing things "the easy
way".
But people at incubator where telling me that no, incubator itself was
not necessary everytime for code contributions. If IP is sorted out
and the contribution can be maintained by us (and there is a strong
dedication to that) then we would not have to do that.
I really love the principles of the ASF, and I believe the incubator
has great merits for large codebases donated to the ASF, but incubator
is (albeit maybe small) bureaucratic overhead, and if it is not
necessary according to the principles, it shouldn't be happening,
would be saving work both for us and for the incubator people.
regards,
Martin
On 5/15/05, Martin Cooper <ma...@apache.org> wrote:
>
>
> On Sun, 15 May 2005, Martin Marinschek wrote:
>
> > I am attaching an email trace by Noel and Cliff from a question I
> > asked at the incubator mailing list, which basically said that we
> > don't have to do an incubator subproject for anything which we think
> > we can maintain - so Craig seems to be right in this issue if number
> > of opinions count ;)
>
> It's not a question of what you *think* you can maintain. If you bring an
> external code base into the ASF repository, you *must be committed* - as a
> community, not one or two individuals - to maintaining it and resolving
> any technical issues, not to mention resolving any legal issues *before*
> it touches the ASF repository. If there is even a hint that this is not
> the case, you should go through the incubator.
>
> Please don't think of this as "can we avoid doing things the right way and
> just stick it in our repo?". Intended or not, that is how this thread is
> coming across, at least to me. The incubator is there for good reasons,
> and, as Ted has pointed out several times, it need not be a heavyweight
> process. If something is brought into the incubator, and it's in good
> shape with a community forming around it quickly, then there is no reason
> for it to remain there for a protracted period before moving out and
> becoming part of an existing project.
>
> One other thought I'd like to throw out here: As it is today, the MyFaces
> community is faurly small, and relatively inexperienced in the "ways of
> Apache", albeit with a few mentors keeping tabs on it. Given that, I would
> suggest focussing on what's here now, and grokking the ways of the ASF,
> before rushing into how to accummulate more code from other places.
>
> --
> Martin Cooper
>
>
> > regards,
> >
> > Martin
> >
> >
> > On 5/14/05, Noel J. Bergman <no...@devtech.com> wrote:
> >> Cliff Schmidt wrote:
> >>
> >>> you'd only need an incubator subproject if the code could not be
> >>> supported by the current MyFaces community. However, if the
> >>> MyFaces PMC feels that the community already exists to maintain
> >>> the new code contribution, then there's no need for an incubator
> >>> subproject.
> >>
> >> But the IP must still be vetted and recorded (q.v.,
> >> https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects
> >> /ip-clearance-template.html).
> >>
> >> --- Noel
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
> > On 5/15/05, Martin Marinschek <ma...@gmail.com> wrote:
> >> No there we have Ted and Craig saying something differently - now who
> >> of the two experts is right?
> >>
> >> is it possible to develop something on Sourceforge (by non-commiters)
> >> and have it checked in to the ASF codebase by an ASF committer without
> >> going through the incubator?
> >>
> >> Craig says yes - the committer has to take responsibility for sorting
> >> out the legal issues and everything
> >>
> >> Ted says no - everything has to go through incubator.
> >>
> >> May I suggest that it depends on the size and the clarity of the legal
> >> situation of the contribution with respect to the existing codebase -
> >> one component of one developer who puts the component into public
> >> domain might be okay, several would need to go through incubator?
> >>
> >> regards,
> >>
> >> Martin
> >>
> >> On 5/15/05, Ted Husted <te...@gmail.com> wrote:
> >>> On 5/11/05, Sean Schofield <se...@gmail.com> wrote:
> >>>>> 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.
> >>>
> >>> It's more like all external "codebases" donated to the Foundation
> >>> *must* go through the Incubator.
> >>>
> >>> The two concerns are IP and Community. First, the ASF wants to be
> >>> positive that we do in fact own every line of code in our
> >>> repositories. Of course, under the Apache License, we don't mean "own"
> >>> in the exclusive sense. But "own" in the sense that we can put it
> >>> under the Apache License, and no one else has a legal right to
> >>> complain.
> >>>
> >>> If an external codebase could enter the ASF through any of our dozens
> >>> of projects, it would be too easy for a project to slip and allow in a
> >>> codebase with IP issues. So, when IBM donates Derby, it doesn't go
> >>> straight to db.apache.org, it goes to the Incubator first, where
> >>> another set of eyes can look it over.
> >>>
> >>> Now if the codebase is developed here in our repository, regardless of
> >>> its size, then we own it and we can put it under the Apache License.
> >>> It's only external codebases developed by non-committers that concern
> >>> Incubator.
> >>>
> >>> Of course, the ASF doesn't want code as much as we want community
> >>> (people who create, maintain, and support code). Before any large
> >>> donation is accepted, we need to know that there are *several* members
> >>> of our community who will support the code over the long term.
> >>>
> >>> Essentially, the Incubator is a front controller for new projects and
> >>> external code donations.
> >>>
> >>> A lot of projects maintain sandboxes to ensure that there is a
> >>> community support behind a codebase before making it part of the
> >>> trunk. Once it is part of the trunk, there is an expectation that
> >>> *all* of the committers are ready, willing, and able to support the
> >>> code over the long term.
> >>>
> >>> Another word for sandbox is "whiteboard directory", as mention in the
> >>> Rules for Revolutionaries.
> >>>
> >>> * http://incubator.apache.org/learn/rules-for-revolutionaries.html
> >>>
> >>> If you have a sandbox, or whiteboard, then it should be very, very
> >>> clear to anyone using the component that this code is not part of the
> >>> main distribution, *and* that it subject to change or removal without
> >>> notice. If its too easy to use the sandbox code, then people might not
> >>> realize that it's not part of the standard distribution.
> >>>
> >>> Of course, under SVN, it is quite easy to merge and move components
> >>> later, no matter where you hide them now :)
> >>>
> >>> Often, people will develop novel or "revolutionary" code in the
> >>> sandbox, then propose that it be promoted when the code is ready for
> >>> primetime. (Where primetime means the code is stable and there are
> >>> several people interested in using and supporting the code.)
> >>>
> >>> But, "evolutionary" code can be developed as part of the trunk, if
> >>> everyone agrees its something that needs to be part of the next
> >>> release. Generally, a sandbox is for questionable components that may
> >>> or may not be made part of the standard release.
> >>>
> >>> This is important, because Apache Projects are expected to fully
> >>> support whatever goes into a standard release. If it goes into the
> >>> standard release, it should be bug-free in every subsequent release,
> >>> and if it we decide to remove it, we should go through a
> >>> deprecate-replace-remove cycle over two or more stable releases.
> >>>
> >>> Putting code in a standard release means we are committed to the code.
> >>> Putting code in a sandbox is "throwing stuff on the wall and seeing
> >>> if it sticks" :)
> >>>
> >>> Whether a component *needs* to go through a sandbox would depend on
> >>> whether it *needs* to be part of the next standard release. If it's in
> >>> the trunk, and it's not done yet, then it becomes a blocker until it's
> >>> done (or moved out of the trunk).
> >>>
> >>>
> >>> On 5/11/05, Martin Marinschek <ma...@gmail.com> wrote:
> >>>> What about the sourceforge project that has already been set up?
> >>>
> >>> As mentioned, some people on the Struts team setup a SourceForge site
> >>> to make it easier for non-committers to share code with the Struts
> >>> community. But it is not used as an actual sandbox. (Struts already
> >>> has one of those.) It's just a place where people can share Struts
> >>> extensions and sample applications outside of the standard release.
> >>>
> >>> Of course, if a non-committer wants to develop something and then
> >>> propose it to the Apache Struts Project, a good approach would be to
> >>> develop it on the SourceForge site. But, it would still have to go
> >>> through the incubator and all that.
> >>>
> >>> When a Struts committer want to develop something that might become
> >>> part of the Struts release or a new Struts subproject, we start it in
> >>> the ASF repository, not the SourceForge site.
> >>>
> >>> The cool thing about a sandbox, as used by Struts and Jakarta Commons,
> >>> is that you don't need group approval. You can start it up, and see
> >>> how it goes, without having to convince anyone first. It gives you a
> >>> chance to do the code, and then let the code do the talking.
> >>>
> >>> HTH, Ted.
> >>>
> >>
> >
>
Re: Sandbox
Posted by Sean Schofield <se...@gmail.com>.
OK there are enough +1 here so I don't think we need any more votes.
I just wanted to get a sense before I proposed a formal vote with a
specific SVN layout in mind. I will call an official vote once I
think through the SVN stuff.
sean
On 5/19/05, Manfred Geiler <ma...@gmail.com> wrote:
> +1
>
> -Manfred
>
> 2005/5/19, Sean Schofield <se...@gmail.com>:
> > I propose that we go ahead and create a sandbox area and at a minimum
> > it can be used by committers (such as myself) who have existing code
> > they want to get feedback on. Those that want to contribute a
> > component and work within the confines of the sandbox rules (a myfaces
> > committer has to commit your code and patches) can also volunteer
> > components.
> >
> > Can we agree on this principle? I will come up with a proposal for a
> > specific SVN structure this weekend but for now we need agreement on
> > the concept.
> >
> > sean
> >
> >
> > On 5/15/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > Yes, I think that should finally be sorted out ;)
> > >
> > > And we will try to err to the best of the ASF, promised.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 5/16/05, Ted Husted <te...@gmail.com> wrote:
> > > > On 5/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > It's not a question of what you *think* you can maintain. If you bring an
> > > > > > external code base into the ASF repository, you *must be committed* - as a
> > > > > > community, not one or two individuals - to maintaining it and resolving
> > > > > > any technical issues, not to mention resolving any legal issues *before*
> > > > > > it touches the ASF repository. If there is even a hint that this is not
> > > > > > the case, you should go through the incubator.
> > > > >
> > > > > In the case of Jesse's SF code it doesn't sound like incubator is
> > > > > required. This is based on Craig's detailed explanation as well as
> > > > > common sense. According to Craig it is fine for a few individuals to
> > > > > work off list on things and then offer them to the community for
> > > > > inclusion. Its up to the PMC to decide whether or not that code
> > > > > should then go in the sandbox or could be added directly to the source
> > > > > code proper.
> > > >
> > > > According to Craig, it is fine for *committers* to work of list and then ...
> > > >
> > > > I haven't reviewed Jesse's SF code. But if it's on the scale of custom
> > > > JSP tag, then you might have Jesse file a CLA and accept the donation
> > > > directly to the MyFaces project. If the contribution is more than a
> > > > tag library, with several interacting tags, then it might be
> > > > significant enough to pass through the Incubator.
> > > >
> > > > Whether you put the component into the trunk, or into a sandbox, is a
> > > > separate issue than whether the project or the incubator accepts the
> > > > donation.
> > > >
> > > > Some projects use a sandbox to develop new code and then decide
> > > > whether to make it part of the standard distribution (merge it with
> > > > the trunk).
> > > >
> > > > The Incubator Project is the Foundation's "front controller" for
> > > > significant, or extra-ordinary, code donations.
> > > >
> > > > HTH (really I do!), Ted :)
> > > >
> > >
> >
>
Re: Sandbox
Posted by Manfred Geiler <ma...@gmail.com>.
+1
-Manfred
2005/5/19, Sean Schofield <se...@gmail.com>:
> I propose that we go ahead and create a sandbox area and at a minimum
> it can be used by committers (such as myself) who have existing code
> they want to get feedback on. Those that want to contribute a
> component and work within the confines of the sandbox rules (a myfaces
> committer has to commit your code and patches) can also volunteer
> components.
>
> Can we agree on this principle? I will come up with a proposal for a
> specific SVN structure this weekend but for now we need agreement on
> the concept.
>
> sean
>
>
> On 5/15/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Yes, I think that should finally be sorted out ;)
> >
> > And we will try to err to the best of the ASF, promised.
> >
> > regards,
> >
> > Martin
> >
> > On 5/16/05, Ted Husted <te...@gmail.com> wrote:
> > > On 5/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > It's not a question of what you *think* you can maintain. If you bring an
> > > > > external code base into the ASF repository, you *must be committed* - as a
> > > > > community, not one or two individuals - to maintaining it and resolving
> > > > > any technical issues, not to mention resolving any legal issues *before*
> > > > > it touches the ASF repository. If there is even a hint that this is not
> > > > > the case, you should go through the incubator.
> > > >
> > > > In the case of Jesse's SF code it doesn't sound like incubator is
> > > > required. This is based on Craig's detailed explanation as well as
> > > > common sense. According to Craig it is fine for a few individuals to
> > > > work off list on things and then offer them to the community for
> > > > inclusion. Its up to the PMC to decide whether or not that code
> > > > should then go in the sandbox or could be added directly to the source
> > > > code proper.
> > >
> > > According to Craig, it is fine for *committers* to work of list and then ...
> > >
> > > I haven't reviewed Jesse's SF code. But if it's on the scale of custom
> > > JSP tag, then you might have Jesse file a CLA and accept the donation
> > > directly to the MyFaces project. If the contribution is more than a
> > > tag library, with several interacting tags, then it might be
> > > significant enough to pass through the Incubator.
> > >
> > > Whether you put the component into the trunk, or into a sandbox, is a
> > > separate issue than whether the project or the incubator accepts the
> > > donation.
> > >
> > > Some projects use a sandbox to develop new code and then decide
> > > whether to make it part of the standard distribution (merge it with
> > > the trunk).
> > >
> > > The Incubator Project is the Foundation's "front controller" for
> > > significant, or extra-ordinary, code donations.
> > >
> > > HTH (really I do!), Ted :)
> > >
> >
>
Re: Sandbox
Posted by Grant Smith <gr...@marathon-man.com>.
+1 ... although the list is so slow at the moment, you might only get
the vote next year... grr. :-(
Sean Schofield wrote:
>I propose that we go ahead and create a sandbox area and at a minimum
>it can be used by committers (such as myself) who have existing code
>they want to get feedback on. Those that want to contribute a
>component and work within the confines of the sandbox rules (a myfaces
>committer has to commit your code and patches) can also volunteer
>components.
>
>Can we agree on this principle? I will come up with a proposal for a
>specific SVN structure this weekend but for now we need agreement on
>the concept.
>
>sean
>
>
>On 5/15/05, Martin Marinschek <ma...@gmail.com> wrote:
>
>
>>Yes, I think that should finally be sorted out ;)
>>
>>And we will try to err to the best of the ASF, promised.
>>
>>regards,
>>
>>Martin
>>
>>On 5/16/05, Ted Husted <te...@gmail.com> wrote:
>>
>>
>>>On 5/15/05, Sean Schofield <se...@gmail.com> wrote:
>>>
>>>
>>>>>It's not a question of what you *think* you can maintain. If you bring an
>>>>>external code base into the ASF repository, you *must be committed* - as a
>>>>>community, not one or two individuals - to maintaining it and resolving
>>>>>any technical issues, not to mention resolving any legal issues *before*
>>>>>it touches the ASF repository. If there is even a hint that this is not
>>>>>the case, you should go through the incubator.
>>>>>
>>>>>
>>>>In the case of Jesse's SF code it doesn't sound like incubator is
>>>>required. This is based on Craig's detailed explanation as well as
>>>>common sense. According to Craig it is fine for a few individuals to
>>>>work off list on things and then offer them to the community for
>>>>inclusion. Its up to the PMC to decide whether or not that code
>>>>should then go in the sandbox or could be added directly to the source
>>>>code proper.
>>>>
>>>>
>>>According to Craig, it is fine for *committers* to work of list and then ...
>>>
>>>I haven't reviewed Jesse's SF code. But if it's on the scale of custom
>>>JSP tag, then you might have Jesse file a CLA and accept the donation
>>>directly to the MyFaces project. If the contribution is more than a
>>>tag library, with several interacting tags, then it might be
>>>significant enough to pass through the Incubator.
>>>
>>>Whether you put the component into the trunk, or into a sandbox, is a
>>>separate issue than whether the project or the incubator accepts the
>>>donation.
>>>
>>>Some projects use a sandbox to develop new code and then decide
>>>whether to make it part of the standard distribution (merge it with
>>>the trunk).
>>>
>>>The Incubator Project is the Foundation's "front controller" for
>>>significant, or extra-ordinary, code donations.
>>>
>>>HTH (really I do!), Ted :)
>>>
>>>
>>>
>
>.
>
>
>
Re: Sandbox
Posted by Sean Schofield <se...@gmail.com>.
I propose that we go ahead and create a sandbox area and at a minimum
it can be used by committers (such as myself) who have existing code
they want to get feedback on. Those that want to contribute a
component and work within the confines of the sandbox rules (a myfaces
committer has to commit your code and patches) can also volunteer
components.
Can we agree on this principle? I will come up with a proposal for a
specific SVN structure this weekend but for now we need agreement on
the concept.
sean
On 5/15/05, Martin Marinschek <ma...@gmail.com> wrote:
> Yes, I think that should finally be sorted out ;)
>
> And we will try to err to the best of the ASF, promised.
>
> regards,
>
> Martin
>
> On 5/16/05, Ted Husted <te...@gmail.com> wrote:
> > On 5/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > It's not a question of what you *think* you can maintain. If you bring an
> > > > external code base into the ASF repository, you *must be committed* - as a
> > > > community, not one or two individuals - to maintaining it and resolving
> > > > any technical issues, not to mention resolving any legal issues *before*
> > > > it touches the ASF repository. If there is even a hint that this is not
> > > > the case, you should go through the incubator.
> > >
> > > In the case of Jesse's SF code it doesn't sound like incubator is
> > > required. This is based on Craig's detailed explanation as well as
> > > common sense. According to Craig it is fine for a few individuals to
> > > work off list on things and then offer them to the community for
> > > inclusion. Its up to the PMC to decide whether or not that code
> > > should then go in the sandbox or could be added directly to the source
> > > code proper.
> >
> > According to Craig, it is fine for *committers* to work of list and then ...
> >
> > I haven't reviewed Jesse's SF code. But if it's on the scale of custom
> > JSP tag, then you might have Jesse file a CLA and accept the donation
> > directly to the MyFaces project. If the contribution is more than a
> > tag library, with several interacting tags, then it might be
> > significant enough to pass through the Incubator.
> >
> > Whether you put the component into the trunk, or into a sandbox, is a
> > separate issue than whether the project or the incubator accepts the
> > donation.
> >
> > Some projects use a sandbox to develop new code and then decide
> > whether to make it part of the standard distribution (merge it with
> > the trunk).
> >
> > The Incubator Project is the Foundation's "front controller" for
> > significant, or extra-ordinary, code donations.
> >
> > HTH (really I do!), Ted :)
> >
>
Re: Sandbox
Posted by Martin Marinschek <ma...@gmail.com>.
Yes, I think that should finally be sorted out ;)
And we will try to err to the best of the ASF, promised.
regards,
Martin
On 5/16/05, Ted Husted <te...@gmail.com> wrote:
> On 5/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > It's not a question of what you *think* you can maintain. If you bring an
> > > external code base into the ASF repository, you *must be committed* - as a
> > > community, not one or two individuals - to maintaining it and resolving
> > > any technical issues, not to mention resolving any legal issues *before*
> > > it touches the ASF repository. If there is even a hint that this is not
> > > the case, you should go through the incubator.
> >
> > In the case of Jesse's SF code it doesn't sound like incubator is
> > required. This is based on Craig's detailed explanation as well as
> > common sense. According to Craig it is fine for a few individuals to
> > work off list on things and then offer them to the community for
> > inclusion. Its up to the PMC to decide whether or not that code
> > should then go in the sandbox or could be added directly to the source
> > code proper.
>
> According to Craig, it is fine for *committers* to work of list and then ...
>
> I haven't reviewed Jesse's SF code. But if it's on the scale of custom
> JSP tag, then you might have Jesse file a CLA and accept the donation
> directly to the MyFaces project. If the contribution is more than a
> tag library, with several interacting tags, then it might be
> significant enough to pass through the Incubator.
>
> Whether you put the component into the trunk, or into a sandbox, is a
> separate issue than whether the project or the incubator accepts the
> donation.
>
> Some projects use a sandbox to develop new code and then decide
> whether to make it part of the standard distribution (merge it with
> the trunk).
>
> The Incubator Project is the Foundation's "front controller" for
> significant, or extra-ordinary, code donations.
>
> HTH (really I do!), Ted :)
>
Re: Sandbox
Posted by Ted Husted <te...@gmail.com>.
On 5/15/05, Sean Schofield <se...@gmail.com> wrote:
> > It's not a question of what you *think* you can maintain. If you bring an
> > external code base into the ASF repository, you *must be committed* - as a
> > community, not one or two individuals - to maintaining it and resolving
> > any technical issues, not to mention resolving any legal issues *before*
> > it touches the ASF repository. If there is even a hint that this is not
> > the case, you should go through the incubator.
>
> In the case of Jesse's SF code it doesn't sound like incubator is
> required. This is based on Craig's detailed explanation as well as
> common sense. According to Craig it is fine for a few individuals to
> work off list on things and then offer them to the community for
> inclusion. Its up to the PMC to decide whether or not that code
> should then go in the sandbox or could be added directly to the source
> code proper.
According to Craig, it is fine for *committers* to work of list and then ...
I haven't reviewed Jesse's SF code. But if it's on the scale of custom
JSP tag, then you might have Jesse file a CLA and accept the donation
directly to the MyFaces project. If the contribution is more than a
tag library, with several interacting tags, then it might be
significant enough to pass through the Incubator.
Whether you put the component into the trunk, or into a sandbox, is a
separate issue than whether the project or the incubator accepts the
donation.
Some projects use a sandbox to develop new code and then decide
whether to make it part of the standard distribution (merge it with
the trunk).
The Incubator Project is the Foundation's "front controller" for
significant, or extra-ordinary, code donations.
HTH (really I do!), Ted :)
Re: Sandbox
Posted by Sean Schofield <se...@gmail.com>.
> It's not a question of what you *think* you can maintain. If you bring an
> external code base into the ASF repository, you *must be committed* - as a
> community, not one or two individuals - to maintaining it and resolving
> any technical issues, not to mention resolving any legal issues *before*
> it touches the ASF repository. If there is even a hint that this is not
> the case, you should go through the incubator.
In the case of Jesse's SF code it doesn't sound like incubator is
required. This is based on Craig's detailed explanation as well as
common sense. According to Craig it is fine for a few individuals to
work off list on things and then offer them to the community for
inclusion. Its up to the PMC to decide whether or not that code
should then go in the sandbox or could be added directly to the source
code proper.
Also according to Craig, it sounds like its equally fine to develop
the code inside a sandbox and have those doing the contributions rely
on existing committers to contribute patches, etc. This is my strong
preference. Its a bit of a hassle but it will be easier for the
entire community to participate if the components are in one central
location. When a component looks to be ready we just vote it out of
the sandbox. There can be a clear line of delineation between what is
officially sanctioned MyFaces code and what is still "experimental."
> Please don't think of this as "can we avoid doing things the right way and
> just stick it in our repo?". Intended or not, that is how this thread is
> coming across, at least to me. The incubator is there for good reasons,
> and, as Ted has pointed out several times, it need not be a heavyweight
> process. If something is brought into the incubator, and it's in good
> shape with a community forming around it quickly, then there is no reason
> for it to remain there for a protracted period before moving out and
> becoming part of an existing project.
>
> One other thought I'd like to throw out here: As it is today, the MyFaces
> community is faurly small, and relatively inexperienced in the "ways of
> Apache", albeit with a few mentors keeping tabs on it. Given that, I would
> suggest focussing on what's here now, and grokking the ways of the ASF,
> before rushing into how to accummulate more code from other places.
I agree that we are relatively new to the ways of Apache (at least
from a rules and regulations standpoint.) I don't think we are really
focused on accumulating code from other places. I think those of us
proposing a sandbox are doing so as a way to study code that come from
*within* the community but that still needs to be vetted before formal
inclusion. To me that seems entirely appropriate (and a good way of
encouraging potential new committers to contribute.)
> Martin Cooper
sean
Re: Sandbox
Posted by Martin Cooper <ma...@apache.org>.
On Sun, 15 May 2005, Martin Marinschek wrote:
> I am attaching an email trace by Noel and Cliff from a question I
> asked at the incubator mailing list, which basically said that we
> don't have to do an incubator subproject for anything which we think
> we can maintain - so Craig seems to be right in this issue if number
> of opinions count ;)
It's not a question of what you *think* you can maintain. If you bring an
external code base into the ASF repository, you *must be committed* - as a
community, not one or two individuals - to maintaining it and resolving
any technical issues, not to mention resolving any legal issues *before*
it touches the ASF repository. If there is even a hint that this is not
the case, you should go through the incubator.
Please don't think of this as "can we avoid doing things the right way and
just stick it in our repo?". Intended or not, that is how this thread is
coming across, at least to me. The incubator is there for good reasons,
and, as Ted has pointed out several times, it need not be a heavyweight
process. If something is brought into the incubator, and it's in good
shape with a community forming around it quickly, then there is no reason
for it to remain there for a protracted period before moving out and
becoming part of an existing project.
One other thought I'd like to throw out here: As it is today, the MyFaces
community is faurly small, and relatively inexperienced in the "ways of
Apache", albeit with a few mentors keeping tabs on it. Given that, I would
suggest focussing on what's here now, and grokking the ways of the ASF,
before rushing into how to accummulate more code from other places.
--
Martin Cooper
> regards,
>
> Martin
>
>
> On 5/14/05, Noel J. Bergman <no...@devtech.com> wrote:
>> Cliff Schmidt wrote:
>>
>>> you'd only need an incubator subproject if the code could not be
>>> supported by the current MyFaces community. However, if the
>>> MyFaces PMC feels that the community already exists to maintain
>>> the new code contribution, then there's no need for an incubator
>>> subproject.
>>
>> But the IP must still be vetted and recorded (q.v.,
>> https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects
>> /ip-clearance-template.html).
>>
>> --- Noel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> On 5/15/05, Martin Marinschek <ma...@gmail.com> wrote:
>> No there we have Ted and Craig saying something differently - now who
>> of the two experts is right?
>>
>> is it possible to develop something on Sourceforge (by non-commiters)
>> and have it checked in to the ASF codebase by an ASF committer without
>> going through the incubator?
>>
>> Craig says yes - the committer has to take responsibility for sorting
>> out the legal issues and everything
>>
>> Ted says no - everything has to go through incubator.
>>
>> May I suggest that it depends on the size and the clarity of the legal
>> situation of the contribution with respect to the existing codebase -
>> one component of one developer who puts the component into public
>> domain might be okay, several would need to go through incubator?
>>
>> regards,
>>
>> Martin
>>
>> On 5/15/05, Ted Husted <te...@gmail.com> wrote:
>>> On 5/11/05, Sean Schofield <se...@gmail.com> wrote:
>>>>> 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.
>>>
>>> It's more like all external "codebases" donated to the Foundation
>>> *must* go through the Incubator.
>>>
>>> The two concerns are IP and Community. First, the ASF wants to be
>>> positive that we do in fact own every line of code in our
>>> repositories. Of course, under the Apache License, we don't mean "own"
>>> in the exclusive sense. But "own" in the sense that we can put it
>>> under the Apache License, and no one else has a legal right to
>>> complain.
>>>
>>> If an external codebase could enter the ASF through any of our dozens
>>> of projects, it would be too easy for a project to slip and allow in a
>>> codebase with IP issues. So, when IBM donates Derby, it doesn't go
>>> straight to db.apache.org, it goes to the Incubator first, where
>>> another set of eyes can look it over.
>>>
>>> Now if the codebase is developed here in our repository, regardless of
>>> its size, then we own it and we can put it under the Apache License.
>>> It's only external codebases developed by non-committers that concern
>>> Incubator.
>>>
>>> Of course, the ASF doesn't want code as much as we want community
>>> (people who create, maintain, and support code). Before any large
>>> donation is accepted, we need to know that there are *several* members
>>> of our community who will support the code over the long term.
>>>
>>> Essentially, the Incubator is a front controller for new projects and
>>> external code donations.
>>>
>>> A lot of projects maintain sandboxes to ensure that there is a
>>> community support behind a codebase before making it part of the
>>> trunk. Once it is part of the trunk, there is an expectation that
>>> *all* of the committers are ready, willing, and able to support the
>>> code over the long term.
>>>
>>> Another word for sandbox is "whiteboard directory", as mention in the
>>> Rules for Revolutionaries.
>>>
>>> * http://incubator.apache.org/learn/rules-for-revolutionaries.html
>>>
>>> If you have a sandbox, or whiteboard, then it should be very, very
>>> clear to anyone using the component that this code is not part of the
>>> main distribution, *and* that it subject to change or removal without
>>> notice. If its too easy to use the sandbox code, then people might not
>>> realize that it's not part of the standard distribution.
>>>
>>> Of course, under SVN, it is quite easy to merge and move components
>>> later, no matter where you hide them now :)
>>>
>>> Often, people will develop novel or "revolutionary" code in the
>>> sandbox, then propose that it be promoted when the code is ready for
>>> primetime. (Where primetime means the code is stable and there are
>>> several people interested in using and supporting the code.)
>>>
>>> But, "evolutionary" code can be developed as part of the trunk, if
>>> everyone agrees its something that needs to be part of the next
>>> release. Generally, a sandbox is for questionable components that may
>>> or may not be made part of the standard release.
>>>
>>> This is important, because Apache Projects are expected to fully
>>> support whatever goes into a standard release. If it goes into the
>>> standard release, it should be bug-free in every subsequent release,
>>> and if it we decide to remove it, we should go through a
>>> deprecate-replace-remove cycle over two or more stable releases.
>>>
>>> Putting code in a standard release means we are committed to the code.
>>> Putting code in a sandbox is "throwing stuff on the wall and seeing
>>> if it sticks" :)
>>>
>>> Whether a component *needs* to go through a sandbox would depend on
>>> whether it *needs* to be part of the next standard release. If it's in
>>> the trunk, and it's not done yet, then it becomes a blocker until it's
>>> done (or moved out of the trunk).
>>>
>>>
>>> On 5/11/05, Martin Marinschek <ma...@gmail.com> wrote:
>>>> What about the sourceforge project that has already been set up?
>>>
>>> As mentioned, some people on the Struts team setup a SourceForge site
>>> to make it easier for non-committers to share code with the Struts
>>> community. But it is not used as an actual sandbox. (Struts already
>>> has one of those.) It's just a place where people can share Struts
>>> extensions and sample applications outside of the standard release.
>>>
>>> Of course, if a non-committer wants to develop something and then
>>> propose it to the Apache Struts Project, a good approach would be to
>>> develop it on the SourceForge site. But, it would still have to go
>>> through the incubator and all that.
>>>
>>> When a Struts committer want to develop something that might become
>>> part of the Struts release or a new Struts subproject, we start it in
>>> the ASF repository, not the SourceForge site.
>>>
>>> The cool thing about a sandbox, as used by Struts and Jakarta Commons,
>>> is that you don't need group approval. You can start it up, and see
>>> how it goes, without having to convince anyone first. It gives you a
>>> chance to do the code, and then let the code do the talking.
>>>
>>> HTH, Ted.
>>>
>>
>
Re: Sandbox
Posted by Martin Marinschek <ma...@gmail.com>.
I am attaching an email trace by Noel and Cliff from a question I
asked at the incubator mailing list, which basically said that we
don't have to do an incubator subproject for anything which we think
we can maintain - so Craig seems to be right in this issue if number
of opinions count ;)
regards,
Martin
On 5/14/05, Noel J. Bergman <no...@devtech.com> wrote:
> Cliff Schmidt wrote:
>
> > you'd only need an incubator subproject if the code could not be
> > supported by the current MyFaces community. However, if the
> > MyFaces PMC feels that the community already exists to maintain
> > the new code contribution, then there's no need for an incubator
> > subproject.
>
> But the IP must still be vetted and recorded (q.v.,
> https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects
> /ip-clearance-template.html).
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
On 5/15/05, Martin Marinschek <ma...@gmail.com> wrote:
> No there we have Ted and Craig saying something differently - now who
> of the two experts is right?
>
> is it possible to develop something on Sourceforge (by non-commiters)
> and have it checked in to the ASF codebase by an ASF committer without
> going through the incubator?
>
> Craig says yes - the committer has to take responsibility for sorting
> out the legal issues and everything
>
> Ted says no - everything has to go through incubator.
>
> May I suggest that it depends on the size and the clarity of the legal
> situation of the contribution with respect to the existing codebase -
> one component of one developer who puts the component into public
> domain might be okay, several would need to go through incubator?
>
> regards,
>
> Martin
>
> On 5/15/05, Ted Husted <te...@gmail.com> wrote:
> > On 5/11/05, Sean Schofield <se...@gmail.com> wrote:
> > > > 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.
> >
> > It's more like all external "codebases" donated to the Foundation
> > *must* go through the Incubator.
> >
> > The two concerns are IP and Community. First, the ASF wants to be
> > positive that we do in fact own every line of code in our
> > repositories. Of course, under the Apache License, we don't mean "own"
> > in the exclusive sense. But "own" in the sense that we can put it
> > under the Apache License, and no one else has a legal right to
> > complain.
> >
> > If an external codebase could enter the ASF through any of our dozens
> > of projects, it would be too easy for a project to slip and allow in a
> > codebase with IP issues. So, when IBM donates Derby, it doesn't go
> > straight to db.apache.org, it goes to the Incubator first, where
> > another set of eyes can look it over.
> >
> > Now if the codebase is developed here in our repository, regardless of
> > its size, then we own it and we can put it under the Apache License.
> > It's only external codebases developed by non-committers that concern
> > Incubator.
> >
> > Of course, the ASF doesn't want code as much as we want community
> > (people who create, maintain, and support code). Before any large
> > donation is accepted, we need to know that there are *several* members
> > of our community who will support the code over the long term.
> >
> > Essentially, the Incubator is a front controller for new projects and
> > external code donations.
> >
> > A lot of projects maintain sandboxes to ensure that there is a
> > community support behind a codebase before making it part of the
> > trunk. Once it is part of the trunk, there is an expectation that
> > *all* of the committers are ready, willing, and able to support the
> > code over the long term.
> >
> > Another word for sandbox is "whiteboard directory", as mention in the
> > Rules for Revolutionaries.
> >
> > * http://incubator.apache.org/learn/rules-for-revolutionaries.html
> >
> > If you have a sandbox, or whiteboard, then it should be very, very
> > clear to anyone using the component that this code is not part of the
> > main distribution, *and* that it subject to change or removal without
> > notice. If its too easy to use the sandbox code, then people might not
> > realize that it's not part of the standard distribution.
> >
> > Of course, under SVN, it is quite easy to merge and move components
> > later, no matter where you hide them now :)
> >
> > Often, people will develop novel or "revolutionary" code in the
> > sandbox, then propose that it be promoted when the code is ready for
> > primetime. (Where primetime means the code is stable and there are
> > several people interested in using and supporting the code.)
> >
> > But, "evolutionary" code can be developed as part of the trunk, if
> > everyone agrees its something that needs to be part of the next
> > release. Generally, a sandbox is for questionable components that may
> > or may not be made part of the standard release.
> >
> > This is important, because Apache Projects are expected to fully
> > support whatever goes into a standard release. If it goes into the
> > standard release, it should be bug-free in every subsequent release,
> > and if it we decide to remove it, we should go through a
> > deprecate-replace-remove cycle over two or more stable releases.
> >
> > Putting code in a standard release means we are committed to the code.
> > Putting code in a sandbox is "throwing stuff on the wall and seeing
> > if it sticks" :)
> >
> > Whether a component *needs* to go through a sandbox would depend on
> > whether it *needs* to be part of the next standard release. If it's in
> > the trunk, and it's not done yet, then it becomes a blocker until it's
> > done (or moved out of the trunk).
> >
> >
> > On 5/11/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > What about the sourceforge project that has already been set up?
> >
> > As mentioned, some people on the Struts team setup a SourceForge site
> > to make it easier for non-committers to share code with the Struts
> > community. But it is not used as an actual sandbox. (Struts already
> > has one of those.) It's just a place where people can share Struts
> > extensions and sample applications outside of the standard release.
> >
> > Of course, if a non-committer wants to develop something and then
> > propose it to the Apache Struts Project, a good approach would be to
> > develop it on the SourceForge site. But, it would still have to go
> > through the incubator and all that.
> >
> > When a Struts committer want to develop something that might become
> > part of the Struts release or a new Struts subproject, we start it in
> > the ASF repository, not the SourceForge site.
> >
> > The cool thing about a sandbox, as used by Struts and Jakarta Commons,
> > is that you don't need group approval. You can start it up, and see
> > how it goes, without having to convince anyone first. It gives you a
> > chance to do the code, and then let the code do the talking.
> >
> > HTH, Ted.
> >
>
Re: Sandbox
Posted by Sean Schofield <se...@gmail.com>.
> May I suggest that it depends on the size and the clarity of the legal
> situation of the contribution with respect to the existing codebase -
> one component of one developer who puts the component into public
> domain might be okay, several would need to go through incubator?
I agree with Martin's take on this. For a single component (or a
small number of components) it doesn't seem necessary for the code to
be added to the incubator first. The incubator does seem appropriate
for large scale projects (such as MyFaces when it was in SF) that are
moving to ASF.
> Martin
sean
Re: Sandbox
Posted by Martin Marinschek <ma...@gmail.com>.
No there we have Ted and Craig saying something differently - now who
of the two experts is right?
is it possible to develop something on Sourceforge (by non-commiters)
and have it checked in to the ASF codebase by an ASF committer without
going through the incubator?
Craig says yes - the committer has to take responsibility for sorting
out the legal issues and everything
Ted says no - everything has to go through incubator.
May I suggest that it depends on the size and the clarity of the legal
situation of the contribution with respect to the existing codebase -
one component of one developer who puts the component into public
domain might be okay, several would need to go through incubator?
regards,
Martin
On 5/15/05, Ted Husted <te...@gmail.com> wrote:
> On 5/11/05, Sean Schofield <se...@gmail.com> wrote:
> > > 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.
>
> It's more like all external "codebases" donated to the Foundation
> *must* go through the Incubator.
>
> The two concerns are IP and Community. First, the ASF wants to be
> positive that we do in fact own every line of code in our
> repositories. Of course, under the Apache License, we don't mean "own"
> in the exclusive sense. But "own" in the sense that we can put it
> under the Apache License, and no one else has a legal right to
> complain.
>
> If an external codebase could enter the ASF through any of our dozens
> of projects, it would be too easy for a project to slip and allow in a
> codebase with IP issues. So, when IBM donates Derby, it doesn't go
> straight to db.apache.org, it goes to the Incubator first, where
> another set of eyes can look it over.
>
> Now if the codebase is developed here in our repository, regardless of
> its size, then we own it and we can put it under the Apache License.
> It's only external codebases developed by non-committers that concern
> Incubator.
>
> Of course, the ASF doesn't want code as much as we want community
> (people who create, maintain, and support code). Before any large
> donation is accepted, we need to know that there are *several* members
> of our community who will support the code over the long term.
>
> Essentially, the Incubator is a front controller for new projects and
> external code donations.
>
> A lot of projects maintain sandboxes to ensure that there is a
> community support behind a codebase before making it part of the
> trunk. Once it is part of the trunk, there is an expectation that
> *all* of the committers are ready, willing, and able to support the
> code over the long term.
>
> Another word for sandbox is "whiteboard directory", as mention in the
> Rules for Revolutionaries.
>
> * http://incubator.apache.org/learn/rules-for-revolutionaries.html
>
> If you have a sandbox, or whiteboard, then it should be very, very
> clear to anyone using the component that this code is not part of the
> main distribution, *and* that it subject to change or removal without
> notice. If its too easy to use the sandbox code, then people might not
> realize that it's not part of the standard distribution.
>
> Of course, under SVN, it is quite easy to merge and move components
> later, no matter where you hide them now :)
>
> Often, people will develop novel or "revolutionary" code in the
> sandbox, then propose that it be promoted when the code is ready for
> primetime. (Where primetime means the code is stable and there are
> several people interested in using and supporting the code.)
>
> But, "evolutionary" code can be developed as part of the trunk, if
> everyone agrees its something that needs to be part of the next
> release. Generally, a sandbox is for questionable components that may
> or may not be made part of the standard release.
>
> This is important, because Apache Projects are expected to fully
> support whatever goes into a standard release. If it goes into the
> standard release, it should be bug-free in every subsequent release,
> and if it we decide to remove it, we should go through a
> deprecate-replace-remove cycle over two or more stable releases.
>
> Putting code in a standard release means we are committed to the code.
> Putting code in a sandbox is "throwing stuff on the wall and seeing
> if it sticks" :)
>
> Whether a component *needs* to go through a sandbox would depend on
> whether it *needs* to be part of the next standard release. If it's in
> the trunk, and it's not done yet, then it becomes a blocker until it's
> done (or moved out of the trunk).
>
>
> On 5/11/05, Martin Marinschek <ma...@gmail.com> wrote:
> > What about the sourceforge project that has already been set up?
>
> As mentioned, some people on the Struts team setup a SourceForge site
> to make it easier for non-committers to share code with the Struts
> community. But it is not used as an actual sandbox. (Struts already
> has one of those.) It's just a place where people can share Struts
> extensions and sample applications outside of the standard release.
>
> Of course, if a non-committer wants to develop something and then
> propose it to the Apache Struts Project, a good approach would be to
> develop it on the SourceForge site. But, it would still have to go
> through the incubator and all that.
>
> When a Struts committer want to develop something that might become
> part of the Struts release or a new Struts subproject, we start it in
> the ASF repository, not the SourceForge site.
>
> The cool thing about a sandbox, as used by Struts and Jakarta Commons,
> is that you don't need group approval. You can start it up, and see
> how it goes, without having to convince anyone first. It gives you a
> chance to do the code, and then let the code do the talking.
>
> HTH, Ted.
>
Re: Sandbox
Posted by Ted Husted <te...@gmail.com>.
On 5/11/05, Sean Schofield <se...@gmail.com> wrote:
> > 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.
It's more like all external "codebases" donated to the Foundation
*must* go through the Incubator.
The two concerns are IP and Community. First, the ASF wants to be
positive that we do in fact own every line of code in our
repositories. Of course, under the Apache License, we don't mean "own"
in the exclusive sense. But "own" in the sense that we can put it
under the Apache License, and no one else has a legal right to
complain.
If an external codebase could enter the ASF through any of our dozens
of projects, it would be too easy for a project to slip and allow in a
codebase with IP issues. So, when IBM donates Derby, it doesn't go
straight to db.apache.org, it goes to the Incubator first, where
another set of eyes can look it over.
Now if the codebase is developed here in our repository, regardless of
its size, then we own it and we can put it under the Apache License.
It's only external codebases developed by non-committers that concern
Incubator.
Of course, the ASF doesn't want code as much as we want community
(people who create, maintain, and support code). Before any large
donation is accepted, we need to know that there are *several* members
of our community who will support the code over the long term.
Essentially, the Incubator is a front controller for new projects and
external code donations.
A lot of projects maintain sandboxes to ensure that there is a
community support behind a codebase before making it part of the
trunk. Once it is part of the trunk, there is an expectation that
*all* of the committers are ready, willing, and able to support the
code over the long term.
Another word for sandbox is "whiteboard directory", as mention in the
Rules for Revolutionaries.
* http://incubator.apache.org/learn/rules-for-revolutionaries.html
If you have a sandbox, or whiteboard, then it should be very, very
clear to anyone using the component that this code is not part of the
main distribution, *and* that it subject to change or removal without
notice. If its too easy to use the sandbox code, then people might not
realize that it's not part of the standard distribution.
Of course, under SVN, it is quite easy to merge and move components
later, no matter where you hide them now :)
Often, people will develop novel or "revolutionary" code in the
sandbox, then propose that it be promoted when the code is ready for
primetime. (Where primetime means the code is stable and there are
several people interested in using and supporting the code.)
But, "evolutionary" code can be developed as part of the trunk, if
everyone agrees its something that needs to be part of the next
release. Generally, a sandbox is for questionable components that may
or may not be made part of the standard release.
This is important, because Apache Projects are expected to fully
support whatever goes into a standard release. If it goes into the
standard release, it should be bug-free in every subsequent release,
and if it we decide to remove it, we should go through a
deprecate-replace-remove cycle over two or more stable releases.
Putting code in a standard release means we are committed to the code.
Putting code in a sandbox is "throwing stuff on the wall and seeing
if it sticks" :)
Whether a component *needs* to go through a sandbox would depend on
whether it *needs* to be part of the next standard release. If it's in
the trunk, and it's not done yet, then it becomes a blocker until it's
done (or moved out of the trunk).
On 5/11/05, Martin Marinschek <ma...@gmail.com> wrote:
> What about the sourceforge project that has already been set up?
As mentioned, some people on the Struts team setup a SourceForge site
to make it easier for non-committers to share code with the Struts
community. But it is not used as an actual sandbox. (Struts already
has one of those.) It's just a place where people can share Struts
extensions and sample applications outside of the standard release.
Of course, if a non-committer wants to develop something and then
propose it to the Apache Struts Project, a good approach would be to
develop it on the SourceForge site. But, it would still have to go
through the incubator and all that.
When a Struts committer want to develop something that might become
part of the Struts release or a new Struts subproject, we start it in
the ASF repository, not the SourceForge site.
The cool thing about a sandbox, as used by Struts and Jakarta Commons,
is that you don't need group approval. You can start it up, and see
how it goes, without having to convince anyone first. It gives you a
chance to do the code, and then let the code do the talking.
HTH, Ted.
Re: Sandbox
Posted by Sean Schofield <se...@gmail.com>.
> 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.
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.
> 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.
sean
Re: Sandbox
Posted by Michael McGrady <mi...@gmail.com>.
What happened to the first sandbox debate?
On 5/11/05, Grant Smith <gr...@marathon-man.com> wrote:
> I'd like to kick off the whole sandbox debate again. Yes, I'm a sucker
> for punishment..
>
> 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.
>
> Would this satisfy the ASF's requirement for "All New Components Must Go
> Through the Incubator" ? Hopefully...
>
>