Hello ewh,
Thank you for these experiments and reporting the results. This
certainly helped me decide which way to go about it. When I had
initially tried using "allow" as a Java class (as done in NetBeans), I
was unsure if that would be the right way to go. It didn't feel clean
and I thought
Figured give an update wrt our project: The method used by Netbeans project
as cited by Jan appears to work.
I have not done full testing wrt to Ant as it appears the use of the
SecurityManager in Ant is limited in scope to invoking another Java class
in the same JVM, which we do not seem to do (n
On 2022-03-06, Matt Benson wrote:
> I fully planned to do so once I know what next version number we'd be
> targeting.
Ah, thanks
> Minor or point?
I believe the last time we did a minor release has been five years ago,
it's just not going on that much anymore :-)
Most likely we'll have to dro
I fully planned to do so once I know what next version number we'd be
targeting. Minor or point?
Matt
On Sun, Mar 6, 2022, 7:43 AM Stefan Bodewig wrote:
> On 2022-03-06, Stefan Bodewig wrote:
>
> > On 2022-02-25, wrote:
>
> >>>
> >>>default
> >>>the default value of the attribute
> >
On 2022-03-06, Stefan Bodewig wrote:
> On 2022-02-25, wrote:
>>>
>>>default
>>>the default value of the attribute
>>>No
>>>
> please add "since ..." somewhere here and a small note in WHATSNEW.
and please do the same for the other attributes an elements you've
added.
Stefan
-
On 2022-02-25, wrote:
>>
>>default
>>the default value of the attribute
>>No
>>
please add "since ..." somewhere here and a small note in WHATSNEW.
Thanks
Stefan
-
To unsubscribe, e-mail: dev-unsubscr.
Hello Jan,
On 08/02/22 12:04 pm, Jan Lahoda wrote:
On Tue, Feb 8, 2022 at 5:53 AM Jaikiran Pai wrote:
Hello Earl,
On 08/02/22 12:59 am, Earl Hood wrote:
How exactly does setting the sysprop for only 18 and 19 allow folks to
test
their stuff? If Ant currently depends on the security manag
Hello Stefan,
On 08/02/22 1:15 am, Stefan Bodewig wrote:
On 2022-02-07, Jaikiran Pai wrote:
So the launch scripts (the Linux one and the .bat for Windows one)
have both been updated to set this system property only for Java 18
and 19. I expect this to be a temporary thing till the new API is
a
On Tue, Feb 8, 2022 at 5:53 AM Jaikiran Pai wrote:
> Hello Earl,
>
> On 08/02/22 12:59 am, Earl Hood wrote:
> > How exactly does setting the sysprop for only 18 and 19 allow folks to
> test
> > their stuff? If Ant currently depends on the security manager to
> operate,
> > why not set the syspro
On 2022-02-08, Jaikiran Pai wrote:
> Hello Earl,
> On 08/02/22 12:59 am, Earl Hood wrote:
>> How exactly does setting the sysprop for only 18 and 19 allow folks to test
>> their stuff? If Ant currently depends on the security manager to operate,
>> why not set the sysprop regardless, then remove
Hello Earl,
On 08/02/22 12:59 am, Earl Hood wrote:
How exactly does setting the sysprop for only 18 and 19 allow folks to test
their stuff? If Ant currently depends on the security manager to operate,
why not set the sysprop regardless, then remove in future when a
replacement API exists?
Jav
On 2022-02-07, Jaikiran Pai wrote:
> So the launch scripts (the Linux one and the .bat for Windows one)
> have both been updated to set this system property only for Java 18
> and 19. I expect this to be a temporary thing till the new API is
> available. Once the new API is available, I think we s
How exactly does setting the sysprop for only 18 and 19 allow folks to test
their stuff? If Ant currently depends on the security manager to operate,
why not set the sysprop regardless, then remove in future when a
replacement API exists?
Since I work on a project that embeds Ant and uses it API,
Hello Stefan,
I was planning to send out a mail about this change later tonight. But
good you brought this up. To give some background, the security manager
changes starting Java 18 make it such that setting of the security
manager at runtime now throws an exception, which effectively fails al
On 2022-02-07, wrote:
> - if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ]; then
> + if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ] || [
> "$JAVA_SPEC_VERSION" = "java.specification.version=19" ]; then
Bourne shell's case may make this more
readable (not sure whether
On 2021-03-21, Jaikiran Pai wrote:
> On 20/03/21 11:31 pm, bode...@apache.org wrote:
> + */
> + public class NullOutputStream extends OutputStream {
> +/**
> + * Shared instance which is safe to use concurrently as the stream
> + * doesn't hold any state at all.
> + */
> +pub
On 20/03/21 11:31 pm, bode...@apache.org wrote:
...
+ */
+public class NullOutputStream extends OutputStream {
+
+/**
+ * Shared instance which is safe to use concurrently as the stream
+ * doesn't hold any state at all.
+ */
+public static NullOutputStream INSTANCE = new Nu
with the only binding +1s being Jaikiran's and mine, the vote has
failed. We may want to revisit the issue at a later time.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...
On 2020-05-21, Maarten Coene wrote:
> could you explain a bit more why we should EOL the 1.9.x branch?
Honestly, I only wanted to make public what I believe is the case
anyway. Whether the branch is alive or not pnly depends on whether
people push changes to it. While preparing the last 1.
Hello Maarten,
For me the main reason why I initially proposed EOLing 1.9.x branch (and
releases) is because creating new fixes for it and then releasing it is
becoming cumbersome. Java APIs have moved on from the Java 5 days a long
way (even just comparing against Java 8 itself). What that means
Hi Stefan,
could you explain a bit more why we should EOL the 1.9.x branch?
Personally, I think it's a mistake to abondon the Java 5 support.
I think there are still projects around targetting java 5, 6 or 7 using Ant as
build tool.
For instance, one of the reasons we are still using Ant
+1 if that counts. I don't think there's much use of Java 7- nowadays,
especially when networked.
Gintas
On Wed, 20 May 2020 at 13:24, Stefan Bodewig wrote:
> It looks as if the vote will simply not pass because of a lack of
> participation - which is certainly fine. Unless we get more binding
It looks as if the vote will simply not pass because of a lack of
participation - which is certainly fine. Unless we get more binding
votes, I'll close the vote as failed soon.
Mayby we should have discussed the motion here before I created the
vote. Therefore I have created this separate thread.
+1 for making 1.9.15 the last release for 1.9.x series and then retiring
the 1.9.x branch.
-Jaikiran
On 12/05/20 4:03 pm, Stefan Bodewig wrote:
> Hi all
>
> I was under the impression we had already voted on this but my
> recollections was wrong.
>
> Wnen 1.10.7 has been rele
seems we are not
really using the 1.9.x branch anymore and 1.9.15 is "complete".
Therefore I'd like to reduce the merge effort by declaring 1.9.15 the
final Java5 compatible release and retire the branch.
As it is not clear whether the vote for the 1.9.15 release will pass at
all, thi
On 2020-05-05, Jaikiran Pai wrote:
> With this change, things are much better now with Java 15
> https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk15-ea,label_exp=ubuntu/36/testReport/
> That one remaining failure is due to Nashorn no longer being part of
> Java 15.
Ri
...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> bodewig pushed a commit to branch 1.9.x
> in repository https://gitbox.apache.org/repos/asf/ant.git
>
>
> The following commit(s) were added to refs/heads/1.9.x by this push:
> ne
For Groovy we use a single command but as part of push with multiple
--release options, something like:
snapcraft push --release=3.0/beta --release=beta groovy_3.0.0-beta-3_all.snap
On Thu, Sep 5, 2019 at 5:08 PM Stefan Bodewig wrote:
> On 2019-09-05, wrote:
>
> > -$ snapcraft release ant
Hi Stefan,
On 05/09/19 12:38 PM, Stefan Bodewig wrote:
> On 2019-09-05, wrote:
>
>> -$ snapcraft release ant REVISION latest/stable 1.10/stable
>> +$ snapcraft release ant REVISION latest/stable
>> +$ snapcraft release ant REVISION 1.10/stable
> I'm pretty sure I've done it with the s
On 2019-09-05, wrote:
> -$ snapcraft release ant REVISION latest/stable 1.10/stable
> +$ snapcraft release ant REVISION latest/stable
> +$ snapcraft release ant REVISION 1.10/stable
I'm pretty sure I've done it with the single command when I published
1.10.6, but I may be wrong. Also
n external compiler?
-Jaikiran
On 25-08-19 11:44, j...@apache.org wrote:
This is an automated email from the ASF dual-hosted git repository.
jkf pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ant.git
The following commit(s) were added to refs/heads/master by
is also the case
> in the ant 1.10.6 release.
Do you mean using the "executable" attribute of the javac task to point
to an external compiler?
-Jaikiran
>
> On 25-08-19 11:44, j...@apache.org wrote:
>> This is an automated email from the ASF dual-hosted git repository
On 2019-05-27, Martijn wrote:
> What maybe with this regards is a problem is the update of the
> http:///www.apache.org/licenses to https in the LICENSE file. (I will
> revert those).
> The reference to the license in the source file header is not part of
> the license itself, it is a reference
t.
>
> Br Martijn
>
>
>
> On 26-05-19 08:46, j...@apache.org wrote:
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> jkf pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/ant.git
>
Hi,
Interesting, right at the top, the page itself refers to the https
location nowadays. In the licensing FAQ also a reference to the https
version is endorsed, not the http version.
What maybe with this regards is a problem is the update of the
http:///www.apache.org/licenses to https in
On 2019-05-26, wrote:
> updated reference to license from http to https using find . -type f -exec
> sed -i
> s/http://www.apache.org/licenses/LICENSE-2.0/https://www.apache.org/licenses/LICENSE-2.0/
> {} \;
I'm afraid we can't do that. The license URL is part of the license
text, changing th
on refused
errors we often get in the get-test and gunzip-test.
Br Martijn
On 26-05-19 08:46, j...@apache.org wrote:
This is an automated email from the ASF dual-hosted git repository.
jkf pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ant.git
The followin
s://bz.apache.org/bugzilla/show_bug.cgi?id=63226 ) and
> which is trivial. Maybe could you have a look ?
>
> best regards
> E.A.
>
> Le mer. 6 mars 2019 à 07:51, a écrit :
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> jaiki
mated email from the ASF dual-hosted git repository.
>
> jaikiran pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/ant.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 9e1bd14 Incorrect HTML
> 9e
Thanks, sorry about missing pom.xml and the manual.
Gintas
On Thu, 27 Dec 2018 at 14:21, Jaikiran Pai wrote:
> Hi Stefan,
>
> Thank you for reminding me of those files. I have now pushed a commit in
> both the branches which updates these files to use the new version.
>
> -Jaikiran
>
> On 27/12
Hi Stefan,
Thank you for reminding me of those files. I have now pushed a commit in
both the branches which updates these files to use the new version.
-Jaikiran
On 27/12/18 3:04 PM, Stefan Bodewig wrote:
> Hi Jaikiran
>
> you should probably also update manual/install.html as well as the
> affe
Hi Jaikiran
you should probably also update manual/install.html as well as the
affected POMs (in this case src/etc/poms/ant-jsch/pomx.xml) for
consistency.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For addi
On 2018-12-22, Jaikiran Pai wrote:
> Adding us...@infra.apache.org. Comments inline.
> On 21/12/18 1:01 AM, bode...@apache.org wrote:
>> This is an automated email from the ASF dual-hosted git repository.
>> bodewig pushed a change to branch master
>> in repository h
Adding us...@infra.apache.org. Comments inline.
On 21/12/18 1:01 AM, bode...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> bodewig pushed a change to branch master
> in repository https://gitbox.apache.org/repos/asf/ant.git.
>
>
this is not good, we must not force push to any
branch that is actively used, It is acceptable on feature branches where
you work on your own but completely unacceptable otherwise.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr.
On 2018-04-05, Maarten Coene wrote:
> Sorry, I have no idea what this is... should it be reverted?
No, you haven't really changed anything.
Your "fix typo" commit was based on a version of the master branch that
is older than the HEAD at apache as you didn't update your
: [2/2] ant git commit: Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/ant
Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ant
Project: http://git-wip-us.apache.org/repos/asf/ant/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant/c
On 2018-03-29, Gintautas Grigelionis wrote:
> IMHO sbt fork happened because Ivy was not using Git then.
I don't understand. Either they have changed Ivy or could have used
binaries. If they had to change Ivy the question is what did they have
to change.
> So my idea is to graft t
IMHO sbt fork happened because Ivy was not using Git then.
GitHub shows clearly that the fork was created off Ivy repo clone created
by EasyAnt (which is dormant now).
So my idea is to graft their branch onto Ivy repo whereupon EasyAnt-derived
clones can be mothballed.
What happens next is an open
On 2018-03-25, Gintautas Grigelionis wrote:
> I asked sbt developers [1] whether they would like to use the same Git
> repo. The consensus seems to be that sbt would like to have their own
> branch (or two). Would it be acceptable to graft sbt branch(es) to Ivy repo?
I'm not sur
I asked sbt developers [1] whether they would like to use the same Git
repo. The consensus seems to be that sbt would like to have their own
branch (or two). Would it be acceptable to graft sbt branch(es) to Ivy repo?
Gintas
[1] https://github.com/sbt/ivy/issues/28
Github user jaikiran commented on the issue:
https://github.com/apache/ant/pull/49
Committed to master branch
https://github.com/apache/ant/commit/cefdbd398d8e310b218f9e2ca6f0b7fb13eddbb9
---
-
To unsubscribe, e
Github user jaikiran closed the pull request at:
https://github.com/apache/ant/pull/49
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Github user bodewig commented on the issue:
https://github.com/apache/ant/pull/49
Looks good to me, thanks!
WRT a Java5 compatible backport, I'd leave this really up to you. I don't
see a pressing need for backporting either.
---
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155941358
--- Diff: src/main/org/apache/tools/ant/util/SymbolicLinkUtils.java ---
@@ -30,6 +30,8 @@
* a symbolic link based on the absent support for them in Java.
Github user jaikiran commented on the issue:
https://github.com/apache/ant/pull/49
>> Overall I'm in favor of this change and if you want to spend the time on
fixing the bugzilla issue in a Java5 friendly way for 1.9.x that would
certainly be good - bit not something I'd see as an req
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155941213
--- Diff: src/main/org/apache/tools/ant/util/SymbolicLinkUtils.java ---
@@ -30,6 +30,8 @@
* a symbolic link based on the absent support for them in Java.
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155941155
--- Diff: src/main/org/apache/tools/ant/taskdefs/optional/unix/Symlink.java
---
@@ -500,18 +502,12 @@ private void doLink(String res, String lnk) throws
BuildE
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155941101
--- Diff: src/main/org/apache/tools/ant/taskdefs/optional/unix/Symlink.java
---
@@ -448,49 +432,67 @@ private void handleError(String msg) {
/**
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155941095
--- Diff: src/main/org/apache/tools/ant/taskdefs/optional/unix/Symlink.java
---
@@ -207,26 +198,30 @@ public void recreate() throws BuildException {
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155941080
--- Diff: manual/Tasks/symlink.html ---
@@ -26,7 +26,7 @@
Symlink
Description
- Manages symbolic links on Unix based platforms. Can be used t
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155941076
--- Diff: WHATSNEW ---
@@ -27,6 +27,11 @@ Fixed bugs:
copy happened to be the same source file (symlinked back
to itself).
+ * Bugzilla
Github user bodewig commented on the issue:
https://github.com/apache/ant/pull/49
Thanks @jaikiran, I've added a buch of inline comments.
Overall I'm in favor of this change and if you want to spend the time on
fixing the bugzilla issue in a Java5 friendly way for 1.9.x that w
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155928363
--- Diff: src/main/org/apache/tools/ant/util/SymbolicLinkUtils.java ---
@@ -30,6 +30,8 @@
* a symbolic link based on the absent support for them in Java.
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155928313
--- Diff: src/main/org/apache/tools/ant/taskdefs/optional/unix/Symlink.java
---
@@ -500,18 +502,12 @@ private void doLink(String res, String lnk) throws
BuildEx
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155928143
--- Diff: src/main/org/apache/tools/ant/taskdefs/optional/unix/Symlink.java
---
@@ -448,49 +432,67 @@ private void handleError(String msg) {
/**
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155928069
--- Diff: src/main/org/apache/tools/ant/taskdefs/optional/unix/Symlink.java
---
@@ -207,26 +198,30 @@ public void recreate() throws BuildException {
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155927463
--- Diff: src/main/org/apache/tools/ant/taskdefs/optional/unix/Symlink.java
---
@@ -207,26 +198,30 @@ public void recreate() throws BuildException {
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155927271
--- Diff: manual/Tasks/symlink.html ---
@@ -26,7 +26,7 @@
Symlink
Description
- Manages symbolic links on Unix based platforms. Can be used to
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/ant/pull/49#discussion_r155927252
--- Diff: WHATSNEW ---
@@ -27,6 +27,11 @@ Fixed bugs:
copy happened to be the same source file (symlinked back
to itself).
+ * Bugzilla
GitHub user jaikiran opened a pull request:
https://github.com/apache/ant/pull/49
[master branch] - Fix BZ-58683
The commit here fixes the issue reported at
https://bz.apache.org/bugzilla/show_bug.cgi?id=58683.
This commit along with fixing the issue reported in that bug
Github user asfgit closed the pull request at:
https://github.com/apache/ant/pull/37
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Github user jaikiran commented on the issue:
https://github.com/apache/ant/pull/37
Tests against various JDK versions against Windows and Linux went fine
without any regressions. Will go ahead and merge this now.
---
--
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant/pull/37#discussion_r141594830
--- Diff: src/main/org/apache/tools/ant/util/ResourceUtils.java ---
@@ -666,6 +666,14 @@ private static void copyWithFilterSets(final Resource
source, final Res
Github user bodewig commented on the issue:
https://github.com/apache/ant/pull/37
Great change and I agree it should be fixed in the central location. Many
thanks!
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.a
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/ant/pull/37#discussion_r141578555
--- Diff: src/main/org/apache/tools/ant/util/ResourceUtils.java ---
@@ -666,6 +666,14 @@ private static void copyWithFilterSets(final Resource
source, final Reso
Github user jaikiran commented on the issue:
https://github.com/apache/ant/pull/39
Merged to both 1.9.x and master branches.
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-ma
Github user asfgit closed the pull request at:
https://github.com/apache/ant/pull/39
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Github user nlalevee commented on the issue:
https://github.com/apache/ant/pull/39
LGTM
+1 for merge
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apac
Github user jaikiran commented on the issue:
https://github.com/apache/ant/pull/39
Ignore the Jenkins job message please - I haven't yet got it configured
correctly.
---
-
To unsubscribe, e-mail: dev-unsubscr...@an
GitHub user jaikiran opened a pull request:
https://github.com/apache/ant/pull/39
[1.9.x branch] BZ-58589 Preserve last modified time (if asked for) for
files uploaded by SFTP
The commit here adds support for preserving the last modified time on files
when uploaded via SFTP, as
GitHub user jaikiran opened a pull request:
https://github.com/apache/ant/pull/37
[1.9.x branch] BZ-60644 Fix file corruption during copy task
The commit here includes a fix for the issue reported in
https://bz.apache.org/bugzilla/show_bug.cgi?id=60644. As described in that
issue
Github user jaikiran commented on the issue:
https://github.com/apache/ant/pull/35
All done - applied this commit to 1.9.x branch and then merged to master
branch. The pushed commit also includes updates to the WHATSNEW and contributor
files.
---
If your project is set up for it
Github user jaikiran closed the pull request at:
https://github.com/apache/ant/pull/35
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enable
GitHub user jaikiran opened a pull request:
https://github.com/apache/ant/pull/35
[1.9.x branch] Fix for BZ-43271 BZ-59648
The commit here fixes the issue reported in:
https://bz.apache.org/bugzilla/show_bug.cgi?id=43271#c6
https://bz.apache.org/bugzilla/show_bug.cgi?id
nderwerp: Re: Fw: [2/2] ant-ivy git commit: Merge remote-tracking branch
'origin/master'
I'm guessing that while committing the fix for IVY-1404 you probably did
a "git merge" against latest master of upstream, which created this
merge commit.
-Jaikiran
On 12/07/
Van: Jaikiran Pai
Aan: dev@ant.apache.org
Verzonden: woensdag 12 juli 17:53 2017
Onderwerp: Re: Fw: [2/2] ant-ivy git commit: Merge remote-tracking branch
'origin/master'
I'm guessing that while committing the fix for IVY-1404 you probably did
a "git merge" against la
ese files as far
as I know...
Maarten
- Doorgestuurd bericht -
Van: "maart...@apache.org"
Aan: notificati...@ant.apache.org
Verzonden: woensdag 12 juli 10:06 2017
Onderwerp: [2/2] ant-ivy git commit: Merge remote-tracking branch
'origin/master'
Mer
t: Merge remote-tracking branch
'origin/master'
Merge remote-tracking branch 'origin/master'
Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/1a36ae09
Tree: http://git-wip-us.apache.org/repos/asf/ant
Hi all
it's been nine months since our last release. After setting up the new
branches I'd like to get 1.9.7 out soonish. Is anybody sitting on any
changes you want to see included?
If not I'd volunteer to cut a release candidate (and adapt the release
process description as I go) in about a week
On 2016-03-26, Stefan Bodewig wrote:
> The Java8 build on Windows fails. It always did but was disabled, the
> comment was "Java8 cannot be installed on Windows"
This one is running right now - OpenJDK isn't available but Oracle JDK
is. The trick was to use "latest1.8" rather than "jdk 1.8". Oh m
On 2016-03-26, Jan Matèrne (jhm) wrote:
> * create a branch 1.9.x that we use for Java5 compatible maintenance
> releases
> * create Jenkins Matrix Build: win/linux java5-8
> * change the version number of the master branch to 1.10.0alpha
> (-SNAPSHOT, whatever) and mak
I added some notes to Stefans list.
Some more to do?
Jan
* create a branch 1.9.x that we use for Java5 compatible maintenance
releases
* create Jenkins Matrix Build: win/linux java5-8
* create Gump Job Java5+Ant1.9.x
* change the version number of the master branch to 1.10.0alpha
(-SNAPSHOT
On 2016-03-25, Stefan Bodewig wrote:
> On 2016-03-22, Stefan Bodewig wrote:
>> * create a branch 1.9.x that we use for Java5 compatible maintenance
>> releases - with Jenkins Matrix Builds, of course.
Done.
https://builds.apache.org/job/Ant-Build-Matrix-1.9.x/
>> * chan
On 2016-03-22, Stefan Bodewig wrote:
> * create a branch 1.9.x that we use for Java5 compatible maintenance
> releases - with Jenkins Matrix Builds, of course.
> * change the version number of the master branch to 1.10.0alpha
> (-SNAPSHOT, whatever) and make Java8 the new basel
On 2016-03-22, André-John Mas wrote:
> I don't mind which version we go with, but I would like to see the
> main Ant home page be clear about which Ant version to use, based on
> installed Java version.
> Could we have a compatibility matrix or something equivalent, on the
> main page? Something
crowd :)
Andre
> On 22 Mar, 2016, at 13:44, Jan Matèrne (jhm) wrote:
>
> +1 for Java8.
> For old java versions we have the 1.9-branch.
>
> Jan
>
>> -Ursprüngliche Nachricht-
>> Von: Roger and Beth Whitcomb [mailto:rogerandb...@rbwhitcomb.com]
>> Gesend
+1 for Java8.
For old java versions we have the 1.9-branch.
Jan
> -Ursprüngliche Nachricht-
> Von: Roger and Beth Whitcomb [mailto:rogerandb...@rbwhitcomb.com]
> Gesendet: Dienstag, 22. März 2016 18:14
> An: dev@ant.apache.org
> Betreff: Re: [VOTE] Adopt Java8 as Basel
As a heavy Ant user, faced with my own "minimum supported Java version"
headaches,
I'm +1 on this.
~Roger Whitcomb
On 3/22/16 5:11 AM, Stefan Bodewig wrote:
Hi all
after the recent discussion, I'd like to propose the following:
* create a branch 1.9.x that we use
block the
vote for this:-0
Maarten
Van: Stefan Bodewig
Aan: dev@ant.apache.org
Verzonden: dinsdag 22 maart 13:11 2016
Onderwerp: [VOTE] Adopt Java8 as Baseline for 1.10 on master Branch
Hi all
after the recent discussion, I'd like to propose the following:
* create a bra
1 - 100 of 269 matches
Mail list logo
