[jbosstools-dev] AS Test Suite failure fix?

[Rob Stryker]

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
>