You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Babak Vahdat <ba...@swissonline.ch> on 2012/08/15 11:32:18 UTC
About the camel-ftp unit-tests which are broken
Hi
Just by chance I realized that a bunch of camel-ftp unit-tests are broken.
The reason is that the path prefix usage of FTP_ROOT_DIR has been only
removed while sending through the ProducerTemplate but *not* while asserting
on a condition, here an example:
https://svn.apache.org/repos/asf/camel/trunk/components/camel-ftp/src/test/java/org/apache/camel/component/file/remote/sftp/SftpSimpleProduceTest.java
The corresponding revision:
http://svn.apache.org/viewvc?view=revision&revision=1206371
@Hadrian: What was your idea to "only produce output in the target
directory"? What would be the benefit of it? Would you have time to resolve
these broken tests? If not I could take this over. I think we should also
backport the fix both to the 2.10.x & 2.9.x branches as well.
@Claus: Do you maybe remember what the problem in 2010 exactly was at the
time you had to @Ignore("Disabled due CI servers fails on full build running
with these tests") by bunch of these tests. Shouldn't we maybe try to
"reactivate" these tests to see how Jenkins would behave *today* so that
we've some regression-tests we could count on, as it was just a matter of
luck that I realized this.
I know, build time on CI-Server will still take longer but I think better to
have a slower train than a broken one.
Thoughts?
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: About the camel-ftp unit-tests which are broken
Posted by Christian Müller <ch...@gmail.com>.
Thanks for looking into it!
Sent from a mobile device
Am 17.08.2012 22:36 schrieb "Babak Vahdat" <ba...@swissonline.ch>:
> Hi
>
> O.K. this's fixed now, as well there're 14 SFTP tests which are re-enabled
> so that we can now count on their regression-check.
>
> https://issues.apache.org/jira/browse/CAMEL-5514
>
> Babak
>
>
> Babak Vahdat wrote
> >
> > Am 16.08.12 15:32 schrieb "Hadrian Zbarcea" unter <hzbarcea@>:
> >
> >>@Babak,
> >>
> >>Why produce output only under target? Only to allow `mvn clean` to clean
> >>up properly. Maven conventions...
> >
> > I don't really get your point here! "mvn clean" would *still* clean up
> > properly even if the tests would create the file under the path
> > FTP_ROOT_DIR which is "target/res/home" and not directly inside the
> > "target" folder. Currently it's even worse, as an example try to run the
> > first test method of SftpSimpleProduceTest which is the method
> > testSftpSimpleProduce and then look where "hello.txt" get's generated! It
> > will get generated at the same level of the target folder!!! Then
> > subversion will consider this as an outgoing change the next time you
> > would sync with the repo. The reason for this is pretty clear as you
> > changed the line:
> >
> > template.sendBodyAndHeader("sftp://localhost:" + getPort() + "/" +
> > FTP_ROOT_DIR + "?username=admin&password=admin", "Hello World",
> > Exchange.FILE_NAME, "hello.txt");
> >
> > To:
> >
> >
> > template.sendBodyAndHeader("sftp://localhost:" + getPort() +
> > "/?username=admin&password=admin", "Hello World", Exchange.FILE_NAME,
> > "hello.txt");
> >
> >>Same applies to log files in other
> >>components. I am not sure I cleaned up in all the places.
> >>
> >>I noticed that too. The tests were @Ignore'd before my changes and I
> >>don't think the reason for failures is only what you mentioned.
> >
> > This's not true!
> >
> > Yes the tests were *already* @Ignore'd before you modified them and that
> > is exactly the root cause of the problem as otherwise we had realized
> this
> > much sooner (e.g. by next build on CI-Server). As an example consider
> > *another* test class: SftpSimpleProduceNotStepwiseTest where you're the
> > last modifier of it (well, Daniel changed some svn:props after you but
> > that's not relevant for this discussion). Now enable and run the tests,
> > all 3 will fail, take the previous revision *before* your change, they
> > will all pass!
> >
> > Just to make sure you don't misunderstand me: my aim is NOT to accuse you
> > or whatnot BUT only to FIX the existing problem creeping after your
> > revision. As we all know no body is perfect and we do all make mistakes
> > (including myself). Anyway, I'll raise a JIRA and take over this to fix
> > them all.
> >
> > Thanks for your reply and attention.
> >
> > Babak
> >
> >> As the
> >>setUp() did take place, directories were created in the wrong place.
> >>
> >>I hope this helps,
> >>Hadrian
> >>
> >>
> >>
> >>On 08/16/2012 06:14 AM, Babak Vahdat wrote:
> >>> Just for the sake of completeness:
> >>>
> >>> The broken unit-tests being mentioned here are all "@Ignore"ed, so
> >>>you've to
> >>> enable them to see that they're really broken. :-)
> >>>
> >>> Babak
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>>
> http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-ar
> >>>e-broken-tp5717372p5717495.html
> >>> Sent from the Camel Development mailing list archive at Nabble.com.
> >>>
> >
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372p5717640.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
Re: About the camel-ftp unit-tests which are broken
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Aug 20, 2012 at 2:00 PM, Babak Vahdat
<ba...@swissonline.ch> wrote:
> Hi
>
> There was an old revision not being backported to the 2.9.x branch causing
> the SFTP tests to fail on this branch after I re-enabled them.
>
> After backporting this revision all the tests did pass on this branch as
> well:
>
> https://builds.apache.org/job/Camel.2.9.x.fulltest/org.apache.camel$camel-ftp/128/testReport/
>
Nice work. Great to know it all tests fine on all our branches now.
> Babak
>
>
> Willem.Jiang wrote
>>
>> Hi Babak,
>>
>> Camel.2.9.x.fulltest[1] are failed with this change, can you have a look
>> at it?
>>
>> [1]
>> https://builds.apache.org/job/Camel.2.9.x.fulltest/lastBuild/#showFailuresLink
>>
>> --
>> Willem Jiang
>>
>> FuseSource
>> Web: http://www.fusesource.com (http://www.fusesource.com/)
>> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
>> (English)
>> http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
>> Twitter: willemjiang
>> Weibo: willemjiang
>>
>>
>>
>>
>>
>> On Saturday, August 18, 2012 at 4:36 AM, Babak Vahdat wrote:
>>
>>> Hi
>>>
>>> O.K. this's fixed now, as well there're 14 SFTP tests which are
>>> re-enabled
>>> so that we can now count on their regression-check.
>>>
>>> https://issues.apache.org/jira/browse/CAMEL-5514
>>>
>>> Babak
>>>
>>>
>>> Babak Vahdat wrote
>>> >
>>> > Am 16.08.12 15:32 schrieb "Hadrian Zbarcea" unter <hzbarcea@>:
>>> >
>>> > > @Babak,
>>> > >
>>> > > Why produce output only under target? Only to allow `mvn clean` to
>>> clean
>>> > > up properly. Maven conventions...
>>> >
>>> >
>>> >
>>> > I don't really get your point here! "mvn clean" would *still* clean up
>>> > properly even if the tests would create the file under the path
>>> > FTP_ROOT_DIR which is "target/res/home" and not directly inside the
>>> > "target" folder. Currently it's even worse, as an example try to run
>>> the
>>> > first test method of SftpSimpleProduceTest which is the method
>>> > testSftpSimpleProduce and then look where "hello.txt" get's generated!
>>> It
>>> > will get generated at the same level of the target folder!!! Then
>>> > subversion will consider this as an outgoing change the next time you
>>> > would sync with the repo. The reason for this is pretty clear as you
>>> > changed the line:
>>> >
>>> > template.sendBodyAndHeader("sftp://localhost:" + getPort() + "/" +
>>> > FTP_ROOT_DIR + "?username=admin&password=admin", "Hello World",
>>> > Exchange.FILE_NAME, "hello.txt");
>>> >
>>> > To:
>>> >
>>> >
>>> > template.sendBodyAndHeader("sftp://localhost:" + getPort() +
>>> > "/?username=admin&password=admin", "Hello World", Exchange.FILE_NAME,
>>> > "hello.txt");
>>> >
>>> > > Same applies to log files in other
>>> > > components. I am not sure I cleaned up in all the places.
>>> > >
>>> > > I noticed that too. The tests were @Ignore'd before my changes and I
>>> > > don't think the reason for failures is only what you mentioned.
>>> >
>>> >
>>> >
>>> > This's not true!
>>> >
>>> > Yes the tests were *already* @Ignore'd before you modified them and
>>> that
>>> > is exactly the root cause of the problem as otherwise we had realized
>>> this
>>> > much sooner (e.g. by next build on CI-Server). As an example consider
>>> > *another* test class: SftpSimpleProduceNotStepwiseTest where you're the
>>> > last modifier of it (well, Daniel changed some svn:props after you but
>>> > that's not relevant for this discussion). Now enable and run the tests,
>>> > all 3 will fail, take the previous revision *before* your change, they
>>> > will all pass!
>>> >
>>> > Just to make sure you don't misunderstand me: my aim is NOT to accuse
>>> you
>>> > or whatnot BUT only to FIX the existing problem creeping after your
>>> > revision. As we all know no body is perfect and we do all make mistakes
>>> > (including myself). Anyway, I'll raise a JIRA and take over this to fix
>>> > them all.
>>> >
>>> > Thanks for your reply and attention.
>>> >
>>> > Babak
>>> >
>>> > > As the
>>> > > setUp() did take place, directories were created in the wrong place.
>>> > >
>>> > > I hope this helps,
>>> > > Hadrian
>>> > >
>>> > >
>>> > >
>>> > > On 08/16/2012 06:14 AM, Babak Vahdat wrote:
>>> > > > Just for the sake of completeness:
>>> > > >
>>> > > > The broken unit-tests being mentioned here are all "@Ignore"ed, so
>>> > > > you've to
>>> > > > enable them to see that they're really broken. :-)
>>> > > >
>>> > > > Babak
>>> > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > View this message in context:
>>> > > >
>>> http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-ar
>>> > > > e-broken-tp5717372p5717495.html
>>> > > > Sent from the Camel Development mailing list archive at Nabble.com
>>> (http://Nabble.com).
>>> > >
>>> >
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372p5717640.html
>>> Sent from the Camel Development mailing list archive at Nabble.com
>>> (http://Nabble.com).
>>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372p5717707.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: About the camel-ftp unit-tests which are broken
Posted by Babak Vahdat <ba...@swissonline.ch>.
Hi
There was an old revision not being backported to the 2.9.x branch causing
the SFTP tests to fail on this branch after I re-enabled them.
After backporting this revision all the tests did pass on this branch as
well:
https://builds.apache.org/job/Camel.2.9.x.fulltest/org.apache.camel$camel-ftp/128/testReport/
Babak
Willem.Jiang wrote
>
> Hi Babak,
>
> Camel.2.9.x.fulltest[1] are failed with this change, can you have a look
> at it?
>
> [1]
> https://builds.apache.org/job/Camel.2.9.x.fulltest/lastBuild/#showFailuresLink
>
> --
> Willem Jiang
>
> FuseSource
> Web: http://www.fusesource.com (http://www.fusesource.com/)
> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
> (English)
> http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
>
>
>
>
> On Saturday, August 18, 2012 at 4:36 AM, Babak Vahdat wrote:
>
>> Hi
>>
>> O.K. this's fixed now, as well there're 14 SFTP tests which are
>> re-enabled
>> so that we can now count on their regression-check.
>>
>> https://issues.apache.org/jira/browse/CAMEL-5514
>>
>> Babak
>>
>>
>> Babak Vahdat wrote
>> >
>> > Am 16.08.12 15:32 schrieb "Hadrian Zbarcea" unter <hzbarcea@>:
>> >
>> > > @Babak,
>> > >
>> > > Why produce output only under target? Only to allow `mvn clean` to
>> clean
>> > > up properly. Maven conventions...
>> >
>> >
>> >
>> > I don't really get your point here! "mvn clean" would *still* clean up
>> > properly even if the tests would create the file under the path
>> > FTP_ROOT_DIR which is "target/res/home" and not directly inside the
>> > "target" folder. Currently it's even worse, as an example try to run
>> the
>> > first test method of SftpSimpleProduceTest which is the method
>> > testSftpSimpleProduce and then look where "hello.txt" get's generated!
>> It
>> > will get generated at the same level of the target folder!!! Then
>> > subversion will consider this as an outgoing change the next time you
>> > would sync with the repo. The reason for this is pretty clear as you
>> > changed the line:
>> >
>> > template.sendBodyAndHeader("sftp://localhost:" + getPort() + "/" +
>> > FTP_ROOT_DIR + "?username=admin&password=admin", "Hello World",
>> > Exchange.FILE_NAME, "hello.txt");
>> >
>> > To:
>> >
>> >
>> > template.sendBodyAndHeader("sftp://localhost:" + getPort() +
>> > "/?username=admin&password=admin", "Hello World", Exchange.FILE_NAME,
>> > "hello.txt");
>> >
>> > > Same applies to log files in other
>> > > components. I am not sure I cleaned up in all the places.
>> > >
>> > > I noticed that too. The tests were @Ignore'd before my changes and I
>> > > don't think the reason for failures is only what you mentioned.
>> >
>> >
>> >
>> > This's not true!
>> >
>> > Yes the tests were *already* @Ignore'd before you modified them and
>> that
>> > is exactly the root cause of the problem as otherwise we had realized
>> this
>> > much sooner (e.g. by next build on CI-Server). As an example consider
>> > *another* test class: SftpSimpleProduceNotStepwiseTest where you're the
>> > last modifier of it (well, Daniel changed some svn:props after you but
>> > that's not relevant for this discussion). Now enable and run the tests,
>> > all 3 will fail, take the previous revision *before* your change, they
>> > will all pass!
>> >
>> > Just to make sure you don't misunderstand me: my aim is NOT to accuse
>> you
>> > or whatnot BUT only to FIX the existing problem creeping after your
>> > revision. As we all know no body is perfect and we do all make mistakes
>> > (including myself). Anyway, I'll raise a JIRA and take over this to fix
>> > them all.
>> >
>> > Thanks for your reply and attention.
>> >
>> > Babak
>> >
>> > > As the
>> > > setUp() did take place, directories were created in the wrong place.
>> > >
>> > > I hope this helps,
>> > > Hadrian
>> > >
>> > >
>> > >
>> > > On 08/16/2012 06:14 AM, Babak Vahdat wrote:
>> > > > Just for the sake of completeness:
>> > > >
>> > > > The broken unit-tests being mentioned here are all "@Ignore"ed, so
>> > > > you've to
>> > > > enable them to see that they're really broken. :-)
>> > > >
>> > > > Babak
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > View this message in context:
>> > > >
>> http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-ar
>> > > > e-broken-tp5717372p5717495.html
>> > > > Sent from the Camel Development mailing list archive at Nabble.com
>> (http://Nabble.com).
>> > >
>> >
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372p5717640.html
>> Sent from the Camel Development mailing list archive at Nabble.com
>> (http://Nabble.com).
>
--
View this message in context: http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372p5717707.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: About the camel-ftp unit-tests which are broken
Posted by Willem jiang <wi...@gmail.com>.
Hi Babak,
Camel.2.9.x.fulltest[1] are failed with this change, can you have a look at it?
[1] https://builds.apache.org/job/Camel.2.9.x.fulltest/lastBuild/#showFailuresLink
--
Willem Jiang
FuseSource
Web: http://www.fusesource.com (http://www.fusesource.com/)
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: willemjiang
On Saturday, August 18, 2012 at 4:36 AM, Babak Vahdat wrote:
> Hi
>
> O.K. this's fixed now, as well there're 14 SFTP tests which are re-enabled
> so that we can now count on their regression-check.
>
> https://issues.apache.org/jira/browse/CAMEL-5514
>
> Babak
>
>
> Babak Vahdat wrote
> >
> > Am 16.08.12 15:32 schrieb "Hadrian Zbarcea" unter <hzbarcea@>:
> >
> > > @Babak,
> > >
> > > Why produce output only under target? Only to allow `mvn clean` to clean
> > > up properly. Maven conventions...
> >
> >
> >
> > I don't really get your point here! "mvn clean" would *still* clean up
> > properly even if the tests would create the file under the path
> > FTP_ROOT_DIR which is "target/res/home" and not directly inside the
> > "target" folder. Currently it's even worse, as an example try to run the
> > first test method of SftpSimpleProduceTest which is the method
> > testSftpSimpleProduce and then look where "hello.txt" get's generated! It
> > will get generated at the same level of the target folder!!! Then
> > subversion will consider this as an outgoing change the next time you
> > would sync with the repo. The reason for this is pretty clear as you
> > changed the line:
> >
> > template.sendBodyAndHeader("sftp://localhost:" + getPort() + "/" +
> > FTP_ROOT_DIR + "?username=admin&password=admin", "Hello World",
> > Exchange.FILE_NAME, "hello.txt");
> >
> > To:
> >
> >
> > template.sendBodyAndHeader("sftp://localhost:" + getPort() +
> > "/?username=admin&password=admin", "Hello World", Exchange.FILE_NAME,
> > "hello.txt");
> >
> > > Same applies to log files in other
> > > components. I am not sure I cleaned up in all the places.
> > >
> > > I noticed that too. The tests were @Ignore'd before my changes and I
> > > don't think the reason for failures is only what you mentioned.
> >
> >
> >
> > This's not true!
> >
> > Yes the tests were *already* @Ignore'd before you modified them and that
> > is exactly the root cause of the problem as otherwise we had realized this
> > much sooner (e.g. by next build on CI-Server). As an example consider
> > *another* test class: SftpSimpleProduceNotStepwiseTest where you're the
> > last modifier of it (well, Daniel changed some svn:props after you but
> > that's not relevant for this discussion). Now enable and run the tests,
> > all 3 will fail, take the previous revision *before* your change, they
> > will all pass!
> >
> > Just to make sure you don't misunderstand me: my aim is NOT to accuse you
> > or whatnot BUT only to FIX the existing problem creeping after your
> > revision. As we all know no body is perfect and we do all make mistakes
> > (including myself). Anyway, I'll raise a JIRA and take over this to fix
> > them all.
> >
> > Thanks for your reply and attention.
> >
> > Babak
> >
> > > As the
> > > setUp() did take place, directories were created in the wrong place.
> > >
> > > I hope this helps,
> > > Hadrian
> > >
> > >
> > >
> > > On 08/16/2012 06:14 AM, Babak Vahdat wrote:
> > > > Just for the sake of completeness:
> > > >
> > > > The broken unit-tests being mentioned here are all "@Ignore"ed, so
> > > > you've to
> > > > enable them to see that they're really broken. :-)
> > > >
> > > > Babak
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > > http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-ar
> > > > e-broken-tp5717372p5717495.html
> > > > Sent from the Camel Development mailing list archive at Nabble.com (http://Nabble.com).
> > >
> >
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372p5717640.html
> Sent from the Camel Development mailing list archive at Nabble.com (http://Nabble.com).
Re: About the camel-ftp unit-tests which are broken
Posted by Babak Vahdat <ba...@swissonline.ch>.
Hi
O.K. this's fixed now, as well there're 14 SFTP tests which are re-enabled
so that we can now count on their regression-check.
https://issues.apache.org/jira/browse/CAMEL-5514
Babak
Babak Vahdat wrote
>
> Am 16.08.12 15:32 schrieb "Hadrian Zbarcea" unter <hzbarcea@>:
>
>>@Babak,
>>
>>Why produce output only under target? Only to allow `mvn clean` to clean
>>up properly. Maven conventions...
>
> I don't really get your point here! "mvn clean" would *still* clean up
> properly even if the tests would create the file under the path
> FTP_ROOT_DIR which is "target/res/home" and not directly inside the
> "target" folder. Currently it's even worse, as an example try to run the
> first test method of SftpSimpleProduceTest which is the method
> testSftpSimpleProduce and then look where "hello.txt" get's generated! It
> will get generated at the same level of the target folder!!! Then
> subversion will consider this as an outgoing change the next time you
> would sync with the repo. The reason for this is pretty clear as you
> changed the line:
>
> template.sendBodyAndHeader("sftp://localhost:" + getPort() + "/" +
> FTP_ROOT_DIR + "?username=admin&password=admin", "Hello World",
> Exchange.FILE_NAME, "hello.txt");
>
> To:
>
>
> template.sendBodyAndHeader("sftp://localhost:" + getPort() +
> "/?username=admin&password=admin", "Hello World", Exchange.FILE_NAME,
> "hello.txt");
>
>>Same applies to log files in other
>>components. I am not sure I cleaned up in all the places.
>>
>>I noticed that too. The tests were @Ignore'd before my changes and I
>>don't think the reason for failures is only what you mentioned.
>
> This's not true!
>
> Yes the tests were *already* @Ignore'd before you modified them and that
> is exactly the root cause of the problem as otherwise we had realized this
> much sooner (e.g. by next build on CI-Server). As an example consider
> *another* test class: SftpSimpleProduceNotStepwiseTest where you're the
> last modifier of it (well, Daniel changed some svn:props after you but
> that's not relevant for this discussion). Now enable and run the tests,
> all 3 will fail, take the previous revision *before* your change, they
> will all pass!
>
> Just to make sure you don't misunderstand me: my aim is NOT to accuse you
> or whatnot BUT only to FIX the existing problem creeping after your
> revision. As we all know no body is perfect and we do all make mistakes
> (including myself). Anyway, I'll raise a JIRA and take over this to fix
> them all.
>
> Thanks for your reply and attention.
>
> Babak
>
>> As the
>>setUp() did take place, directories were created in the wrong place.
>>
>>I hope this helps,
>>Hadrian
>>
>>
>>
>>On 08/16/2012 06:14 AM, Babak Vahdat wrote:
>>> Just for the sake of completeness:
>>>
>>> The broken unit-tests being mentioned here are all "@Ignore"ed, so
>>>you've to
>>> enable them to see that they're really broken. :-)
>>>
>>> Babak
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>>http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-ar
>>>e-broken-tp5717372p5717495.html
>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>
>
--
View this message in context: http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372p5717640.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: About the camel-ftp unit-tests which are broken
Posted by Babak Vahdat <ba...@swissonline.ch>.
Am 16.08.12 15:32 schrieb "Hadrian Zbarcea" unter <hz...@gmail.com>:
>@Babak,
>
>Why produce output only under target? Only to allow `mvn clean` to clean
>up properly. Maven conventions...
I don't really get your point here! "mvn clean" would *still* clean up
properly even if the tests would create the file under the path
FTP_ROOT_DIR which is "target/res/home" and not directly inside the
"target" folder. Currently it's even worse, as an example try to run the
first test method of SftpSimpleProduceTest which is the method
testSftpSimpleProduce and then look where "hello.txt" get's generated! It
will get generated at the same level of the target folder!!! Then
subversion will consider this as an outgoing change the next time you
would sync with the repo. The reason for this is pretty clear as you
changed the line:
template.sendBodyAndHeader("sftp://localhost:" + getPort() + "/" +
FTP_ROOT_DIR + "?username=admin&password=admin", "Hello World",
Exchange.FILE_NAME, "hello.txt");
To:
template.sendBodyAndHeader("sftp://localhost:" + getPort() +
"/?username=admin&password=admin", "Hello World", Exchange.FILE_NAME,
"hello.txt");
>Same applies to log files in other
>components. I am not sure I cleaned up in all the places.
>
>I noticed that too. The tests were @Ignore'd before my changes and I
>don't think the reason for failures is only what you mentioned.
This's not true!
Yes the tests were *already* @Ignore'd before you modified them and that
is exactly the root cause of the problem as otherwise we had realized this
much sooner (e.g. by next build on CI-Server). As an example consider
*another* test class: SftpSimpleProduceNotStepwiseTest where you're the
last modifier of it (well, Daniel changed some svn:props after you but
that's not relevant for this discussion). Now enable and run the tests,
all 3 will fail, take the previous revision *before* your change, they
will all pass!
Just to make sure you don't misunderstand me: my aim is NOT to accuse you
or whatnot BUT only to FIX the existing problem creeping after your
revision. As we all know no body is perfect and we do all make mistakes
(including myself). Anyway, I'll raise a JIRA and take over this to fix
them all.
Thanks for your reply and attention.
Babak
> As the
>setUp() did take place, directories were created in the wrong place.
>
>I hope this helps,
>Hadrian
>
>
>
>On 08/16/2012 06:14 AM, Babak Vahdat wrote:
>> Just for the sake of completeness:
>>
>> The broken unit-tests being mentioned here are all "@Ignore"ed, so
>>you've to
>> enable them to see that they're really broken. :-)
>>
>> Babak
>>
>>
>>
>> --
>> View this message in context:
>>http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-ar
>>e-broken-tp5717372p5717495.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
Re: About the camel-ftp unit-tests which are broken
Posted by Hadrian Zbarcea <hz...@gmail.com>.
@Babak,
Why produce output only under target? Only to allow `mvn clean` to clean
up properly. Maven conventions... Same applies to log files in other
components. I am not sure I cleaned up in all the places.
I noticed that too. The tests were @Ignore'd before my changes and I
don't think the reason for failures is only what you mentioned. As the
setUp() did take place, directories were created in the wrong place.
I hope this helps,
Hadrian
On 08/16/2012 06:14 AM, Babak Vahdat wrote:
> Just for the sake of completeness:
>
> The broken unit-tests being mentioned here are all "@Ignore"ed, so you've to
> enable them to see that they're really broken. :-)
>
> Babak
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372p5717495.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
Re: About the camel-ftp unit-tests which are broken
Posted by Babak Vahdat <ba...@swissonline.ch>.
Just for the sake of completeness:
The broken unit-tests being mentioned here are all "@Ignore"ed, so you've to
enable them to see that they're really broken. :-)
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/About-the-camel-ftp-unit-tests-which-are-broken-tp5717372p5717495.html
Sent from the Camel Development mailing list archive at Nabble.com.