Merging locationmap with trunk [was: Merging views with trunk]

[Tim Williams <wi...@gmail.com>]

> Now to the road-map I see for views and the lm-branch:
> 1) Fix all issues with the lm in the lm-branch (there are just minor
> ones that I am aware of)
> 2) merge all lm related stuff with trunk (branch->trunk)
> 3) merge all view changes into whiteboard trunk (branch->trunk) That
> step is and should be independent from step 2, it is only after this
> step because we now have 1 contract that is based on the lm stuff.
> 4) *Stop* and freeze developing the view plugins in trunk!!!
> 5) Open view-branch and start to integrate views into the core

I think the only issue with the locationmap branch that I can find is
FOR-554.  With the suggested workaround that I describe below, I think
we can take that off the list for now and allow the branch to go ahead
and be merged.  I don't want to be too pushy here, but locationmap
branch already seems to have gotten a bad rep for being away from
trunk too long so I think anything we can do to let others take
advantage of the goodness that's in this branch, the better off we'll
be.

Here's my proposal for FOR-554.  Essentially, do an exists check for
locationmap resolution, then as an otherwise, go back to the default
location and let the SourceNotFoundException come from there.  That
will get an understandable error message at least.

For example, what we have now:
<map:select type="exists">
  <map:when test="{project:content.xdocs}tabs.xml">
    <map:generate src="{project:content.xdocs}tabs.xml"/>
  </map:when>
  <map:otherwise>
    <map:generate src="{lm:tabs.xml}"/>
  </map:otherwise>
</map:select>
since the FileGenerator resolves an empty string (what's returned from
a non-matching hint in the locationmapmodule) to the root context, it
gives us an AccessDenied exception rather than a sourcenotfound
exception. What I think we should do as the workaround is:
<map:select type="exists">
  <map:when test="{project:content.xdocs}tabs.xml">
    <map:generate src="{project:content.xdocs}tabs.xml"/>
  </map:when>
  <map:when test="{lm:tabs.xml}">
    <map:generate src="{lm:tabs.xml}"/>
  </map:when>
  <map:otherwise>
    <map:generate src="{project:content.xdocs}tabs.xml"/>
  </map:otherwise>
</map:select>
This, while clearly not the best answer, would give users a reasonable
sourcenotfound error message.

There are two things leading me to this answer:
1) I believe FOR-554 is ultimately a cocoon bug that should be fixed
and so anything we do would be a workaround.

2) I've come to understand that we need a more robust location
resolution error handling capability (as described in another post
that apparently wasn't well received).  It basically said that we
should ultimately be reporting in error messages all locations that
were searched for a resource rather than whatever happens to be in the
"otherwise" clause.

Thoughts?

This, of course, also assumes that everyone agreed that for now we
should revert the fresh-site dependency on views until they're ready
to come out of whiteboard.

Anyway, as I said, I don't mean to come across pushy on this
locationmap branch but I think it's ready to merge and shouldn't grow
moldy.  If this is an acceptable solution, then I'll submit the
appropriate patch for tabs, site, and resource locationmap resolution.

Thanks,
--tim

Re: Merging locationmap with trunk [was: Merging views with trunk]

[Thorsten Scherler <th...@apache.org>]

On Mon, 2005-07-04 at 11:52 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Fri, 2005-07-01 at 08:33 +0100, Ross Gardler wrote:
> > 
> >>Tim Williams wrote:
> 
> >>The actual merge is going to be complex though. 
> > 
> > 
> > Why?
> > 
> > I will happily merge the stuff. Actually not too much have changed.
> 
> Because it will not be a simple "merge this branch with the trunk". We 
> need to ensure we don't merge any of the views stuff (both views and 
> locationmap have touched fresh-site). In addition, the views were copied 
> over at a different time to the rest of the branch, this means there are 
> two root version numbers.
> 

Yeah, I will revert all view specific stuff in the fresh site, then
merge views and last but not least the rest of the locationmap.

> It's not a huge problem, just needs a little thought.
> 
> If you have a little time to do the merge that would be great. All 
> Locationmap branches have been applied now. If not, I should get the 
> time sometime later in the week.

I will try to merge them but I am a wee bit short in time.

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: Merging locationmap with trunk [was: Merging views with trunk]

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> On Fri, 2005-07-01 at 08:33 +0100, Ross Gardler wrote:
> 
>>Tim Williams wrote:

>>The actual merge is going to be complex though. 
> 
> 
> Why?
> 
> I will happily merge the stuff. Actually not too much have changed.

Because it will not be a simple "merge this branch with the trunk". We 
need to ensure we don't merge any of the views stuff (both views and 
locationmap have touched fresh-site). In addition, the views were copied 
over at a different time to the rest of the branch, this means there are 
two root version numbers.

It's not a huge problem, just needs a little thought.

If you have a little time to do the merge that would be great. All 
Locationmap branches have been applied now. If not, I should get the 
time sometime later in the week.

Ross

Re: Merging locationmap with trunk [was: Merging views with trunk]

[Thorsten Scherler <th...@apache.org>]

On Fri, 2005-07-01 at 08:33 +0100, Ross Gardler wrote:
> Tim Williams wrote:
> >>Now to the road-map I see for views and the lm-branch:
> >>1) Fix all issues with the lm in the lm-branch (there are just minor
> >>ones that I am aware of)
> >>2) merge all lm related stuff with trunk (branch->trunk)
> >>3) merge all view changes into whiteboard trunk (branch->trunk) That
> >>step is and should be independent from step 2, it is only after this
> >>step because we now have 1 contract that is based on the lm stuff.
> >>4) *Stop* and freeze developing the view plugins in trunk!!!
> >>5) Open view-branch and start to integrate views into the core
> > 
> > 
> > I think the only issue with the locationmap branch that I can find is
> > FOR-554.  With the suggested workaround that I describe below, I think
> > we can take that off the list for now and allow the branch to go ahead
> > and be merged.

...

> 
> The actual merge is going to be complex though. 

Why?

I will happily merge the stuff. Actually not too much have changed.

> When the views were 
> brought over there was a partial merge of the tree so there and now it 
> appears that people don't want it to go back into trunk.
> 

Stop. 

>>2) merge all lm related stuff with trunk (branch->trunk)
> >>3) merge all view changes into whiteboard trunk (branch->trunk)

It is like this because your are right I merged the whiteboard plugins
from trunk to locationmap_branch. That means this plugins need to be
treated different from the rest. IMO we need to split the merge into
view-merge and rest-merge. That's it. ...and thinking about it, it
should be reverted (3 then 2) because then we can merge the rest
completely. 

> I don't want to tackle this until I have a good couple of hours to focus 
> on it. I doubt that will be until the tail end of next week.
> 

I will prepare a vote.

> > 2) I've come to understand that we need a more robust location
> > resolution error handling capability (as described in another post
> > that apparently wasn't well received).  It basically said that we
> > should ultimately be reporting in error messages all locations that
> > were searched for a resource rather than whatever happens to be in the
> > "otherwise" clause.
> 

the "only" thing we need to do is write a sitemap matcher listener to
store all tried locations in a bean and the parse it in the
stacktrace. ...makes sense?

> What do you mean "apparently wasn't well received"? I don't recall any 
> objections. In our community that means people are either neutral or 
> like the idea, it means thay have nothing else to add. I'm not sure how 
> you will do some of the more advanced stuff (like say we checked here, 
> here and there, at least not without hard coding that info) but I agree 
> we can do at least improve on what we already have.
> 
> > This, of course, also assumes that everyone agreed that for now we
> > should revert the fresh-site dependency on views until they're ready
> > to come out of whiteboard.
> 
> Yes, Thorsten says he wants views to go into their own branch.
> 

Yeah, after the merge with the trunk.

> > Anyway, as I said, I don't mean to come across pushy on this
> > locationmap branch but I think it's ready to merge and shouldn't grow
> > moldy.
> 

Yeah, thanks for the headsup. ;-) Was not at all pushy.

> You are doing the right thing. Right now there are only the two of us 
> active on Locationmaps I'm busy with other things for a short while and 
> so you are left on your own to keep things moving. This is not at all 
> pushy, but *exactly* what we, as a community want, If we don;t like your 
> proposal we can always say no.
> 

Actually I am playing with the travesable generator, but have not check
in anything yet. I hope to add an example how I understood nicola on the
weekend (per dir view feature). He can then correct/enhance/clarify
it ;-)

> Ross
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: Merging locationmap with trunk [was: Merging views with trunk]

[Ross Gardler <rg...@apache.org>]

Tim Williams wrote:
>>Now to the road-map I see for views and the lm-branch:
>>1) Fix all issues with the lm in the lm-branch (there are just minor
>>ones that I am aware of)
>>2) merge all lm related stuff with trunk (branch->trunk)
>>3) merge all view changes into whiteboard trunk (branch->trunk) That
>>step is and should be independent from step 2, it is only after this
>>step because we now have 1 contract that is based on the lm stuff.
>>4) *Stop* and freeze developing the view plugins in trunk!!!
>>5) Open view-branch and start to integrate views into the core
> 
> 
> I think the only issue with the locationmap branch that I can find is
> FOR-554.  With the suggested workaround that I describe below, I think
> we can take that off the list for now and allow the branch to go ahead
> and be merged.


Your workaround is a good one. I also note you are working with the 
Cocoon community to solve the problem in a more permanent way. Please 
provide a patch for your workaround, I will apply it early next week 
(out of office until then).

The actual merge is going to be complex though. When the views were 
brought over there was a partial merge of the tree so there and now it 
appears that people don't want it to go back into trunk.

I don't want to tackle this until I have a good couple of hours to focus 
on it. I doubt that will be until the tail end of next week.

> 2) I've come to understand that we need a more robust location
> resolution error handling capability (as described in another post
> that apparently wasn't well received).  It basically said that we
> should ultimately be reporting in error messages all locations that
> were searched for a resource rather than whatever happens to be in the
> "otherwise" clause.

What do you mean "apparently wasn't well received"? I don't recall any 
objections. In our community that means people are either neutral or 
like the idea, it means thay have nothing else to add. I'm not sure how 
you will do some of the more advanced stuff (like say we checked here, 
here and there, at least not without hard coding that info) but I agree 
we can do at least improve on what we already have.

> This, of course, also assumes that everyone agreed that for now we
> should revert the fresh-site dependency on views until they're ready
> to come out of whiteboard.

Yes, Thorsten says he wants views to go into their own branch.

> Anyway, as I said, I don't mean to come across pushy on this
> locationmap branch but I think it's ready to merge and shouldn't grow
> moldy.

You are doing the right thing. Right now there are only the two of us 
active on Locationmaps I'm busy with other things for a short while and 
so you are left on your own to keep things moving. This is not at all 
pushy, but *exactly* what we, as a community want, If we don;t like your 
proposal we can always say no.

Ross