Re: thinking about new releases

[Jaikiran Pai]

+1. I don't have anything in a state that I can push to either of these 
branches, in the immediate future.


-Jaikiran


On 16/06/18 9:38 PM, Stefan Bodewig wrote:

Hi all

given https://dev.snyk.io/research/zip-slip-vulnerability lists Ant
1.9.12 as a release fixing a security problem it might be a good idea to
actually release 1.9.12 :-)

AFAICS there is no unfinished work in either branch, but I may be
wrong. I am aware there ar enhancement requests around javadoc that may
be worth waiting for for 1.10.x. Is anybody else planning to do
something that should be finished before creating release candidates?

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

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Jaikiran Pai]

I pushed a bunch of commits to address these issues and have now 
released newer binaries for 2.3.0-rc1 release and initiated a separate 
VOTE mail for it.


-Jaikiran


On 16/06/18 6:48 PM, Stefan Bodewig wrote:

Hi

please add your PGP key to dist.apache.org/release/ant/KEYS

* checksums and signatures are good
* for the files in updatesite it still contains .md5 and .sha but
   nothing stronger, please add stronger hashes and remove the md5 files
   unless they are read by eclipse
* source tarball and tag differ slightly (build.properties and
   releaese.adoc)
* the source tarball extracts everything to the current directory unlike
   the binary tarball which creates a subdirectory
   apache-ivyde-2.3.0.rc1-201806132023-RELEASE - I'm not complaining but
   it seems inconsistent
* 
org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar
   lacks LICENSE and NOTICE files

I'd prefer
org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar
to be fixed for this release and will vote -1 on a next release for such
an issue. The tag/source difference is acceptable to me but shouldn't
happen.

My vote is a +0

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

[VOTE] Apache IvyDE 2.3.0-rc1 release

[Jaikiran Pai]

This is a newer vote mail that I'm initiating for the 2.3.0-rc1 release 
of IvyDE.


The newly updated tag is here 
https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1


You can download the distribution from this URL: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/


The Eclipse p2 repository is here: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806171016-RELEASE/


The 2.3.0-rc1 release of IvyDE consists of the following changes:

* FIX: xml bomb in workspace causes hang in Ivy code during Search or 
Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
* FIX: Deadlock in classpath container 
(https://issues.apache.org/jira/browse/IVYDE-361)
* FIX: Typo in IvyResolveJob 
(https://issues.apache.org/jira/browse/IVYDE-362)
* FIX: User-selected configurations not checked in the viewer 
(https://issues.apache.org/jira/browse/IVYDE-378)
* FIX: Fix ClassCastException 
(https://issues.apache.org/jira/browse/IVYDE-386)


* NEW: Support for OSGi 'Bundle-Classpath' directive
* NEW: Basic support for the workspace resolver to find OSGi bundles 
managed by Ivy in the workspace

* NEW: Support for storing credentials securely


Do you vote for the release of these binaries?


-Jaikiran


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Java modules as Ant resources

[Gintautas Grigelionis]

Den lör 16 juni 2018 kl 17:47 skrev Stefan Bodewig :

> On 2018-06-16, Gintautas Grigelionis wrote:
>
> > if services would become a new mechanism for adding tasks, modules
> > would be of help by providing an API to discover them.
>
> Which may be a bit more tricky than it looks as currently tasks don't
> provide metadata about themselves (tag name, namespace uri) as this is
> handled by the surounding concepts like the antlib task.
>

Namespace is usually derived from package name and can be derived from
module name.
Tag name can be derived from service name, and it looks like provider
method [1] could be used as a mechanism for aliasing.

> Since modules are a jar with a twist, it seems that they could be
> > abstracted as resources if one would like to expose what's happening
> > under the hood/bonnet.
>
> The term resource might be overloaded and mean different things to you
> and me. In Ant terms a module would be a ResourceCollection, probably.
>

I see. Thanks for correction.


> > The question was more about whether that exposure would be useful (so
> > that there could be ModuleSets, etc).
>
> Something like a ZipGroupFileset?
>

Exactly.

Gintas

[1]
https://docs.oracle.com/javase/9/docs/api/java/util/ServiceLoader.html#developing-service-providers

Re: thinking about new releases

[Gintautas Grigelionis]

Den lör 16 juni 2018 kl 18:08 skrev Stefan Bodewig :

> Hi all
>
> given https://dev.snyk.io/research/zip-slip-vulnerability lists Ant
> 1.9.12 as a release fixing a security problem it might be a good idea to
> actually release 1.9.12 :-)
>
> AFAICS there is no unfinished work in either branch, but I may be
> wrong. I am aware there ar enhancement requests around javadoc that may
> be worth waiting for for 1.10.x. Is anybody else planning to do
> something that should be finished before creating release candidates?
>

I assume that you're referring to [1] and [2].
I merely documented the new switches of javadoc in Java 9+, but that's all.
+1 to release 1.9.12 and 1.10.4

Gintas

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62424
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=62441

thinking about new releases

[Stefan Bodewig]

Hi all

given https://dev.snyk.io/research/zip-slip-vulnerability lists Ant
1.9.12 as a release fixing a security problem it might be a good idea to
actually release 1.9.12 :-)

AFAICS there is no unfinished work in either branch, but I may be
wrong. I am aware there ar enhancement requests around javadoc that may
be worth waiting for for 1.10.x. Is anybody else planning to do
something that should be finished before creating release candidates?

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

[Gintautas Grigelionis]

Den lör 16 juni 2018 kl 17:29 skrev Stefan Bodewig :

> On 2018-06-16, Gintautas Grigelionis wrote:
>
> > 2018-06-16 15:42 GMT+02:00 Stefan Bodewig :
>
> >> On 2018-06-06, Gintautas Grigelionis wrote:
>
> >>> 2018-06-06 14:31 GMT+02:00 Stefan Bodewig :
>
>  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.
>
> >> DirectoryScanner's interface provides you with files and directories and
> >> as it stands these File objects may actually by symlinks and the
> >> implicit expectation is that whoever uses them follows the links and in
> >> the end works on the target.
>
> > If things work as you believe, then it's simple -- FileSets just pass
> > the symlinks to consumers which may or may not check whether File
> > objects are symlinks. In the former case, they might use the new
> > semantics, in the latter case nothing's changed.
>
> In that case - the later - the followsymlinks="false" and
> skipsymlinks="false" would behave the same as followsymlinks="true" for
> those who do not check whether a file is a symlink, correct?
>

Correct.

In case of followsymlinks="false" and skipsymlinks="false" I expect
FileSets or
DirSets to contain symlinks as such; but well-behaved symlink-unaware tasks
would follow the symlinks effectively behaving as if followsymlinks="true"
(the default) with the old semantics.


> >>> I wonder if we can have an interim solution when selectors could use
> >>> proper followsymlinks semantics, but behaviour of DirectoryScanner is
> >>> unchanged?
>
> >> You may give it a try, I'm not sure exactly what you mean.
>
> > I attached a test case to one of my previous e-mails to illustrate
> > what I mean.
>
> The mailing list is configured to not allow attachments.
>

I just included in my reply on 6/6 at 21.30 without describing what it was
:-(
See [1] below.

> One part of it would be symlink support in archives (zip and tar).
>
> To which extent?
>
> When creating archives you may need to decide whether you want to use a
> relative or an absolute path to the target (I must admit I have no idea
> whether nio allows us to know how the target has been specified as
> opposed to just what the target is). When extracting and trying to
> re-create symlinks you may also need to watch out for path traversal
> problems.
>

To the extent where tarfilesets and zipfilesets can make use of symlinks in
the same way as filesets would do.
I am aware of extra complexity with path traversals that may cause loops
etc.

What is your time-frame for this? I've been thinking about cutting Ant
> releases soonish, but this is something for a different thread.
>

This is for the future, I'm quite content with what I could do with
selectors so far
(unless I missed something). I'm looking forward to spend time on symlinks
in other parts of Ant later this summer.

Gintas

[1] http://marc.info/?l=ant-dev&m=152833304425275&w=2

Re: Java modules as Ant resources

[Stefan Bodewig]

On 2018-06-16, Gintautas Grigelionis wrote:

> if services would become a new mechanism for adding tasks, modules
> would be of help by providing an API to discover them.

Which may be a bit more tricky than it looks as currently tasks don't
provide metadata about themselves (tag name, namespace uri) as this is
handled by the surounding concepts like the antlib task.

I agree, if we want to add an additional mechanism it should probably
use ServiceLoader and thus be supported by modules.

> Since modules are a jar with a twist, it seems that they could be
> abstracted as resources if one would like to expose what's happening
> under the hood/bonnet.

The term resource might be overloaded and mean different things to you
and me. In Ant terms a module would be a ResourceCollection, probably.

> The question was more about whether that exposure would be useful (so
> that there could be ModuleSets, etc).

Something like a ZipGroupFileset?

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

[Stefan Bodewig]

On 2018-06-16, Gintautas Grigelionis wrote:

> 2018-06-16 15:42 GMT+02:00 Stefan Bodewig :

>> On 2018-06-06, Gintautas Grigelionis wrote:

>>> 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.

>> You are right. In a Java world where you couldn't really do anything
>> with symlinks it has probably been clear implicitly.

> I would argue that things are less clear implicitly since Java 7, we just
> seemed to ignore it.

Right.

 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.

>> DirectoryScanner's interface provides you with files and directories and
>> as it stands these File objects may actually by symlinks and the
>> implicit expectation is that whoever uses them follows the links and in
>> the end works on the target.

> If things work as you believe, then it's simple -- FileSets just pass
> the symlinks to consumers which may or may not check whether File
> objects are symlinks. In the former case, they might use the new
> semantics, in the latter case nothing's changed.

In that case - the later - the followsymlinks="false" and
skipsymlinks="false" would behave the same as followsymlinks="true" for
those who do not check whether a file is a symlink, correct?

>>> I wonder if we can have an interim solution when selectors could use
>>> proper followsymlinks semantics, but behaviour of DirectoryScanner is
>>> unchanged?

>> You may give it a try, I'm not sure exactly what you mean.

> I attached a test case to one of my previous e-mails to illustrate
> what I mean.

The mailing list is configured to not allow attachments.

> Hmm, I've got an impression that Commons Compress was more capable;
> if Ant can handle zip and tar files with symlinks, then a big part of the
> job is done.

Commons Compress and Ant are the same in that you can create an archive
that contains entries that look like symlinks to tools that know how to
handle them. And at least in the case of tar and Commons Compress they
will tell you a certain entry is a symlink (for zip you need to detect
that yourself by looking at the flags).

In that sense we can create archives with symlinks in them and we will
be able to detect an entry inisde of an archive is a symlink. I'd have
to check whether we need to backport anything from Commons Compress in
order to make the little symlink support that is there is also available
to Ant.

>>> So, what's the plan?

>> It's your itch, what is your plan? :-)

> One part of it would be symlink support in archives (zip and tar).

To which extent?

When creating archives you may need to decide whether you want to use a
relative or an absolute path to the target (I must admit I have no idea
whether nio allows us to know how the target has been specified as
opposed to just what the target is). When extracting and trying to
re-create symlinks you may also need to watch out for path traversal
problems.

What is your time-frame for this? I've been thinking about cutting Ant
releases soonish, but this is soemthing for a different threat.

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

[Gintautas Grigelionis]

2018-06-16 15:42 GMT+02:00 Stefan Bodewig :

> On 2018-06-06, Gintautas Grigelionis wrote:
>
> > 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.
>
> You are right. In a Java world where you couldn't really do anything
> with symlinks it has probably been clear implicitly.
>

I would argue that things are less clear implicitly since Java 7, we just
seemed to ignore it.
Too bad change of Java ownership left things unfinished, as in archive
support.


> >> 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.
>
> DirectoryScanner's interface provides you with files and directories and
> as it stands these File objects may actually by symlinks and the
> implicit expectation is that whoever uses them follows the links and in
> the end works on the target.
>

If things work as you believe, then it's simple -- FileSets just pass the
symlinks to consumers
which may or may not check whether File objects are symlinks. In the former
case, they might
use the new semantics, in the latter case nothing's changed.


> We could add new array of symlinks that are not supposed to be followed
> but most tasks would simply ignore them (all tasks that we don't change
> ourselves).
>
> > Dangling symlinks should go into notFollowedSymlinks.  Regarding
> > , included but not followed symlink must be left as is (eg
> > directories are not filtered either).
>
> Probably. There will not be a interpretation that will work for all
> tasks, it will be on a task by task basis. As we can only control the
> tasks that are inside of Ant's codebase, this means we must not change
> the interpretation of the files and directories returned by
> DirectoryScanner at all.
>

That is fine as long the tasks follow symlinks in a FileSet and no
additional structures for keeping them is needed.
If there are tasks that might choke on/skip a File which is a symlink, or,
as is the case with shared libraries on U*X,
add multiple copies of the same file to an archive by following symlinks,
then there's more work to do.


> > I wonder if we can have an interim solution when selectors could use
> > proper followsymlinks semantics, but behaviour of DirectoryScanner is
> > unchanged?
>
> You may give it a try, I'm not sure exactly what you mean.
>

I attached a test case to one of my previous e-mails to illustrate what I
mean.


> >>> 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.
>
> Where would DirectoryScanner put those included symlinks?
>

Either treat them as files/directories, or put in a separate structure, as
discussed above.

> in the meantime, would it make sense to document what "followsymlinks"
> > means in FileSet and what "followsymlinks" means in selectors that
> > permit the attribute?
>
> We must document that, I'd say :-)
>

That's done.


> > 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] :-).
>
> I know Commons Compress pretty well ;-) and it doesn't really support
> symlinks in archives either. Given that Ant's zip package is the parent
> of Compress' zip support we should be able to do whatever Commons
> Compress can do here as well. There is a good reason why we don't use
> java.util.zip at all.
>

Hmm, I've got an impression that Commons Compress was more capable;
if Ant can handle zip and tar files with symlinks, then a big part of the
job is done.


> > So, what's the plan?
>
> It's your itch, what is your plan? :-)
>

One part of it would be symlink support in archives (zip and tar).
Another part would be investigating of what DirectoryScanner could do and
what is
expected of FileSet/DirSet, then deciding whether it is possible to fit the
symlinks in there.

Gintas

Re: Java modules as Ant resources

[Gintautas Grigelionis]

2018-06-16 16:04 GMT+02:00 Stefan Bodewig :

> On 2018-06-16, Gintautas Grigelionis wrote:
>
> > 2018-06-16 15:30 GMT+02:00 Stefan Bodewig :
>
> >> On 2018-06-10, Gintautas Grigelionis wrote:
>
> >>> I would treating Java modules as Ant resources help in this scenario?
>
> >> What exactly - beyond using a module as a zipfileset - would you want
> >> to do?
>
> > What about dependency graphs and service discovery? :-) [1]
>
> I'm afraid I'm too slow today. What exactly do you mean when you say you
> want to support Java modules as Ant resources?
>
> An Ant Resource (the class in org.apache.tools.ant.types) is something
> we can read from like a file or an URI and sometimes write to. I don't
> think this is what you have in mind as we can already do that to a Java
> module (which is a jar) and it is not related to dependency graphs or
> service discovery at all.
>

Sorry for not presenting the idea clearly because of time skip: if services
would become
a new mechanism for adding tasks, modules would be of help by providing an
API to discover them.
Since modules are a jar with a twist, it seems that they could be
abstracted as resources
if one would like to expose what's happening under the hood/bonnet.
The question was more about whether that exposure would be useful
(so that there could be ModuleSets, etc).

Gintas

Re: Java modules as Ant resources

[Stefan Bodewig]

On 2018-06-16, Gintautas Grigelionis wrote:

> 2018-06-16 15:30 GMT+02:00 Stefan Bodewig :

>> On 2018-06-10, Gintautas Grigelionis wrote:

>>> I would treating Java modules as Ant resources help in this scenario?

>> What exactly - beyond using a module as a zipfileset - would you want
>> to do?

> What about dependency graphs and service discovery? :-) [1]

I'm afraid I'm too slow today. What exactly do you mean when you say you
want to support Java modules as Ant resources?

An Ant Resource (the class in org.apache.tools.ant.types) is something
we can read from like a file or an URI and sometimes write to. I don't
think this is what you have in mind as we can already do that to a Java
module (which is a jar) and it is not related to dependency graphs or
service discovery at all.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Java modules as Ant resources

[Gintautas Grigelionis]

2018-06-16 15:30 GMT+02:00 Stefan Bodewig :

> On 2018-06-10, Gintautas Grigelionis wrote:
>
> > I would treating Java modules as Ant resources help in this scenario?
>
> What exactly - beyond using a module as a zipfileset - would you want
> to do?
>

What about dependency graphs and service discovery? :-) [1]

Gintas

[1]
https://docs.oracle.com/javase/9/docs/api/java/lang/module/package-summary.html

[CANCEL] [VOTE] Apache IvyDE 2.3.0-rc1 release

[Jaikiran Pai]

Given some of the valid issues that Stefan has raised with this released 
instance, I'm cancelling this vote. This is a first release after a long 
time and I plan to have this as clean as possible. I will send out a new 
vote mail once I sort out these issues.


-Jaikiran


On 16/06/18 6:48 PM, Stefan Bodewig wrote:

Hi

please add your PGP key to dist.apache.org/release/ant/KEYS

* checksums and signatures are good
* for the files in updatesite it still contains .md5 and .sha but
   nothing stronger, please add stronger hashes and remove the md5 files
   unless they are read by eclipse
* source tarball and tag differ slightly (build.properties and
   releaese.adoc)
* the source tarball extracts everything to the current directory unlike
   the binary tarball which creates a subdirectory
   apache-ivyde-2.3.0.rc1-201806132023-RELEASE - I'm not complaining but
   it seems inconsistent
* 
org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar
   lacks LICENSE and NOTICE files

I'd prefer
org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar
to be fixed for this release and will vote -1 on a next release for such
an issue. The tag/source difference is acceptable to me but shouldn't
happen.

My vote is a +0

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

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Jaikiran Pai]

Thanks Stefan, I'll fix these issues and send out a new voting mail.

-Jaikiran

On Saturday, June 16, 2018, Stefan Bodewig  wrote:
> Hi
>
> please add your PGP key to dist.apache.org/release/ant/KEYS
>
> * checksums and signatures are good
> * for the files in updatesite it still contains .md5 and .sha but
>   nothing stronger, please add stronger hashes and remove the md5 files
>   unless they are read by eclipse
> * source tarball and tag differ slightly (build.properties and
>   releaese.adoc)
> * the source tarball extracts everything to the current directory unlike
>   the binary tarball which creates a subdirectory
>   apache-ivyde-2.3.0.rc1-201806132023-RELEASE - I'm not complaining but
>   it seems inconsistent
> *
org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar
>   lacks LICENSE and NOTICE files
>
> I'd prefer
>
org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar
> to be fixed for this release and will vote -1 on a next release for such
> an issue. The tag/source difference is acceptable to me but shouldn't
> happen.
>
> My vote is a +0
>
> 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

[Stefan Bodewig]

On 2018-06-06, Gintautas Grigelionis wrote:

> 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.

You are right. In a Java world where you couldn't really do anything
with symlinks it has probably been clear implicitly.

>> 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.

DirectoryScanner's interface provides you with files and directories and
as it stands these File objects may actually by symlinks and the
implicit expectation is that whoever uses them follows the links and in
the end works on the target.

We could add new array of symlinks that are not supposed to be followed
but most tasks would simply ignore them (all tasks that we don't change
ourselves).

> Dangling symlinks should go into notFollowedSymlinks.  Regarding
> , included but not followed symlink must be left as is (eg
> directories are not filtered either).

Probably. There will not be a interpretation that will work for all
tasks, it will be on a task by task basis. As we can only control the
tasks that are inside of Ant's codebase, this means we must not change
the interpretation of the files and directories returned by
DirectoryScanner at all.

> I wonder if we can have an interim solution when selectors could use
> proper followsymlinks semantics, but behaviour of DirectoryScanner is
> unchanged?

You may give it a try, I'm not sure exactly what you mean.

>>> 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.

Where would DirectoryScanner put those included symlinks?

> in the meantime, would it make sense to document what "followsymlinks"
> means in FileSet and what "followsymlinks" means in selectors that
> permit the attribute?

We must document that, I'd say :-)

> 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] :-).

I know Commons Compress pretty well ;-) and it doesn't really support
symlinks in archives either. Given that Ant's zip package is the parent
of Compress' zip support we should be able to do whatever Commons
Compress can do here as well. There is a good reason why we don't use
java.util.zip at all.

> So, what's the plan?

It's your itch, what is your plan? :-)

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Java modules as Ant resources

[Stefan Bodewig]

On 2018-06-10, Gintautas Grigelionis wrote:

> I would treating Java modules as Ant resources help in this scenario?

What extactly - beyond using a module as a zipfileset - would you want
to do?

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Stefan Bodewig]

Hi

please add your PGP key to dist.apache.org/release/ant/KEYS

* checksums and signatures are good
* for the files in updatesite it still contains .md5 and .sha but
  nothing stronger, please add stronger hashes and remove the md5 files
  unless they are read by eclipse
* source tarball and tag differ slightly (build.properties and
  releaese.adoc)
* the source tarball extracts everything to the current directory unlike
  the binary tarball which creates a subdirectory
  apache-ivyde-2.3.0.rc1-201806132023-RELEASE - I'm not complaining but
  it seems inconsistent
* 
org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar
  lacks LICENSE and NOTICE files

I'd prefer
org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar
to be fixed for this release and will vote -1 on a next release for such
an issue. The tag/source difference is acceptable to me but shouldn't
happen.

My vote is a +0

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Stefan Bodewig]

On 2018-06-16, Gintautas Grigelionis wrote:

> There is yet another point (please bear with me) regarding manual
> installation instructions. In Eclipse 4 series (which is our baseline) the
> "dropins" have a separate directory [1]; I don't think manual copying
> directly to features + plugins works anymore and the documentation must be
> changed accordingly. I believe Nicolas had to change the build scripts for
> that reason, too.

The documentation is on the website which can be updated independent of
any release, fortunately.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Gintautas Grigelionis]

I suppose that deserves a mention in the doc/src/dev...

Gintas

2018-06-14 19:15 GMT+02:00 Nicolas Lalevée :

> Just a quick comment on the mirror url not working. The page is telling
> "The requested file or directory is not on the mirrors. »
> And indeed, the artifacts are not published yet to the final location, the
> release is not accepted yet.
>
> Nicolas
>
>
>
> > Le 14 juin 2018 à 10:19, Gintautas Grigelionis 
> a écrit :
> >
> > 2018-06-14 8:15 GMT+02:00 Stefan Bodewig  bode...@apache.org>>:
> >
> >> On 2018-06-13, Gintautas Grigelionis wrote:
> >>
> >>> org.xml.sax.SAXParseException; systemId:
> >>> http://ant.apache.org/ivy/ivyde/updatesite/p2-mirrors--xml.
> >> cgi?path=ivyde-2.3.0.rc1-201806132023-RELEASE&countryCode=
> >> se&timeZone=1&format=xml;
> >>> lineNumber: 39; columnNumber: 3; Element type "link" lack matching end
> >> tag
> >>> "".
> >>
> >> When I follow the link above, I get an HTML page which is not
> >> well-formed XML, so the messages are to be expected.
> >>
> >> BTW, wherever thos link comes from, it would be good if it used https
> >> rather than http.
> >
> >
> > I followed the link to the source in svn
> >
> > https://svn.apache.org/viewvc/ant/site/ivyde/production/
> updatesite/p2-mirrors--xml.cgi?view=markup  viewvc/ant/site/ivyde/production/updatesite/p2-
> mirrors--xml.cgi?view=markup>
> >
> > #!/bin/sh
> > # Wrapper script around mirrors.cgi script
> > # (we must change to that directory in order for python to pick up the
> > # python includes correctly)
> > cd /www/www.apache.org/dyn/mirrors 
> > /www/www.apache.org/dyn/mirrors/mirrors.cgi  mirrors/mirrors.cgi> $
> >
> > It seems that mirrors.cgi bails out, since it redirects to a (correct
> > HTML-wise, incorrect XML-wise) page containing
> >
> > The requested file or directory is *not* on the mirrors.
> >
> > I wonder whether there is some documentation available on what output
> > the CGI script (and corresponding HTML template?) should produce.
> > Apparently, they do not work as intended since last changes were made
> > 6 years ago.
> >
> > Gintas
>
>