+1 and amen to that. IMHO, sandbox is a separate component lib not yet part of MyFaces, if you want to use, include its lib and declare a separate TLD. If you don't want to do that, wait till the components are accepted as part of official MyFaces.
My 2 cents, Kalle > -----Original Message----- > From: Sean Schofield [mailto:[EMAIL PROTECTED] > Sent: Monday, September 26, 2005 12:28 PM > To: MyFaces Development > Subject: Re: [proosal] Changes to sandbox > > Let's make sure we are on the same page here (some stuff I > read in Sylvain's reply leads me to believe we are > interpreting Martin's suggestion differently.) > > Here is a new proposal ... > > 1.) Remove any reference to sandbox from myfaces-all.jar. > Zero traces of sandbox in myfaces-all.jar. This means no > faces-config, no TLD (including the all TLD) and no class files. > > 2.) Include sandbox.jar in both the nightly and release > builds. This means that there will be no more > "-Dskip.sandbox=true" and that the sandbox directories will > always be available when building. The sandbox.jar will > contain its own TLD and class files. > > That's how I understood Martin's proposal. Either way this > is what I am proposing now. I am prepared to compromise by > including sandbox stuff in the distro but my position is that > it should not be part of all and that we shouldn't sandbox > stuff in with the TLD or faces-config.xml for tomahawk. > > sean > > On 9/26/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > > One more thing about those TLDs. > > > > I find that having one big tld for each project is quite > bad, as it's > > hard to read and to maintain. It also promotes commit > conflicts when 2 > > developer are working concurrently on different components. > > Maybe a better approach would be to have tld snipsets in each > > component's directory, and to generate each tld in the > build process. > > > > Any thoughts about this ? > > > > Sylvain. > > > > > > On Mon, 2005-09-26 at 14:57 -0400, Sylvain Vieujot wrote: > > > > I too think it makes sens to release the sandbox into the > myfaces-all.jar. > > > > But if we do that, then this jar needs to contain a > faces-config.xml > > that merges the ones from tomahawk & from the sandbox (build file, > > merge-sandbox target). > > The process for merging the faces-config.xml files & the tld is > > basically the same. That's why I think of it as a logical step. > > I don't see how removing it will improve the code. > > I didn't knew we would keep the tld fragments in the sandbox's tld > > once they are promoted to tomahawk, and that was the main > idea behind > > the "all tld". > > But, are we sure it's the good solution to keep old components > > forever in the sanbox tld. It'll be increasingly hard to > maintain and > > to keep synchronized with the one of tomahawk. > > So, I prefer the path of having an all in one tld, but to clearly > > mark it as unstable as it contains sandbox's components. > > > > Sylvain. > > > > On Mon, 2005-09-26 at 12:12 -0600, Bill Dudney wrote: > > I like this approach too. sandbox.jar is separate but part of the > > release. > > > > I'm equally OK with putting the sandbox stuff into the myfaces- > > all.jar with a separate tld (i.e. don't do the 'all' tld). > Users wont > > be confused because its in a separate tld. > > > > I don't agree that its a lazy/not lazy thing, its just > simpler to have > > one jar file with the whole thing instead of multiple. > > > > TTFN, > > > > -bd- > > > > On Sep 26, 2005, at 11:57 AM, Sean Schofield wrote: > > > > >> Issue 2: making an exception for sandbox in the build: > > >> > > >> @Sean: Still, I think we shouldn't make an exception to > the build > > >> for the sandbox.jar when releasing - I'd say we just > release it as > > >> well, clearly indicating that this is experimental stuff. > > >> > > > > > > I might be persuaded to accept this route. It would certainly be > > > easier (we wouldn't have to worry about skipping the sandbox.) > > > > > > So we would get rid of myfaces all TLD and *not* include > sandbox in > > > myfaces-all.jar right? Everything would be in sandbox.jar > and thar > > > jar would be available in both the nightly and release builds? > > > > > > Is that what you are proposing? > > > > > > sean > > > > > > > > > >
