On the same machine w/ the same JVM, you could very well see the same
ordering consistently, even in situations where ordering is
non-deterministic. See if that list is ever a set. Then you might find your
problem :)
-Dan
On Mon, Feb 13, 2012 at 18:26, Richard Kennard <
richard(a)kennardconsulting.com> wrote:
My apologies. It looks like I am misunderstanding the API. The code
in
question does this (FacesScaffold.java:691):
for (Resource<?> resource :
web.getWebResource("scaffold").listResources())
{
HtmlOutcomeTargetLink outcomeTargetLink = new HtmlOutcomeTargetLink();
outcomeTargetLink.putAttribute("outcome", "/scaffold/" +
resource.getName() + "/search");
outcomeTargetLink.setValue(StringUtils.uncamelCase(resource.getName()));
HtmlTag listItem = new HtmlTag("li");
listItem.getChildren().add(outcomeTargetLink);
unorderedList.getChildren().add(listItem);
}
So I am relying on .listResources to return a consistent ordering. It
returns a List, not a Set, so I thought it would be a defined ordering? And
in all my
tests it seemed to come out alphabetically.
But I guess I am wrong and I apologise. Lincoln can you confirm and wrap
this code in something to sort the list?
Regards,
Richard.
P.S. Marius thanks for debugging!
On 14/02/2012 8:03 AM, Marius Bogoevici wrote:
>
> The main reason behind the different build experiences seems to be
that the navigation content in FacesScaffoldTest is not generated
consistently
> across systems:
>
> - the test expects:
>
> [code]
> <ul>
> <li>
> <h:link outcome="/scaffold/customer/search"
value="Customer"/>
> </li>
> <li>
> <h:link outcome="/scaffold/employer/search"
value="Employer"/>
> </li>
> [/code]
>
> - on failure, the scaffold generates:
>
> [code]
> <ul>
> <li>
> <h:link outcome="/scaffold/employer/search"
value="Employer"/>
> </li>
> <li>
> <h:link outcome="/scaffold/customer/search"
value="Customer"/>
> </li>
> [/code]
>
> For some reason, the links are not generated always in the same
order, but I am not sure what part in the scaffold or metawidget is
responsible for that.
>
>
>
>
> On 12-02-13 01:23 PM, Ryan Bradley wrote:
>> Looks like I'm getting the same errors that Marius was. I nuked my
Maven repository, ran a 'mvn clean install', and the following tests failed:
>>
>>
testGenerateManyToOneEntity(org.jboss.forge.scaffold.faces.FacesScaffoldTest)
>>
testGenerateOneToManyEntity(org.jboss.forge.scaffold.faces.FacesScaffoldTest)
>>
>> I've put the stack trace in a Pastebin:
http://pastebin.com/qXafYDg4.
>>
>> Cheers,
>> Ryan
>>
>> P.S. I am running 64-bit Fedora 15 on my machine.
>>
>> On 02/13/2012 11:18 AM, Koen Aers wrote:
>>> Yes it does here…
>>> I only tried on OSX though.
>>>
>>> Cheers,
>>> Koen
>>>
>>> Op 13-feb.-2012, om 17:06 heeft Lincoln Baxter, III het volgende
geschreven:
>>>
>>>> So the build is working for folks? I nuked my repo and build
succeeded :)
>>>>
>>>> ~Lincoln
>>>>
>>>> On Mon, Feb 13, 2012 at 3:19 AM, Koen Aers
<koen.aers(a)gmail.com<mailto:
koen.aers(a)gmail.com>> wrote:
>>>>
>>>> Nuking the Maven repo also did the trick on my machine.
>>>>
>>>> Thanks Marius!
>>>>
>>>> Cheers,
>>>> Koen
>>>>
>>>> Op 13-feb.-2012, om 02:08 heeft Marius Bogoevici het volgende
geschreven:
>>>>
>>>>> My build failed consistently in
FacesScaffoldTest.testGenerateOneToManyEntity() and
FacesScaffoldTest.testGenerateOneToManyEntity until I nuked
>>>>> my local Maven repo. Then it didn't.
>>>>>
>>>>> On 12-02-10 3:24 PM, Lincoln Baxter, III wrote:
>>>>>> Just a sanity check. Thanks!
>>>>>>
>>>>>>
https://github.com/forge/core
>>>>>>
>>>>>> --
>>>>>> Lincoln Baxter, III
>>>>>>
http://ocpsoft.com <
http://ocpsoft.com/>
>>>>>>
http://scrumshark.com <
http://scrumshark.com/>
>>>>>> "Keep it Simple"
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> forge-dev mailing list
>>>>>> forge-dev(a)lists.jboss.org
<mailto:forge-dev@lists.jboss.org>
>>>>>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev(a)lists.jboss.org
<mailto:forge-dev@lists.jboss.org>
>>>>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
>>>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lincoln Baxter, III
>>>>
http://ocpsoft.com <
http://ocpsoft.com/>
>>>>
http://scrumshark.com <
http://scrumshark.com/>
>>>> "Keep it Simple"
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
>>>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597