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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > 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 <[EMAIL PROTECTED]> 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 >
