Re: [2/2] ant git commit: Bz 22370: followlinks attribute
On 2018-06-05, Gintautas Grigelionis wrote: > Stefan is right -- "followsymlinks" for the fileset should have been called > "skipsymlinks" or something like that. I'm afraid I don't follow you here, what did you expect followsymlinks going by the name? What would the "new semantics of followsymlinks" you talk about be? How would the combinations followsymlinks="true" skipsymlinks="true" followsymlinks="false" skipsymlinks="false" behave? Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [2/2] ant git commit: Bz 22370: followlinks attribute
2018-06-06 10:50 GMT+02:00 Stefan Bodewig : > On 2018-06-05, Gintautas Grigelionis wrote: > > > Stefan is right -- "followsymlinks" for the fileset should have been > called > > "skipsymlinks" or something like that. > > I'm afraid I don't follow you here, what did you expect followsymlinks > going by the name? What would the "new semantics of followsymlinks" you > talk about be? > > How would the combinations > > followsymlinks="true" skipsymlinks="true" > followsymlinks="false" skipsymlinks="false" > > behave? > I expect the following: followsymlinks="false" should select symbolic links (rather than omitting them which seems to be its current behaviour); followsymlinks="true" should select whatever the links point at to (unless there is a loop). Consequently, I expect followsymlinks="false" skipsymlinks="false" to behave as followsymlinks="false"; whereas followsymlinks="true" skipsymlinks="true" is ambiguous: if followsymlinks takes precedence, skipsymlinks is redundant; if skipsymlinks takes precedence, then followsymlinks is ignored. Gintas
Re: [2/2] ant git commit: Bz 22370: followlinks attribute
On 2018-06-06, Gintautas Grigelionis wrote: > 2018-06-06 10:50 GMT+02:00 Stefan Bodewig : >> On 2018-06-05, Gintautas Grigelionis wrote: >>> Stefan is right -- "followsymlinks" for the fileset should have been >> called >>> "skipsymlinks" or something like that. >> I'm afraid I don't follow you here, what did you expect followsymlinks >> going by the name? What would the "new semantics of followsymlinks" you >> talk about be? >> How would the combinations >> followsymlinks="true" skipsymlinks="true" >> followsymlinks="false" skipsymlinks="false" >> behave? > I expect the following: > followsymlinks="false" should select symbolic links (rather than omitting > them which seems to be its current behaviour); > followsymlinks="true" should select whatever the links point at to (unless > there is a loop). I guess here our API breaks down as we only ever deal with files or directories (outside of the symlink task). Would the symlink be included in DirectoryScanner's "included files" or "included directories"? What will do to a symlink that is included but not followed. The current semantics of fileset's followsymlinks is deeply rooted in "we don't know how to deal with links and can only handle files and directories". I'm afraid a bunch of tasks will not do what you expect if DirectoryScanner suddenly returned File instances that are not real files/directories. Either they'd simply follow the link or break down - I assume in most cases it will be the former. > Consequently, I expect > followsymlinks="false" skipsymlinks="false" to behave as > followsymlinks="false"; which would be the same as skipsymlinks="true", right? > whereas followsymlinks="true" skipsymlinks="true" is ambiguous: if > followsymlinks takes precedence, skipsymlinks is redundant; if > skipsymlinks takes precedence, then followsymlinks is ignored. So we'd need to decide what takes precedence and document it properly. As I said above, I don't think Ant's tasks are going to treat non-followed symlinks the way you'd expect them to. We could collect them separately and add a new getIncludedSymlinks method to DirectoryScanner so each task could do what it is supposed to do for not-followed links, but then we'll start documenting whether a given task X handles those links at all and if so what it does. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
FINAL REMINDER: Apache EU Roadshow 2018 in Berlin next week!
Hello Apache Supporters and Enthusiasts This is a final reminder that our Apache EU Roadshow will be held in Berlin next week on 13th and 14th June 2018. We will have 28 different sessions running over 2 days that cover some great topics. So if you are interested in Microservices, Internet of Things (IoT), Cloud, Apache Tomcat or Apache Http Server then we have something for you. https://foss-backstage.de/sessions/apache-roadshow We will be co-located with FOSS Backstage, so if you are interested in topics such as incubator, the Apache Way, open source governance, legal, trademarks or simply open source communities then there will be something there for you too. You can attend any of talks, presentations and workshops from the Apache EU Roadshow or FOSS Backstage. You can find details of the combined Apache EU Roadshow and FOSS Backstage conference schedule below: https://foss-backstage.de/schedule?day=2018-06-13 Ticket prices go up on 8th June 2018 and we have a last minute discount code that anyone can use before the deadline: 15% discount code: ASF15_discount valid until June 7, 23:55 CET You can register at the following link: https://foss-backstage.de/tickets Our Apache booth and lounge will be open from 11th - 14th June for meetups, hacking or to simply relax between sessions. And we will be posting regular updates on social media throughout next week so please follow us on Twitter @ApacheCon Thank you for your continued support and we look forward to seeing you in Berlin! Thanks Sharan Foga, VP Apache Community Development http://apachecon.com/ PLEASE NOTE: You are receiving this message because you are subscribed to a user@ or dev@ list of one or more Apache Software Foundation projects. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [2/2] ant git commit: Bz 22370: followlinks attribute
2018-06-06 14:31 GMT+02:00 Stefan Bodewig :
> I guess here our API breaks down as we only ever deal with files or
> directories (outside of the symlink task).
>
FileSet documentation should be more explicit about the matter, in
particular explaining what "followsymlinks" really means.
Would the symlink be included in DirectoryScanner's "included files" or
> "included directories"? What will do to a symlink that is
> included but not followed.
>
"Files or directories" dichotomy might be a straitjacket, but symlinks can
be fitted into it depending on what their target is.
Dangling symlinks should go into notFollowedSymlinks.
Regarding , included but not followed symlink must be left as is (eg
directories are not filtered either).
>
> The current semantics of fileset's followsymlinks is deeply rooted in
> "we don't know how to deal with links and can only handle files and
> directories". I'm afraid a bunch of tasks will not do what you expect if
> DirectoryScanner suddenly returned File instances that are not real
> files/directories. Either they'd simply follow the link or break down -
> I assume in most cases it will be the former.
>
True; I wonder if we can have an interim solution when selectors could use
proper followsymlinks semantics,
but behaviour of DirectoryScanner is unchanged?
> > Consequently, I expect
> > followsymlinks="false" skipsymlinks="false" to behave as
> > followsymlinks="false";
>
> which would be the same as skipsymlinks="true", right?
>
No, under the new proposal that would include the symlinks as symlinks, not
files or directories.
> > whereas followsymlinks="true" skipsymlinks="true" is ambiguous: if
> > followsymlinks takes precedence, skipsymlinks is redundant; if
> > skipsymlinks takes precedence, then followsymlinks is ignored.
>
> So we'd need to decide what takes precedence and document it properly.
>
> As I said above, I don't think Ant's tasks are going to treat
> non-followed symlinks the way you'd expect them to. We could collect
> them separately and add a new getIncludedSymlinks method to
> DirectoryScanner so each task could do what it is supposed to do for
> not-followed links, but then we'll start documenting whether a given
> task X handles those links at all and if so what it does.
>
That's true; in the meantime, would it make sense to document what
"followsymlinks" means
in FileSet and what "followsymlinks" means in selectors that permit the
attribute?
There are other issues, like support for symlinks in archives (JRE does not
support them in
zip files [1], rather one -- like Gradle [2] -- must use Commons Compress).
Actually, there are a couple
of old Bugzilla issues addressing symlinks [3, 4] :-).
So, what's the plan?
Gintas
[1] https://bugs.openjdk.java.net/browse/JDK-8184973
[2] https://github.com/paleozogt/symzip-plugin
[3] https://bz.apache.org/bugzilla/show_bug.cgi?id=14320
[4] https://bz.apache.org/bugzilla/show_bug.cgi?id=15244
followsymlinks=true: ${toString:fileset}
followsymlinks=false: ${toString:fileset-symlinks}
symlink followsymlinks=true: ${toString:fileset-is-symlink}
symlink followsymlinks=false:
${toString:fileset-symlinks-is-symlink}
ownedby ${user.name}: ${toString:fileset-owned-by-user}
followsymlinks=false ownedby ${user.name}:
${toString:fileset-symlinks-owned-by-user}
group ${wheel.group}: ${toString:fileset-owned-by-group}
followsymlinks=false group ${wheel.group}:
${toString:fileset-symlinks-owned-by-group}
permissions ${file.permissions}:
${toString:fileset-with-permissions}
followsymlinks=false permissions ${file.permissions}:
${toString:fileset-symlinks-with-permissions}
AW: AntUnit Bug Causing Jenkins Failures
+1 Jan > -Ursprüngliche Nachricht- > Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com] > Gesendet: Montag, 4. Juni 2018 10:32 > An: dev@ant.apache.org > Betreff: Re: AntUnit Bug Causing Jenkins Failures > > Sounds fine to me. > > -Jaikiran > > > On 04/06/18 1:08 PM, Stefan Bodewig wrote: > > Hi all > > > > one of the recurring issues that make Jenkins builds fail is a > > thread-safety bug in AntUnit's log capturing code. This is supposed > to > > be fixed in AntUnit's master branch. > > > > I propose to build an alpha version of AntUnit and push that to Ant's > > lib/optional - and then monitor Jenkins for a while validating the > > fix. And if it seems to work, cut a new AntUnit release. > > > > This would break build jobs that try to populate lib/optional from > > existing repos (either via fetch.xml or Ivy or whatever) until the > > next AntUnit release has been published. I am not aware of any such > CI > > job but thought it would be good to ask before going forward. > > > > Stefan > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > > commands, e-mail: dev-h...@ant.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
