subject:"\[PATCH\]"

[GitHub] ant-ivy issue #71: Ivy main/standalone: Patch to include 'makepom' function

2018-08-06 Thread twogee

Github user twogee commented on the issue:

https://github.com/apache/ant-ivy/pull/71
  
@aanno could you please rebase and push the branch in order to close the PR?


---

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

[GitHub] ant-ivy issue #71: Ivy main/standalone: Patch to include 'makepom' function

2018-04-04 Thread jaikiran

Github user jaikiran commented on the issue:

https://github.com/apache/ant-ivy/pull/71
  
@aanno, thank you for this PR. I have gone ahead and included your patch 
with minor modifications to upstream and also included a test along with it. I 
have also included your name in our release notes. Since I couldn't find your 
full name in your github profile, I used `aanno`, if you prefer to have your 
full name included in the release notes, please let me know and I'll update it 
accordingly.



---

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

[GitHub] ant-ivy pull request #71: Ivy main/standalone: Patch to include 'makepom' fu...

2018-03-28 Thread twogee

Github user twogee commented on a diff in the pull request:

https://github.com/apache/ant-ivy/pull/71#discussion_r177857645
  
--- Diff: src/java/org/apache/ivy/Main.java ---
@@ -199,6 +201,10 @@ static CommandLineParser getParser() {
 new OptionBuilder("cp").arg("cp")
 .description("extra classpath to use when 
launching process").create())
 
+.addCategory("maven compatibility options")
+.addOption(new 
OptionBuilder("pomfile").arg("pomfile").countArgs(false)
+.description("makepom as standalone 
tasks").create())
--- End diff --

On the second thoughts, why not calling the option `makepom` ð ?


---

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

[GitHub] ant-ivy pull request #71: Ivy main/standalone: Patch to include 'makepom' fu...

2018-03-28 Thread twogee

Github user twogee commented on a diff in the pull request:

https://github.com/apache/ant-ivy/pull/71#discussion_r177696348
  
--- Diff: src/java/org/apache/ivy/Main.java ---
@@ -199,6 +201,10 @@ static CommandLineParser getParser() {
 new OptionBuilder("cp").arg("cp")
 .description("extra classpath to use when 
launching process").create())
 
+.addCategory("maven compatibility options")
+.addOption(new 
OptionBuilder("pomfile").arg("pomfile").countArgs(false)
+.description("makepom as standalone 
tasks").create())
--- End diff --

IMHO `pomfile` is confusing (cf use of `ivyfile` and `propertiesfile`). I'd 
suggest `writepom`or something like that.


---

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

[GitHub] ant-ivy pull request #71: Ivy main/standalone: Patch to include 'makepom' fu...

2018-03-28 Thread jaikiran

Github user jaikiran commented on a diff in the pull request:

https://github.com/apache/ant-ivy/pull/71#discussion_r177694759
  
--- Diff: src/java/org/apache/ivy/Main.java ---
@@ -199,6 +201,10 @@ static CommandLineParser getParser() {
 new OptionBuilder("cp").arg("cp")
 .description("extra classpath to use when 
launching process").create())
 
+.addCategory("maven compatibility options")
+.addOption(new 
OptionBuilder("pomfile").arg("pomfile").countArgs(false)
--- End diff --

A small suggestion - can you change this to something like:
```
new OptionBuilder("makepom").arg("pomfile")
```


---

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

[GitHub] ant-ivy pull request #71: Ivy main/standalone: Patch to include 'makepom' fu...

2018-03-28 Thread jaikiran

Github user jaikiran commented on a diff in the pull request:

https://github.com/apache/ant-ivy/pull/71#discussion_r177694862
  
--- Diff: src/java/org/apache/ivy/Main.java ---
@@ -199,6 +201,10 @@ static CommandLineParser getParser() {
 new OptionBuilder("cp").arg("cp")
 .description("extra classpath to use when 
launching process").create())
 
+.addCategory("maven compatibility options")
+.addOption(new 
OptionBuilder("pomfile").arg("pomfile").countArgs(false)
+.description("makepom as standalone 
tasks").create())
--- End diff --

I think the description should be a bit more clear and state that this 
generates a pom file for the resolved module.


---

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

[GitHub] ant-ivy issue #71: Ivy main/standalone: Patch to include 'makepom' function

2018-03-28 Thread jaikiran

Github user jaikiran commented on the issue:

https://github.com/apache/ant-ivy/pull/71
  
@aanno Thank you for the patch. This mostly looks fine. I have added some 
review comments. Can you please also introduce a test case for this? Something 
that tests that these command options are recognized and the pom file does get 
created.  There's a `MainTest` which you can refer to and add a new test method 
there.



---

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

[GitHub] ant-ivy pull request #71: Ivy main/standalone: Patch to include 'makepom' fu...

2018-03-27 Thread aanno

GitHub user aanno opened a pull request:

https://github.com/apache/ant-ivy/pull/71

Ivy main/standalone: Patch to include 'makepom' function 

Hello,

I added the pomfile option to main/standalone. This allows creating an 
(maven) pom file from outside an ant task.

Example of use:

```sh
$ pwd
~/.ivy2/cache/org.typelevel/cats-core_2.11
$ java -jar 
~/scm/github/ant-ivy/build/artifact/org.apache.ivy_2.5.0.alpha_20180327212209.jar
 -ivy ivy-1.0.1.xml -pomfile cats-core.xml
$ ls
cats-core-2.11.xml  ivy-1.0.1.xml  ivy-1.0.1.xml.original  
ivydata-1.0.1.properties  jars  srcs
```
Feedback is welcome. What should I do to get this patch into mainline?

Kind regards,

aanno

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/aanno/ant-ivy feature/aanno-main-pomfile

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant-ivy/pull/71.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #71


commit 5e814ad7a84ffb2a9d4df72fc801e9b8d6aa2f64
Author: Thomas Pasch 
Date:   2018-03-27T19:17:01Z

Added pomfile option to main/standalone




---

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

Re: [PATCH]

2018-01-24 Thread Jaikiran Pai


Hi Adam,

The mailing list strips off the attachments, so your patch didn't come 
through. In general, can you instead please create a bugzilla issue here 
https://bz.apache.org/bugzilla/enter_bug.cgi?product=Ant and explain the 
issue you were running into (including the version of Ant you are using 
and the exception stacktrace that you got) and attach the proposed patch 
there?


-Jaikiran


On 24/01/18 4:57 PM, Adam Retter wrote:

If you previously used the Saxon XSLT Processor within
 you would get an error as the XSLT stylesheets
provided with Ant do not work with Saxon, they in fact rely on Xalan2
specific extensions.

The attached patch adds Saxon compatible stylesheets and selects the
Saxon stylesheets if the Saxon processor is specified, e.g. the
following now works:



 
 
 

 
 
 
 
 
 
 
 




Hope this can make it into the next Ant release? Let me know if you
need any changes...

Cheers Adam.



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

[PATCH]

2018-01-24 Thread Adam Retter

If you previously used the Saxon XSLT Processor within
 you would get an error as the XSLT stylesheets
provided with Ant do not work with Saxon, they in fact rely on Xalan2
specific extensions.

The attached patch adds Saxon compatible stylesheets and selects the
Saxon stylesheets if the Saxon processor is specified, e.g. the
following now works:



















Hope this can make it into the next Ant release? Let me know if you
need any changes...

Cheers Adam.

-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk


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

Re: IVYDE-382 proposed patch

2017-07-01 Thread Nicolas Lalevée

Hi Alexander,

Yes, it would be really nice if you could create a page documenting the new 
feature.

I have just migrated the documentation of IvyDE to asciidoc, so it will be 
easier to contribute.
I have also squashed and rebased your work on this branch:
https://github.com/apache/ant-ivyde/tree/ivyDECredentials-cleaned 
<https://github.com/apache/ant-ivyde/tree/ivyDECredentials-cleaned>

To contribute you can create a pull request on this branch, we will get 
notified.

Cheers,
Nicolas


> Le 30 juin 2017 à 16:52, alexander.bl...@arctis.at a écrit :
> 
> Good afternoon, 
> 
> sorry for the delay in my reply. The last two weeks I was very busy with
> exams and work. 
> 
> We are glad that our proposed patch found its way back to the main
> development path and that perhaps it will be a part of a following
> release :-) 
> 
> Is there a way we can support you? 
> 
> Should we extend the official IvyDE doc by providing a more
> sophisticated description about the new feature (like you suggested in
> the previous mail)? 
> 
> Many greetings from Austria, 
> 
> Alexander 
> 
> Am 14.06.2017 23:56, schrieb Nicolas Lalevée:
> 
>> Hi,
>> 
>> For some reason git apply was refusing to process the patch and was just 
>> returning an error: corrupt patch at line 1964
>> 
>> So I played with git commands and work with the sources available on github.
>> I have create a branch on the ASF repo, ivyDECredentials, which has one 
>> commit which squash all the forked commit on github.
>> I have then created another branch, ivyDECredentials-cleaned, which rebase 
>> the work, remove unnecessary changes like the readme file, and did some file 
>> formatting.
>> 
>> Now it needs some review and testing in order to be merged. I'll take time 
>> to do it but if somebody else if wants to help, another pair of eyes on this 
>> is very welcomed.
>> 
>> Also would be welcomed some documentation about this new feature. The IvyDE 
>> doc is quite complete, it would be really nice to keep it at this level.
>> 
>> Nicolas
>> 
>>> Le 14 juin 2017 à 05:18, J Pai  a écrit :
>>> 
>>> Hi Alexander,
>>> 
>>> I actually just realized that your initial mail actually had a patch file 
>>> attached. I didn't notice that before and only today noticed it while 
>>> looking at the mail list archive. So assuming this applies cleanly on 
>>> latest master branch of IvyDE, I think this should be fine too, instead of 
>>> creating a PR. I am not experienced with Eclipse plugins, so I personally 
>>> won't be able to help much, but hopefully someone from the IvyDE team will 
>>> be able to review and decide about this patch. Thank you again for 
>>> contributing this.
>>> 
>>> -Jaikiran
>>> On 26-May-2017, at 8:28 AM, J Pai  wrote:
>>> 
>>> Hi Alexander,
>>> 
>>> Thank you for volunteering to provide this feature patch. I had a look a 
>>> the repo you pointed to and read the README. It does seem to contain a good 
>>> amount of work in that branch in multiple commits. 
>>> 
>>> To make it easier for whoever will decide about merging these to upstream 
>>> ant-ivyde project, would it to be possible for you to do the following:
>>> 
>>> 1. *Fork* the ant-ivyde project (on github) 
>>> https://github.com/apache/ant-ivyde/ into your account. There's a "Fork" 
>>> button on the right corner of the github page for the repo.
>>> 2. Once forked into your account, you can push your enhancement and bug fix 
>>> related commits to either your master branch of your repo or any specific 
>>> branch of your choice.
>>> - If the bug fixes are independent of the feature, then it would be good if 
>>> they are done in separate branches, so that a separate pull request (PR) 
>>> can be issued.
>>> 3. Once you are ready with the commits, you can then issue a pull request 
>>> (PR) from your repo to the "master" branch of the ant-ivyde upstream repo 
>>> https://github.com/apache/ant-ivyde/.  Typically PRs are meant to contain 
>>> commits that are all specific to a single feature or for a specific bug fix.
>>> 
>>> Once the PRs are submitted, I'm sure one or more members of the development 
>>> team who have relevant knowledge of Eclipse and the project will review 
>>> this and either merge it or provide inputs.
>>> 
>>> Thanks again for this, both Ivy and IvyDE project has been stagnant for a 
>>> while and with contributions

Re: IVYDE-382 proposed patch

2017-07-01 Thread alexander . blaas

Good afternoon, 

sorry for the delay in my reply. The last two weeks I was very busy with
exams and work. 

We are glad that our proposed patch found its way back to the main
development path and that perhaps it will be a part of a following
release :-) 

Is there a way we can support you? 

Should we extend the official IvyDE doc by providing a more
sophisticated description about the new feature (like you suggested in
the previous mail)? 

Many greetings from Austria, 

Alexander 

Am 14.06.2017 23:56, schrieb Nicolas Lalevée:

> Hi,
> 
> For some reason git apply was refusing to process the patch and was just 
> returning an error: corrupt patch at line 1964
> 
> So I played with git commands and work with the sources available on github.
> I have create a branch on the ASF repo, ivyDECredentials, which has one 
> commit which squash all the forked commit on github.
> I have then created another branch, ivyDECredentials-cleaned, which rebase 
> the work, remove unnecessary changes like the readme file, and did some file 
> formatting.
> 
> Now it needs some review and testing in order to be merged. I'll take time to 
> do it but if somebody else if wants to help, another pair of eyes on this is 
> very welcomed.
> 
> Also would be welcomed some documentation about this new feature. The IvyDE 
> doc is quite complete, it would be really nice to keep it at this level.
> 
> Nicolas
> 
>> Le 14 juin 2017 à 05:18, J Pai  a écrit :
>> 
>> Hi Alexander,
>> 
>> I actually just realized that your initial mail actually had a patch file 
>> attached. I didn't notice that before and only today noticed it while 
>> looking at the mail list archive. So assuming this applies cleanly on latest 
>> master branch of IvyDE, I think this should be fine too, instead of creating 
>> a PR. I am not experienced with Eclipse plugins, so I personally won't be 
>> able to help much, but hopefully someone from the IvyDE team will be able to 
>> review and decide about this patch. Thank you again for contributing this.
>> 
>> -Jaikiran
>> On 26-May-2017, at 8:28 AM, J Pai  wrote:
>> 
>> Hi Alexander,
>> 
>> Thank you for volunteering to provide this feature patch. I had a look a the 
>> repo you pointed to and read the README. It does seem to contain a good 
>> amount of work in that branch in multiple commits. 
>> 
>> To make it easier for whoever will decide about merging these to upstream 
>> ant-ivyde project, would it to be possible for you to do the following:
>> 
>> 1. *Fork* the ant-ivyde project (on github) 
>> https://github.com/apache/ant-ivyde/ into your account. There's a "Fork" 
>> button on the right corner of the github page for the repo.
>> 2. Once forked into your account, you can push your enhancement and bug fix 
>> related commits to either your master branch of your repo or any specific 
>> branch of your choice.
>> - If the bug fixes are independent of the feature, then it would be good if 
>> they are done in separate branches, so that a separate pull request (PR) can 
>> be issued.
>> 3. Once you are ready with the commits, you can then issue a pull request 
>> (PR) from your repo to the "master" branch of the ant-ivyde upstream repo 
>> https://github.com/apache/ant-ivyde/.  Typically PRs are meant to contain 
>> commits that are all specific to a single feature or for a specific bug fix.
>> 
>> Once the PRs are submitted, I'm sure one or more members of the development 
>> team who have relevant knowledge of Eclipse and the project will review this 
>> and either merge it or provide inputs.
>> 
>> Thanks again for this, both Ivy and IvyDE project has been stagnant for a 
>> while and with contributions like these, we should be able to release out a 
>> new version soon.
>> 
>> -Jaikiran
>> 
>> On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote:
>> 
>> Dear Sir or Madam,
>> 
>> as it was suggested in 
>> https://issues.apache.org/jira/browse/IVYDE-382?focusedCommentId=16018847&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16018847,
>>  we are sending you our proposed patch for 
>> https://issues.apache.org/jira/browse/IVYDE-382. The corresponding 
>> patch-file is attached to this email. The source code is available at 
>> https://github.com/alex-bl/ivyDEextension/tree/ivyDECredentials in the 
>> branch "ivyDECredentials". 
>> 
>> Yours sincerely,
>> 
>> Alexander Blaas
>> 
>> 
>> -
>> 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: IVYDE-382 proposed patch

2017-06-14 Thread Nicolas Lalevée

Hi,

For some reason git apply was refusing to process the patch and was just 
returning an error: corrupt patch at line 1964

So I played with git commands and work with the sources available on github.
I have create a branch on the ASF repo, ivyDECredentials, which has one commit 
which squash all the forked commit on github.
I have then created another branch, ivyDECredentials-cleaned, which rebase the 
work, remove unnecessary changes like the readme file, and did some file 
formatting.

Now it needs some review and testing in order to be merged. I’ll take time to 
do it but if somebody else if wants to help, another pair of eyes on this is 
very welcomed.

Also would be welcomed some documentation about this new feature. The IvyDE doc 
is quite complete, it would be really nice to keep it at this level.

Nicolas

> Le 14 juin 2017 à 05:18, J Pai  a écrit :
> 
> Hi Alexander,
> 
> I actually just realized that your initial mail actually had a patch file 
> attached. I didn’t notice that before and only today noticed it while looking 
> at the mail list archive. So assuming this applies cleanly on latest master 
> branch of IvyDE, I think this should be fine too, instead of creating a PR. I 
> am not experienced with Eclipse plugins, so I personally won’t be able to 
> help much, but hopefully someone from the IvyDE team will be able to review 
> and decide about this patch. Thank you again for contributing this.
> 
> -Jaikiran
> On 26-May-2017, at 8:28 AM, J Pai  wrote:
> 
> Hi Alexander,
> 
> Thank you for volunteering to provide this feature patch. I had a look a the 
> repo you pointed to and read the README. It does seem to contain a good 
> amount of work in that branch in multiple commits. 
> 
> To make it easier for whoever will decide about merging these to upstream 
> ant-ivyde project, would it to be possible for you to do the following:
> 
> 1. *Fork* the ant-ivyde project (on github) 
> https://github.com/apache/ant-ivyde/ into your account. There’s a “Fork” 
> button on the right corner of the github page for the repo.
> 2. Once forked into your account, you can push your enhancement and bug fix 
> related commits to either your master branch of your repo or any specific 
> branch of your choice.
>   - If the bug fixes are independent of the feature, then it would be 
> good if they are done in separate branches, so that a separate pull request 
> (PR) can be issued.
> 3. Once you are ready with the commits, you can then issue a pull request 
> (PR) from your repo to the “master” branch of the ant-ivyde upstream repo 
> https://github.com/apache/ant-ivyde/.  Typically PRs are meant to contain 
> commits that are all specific to a single feature or for a specific bug fix.
> 
> Once the PRs are submitted, I’m sure one or more members of the development 
> team who have relevant knowledge of Eclipse and the project will review this 
> and either merge it or provide inputs.
> 
> Thanks again for this, both Ivy and IvyDE project has been stagnant for a 
> while and with contributions like these, we should be able to release out a 
> new version soon.
> 
> -Jaikiran
> 
> 
> On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote:
> 
> Dear Sir or Madam,
> 
> as it was suggested in 
> https://issues.apache.org/jira/browse/IVYDE-382?focusedCommentId=16018847&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16018847,
>  we are sending you our proposed patch for 
> https://issues.apache.org/jira/browse/IVYDE-382. The corresponding patch-file 
> is attached to this email. The source code is available at 
> https://github.com/alex-bl/ivyDEextension/tree/ivyDECredentials in the branch 
> "ivyDECredentials". 
> 
> Yours sincerely,
> 
> Alexander Blaas
> 
> 
> -
> 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

I actually just realized that your initial mail actually had a patch file
attached. I didn’t notice that before and only today noticed it while looking
at the mail list archive. So assuming this applies cleanly on latest master
branch of IvyDE, I think this should be fine too, instead of creating a PR. I
am not experienced with Eclipse plugins, so I personally won’t be able to help
much, but hopefully someone from the IvyDE team will be able to review and
decide about this patch. Thank you again for contributing this.

-Jaikiran
On 26-May-2017, at 8:28 AM, J Pai wrote:

Hi Alexander,

Thank you for volunteering to provide this feature patch. I had a look a the
repo you pointed to and read the README. It does seem to contain a good amount
of work in that branch in multiple commits.

To make it easier for whoever will decide about merging these to upstream
ant-ivyde project, would it to be possible for you to do the following:

1. *Fork* the ant-ivyde project (on github)
https://github.com/apache/ant-ivyde/ into your account. There’s a “Fork” button
on the right corner of the github page for the repo.
2. Once forked into your account, you can push your enhancement and bug fix
related commits to either your master branch of your repo or any specific
branch of your choice.
- If the bug fixes are independent of the feature, then it would be
good if they are done in separate branches, so that a separate pull request
(PR) can be issued.
3. Once you are ready with the commits, you can then issue a pull request (PR)
from your repo to the “master” branch of the ant-ivyde upstream repo
https://github.com/apache/ant-ivyde/. Typically PRs are meant to contain
commits that are all specific to a single feature or for a specific bug fix.

Once the PRs are submitted, I’m sure one or more members of the development
team who have relevant knowledge of Eclipse and the project will review this
and either merge it or provide inputs.

Thanks again for this, both Ivy and IvyDE project has been stagnant for a while
and with contributions like these, we should be able to release out a new
version soon.

-Jaikiran

On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote:

Dear Sir or Madam,

as it was suggested in
https://issues.apache.org/jira/browse/IVYDE-382?focusedCommentId=16018847&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16018847,
we are sending you our proposed patch for
https://issues.apache.org/jira/browse/IVYDE-382. The corresponding patch-file
is attached to this email. The source code is available at
https://github.com/alex-bl/ivyDEextension/tree/ivyDECredentials in the branch
"ivyDECredentials".

Yours sincerely,

Alexander Blaas

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

Re: IVYDE-382 proposed patch

2017-05-25 Thread J Pai

Hi Alexander,

Thank you for volunteering to provide this feature patch. I had a look a the
repo you pointed to and read the README. It does seem to contain a good amount
of work in that branch in multiple commits.

To make it easier for whoever will decide about merging these to upstream
ant-ivyde project, would it to be possible for you to do the following:

Once the PRs are submitted, I’m sure one or more members of the development
team who have relevant knowledge of Eclipse and the project will review this
and either merge it or provide inputs.

Thanks again for this, both Ivy and IvyDE project has been stagnant for a while
and with contributions like these, we should be able to release out a new
version soon.

-Jaikiran

On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote:

Dear Sir or Madam,

Yours sincerely,

Alexander Blaas

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

IVYDE-382 proposed patch

2017-05-25 Thread alexander . blaas

Dear Sir or Madam, 

as it was suggested in
https://issues.apache.org/jira/browse/IVYDE-382?focusedCommentId=16018847&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16018847,
we are sending you our proposed patch for
https://issues.apache.org/jira/browse/IVYDE-382. The corresponding
patch-file is attached to this email. The source code is available at
https://github.com/alex-bl/ivyDEextension/tree/ivyDECredentials in the
branch "ivyDECredentials".  

Yours sincerely, 

Alexander Blaasdiff --git a/org.apache.ivyde.eclipse/.classpath b/org.apache.ivyde.eclipse/.classpath
index 85c53c9..16c3e8e 100644
--- a/org.apache.ivyde.eclipse/.classpath
+++ b/org.apache.ivyde.eclipse/.classpath
@@ -1,22 +1,4 @@
 
-
 
 	
 	
diff --git a/org.apache.ivyde.eclipse/.settings/org.eclipse.jdt.core.prefs b/org.apache.ivyde.eclipse/.settings/org.eclipse.jdt.core.prefs
index ac46b41..3eff64b 100644
--- a/org.apache.ivyde.eclipse/.settings/org.eclipse.jdt.core.prefs
+++ b/org.apache.ivyde.eclipse/.settings/org.eclipse.jdt.core.prefs
@@ -1,21 +1,3 @@
-#***
-#* Licensed to the Apache Software Foundation (ASF) under one
-#* or more contributor license agreements.  See the NOTICE file
-#* distributed with this work for additional information
-#* regarding copyright ownership.  The ASF licenses this file
-#* to you under the Apache License, Version 2.0 (the
-#* "License"); you may not use this file except in compliance
-#* with the License.  You may obtain a copy of the License at
-#*
-#*   http://www.apache.org/licenses/LICENSE-2.0
-#*
-#* Unless required by applicable law or agreed to in writing,
-#* software distributed under the License is distributed on an
-#* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-#* KIND, either express or implied.  See the License for the
-#* specific language governing permissions and limitations
-#* under the License.
-#***
 eclipse.preferences.version=1
 org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
 org.eclipse.jdt.core.compiler.codegen.methodParameters=do not generate
@@ -95,7 +77,12 @@
 org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_cases=true
 org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch=true
 org.eclipse.jdt.core.formatter.indentation.size=4
-org.eclipse.jdt.core.formatter.insert_new_line_after_annotation=insert
+org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_field=insert
+org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_local_variable=insert
+org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_method=insert
+org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_package=insert
+org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_parameter=insert
+org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_type=insert
 org.eclipse.jdt.core.formatter.insert_new_line_after_opening_brace_in_array_initializer=do not insert
 org.eclipse.jdt.core.formatter.insert_new_line_at_end_of_file_if_missing=do not insert
 org.eclipse.jdt.core.formatter.insert_new_line_before_catch_in_try_statement=do not insert
diff --git a/org.apache.ivyde.eclipse/META-INF/MANIFEST.MF b/org.apache.ivyde.eclipse/META-INF/MANIFEST.MF
index f354d8e..94b6ae8 100644
--- a/org.apache.ivyde.eclipse/META-INF/MANIFEST.MF
+++ b/org.apache.ivyde.eclipse/META-INF/MANIFEST.MF
@@ -1,8 +1,8 @@
 Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: Apache IvyDE
-Bundle-SymbolicName: org.apache.ivyde.eclipse; singleton:=true
-Bundle-Version: 2.3.0.qualifier
+Bundle-SymbolicName: org.apache.ivyde.eclipse;singleton:=true
+Bundle-Version: 2.3.1.qualifier
 Bundle-ClassPath: ivyde-eclipse.jar
 Bundle-Activator: org.apache.ivyde.internal.eclipse.IvyPlugin
 Bundle-Vendor: Apache Software Foundation
@@ -33,6 +33,11 @@
  org.eclipse.debug.core;bundle-version="[3.4.0,4.0.0)",
  org.eclipse.jdt.launching;bundle-version="[3.4.0,4.0.0)",
  org.eclipse.debug.ui;bundle-version="[3.4.0,4.0.0)",
- org.eclipse.core.variables;bundle-version="[3.2.0,4.0.0)"
+ org.eclipse.core.variables;bundle-version="[3.2.0,4.0.0)",
+ org.eclipse.equinox.security;bundle-version="[1.1.100,2.0.0)",
+ org.eclipse.core.databinding;bundle-version="[1.4.1,2.0.0)",
+ org.eclipse.core.databinding.property;bundle-version="[1.4.100,2.0.0)",
+ org.eclipse.core.databinding.beans;bundle-version="[1.2.200,2.0.0)",
+ org.eclipse.jface.databinding;bundle-version="[1.6.0,2.0.0)"
 Bundle-ActivationPolicy: lazy
 Bundle-RequiredExecutionEnvironment: JavaSE-1.6
diff --git a/org.apache.ivyde.eclipse/build.prop

[GitHub] ant pull request #30: Patch compile script

2017-01-16 Thread pyxide

GitHub user pyxide opened a pull request:

https://github.com/apache/ant/pull/30

Patch compile script



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pyxide/ant PATCH_COMPILE_SCRIPT

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant/pull/30.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #30


commit 824a17b2b78615da01433b333ca4861b8402f31a
Author: pyxide 
Date:   2017-01-13T16:16:50Z

Scriptdef task new options : 'compiled' (if javax.script engine
implements Compilable), 'encoding' to load resources

commit ea81a70738db8b3a5f5ab8f3199fb34201560b31
Author: pyxide 
Date:   2017-01-16T12:48:26Z

Fix CRLF to LF




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-08 Thread Paul Sandoz

Hi Andre,

> On 6 Mar 2016, at 00:15, André-John Mas  wrote:
> 
> Hi,
> 
> Given the issues we are seeing, and I suspect this is not the only code with 
> these assumptions, is there any way this functionality can be limited to 
> "multi-release aware" code, either via a constructor parameter or a new 
> method? What is the most elegant approach?
> 

For resource URLs, associated with an MR-JAR, and obtained from a class loader, 
here are three possible routes we could take:

1) Modify the resources URLs, cognisent of the known issues processing such 
URLs;
2) Resources URLs are reified; or
3) Resources URLs are not modified (meaning they are not runtime versioned).

By 2) i mean that:

  URL u = loader.getResource(“foo/Bar.class”)

may return u that is say:

  “jar:file:/….!/META-INF/versions/9/foo/Bar.class”

rather than:

  “jar:file:/….!/foo/Bar.class”

But we need to work through the implications of that approach.

Paul.

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-07 Thread Paul Sandoz

Hi Uwe, Alan,

Uwe, thanks so much for testing and investigating, that is very helpful and 
really appreciated. The EA process is working as intended, although i wish the 
result was not so debilitating in this case. Sorry about that.

> On 5 Mar 2016, at 15:03, Alan Bateman  wrote:
> 
> 
> On 05/03/2016 13:24, Uwe Schindler wrote:
>> :
>> 
>> I'd suggest to please ASAP revert the Multi-Release JAR file patch and 
>> provide a new preview build as soon as possible. I think there is more work 
>> needed to fix this. If this does not revert to the original state, it will 
>> be impossible to build and test Lucene, Elasticsearch, (and almost every 
>> Java project out there!). So short: We cannot test anymore and it is likely 
>> that we cannot support Java 9 anymore because the build system used by most 
>> Java projects behind the scenes does not bootstrap itself anymore.
>> 
> Sigh, I think those of us that reviewed this missed the point that the 
> fragment is appended by default.

Yes :-( i missed that in review 

Here is a possible fix:

URLClassPath.java:
—

/**
 * This class is used to maintain a search path of URLs for loading classes
 * and resources from both JAR files and directories.
@@ -760,7 +759,11 @@
try {
// add #runtime fragment to tell JarURLConnection to use
// runtime versioning if the underlying jar file is 
multi-release
-url = new URL(getBaseURL(), ParseUtil.encodePath(name, false) 
+ "#runtime");
+if (jar.isMultiRelease()) {
+url = new URL(getBaseURL(), ParseUtil.encodePath(name, 
false) + "#runtime");
+} else {
+url = new URL(getBaseURL(), ParseUtil.encodePath(name, 
false));
+}
if (check) {
URLClassPath.check(url);
}

With that fix i can successfully build Lucene (i think the problem with Ivy is 
the same underlying cause as with Ant. We have also noticed problems with 
Jetty).

My intention was the #runtime fragment should only be used for MR-JARs.

We may need to reconsider that given the fragility of processing URLs that have 
been reported, although MR-JARs are new and it will take time for this to work 
through the eco-system allowing time to weed out the bugs.

Ideally the best solution is to change the URL scheme, say 
“mrjar:file:/…!/…class” only for MR-JARs of course, but i considered this might 
be even more invasive for class scanners etc, (assuming URLs are processed 
correctly). However, the Jigsaw image is already adjusting the scheme for 
classes in an image:

 l.getResource("java/net/URL.class”) -> jrt:/java.base/java/net/URL.class

and that will also impact other stuff folded into the image.

So perhaps we should revisit? Tricky tradeoffs here.

> This will of course break code that parses URL strings in naive ways 
> (anything looking for ".xml" should be looking at the path component of 
> course). I'll create a bug for this now, assuming you haven't created one 
> already.
> 

Alan created:

  https://bugs.openjdk.java.net/browse/JDK-8151339

Thanks,
Paul.

> One general point is that the purpose of EA builds and timely testing by 
> Lucene and other projects is invaluable for shaking out issues. There will be 
> issues periodically and much better to find these within a few days of 
> pushing a change rather than months later.
> 
> -Alan

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-06 Thread David Holmes

On 5/03/2016 11:50 PM, Claes Redestad wrote:

Hi,

similar issues were discovered too late to stop b108, e.g.,
https://bugs.openjdk.java.net/browse/JDK-8150920. Fix is already in jdk9/dev,
so I think the next build should be more well-behaved and hope we can provide
it more promptly than normal.

As that bug leads to a non-open bug here's the changeset URL:

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/721288127c82

David

If you can build OpenJDK from jdk9/dev and report any remaining issues due to
the multi-release feature that would be quite helpful!

Thanks!

/Claes

Uwe Schindler skrev: (5 mars 2016 14:24:37 CET)

Hi OpenJDK Core Developers,

you may know the Apache Lucene team is testing early access releases of
Java 9. We reported many bugs already, but most of them only applied to
Hotspot and Lucene itsself. But this problem since build 108 is now
really severe, because it breaks the build system already!

To allow further testing of Open Source Projects, I'd suggest to revert
the Multi-Release-JAR runtime support patch and provide a new preview
build ASAP, because we found out after a night of debugging a build
system from which we don't know all internals what is causing the
problems and there is no workaround. I am very sorry that I have to say
this, but it unfortunately build 108 breaks *ALL* versions of Apache
Ant, the grandfather of all Java build systems :-) I know also OpenJDK
is using it, too! So with Multi-Release JAR file patch applied (see
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c), any
Ant-based build - including the JDK build itsself - would no longer
bootstrap. It is impossible to also build Gradle projects, because
Gradle uses Ant internally for many tasks). Maven projects may be
affected, too.

Now you might have the question: What happened?

We tried to build Lucene on our Jenkins server, but the build itsself
failed with a stupid error message:

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:21: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:56:
not doesn't support the nested "matches" element.

The first idea was: Ah, there were changes in XML parsing
(JDK-8149915). So we debugged the build. But it was quite clear that
XML parsing was not the issue. It got quite clear when we enabled
"-debug" on the build. What happened was that Ant was not loading its
internal conditions/tasks/type definitions anymore, so the build system
does not know almost any type anymore. The debug log showed that Ant
was no longer able to load the resource
"/org/apache/tools/ant/antlib.xml" from its own JAR file anymore.
Instead it printed some strange debugging output (which looked totally
broken).

I spend the whole night digging through their code and found the issue:
The commit of Multi-Release-Jar files (see
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c) broke
resource handling in Apache Ant. In short: If you call
ClassLoader.getResources() / or getResource() you get back an URL from
where you can load the Resource - this is all fine and still works.
But, with the Multi-Release JAR files patch this now has an URL
fragment appended to the URL: '#release' (see
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c); this also
applies to non-multi-release JAR files like Apache Ant's "ant.jar".

In Java 7, Java 8,... and Java 9pre-b108,
ClassLoader.getResource()/getResources() returned stuff like:

"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml"

Now in Java 9b108 the following is returned:

"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml#release"

And here Ant breaks (and I assume many other projects like Maven, too).
Ant checks for the file extension of the string (because it may load
definitions from both XML and properties files). So it does
endsWith(".xml") and of course this now returns false. The effect is
that Ant tries to load its own task definitions as a java properties
file instead of XML. Of course this fails, because the data behind this
URL is XML. The effect is that Ant cannot bootstrap as everything to
build is missing.

One might say: Ant's code is broken (I agree, it is not nice because it
relies on the string representation of the resource URL - which is a
no-go anyways), but it is impossible to fix, because Ant is bundled on
most developer computers and those will suddenly break with Java 9!
There is also no version out there that works around this, so we cannot
test anything anymore!

The problematic line in Ant's code is here:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.ant/ant/1.9.6/org/apache/tools/ant/taskdefs/Definer.java?av=f#259

I'd suggest to please ASAP revert the Multi-Release JAR file patch and
pr

RE: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-06 Thread Uwe Schindler

> > > This is why I put the Ant developers in CC. The correct way would be
> > > to look at the *decoded* path (not just getPath() because this is also
> > > one of the "famous" traps in the URL class - one reason why it should
> > > be avoided in favor of URI). URL.toURI().getPath() is most safe to fix
> > > the issue in Apache Ant
> >
> > Part of the reason for this certainly is that the code has been written
> > before the URI class even existed.
> >
> > > (Stefan Bodewig: Should I open an issue in Ant?).
> >
> > Yes, please do. Thanks Uwe.
> 
> I opened: https://bz.apache.org/bugzilla/show_bug.cgi?id=59130
> 
> > > Maybe Ant developers can fix this code in later versions to handle
> > > URLs more correct.
> >
> > +1
> 
> Unfortunately this is not the only issue caused by this. After I tried to 
> build
> Lucene with the patch applied, the next candidate for the issue broke:
> Apache Ivy. It was no longer able to load the ivy-settings.xml file from its 
> JAR
> file.
> 
> The reason here is another one: It constructs the JAR file URL on its own (it
> looks like this), but does not add the #release fragment. And because of this,
> JarURLConnection does not find the file...:
> 
> [...] multiple parent causes [...]
> Caused by: java.io.FileNotFoundException: JAR entry
> org/apache/ivy/core/settings/ivysett/ivysettings-public.xml not found in
> C:\Users\Uwe Schindler\.ant\lib\ivy-2.3.0.jar
> at
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.jav
> a:142)
> at
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnec
> tion.java:150)
> at
> org.apache.ivy.util.url.BasicURLHandler.openStream(BasicURLHandler.java:1
> 71)
> at
> org.apache.ivy.util.url.URLHandlerDispatcher.openStream(URLHandlerDispat
> cher.java:74)
> at
> org.apache.ivy.core.settings.XmlSettingsParser.doParse(XmlSettingsParser.j
> ava:157)
> at
> org.apache.ivy.core.settings.XmlSettingsParser.parse(XmlSettingsParser.java
> :183)
> at
> org.apache.ivy.core.settings.XmlSettingsParser.includeStarted(XmlSettingsP
> arser.java:435)
> at
> org.apache.ivy.core.settings.XmlSettingsParser.startElement(XmlSettingsPar
> ser.java:211)
> ... 35 more
> 
> So it looks like the Multi-release JAR file patch also breaks the other way
> round: Code constructing JAR URLs according to the standard no longer work.
> In my opinion, the JAR URLs should not change at all and the code should
> transparently choose the right release version. Maybe add a fragment only
> to explicitly state a specific version (so one would be able to load the Java 
> 7
> version). But this could also be done using the META-INF/... path. The default
> handling should be that "old" and (I think they are standardized) JAR URLs
> still works as they should - not requiring the fragment!

I tried another project (a private one) and it failed in similar ways while 
loading XSL templates. This project produced no self-crafted jar:-URLs; instead 
it relied on relative URL resolving (the same applies to Apache Ivy).

A common pattern (especially in the "XML world") is to have relative links in 
your files, e.g. an XSLT file that includes another ones. If you place those 
XSL or XML files containing relative links in a JAR file, with previous Java 
versions everything worked as it should. You started the XML parser with the 
URL returned by the classloader and it was able to also resolve relative links 
between the files (because the jar: URL protocol correctly supports relative 
resolving of paths). So  xml/xsl file containing a reference to another file in 
same package using a filename like  works 
perfectly with the JAR URL protocol. If the original file had a URL like 
"jar:file:!/package/master.xsl" and this was passed to XML parser [e.g, 
like TranformerFactory#newTransformer(new 
StreamSource(classloader.getResource("package/master.xsl ").toString())], the 
XML parser would load "jar:file:!/package/otherfile.xsl"

But because the fragment is lost during resolving relative URLs, this no longer 
works with Multi-Release JAR files. It looks like JARURLConnection throws 
FileNotFoundException without the #release fragment.

I hope this helps to see why using fragments as part of the identifier is not 
quite correct in the URL world. I'd use some other way to refer to specific 
versions. At least let the no-fragment case always load the version-based file. 
Only use a fragment to refer to another version.

Uwe


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

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-05 Thread André-John Mas

Hi,

Given the issues we are seeing, and I suspect this is not the only code with 
these assumptions, is there any way this functionality can be limited to 
"multi-release aware" code, either via a constructor parameter or a new method? 
What is the most elegant approach?

Andre

> On 5 Mar, 2016, at 08:50, Claes Redestad  wrote:
> 
> Hi,
> 
> similar issues were discovered too late to stop b108, e.g., 
> https://bugs.openjdk.java.net/browse/JDK-8150920. Fix is already in jdk9/dev, 
> so I think the next build should be more well-behaved and hope we can provide 
> it more promptly than normal.
> 
> If you can build OpenJDK from jdk9/dev and report any remaining issues due to 
> the multi-release feature that would be quite helpful!
> 
> Thanks!
> 
> /Claes
> 
> Uwe Schindler  skrev: (5 mars 2016 14:24:37 CET)
>> Hi OpenJDK Core Developers,
>> 
>> you may know the Apache Lucene team is testing early access releases of
>> Java 9. We reported many bugs already, but most of them only applied to
>> Hotspot and Lucene itsself. But this problem since build 108 is now
>> really severe, because it breaks the build system already!
>> 
>> To allow further testing of Open Source Projects, I'd suggest to revert
>> the Multi-Release-JAR runtime support patch and provide a new preview
>> build ASAP, because we found out after a night of debugging a build
>> system from which we don't know all internals what is causing the
>> problems and there is no workaround. I am very sorry that I have to say
>> this, but it unfortunately build 108 breaks *ALL* versions of Apache
>> Ant, the grandfather of all Java build systems :-) I know also OpenJDK
>> is using it, too! So with Multi-Release JAR file patch applied (see
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c), any
>> Ant-based build - including the JDK build itsself - would no longer
>> bootstrap. It is impossible to also build Gradle projects, because
>> Gradle uses Ant internally for many tasks). Maven projects may be
>> affected, too.
>> 
>> Now you might have the question: What happened?
>> 
>> We tried to build Lucene on our Jenkins server, but the build itsself
>> failed with a stupid error message:
>> 
>> BUILD FAILED
>> /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:21: The
>> following error occurred while executing this line:
>> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:56:
>> not doesn't support the nested "matches" element.
>> 
>> The first idea was: Ah, there were changes in XML parsing
>> (JDK-8149915). So we debugged the build. But it was quite clear that
>> XML parsing was not the issue. It got quite clear when we enabled
>> "-debug" on the build. What happened was that Ant was not loading its
>> internal conditions/tasks/type definitions anymore, so the build system
>> does not know almost any type anymore. The debug log showed that Ant
>> was no longer able to load the resource
>> "/org/apache/tools/ant/antlib.xml" from its own JAR file anymore.
>> Instead it printed some strange debugging output (which looked totally
>> broken).
>> 
>> I spend the whole night digging through their code and found the issue:
>> The commit of Multi-Release-Jar files (see
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c) broke
>> resource handling in Apache Ant. In short: If you call
>> ClassLoader.getResources() / or getResource() you get back an URL from
>> where you can load the Resource - this is all fine and still works.
>> But, with the Multi-Release JAR files patch this now has an URL
>> fragment appended to the URL: '#release' (see
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c); this also
>> applies to non-multi-release JAR files like Apache Ant's "ant.jar".
>> 
>> In Java 7, Java 8,... and Java 9pre-b108,
>> ClassLoader.getResource()/getResources() returned stuff like: 
>> 
>> "jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml"
>> 
>> Now in Java 9b108 the following is returned:
>> 
>> "jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml#release"
>> 
>> And here Ant breaks (and I assume many other projects like Maven, too).
>> Ant checks for the file extension of the string (because it may load
>> definitions from both XML and properties files). So it does
>> endsWith(".xml") and of course this now returns false. The effect is
>> that A

RE: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-05 Thread Uwe Schindler

Hi Stefan,

> -Original Message-
> From: Stefan Bodewig [mailto:bode...@apache.org]
> Sent: Saturday, March 05, 2016 7:56 PM
> To: dev@ant.apache.org; Uwe Schindler 
> Cc: 'Alan Bateman' ; core-libs-
> d...@openjdk.java.net; rory.odonn...@oracle.com; dev@ant.apache.org;
> 'Steve Drach' 
> Subject: Re: Multi-Release JAR file patch as applied to build 108 of Java 9
> breaks almost every project out there (Apache Ant, Gradle, partly Apache
> Maven)
> 
> On 2016-03-05, Uwe Schindler wrote:
> 
> > This is why I put the Ant developers in CC. The correct way would be
> > to look at the *decoded* path (not just getPath() because this is also
> > one of the "famous" traps in the URL class - one reason why it should
> > be avoided in favor of URI). URL.toURI().getPath() is most safe to fix
> > the issue in Apache Ant
> 
> Part of the reason for this certainly is that the code has been written
> before the URI class even existed.
> 
> > (Stefan Bodewig: Should I open an issue in Ant?).
> 
> Yes, please do. Thanks Uwe.

I opened: https://bz.apache.org/bugzilla/show_bug.cgi?id=59130

> > Maybe Ant developers can fix this code in later versions to handle
> > URLs more correct.
> 
> +1

Unfortunately this is not the only issue caused by this. After I tried to build 
Lucene with the patch applied, the next candidate for the issue broke:
Apache Ivy. It was no longer able to load the ivy-settings.xml file from its 
JAR file.

The reason here is another one: It constructs the JAR file URL on its own (it 
looks like this), but does not add the #release fragment. And because of this, 
JarURLConnection does not find the file...:

[...] multiple parent causes [...]
Caused by: java.io.FileNotFoundException: JAR entry 
org/apache/ivy/core/settings/ivysett/ivysettings-public.xml not found in 
C:\Users\Uwe Schindler\.ant\lib\ivy-2.3.0.jar
at 
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:142)
at 
sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
at 
org.apache.ivy.util.url.BasicURLHandler.openStream(BasicURLHandler.java:171)
at 
org.apache.ivy.util.url.URLHandlerDispatcher.openStream(URLHandlerDispatcher.java:74)
at 
org.apache.ivy.core.settings.XmlSettingsParser.doParse(XmlSettingsParser.java:157)
at 
org.apache.ivy.core.settings.XmlSettingsParser.parse(XmlSettingsParser.java:183)
at 
org.apache.ivy.core.settings.XmlSettingsParser.includeStarted(XmlSettingsParser.java:435)
at 
org.apache.ivy.core.settings.XmlSettingsParser.startElement(XmlSettingsParser.java:211)
... 35 more

So it looks like the Multi-release JAR file patch also breaks the other way 
round: Code constructing JAR URLs according to the standard no longer work. In 
my opinion, the JAR URLs should not change at all and the code should 
transparently choose the right release version. Maybe add a fragment only to 
explicitly state a specific version (so one would be able to load the Java 7 
version). But this could also be done using the META-INF/... path. The default 
handling should be that "old" and (I think they are standardized) JAR URLs 
still works as they should - not requiring the fragment!

Uwe

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

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-05 Thread Stefan Bodewig

On 2016-03-05, Uwe Schindler wrote:

> This is why I put the Ant developers in CC. The correct way would be
> to look at the *decoded* path (not just getPath() because this is also
> one of the "famous" traps in the URL class - one reason why it should
> be avoided in favor of URI). URL.toURI().getPath() is most safe to fix
> the issue in Apache Ant

Part of the reason for this certainly is that the code has been written
before the URI class even existed.

> (Stefan Bodewig: Should I open an issue in Ant?).

Yes, please do. Thanks Uwe.

> Maybe Ant developers can fix this code in later versions to handle
> URLs more correct.

+1

Stefan

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

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-05 Thread Alan Bateman



On 05/03/2016 13:24, Uwe Schindler wrote:

:

I'd suggest to please ASAP revert the Multi-Release JAR file patch and provide 
a new preview build as soon as possible. I think there is more work needed to 
fix this. If this does not revert to the original state, it will be impossible 
to build and test Lucene, Elasticsearch, (and almost every Java project out 
there!). So short: We cannot test anymore and it is likely that we cannot 
support Java 9 anymore because the build system used by most Java projects 
behind the scenes does not bootstrap itself anymore.

Sigh, I think those of us that reviewed this missed the point that the 
fragment is appended by default. This will of course break code that 
parses URL strings in naive ways (anything looking for ".xml" should be 
looking at the path component of course). I'll create a bug for this 
now, assuming you haven't created one already.


One general point is that the purpose of EA builds and timely testing by 
Lucene and other projects is invaluable for shaking out issues. There 
will be issues periodically and much better to find these within a few 
days of pushing a change rather than months later.


-Alan

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

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-05 Thread Claes Redestad

Hi,

similar issues were discovered too late to stop b108, e.g., 
https://bugs.openjdk.java.net/browse/JDK-8150920. Fix is already in jdk9/dev, 
so I think the next build should be more well-behaved and hope we can provide 
it more promptly than normal.

If you can build OpenJDK from jdk9/dev and report any remaining issues due to 
the multi-release feature that would be quite helpful!

Thanks!

/Claes

Uwe Schindler  skrev: (5 mars 2016 14:24:37 CET)
>Hi OpenJDK Core Developers,
>
>you may know the Apache Lucene team is testing early access releases of
>Java 9. We reported many bugs already, but most of them only applied to
>Hotspot and Lucene itsself. But this problem since build 108 is now
>really severe, because it breaks the build system already!
>
>To allow further testing of Open Source Projects, I'd suggest to revert
>the Multi-Release-JAR runtime support patch and provide a new preview
>build ASAP, because we found out after a night of debugging a build
>system from which we don't know all internals what is causing the
>problems and there is no workaround. I am very sorry that I have to say
>this, but it unfortunately build 108 breaks *ALL* versions of Apache
>Ant, the grandfather of all Java build systems :-) I know also OpenJDK
>is using it, too! So with Multi-Release JAR file patch applied (see
>http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c), any
>Ant-based build - including the JDK build itsself - would no longer
>bootstrap. It is impossible to also build Gradle projects, because
>Gradle uses Ant internally for many tasks). Maven projects may be
>affected, too.
>
>Now you might have the question: What happened?
>
>We tried to build Lucene on our Jenkins server, but the build itsself
>failed with a stupid error message:
>
>BUILD FAILED
>/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:21: The
>following error occurred while executing this line:
>/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:56:
>not doesn't support the nested "matches" element.
>
>The first idea was: Ah, there were changes in XML parsing
>(JDK-8149915). So we debugged the build. But it was quite clear that
>XML parsing was not the issue. It got quite clear when we enabled
>"-debug" on the build. What happened was that Ant was not loading its
>internal conditions/tasks/type definitions anymore, so the build system
>does not know almost any type anymore. The debug log showed that Ant
>was no longer able to load the resource
>"/org/apache/tools/ant/antlib.xml" from its own JAR file anymore.
>Instead it printed some strange debugging output (which looked totally
>broken).
>
>I spend the whole night digging through their code and found the issue:
>The commit of Multi-Release-Jar files (see
>http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c) broke
>resource handling in Apache Ant. In short: If you call
>ClassLoader.getResources() / or getResource() you get back an URL from
>where you can load the Resource - this is all fine and still works.
>But, with the Multi-Release JAR files patch this now has an URL
>fragment appended to the URL: '#release' (see
>http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c); this also
>applies to non-multi-release JAR files like Apache Ant's "ant.jar".
>
>In Java 7, Java 8,... and Java 9pre-b108,
>ClassLoader.getResource()/getResources() returned stuff like: 
>
>"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml"
>
>Now in Java 9b108 the following is returned:
>
>"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml#release"
>
>And here Ant breaks (and I assume many other projects like Maven, too).
>Ant checks for the file extension of the string (because it may load
>definitions from both XML and properties files). So it does
>endsWith(".xml") and of course this now returns false. The effect is
>that Ant tries to load its own task definitions as a java properties
>file instead of XML. Of course this fails, because the data behind this
>URL is XML. The effect is that Ant cannot bootstrap as everything to
>build is missing.
>
>One might say: Ant's code is broken (I agree, it is not nice because it
>relies on the string representation of the resource URL - which is a
>no-go anyways), but it is impossible to fix, because Ant is bundled on
>most developer computers and those will suddenly break with Java 9!
>There is also no version out there that works around this, so we cannot
>test anything anymore!
>
>The problematic line in Ant's code is here:
>http://grepcode.com/file/repo1.maven.org/maven2/org.apache.ant/

RE: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-05 Thread Uwe Schindler

Thanks Alan,

I am glad that the appending of "#resource" is indeed a bug.

> > I'd suggest to please ASAP revert the Multi-Release JAR file patch and
> provide a new preview build as soon as possible. I think there is more work
> needed to fix this. If this does not revert to the original state, it will be
> impossible to build and test Lucene, Elasticsearch, (and almost every Java
> project out there!). So short: We cannot test anymore and it is likely that we
> cannot support Java 9 anymore because the build system used by most Java
> projects behind the scenes does not bootstrap itself anymore.
> >
> Sigh, I think those of us that reviewed this missed the point that the
> fragment is appended by default. This will of course break code that
> parses URL strings in naive ways (anything looking for ".xml" should be
> looking at the path component of course).

This is why I put the Ant developers in CC. The correct way would be to look at 
the *decoded* path (not just getPath() because this is also one of the "famous" 
traps in the URL class - one reason why it should be avoided in favor of URI). 
URL.toURI().getPath() is most safe to fix the issue in Apache Ant (Stefan 
Bodewig: Should I open an issue in Ant?). Maybe Ant developers can fix this 
code in later versions to handle URLs more correct. In general there is lots of 
code outside that incorrectly uses URLs, because developers are lazy...

> I'll create a bug for this
> now, assuming you haven't created one already.

No, I haven't. Thanks for doing this.

> One general point is that the purpose of EA builds and timely testing by
> Lucene and other projects is invaluable for shaking out issues. There
> will be issues periodically and much better to find these within a few
> days of pushing a change rather than months later.

This is why we do this! The problem with the EA builds is still the large delay 
until pushes are appearing in builds. In most cases it takes > 2 weeks until an 
EA build contains pushed fixes.

We are still waiting for fixes of JDK-8150280 and JDK-8150436 (duplicate of 
JDK-8148786). Both issues were resolved long time ago. The problem is if we 
have fatal issues like this, because it prevents testing the above bugs (once 
they are fixed).

Thanks,
Uwe


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

RE: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-05 Thread Uwe Schindler

Hi Claes,

 

is there a way to just build a new runtime library without compiling a full JDK 
(including Hotspot). So just replacing the jimage files locally?

 

Uwe

 

-

Uwe Schindler

uschind...@apache.org 

ASF Member, Apache Lucene PMC / Committer

Bremen, Germany

http://lucene.apache.org/

 

From: Claes Redestad [mailto:claes.redes...@oracle.com] 
Sent: Saturday, March 05, 2016 2:50 PM
To: Uwe Schindler ; core-libs-...@openjdk.java.net
Cc: rory.odonn...@oracle.com; dev@ant.apache.org; bode...@apache.org
Subject: Re: Multi-Release JAR file patch as applied to build 108 of Java 9 
breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

 

Hi,

similar issues were discovered too late to stop b108, e.g., 
https://bugs.openjdk.java.net/browse/JDK-8150920. Fix is already in jdk9/dev, 
so I think the next build should be more well-behaved and hope we can provide 
it more promptly than normal.

If you can build OpenJDK from jdk9/dev and report any remaining issues due to 
the multi-release feature that would be quite helpful!

Thanks!

/Claes

Uwe Schindler mailto:uschind...@apache.org> > skrev: (5 
mars 2016 14:24:37 CET)

Hi OpenJDK Core Developers,

you may know the Apache Lucene team is testing early access releases of Java 9. 
We reported many bugs already, but most of them only applied to Hotspot and 
Lucene itsself. But this problem since build 108 is now really severe, because 
it breaks the build system already!

To allow further testing of Open Source Projects, I'd suggest to revert the 
Multi-Release-JAR runtime support patch and provide a new preview build ASAP, 
because we found out after a night of debugging a build system from which we 
don't know all internals what is causing the problems and there is no 
workaround. I am very sorry that I have to say this, but it unfortunately build 
108 breaks *ALL* versions of Apache Ant, the grandfather of all Java build 
systems :-) I know also OpenJDK is using it, too! So with Multi-Release JAR 
file patch applied (see 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c), any Ant-based build 
- including the JDK build itsself - would no longer bootstrap. It is impossible 
to also build Gradle projects, because Gradle uses Ant internally for many 
tasks). Maven projects may be affected, too.

Now you might have the question: What happened?

We tried to build Lucene on our Jenkins server, but the build itsself failed 
with a stupid error message:

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:21: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:56: 
not doesn't support the nested "matches" element.

The first idea was: Ah, there were changes in XML parsing (JDK-8149915). So we 
debugged the build. But it was quite clear that XML parsing was not the issue. 
It got quite clear when we enabled "-debug" on the build. What happened was 
that Ant was not loading its internal conditions/tasks/type definitions 
anymore, so the build system does not know almost any type anymore. The debug 
log showed that Ant was no longer able to load the resource 
"/org/apache/tools/ant/antlib.xml" from its own JAR file anymore. Instead it 
printed some strange debugging output (which looked totally broken).

I spend the whole night digging through their code and found the issue: The 
commit of Multi-Release-Jar files (see 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c) broke resource 
handling in Apache Ant. In short: If you call ClassLoader.getResources() / or 
getResource() you get back an URL from where you can load the Resource - this 
is all fine and still works. But, with the Multi-Release JAR files patch this 
now has an URL fragment appended to the URL: '#release' (see 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c); this also applies 
to non-multi-release JAR files like Apache Ant's "ant.jar".

In Java 7, Java 8,... and Java 9pre-b108, 
ClassLoader.getResource()/getResources() returned stuff like: 

"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml"

Now in Java 9b108 the following is returned:

"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml#release"

And here Ant breaks (and I assume many other projects like Maven, too). Ant 
checks for the file extension of the string (because it may load definitions 
from both XML and properties files). So it does endsWith(".xml") and of course 
this now returns false. The effect is that Ant tries to load its own task 
definitions as a java properties file instead of XML. Of course this fails, 
because the data behind this URL is XML. The effect is that Ant cannot 
bootstrap as everything to build is missing.

One might say: Ant's code is broken (I agree

Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-05 Thread Uwe Schindler

Hi OpenJDK Core Developers,

you may know the Apache Lucene team is testing early access releases of Java 9.
We reported many bugs already, but most of them only applied to Hotspot and
Lucene itsself. But this problem since build 108 is now really severe, because
it breaks the build system already!

To allow further testing of Open Source Projects, I'd suggest to revert the
Multi-Release-JAR runtime support patch and provide a new preview build ASAP,
because we found out after a night of debugging a build system from which we
don't know all internals what is causing the problems and there is no
workaround. I am very sorry that I have to say this, but it unfortunately build
108 breaks *ALL* versions of Apache Ant, the grandfather of all Java build
systems :-) I know also OpenJDK is using it, too! So with Multi-Release JAR
file patch applied (see
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c), any Ant-based build
- including the JDK build itsself - would no longer bootstrap. It is impossible
to also build Gradle projects, because Gradle uses Ant internally for many
tasks). Maven projects may be affected, too.

Now you might have the question: What happened?

We tried to build Lucene on our Jenkins server, but the build itsself failed
with a stupid error message:

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:21: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:56:
not doesn't support the nested "matches" element.

The first idea was: Ah, there were changes in XML parsing (JDK-8149915). So we
debugged the build. But it was quite clear that XML parsing was not the issue.
It got quite clear when we enabled "-debug" on the build. What happened was
that Ant was not loading its internal conditions/tasks/type definitions
anymore, so the build system does not know almost any type anymore. The debug
log showed that Ant was no longer able to load the resource
"/org/apache/tools/ant/antlib.xml" from its own JAR file anymore. Instead it
printed some strange debugging output (which looked totally broken).

I spend the whole night digging through their code and found the issue: The
commit of Multi-Release-Jar files (see
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c) broke resource
handling in Apache Ant. In short: If you call ClassLoader.getResources() / or
getResource() you get back an URL from where you can load the Resource - this
is all fine and still works. But, with the Multi-Release JAR files patch this
now has an URL fragment appended to the URL: '#release' (see
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c); this also applies
to non-multi-release JAR files like Apache Ant's "ant.jar".

In Java 7, Java 8,... and Java 9pre-b108,
ClassLoader.getResource()/getResources() returned stuff like:

"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml"

Now in Java 9b108 the following is returned:

"jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml#release"

And here Ant breaks (and I assume many other projects like Maven, too). Ant
checks for the file extension of the string (because it may load definitions
from both XML and properties files). So it does endsWith(".xml") and of course
this now returns false. The effect is that Ant tries to load its own task
definitions as a java properties file instead of XML. Of course this fails,
because the data behind this URL is XML. The effect is that Ant cannot
bootstrap as everything to build is missing.

One might say: Ant's code is broken (I agree, it is not nice because it relies
on the string representation of the resource URL - which is a no-go anyways),
but it is impossible to fix, because Ant is bundled on most developer computers
and those will suddenly break with Java 9! There is also no version out there
that works around this, so we cannot test anything anymore!

The problematic line in Ant's code is here:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.ant/ant/1.9.6/org/apache/tools/ant/taskdefs/Definer.java?av=f#259

I'd suggest to please ASAP revert the Multi-Release JAR file patch and provide
a new preview build as soon as possible. I think there is more work needed to
fix this. If this does not revert to the original state, it will be impossible
to build and test Lucene, Elasticsearch, (and almost every Java project out
there!). So short: We cannot test anymore and it is likely that we cannot
support Java 9 anymore because the build system used by most Java projects
behind the scenes does not bootstrap itself anymore.

My suggestion would be to investigate other versions for this patch that does
*not* modify the resource URLs by appending a fragment to them

Re: Ivy - Patch for IVY-1522 (needs to be tested on Windows OS)

2015-08-30 Thread Jaikiran Pai

I have sent a PR with a fix for IVY-1522 
https://github.com/apache/ant-ivy/pull/8 which will have to be tested 
against a Windows OS.


-Jaikiran
On Thursday 23 July 2015 06:48 PM, Jaikiran Pai wrote:
I have a patch (along with a testcase) for this issue 
https://issues.apache.org/jira/browse/IVY-1522 which I would like to 
contribute. However, I am on a *nix operating system and don't use 
Windows OS. The patch and the test (and the rest of the existing 
tests) works fine on this system but in order to verify against 
Windows OS, it would have to be run against such a system.


How is this currently handled? Should I go ahead and submit a PR at 
github and will it then be run by someone against a Windows OS?


-Jaikiran



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

Ivy - Patch for IVY-1522 (needs to be tested on Windows OS)

2015-07-23 Thread Jaikiran Pai

I have a patch (along with a testcase) for this issue 
https://issues.apache.org/jira/browse/IVY-1522 which I would like to 
contribute. However, I am on a *nix operating system and don't use 
Windows OS. The patch and the test (and the rest of the existing tests) 
works fine on this system but in order to verify against Windows OS, it 
would have to be run against such a system.


How is this currently handled? Should I go ahead and submit a PR at 
github and will it then be run by someone against a Windows OS?


-Jaikiran

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

[PATCH] Bug 57789 - Add possibility to send email with CC and BCC via MailLogger

2015-04-15 Thread Roman Savko

Hello guys,

Could you, please, review and apply patch for *Bug 57789 - Add possibility
to send email with CC and BCC via MailLogger*?

Patch based on trunk.


Regards,
Roman.

Re: Patch: add support for http.agent override

2014-03-09 Thread Antoine Levy Lambert

Hello Tony,

thanks for your contribution, patch submitted.

Regards,

Antoine
On Feb 28, 2014, at 10:15 PM, Tony Likhite  wrote:

> We needed this to get Ivy working with a client's extremely paranoid HTTP
> proxy setup. It insisted on a specific User-Agent header, so we added
> support for -Dhttp.agent (same as Ant).
> 
> -- 
> 
> Index: src/java/org/apache/ivy/util/url/AbstractURLHandler.java
> ===
> --- src/java/org/apache/ivy/util/url/AbstractURLHandler.java(revision
> 1573075)
> +++ src/java/org/apache/ivy/util/url/AbstractURLHandler.java(working
> copy)
> @@ -30,6 +30,7 @@
> import java.util.zip.GZIPInputStream;
> import java.util.zip.Inflater;
> import java.util.zip.InflaterInputStream;
> +import org.apache.ivy.Ivy;
> 
> public abstract class AbstractURLHandler implements URLHandler {
> 
> @@ -62,6 +63,14 @@
> return getURLInfo(url, timeout).getLastModified();
> }
> 
> +protected String getUserAgent() {
> +String userAgent = System.getProperty("http.agent");
> +if (userAgent == null) {
> +userAgent = "Apache Ivy/" + Ivy.getIvyVersion();
> +}
> +return userAgent;
> +}
> +
> protected void validatePutStatusCode(URL dest, int statusCode, String
> statusMessage)
> throws IOException {
> switch (statusCode) {
> Index: src/java/org/apache/ivy/util/url/BasicURLHandler.java
> ===
> --- src/java/org/apache/ivy/util/url/BasicURLHandler.java(revision
> 1573075)
> +++ src/java/org/apache/ivy/util/url/BasicURLHandler.java(working copy)
> @@ -64,7 +64,7 @@
> try {
> url = normalizeToURL(url);
> con = url.openConnection();
> -con.setRequestProperty("User-Agent", "Apache Ivy/" +
> Ivy.getIvyVersion());
> +con.setRequestProperty("User-Agent", getUserAgent());
> if (con instanceof HttpURLConnection) {
> HttpURLConnection httpCon = (HttpURLConnection) con;
> if (getRequestMethod() == URLHandler.REQUEST_METHOD_HEAD) {
> @@ -159,7 +159,7 @@
> try {
> url = normalizeToURL(url);
> conn = url.openConnection();
> -conn.setRequestProperty("User-Agent", "Apache Ivy/" +
> Ivy.getIvyVersion());
> +conn.setRequestProperty("User-Agent", getUserAgent());
> conn.setRequestProperty("Accept-Encoding", "gzip,deflate");
> if (conn instanceof HttpURLConnection) {
> HttpURLConnection httpCon = (HttpURLConnection) conn;
> @@ -193,7 +193,7 @@
> try {
> src = normalizeToURL(src);
> srcConn = src.openConnection();
> -srcConn.setRequestProperty("User-Agent", "Apache Ivy/" +
> Ivy.getIvyVersion());
> +srcConn.setRequestProperty("User-Agent", getUserAgent());
> srcConn.setRequestProperty("Accept-Encoding", "gzip,deflate");
> if (srcConn instanceof HttpURLConnection) {
> HttpURLConnection httpCon = (HttpURLConnection) srcConn;
> @@ -244,7 +244,7 @@
> conn = (HttpURLConnection) dest.openConnection();
> conn.setDoOutput(true);
> conn.setRequestMethod("PUT");
> -conn.setRequestProperty("User-Agent", "Apache Ivy/" +
> Ivy.getIvyVersion());
> +conn.setRequestProperty("User-Agent", getUserAgent());
> conn.setRequestProperty("Content-type",
> "application/octet-stream");
> conn.setRequestProperty("Content-length",
> Long.toString(source.length()));
> conn.setInstanceFollowRedirects(true);
> Index: src/java/org/apache/ivy/util/url/HttpClientHandler.java
> ===
> --- src/java/org/apache/ivy/util/url/HttpClientHandler.java(revision
> 1573075)
> +++ src/java/org/apache/ivy/util/url/HttpClientHandler.java(working
> copy)
> @@ -295,7 +295,7 @@
> 
> // user-agent
> 
> httpClient.getParams().setParameter(HttpMethodParams.USER_AGENT,
> -"Apache Ivy/" + Ivy.getIvyVersion());
> +getUserAgent());
> 
> // authentication
> 
> httpClient.getParams().setParameter(CredentialsProvider.PROVIDER,
> 
> 
> -- 
> Tony Likhite


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

Patch: add support for http.agent override

2014-02-28 Thread Tony Likhite

We needed this to get Ivy working with a client's extremely paranoid HTTP
proxy setup. It insisted on a specific User-Agent header, so we added
support for -Dhttp.agent (same as Ant).

-- 

Index: src/java/org/apache/ivy/util/url/AbstractURLHandler.java
===
--- src/java/org/apache/ivy/util/url/AbstractURLHandler.java(revision
1573075)
+++ src/java/org/apache/ivy/util/url/AbstractURLHandler.java(working
copy)
@@ -30,6 +30,7 @@
 import java.util.zip.GZIPInputStream;
 import java.util.zip.Inflater;
 import java.util.zip.InflaterInputStream;
+import org.apache.ivy.Ivy;

 public abstract class AbstractURLHandler implements URLHandler {

@@ -62,6 +63,14 @@
 return getURLInfo(url, timeout).getLastModified();
 }

+protected String getUserAgent() {
+String userAgent = System.getProperty("http.agent");
+if (userAgent == null) {
+userAgent = "Apache Ivy/" + Ivy.getIvyVersion();
+}
+return userAgent;
+}
+
 protected void validatePutStatusCode(URL dest, int statusCode, String
statusMessage)
 throws IOException {
 switch (statusCode) {
Index: src/java/org/apache/ivy/util/url/BasicURLHandler.java
===
--- src/java/org/apache/ivy/util/url/BasicURLHandler.java(revision
1573075)
+++ src/java/org/apache/ivy/util/url/BasicURLHandler.java(working copy)
@@ -64,7 +64,7 @@
 try {
 url = normalizeToURL(url);
 con = url.openConnection();
-con.setRequestProperty("User-Agent", "Apache Ivy/" +
Ivy.getIvyVersion());
+con.setRequestProperty("User-Agent", getUserAgent());
 if (con instanceof HttpURLConnection) {
 HttpURLConnection httpCon = (HttpURLConnection) con;
 if (getRequestMethod() == URLHandler.REQUEST_METHOD_HEAD) {
@@ -159,7 +159,7 @@
 try {
 url = normalizeToURL(url);
 conn = url.openConnection();
-conn.setRequestProperty("User-Agent", "Apache Ivy/" +
Ivy.getIvyVersion());
+conn.setRequestProperty("User-Agent", getUserAgent());
 conn.setRequestProperty("Accept-Encoding", "gzip,deflate");
 if (conn instanceof HttpURLConnection) {
 HttpURLConnection httpCon = (HttpURLConnection) conn;
@@ -193,7 +193,7 @@
 try {
 src = normalizeToURL(src);
 srcConn = src.openConnection();
-srcConn.setRequestProperty("User-Agent", "Apache Ivy/" +
Ivy.getIvyVersion());
+srcConn.setRequestProperty("User-Agent", getUserAgent());
 srcConn.setRequestProperty("Accept-Encoding", "gzip,deflate");
 if (srcConn instanceof HttpURLConnection) {
 HttpURLConnection httpCon = (HttpURLConnection) srcConn;
@@ -244,7 +244,7 @@
 conn = (HttpURLConnection) dest.openConnection();
 conn.setDoOutput(true);
 conn.setRequestMethod("PUT");
-conn.setRequestProperty("User-Agent", "Apache Ivy/" +
Ivy.getIvyVersion());
+conn.setRequestProperty("User-Agent", getUserAgent());
 conn.setRequestProperty("Content-type",
"application/octet-stream");
 conn.setRequestProperty("Content-length",
Long.toString(source.length()));
 conn.setInstanceFollowRedirects(true);
Index: src/java/org/apache/ivy/util/url/HttpClientHandler.java
===
--- src/java/org/apache/ivy/util/url/HttpClientHandler.java(revision
1573075)
+++ src/java/org/apache/ivy/util/url/HttpClientHandler.java(working
copy)
@@ -295,7 +295,7 @@

 // user-agent

httpClient.getParams().setParameter(HttpMethodParams.USER_AGENT,
-"Apache Ivy/" + Ivy.getIvyVersion());
+getUserAgent());

 // authentication

httpClient.getParams().setParameter(CredentialsProvider.PROVIDER,


-- 
Tony Likhite

Re: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of Ant (patch included)

2013-12-27 Thread Ben Gertzfield

On Sun, Dec 22, 2013 at 10:01 PM, Stefan Bodewig  wrote:

> On 2013-12-23,  wrote:
>
> > Do we want to distribute the installer systematically with new
> > versions of Ant ?
>
> I wouldn't mind much if it can be created outside of a Mac.  Then again
> we don't ship Windows installers, Debian packages, RPMs ... either.
>

Currently it does depend on a closed-source tool that ships with OS X, but
if we could replace that, the rest can run anywhere.

The main reason I contributed the .pkg installer logic was that Apple
previously shipped Ant with OS 10.8 and earlier, but they removed it in
10.9.

I think a lot of OS X users have grown to depend on Ant being available,
but I feel requiring them to install Homebrew or other heavyweight package
management systems is a lot to ask. It'd be really nice if we could fill in
the gaps Apple left behind in 10.9.

Ben

AW: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of Ant (patch included)

2013-12-23 Thread jhm

Sadly there is no Mac or Debian slave available for Jenkins [1].
With that we could set up some Jobs for building on Windows, Mac (n.a.), 
Solaris, Ubuntu, Debian (n.a.).


Jan


[1] https://builds.apache.org/

> -Ursprüngliche Nachricht-
> Von: Andre-John mas [mailto:andrejohn@gmail.com]
> Gesendet: Montag, 23. Dezember 2013 17:13
> An: Ant Developers List
> Cc: Ant Developers List
> Betreff: Re: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of
> Ant (patch included)
> 
> Hi,
> 
> I think this may be the simplest approach, since invariably most people
> using Ant will probably interact with the command line at some point?
> 
> Andre
> 
> Sent from my tablet
> 
> On 2013-12-23, at 11:05, Nicolas Lalevée 
> wrote:
> 
> >
> > Le 23 déc. 2013 à 13:47, Antoine Levy Lambert  a
> écrit :
> >
> >> Hello Stefan,
> >>
> >> the python script to create the MacOSX installer relies on a utility
> pkgbuild which I suppose locks it to MacOSX.
> >> True we do not ship Windows Installers, Debian packages, so maybe we
> should hold off on shipping the MacOSX installer.
> >> Especially since there is no guarantee that future builds will be
> done on Macs.
> >
> > BTW, I am using macports to install Ant on my mac, works like a
> charm, and updated frequently. And I know it is possible to do it via
> homebrew or fink too.
> >
> > Nicolas
> >
> >
> > -
> > 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: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of Ant (patch included)

2013-12-23 Thread Andre-John mas

Hi,

I think this may be the simplest approach, since invariably most people using 
Ant will probably interact with the command line at some point?

Andre

Sent from my tablet

On 2013-12-23, at 11:05, Nicolas Lalevée  wrote:

> 
> Le 23 déc. 2013 à 13:47, Antoine Levy Lambert  a écrit :
> 
>> Hello Stefan,
>> 
>> the python script to create the MacOSX installer relies on a utility 
>> pkgbuild which I suppose locks it to MacOSX.
>> True we do not ship Windows Installers, Debian packages, so maybe we should 
>> hold off on shipping the MacOSX installer.
>> Especially since there is no guarantee that future builds will be done on 
>> Macs.
> 
> BTW, I am using macports to install Ant on my mac, works like a charm, and 
> updated frequently. And I know it is possible to do it via homebrew or fink 
> too.
> 
> Nicolas
> 
> 
> -
> 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: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of Ant (patch included)

2013-12-23 Thread Andre-John mas

On 2013-12-23, at 1:01, Stefan Bodewig  wrote:

> On 2013-12-23,  wrote:
> 
>> Do we want to distribute the installer systematically with new
>> versions of Ant ?
> 
> I wouldn't mind much if it can be created outside of a Mac.  Then again
> we don't ship Windows installers, Debian packages, RPMs ... either.

That would be cool, though for that to happen we would need to find some 
library or tool that can do that. Does anyone know if the FreeBSD pkg_create 
tool creates compatible files?

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

Re: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of Ant (patch included)

2013-12-23 Thread Nicolas Lalevée


Le 23 déc. 2013 à 13:47, Antoine Levy Lambert  a écrit :

> Hello Stefan,
> 
> the python script to create the MacOSX installer relies on a utility pkgbuild 
> which I suppose locks it to MacOSX.
> True we do not ship Windows Installers, Debian packages, so maybe we should 
> hold off on shipping the MacOSX installer.
> Especially since there is no guarantee that future builds will be done on 
> Macs.

BTW, I am using macports to install Ant on my mac, works like a charm, and 
updated frequently. And I know it is possible to do it via homebrew or fink too.

Nicolas


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

Re: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of Ant (patch included)

2013-12-23 Thread Antoine Levy Lambert

Hello Stefan,

the python script to create the MacOSX installer relies on a utility pkgbuild 
which I suppose locks it to MacOSX.
True we do not ship Windows Installers, Debian packages, so maybe we should 
hold off on shipping the MacOSX installer.
Especially since there is no guarantee that future builds will be done on Macs.

Regards,

Antoine
On Dec 23, 2013, at 1:01 AM, Stefan Bodewig wrote:

> On 2013-12-23,  wrote:
> 
>> Do we want to distribute the installer systematically with new
>> versions of Ant ?
> 
> I wouldn't mind much if it can be created outside of a Mac.  Then again
> we don't ship Windows installers, Debian packages, RPMs ... either.
> 
> 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: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of Ant (patch included)

2013-12-22 Thread Stefan Bodewig

On 2013-12-23,  wrote:

> Do we want to distribute the installer systematically with new
> versions of Ant ?

I wouldn't mind much if it can be created outside of a Mac.  Then again
we don't ship Windows installers, Debian packages, RPMs ... either.

Stefan

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

[PATCH r3] Ivy useOrigin=true support for URLResolver with file:// URLs

2013-11-20 Thread Charles Duffy

The version here adds a unit test, and patches URLResolver per prior
feedback (which had failed to make it into the public version of the
patch's r2).
Index: src/java/org/apache/ivy/plugins/repository/url/URLRepository.java
===
--- src/java/org/apache/ivy/plugins/repository/url/URLRepository.java   
(revision 1543060)
+++ src/java/org/apache/ivy/plugins/repository/url/URLRepository.java   
(working copy)
@@ -41,10 +41,12 @@
 
 private Map resourcesCache = new HashMap();
 
+private boolean localIfFileUrl = true;
+
 public Resource getResource(String source) throws IOException {
 Resource res = (Resource) resourcesCache.get(source);
 if (res == null) {
-res = new URLResource(new URL(source));
+res = new URLResource(new URL(source), localIfFileUrl);
 resourcesCache.put(source, res);
 }
 return res;
@@ -138,4 +140,12 @@
 return null;
 }
 
+public void setLocalIfFileUrl(boolean value) {
+localIfFileUrl = value;
+}
+
+public boolean getLocalIfFileUrl() {
+return localIfFileUrl;
+}
+
 }
Index: src/java/org/apache/ivy/plugins/repository/url/URLResource.java
===
--- src/java/org/apache/ivy/plugins/repository/url/URLResource.java 
(revision 1543060)
+++ src/java/org/apache/ivy/plugins/repository/url/URLResource.java 
(working copy)
@@ -17,20 +17,26 @@
  */
 package org.apache.ivy.plugins.repository.url;
 
+import java.io.File;
 import java.io.IOException;
 import java.io.InputStream;
 import java.net.MalformedURLException;
+import java.net.URISyntaxException;
 import java.net.URL;
 
 import org.apache.ivy.plugins.repository.Resource;
+import org.apache.ivy.util.Message;
 import org.apache.ivy.util.url.URLHandlerRegistry;
 import org.apache.ivy.util.url.URLHandler.URLInfo;
 
 public class URLResource implements Resource {
 private URL url;
 
 private boolean init = false;
 
+/** whether file:// URLs are local */
+private boolean localIfFileUrl = true;
+
 private long lastModified;
 
 private long contentLength;
@@ -41,10 +47,27 @@
 this.url = url;
 }
 
+public URLResource(URL url, boolean localIfFileUrl) {
+this(url);
+this.localIfFileUrl = localIfFileUrl;
+}
+
 public String getName() {
 return url.toExternalForm();
 }
 
+public String getLocalName() {
+if(isLocal()) {
+try {
+return new File(url.toURI()).getPath();
+} catch (URISyntaxException e) {
+Message.warn("Unable to parse URI for local name " + 
getName(), e);
+return null;
+}
+}
+return null;
+}
+
 public Resource clone(String cloneName) {
 try {
 return new URLResource(new URL(cloneName));
@@ -91,8 +114,16 @@
 return getName();
 }
 
+public void setLocalIfFileUrl(boolean value) {
+localIfFileUrl = value;
+}
+
+public boolean getLocalIfFileUrl() {
+return localIfFileUrl;
+}
+
 public boolean isLocal() {
-return false;
+return localIfFileUrl && "file".equals(url.getProtocol());
 }
 
 public InputStream openStream() throws IOException {
Index: src/java/org/apache/ivy/plugins/repository/LazyResource.java
===
--- src/java/org/apache/ivy/plugins/repository/LazyResource.java
(revision 1543060)
+++ src/java/org/apache/ivy/plugins/repository/LazyResource.java
(working copy)
@@ -62,6 +62,10 @@
 return name;
 }
 
+public String getLocalName() {
+return null;
+}
+
 public boolean isLocal() {
 checkInit();
 return local;
Index: src/java/org/apache/ivy/plugins/repository/BasicResource.java
===
--- src/java/org/apache/ivy/plugins/repository/BasicResource.java   
(revision 1543060)
+++ src/java/org/apache/ivy/plugins/repository/BasicResource.java   
(working copy)
@@ -60,6 +60,10 @@
 return this.name;
 }
 
+public String getLocalName() {
+return null;
+}
+
 public boolean isLocal() {
 return this.local;
 }
Index: src/java/org/apache/ivy/plugins/repository/sftp/SFTPResource.java
===
--- src/java/org/apache/ivy/plugins/repository/sftp/SFTPResource.java   
(revision 1543060)
+++ src/java/org/apache/ivy/plugins/repository/sftp/SFTPResource.java   
(working copy)
@@ -44,6 +44,10 @@
 return path;
 }
 
+public String getLocalName() {
+return null;
+}
+
 public Resource clone(String cloneName) {
 return new SFTPResource(repository, cloneName);
 }
Index: src/java/org/apache/ivy/plugins/repository/j

Re: [PATCH] Ivy useOrigin=true support for URLResolver with file:// URLs

2013-11-18 Thread Charles Duffy

Thank you kindly for the review!

The attached revision of the patch uses the File(URI) constructor to
perform the necessary decoding.


On Sun, Nov 17, 2013 at 6:08 PM, Antoine Levy Lambert wrote:

> Hello Charles,
>
> thanks for proposing a patch.
>
> I have read the patch and I see one area for improvement.
>
> Your patch seems to assume that File URLs have exactly the same syntax
> like file system paths except the file: prefix to indicate the protocol.
>
> You need to use URLDecoder or equivalent because a File URL will have some
> special characters encoded such as spaces replaced by %32.
>
>  Regards,
>
> Antoine
>
> On Nov 11, 2013, at 1:51 PM, Charles Duffy wrote:
>
> > This isn't actually so important for URLResolver itself, which can be
> replaced with the FileSystem resolver at will -- but without this patch,
> one can't get the unique behavior of the IBiblio resolver combined with
> useOrigin.
> >
> > Feedback appreciated.
> > 
> > -
> > 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
>
>
Index: src/java/org/apache/ivy/plugins/repository/url/URLRepository.java
===
--- src/java/org/apache/ivy/plugins/repository/url/URLRepository.java   
(revision 1543060)
+++ src/java/org/apache/ivy/plugins/repository/url/URLRepository.java   
(working copy)
@@ -41,10 +41,12 @@
 
 private Map resourcesCache = new HashMap();
 
+private boolean localIfFileUrl = true;
+
 public Resource getResource(String source) throws IOException {
 Resource res = (Resource) resourcesCache.get(source);
 if (res == null) {
-res = new URLResource(new URL(source));
+res = new URLResource(new URL(source), localIfFileUrl);
 resourcesCache.put(source, res);
 }
 return res;
@@ -138,4 +140,12 @@
 return null;
 }
 
+public void setLocalIfFileUrl(boolean value) {
+localIfFileUrl = value;
+}
+
+public boolean getLocalIfFileUrl() {
+return localIfFileUrl;
+}
+
 }
Index: src/java/org/apache/ivy/plugins/repository/url/URLResource.java
===
--- src/java/org/apache/ivy/plugins/repository/url/URLResource.java 
(revision 1543060)
+++ src/java/org/apache/ivy/plugins/repository/url/URLResource.java 
(working copy)
@@ -31,6 +31,9 @@
 
 private boolean init = false;
 
+/** whether file:// URLs are local */
+private boolean localIfFileUrl = true;
+
 private long lastModified;
 
 private long contentLength;
@@ -41,10 +44,22 @@
 this.url = url;
 }
 
+public URLResource(URL url, boolean localIfFileUrl) {
+this(url);
+this.localIfFileUrl = localIfFileUrl;
+}
+
 public String getName() {
 return url.toExternalForm();
 }
 
+public String getLocalName() {
+if(isLocal()) {
+return url.getPath();
+}
+return null;
+}
+
 public Resource clone(String cloneName) {
 try {
 return new URLResource(new URL(cloneName));
@@ -91,8 +106,16 @@
 return getName();
 }
 
+public void setLocalIfFileUrl(boolean value) {
+localIfFileUrl = value;
+}
+
+public boolean getLocalIfFileUrl() {
+return localIfFileUrl;
+}
+
 public boolean isLocal() {
-return false;
+return localIfFileUrl && "file".equals(url.getProtocol());
 }
 
 public InputStream openStream() throws IOException {
Index: src/java/org/apache/ivy/plugins/repository/LazyResource.java
===
--- src/java/org/apache/ivy/plugins/repository/LazyResource.java
(revision 1543060)
+++ src/java/org/apache/ivy/plugins/repository/LazyResource.java
(working copy)
@@ -62,6 +62,10 @@
 return name;
 }
 
+public String getLocalName() {
+return null;
+}
+
 public boolean isLocal() {
 checkInit();
 return local;
Index: src/java/org/apache/ivy/plugins/repository/BasicResource.java
===
--- src/java/org/apache/ivy/plugins/repository/BasicResource.java   
(revision 1543060)
+++ src/java/org/apache/ivy/plugins/repository/BasicResource.java   
(working copy)
@@ -60,6 +60,10 @@
 return this.name;
 }
 
+public String getLocalName() {
+return

Re: [PATCH] Ivy useOrigin=true support for URLResolver with file:// URLs

2013-11-17 Thread Antoine Levy Lambert

Hello Charles,

thanks for proposing a patch.

I have read the patch and I see one area for improvement.

Your patch seems to assume that File URLs have exactly the same syntax like 
file system paths except the file: prefix to indicate the protocol.

You need to use URLDecoder or equivalent because a File URL will have some 
special characters encoded such as spaces replaced by %32.

 Regards,

Antoine

On Nov 11, 2013, at 1:51 PM, Charles Duffy wrote:

> This isn't actually so important for URLResolver itself, which can be 
> replaced with the FileSystem resolver at will -- but without this patch, one 
> can't get the unique behavior of the IBiblio resolver combined with useOrigin.
> 
> Feedback appreciated.
> 
> -
> 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

[PATCH] Ivy useOrigin=true support for URLResolver with file:// URLs

2013-11-11 Thread Charles Duffy

This isn't actually so important for URLResolver itself, which can be
replaced with the FileSystem resolver at will -- but without this patch,
one can't get the unique behavior of the IBiblio resolver combined with
useOrigin.

Feedback appreciated.
Index: src/java/org/apache/ivy/core/cache/DefaultRepositoryCacheManager.java
===
--- src/java/org/apache/ivy/core/cache/DefaultRepositoryCacheManager.java   
(revision 1540780)
+++ src/java/org/apache/ivy/core/cache/DefaultRepositoryCacheManager.java   
(working copy)
@@ -863,10 +863,11 @@
 try {
 ResolvedResource artifactRef = 
resourceResolver.resolve(artifact);
 if (artifactRef != null) {
+String localName = 
artifactRef.getResource().getLocalName();
 origin = new ArtifactOrigin(
 artifact,
 artifactRef.getResource().isLocal(),
-artifactRef.getResource().getName());
+localName != null ? localName : 
artifactRef.getResource().getName());
 if (useOrigin && artifactRef.getResource().isLocal()) {
 saveArtifactOrigin(artifact, origin);
 archiveFile = getArchiveFileInCache(artifact, 
origin);
Index: src/java/org/apache/ivy/core/cache/ArtifactOrigin.java
===
--- src/java/org/apache/ivy/core/cache/ArtifactOrigin.java  (revision 
1540780)
+++ src/java/org/apache/ivy/core/cache/ArtifactOrigin.java  (working copy)
@@ -72,6 +72,12 @@
 Checks.checkNotNull(location, "location");
 this.artifact = artifact;
 this.isLocal = isLocal;
+if(this.isLocal) {
+if(location.startsWith("file:")) {
+location = location.substring("file:".length());
+}
+Checks.checkAbsolute(location, "");
+}
 this.location = location;
 }
 
Index: src/java/org/apache/ivy/plugins/repository/vfs/VfsResource.java
===
--- src/java/org/apache/ivy/plugins/repository/vfs/VfsResource.java 
(revision 1540780)
+++ src/java/org/apache/ivy/plugins/repository/vfs/VfsResource.java 
(working copy)
@@ -201,6 +201,14 @@
 return getName().startsWith("file:");
 }
 
+public String getLocalName() {
+String name = getName();
+if(name.startsWith("file:")) {
+return name.substring("file:".length());
+}
+return null;
+}
+
 public InputStream openStream() throws IOException {
 return getContent().getInputStream();
 }
Index: src/java/org/apache/ivy/plugins/repository/url/URLResource.java
===
--- src/java/org/apache/ivy/plugins/repository/url/URLResource.java 
(revision 1540780)
+++ src/java/org/apache/ivy/plugins/repository/url/URLResource.java 
(working copy)
@@ -17,20 +17,23 @@
  */
 package org.apache.ivy.plugins.repository.url;
 
+import org.apache.ivy.plugins.repository.Resource;
+import org.apache.ivy.util.url.URLHandler.URLInfo;
+import org.apache.ivy.util.url.URLHandlerRegistry;
+
 import java.io.IOException;
 import java.io.InputStream;
 import java.net.MalformedURLException;
 import java.net.URL;
 
-import org.apache.ivy.plugins.repository.Resource;
-import org.apache.ivy.util.url.URLHandlerRegistry;
-import org.apache.ivy.util.url.URLHandler.URLInfo;
-
 public class URLResource implements Resource {
 private URL url;
 
 private boolean init = false;
 
+/** whether file:// URLs are local */
+private boolean localIfFileUrl = true;
+
 private long lastModified;
 
 private long contentLength;
@@ -41,10 +44,22 @@
 this.url = url;
 }
 
+public URLResource(URL url, boolean localIfFileUrl) {
+this(url);
+this.localIfFileUrl = localIfFileUrl;
+}
+
 public String getName() {
 return url.toExternalForm();
 }
 
+public String getLocalName() {
+if(isLocal()) {
+return url.getPath();
+}
+return null;
+}
+
 public Resource clone(String cloneName) {
 try {
 return new URLResource(new URL(cloneName));
@@ -91,8 +106,16 @@
 return getName();
 }
 
+public void setLocalIfFileUrl(boolean value) {
+localIfFileUrl = value;
+}
+
+public boolean getLocalIfFileUrl() {
+return localIfFileUrl;
+}
+
 public boolean isLocal() {
-return false;
+return localIfFileUrl && "file".equals(url.getProtocol());
 }
 
 public InputStream

Re: [PATCH] fixing unit tests related to URLResolver

2013-08-28 Thread Matt Benson

Actually the right way is to submit a report through Ivy's issue tracker.

Thanks,
Matt
On Aug 27, 2013 8:35 PM, "Jerry Maloney"  wrote:

> Hi, I was doing some work on
> https://issues.apache.org/jira/browse/IVY-1436 and I think I found some
> unit tests that are broken due to some changed URLs and structure at
> http://repo1.maven.org/
>
> I haven't submitted to this code base before; could someone in the know
> please let me know if this is still the right way?
>
> Thanks,
> Jerry Maloney
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>

Re: [PATCH] IVY-1436

2013-08-28 Thread Jerry

Thanks, Maarten. I've attached it and the other patch I wrote (about the
URLResolver unit test) to https://issues.apache.org/jira/browse/IVY-1436.

Jerry



--
View this message in context: 
http://ant.1045680.n5.nabble.com/PATCH-IVY-1436-tp5714410p5714414.html
Sent from the Ant - Dev mailing list archive at Nabble.com.

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

Re: [PATCH] IVY-1436

2013-08-27 Thread Maarten Coene

Could you please attach your patch to the JIRA issue?

Thanks!
Maarten





 Van: Jerry Maloney 
Aan: dev@ant.apache.org 
Verzonden: woensdag 28 augustus 3:37 2013
Onderwerp: [PATCH] IVY-1436
 


This patch fixes the issue I described in 
https://issues.apache.org/jira/browse/IVY-1436 .

Thanks,

Jerry Maloney

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

[PATCH] IVY-1436

2013-08-27 Thread Jerry Maloney

This patch fixes the issue I described in
https://issues.apache.org/jira/browse/IVY-1436 .

Thanks,
Jerry Maloney


patch.tar.gz
Description: GNU Zip compressed data

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

[PATCH] fixing unit tests related to URLResolver

2013-08-27 Thread Jerry Maloney

Hi, I was doing some work on
https://issues.apache.org/jira/browse/IVY-1436and I think I found some
unit tests that are broken due to some changed
URLs and structure at http://repo1.maven.org/

I haven't submitted to this code base before; could someone in the know
please let me know if this is still the right way?

Thanks,
Jerry Maloney


patch.tar.gz
Description: GNU Zip compressed data

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

Re: [PATCH] XSLT/param@expression used as string instead of as expression as documented - Bug 21525

2013-08-23 Thread František Kučera

Hi,
can anybody please review this patch?
Franta

Dne 8.7.2013 01:59, František Kučera napsal(a):
> Hi,
> I have submitted a patch to Bug 21525. The patch adds possibility to
> specify data type or use XPath expression in XSLT task's parameters. It
> is working for me, but I know it still needs some documentation update
> and probably some tests to be written. Could you please navigate me, how
> to finish it and push this improvement into the next Ant version?
> Best Regards,
> Franta

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

[PATCH] XSLT/param@expression used as string instead of as expression as documented

2013-07-07 Thread František Kučera

Hi,
I have submitted a patch to Bug 21525. The patch adds possibility to
specify data type or use XPath expression in XSLT task's parameters. It
is working for me, but I know it still needs some documentation update
and probably some tests to be written. Could you please navigate me, how
to finish it and push this improvement into the next Ant version?
Best Regards,
Franta

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

[PATCH] Add missing exec features to SSHExec: error, errorproperty, resultproperty

2013-06-17 Thread Gilbert Rebhan

Just uploaded a patch for 
https://issues.apache.org/bugzilla/show_bug.cgi?id=48478,
which provides the following enhancements :
+ errorProperty
+ errorFile
+ appenderr
+ suppressSystemErr
+ resultProperty

Regards, Gilbert Rebhan

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

Re: [PATCH] SSH agent support for Ivy's SSH and SFTP transports

2013-05-17 Thread Charles Duffy


On 05/14/2013 10:00 AM, Charles Duffy wrote:
The SSH library used by ant, jsch, has a series of optional additional 
components available adding support for communicating with an external 
keystore. I've been using these successfully (with a number of users) 
over the course of the last few weeks, and would like to submit the 
patch I'm using for this support upstream.


Is there a reasonable chance of getting this, or something like it, 
merged? SSH agent support is critical for single-sign-on 
authentication to resources accessed via SSH or SFTP.


Howdy --

My employer has executed a CCLA, I've executed an individual CLA, and 
the patch remains available at 
https://issues.apache.org/jira/browse/IVY-1421. Moreover, jSCH's 
maintainership has expressed interest in seeing this functionality more 
widely available (see 
https://github.com/ymnk/jsch-agent-proxy/issues/8#issuecomment-17918786).


Is there anything else I can or should do on my end?


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

AW: [PATCH] SSH agent support for Ivy's SSH and SFTP transports

2013-05-15 Thread jhm

All attachements are dropped in the mailing lists.

Jan

> -Ursprüngliche Nachricht-
> Von: Charles Duffy [mailto:char...@dyfis.net]
> Gesendet: Mittwoch, 15. Mai 2013 14:13
> An: dev@ant.apache.org
> Betreff: Re: [PATCH] SSH agent support for Ivy's SSH and SFTP
> transports
> 
> The patch has been added to the JIRA ticket, and is available at
> https://issues.apache.org/jira/secure/attachment/12583315/ivy-jsch-
> agentproxy-support.diff
> 
> (My sent mail archive shows it attached to the original list post as
> well; I'm a little unclear on how it got dropped).
> 
> Many thanks,
> 
> -- Charles Duffy
>char...@dyfis.net
>du...@indeed.com
> 
> 
> On Tue, May 14, 2013 at 10:00 AM, Charles Duffy 
> wrote:
> 
> > Howdy, all --
> >
> > The SSH library used by ant, jsch, has a series of optional
> additional
> > components available adding support for communicating with an
> external
> > keystore. I've been using these successfully (with a number of users)
> > over the course of the last few weeks, and would like to submit the
> > patch I'm using for this support upstream.
> >
> > Is there a reasonable chance of getting this, or something like it,
> > merged? SSH agent support is critical for single-sign-on
> > authentication to resources accessed via SSH or SFTP.
> >
> > I'm aware that the lack of test cases is unusual, but I'm unclear on
> > how one would go about testing the functionality in question (given
> > its nature
> > -- integrating with external services).
> >
> > I've created a ticket to track this --
> > https://issues.apache.org/jira/browse/IVY-1421 -- but don't see an
> > option to upload a patch there. Feedback would be gratefully
> appreciated.
> >
> > Many thanks,
> >
> > -- Charles Duffy
> >char...@dyfis.net
> >du...@indeed.com
> >


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

Re: [PATCH] SSH agent support for Ivy's SSH and SFTP transports

2013-05-15 Thread Charles Duffy

The patch has been added to the JIRA ticket, and is available at
https://issues.apache.org/jira/secure/attachment/12583315/ivy-jsch-agentproxy-support.diff

(My sent mail archive shows it attached to the original list post as well;
I'm a little unclear on how it got dropped).

Many thanks,

-- Charles Duffy
   char...@dyfis.net
   du...@indeed.com


On Tue, May 14, 2013 at 10:00 AM, Charles Duffy  wrote:

> Howdy, all --
>
> The SSH library used by ant, jsch, has a series of optional additional
> components available adding support for communicating with an external
> keystore. I've been using these successfully (with a number of users) over
> the course of the last few weeks, and would like to submit the patch I'm
> using for this support upstream.
>
> Is there a reasonable chance of getting this, or something like it,
> merged? SSH agent support is critical for single-sign-on authentication to
> resources accessed via SSH or SFTP.
>
> I'm aware that the lack of test cases is unusual, but I'm unclear on how
> one would go about testing the functionality in question (given its nature
> -- integrating with external services).
>
> I've created a ticket to track this --
> https://issues.apache.org/jira/browse/IVY-1421 -- but don't see an option
> to upload a patch there. Feedback would be gratefully appreciated.
>
> Many thanks,
>
> -- Charles Duffy
>char...@dyfis.net
>du...@indeed.com
>

AW: [PATCH] SSH agent support for Ivy's SSH and SFTP transports

2013-05-14 Thread jhm

Chances are increasing when opening an issue and providing a patch ;-)

You could attach your patch in Jira when:

- clicking on "More Actions" (drop down menu opens)

- clicking on "Attach Files" (dialog opens)

- ...

 

 

Jan

 

 

Von: Charles Duffy [mailto:char...@dyfis.net] 
Gesendet: Dienstag, 14. Mai 2013 17:00
An: dev@ant.apache.org
Betreff: [PATCH] SSH agent support for Ivy's SSH and SFTP transports

 

Howdy, all --

 

The SSH library used by ant, jsch, has a series of optional additional 
components available adding support for communicating with an external 
keystore. I've been using these successfully (with a number of users) over the 
course of the last few weeks, and would like to submit the patch I'm using for 
this support upstream.

 

Is there a reasonable chance of getting this, or something like it, merged? SSH 
agent support is critical for single-sign-on authentication to resources 
accessed via SSH or SFTP.

 

I'm aware that the lack of test cases is unusual, but I'm unclear on how one 
would go about testing the functionality in question (given its nature -- 
integrating with external services).

 

I've created a ticket to track this -- 
https://issues.apache.org/jira/browse/IVY-1421 -- but don't see an option to 
upload a patch there. Feedback would be gratefully appreciated.

 

Many thanks,

 

-- Charles Duffy

   char...@dyfis.net

   du...@indeed.com

[PATCH] SSH agent support for Ivy's SSH and SFTP transports

2013-05-14 Thread Charles Duffy

Howdy, all --

The SSH library used by ant, jsch, has a series of optional additional
components available adding support for communicating with an external
keystore. I've been using these successfully (with a number of users) over
the course of the last few weeks, and would like to submit the patch I'm
using for this support upstream.

Is there a reasonable chance of getting this, or something like it, merged?
SSH agent support is critical for single-sign-on authentication to
resources accessed via SSH or SFTP.

I'm aware that the lack of test cases is unusual, but I'm unclear on how
one would go about testing the functionality in question (given its nature
-- integrating with external services).

I've created a ticket to track this --
https://issues.apache.org/jira/browse/IVY-1421 -- but don't see an option
to upload a patch there. Feedback would be gratefully appreciated.

Many thanks,

-- Charles Duffy
   char...@dyfis.net
   du...@indeed.com

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

Re: Get task doesn't always respect skipExisting - Patch included

2013-04-18 Thread Stefan Bodewig

On 2013-04-17, Zach Garner wrote:

> Hi everyone, I am trying to use the  task with skipExisting=true.
> Because of my particular situation, I usually have the target file
> downloaded but sometimes it is owned by root, and so it is not writeable.

> The checkAttributes() method of Get.java fails the build if the destination
> file is not writeable, even when skipExisting is true.

Yep, sounds like a bug.

> I've attached the small patch to fix it. Let me know if I can help get this
> committed, if there's interest

Unfortunately our mailing list setup has eaten up your patch.  Could you
please open a bugzilla issue and attach the patch there?

Thanks

Stefan

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

Get task doesn't always respect skipExisting - Patch included

2013-04-17 Thread Zach Garner

Hi everyone, I am trying to use the  task with skipExisting=true.
Because of my particular situation, I usually have the target file
downloaded but sometimes it is owned by root, and so it is not writeable.

The checkAttributes() method of Get.java fails the build if the destination
file is not writeable, even when skipExisting is true.

I've attached the small patch to fix it. Let me know if I can help get this
committed, if there's interest

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

Re: [patch] Bug with spaces in file names in ApacheURLLister.java

2013-03-30 Thread Andreas Heindl

sorry, better patch might be a replacement of href instead of 
introducing a temporary variable href_dec:


href = Uri.decode(href);
String strippedHref = href.endsWith("/") ? href.substring(0, 
href.length() - 1) : href;

...


On 3/30/2013 9:48 AM, Andreas Heindl wrote:

Hello,

there is a bug in
apache-ivy-2.3.0-src.zip/apache-ivy-2.3.0/src/java/org/apache/ivy/util/url/ApacheURLLister.java


When parsing an file containing spaces, its href representation is
encoded, whilst the text is unencoded. The check in line 177:

String strippedHref = href_dec.endsWith("/") ? href_dec.substring(0,
href_dec.length() - 1) : href_dec;
String strippedText = text.endsWith("/") ? text.substring(0,
text.length() - 1) : text;
if (!strippedHref.equalsIgnoreCase(strippedText)) {
 continue;

therefore is not successful.

Example:
href=bla%20und%20bub.dat
text=bla und bub.dat


Suggested patch is an Uri.decode(href):


String href_dec = Uri.decode(href);
String strippedHref = href_dec.endsWith("/") ? href_dec.substring(0,
href_dec.length() - 1) : href_dec;
String strippedText = text.endsWith("/") ? text.substring(0,
text.length() - 1) : text;
if (!strippedHref.equalsIgnoreCase(strippedText)) {
 continue;




Greetings,
  Andreas


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

[patch] Bug with spaces in file names in ApacheURLLister.java

2013-03-30 Thread Andreas Heindl


Hello,

there is a bug in
apache-ivy-2.3.0-src.zip/apache-ivy-2.3.0/src/java/org/apache/ivy/util/url/ApacheURLLister.java

When parsing an file containing spaces, its href representation is 
encoded, whilst the text is unencoded. The check in line 177:


String strippedHref = href_dec.endsWith("/") ? href_dec.substring(0, 
href_dec.length() - 1) : href_dec;
String strippedText = text.endsWith("/") ? text.substring(0, 
text.length() - 1) : text;

if (!strippedHref.equalsIgnoreCase(strippedText)) {
continue;

therefore is not successful.

Example:
href=bla%20und%20bub.dat
text=bla und bub.dat


Suggested patch is an Uri.decode(href):


String href_dec = Uri.decode(href);
String strippedHref = href_dec.endsWith("/") ? href_dec.substring(0, 
href_dec.length() - 1) : href_dec;
String strippedText = text.endsWith("/") ? text.substring(0, 
text.length() - 1) : text;

if (!strippedHref.equalsIgnoreCase(strippedText)) {
continue;




Greetings,
 Andreas

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

Re: [PATCH] Bug 54026 - Zip task on that excludes certain files by way of the mapper results in a NullPointerException

2013-01-06 Thread Antoine Levy Lambert

Patch submitted, thanks.

Regards,

Antoine
On Oct 19, 2012, at 7:55 AM, Daniel Trebbien wrote:

> I just wanted to point out this new bug report and the attached patch.
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=54026
> 
> Daniel Trebbien
> 
> -
> 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: [PATCH] Bug 54026 - Zip task on that excludes certain files by way of the mapper results in a NullPointerException

2012-12-08 Thread Daniel Trebbien

Hi all,

Would an Ant maintainer please review my patch for Bug 54026?


On Fri, Oct 19, 2012 at 7:55 AM, Daniel Trebbien  wrote:
> I just wanted to point out this new bug report and the attached patch.
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=54026
>
> Daniel Trebbien

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

[PATCH] Bug 54026 - Zip task on that excludes certain files by way of the mapper results in a NullPointerException

2012-10-19 Thread Daniel Trebbien

I just wanted to point out this new bug report and the attached patch.

https://issues.apache.org/bugzilla/show_bug.cgi?id=54026

Daniel Trebbien

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

Re: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task

2012-09-17 Thread Ralf


Matt,

good to hear.

With regex you could easily match the additional features I added to the 
local task.


I can offer my help.

Ralf


On 16/09/12 17:24, Matt Benson wrote:

Hi,
FWIW, I approve generally of this feature and was soon going to start
working on something similar, only I had intended to support regex
matching.  I'm not quite sure when I will be able to get back to work
on Ant, but I need the feature so rest assured it will get in there at
some point.

Matt




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

Re: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task

2012-09-17 Thread Matt Benson

Hi DD,
  I had looked at PropertySet in this context, but ISTR there may have
been problems due to its desire to work with properties that already
exist rather than properties that *might* be set.

Matt

On Mon, Sep 17, 2012 at 3:36 AM, Dominique Devienne  wrote:
> On Sun, Sep 16, 2012 at 5:24 PM, Matt Benson  wrote:
>> [...] only I had intended to support regex matching.
>
> Can't 's selection logic be reused? --DD
>
> PS: Didn't look at the patch, so maybe it is.

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

Re: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task

2012-09-17 Thread Dominique Devienne

On Sun, Sep 16, 2012 at 5:24 PM, Matt Benson  wrote:
> [...] only I had intended to support regex matching.

Can't 's selection logic be reused? --DD

PS: Didn't look at the patch, so maybe it is.

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

Re: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task

2012-09-16 Thread Matt Benson

Hi,
FWIW, I approve generally of this feature and was soon going to start
working on something similar, only I had intended to support regex
matching.  I'm not quite sure when I will be able to get back to work
on Ant, but I need the feature so rest assured it will get in there at
some point.

Matt

On Sun, Sep 16, 2012 at 7:04 AM, Vimil Saju  wrote:
> I like this feature. I have been using the local task multiple times in my 
> targets to name properties, this enhancement will make my build scripts much 
> more cleaner.
>
>
> 
>  From: Ralf 
> To: dev@ant.apache.org
> Sent: Sunday, September 16, 2012 1:59 AM
> Subject: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all 
> local, New: global task
>
> Hello,
>
> about a month ago I added an enhancement request with patch to ant bugzilla.
> As there were no feedback on bugzilla, I thought I start a little promotion.
>
> The patch adds some functionality to the local task:
>
>  
>  
>
>  
>  
>
>  
>  
>
>
> Additionally the new task "global" was added to be able to export a
> property from a scope if all other properties are defined local.
>
>  
>  
>  
>  
>
>
> Most important for me (and hopfully others) are the addition to the
> local task (local-by-prefiy and all-local). The global tasks seems
> like a logical implication to me.
>
> Please have a look at the description for Bugzilla 53723 and the patch.
> It would be great if this enhancement would be included into ant.
>
> Regards,
> Ralf
>
> PS: https://issues.apache.org/bugzilla/show_bug.cgi?id=53723
>
> -
> 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: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task

2012-09-16 Thread Vimil Saju

I like this feature. I have been using the local task multiple times in my 
targets to name properties, this enhancement will make my build scripts much 
more cleaner.

 From: Ralf 
To: dev@ant.apache.org 
Sent: Sunday, September 16, 2012 1:59 AM
Subject: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all 
local, New: global task

Hello,

about a month ago I added an enhancement request with patch to ant bugzilla.
As there were no feedback on bugzilla, I thought I start a little promotion.

The patch adds some functionality to the local task:

Additionally the new task "global" was added to be able to export a
property from a scope if all other properties are defined local.

Most important for me (and hopfully others) are the addition to the
local task (local-by-prefiy and all-local). The global tasks seems
like a logical implication to me.

Please have a look at the description for Bugzilla 53723 and the patch.
It would be great if this enhancement would be included into ant.

Regards,
        Ralf

PS: https://issues.apache.org/bugzilla/show_bug.cgi?id=53723

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

Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task

2012-09-16 Thread Ralf


Hello,

about a month ago I added an enhancement request with patch to ant bugzilla.
As there were no feedback on bugzilla, I thought I start a little promotion.

The patch adds some functionality to the local task:

 
 

 
 

 
 


Additionally the new task "global" was added to be able to export a
property from a scope if all other properties are defined local.

 
 
 
 


Most important for me (and hopfully others) are the addition to the
local task (local-by-prefiy and all-local). The global tasks seems
like a logical implication to me.

Please have a look at the description for Bugzilla 53723 and the patch.
It would be great if this enhancement would be included into ant.

Regards,
Ralf

PS: https://issues.apache.org/bugzilla/show_bug.cgi?id=53723

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

Cache cleanup for non-primary Maven SNAPSHOT artifacts [IVY-1221; patch]

2012-06-26 Thread William Price

Any reviews/comments for my recent patch attached to IVY-1221?
First time contributing to this project, so please have some patience if I'm 
unaware of procedures.

-- 
William Price




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

Patch for IVY-1273; Updates on IVY-482 and IVY-1100

2012-03-23 Thread Joseph Boyd

Hi all,

I've recently attached a patch for IVY-1273.

Also, I've looked into and commented on IVY-482 and IVY-1100, both of
which can likely be closed.

I'd appreciate a dev looking at these items as soon as is convenient.


Cheers!

...Joseph Boyd

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

Re: [PATCH] Add retryDelay to the retry task

2011-10-28 Thread Stefan Bodewig

On 2011-10-24, AVee wrote:

> On Sat, 22 Oct 2011 07:31:24 +0200, Stefan Bodewig
>  wrote:

>> I know that I have used retry logic in totally different circumstances
>> in code where I increased the delay with each retry attempt.  I.e. I
>> waited a very short time before the first retry and doubled it each
>> time.  Would something like this make sense here as well?

> The thought crossed my mind, but I didn't do this because (for me at
> least) the number of retries is always going to be very limited.
> When the number of retries is limited the total time you're going to
> be retrying is going to be relatively low, I guess the increment won't
> make a  big difference in that case. Personally I wouldn't want my
> build scripts  to spend 10 minutes retrying something, but if you
> think there's a use for  it I could build it. Should be easy enough.

In my case it was a very short wait time for specific circumstances -
that are pretty unlikely to occur as part of a build process.  Let's
defer that feature until anybody really asks for it.

>> It would be good if you could open an enhancement request in bugzilla
>> and attach your patch.  It is less prone to get lost there compared to
>> the developers' INBOX.

> There you go: https://issues.apache.org/bugzilla/show_bug.cgi?id=52076

Thanks

Stefan

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

Re: [PATCH] Add retryDelay to the retry task

2011-10-24 Thread AVee

On Sat, 22 Oct 2011 07:31:24 +0200, Stefan Bodewig   
wrote:



Hi Arjan,


...


I know that I have used retry logic in totally different circumstances
in code where I increased the delay with each retry attempt.  I.e. I
waited a very short time before the first retry and doubled it each
time.  Would something like this make sense here as well?


The thought crossed my mind, but I didn't do this because (for me at  
least) the number of retries is always going to be very limited.
When the number of retries is limited the total time you're going to be  
retrying is going to be relatively low, I guess the increment won't make a  
big difference in that case. Personally I wouldn't want my build scripts  
to spend 10 minutes retrying something, but if you think there's a use for  
it I could build it. Should be easy enough.



It would be good if you could open an enhancement request in bugzilla
and attach your patch.  It is less prone to get lost there compared to
the developers' INBOX.


There you go: https://issues.apache.org/bugzilla/show_bug.cgi?id=52076

Regards,
Arjan Veenstra

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

Re: [PATCH] Add retryDelay to the retry task

2011-10-21 Thread Stefan Bodewig

Hi Arjan,

On 2011-10-17, AVee wrote:

> Hi,

> I wanted the retry task to wait a bit before retrying. Since I didn't
> find a clean way to do this I patched the retry task to support a
> retryDelay' attribute.

This sounds like a good idea to me - I haven't found time to review your
patch so far, though.  Sorry.

I know that I have used retry logic in totally different circumstances
in code where I increased the delay with each retry attempt.  I.e. I
waited a very short time before the first retry and doubled it each
time.  Would something like this make sense here as well?

> I'd like to see this added to ANT as running custom versions of basic
> tools is just tedious.

Sure.

It would be good if you could open an enhancement request in bugzilla
and attach your patch.  It is less prone to get lost there compared to
the developers' INBOX.

Thanks

Stefan

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

[PATCH] Add retryDelay to the retry task

2011-10-17 Thread AVee


Hi,

I wanted the retry task to wait a bit before retrying. Since I didn't 
find a clean way to do this I patched the retry task to support a 
'retryDelay' attribute. This simply sets the time to sleep between 
different retry attempts. We currently use this on our build server to 
retry SVN updates which might fail because multiple jobs are updating 
the same sandbox concurrently. So far it's been working fine.


The attached patch has only been compiled/tested against java 1.6, but 
I guess it should be fine in older versions as well.


The output, when a retryDelay is set looks like this:
updateLib:
 [echo] Start library update...
  [svn] svn: Working copy 'C:\BuildSystem\Libraries' locked; try 
performing 'cleanup'
  [svn] svn: Working copy 'C:\BuildSystem\Libraries' locked; try 
performing 'cleanup'

  [svn]  failed.
[retry] Attempt [0]: error occurred; retrying after 1000 ms...
  [svn] svn: Working copy 'C:\BuildSystem\Libraries' locked; try 
performing 'cleanup'
  [svn] svn: Working copy 'C:\BuildSystem\Libraries' locked; try 
performing 'cleanup'

  [svn]  failed.
[retry] Attempt [1]: error occurred; retrying after 1000 ms...
 [echo] Update done...

I'd like to see this added to ANT as running custom versions of basic 
tools is just tedious. So if anything in this patch would block 
inclusion please let me know and I'll see if I can improve it.


Regards,
Arjan VeenstraIndex: main/org/apache/tools/ant/taskdefs/Retry.java
===
--- main/org/apache/tools/ant/taskdefs/Retry.java   (revision 1183274)
+++ main/org/apache/tools/ant/taskdefs/Retry.java   (working copy)
@@ -40,6 +40,11 @@
 private int retryCount = 1;
 
 /**
+ * The time to wait between reties in milliseconds, default to 0.
+ */
+private int retryDelay = 0;
+
+/**
  * set the task
  * @param t the task to retry.
  */
@@ -61,6 +66,17 @@
 }
 
 /**
+ * set the delay between retries (in miliseconds)
+ * @param n the time between retries.
+ */
+public void setRetryDelay(int retryDelay) {
+if(retryDelay < 0)
+this.retryDelay = 0;
+else
+this.retryDelay = retryDelay;
+   }
+
+/**
  * perform the work
  * @throws BuildException if there is an error.
  */
@@ -81,7 +97,17 @@
 exceptionMessage.append(errorMessages);
 throw new BuildException(exceptionMessage.toString(), 
getLocation());
 }
-log("Attempt [" + i + "]: error occurred; retrying...", e, 
Project.MSG_INFO);
+String msg;
+if(retryDelay > 0)
+msg = "Attempt [" + i + "]: error occurred; retrying after 
" + retryDelay + " ms...";
+else
+msg = "Attempt [" + i + "]: error occurred; retrying...";
+log(msg, e, Project.MSG_INFO);
+try {
+Thread.sleep(retryDelay);
+} catch (InterruptedException ie) {
+// Ignore Exception
+}
 errorMessages.append(StringUtils.LINE_SEP);
 }
 }

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

Re: Review-Request Patch for Bug #1031

2011-08-23 Thread Nicolas Lalevée

I replied in the jira:
https://issues.apache.org/jira/browse/IVY-1031

Nicolas

Le 14 août 2011 à 22:48, Matthias Bläsing a écrit :

> Hello,
> 
> I'm not sure what is the correct way to get a patch applied to the ivy
> core, but I was faced with the same situation as described in Bug #1031
> and created a fix for it (see the last attached patch).
> 
> So could that be integrated into the core? Or what would have to be
> changed?
> 
> Greetings
> 
> Matthias
> 
> PS: Please keep me in CC, as I'm not 
> 
> 
> -
> 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

Review-Request Patch for Bug #1031

2011-08-14 Thread Matthias Bläsing

Hello,

I'm not sure what is the correct way to get a patch applied to the ivy
core, but I was faced with the same situation as described in Bug #1031
and created a fix for it (see the last attached patch).

So could that be integrated into the core? Or what would have to be
changed?

Greetings

Matthias

PS: Please keep me in CC, as I'm not 


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

Re: [PATCH] Ant faq.xml

2011-03-30 Thread Stefan Bodewig

On 2011-03-30, Gilbert Rebhan wrote:

>  Original Message  
> Subject: Re: [PATCH] Ant faq.xml
> From: Stefan Bodewig 
> To: dev@ant.apache.org
> Date: Wed Mar 30 2011 17:54:47 GMT+0200 (CET)

>> On 2011-03-24, Gilbert Rebhan wrote:

>>> Patchfile, see attached file : patchfile.txt

>> For some reasons my MUA doesn't see the contents of attachments when
>> sent to Apache lists.

> So is there a better way to send patches ?
> i just followed the instructions under =
> http://ant.apache.org/faq.html#adding-faqs

If you could see the attachment after the mail made it to the list then
the problem is on my side.  I think you did just fine.

Stefan

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

Re: [PATCH] Ant faq.xml

2011-03-30 Thread Gilbert Rebhan

 Original Message  
Subject: Re: [PATCH] Ant faq.xml
From: Stefan Bodewig 
To: dev@ant.apache.org
Date: Wed Mar 30 2011 17:54:47 GMT+0200 (CET)

> On 2011-03-24, Gilbert Rebhan wrote:
> 
>> Patchfile, see attached file : patchfile.txt

> For some reasons my MUA doesn't see the contents of attachments when
> sent to Apache lists.

So is there a better way to send patches ?
i just followed the instructions under =
http://ant.apache.org/faq.html#adding-faqs

> One thing that makes me suspicious is that my reconstructed
> patchfile.txt didn't close the CDATA section you opened for the example.

To my shame i must confess i forgot the closing
]]>
in my patchfile :-(
My editor didn't mark it as error..
Sorry for that.

>I've tried to reproduce the patchfile from the
> raw email's content, you may want to double check whether what is
> visible on the Ant site now really is what you intended to see.

Thanks a lot Stefan, it's exactly what i wanted to put into the FAQ !


Regards, Gilbert


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

Re: [PATCH] Ant faq.xml

2011-03-30 Thread Stefan Bodewig

On 2011-03-24, Gilbert Rebhan wrote:

> Patchfile, see attached file : patchfile.txt

For some reasons my MUA doesn't see the contents of attachments when
sent to Apache lists.  I've tried to reproduce the patchfile from the
raw email's content, you may want to double check whether what is
visible on the Ant site now really is what you intended to see.

One thing that makes me suspicious is that my reconstructed
patchfile.txt didn't close the CDATA section you opened for the example.

Stefan

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

[PATCH] Ant faq.xml

2011-03-24 Thread Gilbert Rebhan


Second try, fixed a typo..

Patch contains a solution for nested Properties / Properties
dereferencing with Ant Plugin Flaka (http://code.google.com/p/flaka/)

How do i..
How can I do something like  (double expanding the property)?

Patchfile, see attached file : patchfile.txt


Regards, Gilbert
--- faq.xml.orig2011-03-23 22:45:07.621396271 +0100
+++ faq.xml 2011-03-23 22:51:23.511342304 +0100
@@ -768,6 +768,22 @@
 
 
  ${${var}} = foo.value ]]>
+ With http://code.google.com/p/flaka/";>Flaka (external 
Ant Plugin) you could
+ do the dereferencing with #{${anotherprop}} - not just
+ in flaka tasks, but all tasks after installing flaka's property 
handler'.
+ 
+ With http://code.google.com/p/flaka/";>Flaka (external 
Ant Plugin) you could
+ do the dereferencing with #{${anotherprop}} - not just
+ in flaka tasks, but all tasks after installing flaka's property 
handler.
+

[PATCH] Ant FAQ.xml

2011-03-23 Thread Gilbert Rebhan

Patch contains a solution for nested Properties / Properties
dereferencing with Ant Plugin Flaka (http://code.google.com/p/flaka/)

How do i..
How can I do something like  (double expanding the property)?

Patchfile, see attached file : patchfile.txt


Regards, Gilbert
--- faq.xml.orig2011-03-23 22:45:07.621396271 +0100
+++ faq.xml 2011-03-23 22:51:23.511342304 +0100
@@ -768,6 +768,22 @@
 
 
  ${${var}} = foo.value ]]>
+ With http://code.google.com/p/flaka/";>Flaka (external 
Ant Plugin) you could
+ do the dereferencing with #{${anotherprop}} - not just
+ in flaka tasks, but all tasks after installing flaka's property 
handler'.
+

Re: Preserving file permissions in copy and zip tasks [patch]

2011-01-23 Thread Jeffrey E Care

Haven't reviewed the code here but if it's not there already I would 
suggest having some sort of abstraction layer for this function instead of 
tying Ant directly to this jna-posix library. Last time I checked Java 7 
is *supposed* to provide access to "bulk file attributes" (such as 
permissions) under JSR 203; there may be other libraries that can 
implement these functions too.

(http://openjdk.java.net/projects/nio/)


 

Jeffrey E. (Jeff) Care 
ca...@us.ibm.com 
IBM WebSphere Application Server 
WAS Release Engineering 





Robin Fernandes  wrote on 01/23/2011 08:02:23 AM:

> [image removed] 
> 
> Preserving file permissions in copy and zip tasks [patch]
> 
> Robin Fernandes 
> 
> to:
> 
> dev
> 
> 01/23/2011 08:11 AM
> 
> Please respond to "Ant Developers List"
> 
> Hi all,
> 
> A fairly common (and documented) gripe with filesystem tasks is that
> they tend to ignore or lose Unix file permissions. I've had a look at
> workarounds for this, and have found that the jna-posix library
> (originally developed for JRuby) provides useful APIs for interacting
> with file permissions as best as possible from current levels of Java.
> The library attempts to invoke standard native functions over JNA if
> possible, and falls back Java APIs (which can only approximate
> permissions) if no suitable linkage is available.
> 
> Here's a patch which modifies the Copy and Zip tasks to preserve
> permissions, using jna-posix : https://gist.github.com/792062.
> Is this approach worth considering to make Ant's core tasks play
> better with file permissions?
> 
> Cheers,
> Robin
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>

Preserving file permissions in copy and zip tasks [patch]

2011-01-23 Thread Robin Fernandes

Hi all,

A fairly common (and documented) gripe with filesystem tasks is that
they tend to ignore or lose Unix file permissions. I've had a look at
workarounds for this, and have found that the jna-posix library
(originally developed for JRuby) provides useful APIs for interacting
with file permissions as best as possible from current levels of Java.
The library attempts to invoke standard native functions over JNA if
possible, and falls back Java APIs (which can only approximate
permissions) if no suitable linkage is available.

Here's a patch which modifies the Copy and Zip tasks to preserve
permissions, using jna-posix : https://gist.github.com/792062.
Is this approach worth considering to make Ant's core tasks play
better with file permissions?

Cheers,
Robin

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

Re: [PATCH] ant-core/docs/manual/Tasks/taskdef.html

2010-11-29 Thread Stefan Bodewig

On 2010-11-29, Stefan Bodewig wrote:

> On 2010-11-23, Kevin Connor Arpe wrote:

>> Regarding the namespace issue, no one I talked to at my office knew
>> anything about classloaders.  I wasn't sure how to describe it, but I
>> don't want users to need to be a Java expert to understand the docs...

> The problem is you need to understand a bit of Java classloading in
> order to understand what is going on.  And as usual people who know a
> difficult issue - and had to learn them a long time ago - are often not
> the best people to describe them to newbies.  I'll give it a shot when I
> get around to it.

Kevin, could you do me a favor and review the changes I've made in
, please -
they should become visible online within a few hours.  It could be total
gibberish.

Would what I've written helped you back when you tried to write your
tasks?  Do the people at your office understand it?

Thanks

Stefan

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

Re: [PATCH] ant-core/docs/manual/Tasks/taskdef.html

2010-11-29 Thread Stefan Bodewig

On 2010-11-23, Kevin Connor Arpe wrote:

> Seems like my patch should be merged with the typedef page.

I thought so,

> Regarding the namespace issue, no one I talked to at my office knew
> anything about classloaders.  I wasn't sure how to describe it, but I
> don't want users to need to be a Java expert to understand the docs...

The problem is you need to understand a bit of Java classloading in
order to understand what is going on.  And as usual people who know a
difficult issue - and had to learn them a long time ago - are often not
the best people to describe them to newbies.  I'll give it a shot when I
get around to it.

> I will leave this patch to you to integrate -- 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: [PATCH] ant-core/docs/manual/Tasks/taskdef.html

2010-11-23 Thread Kevin Connor Arpe

Seems like my patch should be merged with the typedef page.

I'm not an expert in Ant nor Java, hence some terminology is a bit imperfect.

Regarding the namespace issue, no one I talked to at my office knew
anything about classloaders.
I wasn't sure how to describe it, but I don't want users to need to be
a Java expert to understand the docs...

I will leave this patch to you to integrate -- or not.

On Mon, Nov 22, 2010 at 8:46 PM, Stefan Bodewig  wrote:
> On 2010-11-15, Kevin Connor Arpe wrote:
>
>> As promised, I would commit back a patch.  In this case, docs are the
>> right solution.
>
> Thank you Kevin.
>
>> I have upgraded the TaskDef Task docs.
>
> Much of what you've added is already present on the typedef page - maybe
> we should make it clearer that taskdef actually is a typedef rather than
> duplicate the information with different words?
>
> The changes you propose would recommend using multiple taskdef tasks to
> declare multiple related tasks - in fact this is not the way we'd
> encourage people to do that, they'd better use an antlib or taskdef's
> resource attribute instead.
>
> Also you talk about "namespace in the Java VM" which is a bit confusing
> since there is no such thing.  What you mean is they share the same
> classloader.
>
> 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: [PATCH] ant-core/docs/manual/Tasks/taskdef.html

2010-11-22 Thread Stefan Bodewig

On 2010-11-15, Kevin Connor Arpe wrote:

> As promised, I would commit back a patch.  In this case, docs are the
> right solution.

Thank you Kevin.

> I have upgraded the TaskDef Task docs.

Much of what you've added is already present on the typedef page - maybe
we should make it clearer that taskdef actually is a typedef rather than
duplicate the information with different words?

The changes you propose would recommend using multiple taskdef tasks to
declare multiple related tasks - in fact this is not the way we'd
encourage people to do that, they'd better use an antlib or taskdef's
resource attribute instead.

Also you talk about "namespace in the Java VM" which is a bit confusing
since there is no such thing.  What you mean is they share the same
classloader.

Stefan

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

[PATCH] ant-core/docs/manual/Tasks/taskdef.html

2010-11-15 Thread Kevin Connor Arpe

Anters,

Thank you very much for your help.  As promised, I would commit back a
patch.  In this case, docs are the right solution.

I have upgraded the TaskDef Task docs.

Attached is my patch from ant-core tar/gzip'd.

Thanks,
Kevin Connor ARPE
Hongkong

On Tue, Oct 26, 2010 at 3:31 PM, Stefan Bodewig  wrote:
> On 2010-10-25, Dominique Devienne wrote:
>
>> I don't remember the details, but it's likely your two independent
>>  that force using separate class loaders. Using either a
>> single taskdef loading a .properties file, or using a classpathref
>> might use the same classloader instead.
>
> The loaderref attribute is the ingredient needed to have different
>  tasks share the same classloader (provided they use the same
> classpath as well, that is).
>
>> Also putting your tasks into an AntLib in its own Jar with a proper
>> antlib.xml manifest would also likely use a single class loader.
>
> Using just one  either via an Antlib descriptor or a property
> file and the resource attribute to define both tasks would work.
>
>> But as Jeffrey wrote, you could have your tasks read/write properties
>> to communicate, or pass them a reference to a datatype instance as
>> well.
>
> +1
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


ant-core.patch.tar.gz
Description: GNU Zip compressed data

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

Re: [PATCH] ant-core/docs/manual/tutorial-writing-tasks.html

2010-10-22 Thread Stefan Bodewig

Thanks Kevin,

I've committed the patch as it was but not updated the site, yet.

In your section about getting the project you may want to mention that
getProject is only available to task that (maybe via Task) inherit from
ProjectComponent.  Any other task can provide a void setProject(Project)
method and receive the instance as well.

The project instance will be available as soon as the setProject methid
has been invoked, this happens i tsep three of the life-cycle descibed
in <http://ant.apache.org/manual/develop.html#writingowntask>.

Stefan

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

Re: [PATCH] ant-core/docs/manual/tutorial-writing-tasks.html

2010-10-22 Thread Stefan Bodewig

Hi Kevin,

On 2010-10-20, Kevin Connor Arpe wrote:

> I am using instructions from here:
> http://www.apache.org/dev/contributors.html#patches
> This developer list has no specifics about sending patches.

<http://ant.apache.org/bugs.html#Fixing%20the%20Bug> - well hidden, I
know 8-)

> Please let me know if I need to sign a legal release, etc.  I can do it.

I don't expect it to be necessary unless you patch would be really big
(I haven't looked into it, yet).

> Attached is a patch to update docs for writing custom Ant tasks.  I am
> doing it a bit at work these days and I want to contribute back to
> this incredible project.

Your help is much appreciated, I'll look into the patch and either
commit it as is or come back to you with comments.

Thanks

Stefan

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

[PATCH] ant-core/docs/manual/tutorial-writing-tasks.html

2010-10-20 Thread Kevin Connor Arpe

Hi,

I am using instructions from here:
http://www.apache.org/dev/contributors.html#patches
This developer list has no specifics about sending patches.

Please let me know if I need to sign a legal release, etc.  I can do it.

Attached is a patch to update docs for writing custom Ant tasks.  I am
doing it a bit at work these days and I want to contribute back to
this incredible project.  Thanks to the person who wrote the original
set of docs.  Thank you, thank you, thank you.  I could not have
written my custom tasks without it.

Attached is my patch from ant-core tar/gzip'd.

Thanks,
Kevin Connor ARPE
Hongkong


ant-core.patch.tar.gz
Description: GNU Zip compressed data

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

[PATCH]: Set userinfo on HTTP condition if supplied

2010-08-19 Thread Nicholas Pellow


Hi, (let me try again, without the tar.gz attachment)

Attached is a patch for Ant that will check for any userinfo in the  
URL supplied to the http condition.
If available, then this will be used as the Basic-Auth header when  
making the request.
This allows http requests to be made to services that are protected by  
basic-auth.

e.g. http://username:passw...@localhost:6060/foo/ready.json


I have tested this manually, however could not see a good reliable way  
to unit test this.
If no userinfo element is suppliued in the URL, then the connection  
behaves the same as before.


Details here: https://issues.apache.org/bugzilla/show_bug.cgi?id=49788

Cheers,
Nick


P.S. The instructions or patch.xml for creating a Patch against ANT  
should probably be updated to mention that .tar.gz patches will not be  
accepted.

Re: Small ivy patch for command line interface

2010-03-03 Thread Jeffrey E Care

I'm fairly certain that the listserv strips attachments.


 

Jeffrey E. (Jeff) Care 
ca...@us.ibm.com 
IBM WebSphere Application Server 
WAS Release Engineering 





Terence Lewis  wrote on 03/03/2010 04:14:46 PM:

> [image removed] 
> 
> Small ivy patch for command line interface
> 
> Terence Lewis 
> 
> to:
> 
> dev
> 
> 03/03/2010 05:07 PM
> 
> Please respond to "Ant Developers List"
> 
> Hello,
> 
> Firstly, please excuse me if this isn't the correct place to submit 
> a patch. I downloaded the source that comes with the 2.1.0 release -
> this patch is a very small change to enable specification of a 
> branch as a command-line option.
> 
> Please advise if the patch is suitable in it's current format or if 
> there's anything else I need to do to get it accepted. The website 
> says there is a better chance for acceptance if there is an 
> accompanying test, but I didn't see any similar tests to copy in the
> test sub-folder.
> 
> 
> Thanks
> 
> 
> Terence Lewis
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org

Re: Small ivy patch for command line interface

2010-03-03 Thread Maarten Coene

It might be related to my mail client, but I can't open your attachment.

The best way to submit a patch is to create a JIRA issue and attach your patch 
to that issue.
https://issues.apache.org/jira/browse/IVY

thanks,
Maarten



From: Terence Lewis 
To: dev@ant.apache.org
Sent: Wed, March 3, 2010 10:14:46 PM
Subject: Small ivy patch for command line interface

Hello,

Firstly, please excuse me if this isn't the correct place to submit a patch. I 
downloaded the source that comes with the 2.1.0 release - this patch is a very 
small change to enable specification of a branch as a command-line option.

Please advise if the patch is suitable in it's current format or if there's 
anything else I need to do to get it accepted. The website says there is a 
better chance for acceptance if there is an accompanying test, but I didn't see 
any similar tests to copy in the test sub-folder.


Thanks


Terence Lewis

-
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

Small ivy patch for command line interface

2010-03-03 Thread Terence Lewis

Hello,

Firstly, please excuse me if this isn't the correct place to submit a patch.
I downloaded the source that comes with the 2.1.0 release - this patch is a
very small change to enable specification of a branch as a command-line
option.

Please advise if the patch is suitable in it's current format or if there's
anything else I need to do to get it accepted. The website says there is a
better chance for acceptance if there is an accompanying test, but I didn't
see any similar tests to copy in the test sub-folder.


Thanks


Terence Lewis

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

Re: [PATCH] JUnitTestRunner.filterStack(String) does not flush BufferedWriter

2010-02-01 Thread Stefan Bodewig

On 2010-02-01, N C  wrote:

> --- On Mon, 2/1/10, Stefan Bodewig  wrote:

>> I'll revisit the remaining classes I have changed to ensure
>> they close the writers now if they didn't do so before.

> If you haven't, you might want to take a look at
> PlainJUnitResultFormatter.  It isn't clear to me that the
> BufferedWriter "wri" is properly flushed under exceptional conditions,
> but I don't know the code well enough.

This was one of several places where I changed the code in the error
case.  Here like in other places the stream wouldn't get flushed if an
exception occured while writing - but the flush will most likely not
succeed in this case anyway, so the change won't have much of an impact.

Stefan

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

Re: [PATCH] JUnitTestRunner.filterStack(String) does not flush BufferedWriter

2010-02-01 Thread Antoine Levy Lambert

Thanks to you too again. We are redoing the next 1.8.0 RC because of 
what you found :-).


Regards,

Antoine

N C wrote:

--- On Sun, 1/31/10, Antoine Levy-Lambert  wrote:
  

If you are setup to build/compile ant yourself, you can
update your working copy from svn and report whether the change fixes
the problem for you.



I've built from r905382.  The problem is resolved in this build.  Thanks.



  



  



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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 2173 matches

Mail list logo