AUTO: Carsten Pfeiffer ist außer Haus (returning 18.04.2017)
I am out of the office until 18.04.2017. In dringenden Fällen kontaktieren Sie bitte sekretariatgebit.de Note: This is an automated response to your message "Re: [28/34] ant git commit: java 5-8" sent on 13.04.2017 17:21:15. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 04.01.2017)
I am out of the office until 04.01.2017. In dringenden Fällen kontaktieren Sie bitte erwin.tratargebit.de oder tom.kraussgebit.de. Note: This is an automated response to your message "Bug report for Ant [2016/12/25]" sent on 25.12.2016 08:15:01. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 28.11.2016)
I am out of the office until 28.11.2016. In dringenden Fällen kontaktieren Sie bitte erwin.tratargebit.de oder tom.kraussgebit.de. Note: This is an automated response to your message "[SPAM] AW: DISCUSS How to retire a subproject/component" sent on 25.11.2016 08:18:06. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 14.11.2016)
I am out of the office until 14.11.2016. In dringenden Fällen kontaktieren Sie bitte erwin.tratargebit.de oder tom.kraussgebit.de. Note: This is an automated response to your message "Bug report for Ant [2016/11/13]" sent on 13.11.2016 08:15:01. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 02.11.2016)
I am out of the office until 02.11.2016. In dringenden Fällen kontaktieren Sie bitte erwin.tratargebit.de oder tom.kraussgebit.de. Note: This is an automated response to your message "Re: ant wrapper script testing" sent on 31.10.2016 21:20:38. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 28.10.2016)
I am out of the office until 28.10.2016. Note: This is an automated response to your message "Re: Early Access builds for JDK 8u122 b02 , JDK 9 & JDK 9 with Project Jigsaw b140 are available on java.net" sent on 25.10.2016 11:25:59. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 17.10.2016)
I am out of the office until 17.10.2016. In dringenden Fällen, kontaktieren Sie bitte ErwinTratargebitde oder TomKraussgebitde. Note: This is an automated response to your message "Re: ant wrapper script testing" sent on 14.10.2016 21:16:06. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 29.09.2016)
I am out of the office until 29.09.2016. In dringenden Fällen, kontaktieren Sie bitte ErwinTratargebitde oder TomKraussgebitde. Note: This is an automated response to your message "[GitHub] ant issue #24: fix 60150 values containing backtick or $ character cause she..." sent on 28.09.2016 21:08:07. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 05.09.2016)
I am out of the office until 05.09.2016. In dringenden Fällen, kontaktieren Sie bitte ErwinTratargebitde oder TomKraussgebitde. Note: This is an automated response to your message "[GitHub] ant-easyant-core pull request #2: Upgrade Junit: fix Eclipse project classpa..." sent on 22.08.2016 21:02:19. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 06.06.2016)
I am out of the office until 06.06.2016. In dringenden Fällen, kontaktieren Sie bitte ErwinTratargebitde oder TomKraussgebitde. Note: This is an automated response to your message "Bug report for Ant [2016/06/05]" sent on 05.06.2016 09:15:01. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 08.02.2016)
I am out of the office until 08.02.2016. In dringenden Fällen, kontaktieren Sie bitte ErwinTratargebitde oder TomKraussgebitde. Note: This is an automated response to your message "Bug report for Ant [2016/02/07]" sent on 07.02.2016 08:15:01. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 04.01.2016)
I am out of the office until 04.01.2016. In dringenden Fällen, kontaktieren Sie bitte ErwinTratargebitde oder TomKraussgebitde. Note: This is an automated response to your message "Bug report for Ant [2015/12/27]" sent on 27.12.2015 08:15:02. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 11.05.2015)
I am out of the office until 11.05.2015. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Note: This is an automated response to your message Bug report for Ant [2015/05/10] sent on 10.05.2015 09:15:01. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 13.04.2015)
I am out of the office until 13.04.2015. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Note: This is an automated response to your message Re: [jira] (IVY-1197) OutOfMemoryError during ivy:publish sent on 08.04.2015 03:22:38. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 08.01.2015)
I am out of the office until 08.01.2015. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Note: This is an automated response to your message [ANNOUNCE] Apache Ivy 2.4.0 Released sent on 26.12.2014 17:54:05. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 04.12.2014)
I am out of the office until 04.12.2014. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Note: This is an automated response to your message Re: [CANCELED][VOTE] Release Ivy 2.4.0 sent on 03.12.2014 10:25:28. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 17.11.2014)
I am out of the office until 17.11.2014. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Note: This is an automated response to your message which repo to use, svn or github? sent on 14.11.2014 01:05:36. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (Rückkehr am 25.06.2014)
Ich kehre zurück am 25.06.2014. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht former svn:externals: subtree merge or submodule gesendet am 29.05.2014 11:45:47. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Deadlock in IvyClasspathContainerImpl.setClasspathEntries() (regression from IVYDE-259)
Hi, The change in IvyClasspathContainer (asyncExec - syncExec) may unfortunately lead to deadlock situations. If the main thread attempts to execute a job while the resolve job is already running, the main thread waits for the resolve job to finish. The latter then attempts to syncExec() into the main thread, which won't work. Thread [Worker-4] (Suspended) waiting for: RunnableLock (id=122) Object.wait(long) line: not available [native method] RunnableLock(Object).wait() line: 503 Synchronizer.syncExec(Runnable) line: 187 Display.syncExec(Runnable) line: 4330 IvyClasspathContainerImpl.setClasspathEntries(IClasspathEntry[]) line: 148 IvyClasspathContainerImpl.updateClasspathEntries(IClasspathEntry[]) line: 144 IvyClasspathResolver.postBatchResolve() line: 40 IvyResolveJob.doRun(IProgressMonitor) line: 263 IvyResolveJob.run(IProgressMonitor) line: 85 Worker.run() line: 54 Thread [main] (Suspended) owns: RunnableLock (id=122) waited by: Thread [Worker-4] (Suspended) waiting for: Object (id=123) Object.wait(long) line: not available [native method] Object.wait() line: 503 ThreadJob.waitForRun(ThreadJob, IProgressMonitor, InternalJob, Thread) line: 272 ThreadJob.joinRun(ThreadJob, IProgressMonitor) line: 199 ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 92 JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 286 WorkManager.checkIn(ISchedulingRule, IProgressMonitor) line: 118 Workspace.prepareOperation(ISchedulingRule, IProgressMonitor) line: 2282 Folder(Resource).refreshLocal(int, IProgressMonitor) line: 1655 ExternalFoldersManager.createLinkFolder(IPath, boolean, IProject, IProgressMonitor) line: 155 ExternalFoldersManager.createLinkFolder(IPath, boolean, IProgressMonitor) line: 145 ExternalFolderChange.updateExternalFoldersIfNecessary(boolean, IProgressMonitor) line: 48 SetContainerOperation(ChangeClasspathOperation).classpathChanged(ClasspathChange, boolean) line: 62 SetContainerOperation.executeOperation() line: 110 SetContainerOperation(JavaModelOperation).run(IProgressMonitor) line: 728 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2344 SetContainerOperation(JavaModelOperation).runOperation(IProgressMonitor) line: 793 JavaCore.setClasspathContainer(IPath, IJavaProject[], IClasspathContainer[], IProgressMonitor) line: 4952 IvyClasspathContainerImpl.notifyUpdateClasspathEntries() line: 172 IvyClasspathContainerImpl$1.run() line: 162 RunnableLock.run() line: 35 Synchronizer.runAsyncMessages(boolean) line: 135 Display.runAsyncMessages(boolean) line: 3563 Display.readAndDispatch() line: 3212 ... I'm wondering why the IvyClasspathContainer (now Impl) needs to syncExec() or asyncExec() at all. Do you remember why it cannot update the classpath in the background thread? Thanks Carsten
AUTO: Carsten Pfeiffer ist außer Haus (Rückkehr am 08.01.2014)
Ich kehre zurück am 08.01.2014. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht Re: [VOTE] Release Ant 1.9.3 gesendet am 26.12.2013 07:49:29. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Antwort: Re: Re: OverlappingFileLockException when using artifact-lock-nio
Hi Charles, awesome, your fix works perfectly. That was fast :-) Thanks a lot, Carsten Von:Charles Duffy char...@dyfis.net An: Ant Developers List dev@ant.apache.org Datum: 19.12.2013 23:37 Betreff:Re: Re: OverlappingFileLockException when using artifact-lock-nio Howdy, Carsten -- Thank you again for the reproducer, which was invaluable in tracking down this issue and validating the fix. The issue should be resolved in current trunk; also, a new test case has been added to the suite to prevent regressions. Please let me know if you have further issues. Thanks, -- Charles On Wed, Dec 18, 2013 at 3:16 AM, carsten.pfeif...@gebit.de wrote: Hi again, I've filed the issue https://issues.apache.org/jira/browse/IVY-1454 The exception indeed appears to occur due to our specific use of the parallel task, in conjunction with the antcallback task from ant-contrib. Thanks, Carsten Von:carsten.pfeif...@gebit.de An: Ant Developers List dev@ant.apache.org Datum: 18.12.2013 09:38 Betreff:Re: OverlappingFileLockException when using artifact-lock-nio Hi Charles, thanks a lot for your investigation -- I'm gathering some more information about the problem and submit them to JIRA. The is a trunk build from https://builds.apache.org/job/Ivy/446/ and unfortunately, we're not using symlinks to the caches and have multiple cache configurations :-} I'll send a notice with the issue number when I've got all the details. Thanks, Carsten Von:Charles Duffy char...@dyfis.net An: Ant Developers List dev@ant.apache.org Datum: 18.12.2013 01:49 Betreff:Re: Re: OverlappingFileLockException when using artifact-lock-nio Howdy -- I've spent a few minutes analyzing the logic in the code in question. tryLock is documented to throw that exception only when the other instance of the lock is held by the same process, rather than by out-of-process code. The current code intends to avoid that situation by use of a synchronized block in acquireLock(); tryLock() is only called within that block. Since the concrete lock strategy classes' instances should be singletons, that block should prevent multiple tryLock() invocations inside a process. Unfortunately, the practice appears to differ from that theory, but even so, a few conclusions can be drawn: - The issue in question should be specific to use of parallel, not to multiple uses of ivy from unrelated JVM processes. - The underlying issue extends beyond the NIO locker -- I wouldn't trust either of Ivy's file-locking mechanisms to be safe if the intended synchronization guarantee by acquireLock() is invalid. - If there's any chance you could have multiple definitions of the same cache in your configuration, particularly with different filenames referring to the same files (as with symlinks), that would make this much less of a puzzle. :) Could you confirm that you can reproduce this on a trunk build of Ivy? (NIO locking was very, very broken prior to the merge of IVY-1424). To come closer to a proper fix, I'll need to put together a reproducer. Have you filed a JIRA ticket for this (on https://issues.apache.org/jira/browse/IVY), or would you like me to do so on your behalf? Thanks! On Tue, Dec 17, 2013 at 10:29 AM, carsten.pfeif...@gebit.de wrote: Cool, if you find something, I'll happily test that. Thanks, Carsten Von:Charles Duffy char...@dyfis.net An: Ant Developers List dev@ant.apache.org Datum: 17.12.2013 15:29 Betreff:Re: OverlappingFileLockException when using artifact-lock-nio I'll try to take a look at this today. Thanks for the report! On Tue, Dec 17, 2013 at 8:19 AM, carsten.pfeif...@gebit.de wrote: Hi, I just tried the artifact-lock-io lockstrategy with ivy_2.4.0.alpha_20131214174343.jar. At some point I got resolve error like this: [ivy:resolve] :: [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: [ivy:resolve] :: [ivy:resolve] :: org.hamcrest#hamcrest-core;1.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.glassfish#javax.ejb;3.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.jboss.weld.se#weld-se-core;1.1.10.Final: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: Now I'm wondering if I did something wrong in our parallel tasks or if that rather indicates a problem in the lock strategy implementation. The build system is Debian Linux (Wheezy), filesystem is local. There's
Re: OverlappingFileLockException when using artifact-lock-nio
Hi Charles, thanks a lot for your investigation -- I'm gathering some more information about the problem and submit them to JIRA. The is a trunk build from https://builds.apache.org/job/Ivy/446/ and unfortunately, we're not using symlinks to the caches and have multiple cache configurations :-} I'll send a notice with the issue number when I've got all the details. Thanks, Carsten Von:Charles Duffy char...@dyfis.net An: Ant Developers List dev@ant.apache.org Datum: 18.12.2013 01:49 Betreff:Re: Re: OverlappingFileLockException when using artifact-lock-nio Howdy -- I've spent a few minutes analyzing the logic in the code in question. tryLock is documented to throw that exception only when the other instance of the lock is held by the same process, rather than by out-of-process code. The current code intends to avoid that situation by use of a synchronized block in acquireLock(); tryLock() is only called within that block. Since the concrete lock strategy classes' instances should be singletons, that block should prevent multiple tryLock() invocations inside a process. Unfortunately, the practice appears to differ from that theory, but even so, a few conclusions can be drawn: - The issue in question should be specific to use of parallel, not to multiple uses of ivy from unrelated JVM processes. - The underlying issue extends beyond the NIO locker -- I wouldn't trust either of Ivy's file-locking mechanisms to be safe if the intended synchronization guarantee by acquireLock() is invalid. - If there's any chance you could have multiple definitions of the same cache in your configuration, particularly with different filenames referring to the same files (as with symlinks), that would make this much less of a puzzle. :) Could you confirm that you can reproduce this on a trunk build of Ivy? (NIO locking was very, very broken prior to the merge of IVY-1424). To come closer to a proper fix, I'll need to put together a reproducer. Have you filed a JIRA ticket for this (on https://issues.apache.org/jira/browse/IVY), or would you like me to do so on your behalf? Thanks! On Tue, Dec 17, 2013 at 10:29 AM, carsten.pfeif...@gebit.de wrote: Cool, if you find something, I'll happily test that. Thanks, Carsten Von:Charles Duffy char...@dyfis.net An: Ant Developers List dev@ant.apache.org Datum: 17.12.2013 15:29 Betreff:Re: OverlappingFileLockException when using artifact-lock-nio I'll try to take a look at this today. Thanks for the report! On Tue, Dec 17, 2013 at 8:19 AM, carsten.pfeif...@gebit.de wrote: Hi, I just tried the artifact-lock-io lockstrategy with ivy_2.4.0.alpha_20131214174343.jar. At some point I got resolve error like this: [ivy:resolve] :: [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: [ivy:resolve] :: [ivy:resolve] :: org.hamcrest#hamcrest-core;1.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.glassfish#javax.ejb;3.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.jboss.weld.se#weld-se-core;1.1.10.Final: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: Now I'm wondering if I did something wrong in our parallel tasks or if that rather indicates a problem in the lock strategy implementation. The build system is Debian Linux (Wheezy), filesystem is local. There's no other access to Ivy's cache than by Ivy itself. Best regards Carsten
Antwort: Re: OverlappingFileLockException when using artifact-lock-nio
Hi again, I've filed the issue https://issues.apache.org/jira/browse/IVY-1454 The exception indeed appears to occur due to our specific use of the parallel task, in conjunction with the antcallback task from ant-contrib. Thanks, Carsten Von:carsten.pfeif...@gebit.de An: Ant Developers List dev@ant.apache.org Datum: 18.12.2013 09:38 Betreff:Re: OverlappingFileLockException when using artifact-lock-nio Hi Charles, thanks a lot for your investigation -- I'm gathering some more information about the problem and submit them to JIRA. The is a trunk build from https://builds.apache.org/job/Ivy/446/ and unfortunately, we're not using symlinks to the caches and have multiple cache configurations :-} I'll send a notice with the issue number when I've got all the details. Thanks, Carsten Von:Charles Duffy char...@dyfis.net An: Ant Developers List dev@ant.apache.org Datum: 18.12.2013 01:49 Betreff:Re: Re: OverlappingFileLockException when using artifact-lock-nio Howdy -- I've spent a few minutes analyzing the logic in the code in question. tryLock is documented to throw that exception only when the other instance of the lock is held by the same process, rather than by out-of-process code. The current code intends to avoid that situation by use of a synchronized block in acquireLock(); tryLock() is only called within that block. Since the concrete lock strategy classes' instances should be singletons, that block should prevent multiple tryLock() invocations inside a process. Unfortunately, the practice appears to differ from that theory, but even so, a few conclusions can be drawn: - The issue in question should be specific to use of parallel, not to multiple uses of ivy from unrelated JVM processes. - The underlying issue extends beyond the NIO locker -- I wouldn't trust either of Ivy's file-locking mechanisms to be safe if the intended synchronization guarantee by acquireLock() is invalid. - If there's any chance you could have multiple definitions of the same cache in your configuration, particularly with different filenames referring to the same files (as with symlinks), that would make this much less of a puzzle. :) Could you confirm that you can reproduce this on a trunk build of Ivy? (NIO locking was very, very broken prior to the merge of IVY-1424). To come closer to a proper fix, I'll need to put together a reproducer. Have you filed a JIRA ticket for this (on https://issues.apache.org/jira/browse/IVY), or would you like me to do so on your behalf? Thanks! On Tue, Dec 17, 2013 at 10:29 AM, carsten.pfeif...@gebit.de wrote: Cool, if you find something, I'll happily test that. Thanks, Carsten Von:Charles Duffy char...@dyfis.net An: Ant Developers List dev@ant.apache.org Datum: 17.12.2013 15:29 Betreff:Re: OverlappingFileLockException when using artifact-lock-nio I'll try to take a look at this today. Thanks for the report! On Tue, Dec 17, 2013 at 8:19 AM, carsten.pfeif...@gebit.de wrote: Hi, I just tried the artifact-lock-io lockstrategy with ivy_2.4.0.alpha_20131214174343.jar. At some point I got resolve error like this: [ivy:resolve] :: [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: [ivy:resolve] :: [ivy:resolve] :: org.hamcrest#hamcrest-core;1.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.glassfish#javax.ejb;3.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.jboss.weld.se#weld-se-core;1.1.10.Final: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: Now I'm wondering if I did something wrong in our parallel tasks or if that rather indicates a problem in the lock strategy implementation. The build system is Debian Linux (Wheezy), filesystem is local. There's no other access to Ivy's cache than by Ivy itself. Best regards Carsten
OverlappingFileLockException when using artifact-lock-nio
Hi, I just tried the artifact-lock-io lockstrategy with ivy_2.4.0.alpha_20131214174343.jar. At some point I got resolve error like this: [ivy:resolve] :: [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: [ivy:resolve] :: [ivy:resolve] :: org.hamcrest#hamcrest-core;1.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.glassfish#javax.ejb;3.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.jboss.weld.se#weld-se-core;1.1.10.Final: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: Now I'm wondering if I did something wrong in our parallel tasks or if that rather indicates a problem in the lock strategy implementation. The build system is Debian Linux (Wheezy), filesystem is local. There's no other access to Ivy's cache than by Ivy itself. Best regards Carsten
Antwort: Re: OverlappingFileLockException when using artifact-lock-nio
Cool, if you find something, I'll happily test that. Thanks, Carsten Von:Charles Duffy char...@dyfis.net An: Ant Developers List dev@ant.apache.org Datum: 17.12.2013 15:29 Betreff:Re: OverlappingFileLockException when using artifact-lock-nio I'll try to take a look at this today. Thanks for the report! On Tue, Dec 17, 2013 at 8:19 AM, carsten.pfeif...@gebit.de wrote: Hi, I just tried the artifact-lock-io lockstrategy with ivy_2.4.0.alpha_20131214174343.jar. At some point I got resolve error like this: [ivy:resolve] :: [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: [ivy:resolve] :: [ivy:resolve] :: org.hamcrest#hamcrest-core;1.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.glassfish#javax.ejb;3.1: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: org.jboss.weld.se#weld-se-core;1.1.10.Final: java.nio.channels.OverlappingFileLockException at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) [ivy:resolve] :: Now I'm wondering if I did something wrong in our parallel tasks or if that rather indicates a problem in the lock strategy implementation. The build system is Debian Linux (Wheezy), filesystem is local. There's no other access to Ivy's cache than by Ivy itself. Best regards Carsten
Re: Review for IVY-1431?
Yes, the idea is to install the artifact just as it was downloaded. If it was downloaded from an Ivy repository, you install the jar + the ivy.xml. If it was downloaded from a Maven repository, you install jar, the original .pom. and the ivy.xml. If you think that this depends too much on where the artifact originally comes from, one could add an optional attribute to the install task installOriginalMetadata or something like that, so that this would become an explicit action. Any comment from a committer, perhaps? :-) Thanks Carsten Von:Stephen Haberman stephen.haber...@gmail.com An: dev@ant.apache.org Datum: 29.10.2013 04:04 Betreff:Re: Review for IVY-1431? So your proposal would be something like a task makeallmissingpoms? Well, no, I was originally thinking that re-making all poms from the ivy.xml files would be preferable, so that the output would be as consistent as possible. Basically a transitive ivy:install+ivy:makepom. So the pom files would be consistent, always canonically derived from the Ivy file, regardless of whether they came from an internal Maven repo or an internal Ivy repo. I think that it's actually quite important to not tamper with existing metadata (i.e. pom - ivy.xml - pom) Yeah, I understand that makes sense for your scenario. You're basically using ivy:install to copy artifacts between Maven repos. Hm. Yeah, it still seems a little weird, but I suppose if I was doing that, I'd want your behavior as well. ...oh. It looks like .original files in the cache are only poms for the person who originally downloaded the file from Maven. Like if I have two devs, A and B, and A installs commons-lang into our Ivy repo, his cache's .original is a pom. If B downloads commons-lang from our Ivy repo, his cache's .original is an Ivy file. So, now if B goes back and he's the one that does the ivy:install to maven task that you want, his cache's original file isn't the pom. Does this sound right? I think to make this a truly supported feature, you'd have to someone get the pom into the Ivy repo, and into every user's local Ivy cache, not just A's. Otherwise the behavior changes depending on who runs what, and that is confusing (AFAICT/IMO). - Stephen - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Review for IVY-1431?
Hi, could have anyone have a look at the patch for https://issues.apache.org/jira/browse/IVY-1431 ? It fixes a problem with publishing modules with their original artifacts (e.g. *.pom). There's even a testcase included :-) Thanks, Carsten
Antwort: Re: Review for IVY-1431?
Hi Stephen, thanks for having a look and your remarks. I think that it's actually quite important to not tamper with existing metadata (i.e. pom - ivy.xml - pom). If makepom could be instructed to recreate the original pom instead creating a similar one, that would be fine, of course. So your proposal would be something like a task makeallmissingpoms? I.e. go through a module and all its dependencies, and create a pom for every module that does not have one? Thanks, Carsten Von:Stephen Haberman stephen.haber...@gmail.com An: Ant Developers List dev@ant.apache.org Datum: 28.10.2013 16:21 Betreff:Re: Review for IVY-1431? Hi Carsten, IANAC (I am not a commiter), but I saw your patch go by and had a few thoughts. I understand that, for your from-Maven dependencies, there are .pom around already, but that seems like luck--what about other dependencies you're pulling in that didn't come from Maven? That don't have existing poms? I think a more general solution would be to have ivy:install support using the ivy:makepom functionality to systematically make POMs for your module + all of the dependencies directly from their Ivy files. Yes, this would cause round-tripping from original POM - Ivy file - derived POM, such that original POM may != derived POM, but I think conceptually this install into repo with POMs for *all* artifacts is a better feature for Ivy than install into repo with POMs for only the artifacts that happen to already have them. That said, your approach sounds great for your specific setup, but it seems like a little bit of a hack and not very general to me. - Stephen - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (Rückkehr am 18.09.2013)
Ich kehre zurück am 18.09.2013. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht Future of JDK 5 support in Ant gesendet am 18.07.2013 00:59:00. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Antwort: Re: Re: IvyDE adopter use-cases
Hi Greg, nature and container IDs should be as stable as an API, so it should not be a problem to rely on them. There's also a command org.apache.ivyde.commands.resolve, which can be parameterized with the project you to be resolved. Not sure if you can resolve a single ivy.xml (in case a project has multiple). I don't know your exact problem with ResolvedPath, but you can also specify your ivysettings.xml relative to a system property, environment variable, a project location, workspace, ... Cheers Carsten Von:Greg Amerson gregory.amer...@liferay.com An: Ant Developers List dev@ant.apache.org Datum: 03.07.2013 05:04 Betreff:Re: Re: IvyDE adopter use-cases Hey Carsten, Thanks for those pointers, that is good to consider, especially for the nature and the container. The resolveall is a bit much but would rather just resolve that single ivy.xml file. I'm sure there is a way to pass that to an existing handler so it only resolves one. But in general, me hard coding natureIds and container IDs is as brittle as calling an API, so I would prefer a real API that I could call. But until that is settled what the API should look like, this method would work. That only leaves the ResolvedPath changes. I can try to submit a patch and test project to import ResolvedPath support for parent directory relative paths. On Tue, Jul 2, 2013 at 11:09 PM, carsten.pfeif...@gebit.de wrote: Hi Greg, most of what you do with the IvyDE API can be done without the IvyDE API. 1. You can easily add the nature by using IProject.setDescription() and providing the Ivy nature ID as a string. 2. You can add the Ivy classpath container to a project's classpath with JavaCore.newContainerEntry( org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER) and adding that via IProject.setRawClasspath(). Adding your specific options of the container is a little problematic though, I agree. You would have to add all those in the right syntax to the container string. 3. You can invoke the resolving e.g. by calling ICommandService. getCommand(org.apache.ivyde.commands.resolveall) and invoking the execute() method on the command's handler. Cheers Carsten Von:Greg Amerson gregory.amer...@liferay.com An: Ant Developers List dev@ant.apache.org Datum: 02.07.2013 16:24 Betreff:Re: IvyDE adopter use-cases Hey Nicolas, Answers inline: On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée nicolas.lale...@hibnet.orgwrote: Hi Greg, Le 2 juil. 2013 à 12:16, Greg Amerson gregory.amer...@liferay.com a écrit : Hello IvyDE developers, My name is Greg Amerson and I am the project lead for Liferay IDE, which is a set of Eclipse plugins for Liferay development. In an upcoming version of Liferay Portal, we have integrated the use of Ivy dependency management for plugin projects, e.g. liferay plugins (fancy j2ee web projects) that are built using JSF portlets now use Ivy to manage jsf dependencies. Therefore in Liferay IDE when our users create Liferay plugin projects, we want users to be able to take advantage of the good support in IvyDE for dependency management, namely the Ivy classpath container. So for new Liferay projects that are created by our New Liferay Project wizard in our plugins, I want to go ahead and automatically configure that project to have all the IvyDE goodness, (nature, container, pre-resolve the container, deployment assembly configuration). In order to test things out I forked the latest trunk on git hub and imported it into my Eclipse SDK dev environment. I then went and built a POC for integration of Liferay plugin projects enhanced with IvyDE settings. During this process I noticed that for our use-cases it seems it will require a few change to IvyDE to support what we want to do: 1. MANIFEST.MF on the eclipse plugin bundle to export all packages (so they can be called from 3rd-party plugins like ours) The API of IvyDE was never properly maintained. Adding new features or fixing bugs often involved changing/adding/removing some classes or methods. I fear that if you rely blindly on the IvyDE API, we may break your plugin in the long run. Maybe with your input we can start building a real API. Only the useful package would be exposed. Only the useful classes. And then we will make sure that IvyDE won't break the API of these classes. We could start with the list of classes of IvyDE you are actually using. That makes total sense. However, I feel that you should follow the same pattern as Eclipse team itself. Put an API division between API and internal classes by putting internal in package path, but still you can export everything. Because in many cases you can't fully know how adopters will use the plugin and you wouldn't want to prohibit the use of it out of the box just because the
Configuring the Ivy classpath container (was: IvyDE adopter use-cases)
Hi Greg,
the configuration of the Ivy classpath container is indeed the only
problematic thing here.
You would have to ask the Ivy developers (I'm just a mere user) whether
these options
are considered stable. It's also a bit ugly to handcraft the string with
these options.
Also maintenance of the ivy classpath container settings is a little
uncomfortable. Adjusting
the container settings for a few projects is not a problem, but if you
have hundreds of them,
you have to searchreplace the query-style options with regular
expressions in all .classpath files
and then hope that all the resulting options are still valid.
Maybe it would be easier to have some kind of ivy.xml.properties file or
something similar that can be
specified as the only option for an ivy classpath container. The
properties file would contain the options
that are currently specified in the .classpath file itself. This would
even allow sharing of the properties
among multiple projects.
Cheers
Carsten
Von:Greg Amerson gregory.amer...@liferay.com
An: Ant Developers List dev@ant.apache.org
Datum: 03.07.2013 10:20
Betreff:Re: Re: Re: IvyDE adopter use-cases
Hey Carsten,
On Wed, Jul 3, 2013 at 3:53 PM, carsten.pfeif...@gebit.de wrote:
Hi Greg,
nature and container IDs should be as stable as an API, so it should not
be a problem to rely on them.
Sure I can use them just as IDs. If they changed it would be hard to use
them for existing projects :).
What about the variables query-style options that are used in the
container
path ? Can those be considered API as well? So I could avoid using the
Configuration object as API?
There's also a command org.apache.ivyde.commands.resolve, which can be
parameterized with the
project you to be resolved. Not sure if you can resolve a single ivy.xml
(in case a project has multiple).
Resolving a single project is just fine, that is exactly the use-case I'm
using, when creating a new project.
I don't know your exact problem with ResolvedPath, but you can also
specify your ivysettings.xml
relative to a system property, environment variable, a project location,
workspace, ...
So in my case I need to use a path that is relative to the project
location, but its relative as in two parent directories higher. So I need
something like this ${project_loc}/../../ivy-settings.xml But this
doesn't
seem to work right now. I'm looking into implementing my own ${sdk_dir}
that would map to the correct parent directory and maybe the relative path
support wouldn't be required in ResolvedPath. I'll let you know.
Cheers
Carsten
Von:Greg Amerson gregory.amer...@liferay.com
An: Ant Developers List dev@ant.apache.org
Datum: 03.07.2013 05:04
Betreff:Re: Re: IvyDE adopter use-cases
Hey Carsten,
Thanks for those pointers, that is good to consider, especially for the
nature and the container. The resolveall is a bit much but would rather
just resolve that single ivy.xml file. I'm sure there is a way to pass
that to an existing handler so it only resolves one.
But in general, me hard coding natureIds and container IDs is as brittle
as
calling an API, so I would prefer a real API that I could call. But
until
that is settled what the API should look like, this method would work.
That only leaves the ResolvedPath changes. I can try to submit a patch
and
test project to import ResolvedPath support for parent directory
relative
paths.
On Tue, Jul 2, 2013 at 11:09 PM, carsten.pfeif...@gebit.de wrote:
Hi Greg,
most of what you do with the IvyDE API can be done without the IvyDE
API.
1. You can easily add the nature by using IProject.setDescription()
and
providing the Ivy nature ID as a string.
2. You can add the Ivy classpath container to a project's classpath
with
JavaCore.newContainerEntry(
org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER)
and adding that via IProject.setRawClasspath(). Adding your
specific
options of the container is a little
problematic though, I agree. You would have to add all those in
the
right syntax to the container string.
3. You can invoke the resolving e.g. by calling ICommandService.
getCommand(org.apache.ivyde.commands.resolveall)
and invoking the execute() method on the command's handler.
Cheers
Carsten
Von:Greg Amerson gregory.amer...@liferay.com
An: Ant Developers List dev@ant.apache.org
Datum: 02.07.2013 16:24
Betreff:Re: IvyDE adopter use-cases
Hey Nicolas,
Answers inline:
On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
nicolas.lale...@hibnet.orgwrote:
Hi Greg,
Le 2 juil. 2013 à 12:16, Greg Amerson gregory.amer...@liferay.com
a
écrit :
Hello IvyDE developers,
My name is Greg Amerson and I am the project lead for Liferay IDE,
which
is
a set of Eclipse plugins for Liferay development. In an upcoming
version
of Liferay
Antwort: Re: IvyDE adopter use-cases
Hi Greg, most of what you do with the IvyDE API can be done without the IvyDE API. 1. You can easily add the nature by using IProject.setDescription() and providing the Ivy nature ID as a string. 2. You can add the Ivy classpath container to a project's classpath with JavaCore.newContainerEntry( org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER) and adding that via IProject.setRawClasspath(). Adding your specific options of the container is a little problematic though, I agree. You would have to add all those in the right syntax to the container string. 3. You can invoke the resolving e.g. by calling ICommandService. getCommand(org.apache.ivyde.commands.resolveall) and invoking the execute() method on the command's handler. Cheers Carsten Von:Greg Amerson gregory.amer...@liferay.com An: Ant Developers List dev@ant.apache.org Datum: 02.07.2013 16:24 Betreff:Re: IvyDE adopter use-cases Hey Nicolas, Answers inline: On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée nicolas.lale...@hibnet.orgwrote: Hi Greg, Le 2 juil. 2013 à 12:16, Greg Amerson gregory.amer...@liferay.com a écrit : Hello IvyDE developers, My name is Greg Amerson and I am the project lead for Liferay IDE, which is a set of Eclipse plugins for Liferay development. In an upcoming version of Liferay Portal, we have integrated the use of Ivy dependency management for plugin projects, e.g. liferay plugins (fancy j2ee web projects) that are built using JSF portlets now use Ivy to manage jsf dependencies. Therefore in Liferay IDE when our users create Liferay plugin projects, we want users to be able to take advantage of the good support in IvyDE for dependency management, namely the Ivy classpath container. So for new Liferay projects that are created by our New Liferay Project wizard in our plugins, I want to go ahead and automatically configure that project to have all the IvyDE goodness, (nature, container, pre-resolve the container, deployment assembly configuration). In order to test things out I forked the latest trunk on git hub and imported it into my Eclipse SDK dev environment. I then went and built a POC for integration of Liferay plugin projects enhanced with IvyDE settings. During this process I noticed that for our use-cases it seems it will require a few change to IvyDE to support what we want to do: 1. MANIFEST.MF on the eclipse plugin bundle to export all packages (so they can be called from 3rd-party plugins like ours) The API of IvyDE was never properly maintained. Adding new features or fixing bugs often involved changing/adding/removing some classes or methods. I fear that if you rely blindly on the IvyDE API, we may break your plugin in the long run. Maybe with your input we can start building a real API. Only the useful package would be exposed. Only the useful classes. And then we will make sure that IvyDE won't break the API of these classes. We could start with the list of classes of IvyDE you are actually using. That makes total sense. However, I feel that you should follow the same pattern as Eclipse team itself. Put an API division between API and internal classes by putting internal in package path, but still you can export everything. Because in many cases you can't fully know how adopters will use the plugin and you wouldn't want to prohibit the use of it out of the box just because the packages were exported people end up having to fork the project just to use it for a specific release. If all packages were exported but some marked internal then those programmers will have already been warned by eclipse and if they choose to ignore it, it is on them if the API breaks in the future. This way we can have best of both worlds. :) But regardless, currently in my first integration attempt I'm using the following classes: org.apache.ivyde.eclipse.IvyNature org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup; org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer; org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter; org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration; org.apache.ivyde.eclipse.cpcontainer.SettingsSetup; org.apache.ivyde.eclipse.retrieve.RetrieveSetup; Here is the code where you can see I'm calling the ivy classes: https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300 Right now that code is all messy and just a POC. But you can see that I'm doing 3 things: -adding ivy nature -adding ivy classpath container -running resolve on classpath container 2. Improved support in ResolvedPath.java class to support relative paths that use the ../ parent path. The problem with relative paths is that they got messed up while being used within the java launcher.
AUTO: Carsten Pfeiffer ist außer Haus (Rückkehr am 01.07.2013)
Ich kehre zurück am 01.07.2013. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht Bug report for Ant [2013/06/09] gesendet am 09.06.2013 09:15:01. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (Rückkehr am 13.05.2013)
Ich kehre zurück am 13.05.2013. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht Re: Evaluating Bintray as a distribution platform for easyant plugins gesendet am 09.05.2013 17:33:52. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 25.03.2013)
I am out of the office until 25.03.2013. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Note: This is an automated response to your message [RESULT][VOTE] Michael Clarke as a committer sent on 21.03.2013 01:04:24. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AUTO: Carsten Pfeiffer ist außer Haus (returning 07.01.2013)
I am out of the office until 07.01.2013. In dringenden Fällen, kontaktieren Sie bitte ErwinpunktTrataratgebitpunktde oder TompunktKraussatgebitpunktde. Note: This is an automated response to your message Bug report for Ant [2012/12/23] sent on 23.12.2012 08:15:01. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Some small patches for IvyDE
Hi Nicolas,
thanks for the quick response. I would indeed be interested in the reason
for having the project name in the
classpath container configuration. I don't know any other classpath
container that does that.
AFAICS, there is a single place where the project is read from the
container path, and that is the second
constructor of IvyClasspathContainerConfiguration:
public IvyClasspathContainerConfiguration(IJavaProject javaProject,
IPath path,
boolean editing, IClasspathAttribute[] attributes) {
this.javaProject = javaProject;
IvyClasspathContainerConfAdapter.load(this, path, attributes);
}
So exactly before the project is read from the container via load(), the
project is already set.
Best wishes
Carsten
From:
Nicolas Lalevée nicolas.lale...@hibnet.org
To:
Ant Developers List dev@ant.apache.org,
Date:
08.11.2012 23:01
Subject:
Re: Some small patches for IvyDE
Le 8 nov. 2012 à 22:32, carsten.pfeif...@gebit.de a écrit :
Hi,
I'm evaluating the use of Ivy and IvyDE and found some small problems
that
I would like to get addressed.
I already submitted Jira tickets with attachments to them, but I'm not
sure they will get any attention without
a default assignee. So that's why I'm here :-)
There is no assignee so that there no particular committer which need to
process them, any committer can be involved. And every committer is
supposed to have subscribed to ant-notification mailing list, so everybody
gets it. But not every committer knows about IvyDE internals or even
features.
But you did good coming here ping us since we are not particularly
responsive :)
The issues are
1) IVYDE-326 Support for variables in the retrieve pattern
2) IVYDE-328 Do not save the project name in the classpath container
configuration
and (much less important) 3) IVYDE-327 Problem when exporting the
eclipse-plugins (compiler target 1.2)
Any feedback would be greatly appreciated.
And thank you Carsten for your patches. They did get my attention.
Particularly IVYDE-328 which I know I will refuse but I need to find again
the reason why I did it. There was some messing up in the JDT, the source
attachment and the Java launching. And I would need to document it so I
won't have hard time remember why I did this :)
I'll process then soon.
cheers,
Nicolas
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Some small patches for IvyDE
Hi, I'm evaluating the use of Ivy and IvyDE and found some small problems that I would like to get addressed. I already submitted Jira tickets with attachments to them, but I'm not sure they will get any attention without a default assignee. So that's why I'm here :-) The issues are 1) IVYDE-326 Support for variables in the retrieve pattern 2) IVYDE-328 Do not save the project name in the classpath container configuration and (much less important) 3) IVYDE-327 Problem when exporting the eclipse-plugins (compiler target 1.2) Any feedback would be greatly appreciated. Thanks, Carsten
