Eclipse Community Forums: Buckminster » RMap redirect breaks searchPath overlap

Home » Archived » Buckminster » RMap redirect breaks searchPath overlap

RMap redirect breaks searchPath overlap [message #515049]

Wed, 17 February 2010 10:02

Eclipse User

Hi,

following construct:

A.rmap
----
<searchPath name="org.eclipse.ecf.osu">
...
</searchPath>

<locator
searchPathRef="org.eclipse.ecf.osu"
pattern="^org\.eclipse\.ecf(\..+)?" />

<redirect href="http://path/to/B.rmap
pattern=".*" />

B.rmap
----
<searchPath name="org.eclipse.ecf">
...
</searchPath>

<locator
searchPathRef="org.eclipse.ecf"
pattern="^org\.eclipse\.ecf(\..+)?" />

Unless I limit the scope of the first searchPathRef to exactly what is
supposed to be found in A, B is not called.

Bug?

Thanks
Markus

Re: RMap redirect breaks searchPath overlap [message #515080 is a reply to message #515049]

Wed, 17 February 2010 11:34

Eclipse User

Hi Markus!

If you don't have a pattern the locator will match everything.
The default behavior is to fail if it doesn't find anything.
By adding the pattern you only go there if you know it's supposed to find it there.
Alternatively you can add a failOnError="false" to the locator, then it will continue to your redirect if it doesn't find what it's looking for.

/John

Re: RMap redirect breaks searchPath overlap [message #515088 is a reply to message #515049]

Wed, 17 February 2010 11:47

Eclipse User

On 02/17/2010 04:02 PM, Markus Alexander Kuppe wrote:
> Unless I limit the scope of the first searchPathRef to exactly what is
> supposed to be found in A, B is not called.
>
A locator hit is finite unless you specify failOnError='false'.

Regards,
Thomas Hallgren

Re: RMap redirect breaks searchPath overlap [message #515143 is a reply to message #515088]

Wed, 17 February 2010 15:52

Eclipse User

On 02/17/2010 05:47 PM, Thomas Hallgren wrote:
> On 02/17/2010 04:02 PM, Markus Alexander Kuppe wrote:
>> Unless I limit the scope of the first searchPathRef to exactly what is
>> supposed to be found in A, B is not called.
>>
> A locator hit is finite unless you specify failOnError='false'.

Sorry, what I meant was that I expect Bucky to try the locator in A
first and if it does not produce a match try locator B instead. However
Bucky appears to try A, fails to produce a match an never tries B.

Markus

Re: RMap redirect breaks searchPath overlap [message #515157 is a reply to message #515143]

Wed, 17 February 2010 12:12

Eclipse User

On 02/17/2010 09:52 PM, Markus Alexander Kuppe wrote:
> On 02/17/2010 05:47 PM, Thomas Hallgren wrote:
>> On 02/17/2010 04:02 PM, Markus Alexander Kuppe wrote:
>>> Unless I limit the scope of the first searchPathRef to exactly what is
>>> supposed to be found in A, B is not called.
>>>
>> A locator hit is finite unless you specify failOnError='false'.
>
> Sorry, what I meant was that I expect Bucky to try the locator in A
> first and if it does not produce a match try locator B instead. However
> Bucky appears to try A, fails to produce a match an never tries B.
>
That's what I meant. Buckminster chooses a SearchPath based on a locator. If that SearchPath fails to produce a match,
the whole resolution fails. That's the intended behavior. You can change this behavior and tell Buckminster to continue
with the next matching locator by setting failOnError="false" on the locator that led to failure.

- thomas

Re: RMap redirect breaks searchPath overlap [message #515243 is a reply to message #515157]

Thu, 18 February 2010 04:33

Eclipse User

On 02/17/2010 11:08 PM, Thomas Hallgren wrote:
> On 02/17/2010 09:52 PM, Markus Alexander Kuppe wrote:
>> On 02/17/2010 05:47 PM, Thomas Hallgren wrote:
>>> On 02/17/2010 04:02 PM, Markus Alexander Kuppe wrote:
>>>> Unless I limit the scope of the first searchPathRef to exactly what is
>>>> supposed to be found in A, B is not called.
>>>>
>>> A locator hit is finite unless you specify failOnError='false'.
>>
>> Sorry, what I meant was that I expect Bucky to try the locator in A
>> first and if it does not produce a match try locator B instead. However
>> Bucky appears to try A, fails to produce a match an never tries B.
>>
> That's what I meant. Buckminster chooses a SearchPath based on a
> locator. If that SearchPath fails to produce a match, the whole
> resolution fails. That's the intended behavior. You can change this
> behavior and tell Buckminster to continue with the next matching locator
> by setting failOnError="false" on the locator that led to failure.

Thanks, I guess I got lost in translation. :-o

Markus

Previous Topic:	generator.lastRevision.format question
Next Topic:	Get Maven component from SVN

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 09 12:59:03 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter