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(a)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(a)lists.jboss.org
>>>https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>