I totally agree with Seans and Martins proposal. Just an additional suggestion from my side: Let's call the sandbox lib "myfaces-sandbox.jar" instead of "sandbox.jar". This way users are perhaps more secured from forgetting to update the sandbox library in their server's (or webapp's) lib dir, when they switch to a new MyFaces release. Perhaps we should actually prefix all outcoming libs with "myfaces-"? Also the tomahawk jar?
-Manfred 2005/9/26, Sean Schofield <[EMAIL PROTECTED]>: > 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 > > > > > > > > > >
