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 > > > > > >
