Re: [VOTE] Stephen Haberman as a committer

[Charles Duffy]

+1

On Mon, Oct 5, 2015, 4:06 AM Conor MacNeill  wrote:

> I would like to nominate Stephen Haberman as a committer. Stephen has
> submitted a number of well tested patches to the Ivy codebase. I
> believe adding Stephen would strengthen the committer-base,
> particularly for the Ivy Sub-project.
>
> Please vote
>
> [ ] +1 Add Stephen as a committer
> [ ] -1 Disagree
> [ ] +0 - Don't care.
>
> I will start proceedings with my +1
>
> Thanks
> Conor
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Roadmap, goals, future of Ivy?

[Charles Duffy]

One thing to note -- the bar for being admitted as a maintainer, and thus
having the opportunity to help guide the project's future yourself, is by
no means unattainable.

I was offered the opportunity after about 2-3 reasonable-quality patches,
if memory serves; unfortunately, I shortly thereafter changed jobs to an
employer not using Ivy, and thus no longer have the ability to contribute
on company time.

If you're interested in helping to revive the project -- I can't personally
extend the opportunity on my own, but if you continue to offer patches at
the same quality as your recent work, you'll have my +1 when it comes to a
vote. :)

On Sat, Aug 22, 2015 at 11:27 AM Jaikiran Pai 
wrote:

> The past few weeks I've been trying to contribute by fixing some issues
> that have been noted in JIRA. I've opened a pull request with a fix a
> while back[1] and also have asked a few questions about some other
> issues that I am thinking to work on. However, there has been no
> response, neither to the pull request nor to the question.
>
> Is there any public roadmap, goals and future plans for the Ivy project?
> I would like to continue contributing, but if there's no real plans to
> continue development in the project, then I would just end up wasting my
> time.
>
> [1] https://github.com/apache/ant-ivy/pull/7
>
> -Jaikiran
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Contributing to apache ant

[Charles Duffy]

Lahiru --

Welcome!

I can't speak for all of the project, but there are certainly plenty of
opportunities for improvement available. I'd suggest looking through our
bug tracker for anything that looks interesting to you.

See the links at http://ant.apache.org/bugs.html, both to list of bugs by
priority and list of bugs by number of votes.

If nothing there strikes your interest, there are subprojects that have
plenty to do as well, and may in some cases have bugs tracked elsewhere;
see for instance https://issues.apache.org/jira/browse/IVY for the Ivy
subproject.

Thank you for your interest in helping to improve Ant!


On Thu, Jul 17, 2014 at 1:18 PM, Lahiru Ranasinghe 
wrote:

> Hi All,
>
> I'm a level 4 software engineering student. I would like to contribute to
> apache ant i'm new to open source community. Is there any opportunity
> available?
>
> Thank you.
>
> --
> Best Regards,
>
> *Lahiru Ranasinghe*
>
> *Email : lahiru0...@gmail.com *Please consider the
> environment before printing this e-mail !
>

Re: migration to git : next steps

[Charles Duffy]

I'd suggest looking into git-subtree as well, if we wanted to maintain a
single-development-tree experience. Submodules have a reputation
(well-deserved, IMHO) of being somewhat unwieldy to work with; using
git-subtree to manage linked trees can be a bit more automation/setup work,
but can also provide a much smoother user experience.


On Mon, May 12, 2014 at 8:03 PM, Matt Sicker  wrote:

> Something I've been experimenting with is using git submodules. You
> basically have a repository for each "submodule", then you can have another
> repository that groups them all together for convenience. It's handy for
> making a sort of stable master that points to the latest tag or something
> similar. It's kind of confusing, but I think it works well for when people
> want to check out a project corresponding to the latest stable rather than
> the trunk (which would normally be stable anyway).
>
>
> On 12 May 2014 21:19, Antoine Levy Lambert  wrote:
>
> >
> > Hi,
> >
> > resending a message which I sent on May 7th but might have been lost
> > completely due to our infrastructure problems last week :
> >
> > >
> > >
> > > To actually migrate to git, we could either make one INFRA JIRA for all
> > the ant family of projects, or do this one step at a time.
> > >
> > > Concerning the antlibs, I suppose we want one git module for each
> antlib
> > - we have 6 of them (antunit, compress, dotnet, props, svn, vss) plus a
> > common folder which ought to be on its own.
> > >
> > > If we do it one step at a time we could start with ant proper, then
> move
> > to ivy, ivyde, easyant and the antlibs.
> > >
> > > What do you think ?
> > >
> > > Antoine
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
>
>
> --
> Matt Sicker 
>

Re: Classloading issue

[Charles Duffy]

I was thinking of doing a runtime type check on the exception returned
(grabbing an instance of the class via introspection, to avoid a
classload-time dependency) and reraising anything unexpected wrapped in a
RuntimeException; otherwise, that's pretty much exactly the way I would
have fixed the issue.


On Tue, May 13, 2014 at 11:55 AM, Nicolas Lalevée <
nicolas.lale...@hibnet.org> wrote:

> r1594279 seems to fix the issue, but I still don't understand why.
> Any suggestion of a better fix is welcomed.
>
> Nicolas
>
> Le 11 mai 2014 à 23:41, Nicolas Lalevée  a
> écrit :
>
> > Hi,
> >
> > I need some help to understand a bug around classloading (nothing that
> particular to Ivy).
> >
> > I was looking into IVY-1471 [1] and I don't understand why it is failing
> that way. In the classpath there are both Ivy and Jsch, but not the
> optional jar related to managing the ssh agent via jsch. And it is failing
> because a class in that optional jar is not found. But I don't understand
> why the classloader is looking for it in the first place.
> >
> > The error is raised is AbstractSshBasedRepository, on the call of
> SshCache.getInstance() [2]. But as far as I can tell, nothing in the
> loading of the SshCache [3] class requires AgentProxyException. The class
> is only needed by the function SshCache#attemptAgentUse() [4], which will
> be called at runtime, if the end user actually want ssh agent support, in
> which case it would naturally fail. But here it fails very earlier.
> >
> > I have made a test case you can test with its build.xml, no IvyDE
> required there [5].
> >
> > Am I missing something ? Is there a special treatment for the loading of
> Exception classes ?
> >
> > Nicolas
> >
> > [1] https://issues.apache.org/jira/browse/IVY-1471
> > [2]
> https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/AbstractSshBasedRepository.java?hb=true#to108
> > [3]
> https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true
> > [4]
> https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true#to300
> > [5]
> http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/ssh-resolver/
> >
> >
> > -
> > 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: [VOTE] migration to git

[Charles Duffy]

+1 for Ant and Ivy, +0 elsewhere.

If we wanted to do a history-preserving transform (with branches, merges
&c. faithfully preserved), I'd be happy to help with the configuration and
use of SubGit (which, while typically a commercially-licensed tool, has
zero-cost licenses available for OSS projects) for this purpose; in my
experience, it results in a considerably higher-quality transform than the
competing git-svn tooling. (SubGit also offers bidirectional translation
support, but I'm wary of the deployment requirements of same, and have
concerns as to whether making proprietary tooling a dependency of Apache's
ongoing infrastructure would be acceptable or wise).


On Sun, Apr 27, 2014 at 10:02 PM, Antoine Levy Lambert wrote:

> Hi,
>
> Let's vote about migrating to git :
>
> -  Ant
>
> - Ivy
>
> - easyant
>
> - Ivyde
>
> - the antlibs
>
> I am not including the sandbox in the thread intentionally.
>
> The web sites will remain in svn in any event because svnpubsub is the
> only supported mechanism to maintain web sites AFAIK.
>
> [] Yes
> [] No
>
>
> Let me start with my +1
>
> Antoine
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: svn commit: r1553704 - /ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java

[Charles Duffy]

The amount of "fun" otherwise involved when two separate threads called
into Ivy code in parallel was considerable, and was regularly resulting in
a logger stack with no relationship with any individual thread's call stack.
On Mar 25, 2014 7:27 AM, "Maarten Coene"  wrote:

> Maybe a bit late, but what was the reason to use a ThreadLocal here?
> This gives issues when the configuration of Ivy (for instance setting a
> custom logger) is done from a different thread than the actual resolve.
>
> Maarten
>
>
>
> 
>  Van: "cdu...@apache.org" 
> Aan: notificati...@ant.apache.org
> Verzonden: vrijdag 27 december 18:40 2013
> Onderwerp: svn commit: r1553704 -
> /ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
>
>
> Author: cduffy
> Date: Fri Dec 27 17:40:20 2013
> New Revision: 1553704
>
> URL: http://svn.apache.org/r1553704
> Log:
> Move non-root MessageLogger instances into a thread-local stack
>
> Logger context is inherently thread-local.
>
> Modified:
>
> ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
>
> Modified:
> ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java?rev=1553704&r1=1553703&r2=1553704&view=diff
>
> ==
> ---
> ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
> (original)
> +++
> ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
> Fri Dec 27 17:40:20 2013
> @@ -34,7 +34,7 @@ import java.util.Stack;
>   * 
>   */
> public class MessageLoggerEngine implements MessageLogger {
> -private final Stack/**/ loggerStack = new Stack();
> +private final ThreadLocal/*>*/ loggerStacks =
> new ThreadLocal();
>
>  private MessageLogger defaultLogger = null;
>
> @@ -44,6 +44,15 @@ public class MessageLoggerEngine impleme
>
>  private List errors = new ArrayList();
>
> +private Stack getLoggerStack() {
> +Stack stack = (Stack) loggerStacks.get();
> +if (stack == null) {
> +stack = new Stack();
> +loggerStacks.set(stack);
> +}
> +return stack;
> +}
> +
>  public MessageLoggerEngine() {
>  }
>
> @@ -66,7 +75,7 @@ public class MessageLoggerEngine impleme
>   */
>  public void pushLogger(MessageLogger logger) {
>  Checks.checkNotNull(logger, "logger");
> -loggerStack.push(logger);
> +getLoggerStack().push(logger);
>  }
>
>  /**
> @@ -76,8 +85,8 @@ public class MessageLoggerEngine impleme
>   * 
>   */
>  public void popLogger() {
> -if (!loggerStack.isEmpty()) {
> -loggerStack.pop();
> +if (!getLoggerStack().isEmpty()) {
> +getLoggerStack().pop();
>  }
>  }
>
> @@ -86,10 +95,10 @@ public class MessageLoggerEngine impleme
>   * @return the current logger, or the default one if there is no
> logger in the stack
>   */
>  public MessageLogger peekLogger() {
> -if (loggerStack.isEmpty()) {
> +if (getLoggerStack().isEmpty()) {
>  return getDefaultLogger();
>  }
> -return (MessageLogger) loggerStack.peek();
> +return (MessageLogger) getLoggerStack().peek();
>  }
>
>  private MessageLogger getDefaultLogger() {
> @@ -130,7 +139,7 @@ public class MessageLoggerEngine impleme
>
>  public void clearProblems() {
>  getDefaultLogger().clearProblems();
> -for (Iterator iter = loggerStack.iterator(); iter.hasNext();) {
> +for (Iterator iter = getLoggerStack().iterator();
> iter.hasNext();) {
>  MessageLogger l = (MessageLogger) iter.next();
>  l.clearProblems();
>  }
> @@ -142,7 +151,7 @@ public class MessageLoggerEngine impleme
>  public void setShowProgress(boolean progress) {
>  getDefaultLogger().setShowProgress(progress);
>  // updates all loggers in the stack
> -for (Iterator iter = loggerStack.iterator(); iter.hasNext();) {
> +for (Iterator iter = getLoggerStack().iterator();
> iter.hasNext();) {
>  MessageLogger l = (MessageLogger) iter.next();
>  l.setShowProgress(progress);
>  }

Re: [VOTE] Apache Ivy 2.4.0-rc1 Release

[Charles Duffy]

Apologies for being late to the game here -- I asked my former employer
(who sponsored some work for this release) if they were interested in
providing feedback, and was deferring a response to allow them an
opportunity to chime in.

+1


On Sat, Mar 15, 2014 at 5:17 PM, Maarten Coene wrote:

> Hi all,
>
> I have built Apache Ivy 2.4.0-rc1.
>
> Here are the links:
> SVN tag: https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.4.0-rc1/
> Binaries: https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0-rc1
> Maven repository:
> https://repository.apache.org/content/repositories/orgapacheant-1002/
>
> Do you vote for the release of these binaries?
>
> [ ] Yes
> [ ] No
>
> Kind regards,
> Maarten Coene

Re: [VOTE] Ivy 2.4.0-rc1 Release

[Charles Duffy]

If you could finish up, that would be very much appreciated. Whereas my
former employer allowed for some amount of Ivy work on business hours, such
is no longer the case, and my personal time has more demands than I'm
presently able to satisfy.

Thank you kindly, and please accept my apologies.


On Tue, Mar 4, 2014 at 8:46 PM, Antoine Levy Lambert  wrote:

> Charles,
>
> are you going to be able to finish the release ?
>
> Do you need some help ?
>
> Best regards,
>
> Antoine
> On Feb 25, 2014, at 8:18 AM, Antoine Levy Lambert  wrote:
>
> > Hi,
> >
> > I still do not see the public GPG key of Charles under
> https://dist.apache.org/repos/dist/release/ant/KEYS
> >
> > I did the following checkout to create a small sandbox with this KEYS
> file in it :
> >
> >
> >
> > svn checkout --depth=files --depth=files
> https://dist.apache.org/repos/dist/release/ant/ dist-release-ant
> >
> > Charles, let us know if you can check in your public key there.
> >
> >
> >
> > Antoine
> >
> >
> >
> > On Feb 15, 2014, at 9:23 AM, Nicolas Lalevée 
> wrote:
> >
> >> Note that the release if not accepted yet, it cannot be published.
> >>
> >> Nicolas
> >>
> >> Le 14 févr. 2014 à 14:55, Charles Duffy  a écrit :
> >>
> >>> Apologies -- new job; I dropped the ball somewhat. I'll try to get
> things
> >>> back on track this weekend.
> >>>
> >>>
> >>> On Fri, Feb 14, 2014 at 1:58 AM, Jean-Louis Boudart <
> >>> jeanlouis.boud...@gmail.com> wrote:
> >>>
> >>>> Is the release over ?
> >>>>
> >>>> I dont find it on maven central
> >>>> Le 28 janv. 2014 01:46, "Charles Duffy"  a écrit :
> >>>>
> >>>>> The keys are actually different -- the one used by the
> currently-posted
> >>>>> .asc files is associated with Indeed, Inc. I'll be resigning the
> binaries
> >>>>> after verifying that their Indeed signatures are intact (and moving
> them
> >>>> to
> >>>>> dist.apache.org at that time).
> >>>>>
> >>>>> Expect a note in this thread when that happens.
> >>>>>
> >>>>>
> >>>>> On Mon, Jan 27, 2014 at 6:42 PM, Nicolas Lalevée <
> >>>>> nicolas.lale...@hibnet.org
> >>>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> Le 22 janv. 2014 à 00:52, Nicolas Lalevée <
> nicolas.lale...@hibnet.org>
> >>>> a
> >>>>>> écrit :
> >>>>>>
> >>>>>>> I have found some issues. The source distribution seems to miss
> some
> >>>>>> test files. I guess this has been the case for quite some time. And
> it
> >>>> is
> >>>>>> "just" about the tests. And it is an RC. So OK for me. And I will
> fix
> >>>>> that
> >>>>>> soon in trunk.
> >>>>>>>
> >>>>>>> To avoid confusion and make things simpler, I suggest we modify the
> >>>>>> release process to that everything goes through the svn of
> >>>>> dist.apache.org,
> >>>>>> and not use anymore people.apache.org. In the end, everything is
> >>>>>> published there.
> >>>>>>> And I'll modify in the doc of the release process the template of
> the
> >>>>>> email of the vote to include a line that is referencing the svn
> tag. So
> >>>>>> it's more difficult to miss it, and it is helpful to do review.
> >>>>>>>
> >>>>>>> I have tested the staging update site: works like a charm.
> >>>>>>>
> >>>>>>> So LGTM.
> >>>>>>>
> >>>>>>> I will cast my vote as soon as I can verify the signature of the
> >>>>>> artifacts.
> >>>>>>
> >>>>>> You pushed some keys to the KEYS files, but it doesn't seems to be
> the
> >>>>>> same as the one you used to sign the proposed artifacts.
> >>>>>>
> >>>>>> My gpg is asking for the key ID 93FB868A. Did I do something wrong
> or
> >>>> the
> >>>>>> keys are actually different ?
> >>>>>>
>

Re: Adding resolver

[Charles Duffy]

Sounds good to me!

I'd be happy to review this patch, but be aware that my involvement may be
a bit deferred -- I recently changed jobs and am in the middle of a move
(from Austin to Chicago); this is holding up some other obligations I have
to the Ivy project as well (around getting a 2.4.0 release out the door).


On Mon, Mar 3, 2014 at 7:58 AM, JBaruch  wrote:

> Hi folks,
>
> I'd like to contribute  resolver to Ivy - similar to ,
> but resolving from Bintray's JCenter instead of Maven Central.
>
> JCenter is a superset of Maven Central and should ease the configuration
> for obtaining artifacts which aren't present in ibiblio (as they will
> probably be found in JCenter).
>
> Groovy's Grape has JCenter as the first resolver in chain for that exact
> reason.
>
> The users will be given a simple way to add jcenter resolver (like they
> have today in Gradle by adding jcenter() to repositories).
>
> I believe it should be an easy task and will be glad to do it.
>
> What do you think?
>
>
> Baruch.
>
> --
> JFrog Developer Advocate
> www.jfrog.com
> +972544954353
> @jbaruch 
> http://linkd.in/jbaruch
>

Re: [VOTE] Ivy 2.4.0-rc1 Release

[Charles Duffy]

Apologies -- new job; I dropped the ball somewhat. I'll try to get things
back on track this weekend.


On Fri, Feb 14, 2014 at 1:58 AM, Jean-Louis Boudart <
jeanlouis.boud...@gmail.com> wrote:

> Is the release over ?
>
> I dont find it on maven central
> Le 28 janv. 2014 01:46, "Charles Duffy"  a écrit :
>
> > The keys are actually different -- the one used by the currently-posted
> > .asc files is associated with Indeed, Inc. I'll be resigning the binaries
> > after verifying that their Indeed signatures are intact (and moving them
> to
> > dist.apache.org at that time).
> >
> > Expect a note in this thread when that happens.
> >
> >
> > On Mon, Jan 27, 2014 at 6:42 PM, Nicolas Lalevée <
> > nicolas.lale...@hibnet.org
> > > wrote:
> >
> > >
> > > Le 22 janv. 2014 à 00:52, Nicolas Lalevée 
> a
> > > écrit :
> > >
> > > > I have found some issues. The source distribution seems to miss some
> > > test files. I guess this has been the case for quite some time. And it
> is
> > > "just" about the tests. And it is an RC. So OK for me. And I will fix
> > that
> > > soon in trunk.
> > > >
> > > > To avoid confusion and make things simpler, I suggest we modify the
> > > release process to that everything goes through the svn of
> > dist.apache.org,
> > > and not use anymore people.apache.org. In the end, everything is
> > > published there.
> > > > And I'll modify in the doc of the release process the template of the
> > > email of the vote to include a line that is referencing the svn tag. So
> > > it's more difficult to miss it, and it is helpful to do review.
> > > >
> > > > I have tested the staging update site: works like a charm.
> > > >
> > > > So LGTM.
> > > >
> > > > I will cast my vote as soon as I can verify the signature of the
> > > artifacts.
> > >
> > > You pushed some keys to the KEYS files, but it doesn't seems to be the
> > > same as the one you used to sign the proposed artifacts.
> > >
> > > My gpg is asking for the key ID 93FB868A. Did I do something wrong or
> the
> > > keys are actually different ?
> > >
> > > Nicolas
> > >
> > >
> > > >
> > > > Nicolas
> > > >
> > > > Le 21 janv. 2014 à 17:19, Charles Duffy  a écrit
> :
> > > >
> > > >> FYI --
> > > >>
> > > >> A tag at
> > https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.4.0-rc1now
> > > >> exists. This differs from the branch head from which the binaries
> for
> > > test
> > > >> were built only inasmuch as its svn:externals specify a specific
> > > revision
> > > >> of the documentation build tools rather than leaving their revision
> > > >> floating.
> > > >>
> > > >>
> > > >> On Tue, Jan 21, 2014 at 6:54 AM, Charles Duffy 
> > > wrote:
> > > >>
> > > >>> Howdy --
> > > >>>
> > > >>> I've attempted to follow the documentation at
> > > >>> http://ant.apache.org/ivy/history/trunk/dev/makerelease.html and
> > > >>>
> http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html(as
> > > >>> included-by-reference in the former) in preparing the above. That
> > > said, it
> > > >>> appears that I missed step 12 (and, accordingly, have a 1.4.0-rc1
> > > branch,
> > > >>> from the present tip of which the binaries were built, but no
> > > associated
> > > >>> tag).
> > > >>>
> > > >>> I'll be sure to get KEYS up-to-date. Thank you for the pointers.
> > > >>>
> > > >>>
> > > >>> On Tue, Jan 21, 2014 at 6:26 AM, Stefan Bodewig <
> bode...@apache.org
> > > >wrote:
> > > >>>
> > > >>>> Hi Charles,
> > > >>>>
> > > >>>> we don't really release binaries, they are just a convenience.
>  All
> > > that
> > > >>>> matters as a release is the sources.
> > > >>>>
> > > >>>> I'm not sure there is anything documenting the release process for
> > Ivy
> > > >>>> but in general you create an svn tag and buil

Re: [VOTE] Ivy 2.4.0-rc1 Release

[Charles Duffy]

The keys are actually different -- the one used by the currently-posted
.asc files is associated with Indeed, Inc. I'll be resigning the binaries
after verifying that their Indeed signatures are intact (and moving them to
dist.apache.org at that time).

Expect a note in this thread when that happens.


On Mon, Jan 27, 2014 at 6:42 PM, Nicolas Lalevée  wrote:

>
> Le 22 janv. 2014 à 00:52, Nicolas Lalevée  a
> écrit :
>
> > I have found some issues. The source distribution seems to miss some
> test files. I guess this has been the case for quite some time. And it is
> "just" about the tests. And it is an RC. So OK for me. And I will fix that
> soon in trunk.
> >
> > To avoid confusion and make things simpler, I suggest we modify the
> release process to that everything goes through the svn of dist.apache.org,
> and not use anymore people.apache.org. In the end, everything is
> published there.
> > And I'll modify in the doc of the release process the template of the
> email of the vote to include a line that is referencing the svn tag. So
> it's more difficult to miss it, and it is helpful to do review.
> >
> > I have tested the staging update site: works like a charm.
> >
> > So LGTM.
> >
> > I will cast my vote as soon as I can verify the signature of the
> artifacts.
>
> You pushed some keys to the KEYS files, but it doesn't seems to be the
> same as the one you used to sign the proposed artifacts.
>
> My gpg is asking for the key ID 93FB868A. Did I do something wrong or the
> keys are actually different ?
>
> Nicolas
>
>
> >
> > Nicolas
> >
> > Le 21 janv. 2014 à 17:19, Charles Duffy  a écrit :
> >
> >> FYI --
> >>
> >> A tag at https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.4.0-rc1now
> >> exists. This differs from the branch head from which the binaries for
> test
> >> were built only inasmuch as its svn:externals specify a specific
> revision
> >> of the documentation build tools rather than leaving their revision
> >> floating.
> >>
> >>
> >> On Tue, Jan 21, 2014 at 6:54 AM, Charles Duffy 
> wrote:
> >>
> >>> Howdy --
> >>>
> >>> I've attempted to follow the documentation at
> >>> http://ant.apache.org/ivy/history/trunk/dev/makerelease.html and
> >>> http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html (as
> >>> included-by-reference in the former) in preparing the above. That
> said, it
> >>> appears that I missed step 12 (and, accordingly, have a 1.4.0-rc1
> branch,
> >>> from the present tip of which the binaries were built, but no
> associated
> >>> tag).
> >>>
> >>> I'll be sure to get KEYS up-to-date. Thank you for the pointers.
> >>>
> >>>
> >>> On Tue, Jan 21, 2014 at 6:26 AM, Stefan Bodewig  >wrote:
> >>>
> >>>> Hi Charles,
> >>>>
> >>>> we don't really release binaries, they are just a convenience.  All
> that
> >>>> matters as a release is the sources.
> >>>>
> >>>> I'm not sure there is anything documenting the release process for Ivy
> >>>> but in general you create an svn tag and build source and binary
> >>>> distributions from that.
> >>>>
> >>>> What you have built now is a binary for testing and you don't really
> >>>> need to vote on that at all.  Just encourage people to try it out :-)
> >>>>
> >>>> If you want to perform some sort of test-release, have a look at
> >>>> <http://svn.apache.org/repos/asf/ant/antlibs/ReleaseInstructions> and
> >>>> similar instructions to get an idea of what is expected.
> >>>>
> >>>>> PS -- As this build was performed on hardware owned by Indeed, Inc.,
> the
> >>>>> binaries are signed with the du...@indeed.com GPG key. For any final
> >>>>> release, I would be using hardware under personal control and a key
> >>>>> associated with cdu...@apache.org.
> >>>>
> >>>> Please make sure whatever key you use is inside
> >>>> https://dist.apache.org/repos/dist/release/ant/KEYS - if you need any
> >>>> help committing it there, please yell.
> >>>>
> >>>> Cheers
> >>>>
> >>>>   Stefan
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> >>>> For additional commands, e-mail: dev-h...@ant.apache.org
> >>>>
> >>>>
> >>>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: [VOTE] Ivy 2.4.0-rc1 Release

[Charles Duffy]

FYI --

A tag at https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.4.0-rc1 now
exists. This differs from the branch head from which the binaries for test
were built only inasmuch as its svn:externals specify a specific revision
of the documentation build tools rather than leaving their revision
floating.


On Tue, Jan 21, 2014 at 6:54 AM, Charles Duffy  wrote:

> Howdy --
>
> I've attempted to follow the documentation at
> http://ant.apache.org/ivy/history/trunk/dev/makerelease.html and
> http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html (as
> included-by-reference in the former) in preparing the above. That said, it
> appears that I missed step 12 (and, accordingly, have a 1.4.0-rc1 branch,
> from the present tip of which the binaries were built, but no associated
> tag).
>
> I'll be sure to get KEYS up-to-date. Thank you for the pointers.
>
>
> On Tue, Jan 21, 2014 at 6:26 AM, Stefan Bodewig wrote:
>
>> Hi Charles,
>>
>> we don't really release binaries, they are just a convenience.  All that
>> matters as a release is the sources.
>>
>> I'm not sure there is anything documenting the release process for Ivy
>> but in general you create an svn tag and build source and binary
>> distributions from that.
>>
>> What you have built now is a binary for testing and you don't really
>> need to vote on that at all.  Just encourage people to try it out :-)
>>
>> If you want to perform some sort of test-release, have a look at
>> <http://svn.apache.org/repos/asf/ant/antlibs/ReleaseInstructions> and
>> similar instructions to get an idea of what is expected.
>>
>> > PS -- As this build was performed on hardware owned by Indeed, Inc., the
>> > binaries are signed with the du...@indeed.com GPG key. For any final
>> > release, I would be using hardware under personal control and a key
>> > associated with cdu...@apache.org.
>>
>> Please make sure whatever key you use is inside
>> https://dist.apache.org/repos/dist/release/ant/KEYS - if you need any
>> help committing it there, please yell.
>>
>> Cheers
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>

Re: [VOTE] Ivy 2.4.0-rc1 Release

[Charles Duffy]

Howdy --

I've attempted to follow the documentation at
http://ant.apache.org/ivy/history/trunk/dev/makerelease.html and
http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html (as
included-by-reference in the former) in preparing the above. That said, it
appears that I missed step 12 (and, accordingly, have a 1.4.0-rc1 branch,
from the present tip of which the binaries were built, but no associated
tag).

I'll be sure to get KEYS up-to-date. Thank you for the pointers.


On Tue, Jan 21, 2014 at 6:26 AM, Stefan Bodewig  wrote:

> Hi Charles,
>
> we don't really release binaries, they are just a convenience.  All that
> matters as a release is the sources.
>
> I'm not sure there is anything documenting the release process for Ivy
> but in general you create an svn tag and build source and binary
> distributions from that.
>
> What you have built now is a binary for testing and you don't really
> need to vote on that at all.  Just encourage people to try it out :-)
>
> If you want to perform some sort of test-release, have a look at
>  and
> similar instructions to get an idea of what is expected.
>
> > PS -- As this build was performed on hardware owned by Indeed, Inc., the
> > binaries are signed with the du...@indeed.com GPG key. For any final
> > release, I would be using hardware under personal control and a key
> > associated with cdu...@apache.org.
>
> Please make sure whatever key you use is inside
> https://dist.apache.org/repos/dist/release/ant/KEYS - if you need any
> help committing it there, please yell.
>
> Cheers
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

[VOTE] Ivy 2.4.0-rc1 Release

[Charles Duffy]

I have built a release candidate for Ivy 2.4.0.

You can download it from this URL:
http://people.apache.org/~cduffy/ivy-2.4.0-rc1/

Do you vote for the release of these binaries?

[ ] Yes
[ ] No

Regards,

Charles Duffy, Ivy 2.4.0 release manager


PS -- As this build was performed on hardware owned by Indeed, Inc., the
binaries are signed with the du...@indeed.com GPG key. For any final
release, I would be using hardware under personal control and a key
associated with cdu...@apache.org.

Proposal: Make Xooki spoof TiddlyWiki to use TiddlyFox plugin?

[Charles Duffy]

Howdy, all --

The release process for Ivy includes using Xooki to edit the documentation
before publication.

Unfortunately, the code Xooki uses for saving updated files, borrowed from
an early TiddlyWiki release, is no longer supported on modern FireFox or
Chrome -- and while HTML5 has its own filesystem API, that refers to a
sandbox cut off from the "real" visible filesystem, so HTML5 apps can't
edit files on the filesystem directly.

Older versions of TiddlyWiki use a Java plugin for filesystem access;
however, this isn't actively maintained, and when testing code that uses it
for saving from Xooki, I get a notice that future security changes are
going to cause breakage.

The way modern versions of TiddlyWiki are able to edit filesystem contents
consists of using the TiddlyFox plugin. The mechanism used by this plugin
to detect when it's being used to edit a TiddlyWiki document is
straightforward to duplicate -- basically, one need only identify oneself
as a TiddlyWiki in a tag in the header, and the user will be prompted to
allow write access should the plugin be correctly installed.

Any yeas/nays/alternative approaches? In preparing the Ivy 2.4.0-rc1
branch, I ended up editing HTML by hand -- but if we're going to be doing
that on an ongoing basis, we should update the process documentation to no
longer point at tools which aren't still supported.

Re: Ivy Code formatting

[Charles Duffy]

Oops!

My apologies for having forgotten this was pending when cutting the -rc1
branch. Happy to update the branch after this change is in, before tagging
and building something to formally propose for voting.


On Sun, Jan 12, 2014 at 11:14 AM, Jean-Louis Boudart <
jeanlouis.boud...@gmail.com> wrote:

> Hi there,
>
> While fixing a bug i noticed that ivy source code was not fully formatted.
> Eclipse formatter is not exported as a plain file but present through
> eclipse project preferences in .settings folder [1].
>
> Considering .settings folder is already commited i suggest to activate
> "Saved actions" to apply on each save :
>
>- code formatting
>- organize import
>
>
> I also suggest to apply formatting on whole project (could be done in a few
> clicks with cleanup feature in eclipse).
>
> Are you in favor of those code modifications ?
>
> We could take the opportunity to cut this before 2.4.0 release.
>
> PS: This could aslo applied on others subprojects (ant for example)
>
> [1]
>
> https://svn.apache.org/repos/asf/ant/ivy/core/trunk/.settings/org.eclipse.jdt.core.prefs
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://ant.apache.org/easyant/
>

Re: Ivy Code formatting

[Charles Duffy]

+1


On Sun, Jan 12, 2014 at 11:14 AM, Jean-Louis Boudart <
jeanlouis.boud...@gmail.com> wrote:

> Hi there,
>
> While fixing a bug i noticed that ivy source code was not fully formatted.
> Eclipse formatter is not exported as a plain file but present through
> eclipse project preferences in .settings folder [1].
>
> Considering .settings folder is already commited i suggest to activate
> "Saved actions" to apply on each save :
>
>- code formatting
>- organize import
>
>
> I also suggest to apply formatting on whole project (could be done in a few
> clicks with cleanup feature in eclipse).
>
> Are you in favor of those code modifications ?
>
> We could take the opportunity to cut this before 2.4.0 release.
>
> PS: This could aslo applied on others subprojects (ant for example)
>
> [1]
>
> https://svn.apache.org/repos/asf/ant/ivy/core/trunk/.settings/org.eclipse.jdt.core.prefs
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://ant.apache.org/easyant/
>

Re: Cleanup callbacks in IvyContext?

[Charles Duffy]

On Thu, Jan 9, 2014 at 12:17 PM, Nicolas Lalevée  wrote:

> Yep, a quite hard problem to resolve. At the ant task level I don't know
> how you could nail it without asking the end user to call some ivy:lock
> task.
>

I'd like to argue that for ant tasks, a default behavior of releasing locks
only on process shutdown should be adequate -- ant invocations not being
long-lived by nature.

IDE plugins alter this a bit... but then, is it really safe to delete
caches while a running IDE expects them to persist?


> I myself don't have much experience with file based lock mechanism between
> different process. For instance what happens if a process holding a lock is
> killed -9, or whatever which make the jvm not even able to trigger its
> shutdown hooks ?
>

I would only propose to support this with NIO locks in use. These are
implicitly released on file descriptor release, even when this is caused by
SIGKILL, power termination, etc.

Re: Cleanup callbacks in IvyContext?

[Charles Duffy]

Apologies about the delay before providing a full reply -- I was
unexpectedly stuck in Chicago without my laptop.

The problem with the LockStrategy interface is that it's too fine-grained
for the use case wherein a read lock needs to be held for the duration of a
high-level operation.

Consider the case where a user calls ivy:resolve, ivy:retrieve and
ivy:report in sequence. An ivy:clean run by an external process between any
of these operations would cause a failure, and would be prevented by any
proper repository-wide read-lock mechanism.

The above _does_ indicate a potential problem with the proposal I opened
this thread with -- inasmuch as it doesn't provide a way to hold locks
spanning multiple high-level operations while still putting each of those
operations in a separate IvyContext. I wonder if it might make sense to
allow a given member in the stack to indicate that it should hold locks its
children. For ant, being generally a short-lived process, it might make
sense for the parent context to be the read lock holder.

Does this clarify the issue I'm trying to solve?


On Sat, Jan 4, 2014 at 8:06 AM, Nicolas Lalevée
wrote:

>
> Le 3 janv. 2014 à 22:28, Charles Duffy  a écrit :
>
> > Howdy, all --
> >
> > I'm trying to strengthen Ivy's locking system to make it strong enough to
> > allow ivy:clean at arbitrary times on systems which can have other
> actions
> > making use of the same shared caches.
> >
> > There are a few requirements to make this happen while still allowing
> > multiple resolves (and like operations) to occur concurrently. One of
> those
> > is maintaining nonexclusive read locks (as opposed to the write locks
> which
> > are currently supported), and cleaning them up when necessary. For
> > ease-of-implementation, I'm currently proposing to only support this
> > behavior when NIO locks (which implicitly support shared locking
> semantics)
> > are enabled.
> >
> > To clean these locks up without requiring end-user code to be modified, I
> > propose using the IvyContext stack -- allowing Runnables to be attached
> to
> > a stack element, and invoking them implicitly when the stack is popped.
> >
> >
> > Because converting a read lock to a write lock is inherently prone to
> race
> > conditions, we might need to break backwards compatibility with respect
> to
> > ivy:clean, allowing this to be called only inside a context where no read
> > operations have been done -- or breaking read lock semantics by dropping
> > all read locks before grabbing the write lock.
> >
> >
> > Thoughts?
>
> My first blind though would be that IvyContext seems to be high level to
> handle locking. Couldn't it be done by improving the LockStrategy interface
> so that it also handles read locks ?
>
> Nicolas
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Cleanup callbacks in IvyContext?

[Charles Duffy]

This is part of why I wouldn't give it knowledge of locks specifically, but
simply Runnable callbacks to invoke on pop -- not specifically tied to a
single use case. This is not entirely unlike atExit calls available through
the JVM, the standard C library, etc.

Improving LockStrategy is a necessary component, to be sure -- but
something needs to tell it when a read lock is needed, and likewise when
its need is past.
On Jan 4, 2014 8:07 AM, "Nicolas Lalevée" 
wrote:

>
> Le 3 janv. 2014 à 22:28, Charles Duffy  a écrit :
>
> > Howdy, all --
> >
> > I'm trying to strengthen Ivy's locking system to make it strong enough to
> > allow ivy:clean at arbitrary times on systems which can have other
> actions
> > making use of the same shared caches.
> >
> > There are a few requirements to make this happen while still allowing
> > multiple resolves (and like operations) to occur concurrently. One of
> those
> > is maintaining nonexclusive read locks (as opposed to the write locks
> which
> > are currently supported), and cleaning them up when necessary. For
> > ease-of-implementation, I'm currently proposing to only support this
> > behavior when NIO locks (which implicitly support shared locking
> semantics)
> > are enabled.
> >
> > To clean these locks up without requiring end-user code to be modified, I
> > propose using the IvyContext stack -- allowing Runnables to be attached
> to
> > a stack element, and invoking them implicitly when the stack is popped.
> >
> >
> > Because converting a read lock to a write lock is inherently prone to
> race
> > conditions, we might need to break backwards compatibility with respect
> to
> > ivy:clean, allowing this to be called only inside a context where no read
> > operations have been done -- or breaking read lock semantics by dropping
> > all read locks before grabbing the write lock.
> >
> >
> > Thoughts?
>
> My first blind though would be that IvyContext seems to be high level to
> handle locking. Couldn't it be done by improving the LockStrategy interface
> so that it also handles read locks ?
>
> Nicolas
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Cleanup callbacks in IvyContext?

[Charles Duffy]

Howdy, all --

I'm trying to strengthen Ivy's locking system to make it strong enough to
allow ivy:clean at arbitrary times on systems which can have other actions
making use of the same shared caches.

There are a few requirements to make this happen while still allowing
multiple resolves (and like operations) to occur concurrently. One of those
is maintaining nonexclusive read locks (as opposed to the write locks which
are currently supported), and cleaning them up when necessary. For
ease-of-implementation, I'm currently proposing to only support this
behavior when NIO locks (which implicitly support shared locking semantics)
are enabled.

To clean these locks up without requiring end-user code to be modified, I
propose using the IvyContext stack -- allowing Runnables to be attached to
a stack element, and invoking them implicitly when the stack is popped.


Because converting a read lock to a write lock is inherently prone to race
conditions, we might need to break backwards compatibility with respect to
ivy:clean, allowing this to be called only inside a context where no read
operations have been done -- or breaking read lock semantics by dropping
all read locks before grabbing the write lock.


Thoughts?

Re: Ivy release schedule

[Charles Duffy]

Absolutely, then. :)

I was under the impression that only members of the PMC could call a vote
for a release.

If that's something any committer can do, I'll gladly run the process after
your pending feature is in.

Thanks!


On Thu, Jan 2, 2014 at 10:02 AM, Nicolas Lalevée  wrote:

>
> Le 30 déc. 2013 à 19:35, Charles Duffy  a écrit :
>
> > Howdy, all --
> >
> > There's rather a lot of good stuff on Ivy's trunk.
>
> Agreed.
>
> > Any thoughts as to when
> > we might be in a position to start a release candidate series?
>
> I think any time a committer is willing to do so.
>
> > (As there are tickets assigned to 2.4.0, and nothing on 2.3.1, would I be
> > correct in gathering that that's where we're going next?)
>
> Yep 2.4.0 should be the next one.
>
> I only have one wish. I am working on supporting "packed" (.pack.gz)
> resources from Eclipse update sites. For that I would need to redesign a
> feature which is only in trunk: uncompress artifact on resolve (not
> documented yet, see DefaultRepositoryCacheManager#uncompressArtifact).
> Since I would like to break it a little bit, I would like to do it before
> releasing it, so no backward compatibility have to be supported.
> I am struggling a little bit with it, but I don't think it will take very
> long.
>
> Nicolas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Ivy release schedule

[Charles Duffy]

Howdy, all --

There's rather a lot of good stuff on Ivy's trunk. Any thoughts as to when
we might be in a position to start a release candidate series?

(As there are tickets assigned to 2.4.0, and nothing on 2.3.1, would I be
correct in gathering that that's where we're going next?)

Re: IVY-1455: effects of override tag escaping definition scope

[Charles Duffy]

Howdy --

I've committed a fix for this with a test case.

That said, I'm not really convinced that our test suite is as comprehensive
as it should be with respect to mediator functionality, so I'd be very
interested in reports of regressions related to the change.


On Thu, Dec 26, 2013 at 5:03 PM, Nicolas Lalevée  wrote:

>
> Le 24 déc. 2013 à 01:12, Charles Duffy  a écrit :
>
> > Howdy, all --
> >
> > I have a reproducer for an issue similar to IVY-1333 ("impossible to get
> > artifacts when data has not been loaded") which demonstrates some
> > surprising behavior, and would appreciate feedback from folks more
> familiar
> > with the ResolveEngine's internals:
> >
> > An  tag in a transitive dependency is impacting the overall
> > resolution, even when no child of that dependency matches the pattern
> > described by the tag in question.
> >
> > The tree looks as follows:
> >
> > reproducer/top-level
> > |- conflict/conflict==1 [conf="with-direct-dep->default"]
> > |- reproducer/phase-one==1 [conf="master->*"]
> > |  |- conflict/conflict==2
> > |  |- reproducer/phase-two==1
> > |  |  |- empty-module/empty-module==1
> > |  |  |- [override:conflict/conflict==1]
> >
> > Because phase-two has no children with a dependency on conflict/conflict
> > (its only child being empty-module), it is entirely surprising to me that
> > its override tag has any effect whatsoever. (However, removing the
> > dependency on empty-module *also* circumvents the bug).
> >
> > The top-level reproducer has two confs descended from master,
> > "with-direct-dep" and "without-direct-dep". In both, conflict/conflict is
> > resolved to version 2, but in the latter, conflict/conflict==1 is not
> > loaded at all. Only when both of these confs are invoked within a single
> > ivy:resolve task does the issue in question trigger.
> >
> > Could I ask for some pointers in the right direction to get a better
> handle
> > on what might be going on here?
> >
> > The reproducer in question is attached to IVY-1455 as a zip file.
>
> That seems to be a hell of a test case, you did a wonderful job getting
> that reproducible.
>
> But I don't know much that "override" feature. I would need to actively
> debug it to understand what the bug is about. So I wouldn't be much of a
> help to you now, maybe later (completely unpredictable later).
>
> Nicolas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Reconsidering IVY-1454

[Charles Duffy]

Howdy, all --

I've been seeing race conditions around mutating methods in IvySettings
resulting in occasional NPEs during IVY-1454 regression testing. We're also
getting issues with ConcurrentModificationExceptions from the logger stack
-- which it seems to me we'd need to move the loggers into thread-local
storage to resolve.

Frankly, there's enough side-effecting code throughout the codebase that
I'm uncomfortable only patching the immediately visible issues. What are
folks' thoughts on putting a big lock around the resolve task, and/or
documenting loudly that Ivy is not supported for concurrent use?

IVY-1455: effects of override tag escaping definition scope

[Charles Duffy]

Howdy, all --

I have a reproducer for an issue similar to IVY-1333 ("impossible to get
artifacts when data has not been loaded") which demonstrates some
surprising behavior, and would appreciate feedback from folks more familiar
with the ResolveEngine's internals:

An  tag in a transitive dependency is impacting the overall
resolution, even when no child of that dependency matches the pattern
described by the tag in question.

The tree looks as follows:

reproducer/top-level
 |- conflict/conflict==1 [conf="with-direct-dep->default"]
 |- reproducer/phase-one==1 [conf="master->*"]
 |  |- conflict/conflict==2
 |  |- reproducer/phase-two==1
 |  |  |- empty-module/empty-module==1
 |  |  |- [override:conflict/conflict==1]

Because phase-two has no children with a dependency on conflict/conflict
(its only child being empty-module), it is entirely surprising to me that
its override tag has any effect whatsoever. (However, removing the
dependency on empty-module *also* circumvents the bug).

The top-level reproducer has two confs descended from master,
"with-direct-dep" and "without-direct-dep". In both, conflict/conflict is
resolved to version 2, but in the latter, conflict/conflict==1 is not
loaded at all. Only when both of these confs are invoked within a single
ivy:resolve task does the issue in question trigger.

Could I ask for some pointers in the right direction to get a better handle
on what might be going on here?

The reproducer in question is attached to IVY-1455 as a zip file.


Many thanks,
-- Charles

Re: Re: OverlappingFileLockException when using artifact-lock-nio

[Charles Duffy]

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,  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" 
> 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 
> An: Ant Developers List 
> 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 , 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,  wrote:
>
> > Cool, if you find something, I'll happily test that.
> >
> > Thanks,
> > Carsten
> >
> >
> >
> > Von:Charles Duffy 
> > An: Ant Developers List 
> > 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,  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  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
> >
> >
>
>
>

Update to newer checkstyle plugin?

[Charles Duffy]

Howdy --

I had to make some changes to checkstyle-config to support modern releases
of the checkstyle plugin. Significant parts of the old config rely on
behavior which was changed in the checkstyle 5.0 release; current upstream
is 5.7.

The plugin I'm testing against uses net.sf.eclipsecs.core.CheckstyleNature,
as opposed to com.atlassw.tools.eclipse.checkstyle.CheckstyleNature. Would
anyone object to appropriate updates to ivy-core's .project
and src/etc/checkstyle/checkstyle-config?

Thanks!

Re: Re: OverlappingFileLockException when using artifact-lock-nio

[Charles Duffy]

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 , 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,  wrote:

> Cool, if you find something, I'll happily test that.
>
> Thanks,
> Carsten
>
>
>
> Von:Charles Duffy 
> An: Ant Developers List 
> 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,  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  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: OverlappingFileLockException when using artifact-lock-nio

[Charles Duffy]

I'll try to take a look at this today. Thanks for the report!


On Tue, Dec 17, 2013 at 8:19 AM,  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  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

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

[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

[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 

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

[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 openStream() throws IOException {
Index: src/java/org/apache/ivy/plugins/repository/url/URLRepository.java
=

Revisiting NIO FileLock

[Charles Duffy]

Howdy --

In both the documentation and the code, the NIO FileLock implementation is
advised against. However, the open(O_CREAT|O_EXCL)-based system which is
presently used in favor of it has the major issue that locks are not
cleaned up on failures -- such that manual intervention can be required to
release stale locks in the event of a power loss, reboot, SIGKILL, or
similar event.

As such, I've revisited the NIO-based implementation, and found what is,
presumably, the bug which led to its deprecation: *The NIO-based mechanism,
as currently implemented on Ivy mainline, does not actually maintain locks
from tryLock() to unlock(), but rather grabs a lock only during the period
of time in which tryLock() is being executed.*
*
*
This is true because locks using the flock() and fcntl() mechanisms which
back NIO locks on UNIX live only as long as the file descriptors to which
they are attached, and tryLock() contains a finally block which closes the
file -- and thus closes the file descriptor, and thus releases the lock. I
have attached a patch fixing this issue to
https://issues.apache.org/jira/browse/IVY-1424.


There are cases where NIO locks will genuinely be less reliable than the
open(O_CREAT|O_EXCL) approach -- network filesystems without support for
flock(), for instance. However, when available and supported by the
underlying OS and filesystem, they should be considered the preferred
approach due to the operating system's enforcement of automated cleanup. As
such, I suggest making them available as a separate lock type, allowing the
local administrator to select the lock type appropriate to the operating
system on which they run, balancing the advantage of automatic cleanup
against the disadvantage of reduced portability.

Thoughts?

checkDescriptorConsistency preventing revision mappings in namespaces

[Charles Duffy]

If you're seeing this for the second time, please pardon the repost -- the
first instance was posted through Nabble, and appears not to to have been
accepted by the real list.

---

For organisations and modules, checkDescriptorConsistency compares mrid and
md -- both of which use the local values.

For revisions, checkDescriptorConsistency generates expectedMrid using
ivyRev.getRevision(). Since ivyRef uses the remote (non-system) values,
this check fails when the mapping has any effect. In practice, this appears
to mean that checkDescriptorConsistency is enforcing that revision mappings
be either (1) unused, or (2) broken; a near-standalone reproducer (with the
only external dependency being the ibiblio repository) is available, with
an example of canned output, at
https://gist.github.com/charles-dyfis-net/5783838

I have a patch attached to https://issues.apache.org/jira/browse/IVY-1423 which
uses mrid.getRevision() rather than ivyRef.getRevision(); with it applied,
I'm successfully able to use namespace revision mappings. That said, I'd be
more comfortable with review from someone familiar with the surrounding
logic and able to speak for why this was previously implemented as it was.

Many thanks,
-- Charles

Ivy contribution process / timeline

[Charles Duffy]

Howdy --

I've recently submitted three tickets to the IVY project on Apache's JIRA
instance:

IVY-1421 - SSH agent support for SSH and SFTP transports
IVY-1423 - Namespace revision mapping does not work bidirectionally
IVY-1424 - NIO FileLocker releases locks while still within tryLock() call

All three of these tickets have patches attached -- patches which I'm
successfully using in production. None of them has received a response of
any kind -- on a timeline which, for IVY-1421, spans more than a month.


Is there process I should be following to shepherd these through? Is there
a fixed release schedule, sufficiently fixed that new tickets will only be
considered after those scheduled for already-planned releases are resolved?

I'd rather not let things fall through the cracks and still be on a
locally-patched Ivy years from now (a state in which I've inherited far too
many tools). Any guidance which could be offered would be appreciated.


Thanks,
-- Charles

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

[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

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

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

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

[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