You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Otto Fowler <ot...@gmail.com> on 2017/02/09 03:39:53 UTC
Build failure on Mac OS X with DS_STORE files
Hi,
I’m trying to build master on Mac OS X, following the instructions from the
site linked in the README.md.
My build is failing because the unit test:
testGetURLsForClasspathWithDirectory
in TestClassLoaderUtils.
It is trying to URLs from a directory, and is expecting 2, but gets 3,
because the DS_STORE is detected and has an url built and returned for it.
The test does not pass in a FileNamesFilter, which could be used to filter
these files out I suppose.
I am wondering if anyone is building successfully on Mac OS X?
Re: Build failure on Mac OS X with DS_STORE files
Posted by Otto Fowler <ot...@gmail.com>.
Thank you guys!
On February 11, 2017 at 16:44:12, Koji Kawamura (ijokarumawak@gmail.com)
wrote:
Thank you, Aldrin!
Koji
On Feb 12, 2017 4:42 AM, "Aldrin Piri" <al...@gmail.com> wrote:
Koji,
Just as a side note, you must perform a separate grunt deploy from the
nifi-site repository for those changes to show up on the site. I took care
of deploying so they would sync and they seem to be live.
--aldrin
On Fri, Feb 10, 2017 at 7:43 PM, Koji Kawamura <ij...@gmail.com>
wrote:
> Thanks Otto, I reviewed pr1497 and merged it.
> For the getting started page, I assume you were referring this quick
start.
> https://nifi.apache.org/quickstart.html
>
> I've modified the Java 8 version description as follows:
> "You need a recent Java 8 (or newer) JDK for the 1.x NiFi line. Older
> Java 8 (such as 1.8.0_31) is known to fail with some unit tests,
> ensure to use the most recent version. The 0.x line works on Java 7 or
> newer."
> https://github.com/apache/nifi-site/blob/master/src/
> pages/markdown/quickstart.md#build-steps
>
> I think it takes a while for the HTML web page gets synchronized.
>
> On Sat, Feb 11, 2017 at 12:17 AM, Otto Fowler <ot...@gmail.com>
> wrote:
> > https://github.com/apache/nifi/pull/1497
> >
> >
> > On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
> > wrote:
> >
> > Thanks! Please ping me when the PR is ready.
> >
> > On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
> > wrote:
> >> Sure - I see what you mean, that is a much better approach.
> >> I will certainly do that.
> >>
> >>
> >>
> >> On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
> >> wrote:
> >>
> >> Hi Otto,
> >>
> >> Thanks for reporting this. I personally haven't encountered this
> >> issue, but as described here [1], when I opened the directory that the
> >> test uses by Mac Finder application, and changed view as icon and move
> >> the icon position, then a .DS_Store file was created.
> >>
> >> I agree with your workaround and I think we should resolve the issue.
> >> By looking at the usage of that method, such as DBCPConnectionPool, or
> >> JoltTransformJSON, those uses file name filter like this:
> >>
> >> (dir, name) -> name != null && name.endsWith(".jar")
> >>
> >> While filtering out specific .DS_Store works, targeting only name
> >> ending with .jar looks more generic work around.
> >>
> >> Would you mind open a JIRA and send a PR? I'd happy to review!
> >>
> >> Thanks,
> >> Koji
> >>
> >> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
> >> wrote:
> >>> If it turns out that this *is* something you would like addressed, I
> can
> >>> do
> >>> the jira and the PR
> >>>
> >>>
> >>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
> >>> wrote:
> >>>
> >>> @Test
> >>> public void testGetURLsForClasspathWithDirectory() throws
> >>> MalformedURLException {
> >>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
> >>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
> >>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
> >>> assertEquals(2, urls.length);
> >>> }
> >>>
> >>>
> >>> resolves the issue, and I am able to build everything.
> >>>
> >>>
> >>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I’m trying to build master on Mac OS X, following the instructions
from
> >>> the
> >>> site linked in the README.md.
> >>>
> >>> My build is failing because the unit test:
> >>> testGetURLsForClasspathWithDirectory
> >>> in TestClassLoaderUtils.
> >>>
> >>> It is trying to URLs from a directory, and is expecting 2, but gets
3,
> >>> because the DS_STORE is detected and has an url built and returned
for
> >>> it.
> >>>
> >>> The test does not pass in a FileNamesFilter, which could be used to
> >>> filter
> >>> these files out I suppose.
> >>>
> >>> I am wondering if anyone is building successfully on Mac OS X?
>
Re: Build failure on Mac OS X with DS_STORE files
Posted by Koji Kawamura <ij...@gmail.com>.
Thank you, Aldrin!
Koji
On Feb 12, 2017 4:42 AM, "Aldrin Piri" <al...@gmail.com> wrote:
Koji,
Just as a side note, you must perform a separate grunt deploy from the
nifi-site repository for those changes to show up on the site. I took care
of deploying so they would sync and they seem to be live.
--aldrin
On Fri, Feb 10, 2017 at 7:43 PM, Koji Kawamura <ij...@gmail.com>
wrote:
> Thanks Otto, I reviewed pr1497 and merged it.
> For the getting started page, I assume you were referring this quick
start.
> https://nifi.apache.org/quickstart.html
>
> I've modified the Java 8 version description as follows:
> "You need a recent Java 8 (or newer) JDK for the 1.x NiFi line. Older
> Java 8 (such as 1.8.0_31) is known to fail with some unit tests,
> ensure to use the most recent version. The 0.x line works on Java 7 or
> newer."
> https://github.com/apache/nifi-site/blob/master/src/
> pages/markdown/quickstart.md#build-steps
>
> I think it takes a while for the HTML web page gets synchronized.
>
> On Sat, Feb 11, 2017 at 12:17 AM, Otto Fowler <ot...@gmail.com>
> wrote:
> > https://github.com/apache/nifi/pull/1497
> >
> >
> > On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
> > wrote:
> >
> > Thanks! Please ping me when the PR is ready.
> >
> > On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
> > wrote:
> >> Sure - I see what you mean, that is a much better approach.
> >> I will certainly do that.
> >>
> >>
> >>
> >> On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
> >> wrote:
> >>
> >> Hi Otto,
> >>
> >> Thanks for reporting this. I personally haven't encountered this
> >> issue, but as described here [1], when I opened the directory that the
> >> test uses by Mac Finder application, and changed view as icon and move
> >> the icon position, then a .DS_Store file was created.
> >>
> >> I agree with your workaround and I think we should resolve the issue.
> >> By looking at the usage of that method, such as DBCPConnectionPool, or
> >> JoltTransformJSON, those uses file name filter like this:
> >>
> >> (dir, name) -> name != null && name.endsWith(".jar")
> >>
> >> While filtering out specific .DS_Store works, targeting only name
> >> ending with .jar looks more generic work around.
> >>
> >> Would you mind open a JIRA and send a PR? I'd happy to review!
> >>
> >> Thanks,
> >> Koji
> >>
> >> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
> >> wrote:
> >>> If it turns out that this *is* something you would like addressed, I
> can
> >>> do
> >>> the jira and the PR
> >>>
> >>>
> >>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
> >>> wrote:
> >>>
> >>> @Test
> >>> public void testGetURLsForClasspathWithDirectory() throws
> >>> MalformedURLException {
> >>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
> >>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
> >>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
> >>> assertEquals(2, urls.length);
> >>> }
> >>>
> >>>
> >>> resolves the issue, and I am able to build everything.
> >>>
> >>>
> >>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I’m trying to build master on Mac OS X, following the instructions
from
> >>> the
> >>> site linked in the README.md.
> >>>
> >>> My build is failing because the unit test:
> >>> testGetURLsForClasspathWithDirectory
> >>> in TestClassLoaderUtils.
> >>>
> >>> It is trying to URLs from a directory, and is expecting 2, but gets 3,
> >>> because the DS_STORE is detected and has an url built and returned for
> >>> it.
> >>>
> >>> The test does not pass in a FileNamesFilter, which could be used to
> >>> filter
> >>> these files out I suppose.
> >>>
> >>> I am wondering if anyone is building successfully on Mac OS X?
>
Re: Build failure on Mac OS X with DS_STORE files
Posted by Aldrin Piri <al...@gmail.com>.
Koji,
Just as a side note, you must perform a separate grunt deploy from the
nifi-site repository for those changes to show up on the site. I took care
of deploying so they would sync and they seem to be live.
--aldrin
On Fri, Feb 10, 2017 at 7:43 PM, Koji Kawamura <ij...@gmail.com>
wrote:
> Thanks Otto, I reviewed pr1497 and merged it.
> For the getting started page, I assume you were referring this quick start.
> https://nifi.apache.org/quickstart.html
>
> I've modified the Java 8 version description as follows:
> "You need a recent Java 8 (or newer) JDK for the 1.x NiFi line. Older
> Java 8 (such as 1.8.0_31) is known to fail with some unit tests,
> ensure to use the most recent version. The 0.x line works on Java 7 or
> newer."
> https://github.com/apache/nifi-site/blob/master/src/
> pages/markdown/quickstart.md#build-steps
>
> I think it takes a while for the HTML web page gets synchronized.
>
> On Sat, Feb 11, 2017 at 12:17 AM, Otto Fowler <ot...@gmail.com>
> wrote:
> > https://github.com/apache/nifi/pull/1497
> >
> >
> > On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
> > wrote:
> >
> > Thanks! Please ping me when the PR is ready.
> >
> > On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
> > wrote:
> >> Sure - I see what you mean, that is a much better approach.
> >> I will certainly do that.
> >>
> >>
> >>
> >> On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
> >> wrote:
> >>
> >> Hi Otto,
> >>
> >> Thanks for reporting this. I personally haven't encountered this
> >> issue, but as described here [1], when I opened the directory that the
> >> test uses by Mac Finder application, and changed view as icon and move
> >> the icon position, then a .DS_Store file was created.
> >>
> >> I agree with your workaround and I think we should resolve the issue.
> >> By looking at the usage of that method, such as DBCPConnectionPool, or
> >> JoltTransformJSON, those uses file name filter like this:
> >>
> >> (dir, name) -> name != null && name.endsWith(".jar")
> >>
> >> While filtering out specific .DS_Store works, targeting only name
> >> ending with .jar looks more generic work around.
> >>
> >> Would you mind open a JIRA and send a PR? I'd happy to review!
> >>
> >> Thanks,
> >> Koji
> >>
> >> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
> >> wrote:
> >>> If it turns out that this *is* something you would like addressed, I
> can
> >>> do
> >>> the jira and the PR
> >>>
> >>>
> >>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
> >>> wrote:
> >>>
> >>> @Test
> >>> public void testGetURLsForClasspathWithDirectory() throws
> >>> MalformedURLException {
> >>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
> >>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
> >>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
> >>> assertEquals(2, urls.length);
> >>> }
> >>>
> >>>
> >>> resolves the issue, and I am able to build everything.
> >>>
> >>>
> >>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I’m trying to build master on Mac OS X, following the instructions from
> >>> the
> >>> site linked in the README.md.
> >>>
> >>> My build is failing because the unit test:
> >>> testGetURLsForClasspathWithDirectory
> >>> in TestClassLoaderUtils.
> >>>
> >>> It is trying to URLs from a directory, and is expecting 2, but gets 3,
> >>> because the DS_STORE is detected and has an url built and returned for
> >>> it.
> >>>
> >>> The test does not pass in a FileNamesFilter, which could be used to
> >>> filter
> >>> these files out I suppose.
> >>>
> >>> I am wondering if anyone is building successfully on Mac OS X?
>
Re: Build failure on Mac OS X with DS_STORE files
Posted by Koji Kawamura <ij...@gmail.com>.
Thanks Otto, I reviewed pr1497 and merged it.
For the getting started page, I assume you were referring this quick start.
https://nifi.apache.org/quickstart.html
I've modified the Java 8 version description as follows:
"You need a recent Java 8 (or newer) JDK for the 1.x NiFi line. Older
Java 8 (such as 1.8.0_31) is known to fail with some unit tests,
ensure to use the most recent version. The 0.x line works on Java 7 or
newer."
https://github.com/apache/nifi-site/blob/master/src/pages/markdown/quickstart.md#build-steps
I think it takes a while for the HTML web page gets synchronized.
On Sat, Feb 11, 2017 at 12:17 AM, Otto Fowler <ot...@gmail.com> wrote:
> https://github.com/apache/nifi/pull/1497
>
>
> On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
> wrote:
>
> Thanks! Please ping me when the PR is ready.
>
> On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
> wrote:
>> Sure - I see what you mean, that is a much better approach.
>> I will certainly do that.
>>
>>
>>
>> On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
>> wrote:
>>
>> Hi Otto,
>>
>> Thanks for reporting this. I personally haven't encountered this
>> issue, but as described here [1], when I opened the directory that the
>> test uses by Mac Finder application, and changed view as icon and move
>> the icon position, then a .DS_Store file was created.
>>
>> I agree with your workaround and I think we should resolve the issue.
>> By looking at the usage of that method, such as DBCPConnectionPool, or
>> JoltTransformJSON, those uses file name filter like this:
>>
>> (dir, name) -> name != null && name.endsWith(".jar")
>>
>> While filtering out specific .DS_Store works, targeting only name
>> ending with .jar looks more generic work around.
>>
>> Would you mind open a JIRA and send a PR? I'd happy to review!
>>
>> Thanks,
>> Koji
>>
>> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
>> wrote:
>>> If it turns out that this *is* something you would like addressed, I can
>>> do
>>> the jira and the PR
>>>
>>>
>>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
>>> wrote:
>>>
>>> @Test
>>> public void testGetURLsForClasspathWithDirectory() throws
>>> MalformedURLException {
>>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>>> assertEquals(2, urls.length);
>>> }
>>>
>>>
>>> resolves the issue, and I am able to build everything.
>>>
>>>
>>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
>>> wrote:
>>>
>>> Hi,
>>>
>>> I’m trying to build master on Mac OS X, following the instructions from
>>> the
>>> site linked in the README.md.
>>>
>>> My build is failing because the unit test:
>>> testGetURLsForClasspathWithDirectory
>>> in TestClassLoaderUtils.
>>>
>>> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>>> because the DS_STORE is detected and has an url built and returned for
>>> it.
>>>
>>> The test does not pass in a FileNamesFilter, which could be used to
>>> filter
>>> these files out I suppose.
>>>
>>> I am wondering if anyone is building successfully on Mac OS X?
Re: Build failure on Mac OS X with DS_STORE files
Posted by Otto Fowler <ot...@gmail.com>.
https://github.com/apache/nifi/pull/1497
On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
wrote:
Thanks! Please ping me when the PR is ready.
On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
wrote:
> Sure - I see what you mean, that is a much better approach.
> I will certainly do that.
>
>
>
> On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
> wrote:
>
> Hi Otto,
>
> Thanks for reporting this. I personally haven't encountered this
> issue, but as described here [1], when I opened the directory that the
> test uses by Mac Finder application, and changed view as icon and move
> the icon position, then a .DS_Store file was created.
>
> I agree with your workaround and I think we should resolve the issue.
> By looking at the usage of that method, such as DBCPConnectionPool, or
> JoltTransformJSON, those uses file name filter like this:
>
> (dir, name) -> name != null && name.endsWith(".jar")
>
> While filtering out specific .DS_Store works, targeting only name
> ending with .jar looks more generic work around.
>
> Would you mind open a JIRA and send a PR? I'd happy to review!
>
> Thanks,
> Koji
>
> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
wrote:
>> If it turns out that this *is* something you would like addressed, I can
>> do
>> the jira and the PR
>>
>>
>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
>> wrote:
>>
>> @Test
>> public void testGetURLsForClasspathWithDirectory() throws
>> MalformedURLException {
>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>> assertEquals(2, urls.length);
>> }
>>
>>
>> resolves the issue, and I am able to build everything.
>>
>>
>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
>> wrote:
>>
>> Hi,
>>
>> I’m trying to build master on Mac OS X, following the instructions from
>> the
>> site linked in the README.md.
>>
>> My build is failing because the unit test:
>> testGetURLsForClasspathWithDirectory
>> in TestClassLoaderUtils.
>>
>> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>> because the DS_STORE is detected and has an url built and returned for
it.
>>
>> The test does not pass in a FileNamesFilter, which could be used to
filter
>> these files out I suppose.
>>
>> I am wondering if anyone is building successfully on Mac OS X?
Re: Build failure on Mac OS X with DS_STORE files
Posted by Otto Fowler <ot...@gmail.com>.
OK - I can build with the latest JDK ( except for the DS_Store issue. So
the problem is that
the getting started page should not just say Java 8, is should have some
version of the JDK that will actually build.
On February 9, 2017 at 19:34:31, Otto Fowler (ottobackwards@gmail.com)
wrote:
I am using 1.8.0_31
I have been able to get a complete good build, but I had to make a few
changes.
On February 9, 2017 at 18:34:48, Koji Kawamura (ijokarumawak@gmail.com)
wrote:
Hi Otto,
Which version of Java are you using?
I remember early version of Java 8 fails to pass the test. Would you
try to update JDK version and build it again?
Thanks,
Koji
On Fri, Feb 10, 2017 at 3:43 AM, Otto Fowler <ot...@gmail.com>
wrote:
> OK, that is good. There very well could be something ‘special’ about what
> I am seeing.
> I am fixing things as I find them. The things that are not working make
> sense to me, in other words I’m not sure how they are not broken for
> everyone.
>
> Maybe if I get to the end of it, I’ll post what the patch *would* be?
>
>
> On February 9, 2017 at 11:11:55, Joe Skora (jskora@gmail.com) wrote:
>
> Otto,
>
> I regularly build on a Mac without problems, and I believe a lot of
> contributors do as well.
>
> I haven't run into the .DS_Store issues with NiFi, probably because I
> rarely use Finder to access my build folders.
>
> I don't recall any issues with ScriptingProcessor, but it's been a week or
> more since I built on the Mac, I can check it tonight.
>
> Regards,
> Joe
>
> On Thu, Feb 9, 2017 at 10:59 AM, Otto Fowler <ot...@gmail.com>
> wrote:
>
>> So,
>>
>> I could have a pr that fixes that problem, but I’m seeing new problems
>> now. I can submit the pr then keep looking at the other problems (
> meaning
>> I can submit a pr without having a working complete build, just fixing
> that
>> test ), but I’m not sure how you all handle things like this.
>>
>> I have to ask, does anyone working on NiFi use a mac? The next problems I
>> have are not with .DS_Store files or anything ‘mac centric’, they are
> with
>> Nashorn Java script types in the ScriptingProcessor tests…..
>>
>> On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
>> wrote:
>>
>> Thanks! Please ping me when the PR is ready.
>>
>> On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
>> wrote:
>> > Sure - I see what you mean, that is a much better approach.
>> > I will certainly do that.
>> >
>> >
>> >
>> > On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
>> > wrote:
>> >
>> > Hi Otto,
>> >
>> > Thanks for reporting this. I personally haven't encountered this
>> > issue, but as described here [1], when I opened the directory that the
>> > test uses by Mac Finder application, and changed view as icon and move
>> > the icon position, then a .DS_Store file was created.
>> >
>> > I agree with your workaround and I think we should resolve the issue.
>> > By looking at the usage of that method, such as DBCPConnectionPool, or
>> > JoltTransformJSON, those uses file name filter like this:
>> >
>> > (dir, name) -> name != null && name.endsWith(".jar")
>> >
>> > While filtering out specific .DS_Store works, targeting only name
>> > ending with .jar looks more generic work around.
>> >
>> > Would you mind open a JIRA and send a PR? I'd happy to review!
>> >
>> > Thanks,
>> > Koji
>> >
>> > On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
>> wrote:
>> >> If it turns out that this *is* something you would like addressed, I
> can
>> >> do
>> >> the jira and the PR
>> >>
>> >>
>> >> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
>> >> wrote:
>> >>
>> >> @Test
>> >> public void testGetURLsForClasspathWithDirectory() throws
>> >> MalformedURLException {
>> >> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>> >> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>> >> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>> >> assertEquals(2, urls.length);
>> >> }
>> >>
>> >>
>> >> resolves the issue, and I am able to build everything.
>> >>
>> >>
>> >> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
>> >> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I’m trying to build master on Mac OS X, following the instructions
> from
>> >> the
>> >> site linked in the README.md.
>> >>
>> >> My build is failing because the unit test:
>> >> testGetURLsForClasspathWithDirectory
>> >> in TestClassLoaderUtils.
>> >>
>> >> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>> >> because the DS_STORE is detected and has an url built and returned for
>> it.
>> >>
>> >> The test does not pass in a FileNamesFilter, which could be used to
>> filter
>> >> these files out I suppose.
>> >>
>> >> I am wondering if anyone is building successfully on Mac OS X?
>>
Re: Build failure on Mac OS X with DS_STORE files
Posted by Otto Fowler <ot...@gmail.com>.
I am using 1.8.0_31
I have been able to get a complete good build, but I had to make a few
changes.
On February 9, 2017 at 18:34:48, Koji Kawamura (ijokarumawak@gmail.com)
wrote:
Hi Otto,
Which version of Java are you using?
I remember early version of Java 8 fails to pass the test. Would you
try to update JDK version and build it again?
Thanks,
Koji
On Fri, Feb 10, 2017 at 3:43 AM, Otto Fowler <ot...@gmail.com>
wrote:
> OK, that is good. There very well could be something ‘special’ about what
> I am seeing.
> I am fixing things as I find them. The things that are not working make
> sense to me, in other words I’m not sure how they are not broken for
> everyone.
>
> Maybe if I get to the end of it, I’ll post what the patch *would* be?
>
>
> On February 9, 2017 at 11:11:55, Joe Skora (jskora@gmail.com) wrote:
>
> Otto,
>
> I regularly build on a Mac without problems, and I believe a lot of
> contributors do as well.
>
> I haven't run into the .DS_Store issues with NiFi, probably because I
> rarely use Finder to access my build folders.
>
> I don't recall any issues with ScriptingProcessor, but it's been a week
or
> more since I built on the Mac, I can check it tonight.
>
> Regards,
> Joe
>
> On Thu, Feb 9, 2017 at 10:59 AM, Otto Fowler <ot...@gmail.com>
> wrote:
>
>> So,
>>
>> I could have a pr that fixes that problem, but I’m seeing new problems
>> now. I can submit the pr then keep looking at the other problems (
> meaning
>> I can submit a pr without having a working complete build, just fixing
> that
>> test ), but I’m not sure how you all handle things like this.
>>
>> I have to ask, does anyone working on NiFi use a mac? The next problems
I
>> have are not with .DS_Store files or anything ‘mac centric’, they are
> with
>> Nashorn Java script types in the ScriptingProcessor tests…..
>>
>> On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
>> wrote:
>>
>> Thanks! Please ping me when the PR is ready.
>>
>> On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
>> wrote:
>> > Sure - I see what you mean, that is a much better approach.
>> > I will certainly do that.
>> >
>> >
>> >
>> > On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
>> > wrote:
>> >
>> > Hi Otto,
>> >
>> > Thanks for reporting this. I personally haven't encountered this
>> > issue, but as described here [1], when I opened the directory that the
>> > test uses by Mac Finder application, and changed view as icon and move
>> > the icon position, then a .DS_Store file was created.
>> >
>> > I agree with your workaround and I think we should resolve the issue.
>> > By looking at the usage of that method, such as DBCPConnectionPool, or
>> > JoltTransformJSON, those uses file name filter like this:
>> >
>> > (dir, name) -> name != null && name.endsWith(".jar")
>> >
>> > While filtering out specific .DS_Store works, targeting only name
>> > ending with .jar looks more generic work around.
>> >
>> > Would you mind open a JIRA and send a PR? I'd happy to review!
>> >
>> > Thanks,
>> > Koji
>> >
>> > On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
>> wrote:
>> >> If it turns out that this *is* something you would like addressed, I
> can
>> >> do
>> >> the jira and the PR
>> >>
>> >>
>> >> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
>> >> wrote:
>> >>
>> >> @Test
>> >> public void testGetURLsForClasspathWithDirectory() throws
>> >> MalformedURLException {
>> >> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>> >> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>> >> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>> >> assertEquals(2, urls.length);
>> >> }
>> >>
>> >>
>> >> resolves the issue, and I am able to build everything.
>> >>
>> >>
>> >> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
>> >> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I’m trying to build master on Mac OS X, following the instructions
> from
>> >> the
>> >> site linked in the README.md.
>> >>
>> >> My build is failing because the unit test:
>> >> testGetURLsForClasspathWithDirectory
>> >> in TestClassLoaderUtils.
>> >>
>> >> It is trying to URLs from a directory, and is expecting 2, but gets
3,
>> >> because the DS_STORE is detected and has an url built and returned
for
>> it.
>> >>
>> >> The test does not pass in a FileNamesFilter, which could be used to
>> filter
>> >> these files out I suppose.
>> >>
>> >> I am wondering if anyone is building successfully on Mac OS X?
>>
Re: Build failure on Mac OS X with DS_STORE files
Posted by Koji Kawamura <ij...@gmail.com>.
Hi Otto,
Which version of Java are you using?
I remember early version of Java 8 fails to pass the test. Would you
try to update JDK version and build it again?
Thanks,
Koji
On Fri, Feb 10, 2017 at 3:43 AM, Otto Fowler <ot...@gmail.com> wrote:
> OK, that is good. There very well could be something ‘special’ about what
> I am seeing.
> I am fixing things as I find them. The things that are not working make
> sense to me, in other words I’m not sure how they are not broken for
> everyone.
>
> Maybe if I get to the end of it, I’ll post what the patch *would* be?
>
>
> On February 9, 2017 at 11:11:55, Joe Skora (jskora@gmail.com) wrote:
>
> Otto,
>
> I regularly build on a Mac without problems, and I believe a lot of
> contributors do as well.
>
> I haven't run into the .DS_Store issues with NiFi, probably because I
> rarely use Finder to access my build folders.
>
> I don't recall any issues with ScriptingProcessor, but it's been a week or
> more since I built on the Mac, I can check it tonight.
>
> Regards,
> Joe
>
> On Thu, Feb 9, 2017 at 10:59 AM, Otto Fowler <ot...@gmail.com>
> wrote:
>
>> So,
>>
>> I could have a pr that fixes that problem, but I’m seeing new problems
>> now. I can submit the pr then keep looking at the other problems (
> meaning
>> I can submit a pr without having a working complete build, just fixing
> that
>> test ), but I’m not sure how you all handle things like this.
>>
>> I have to ask, does anyone working on NiFi use a mac? The next problems I
>> have are not with .DS_Store files or anything ‘mac centric’, they are
> with
>> Nashorn Java script types in the ScriptingProcessor tests…..
>>
>> On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
>> wrote:
>>
>> Thanks! Please ping me when the PR is ready.
>>
>> On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
>> wrote:
>> > Sure - I see what you mean, that is a much better approach.
>> > I will certainly do that.
>> >
>> >
>> >
>> > On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
>> > wrote:
>> >
>> > Hi Otto,
>> >
>> > Thanks for reporting this. I personally haven't encountered this
>> > issue, but as described here [1], when I opened the directory that the
>> > test uses by Mac Finder application, and changed view as icon and move
>> > the icon position, then a .DS_Store file was created.
>> >
>> > I agree with your workaround and I think we should resolve the issue.
>> > By looking at the usage of that method, such as DBCPConnectionPool, or
>> > JoltTransformJSON, those uses file name filter like this:
>> >
>> > (dir, name) -> name != null && name.endsWith(".jar")
>> >
>> > While filtering out specific .DS_Store works, targeting only name
>> > ending with .jar looks more generic work around.
>> >
>> > Would you mind open a JIRA and send a PR? I'd happy to review!
>> >
>> > Thanks,
>> > Koji
>> >
>> > On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
>> wrote:
>> >> If it turns out that this *is* something you would like addressed, I
> can
>> >> do
>> >> the jira and the PR
>> >>
>> >>
>> >> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
>> >> wrote:
>> >>
>> >> @Test
>> >> public void testGetURLsForClasspathWithDirectory() throws
>> >> MalformedURLException {
>> >> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>> >> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>> >> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>> >> assertEquals(2, urls.length);
>> >> }
>> >>
>> >>
>> >> resolves the issue, and I am able to build everything.
>> >>
>> >>
>> >> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
>> >> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I’m trying to build master on Mac OS X, following the instructions
> from
>> >> the
>> >> site linked in the README.md.
>> >>
>> >> My build is failing because the unit test:
>> >> testGetURLsForClasspathWithDirectory
>> >> in TestClassLoaderUtils.
>> >>
>> >> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>> >> because the DS_STORE is detected and has an url built and returned for
>> it.
>> >>
>> >> The test does not pass in a FileNamesFilter, which could be used to
>> filter
>> >> these files out I suppose.
>> >>
>> >> I am wondering if anyone is building successfully on Mac OS X?
>>
Re: Build failure on Mac OS X with DS_STORE files
Posted by Otto Fowler <ot...@gmail.com>.
OK, that is good. There very well could be something ‘special’ about what
I am seeing.
I am fixing things as I find them. The things that are not working make
sense to me, in other words I’m not sure how they are not broken for
everyone.
Maybe if I get to the end of it, I’ll post what the patch *would* be?
On February 9, 2017 at 11:11:55, Joe Skora (jskora@gmail.com) wrote:
Otto,
I regularly build on a Mac without problems, and I believe a lot of
contributors do as well.
I haven't run into the .DS_Store issues with NiFi, probably because I
rarely use Finder to access my build folders.
I don't recall any issues with ScriptingProcessor, but it's been a week or
more since I built on the Mac, I can check it tonight.
Regards,
Joe
On Thu, Feb 9, 2017 at 10:59 AM, Otto Fowler <ot...@gmail.com>
wrote:
> So,
>
> I could have a pr that fixes that problem, but I’m seeing new problems
> now. I can submit the pr then keep looking at the other problems (
meaning
> I can submit a pr without having a working complete build, just fixing
that
> test ), but I’m not sure how you all handle things like this.
>
> I have to ask, does anyone working on NiFi use a mac? The next problems I
> have are not with .DS_Store files or anything ‘mac centric’, they are
with
> Nashorn Java script types in the ScriptingProcessor tests…..
>
> On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
> wrote:
>
> Thanks! Please ping me when the PR is ready.
>
> On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
> wrote:
> > Sure - I see what you mean, that is a much better approach.
> > I will certainly do that.
> >
> >
> >
> > On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
> > wrote:
> >
> > Hi Otto,
> >
> > Thanks for reporting this. I personally haven't encountered this
> > issue, but as described here [1], when I opened the directory that the
> > test uses by Mac Finder application, and changed view as icon and move
> > the icon position, then a .DS_Store file was created.
> >
> > I agree with your workaround and I think we should resolve the issue.
> > By looking at the usage of that method, such as DBCPConnectionPool, or
> > JoltTransformJSON, those uses file name filter like this:
> >
> > (dir, name) -> name != null && name.endsWith(".jar")
> >
> > While filtering out specific .DS_Store works, targeting only name
> > ending with .jar looks more generic work around.
> >
> > Would you mind open a JIRA and send a PR? I'd happy to review!
> >
> > Thanks,
> > Koji
> >
> > On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
> wrote:
> >> If it turns out that this *is* something you would like addressed, I
can
> >> do
> >> the jira and the PR
> >>
> >>
> >> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
> >> wrote:
> >>
> >> @Test
> >> public void testGetURLsForClasspathWithDirectory() throws
> >> MalformedURLException {
> >> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
> >> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
> >> (dir,name)->name.compareTo(".DS_Store") == 0, false);
> >> assertEquals(2, urls.length);
> >> }
> >>
> >>
> >> resolves the issue, and I am able to build everything.
> >>
> >>
> >> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
> >> wrote:
> >>
> >> Hi,
> >>
> >> I’m trying to build master on Mac OS X, following the instructions
from
> >> the
> >> site linked in the README.md.
> >>
> >> My build is failing because the unit test:
> >> testGetURLsForClasspathWithDirectory
> >> in TestClassLoaderUtils.
> >>
> >> It is trying to URLs from a directory, and is expecting 2, but gets 3,
> >> because the DS_STORE is detected and has an url built and returned for
> it.
> >>
> >> The test does not pass in a FileNamesFilter, which could be used to
> filter
> >> these files out I suppose.
> >>
> >> I am wondering if anyone is building successfully on Mac OS X?
>
Re: Build failure on Mac OS X with DS_STORE files
Posted by Joe Skora <js...@gmail.com>.
Otto,
I regularly build on a Mac without problems, and I believe a lot of
contributors do as well.
I haven't run into the .DS_Store issues with NiFi, probably because I
rarely use Finder to access my build folders.
I don't recall any issues with ScriptingProcessor, but it's been a week or
more since I built on the Mac, I can check it tonight.
Regards,
Joe
On Thu, Feb 9, 2017 at 10:59 AM, Otto Fowler <ot...@gmail.com>
wrote:
> So,
>
> I could have a pr that fixes that problem, but I’m seeing new problems
> now. I can submit the pr then keep looking at the other problems ( meaning
> I can submit a pr without having a working complete build, just fixing that
> test ), but I’m not sure how you all handle things like this.
>
> I have to ask, does anyone working on NiFi use a mac? The next problems I
> have are not with .DS_Store files or anything ‘mac centric’, they are with
> Nashorn Java script types in the ScriptingProcessor tests…..
>
> On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
> wrote:
>
> Thanks! Please ping me when the PR is ready.
>
> On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
> wrote:
> > Sure - I see what you mean, that is a much better approach.
> > I will certainly do that.
> >
> >
> >
> > On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
> > wrote:
> >
> > Hi Otto,
> >
> > Thanks for reporting this. I personally haven't encountered this
> > issue, but as described here [1], when I opened the directory that the
> > test uses by Mac Finder application, and changed view as icon and move
> > the icon position, then a .DS_Store file was created.
> >
> > I agree with your workaround and I think we should resolve the issue.
> > By looking at the usage of that method, such as DBCPConnectionPool, or
> > JoltTransformJSON, those uses file name filter like this:
> >
> > (dir, name) -> name != null && name.endsWith(".jar")
> >
> > While filtering out specific .DS_Store works, targeting only name
> > ending with .jar looks more generic work around.
> >
> > Would you mind open a JIRA and send a PR? I'd happy to review!
> >
> > Thanks,
> > Koji
> >
> > On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
> wrote:
> >> If it turns out that this *is* something you would like addressed, I can
> >> do
> >> the jira and the PR
> >>
> >>
> >> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
> >> wrote:
> >>
> >> @Test
> >> public void testGetURLsForClasspathWithDirectory() throws
> >> MalformedURLException {
> >> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
> >> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
> >> (dir,name)->name.compareTo(".DS_Store") == 0, false);
> >> assertEquals(2, urls.length);
> >> }
> >>
> >>
> >> resolves the issue, and I am able to build everything.
> >>
> >>
> >> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
> >> wrote:
> >>
> >> Hi,
> >>
> >> I’m trying to build master on Mac OS X, following the instructions from
> >> the
> >> site linked in the README.md.
> >>
> >> My build is failing because the unit test:
> >> testGetURLsForClasspathWithDirectory
> >> in TestClassLoaderUtils.
> >>
> >> It is trying to URLs from a directory, and is expecting 2, but gets 3,
> >> because the DS_STORE is detected and has an url built and returned for
> it.
> >>
> >> The test does not pass in a FileNamesFilter, which could be used to
> filter
> >> these files out I suppose.
> >>
> >> I am wondering if anyone is building successfully on Mac OS X?
>
Re: Build failure on Mac OS X with DS_STORE files
Posted by Otto Fowler <ot...@gmail.com>.
So,
I could have a pr that fixes that problem, but I’m seeing new problems
now. I can submit the pr then keep looking at the other problems ( meaning
I can submit a pr without having a working complete build, just fixing that
test ), but I’m not sure how you all handle things like this.
I have to ask, does anyone working on NiFi use a mac? The next problems I
have are not with .DS_Store files or anything ‘mac centric’, they are with
Nashorn Java script types in the ScriptingProcessor tests…..
On February 9, 2017 at 09:19:21, Koji Kawamura (ijokarumawak@gmail.com)
wrote:
Thanks! Please ping me when the PR is ready.
On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com>
wrote:
> Sure - I see what you mean, that is a much better approach.
> I will certainly do that.
>
>
>
> On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
> wrote:
>
> Hi Otto,
>
> Thanks for reporting this. I personally haven't encountered this
> issue, but as described here [1], when I opened the directory that the
> test uses by Mac Finder application, and changed view as icon and move
> the icon position, then a .DS_Store file was created.
>
> I agree with your workaround and I think we should resolve the issue.
> By looking at the usage of that method, such as DBCPConnectionPool, or
> JoltTransformJSON, those uses file name filter like this:
>
> (dir, name) -> name != null && name.endsWith(".jar")
>
> While filtering out specific .DS_Store works, targeting only name
> ending with .jar looks more generic work around.
>
> Would you mind open a JIRA and send a PR? I'd happy to review!
>
> Thanks,
> Koji
>
> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
wrote:
>> If it turns out that this *is* something you would like addressed, I can
>> do
>> the jira and the PR
>>
>>
>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
>> wrote:
>>
>> @Test
>> public void testGetURLsForClasspathWithDirectory() throws
>> MalformedURLException {
>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>> assertEquals(2, urls.length);
>> }
>>
>>
>> resolves the issue, and I am able to build everything.
>>
>>
>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
>> wrote:
>>
>> Hi,
>>
>> I’m trying to build master on Mac OS X, following the instructions from
>> the
>> site linked in the README.md.
>>
>> My build is failing because the unit test:
>> testGetURLsForClasspathWithDirectory
>> in TestClassLoaderUtils.
>>
>> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>> because the DS_STORE is detected and has an url built and returned for
it.
>>
>> The test does not pass in a FileNamesFilter, which could be used to
filter
>> these files out I suppose.
>>
>> I am wondering if anyone is building successfully on Mac OS X?
Re: Build failure on Mac OS X with DS_STORE files
Posted by Koji Kawamura <ij...@gmail.com>.
Thanks! Please ping me when the PR is ready.
On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler <ot...@gmail.com> wrote:
> Sure - I see what you mean, that is a much better approach.
> I will certainly do that.
>
>
>
> On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
> wrote:
>
> Hi Otto,
>
> Thanks for reporting this. I personally haven't encountered this
> issue, but as described here [1], when I opened the directory that the
> test uses by Mac Finder application, and changed view as icon and move
> the icon position, then a .DS_Store file was created.
>
> I agree with your workaround and I think we should resolve the issue.
> By looking at the usage of that method, such as DBCPConnectionPool, or
> JoltTransformJSON, those uses file name filter like this:
>
> (dir, name) -> name != null && name.endsWith(".jar")
>
> While filtering out specific .DS_Store works, targeting only name
> ending with .jar looks more generic work around.
>
> Would you mind open a JIRA and send a PR? I'd happy to review!
>
> Thanks,
> Koji
>
> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com> wrote:
>> If it turns out that this *is* something you would like addressed, I can
>> do
>> the jira and the PR
>>
>>
>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
>> wrote:
>>
>> @Test
>> public void testGetURLsForClasspathWithDirectory() throws
>> MalformedURLException {
>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>> assertEquals(2, urls.length);
>> }
>>
>>
>> resolves the issue, and I am able to build everything.
>>
>>
>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
>> wrote:
>>
>> Hi,
>>
>> I’m trying to build master on Mac OS X, following the instructions from
>> the
>> site linked in the README.md.
>>
>> My build is failing because the unit test:
>> testGetURLsForClasspathWithDirectory
>> in TestClassLoaderUtils.
>>
>> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>> because the DS_STORE is detected and has an url built and returned for it.
>>
>> The test does not pass in a FileNamesFilter, which could be used to filter
>> these files out I suppose.
>>
>> I am wondering if anyone is building successfully on Mac OS X?
Re: Build failure on Mac OS X with DS_STORE files
Posted by Otto Fowler <ot...@gmail.com>.
Sure - I see what you mean, that is a much better approach.
I will certainly do that.
On February 9, 2017 at 09:02:05, Koji Kawamura (ijokarumawak@gmail.com)
wrote:
Hi Otto,
Thanks for reporting this. I personally haven't encountered this
issue, but as described here [1], when I opened the directory that the
test uses by Mac Finder application, and changed view as icon and move
the icon position, then a .DS_Store file was created.
I agree with your workaround and I think we should resolve the issue.
By looking at the usage of that method, such as DBCPConnectionPool, or
JoltTransformJSON, those uses file name filter like this:
(dir, name) -> name != null && name.endsWith(".jar")
While filtering out specific .DS_Store works, targeting only name
ending with .jar looks more generic work around.
Would you mind open a JIRA and send a PR? I'd happy to review!
Thanks,
Koji
On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com>
wrote:
> If it turns out that this *is* something you would like addressed, I can
do
> the jira and the PR
>
>
> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
> wrote:
>
> @Test
> public void testGetURLsForClasspathWithDirectory() throws
> MalformedURLException {
> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
> (dir,name)->name.compareTo(".DS_Store") == 0, false);
> assertEquals(2, urls.length);
> }
>
>
> resolves the issue, and I am able to build everything.
>
>
> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
> wrote:
>
> Hi,
>
> I’m trying to build master on Mac OS X, following the instructions from
the
> site linked in the README.md.
>
> My build is failing because the unit test:
> testGetURLsForClasspathWithDirectory
> in TestClassLoaderUtils.
>
> It is trying to URLs from a directory, and is expecting 2, but gets 3,
> because the DS_STORE is detected and has an url built and returned for
it.
>
> The test does not pass in a FileNamesFilter, which could be used to
filter
> these files out I suppose.
>
> I am wondering if anyone is building successfully on Mac OS X?
Re: Build failure on Mac OS X with DS_STORE files
Posted by Koji Kawamura <ij...@gmail.com>.
Excuse me, I forgot to add a link that I referred on how to create
.DS_Store file.
https://discussions.apple.com/thread/5064875?start=0&tstart=0
On Thu, Feb 9, 2017 at 11:02 PM, Koji Kawamura <ij...@gmail.com> wrote:
> Hi Otto,
>
> Thanks for reporting this. I personally haven't encountered this
> issue, but as described here [1], when I opened the directory that the
> test uses by Mac Finder application, and changed view as icon and move
> the icon position, then a .DS_Store file was created.
>
> I agree with your workaround and I think we should resolve the issue.
> By looking at the usage of that method, such as DBCPConnectionPool, or
> JoltTransformJSON, those uses file name filter like this:
>
> (dir, name) -> name != null && name.endsWith(".jar")
>
> While filtering out specific .DS_Store works, targeting only name
> ending with .jar looks more generic work around.
>
> Would you mind open a JIRA and send a PR? I'd happy to review!
>
> Thanks,
> Koji
>
> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com> wrote:
>> If it turns out that this *is* something you would like addressed, I can do
>> the jira and the PR
>>
>>
>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
>> wrote:
>>
>> @Test
>> public void testGetURLsForClasspathWithDirectory() throws
>> MalformedURLException {
>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>> assertEquals(2, urls.length);
>> }
>>
>>
>> resolves the issue, and I am able to build everything.
>>
>>
>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
>> wrote:
>>
>> Hi,
>>
>> I’m trying to build master on Mac OS X, following the instructions from the
>> site linked in the README.md.
>>
>> My build is failing because the unit test:
>> testGetURLsForClasspathWithDirectory
>> in TestClassLoaderUtils.
>>
>> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>> because the DS_STORE is detected and has an url built and returned for it.
>>
>> The test does not pass in a FileNamesFilter, which could be used to filter
>> these files out I suppose.
>>
>> I am wondering if anyone is building successfully on Mac OS X?
Re: Build failure on Mac OS X with DS_STORE files
Posted by Koji Kawamura <ij...@gmail.com>.
Hi Otto,
Thanks for reporting this. I personally haven't encountered this
issue, but as described here [1], when I opened the directory that the
test uses by Mac Finder application, and changed view as icon and move
the icon position, then a .DS_Store file was created.
I agree with your workaround and I think we should resolve the issue.
By looking at the usage of that method, such as DBCPConnectionPool, or
JoltTransformJSON, those uses file name filter like this:
(dir, name) -> name != null && name.endsWith(".jar")
While filtering out specific .DS_Store works, targeting only name
ending with .jar looks more generic work around.
Would you mind open a JIRA and send a PR? I'd happy to review!
Thanks,
Koji
On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler <ot...@gmail.com> wrote:
> If it turns out that this *is* something you would like addressed, I can do
> the jira and the PR
>
>
> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
> wrote:
>
> @Test
> public void testGetURLsForClasspathWithDirectory() throws
> MalformedURLException {
> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
> (dir,name)->name.compareTo(".DS_Store") == 0, false);
> assertEquals(2, urls.length);
> }
>
>
> resolves the issue, and I am able to build everything.
>
>
> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
> wrote:
>
> Hi,
>
> I’m trying to build master on Mac OS X, following the instructions from the
> site linked in the README.md.
>
> My build is failing because the unit test:
> testGetURLsForClasspathWithDirectory
> in TestClassLoaderUtils.
>
> It is trying to URLs from a directory, and is expecting 2, but gets 3,
> because the DS_STORE is detected and has an url built and returned for it.
>
> The test does not pass in a FileNamesFilter, which could be used to filter
> these files out I suppose.
>
> I am wondering if anyone is building successfully on Mac OS X?
Re: Build failure on Mac OS X with DS_STORE files
Posted by Otto Fowler <ot...@gmail.com>.
If it turns out that this *is* something you would like addressed, I can do
the jira and the PR
On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwards@gmail.com)
wrote:
@Test
public void testGetURLsForClasspathWithDirectory() throws
MalformedURLException {
final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
(dir,name)->name.compareTo(".DS_Store") == 0, false);
assertEquals(2, urls.length);
}
resolves the issue, and I am able to build everything.
On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
wrote:
Hi,
I’m trying to build master on Mac OS X, following the instructions from the
site linked in the README.md.
My build is failing because the unit test:
testGetURLsForClasspathWithDirectory
in TestClassLoaderUtils.
It is trying to URLs from a directory, and is expecting 2, but gets 3,
because the DS_STORE is detected and has an url built and returned for it.
The test does not pass in a FileNamesFilter, which could be used to filter
these files out I suppose.
I am wondering if anyone is building successfully on Mac OS X?
Re: Build failure on Mac OS X with DS_STORE files
Posted by Otto Fowler <ot...@gmail.com>.
@Test
public void testGetURLsForClasspathWithDirectory() throws
MalformedURLException {
final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
(dir,name)->name.compareTo(".DS_Store") == 0, false);
assertEquals(2, urls.length);
}
resolves the issue, and I am able to build everything.
On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwards@gmail.com)
wrote:
Hi,
I’m trying to build master on Mac OS X, following the instructions from the
site linked in the README.md.
My build is failing because the unit test:
testGetURLsForClasspathWithDirectory
in TestClassLoaderUtils.
It is trying to URLs from a directory, and is expecting 2, but gets 3,
because the DS_STORE is detected and has an url built and returned for it.
The test does not pass in a FileNamesFilter, which could be used to filter
these files out I suppose.
I am wondering if anyone is building successfully on Mac OS X?