Would it make more sense to have this be a separate java.net project to
cut down on the chance for malfeasance, as well as making it easier for
people who aren't RI committers to get access?
Ryan's trying to figure out if access to arbitrary directories can be
restricted (I guess both in theory with CVS and in practice through the
interface that java.net provides). Does anyone know the answer to that
question? If that can be done, then it might be easier to keep it as
part of the same java.net project in terms of project (and site)
maintenance.
-----
Jason Lee, SCJP
Programmer/Analyst
http://www.iec-okc.com
> -----Original Message-----
> From: Michael Youngstrom [mailto:youngm_at_gmail.com]
> Sent: Tuesday, October 24, 2006 11:39 PM
> To: dev_at_javaserverfaces.dev.java.net
> Subject: Re: [Fwd: RI Sandbox]
>
> Then I would offer up Jacob's deferred binding f:*Listener,
> validator, and converter tags too.
>
> Mike
>
> On 10/24/06, Ryan Lubke <Ryan.Lubke_at_sun.com> wrote:
> > Michael Youngstrom wrote:
> > > I think this would be a great idea. Do we think these components
> > > should be targeted as ri specific, implementation independent, a
> > > mix, or a sandbox for each?
> > I would say implementation independent would be a good goal.
> >
> > >
> > > Mike
> > >
> > > On 10/24/06, Ryan Lubke <Ryan.Lubke_at_sun.com> wrote:
> > >> I forgot to add that the yui-based components would be
> donated by
> > >> Jason Lee.
> > >>
> > >>
> > >>
> > >> ---------- Forwarded message ----------
> > >> From: Ryan Lubke <Ryan.Lubke_at_Sun.COM>
> > >> To: dev_at_javaserverfaces.dev.java.net
> > >> Date: Tue, 24 Oct 2006 14:50:28 -0700
> > >> Subject: RI Sandbox
> > >> Hey All,
> > >>
> > >> I'd like to get a discussion going on starting a sandbox for the
> > >> RI.
> > >>
> > >> Some initial thoughts I have are:
> > >> - it would be a directory under the current repository
> > >> - the standard checkin process would be ignored
> > >> to foster faster development cycles
> > >> - we'd provide a separate download bundle for the
> > >> components of the sandbox
> > >> - this would be open for components, alternate
> > >> implementation components, etc.
> > >>
> > >> There are several candidates for this sandbox already.
> > >> - Stan's alternate NavigationHandler which supports
> > >> parameters
> > >> - 508 compliant datatable since we couldn't
> > >> get it in to the MR (there are several folks
> > >> interested in this one)
> > >> - Some starter yui-based components
> > >>
> > >> Anyone have any thoughts to add to this?
> > >>
> > >>
> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail:
> > >> dev-unsubscribe_at_javaserverfaces.dev.java.net
> > >> For additional commands, e-mail:
> > >> dev-help_at_javaserverfaces.dev.java.net
> > >>
> > >>
> > >>
> > >>
> > >>
> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail:
> > >> dev-unsubscribe_at_javaserverfaces.dev.java.net
> > >> For additional commands, e-mail:
> > >> dev-help_at_javaserverfaces.dev.java.net
> > >>
> > >>
> > >
> > >
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail:
> > > dev-unsubscribe_at_javaserverfaces.dev.java.net
> > > For additional commands, e-mail:
> > > dev-help_at_javaserverfaces.dev.java.net
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> > For additional commands, e-mail:
> dev-help_at_javaserverfaces.dev.java.net
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>