AW: ant task mail fails on jdk10

[jhm]

We already have something:
mail: "This task may depend on external libraries that are not included in
the Ant distribution. See Library Dependencies for more information."
dependencies: 
"mail.jar   Mail task with Mime encoding, and the MimeMail task
http://www.oracle.com/technetwork/java/index-138643.html
 activation.jar Mail task with Mime encoding, and the MimeMail task
http://www.oracle.com/technetwork/java/javase/jaf-135115.html;

mail.jar could be downloaded via "ant -f fetch.xml javamail", but activation
has to be installed.


So what changed with Java10?


Jan


> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Montag, 2. Juli 2018 18:00
> An: dev@ant.apache.org; Simon IJskes - QCG
> Betreff: Re: ant task mail fails on jdk10
> 
> Thank you, Simon
> 
> On 2018-07-02, Simon IJskes - QCG wrote:
> 
> > As bugzilla is unreachable for now:
> 
> > 
> >  > subject="Testemail"  >
> > 
> > 
> > 
> 
> > $ JAVA_HOME=/usr/lib/jvm/java-8-oracle/
> > ~/opt/apache-ant-1.10.4/bin/ant _testmail
> 
> > runs ok.
> 
> > _testmail:
> >  [mail] Sending email: Testemail
> >  [mail] Sent email with 0 attachments
> 
> 
> > $ JAVA_HOME=/usr/lib/jvm/java-10-oracle/
> > ~/opt/apache-ant-1.10.4/bin/ant _testmail
> 
> > _testmail:
> >  [mail] Failed to send email: javax.activation.DataHandler
> 
> JAF has been removed from Java 10, so now you need to provide its
> replacement https://github.com/javaee/activation when starting Ant.
> 
> I don't really think we need to change anything inside of Ant but
> should document the fact and likely add something to the FAQ in
> addition to the mail task's manual page.
> 
> 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: ant task mail fails on jdk10

[Stefan Bodewig]

Thank you, Simon

On 2018-07-02, Simon IJskes - QCG wrote:

> As bugzilla is unreachable for now:

> 
>  subject="Testemail"  >
> 
> 
> 

> $ JAVA_HOME=/usr/lib/jvm/java-8-oracle/
> ~/opt/apache-ant-1.10.4/bin/ant _testmail

> runs ok.

> _testmail:
>  [mail] Sending email: Testemail
>  [mail] Sent email with 0 attachments


> $ JAVA_HOME=/usr/lib/jvm/java-10-oracle/
> ~/opt/apache-ant-1.10.4/bin/ant _testmail

> _testmail:
>  [mail] Failed to send email: javax.activation.DataHandler

JAF has been removed from Java 10, so now you need to provide its
replacement https://github.com/javaee/activation when starting Ant.

I don't really think we need to change anything inside of Ant but should
document the fact and likely add something to the FAQ in addition to the
mail task's manual page.

Stefan

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

ant task mail fails on jdk10

[Simon IJskes - QCG]

As bugzilla is unreachable for now:


subject="Testemail"  >





$ JAVA_HOME=/usr/lib/jvm/java-8-oracle/ ~/opt/apache-ant-1.10.4/bin/ant 
_testmail


runs ok.

_testmail:
 [mail] Sending email: Testemail
 [mail] Sent email with 0 attachments


$ JAVA_HOME=/usr/lib/jvm/java-10-oracle/ ~/opt/apache-ant-1.10.4/bin/ant 
_testmail


_testmail:
 [mail] Failed to send email: javax.activation.DataHandler

BUILD FAILED
../build.xml:6: java.lang.ClassNotFoundException: 
javax.activation.DataHandler

at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:466)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:566)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:291)
	at 
org.apache.tools.ant.taskdefs.email.EmailTask.execute(EmailTask.java:457)

at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)

at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)
at org.apache.tools.ant.Project.executeTarget(Project.java:1361)
	at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)

at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:834)
at org.apache.tools.ant.Main.startAnt(Main.java:223)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)


--
QCG, Software development, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

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

Jenkins-Builds failing

[Jan Matèrne]

Several of our Jenkins builds are failing:

 

IvyDE: 

https://builds.apache.org/view/A/view/Ant/job/IvyDE/

https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console

Can't get
http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208
151217/wtp4x-R-3.4.2-20130208151217.zip to
/home/jenkins/jenkins-slave/workspace/IvyDE/dependencies/wtp4x-R-3.4.2-20130
208151217.zip

 

The source URL gives a 404.

 

 

AntLib - AntUnit

https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/

https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/lastBuild/conso
le

[ivy:resolve]   Server access error at url
https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testuti
l-1.8.1.pom (javax.net.ssl.SSLException: Received fatal alert:
protocol_version)

 

 

AntLib - SVN

same problem as for AU

 

 

Ivy

https://builds.apache.org/view/A/view/Ant/job/Ivy/

https://builds.apache.org/view/A/view/Ant/job/Ivy/lastBuild/console

same problem as for AU

 

 

Ant Nightly

https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/

https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/lastBuild/console

all runs fine, but "Archiving artifacts" requires lt of time …

 

 

Ideas?

 

Jan

AW: Testing IvyDE

[jhm]

Due the update the permission for cancelling a job is gone.
https://jenkins.io/changelog-stable/
Notable changes since 2.107.3:
* It is no longer possible to rename jobs from their configuration page. Jobs 
now have a link in the side panel titled "Rename" that links to a page 
specifically dedicated to renaming jobs.
* The Job/Build permission no longer implies the Job/Cancel permission. The 
latter needs to be granted explicitly to users who previously got it via this 
relationship.
...

I'll check how we get that permission back (global grant by admin, posting a 
list via mail, jira...)


Jan

> -Ursprüngliche Nachricht-
> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> Gesendet: Sonntag, 1. Juli 2018 21:30
> An: 'Ant Developers List'
> Betreff: AW: Testing IvyDE
> 
> > It looks like Ant nightly is stuck (possibly due to plugin update in
> > Jenkins) and it's blocking all other builds.
> >
> > Gintas
> 
> I can't do it myself so I'll ask for killing the job.
> 
> Jan
> 
> 
> -
> 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

JDK 11 is now in Rampdown Phase one

[Rory O'Donnell]

Hi Stefan,

*JDK 11 is now in Rampdown Phase one***
The overall feature set is frozen. No further JEPs will be targeted to 
this release.We’ve forked the main-line source repository, jdk/jdk, to 
the jdk/jdk11 stabilization repository. Any changes pushed to jdk/jdk or 
jdk/client are now bound for JDK 12.


 * For more details , see Mark Reinhold's email to jdk-dev mailing list
   [1]
 * The Rampdown Phase one process  [2].

*Note: -* Early-Access build archive format on Windows has changed to zip.

Since our last email the following JEPs have been targeted to JDK 11 :

 * 181: Nest-Based Access Control
 * 315: Improve Aarch64 Intrinsics
 * 330: Launch Single-File Source-Code Programs
 * 331: Low-Overhead Heap Profiling
 * 332: Transport Layer Security (TLS) 1.3
 * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
 * 335: *Deprecate the Nashorn JavaScript Engine*
 * 336: *Deprecate the Pack200 Tools and API*

Other important changes since last email:

   Build 19:
   JDK-8205043  : G1
   enables adaptive parallel reference processing by default
   Build 18:
   JDK-8196141  : Add
   GoDaddy root certificates
   JDK-8204243  :
   *remove Thread.destroy() and Thread.stop(Throwable)*
   JDK-8202088  :
   Japanese New Era Implementation
   Build 17:
   JDK-8189949  :
   Remove Baltimore Cybertrust Code Signing CA
   JDK-8191031  :
   Remove several Symantec Root CAs
   JDK-8072996  :
   Deprecate stream-based GSSContext methods
   Build 16:
   JDK-8191844  :
   Remove SECOM root

Rgds, Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001509.html
[2] http://openjdk.java.net/projects/jdk/11/#Schedule

Re: FileUtils.normalize/isLeadingPath have bitten me

[Stefan Bodewig]

Hi Nicolas

many thanks for lending an extra pair of eyes. I'll add a few more
tests.

Stefan

On 2018-07-01, Nicolas Lalevée wrote:

> At my first read of the code I wondered if paths ending with slash are 
> properly handled in every case. After more careful reading, it is seems ok. 
> Maybe some unit tests about it would be nice, just to be sure.

> Then, about tackling the bug, I am on the same page as you both. It looks 
> good to me.

> Nicolas

>> Le 1 juil. 2018 à 11:27, Stefan Bodewig  a écrit :

>> On 2018-06-28, Stefan Bodewig wrote:

>>> On 2018-06-28, Jaikiran Pai wrote:

 Which then makes me wonder - in the context of this specific
 untar/expand/unzip issue, should we probably be using a different
 custom very specific logic (which relies on canonical files and
 getParent()) instead of a call to isLeadingPath()?

>>> Probably. I used isLeadingPath because it has been already there - and )
>>> simply didn't realize it wouldn't do what I expected it to.

>> I decided to "fix" isLeadingPath for this edge case and add a method
>> using canonical paths instead - and use that in unzip and friends.

>> Please have a look at the proposed solution, I won't close the Bugzilla
>> issue before we have agreed this is the proper fix.

>> Cheers

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

Re: FileUtils.normalize/isLeadingPath have bitten me

[Stefan Bodewig]

On 2018-07-02, Jaikiran Pai wrote:

> Sorry that I couldn't get to this earlier. My plan to spend more time
> on this during the weekend didn't work out.

It's been a weekend :-)

No worries.

> I just checked the commits related to this and it looks mostly
> correct. However, I am still not 100% sure we have covered it all with
> this new method that was introduced[1] and used in the unzip
> part. What I mean is, the API expectations are right. However the
> implementation _might_ need a bit of rethink since it still relies on
> path string comparison (checks like endsWith) instead of a getParent()
> check.

I mostly kept the string comparison for performance reasons, but maybe
that point is moot and performance should not be a concern
here. Rewriting it to use getParent is no problem at all.

> My suspicion is all theoretical at the moment and may not even be
> valid. I'm going to build the latest changes of Ant give it a try
> against a bunch of my theoretical use cases and see if my suspicions
> are really valid or not.

Thank you

  Stefan


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

Re: FileUtils.normalize/isLeadingPath have bitten me

[Jaikiran Pai]

Hi Stefan,

Sorry that I couldn't get to this earlier. My plan to spend more time on 
this during the weekend didn't work out.


I just checked the commits related to this and it looks mostly correct. 
However, I am still not 100% sure we have covered it all with this new 
method that was introduced[1] and used in the unzip part. What I mean 
is, the API expectations are right. However the implementation _might_ 
need a bit of rethink since it still relies on path string comparison 
(checks like endsWith) instead of a getParent() check. My suspicion is 
all theoretical at the moment and may not even be valid. I'm going to 
build the latest changes of Ant give it a try against a bunch of my 
theoretical use cases and see if my suspicions are really valid or not.


[1] 
https://github.com/apache/ant/commit/6a41d62cb9ab4e640b72cb4de42a6c211dea645d


-Jaikiran


On 01/07/18 2:57 PM, Stefan Bodewig wrote:

On 2018-06-28, Stefan Bodewig wrote:


On 2018-06-28, Jaikiran Pai wrote:

Which then makes me wonder - in the context of this specific
untar/expand/unzip issue, should we probably be using a different
custom very specific logic (which relies on canonical files and
getParent()) instead of a call to isLeadingPath()?

Probably. I used isLeadingPath because it has been already there - and )
simply didn't realize it wouldn't do what I expected it to.

I decided to "fix" isLeadingPath for this edge case and add a method
using canonical paths instead - and use that in unzip and friends.

Please have a look at the proposed solution, I won't close the Bugzilla
issue before we have agreed this is the proper fix.

Cheers

 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