Community
Participate
Working Groups
To Reproduce: 1) Specific ant file "build.xml" <project name="Specific"> <include file="../../../common.xml" as="common" /> <!-- Error Here --> <target name="deploy" depends="common.deploy"/> </project> 2) Ant common build file "common.xml" located in a higher directory, outside of the Eclipse project folder: <project name="common"> <target name="deploy"> <echo>test</echo> </target> </project> Expected: No errors in editor Actual: - Editor displays error at above-marked line : "Target shared.deploy does not exist in this project" - "deploy" target in "build.xml" works with command line ant Note: removing the "as" attribute on the <include> and all the "common" prefixes doesn't seem to fix the problem. Using the <import> tag, however, does seem to make the error disappear.
I made a mistake in my listing of the error. It should be "Target common.deploy does not exist in this project". The issue is that <import> tags seem to allow you to import files outside of an Eclipse project without error, but <include> tags cause an error.
Thanks for the bug report Daniel. The reason this does not work is that we have not added support for the include task yet - I know, I know, it came out in Ant 1.8.x, but there has been no committer time to work on it. I'm going to try and make time to get this done in M2.
*** Bug 434187 has been marked as a duplicate of this bug. ***
Hello, I don't know, when the milestone M2 is planned :-) . However we're quite suffering from this problems, too, and I hate to get red marks on my projects for non-errors How difficult would it be to provide as a workaround an option to switch off ant target checking in this project? I did not find anything. Would help me alot. Thank you Michael
No one currently working on this and this not planned for any release right now. We will seek help from the community to provide a quality patch to solve this.
Hello This bug creates a lot of error markers on my project (150 markers ^^ ) Does it planned for this year to correct this bug ? Best regards
Not for 4.13 but will see if we can do something for 4.14 for December release. If anyone from community can come forward it will be great.
Created attachment 279293 [details] Patch for bug 412809: Support for include task added The attached patch should fix the wrong error reports caused by the include-tasks. Short description of the solution: The org.eclipse.ant.ui-implementation (and the underlying ant-implementation) is able to handle import-tasks (AntImportNode), but not include-tasks. I added the missing node-type (AntIncludeNode) and "registered" the new node-type at the node-selection-functionality (AntModel). Furthermore the new node type needs to handle target-prefixes correctly on included files (according to the documentation at https://ant.apache.org/manual/Tasks/include.html). This functionality is also part of this proposed patch and should allow to use "multi-hierarchical" includes with/without aliases (i.e. "includes inside includes" with/without using the "as"-property). Provided tests: I extended the test-file AntUtilTests and provided several test-build-files and the following tests: - Simple include-hierarchy (1-level) without using aliases - Simple include-hierarchy (1-level) with using aliases (the test-case which was initially added on this bug-description) - Complex include-hierarchy (4-level) without using aliases - Complex include-hierarchy (4-level) with using aliases - Complex include-hierarchy (4-level) with and without using aliases Open issues: 1.) The different task-types seem to have an image associated (see IAntUIConstants.java). I made a new entry for the include-task, but used the image-identifier of the import-task. If this is not desired, please add the correct image and change the identifier). 2.) Include-tasks can be defined with or without custom alias (i.e. by setting the "as"-property). If no alias is set, the identifier to identify a certain target within an included build-file is the project-name. I couldn't find the project-name of the included file where the desired target is located: Every AntTaskNode contains a reference to the project via getTask().getProject(), but this project seems to be always the top-level-project (and not the project where the target is located). Hence my course of action to extract the project-name is to "reparse" the build-file (I got the build-file by calling getIFile()-method of AntElementNode), where the target is located (i.e. by extracting the <project name="projectName">-tag). If I have overseen a more elegant way, please adjust this also. Further notes: I had problems to generate the attached patch-file (eclipse didn't include all changes in the patch-file at the first try). I hope I could have fixed this problem and attached the correct and complete patch-file. If not, please let me know and I'll try it again ;) Kind regards, Alex
Created attachment 279294 [details] patched plugin-jar tested with eclipse oxygen 3 (4.7.3) and 2019-03 (4.11.0) If you don't want to wait for the new release, you can patch your current eclipse-installation with the attached jar: 1.) Navigate to the eclipse-installation-folder and enter the folder "plugins". 2.) Backup the jar "org.eclipse.ant_ui_<the_current_version_number>" (if something goes wrong). 3.) Change the name of the attached jar by renaming it with the name of the "org.eclipse.ant_ui"-jar that is used by your current eclipse-installation (i.e. replacing the "_versionNumber"-suffix with the correct version-number). 4.) Copy the correctly renamed jar into the mentioned "plugin"-folder and replace the current "org.eclipse.ant_ui_<the_current_version_number>"-jar. 5.) Restart eclipse. This temporary fix was tested with eclipse oxygen 3 (4.7.3) and eclipse 2019-03 (4.11.0). Kind regards, Alex
(In reply to alex bl from comment #8) > Further notes: > > I had problems to generate the attached patch-file (eclipse didn't include > all changes in the patch-file at the first try). I hope I could have fixed > this problem and attached the correct and complete patch-file. If not, > please let me know and I'll try it again ;) > > Kind regards, > > Alex Unfortunately patches are only accepted as Gerrit changes this days. For instructions how to create them see https://wiki.eclipse.org/Platform/How_to_Contribute#Creating_a_Gerrit_review_or_a_patch or https://wiki.eclipse.org/Platform-releng/Git_Workflows#Gerrit_workflow_for_a_committer Good luck. :D (and of cause ask if you need help)
Alex, you should also sign ECA agreement https://www.eclipse.org/legal/ECA.php (do you see red ECA icon next to your name in bugzilla?). This is precondition for contributing.
Thanks Alex for stepping up!
(In reply to Paul Pazderski from comment #10) > > Unfortunately patches are only accepted as Gerrit changes this days. For > instructions how to create them see > https://wiki.eclipse.org/Platform/ > How_to_Contribute#Creating_a_Gerrit_review_or_a_patch > or > https://wiki.eclipse.org/Platform-releng/ > Git_Workflows#Gerrit_workflow_for_a_committer > > Good luck. :D (and of cause ask if you need help) I'm pretty sure that I followed all the instructions described at these links :) But my attempt to push my changes is rejected: An error happened while checking if user has a signed agreement Processing changes: refs: 1 Processing changes: refs: 1, done I signed the ECA agreement a couple of hours ago and I used the correct e-mail-address (the one associated with my eclipse user account). Any ideas what's going wrong here?
(In reply to Alexander Blaas from comment #13) > (In reply to Paul Pazderski from comment #10) > > > > Unfortunately patches are only accepted as Gerrit changes this days. For > > instructions how to create them see > > https://wiki.eclipse.org/Platform/ > > How_to_Contribute#Creating_a_Gerrit_review_or_a_patch > > or > > https://wiki.eclipse.org/Platform-releng/ > > Git_Workflows#Gerrit_workflow_for_a_committer > > > > Good luck. :D (and of cause ask if you need help) > > I'm pretty sure that I followed all the instructions described at these > links :) > But my attempt to push my changes is rejected: > > An error happened while checking if user has a signed agreement > Processing changes: refs: 1 > Processing changes: refs: 1, done > > > I signed the ECA agreement a couple of hours ago and I used the correct > e-mail-address (the one associated with my eclipse user account). > > Any ideas what's going wrong here? Sure you were using "olaf.dev17" at gmail.com account? It is shown "green" in bugzilla, so it should be OK for Gerrit too. Try again, may be Gerrit has its usual "weekend" instabilities phase again?
(In reply to Andrey Loskutov from comment #14) > (In reply to Alexander Blaas from comment #13) > > (In reply to Paul Pazderski from comment #10) > > > > > > Unfortunately patches are only accepted as Gerrit changes this days. For > > > instructions how to create them see > > > https://wiki.eclipse.org/Platform/ > > > How_to_Contribute#Creating_a_Gerrit_review_or_a_patch > > > or > > > https://wiki.eclipse.org/Platform-releng/ > > > Git_Workflows#Gerrit_workflow_for_a_committer > > > > > > Good luck. :D (and of cause ask if you need help) > > > > I'm pretty sure that I followed all the instructions described at these > > links :) > > But my attempt to push my changes is rejected: > > > > An error happened while checking if user has a signed agreement > > Processing changes: refs: 1 > > Processing changes: refs: 1, done > > > > > > I signed the ECA agreement a couple of hours ago and I used the correct > > e-mail-address (the one associated with my eclipse user account). > > > > Any ideas what's going wrong here? > > Sure you were using "olaf.dev17" at gmail.com account? It is shown "green" > in bugzilla, so it should be OK for Gerrit too. Try again, may be Gerrit has > its usual "weekend" instabilities phase again? Yes, that's the e-mail I used in the "Signed-off-by"-line, as author and committer. I tried to insert another e-mail, just for fun. Then I got a proper error: "The email address does not match your user account. The following addresses are currently registered: olaf.dev17 at gmail.com". I retried it several times (the last attempt was a couple of minutes ago), but got the same result. I'll try it again after the weekend.
Please try again and if does not work, please create a bug with Eclipse Community-> webmaster. He can look into the issue.
Moving the bug to RC1. Hopefully we will have the issue resolved soon.
New Gerrit change created: https://git.eclipse.org/r/148074
New Gerrit change created: https://git.eclipse.org/r/148076
New Gerrit change created: https://git.eclipse.org/r/148077
New Gerrit change created: https://git.eclipse.org/r/148124
New Gerrit change created: https://git.eclipse.org/r/148125
New Gerrit change created: https://git.eclipse.org/r/148126
Alexander you can and should reuse your changes instead of creating new ones i.e. you should amend changes and repush the commit. If you upload a commit with the same Change-Id in the commit message as a previous commit Gerrit will reuse the same change and show the new commit as new patchset and also will trigger a new build. E.g. for your incomplete https://git.eclipse.org/r/#/c/148124/ you could amend your local with the missing pom.xml change and then push it again with the same Change-Id: I0187b10ba1d983ff6b1bd5b10ab956cae1b1a3e8 and Gerrit had updated this one instead of creating https://git.eclipse.org/r/148125.
PS: anyone who wants to review the change? I'm not experienced with the Eclipse Ant code and not even use Ant very often so anyone other than me might be a better reviewer.
I will review the change tomorrow, please create one Gerrit with complete changes. Some quick observations: 1. We don't need to add in forceQualifierUpdate, we can increase the bundle version 2. Why do we need an update in css files?
(In reply to Paul Pazderski from comment #24) > Alexander you can and should reuse your changes instead of creating new ones > i.e. you should amend changes and repush the commit. > If you upload a commit with the same Change-Id in the commit message as a > previous commit Gerrit will reuse the same change and show the new commit as > new patchset and also will trigger a new build. > E.g. for your incomplete https://git.eclipse.org/r/#/c/148124/ you could > amend your local with the missing pom.xml change and then push it again with > the same Change-Id: I0187b10ba1d983ff6b1bd5b10ab956cae1b1a3e8 and Gerrit had > updated this one instead of creating https://git.eclipse.org/r/148125. Didn't know that. Thanks for the information. (In reply to Sarika Sinha from comment #26) > I will review the change tomorrow, please create one Gerrit with complete > changes. > Some quick observations: > 1. We don't need to add in forceQualifierUpdate, we can increase the bundle > version > 2. Why do we need an update in css files? I'm sorry, I couldn't answer earlier. Is there a way to delete the unnecessary gerrit changes? The css files: These changes were part of a merge-commit. They have nothing to do with my patch.
(In reply to Alexander Blaas from comment #27) > Is there a way to delete the unnecessary gerrit changes? How to remove them here you already figured out yourself. In the changes you can "Abandon" them. That counts as deleted.
New Gerrit change created: https://git.eclipse.org/r/148220
(In reply to Paul Pazderski from comment #28) > (In reply to Alexander Blaas from comment #27) > > Is there a way to delete the unnecessary gerrit changes? > > How to remove them here you already figured out yourself. In the changes you > can "Abandon" them. That counts as deleted. Ok, thanks. The final gerrit change should be ready for review :-)
(In reply to Alexander Blaas from comment #30) > > Ok, thanks. The final gerrit change should be ready for review :-) I have provided the comments on the Gerrit.
Moving to 4.14 M1.
Gerrit change https://git.eclipse.org/r/148220 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=1e3cb5d98f74edc7d362343bd97688ffeb5b4101
Thanks Alexander! Please add an entry to N&N , then we can resolve the bug.
(In reply to Sarika Sinha from comment #34) > Thanks Alexander! > > Please add an entry to N&N , then we can resolve the bug. Sure, no problem. How, respectively, where can I do that?
(In reply to Alexander Blaas from comment #35) > (In reply to Sarika Sinha from comment #34) > > Thanks Alexander! > > > > Please add an entry to N&N , then we can resolve the bug. > > Sure, no problem. How, respectively, where can I do that? Repo is : www.eclipse.org/eclipse/news.git You can add an entry in Platform for 4.14. Checkout the Instructions first available in the repo.
New Gerrit change created: https://git.eclipse.org/r/151143
(In reply to Sarika Sinha from comment #36) > > Repo is : www.eclipse.org/eclipse/news.git > You can add an entry in Platform for 4.14. > Checkout the Instructions first available in the repo. Thanks for the information. I added the new entry as suggested.
Gerrit change https://git.eclipse.org/r/151143 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=53f9938e4226f4853d7cbbfbf5957134d1ea1eda
Thanks!
New Gerrit change created: https://git.eclipse.org/r/151279
We have test failures in ant ui https://download.eclipse.org/eclipse/downloads/drops4/I20191016-1800/testResults.php
Gerrit change https://git.eclipse.org/r/151279 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=593dc9b07cb9d8293cc9024abb53e1580440cca1
@Alexander, We have all the new tests failing on Windows, can you look into it? https://download.eclipse.org/eclipse/downloads/drops4/I20191019-1800/testresults/html/org.eclipse.ant.tests.ui_ep414I-unit-win32-java8_win32.win32.x86_64_8.0.html
(In reply to Sarika Sinha from comment #44) > @Alexander, > We have all the new tests failing on Windows, can you look into it? > https://download.eclipse.org/eclipse/downloads/drops4/I20191019-1800/ > testresults/html/org.eclipse.ant.tests.ui_ep414I-unit-win32-java8_win32. > win32.x86_64_8.0.html Sure. I'll have a look.
(In reply to Sarika Sinha from comment #44) > @Alexander, > We have all the new tests failing on Windows, can you look into it? > https://download.eclipse.org/eclipse/downloads/drops4/I20191019-1800/ > testresults/html/org.eclipse.ant.tests.ui_ep414I-unit-win32-java8_win32. > win32.x86_64_8.0.html Issue found and resolved (a non-uniform way to retrieve file-paths which resulted in different hash-map keys on windows). Before I push the fix: The performance-test still fails: It seems that it takes much more time on windows than on linux... Are you aware of such a "general performance-issue" on windows? If not, may I should review my solution.
(In reply to Alexander Blaas from comment #46) > (In reply to Sarika Sinha from comment #44) > > @Alexander, > > We have all the new tests failing on Windows, can you look into it? > > https://download.eclipse.org/eclipse/downloads/drops4/I20191019-1800/ > > testresults/html/org.eclipse.ant.tests.ui_ep414I-unit-win32-java8_win32. > > win32.x86_64_8.0.html > > Issue found and resolved (a non-uniform way to retrieve file-paths which > resulted in different hash-map keys on windows). > > Before I push the fix: > > The performance-test still fails: It seems that it takes much more time on > windows than on linux... > > Are you aware of such a "general performance-issue" on windows? If not, may > I should review my solution. We have seen some issues on Windows, I can't deny that. But it will be good if you can review the solution also. In the worst case we will have need to have a higher threshold for win only in the test.
New Gerrit change created: https://git.eclipse.org/r/151398
(In reply to Sarika Sinha from comment #47) > (In reply to Alexander Blaas from comment #46) > > (In reply to Sarika Sinha from comment #44) > > > @Alexander, > > > We have all the new tests failing on Windows, can you look into it? > > > https://download.eclipse.org/eclipse/downloads/drops4/I20191019-1800/ > > > testresults/html/org.eclipse.ant.tests.ui_ep414I-unit-win32-java8_win32. > > > win32.x86_64_8.0.html > > > > Issue found and resolved (a non-uniform way to retrieve file-paths which > > resulted in different hash-map keys on windows). > > > > Before I push the fix: > > > > The performance-test still fails: It seems that it takes much more time on > > windows than on linux... > > > > Are you aware of such a "general performance-issue" on windows? If not, may > > I should review my solution. > > We have seen some issues on Windows, I can't deny that. But it will be good > if you can review the solution also. > In the worst case we will have need to have a higher threshold for win only > in the test. The performance issue seems not to be caused by the bugfix: Neither the construction of the property holder (i.e. storing the parsed project-names) nor the target-prefix-construction (i.e. either querying the property holder or retrieving the project-alias-properties and combining them: All the code executed at AntIncludeNode.java between lines 50 and 60) have an execution time of >5ms. As you suggested, I added an OS-dependend treshold (for win 15s just to be sure, for all other OS the 7.5s remain).
Gerrit change https://git.eclipse.org/r/151398 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=1ea38ca8aebd19e692f0b48e4e2b4bc43bb5da9c
(In reply to Alexander Blaas from comment #49) > > The performance issue seems not to be caused by the bugfix: Neither the > construction of the property holder (i.e. storing the parsed project-names) > nor the target-prefix-construction (i.e. either querying the property holder > or retrieving the project-alias-properties and combining them: All the code > executed at AntIncludeNode.java between lines 50 and 60) have an execution > time of >5ms. > > As you suggested, I added an OS-dependend treshold (for win 15s just to be > sure, for all other OS the 7.5s remain). Thanks! Where you able to trace the culprit method or file where the time was spent? We can create a separate bug to work on that.
(In reply to Sarika Sinha from comment #51) > (In reply to Alexander Blaas from comment #49) > > > > The performance issue seems not to be caused by the bugfix: Neither the > > construction of the property holder (i.e. storing the parsed project-names) > > nor the target-prefix-construction (i.e. either querying the property holder > > or retrieving the project-alias-properties and combining them: All the code > > executed at AntIncludeNode.java between lines 50 and 60) have an execution > > time of >5ms. > > > > As you suggested, I added an OS-dependend treshold (for win 15s just to be > > sure, for all other OS the 7.5s remain). > > Thanks! Where you able to trace the culprit method or file where the time > was spent? > We can create a separate bug to work on that. I just reviewed the code belonging to this bugfix. But I'll open a new bug report to investigate that.
Build id: I20191118-0600
