[jbosstools-dev] AS Test Suite failure fix?

[Max Rydahl Andersen]

Rob - just provide the bugzilla where the change was made.

wtp's publishing logic is a mixed bag - sad to see they hardcode it...hope it wont expand.

/max
On Sat, Mar 23, 2013 at 01:30:11AM +0800, Rob Stryker wrote:
>Actually, my honest opinion upon reflection is that the NEW behavior 
>is buggy, as even if a user creates a fileset which INCLUDES .project 
>intentionally, it will be filtered out. However, I didn't write my 
>unit test until AFTER the behavior in wtp was changed, so the change 
>in behavior was never caught.
>
>I guess I could open a NEW bugzilla documenting a bug in wtp in that 
>they filter out specifically included files... But so far .project is 
>the only meta-file specifically ignored by wtp and it is unlikely 
>users would specifically want a .project file published in their war 
>or ejb artifact.
>
>Remember, the user is creating a fileset with an includes / excludes 
>pattern and base-dir. Most users will not be so careless in this 
>regard and will probably add .project to the excludes list anyway as 
>in past behavior. The bug which NOW exists is a user specifically 
>desiring a .project file to be added will be 100% unable to do so ;)
>
>I'm really not sure how to proceed on this issue with that in mind.
>
>
>
>On 03/21/2013 01:11 PM, Nick Boldt wrote:
>>Is there a bugzilla to which I can link from https://www.jboss.org/tools/download/installation/update_4_0#installon420421 
>>?
>>
>>If so, please document it in this JIRA:
>>
>>https://issues.jboss.org/browse/JBIDE-13830
>>
>>On 03/20/2013 02:55 AM, Max Rydahl Andersen wrote:
>>>
>>>On Tue, Mar 19, 2013 at 10:33:37PM -0400, Nick Boldt wrote:
>>>>Does it strike no one as a problem that the tests pass against Juno SR2
>>>>but fail against Juno R? Surely they should pass against any Juno on
>>>>which we run the tests, since we can't guarantee that a user 
>>>>will run on
>>>>a particular version.
>>>
>>>The bug found a behaviorial change in WTP 3.3.0 to 3.3.1.
>>>
>>>This change is for the better (removes any weird eclipse only artifacts
>>>in deployments),
>>>but has the big problem of that we will see different behaviors where we
>>>run.
>>>
>>>But this is kinda expected since a micro release is a place where
>>>bugfixes are done and
>>>thus you will see different behaviors.
>>>
>>>To make the test pass on both versions the test will need to lookup
>>>which bundle version it
>>>us running in - but then you'll have this test pass on SR0 even though
>>>SR0 actually have this
>>>bug which was fixed in SR1+.
>>>
>>>I think the best thing is that these or at least one of tests have their
>>>message updated to say something like:
>>>assertEquals(".project files should not be included. Broken in SR0,
>>>fixed in SR1", ...) or similar allowing
>>>to actually see it when tests fails what/why this changed.
>>>
>>>>Or will we document this like we did for JBT 3.3 [1], to at least
>>>>ENCOURAGE users to use SR2 instead of R or SR1?
>>>
>>>Yes, we should always do that anyway (i.e. recommend to use the latest
>>>Eclipse we've tested against)
>>>
>>>What is/was bad aobut this whole case is that it took so long to realize
>>>since this issue
>>>must have been failing for months on SR0 :(
>>>
>>>/max
>>>
>>>>[1]
>>>>https://www.jboss.org/tools/download/installation/update_3_3#installon370371
>>>>
>>>>
>>>>
>>>>On 03/19/2013 02:27 PM, Denis Golovin wrote:
>>>>>Hudson is actually running build agaains minimum TP, because it has no
>>>>>-Dmaximum switch in maven command line.
>>>>>
>>>>>Denis
>>>>>
>>>>>On 03/19/2013 02:10 AM, Rob Stryker wrote:
>>>>>
>>>>>>https://github.com/jbosstools/jbosstools-server/commit/b3672b46e4df710741c39ff77733246485547c8c
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Denis:
>>>>>>
>>>>>>I realize the error in the test suite was that the .project file is
>>>>>>now included, whereas it was not included in the past. Why do you
>>>>>>think the proper solution to this change in behavior was to simply
>>>>>>change the expected count? That seems like a very bad fix.
>>>>>>
>>>>>>If something upstream has changed, we should discover what it is
>>>>>>before simply changing the expected count in the unit test. Clearly
>>>>>>these tests used to pass, and started failing after the update to m5.
>>>>>>Shouldn't we try to discover what exactly changed here?
>>>>>>
>>>>>>- Rob
>>>>>
>>>>>_______________________________________________
>>>>>jbosstools-dev mailing list
>>>>>jbosstools-dev at lists.jboss.org
>>>>>https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>
>>>>
>>>>-- 
>>>>Nick Boldt :: JBoss by Red Hat
>>>>Productization Lead :: JBoss Tools & Dev Studio
>>>>http://nick.divbyzero.com
>>>>_______________________________________________
>>>>jbosstools-dev mailing list
>>>>jbosstools-dev at lists.jboss.org
>>>>https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>