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