Lets get rid of the sandbox stuff from faces-config.xml for now (at least in the branch.) It is causing to much headache and its only there to support sandbox. What do you think? This last minute addition to the mix is the source of all the problems.
sean On 9/23/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > > On Sep 23, 2005, at 8:27 AM, Sean Schofield wrote: > > > The tag definitely will build without the sandbox b/c that is how I > > built the release. You need -Dskip.sandbox=True. Or if you use the > > bootstrap you just execute the release tag. Now the skip.sandbox > > stuff might be part of why faces-config.xml is missing but we can (and > > should) fix that part. > > > > OK, I've got a build but I had to create build/dist/temp by hand. > I'll look into that before checking in, probably user error on my part. > > > Please try this first before creating all sorts of branches, etc. I > > will repeat that the tag is basically a branch. You can check into it > > so just treat it like a branch. Lets get this fixed with a minimum of > > hasty changes to the SVN scheme. > > More thoughts to follow in separate email > > TTFN, > > -bd- > > > > > sean > > > > On 9/23/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > > > >> Agreed, > >> > >> We need a branch and we need to edit it. > >> > >> As I understand it there is currently the > >> release/ with externals to all the tags except the sandbox. > >> > >> I've just checked out and the tag won't build because it does not > >> included sandbox. > >> > >> My proposal; > >> 1) Create a branch of each subproject that is a copy of the 1_1_0 tag > >> 2) Rework the 'release' to point to the branch of each subproject > >> 3) Create a tag of sandbox starting now that is labeled 1_1_0 (even > >> though it does not correspond to the 1.1.0 release I'd like the > >> naming to be consistent) and copy that to a branch > >> 4) Commit the change to the build branch > >> 5) build and test > >> 6) create a new tag in each subproject called 1_1_1 > >> 7) send email so that Sean can build and push a new release > >> > >> Thoughts? > >> > >> I'm going to start executing in about 15 minutes if I don't hear any > >> dissent so speak now or hold your peace :-) (for the english not as a > >> first language folks that is an old Texas colloquialism meaning if > >> you don't say it now, don't say it) > >> > >> TTFN, > >> > >> -bd- > >> > >> On Sep 23, 2005, at 7:59 AM, Mike Kienenberger wrote: > >> > >> > >>> I'm certainly no expert in making releases nor am I a committer, but > >>> why start off being sloppy? There's a bug that warrants an > >>> immediate > >>> release. There's no guarantee that another such bug won't turn up > >>> after the next release and require another release. That's what > >>> branches are for, so why resist using them? > >>> > >>> Because work on MyFaces are ongoing, it's not reasonable to try to > >>> support maintenance releases without branches, is it? > >>> > >>> On 9/23/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> Sigh. How did we miss this one? I thought we did a test of > >>>> everything? This is probably the only type of error where we could > >>>> justify doing this although its kind of embarassing that it > >>>> happened > >>>> in the first place. > >>>> > >>>> Technically you can check into a tagged version so this is probably > >>>> the best thing to do. Let me know when its done (and tested) and I > >>>> can do a rebuild and re-publish of the myfaces binary bundles over > >>>> the > >>>> weekend. > >>>> > >>>> sean > >>>> > >>>> On 9/23/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> We have been discussing doing a release as the problem with the > >>>>> faces-config.xml missing in the myfaces-all.jar is a very > >>>>> prominent > >>>>> one ;) > >>>>> > >>>>> If there is a way of fixing the existing release with just the > >>>>> faces-config.xml file, that would be better! > >>>>> > >>>>> regards, > >>>>> > >>>>> Martin > >>>>> > >>>>> On 9/23/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>> > >>>>>>> as long as 1_1_0 is ok to change (by convention tags are not > >>>>>>> modified, only branches). > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> Technically you can change it but SVN (at least Tortoise SVN) > >>>>>> warns > >>>>>> you and says its a tag and you shouldn't. Why do we need a > >>>>>> branch at > >>>>>> this point? > >>>>>> > >>>>>> We could create a branch for it but lets establish why this is > >>>>>> necessary first. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> All I'm looking for is a place to change the release only > >>>>>>> enough to > >>>>>>> get the faces-config.xml file in place (as well as the other > >>>>>>> missing > >>>>>>> bits because that file is not found) and then get a new release > >>>>>>> pushed out. > >>>>>>> > >>>>>>> Martin M is planning on doing another release from the trunk > >>>>>>> after I > >>>>>>> finish my commit. That is fine but risky. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> We're doing a release? I haven't read every message on the dev > >>>>>> list > >>>>>> but I must have missed this discussion. What is the > >>>>>> motivation for > >>>>>> this? > >>>>>> > >>>>>> > >>>>>> > >>>>>>> TTFN, > >>>>>>> > >>>>>>> -bd- > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> sean > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Sep 23, 2005, at 5:53 AM, Sean Schofield wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -1 > >>>>>>>> > >>>>>>>> Note that after I tagged the 1.1 release I created a external > >>>>>>>> in the > >>>>>>>> "release" dir so if you use > >>>>>>>> http://svn.apache.org/repos/asf/myfaces/release/1_1_0/ you > >>>>>>>> will get > >>>>>>>> "current" but for the release. It doesn't include sandbox so > >>>>>>>> its not > >>>>>>>> quite the same but sandbox is not part of the official release. > >>>>>>>> > >>>>>>>> Doesn't this give you what you need? > >>>>>>>> > >>>>>>>> sean > >>>>>>>> > >>>>>>>> On 9/23/05, Martin Marinschek <[EMAIL PROTECTED]> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> I agree with Martin on this - if you need everything, you can > >>>>>>>>> always > >>>>>>>>> checkout MyFaces, right? > >>>>>>>>> > >>>>>>>>> regards, > >>>>>>>>> > >>>>>>>>> Martin > >>>>>>>>> > >>>>>>>>> On 9/23/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Thu, 22 Sep 2005, Bill Dudney wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Well the idea is that people would then be using current/ > >>>>>>>>>>> trunk > >>>>>>>>>>> to checkout > >>>>>>>>>>> instead of just current. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> But by definition, what's in branches and tags is not > >>>>>>>>>> current, so > >>>>>>>>>> why does > >>>>>>>>>> it make sense to include them under 'current'? The structure > >>>>>>>>>> you > >>>>>>>>>> described > >>>>>>>>>> is exactly what you have without using the 'current' > >>>>>>>>>> external in > >>>>>>>>>> the first > >>>>>>>>>> place, isn't it? > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Martin Cooper > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> TTFN, > >>>>>>>>>>> > >>>>>>>>>>> -bd- > >>>>>>>>>>> > >>>>>>>>>>> On Sep 22, 2005, at 12:31 PM, Martin Cooper wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, 22 Sep 2005, Bill Dudney wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi All, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'd like to propose that we change current to be; > >>>>>>>>>>>>> > >>>>>>>>>>>>> current > >>>>>>>>>>>>> /branches > >>>>>>>>>>>>> /tags > >>>>>>>>>>>>> /trunk > >>>>>>>>>>>>> > >>>>>>>>>>>>> Still all externals but tracking the group of tags & > >>>>>>>>>>>>> branches > >>>>>>>>>>>>> that are > >>>>>>>>>>>>> common across all the subprojects. > >>>>>>>>>>>>> > >>>>>>>>>>>>> current/trunk -> becomes what we currently call current > >>>>>>>>>>>>> current/branches -> currently empty > >>>>>>>>>>>>> current/tags -> 1_1_0 with externals to each subproject's > >>>>>>>>>>>>> 1_1_0 tag > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> I would recommend against doing that. It would mean that > >>>>>>>>>>>> everyone checking > >>>>>>>>>>>> out 'current' would end up with multiple copies of the > >>>>>>>>>>>> entire > >>>>>>>>>>>> source tree, > >>>>>>>>>>>> which is unlikely to be something that they would want. > >>>>>>>>>>>> > >>>>>>>>>>>> Most people are unlikely to want more than one version > >>>>>>>>>>>> of the > >>>>>>>>>>>> source at any > >>>>>>>>>>>> given time, so I don't see a need to clump together > >>>>>>>>>>>> multiple > >>>>>>>>>>>> versions in a > >>>>>>>>>>>> single checkout. > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Martin Cooper > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> To fix the faces-config.xml bug that's been identified in > >>>>>>>>>>>>> the > >>>>>>>>>>>>> 1_1_0 > >>>>>>>>>>>>> release we can create a branch in current/branches/1_1_0 > >>>>>>>>>>>>> that > >>>>>>>>>>>>> uses > >>>>>>>>>>>>> externals to the tags for everything but 'build' which > >>>>>>>>>>>>> would > >>>>>>>>>>>>> point to the > >>>>>>>>>>>>> 1_1_0 branch in build (not yet created but I'd be glad > >>>>>>>>>>>>> to do > >>>>>>>>>>>>> that). > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thoughts? > >>>>>>>>>>>>> > >>>>>>>>>>>>> TTFN, > >>>>>>>>>>>>> > >>>>>>>>>>>>> -bd- > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> http://www.irian.at > >>>>>>>>> Your JSF powerhouse - > >>>>>>>>> JSF Trainings in English and German > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> http://www.irian.at > >>>>> Your JSF powerhouse - > >>>>> JSF Trainings in English and German > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > >
