ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: IvyDE & properties files
Date Fri, 14 Oct 2011 14:07:55 GMT
Thanks. Makes sense now that it would be a comma-separated list rather than
a path-like structure. Not sure how to better convey that fact in the UI,
but as long as the text box is prepending to the existing text, if there is
existing text, you could always stick a comma at the end of what you're

2011/10/14 Nicolas Lalevée <>

> Le 14 oct. 2011 à 07:05, Mitch Gitman a écrit :
> > I'm having some interesting experiences with IvyDE 2.1.0 while trying to
> > apply properties files to the Ivy settings I want to use.
> > First the merely annoying interesting experience. If I go to click the
> File
> > System... button under "Property files:", the dialog box that shows up
> > filters by *.xml file type. Obviously, at this point, it's not XML files
> > that I'm looking for. I have to do a double-take every time I come across
> > this and ask myself, "What happened to my properties file?"
> > Next the more troubling interesting experience. Note that it says
> "Property
> > files:" plural. If I click on File System: more than once, the newly
> added
> > file path gets prepended to the existing path, with no separator, as if
> it
> > was just one long, run-on filename. Suppose, though, that I do put in a
> > platform-specific file path separator--say a semicolon. When I go to add
> > "IvyDE Managed Dependencies" to a given project, the settings parsing
> will
> > fail when it encounters this multi-file path, confusing it for a single
> > file. The error message will be:
> > "The property file ...;... was not found."
> > I get the same failure if I use one or more workspace locations as
> opposed
> > to file system paths, or mixing the two.
> > So there's no way to apply multiple properties files to an Ivy settings
> used
> > for IvyDE? Forgive me if I'm asking a question here that has already been
> > explored on this list.
> It is documented, but not easy to find I admit.
> This is a comma separated list.
> This UI can definitively be improved. I have also faced myself the issue
> with the *.xml default filtering which is indeed boring. I'll try to come up
> with a better UI.
> Nicolas

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message