Loading ...
Sorry, an error occurred while loading the content.
 

Hudson build is still unstable: PCGen Trunk #484

Expand Messages
  • hudson@ci.pcgen.org
    See
    Message 1 of 20 , Sep 27, 2010
    • hudson@ci.pcgen.org
      See
      Message 2 of 20 , Sep 27, 2010
      • hudson@ci.pcgen.org
        See
        Message 3 of 20 , Sep 27, 2010
        • hudson@ci.pcgen.org
          See
          Message 4 of 20 , Sep 28, 2010
          • hudson@ci.pcgen.org
            See
            Message 5 of 20 , Sep 28, 2010
            • hudson@ci.pcgen.org
              See
              Message 6 of 20 , Sep 29, 2010
              • hudson@ci.pcgen.org
                See
                Message 7 of 20 , Sep 29, 2010
                • James Dempsey
                  Hi, Just an update on these continual messages. The failing unit tests are caused by all tests running in the same virtual machine. I have confirmed this
                  Message 8 of 20 , Sep 29, 2010
                    Hi,

                    Just an update on these continual messages. The failing unit tests are
                    caused by all tests running in the same virtual machine. I have
                    confirmed this locally by changing the fork mode from once to perTest
                    and noting that everything passed, while I had the same failures and
                    more before the change. The down side is that the change increased the
                    run time for the build from 2:49 to 18:57 on my machine!

                    I'll check in the temporary fix for now to stop the messages but we'll
                    have to find a way around the test errors and get the execution time
                    back down to something sane.

                    Cheers,
                    James.

                    On 29/09/2010 1:49 PM hudson@... wrote
                    > See<http://ci.pcgen.org/hudson/job/PCGen%20Trunk/changes>
                  • hudson@ci.pcgen.org
                    See
                    Message 9 of 20 , Sep 29, 2010
                    • Tom Parker
                      Please open a bug against Architecture... the problem is a design for test issue we should address. It s not overly complicated to fix, just will require
                      Message 10 of 20 , Sep 29, 2010
                        Please open a bug against Architecture... the problem is a "design for test" issue we should address. It's not overly complicated to fix, just will require some different start-up methodology for the facets.

                        Short version: The facets normally can be built independently of each other and not pollute (since the listeners are stored within the facet). There is one exception to this - CDOMObjectConsolidationFacet and CDOMObjectSourceFacet share a (singleton) CDOMObjectBridge. If the CDOMObjectBridge is modified, then it is shared object that is modified.

                        We need to turn the singleton into a normal object, let Spring force the singleton behavior in a runtime environment, which it's good at... and load the appropriate object into CDOMObjectBridge users in a test environment. That will allow non-Spring construction to not pollute between tests. It's not that hard, just requires some cleanup in the current code.

                        TP.
                        --
                        Tom Parker


                        --- On Wed, 9/29/10, James Dempsey <jdempsey@...> wrote:

                        > From: James Dempsey <jdempsey@...>
                        > Subject: Re: [pcgen_developers] Hudson build is still unstable: PCGen Trunk #488
                        > To: pcgen_developers@yahoogroups.com
                        > Date: Wednesday, September 29, 2010, 6:39 PM
                        >   Hi,
                        >
                        > Just an update on these continual messages. The failing
                        > unit tests are
                        > caused by all tests running in the same virtual machine. I
                        > have
                        > confirmed this locally by changing the fork mode from once
                        > to perTest
                        > and noting that everything passed, while I had the same
                        > failures and
                        > more before the change. The down side is that the change
                        > increased the
                        > run time for the build from 2:49 to 18:57 on my machine!
                        >
                        > I'll check in the temporary fix for now to stop the
                        > messages but we'll
                        > have to find a way around the test errors and get the
                        > execution time
                        > back down to something sane.
                        >
                        > Cheers,
                        > James.
                        >
                        > On 29/09/2010 1:49 PM hudson@...
                        > wrote
                        > > See<http://ci.pcgen.org/hudson/job/PCGen%20Trunk/changes>
                        >
                        >
                        >
                        > ------------------------------------
                        >
                        > Yahoo! Groups Links
                        >
                        >
                        >     pcgen_developers-fullfeatured@yahoogroups.com
                        >
                        >
                        >
                      • James Dempsey
                        Hi, I ve raised CODE-233 Tests fail when run in single VM Cheers, James. On
                        Message 11 of 20 , Oct 1, 2010
                          Hi,

                          I've raised CODE-233 Tests fail when run in single VM

                          Cheers,
                          James.

                          On 30/09/2010 10:21 AM Tom Parker wrote
                          Please open a bug against Architecture... the problem is a "design for test" issue we should address. It's not overly complicated to fix, just will require some different start-up methodology for the facets.
                          
                          Short version: The facets normally can be built independently of each other and not pollute (since the listeners are stored within the facet).  There is one exception to this - CDOMObjectConsolidationFacet and CDOMObjectSourceFacet share a (singleton) CDOMObjectBridge.  If the CDOMObjectBridge is modified, then it is shared object that is modified.
                          
                          We need to turn the singleton into a normal object, let Spring force the singleton behavior in a runtime environment, which it's good at... and load the appropriate object into CDOMObjectBridge users in a test environment.  That will allow non-Spring construction to not pollute between tests.  It's not that hard, just requires some cleanup in the current code.
                          
                          TP.
                          --
                          Tom Parker
                          
                          
                          --- On Wed, 9/29/10, James Dempsey <jdempsey@...> wrote:
                          
                          
                          From: James Dempsey <jdempsey@...>
                          Subject: Re: [pcgen_developers] Hudson build is still unstable: PCGen Trunk #488
                          To: pcgen_developers@yahoogroups.com
                          Date: Wednesday, September 29, 2010, 6:39 PM
                            Hi,
                          
                          Just an update on these continual messages. The failing
                          unit tests are 
                          caused by all tests running in the same virtual machine. I
                          have 
                          confirmed this locally by changing the fork mode from once
                          to perTest 
                          and noting that everything passed, while I had the same
                          failures and 
                          more before the change. The down side is that the change
                          increased the 
                          run time for the build from 2:49 to 18:57 on my machine!
                          
                          I'll check in the temporary fix for now to stop the
                          messages but we'll 
                          have to find a way around the test errors and get the
                          execution time 
                          back down to something sane.
                          
                          Cheers,
                          James.
                          
                          On 29/09/2010 1:49 PM hudson@...
                          wrote
                          
                          See<http://ci.pcgen.org/hudson/job/PCGen%20Trunk/changes>
                          


                        Your message has been successfully submitted and would be delivered to recipients shortly.