[jsr-314-open] Slashes in resource library names?

[Dan Allen]

Thank Cay.

Let's get it done.

-Dan

On Thu, Feb 4, 2010 at 6:10 PM, Cay Horstmann <cay at horstmann.com> wrote:

> It's at
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=740.
> What a mess!
>
> At least it paves the way towards handling hierarchical library names in
> the future, should you choose to do so.
>
>
> On 02/03/2010 09:12 AM, Dan Allen wrote:
>
>> Cay, could you organize your comments into a spec issue?
>>
>> Thx,
>>
>> -Dan
>>
>> On Wed, Feb 3, 2010 at 11:18 AM, David Geary <clarity.training at gmail.com
>> <mailto:clarity.training at gmail.com>> wrote:
>>
>>    +1. This should definitely be fixed.
>>
>>
>>    david
>>
>>    2010/2/3 Dan Allen <dan.j.allen at gmail.com
>>    <mailto:dan.j.allen at gmail.com>>
>>
>>
>>        On Mon, Feb 1, 2010 at 11:07 AM, Jason Lee
>>        <jason at steeplesoft.com <mailto:jason at steeplesoft.com>> wrote:
>>
>>            On 2/1/10 9:13 AM, Kito Mann wrote:
>>
>>>            There was a discussion about nested resource library names
>>>            last year. I would say to search the archives, but I don't
>>>            know if that's possible. Anyway, here was the outcome:
>>>
>>>                Ed:
>>>
>>>                Yes, you are correct that the resource naming scheme
>>>                prevents nested
>>>                resource libraries. Nested resource libraries were not
>>>                on the list of
>>>                requirements when we designed this feature back in
>>>                November of 2007.  We
>>>                will not accept this requirement change at this point.
>>>
>>>
>>>            Dan:
>>>
>>>            So the spec needs to at least be clear that it's not
>>>            permitted and suggest the alternative. Several people
>>>            reading it didn't understand what to do in this case.
>>>
>>>            IMHO, it's a shame that we can't use the nested structure.
>>>            Seems like a pretty obvious convention instead of
>>>            configuration thing. I don't know how that got missed in
>>>            the design process.
>>>
>>            It would be interesting to find out why that was left out.
>>            Was it simply an oversight, or are there technical reasons
>>            for disallowing that? On the surface, it sounds like it
>>            would be easy to implement and support, but I've not thought
>>            too deeply on the topic.  Maybe that's something we should
>>            fix, if we can, for 2.1.
>>
>>
>>        We never got to the bottom of why this was left out, but I think
>>        there was a general agreement that it should be fixed. Let's
>>        discuss when and get an issue report filed.
>>
>>        Here is the (not-so-pretty) link to the original discussion:
>>
>>
>> http://archives.java.sun.com/cgi-bin/wa?A1=ind0904&L=JSR-314-OPEN&X=3E023C7A0F922F9C1F#16
>>        <
>> http://archives.java.sun.com/cgi-bin/wa?A1=ind0904&L=JSR-314-OPEN&X=3E023C7A0F922F9C1F#16
>> >
>>
>>        (that reminds me I have some leaning on the JCP PMO to get to).
>>
>>        -Dan
>>
>>        --
>>        Dan Allen
>>        Senior Software Engineer, Red Hat | Author of Seam in Action
>>        Registered Linux User #231597
>>
>>        http://mojavelinuxcom <http://mojavelinux.com>
>>
>>        http://mojavelinux.com/seaminaction
>>        http://www.google.com/profiles/dan.j.allen
>>
>>
>>
>>
>>
>> --
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>> http://www.google.com/profiles/dan.j.allen
>>
>
>
> --
>
> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com
>



-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100204/e1f4e6cd/attachment.html