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
