myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Vieujot <svieu...@apache.org>
Subject Re: [proosal] Changes to sandbox
Date Mon, 26 Sep 2005 12:57:50 GMT
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