myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: [proosal] Changes to sandbox
Date Mon, 26 Sep 2005 17:52:22 GMT
Issue 1: creating a one tld comprises them all tld file:

@Sylvain: Sean is right here! we can keep the sandbox component in the
sandbox tld, but move it over to tomahawk.

So you won't have any issues with moving the components over, right?

Issue 2: making an exception for sandbox in the build:

@Sean: Still, I think we shouldn't make an exception to the build for
the sandbox.jar when releasing - I'd say we just release it as well,
clearly indicating that this is experimental stuff.

So we get rid of both exceptions with this procedure!

regards,

Martin

On 9/26/05, Sean Schofield <sean.schofield@gmail.com> wrote:
> Laziness might be a little bit strong of a word but that's basically
> what we're talking about here.  When a sandbox component is promoted
> you have to change your <sbx:inputSuggest> to <t:inputSuggest>.
> Including the sandbox in myfaces-all.jar and providing an "all" TLD
> allows you to not change your code at all when a component is
> promoted.
>
> Keep in mind that you don't have to change anything until you are
> ready to change it.  So you can continue to use <sbx:inputSuggest>
> from the nightly even after its promoted to the main project (and even
> after its released as part of tomahawk.)
>
> sean
>
> On 9/26/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> >  Hello Sean,
> >
> >  It's not a question of laziness.
> >  As said before, having one common jar is very useful when you develop a
> > component there, and when it's moved in production later.
> >  I don't agree excluding it just because there was an unfortunate bug that
> > hasn't been fixed in time for an important release.
> >  And the build process isn't that complex either.
> >
> >  As for the confusion, I don't think our users are so stupide to have any
> > confusion here. It's pretty clear I think. Furthermore they'll have to
> > explicitly choose for this option, so when they do it they'll be fully
> > aware.
> >  And we can put some more warnings it you think it's necessary.
> >
> >  But to me this option is really very useful and will help raise the number
> > and quality of the sandbox's components before moving them to tomahawk.
> >
> >  Sylvain.
> >
> >
> >  On Sun, 2005-09-25 at 20:36 -0400, Sean Schofield wrote:
> >  I don't see how excluding sandbox stuff from myfaces-all.jar will take
> > anything away from our users. If you want to use the sandbox stuff
> > you just need two jars: myfaces-all.jar and sandbox.jar.
> >
> > Putting everything in myfaces-all.jar just allows you to be lazy and
> > use one jar and one TLD. That convenience comes at a cost. The
> > downside is confusion to our users because the jar is missing the
> > sandbox stuff when released but its in the nightly. It also is a
> > massive headache as far as the build is concerned and we have already
> > seen how that has lead to a problem in the release.
> >
> > I like Sylvain's suggestion of excluding the sandbox from the build by
> > default but I would go one step further and exclude it from
> > myfaces-all.jar. Isolate the sandbox stuff in its own jar but make it
> > available by building the source or downloading the nightly build.
> > What is the problem with that? (other than a little extra work for the
> > smaller groups of users using sandbox stuff)
> >
> > My 2 cents.
> >
> > sean
> >
> >
> >
> > On 9/25/05, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> > > I agree with Sylvain that the convenience of having all in a single
> > > jar, with an according TLD is a good thing.
> > >
> > > I also agree with Sean that the sandbox is something that might be
> > > unstable and insecure and should be considered as such by our users.
> > >
> > > Still, after very careful consideration, I think we should not take
> > > away the possibility of our users to test and improve the sandbox,
> > > knowingly doing so as the immaturity of the sandbox is clearly
> > > published.
> > >
> > > Proposal: we clearly mark the sandbox as experimental (as we do of
> > > today, and people seem to very well understand that) and do the same
> > > with the sandbox as with tomahawk - create a jar, include it in the
> > > myfaces-all.jar
> > >
> > > I think that our problems stem from making exceptions and extra work
> > > in the build process, and not from including the sandbox just like the
> > > tomahawk stuff.
> > >
> > > I believe we should put the work in defining the contract to our
> > > users, and not in tweaking the build process!
> > >
> > > ... and I'd like to hear John Fallow's opinion here - the Oracle guys
> > > are putting a lot of effort in their deployment and building process,
> > > let's see what his opinion on this would be.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 9/25/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> > > > I'm not talking about shipping this in the releases, but for those that
> > use
> > > > the head, I think it's a good think as it'll improve the code of the
> > > > sandbox.
> > > > And those that'll use it will do it knowingly.
> > > >
> > > > So, I don't see this as a risk. Rather as a very useful option for the
> > > > developers and advanced users.
> > > >
> > > >
> > > > On Sat, 2005-09-24 at 22:34 +0200, Bruno Aranda wrote:
> > > > I am not sure about that... if you do it too easy people will begin to
> > > > use sandbox components in their production applications, and sandbox
> > > > components are unstable by nature. It is better to promote a sandbox
> > > > component to tomahawk once is mature, so people can use it in their
> > > > applications. IMO, people will begin to miss the difference between
> > > > the sandbox and tomahawk...
> > > >
> > > > My two cents,
> > > >
> > > > Bruno
> > > >
> > > > 2005/9/24, Sylvain Vieujot <svieujot@apache.org>:
> > > > > With a separate sandbox, you can't have use <%@ taglib
> > > > > uri="http://myfaces.apache.org/all" prefix="x" %>
> > > > > So, when a component moves from the sandbox to tomahawk, you have
to
> > > > change
> > > > > all your tags.
> > > > >
> > > > > Also, for those like me who uses all the component, it's the same
> > > > arguments
> > > > > as using separate jars, or the myfaces-all.jar
> > > > >
> > > > > Except for the bug on release, preventing from using a myfaces-all
> > like
> > > > > jar, with the sandbox would be a big inconvenient.
> > > > > I think it would just make it a bite more difficult to use the sandbox
> > > > > stuffs, and gives less incentive in putting a new component there.
> > > > >
> > > > > An example is the fieldset component that I just did.
> > > > > It's very easy to do, and doing it in the sandbox isn't a problem
now
> > > > > thanks to this taglib uri="http://myfaces.apache.org/all" stuff.
> > > > > Without this, I don't think I would have done it because it would
be a
> > > > mess
> > > > > to use s: mixed to t: tags, and moving it later to tomahawk would
have
> > > > > broken my apps.
> > > > > I would just have used the old htmlTag workaround instead.
> > > > > I also started using and contributing to the inputSuggestAjax for
the
> > same
> > > > > reasons.
> > > > > Otherwise, I don't think I would have used it in real applications.
I
> > > > would
> > > > > just have waited for it to be in tomahawk.
> > > > >
> > > > > Keeping things separate is usually a good thing, but in this case,
we
> > > > > should keep this flexibility.
> > > > > It doesn't force the use of it and makes life much simpler.
> > > > >
> > > > > I really don't care on how we achive this. Replacing the skip.sandbox
> > by
> > > > an
> > > > > include.sandbox seems the most straight forward, but even if we do
a
> > > > > separate target, or even a separate build file, I'm fine as long
as we
> > > > keep
> > > > > this possible.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Sylvain.
> > > > >
> > > > >
> > > > > On Sat, 2005-09-24 at 12:11 -0400, Sean Schofield wrote:
> > > > > I agree that maybe we should exclude the sandbox by default. Other
> > > > > than that, I disagree. I don't see any real advantage of mixing the
> > > > > sandbox stuff into the other jars. I think it should be kept separate
> > > > > and for those who want to use sandbox stuff before its released,
just
> > > > > add the extra sandbox.jar. What would be so hard about that?
> > > > >
> > > > > sean
> > > > >
> > > > > On 9/24/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> > > > > > As for the relases, you're right.
> > > > > > But I also see great value still having a single jar with
> > everything.
> > > > > > I allows seamless migration from the sandbox to tomahawk.
> > > > > > As such, it allows us to really test the sandbox.
> > > > > > Otherwise, I'm afraid the components in the sandbox will be
really
> > less
> > > > > > used and tested.
> > > > > >
> > > > > > So, I see several alternatives :
> > > > > > 1) The first, which would be my favorite, is not to have a
> > skip.sandbox,
> > > > > > but rather an include.sandbox value (and omit it by default).
> > > > > > 2) Make 2 targets : One that would generate the myfaces-all.jar
with
> > the
> > > > > > sandbox, and one that would generate it without
> > > > > > 3) Have 2 jars : myfaces-all.jar, and myfaces-all-withSandbox.jar
> > for
> > > > > > example.
> > > > > >
> > > > > > The fact that we have a single tld for example allows us for
example
> > to
> > > > > use
> > > > > > the x: prefix for every component (whether in the sandbox or
not),
> > and I
> > > > > > think this is really important. At least, it is for me.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Sylvain.
> > > > > >
> > > > > >
> > > > > > On Fri, 2005-09-23 at 13:20 -0400, Sean Schofield wrote:
> > > > > > Apparently there is a problem with faces-config.xml in
> > myfaces-all.jar
> > > > > > of the current release. All of this confusion seems to be coming
> > from
> > > > > > the fact that sandbox is in myfaces-all.jar in the nighlty but
not
> > the
> > > > > > release. We have the -Dskip.sandbox option and a bunch of other
> > hacks
> > > > > > in the build to make everything work the way it is now.
> > > > > >
> > > > > > I propose that we not include the sandbox stuff in the
> > myfaces-all.jar
> > > > > > anymore. I was always against this and I think the resulting
> > > > > > confusion and series of hacks outweighs the argument of those
that
> > are
> > > > > > lazy and don't want to include two jars in their ongoing projects.
> > > > > >
> > > > > > Sandbox is untested, undocumented, unvoted and unreleased code.
It
> > > > > > deserves its own jar with its own tld. Its already excluded
from the
> > > > > > release build (which I believe is correct) but the myfaces-all.jar
> > in
> > > > > > the nightly should mirror whats in the release.
> > > > > >
> > > > > > So the proposal is that dist-all generates a separate sandbox.jar
> > with
> > > > > > its own faces-config.xml and its own sanbox.tld.
> > > > > >
> > > > > > I propose we do this *before* any patch release. Also this will
not
> > > > > > affect SVN. It will be a build change only.
> > > > > >
> > > > > > sean
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > > Your JSF powerhouse -
> > > JSF Trainings in English and German
> > >
> >
> >
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Mime
View raw message