myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <sean.schofi...@gmail.com>
Subject Re: [proosal] Changes to sandbox
Date Mon, 26 Sep 2005 17:11:59 GMT
And the generation of the myfaces-all TLD is confusing for several
reasons.  This adds yet another way to reference a tomahawk component
from the already dizzying array of choices.

So tomahawk can be referenced using:

http://myfaces.apache.org/extensions
http://myfaces.apache.org/tomahawk
http://myfaces.apache.org/all (with the confusing 'x' reference that
we are trying to get people away from)

And sandbox can be refrenced using:

http://myfaces.apache.org/sandbox
http://myfaces.apache.org/all

The generation of the "all" TLD itself is a pretty nast hack and is
part of the problem with the current build process.  At first I was OK
with it but I like this less and less.

sean

On 9/26/05, Sylvain Vieujot <svieujot@apache.org> wrote:
>  You're right, this is how it is right now :
>
>  <uri>http://myfaces.apache.org/tomahawk</uri>, with
> recommended prefix t: for Tomahawk
>  <uri>http://myfaces.apache.org/sandbox</uri>, with
> recommended prefix s: for Sandbox
>  <uri>http://myfaces.apache.org/all</uri>, with recommended prefix x: for
> All components (Tomahawk + Sandbox)
>
>
>  On Mon, 2005-09-26 at 12:22 -0400, Mike Kienenberger wrote:
>  I don't use the sandbox stuff (yet), but I think that it should be
> included in the myfaces-all jar, provided it has a different tld file
> (ie, sandbox:component rather than t:component"), and I believe that
> this is already the case. If it requires a different prefix, no one
> is going to accidentally use a sandbox component thinking it's not a
> sandbox component.
>
> Having multiple jar files increases the chance of one of the jar files
> being out of sync with another one of the files. I'd imagine that
> the sandbox components are often dependent on a specific tomahawk
> version.
>
>
>
> 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
> > >
> >
> >
>
>

Mime
View raw message