[GitHub] ant-ivy issue #52: Generics in core

2017-07-17 Thread jaikiran 
Github user jaikiran commented on the issue:

https://github.com/apache/ant-ivy/pull/52
  
It looks like this PR has been updated with additional unrelated changes. 
Except for these 2 commits in this PR:

https://github.com/apache/ant-ivy/pull/52/commits/52b99a74d5770485d95d087aac8a97f8ad6c6795

https://github.com/apache/ant-ivy/pull/52/commits/f825fc31890033ed14580eb0cf06df860888bbb3

the rest of the commits related to bringing in generics to core has been 
merged to upstream.

These 2 commits are pretty much cosmetic changes (to large number of files) 
which I personally would like to avoid since they don't really bring in much 
value. Either way, this PR has now been closed since the major changes related 
to bringing in generics has now been merged.





---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] ant-ivy pull request #52: Generics in core

2017-07-17 Thread asfgit 
Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Proposed changes for IVY-735 - Ability to specify timeouts

2017-07-17 Thread Gintautas Grigelionis 
Exactly what I had in mind 

Gintas

2017-07-17 22:32 GMT+02:00 Jan Matèrne (jhm) :

> Maybe you could set the timeout strategy globally:
> /ivysettings/resolvers/@timeout-constraint
>
> 
>
>read-timeout="" />
>   ...
>
>
>
>   
>
> 
>
>
> Jan
>
>
> > -Ursprüngliche Nachricht-
> > Von: jai.forums2...@gmail.com [mailto:jai.forums2...@gmail.com]
> > Gesendet: Montag, 17. Juli 2017 06:56
> > An: dev@ant.apache.org
> > Betreff: Re: Proposed changes for IVY-735 - Ability to specify timeouts
> >
> > I think, that's actually a good idea. Defining the timeout constraints
> > separately as named constraints and then referencing them would allow
> > reusing these values on whichever resolvers want to:
> >
> > 
> >
> >   
> >
> >   > read-timeout="">
> >
> >  ...
> >
> >   
> >
> >   
> >
> >  
> >
> >   
> >
> > 
> >
> >
> > -Jaikiran
> >
> >
> > On 14/07/17 10:33 PM, Gintautas Grigelionis wrote:
> > > my €.02 : currently, all resolvers only have artifact patterns as
> > > child elements, so I'd rather have the timeouts as attributes that
> > > might use references, similarly to cache managers or latest
> > > strategies. That would imply a global default that may be overridden
> > individually.
> > >
> > > Gintas
> > >
> > > 2017-07-14 13:34 GMT+02:00 :
> > >
> > >> https://issues.apache.org/jira/browse/IVY-735 is a feature request
> > >> where the users have asked for relevant timeouts while dealing with
> > >> downloads. A few weeks back we had a very brief discussion in an
> > >> unrelated mail where it was proposed that we allow configuring these
> > >> timeout all the way from ivy settings.
> > >>
> > >> I have an initial proposal/attempt to implement this feature. The
> > >> initial changes are here in my personal repo[1]. It's a work in
> > >> progress commit which sets up the necessary interfaces and the flow
> > >> to show what I have in mind. Before proceeding further, I would like
> > >> some inputs on whether this looks fine. Here's a summary of what the
> > changes are going to be:
> > >>
> > >> - Each (dependency) resolver will have the ability to specify
> > >> "timeout constraints"[2].
> > >>
> > >> - These timeout constraints will be specified while defining the
> > >> resolver in the ivy settings file. Imagine something like:
> > >>
> > >>  
> > >>
> > >>  
> > >>
> > >>  
> > >>
> > >>   > >> read-timeout=""/>
> > >>
> > >>  
> > >>
> > >>  
> > >>
> > >> - Each of the resolver will then use these timeout constraints (if
> > >> specified) while resolving the module descriptor and downloading the
> > >> artifacts and dealing with those resources.
> > >>
> > >> - The absence of the timeout constraints will let the resolvers
> > >> behave the way they do currently
> > >>
> > >> The changes in the linked commit deprecate some APIs which weren't
> > >> using timeouts and are replaced by APIs which pass along (an
> > >> optional) TimeoutConstraints[2].
> > >>
> > >> In summary, the change being proposed is that (dependency) resolvers
> > >> have the ability to specify these timeout constraints and then use
> > >> them while dealing with module descriptors and artifacts. One thing
> > I
> > >> have (to some extent intentionally) left out is the ability to
> > define
> > >> a global Ivy settings level or "all resolvers" level
> > >> timeout-constraints. That's because I'm not too sure if it adds much
> > >> value instead of defining it at individual resolver level. I'm
> > however open to adding that support as well.
> > >>
> > >> The linked commit currently doesn't have the necessary support for
> > >> parsing these additional XML elements, but if this whole approach
> > >> looks fine, I will take this further and make sure things work as
> > expected.
> > >>
> > >> [1] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b9
> > >> 34f8a2710ebcfeaeb1456c8
> > >>
> > >> [2] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b9
> > >> 34f8a2710ebcfeaeb1456c8#diff-cd8ed454a52f4afa779574f5600a0ccb
> > >>
> > >>
> > >> -Jaikiran
> > >>
> > >>
> > >> 
> > -
> > >> 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
>
>

AW: Proposed changes for IVY-735 - Ability to specify timeouts

2017-07-17 Thread jhm 
Maybe you could set the timeout strategy globally:
/ivysettings/resolvers/@timeout-constraint


   
  
  ...
   
 
   
  
   



Jan


> -Ursprüngliche Nachricht-
> Von: jai.forums2...@gmail.com [mailto:jai.forums2...@gmail.com]
> Gesendet: Montag, 17. Juli 2017 06:56
> An: dev@ant.apache.org
> Betreff: Re: Proposed changes for IVY-735 - Ability to specify timeouts
> 
> I think, that's actually a good idea. Defining the timeout constraints
> separately as named constraints and then referencing them would allow
> reusing these values on whichever resolvers want to:
> 
> 
> 
>   
> 
>   read-timeout="">
> 
>  ...
> 
>   
> 
>   
> 
>  
> 
>   
> 
> 
> 
> 
> -Jaikiran
> 
> 
> On 14/07/17 10:33 PM, Gintautas Grigelionis wrote:
> > my €.02 : currently, all resolvers only have artifact patterns as
> > child elements, so I'd rather have the timeouts as attributes that
> > might use references, similarly to cache managers or latest
> > strategies. That would imply a global default that may be overridden
> individually.
> >
> > Gintas
> >
> > 2017-07-14 13:34 GMT+02:00 :
> >
> >> https://issues.apache.org/jira/browse/IVY-735 is a feature request
> >> where the users have asked for relevant timeouts while dealing with
> >> downloads. A few weeks back we had a very brief discussion in an
> >> unrelated mail where it was proposed that we allow configuring these
> >> timeout all the way from ivy settings.
> >>
> >> I have an initial proposal/attempt to implement this feature. The
> >> initial changes are here in my personal repo[1]. It's a work in
> >> progress commit which sets up the necessary interfaces and the flow
> >> to show what I have in mind. Before proceeding further, I would like
> >> some inputs on whether this looks fine. Here's a summary of what the
> changes are going to be:
> >>
> >> - Each (dependency) resolver will have the ability to specify
> >> "timeout constraints"[2].
> >>
> >> - These timeout constraints will be specified while defining the
> >> resolver in the ivy settings file. Imagine something like:
> >>
> >>  
> >>
> >>  
> >>
> >>  
> >>
> >>   >> read-timeout=""/>
> >>
> >>  
> >>
> >>  
> >>
> >> - Each of the resolver will then use these timeout constraints (if
> >> specified) while resolving the module descriptor and downloading the
> >> artifacts and dealing with those resources.
> >>
> >> - The absence of the timeout constraints will let the resolvers
> >> behave the way they do currently
> >>
> >> The changes in the linked commit deprecate some APIs which weren't
> >> using timeouts and are replaced by APIs which pass along (an
> >> optional) TimeoutConstraints[2].
> >>
> >> In summary, the change being proposed is that (dependency) resolvers
> >> have the ability to specify these timeout constraints and then use
> >> them while dealing with module descriptors and artifacts. One thing
> I
> >> have (to some extent intentionally) left out is the ability to
> define
> >> a global Ivy settings level or "all resolvers" level
> >> timeout-constraints. That's because I'm not too sure if it adds much
> >> value instead of defining it at individual resolver level. I'm
> however open to adding that support as well.
> >>
> >> The linked commit currently doesn't have the necessary support for
> >> parsing these additional XML elements, but if this whole approach
> >> looks fine, I will take this further and make sure things work as
> expected.
> >>
> >> [1] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b9
> >> 34f8a2710ebcfeaeb1456c8
> >>
> >> [2] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b9
> >> 34f8a2710ebcfeaeb1456c8#diff-cd8ed454a52f4afa779574f5600a0ccb
> >>
> >>
> >> -Jaikiran
> >>
> >>
> >> 
> -
> >> 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

JDK 9 EA Build 178 & JDK 8u152 b05 are available on jdk.java.net

2017-07-17 Thread Rory O'Donnell 

Hi Stefan,

*JDK 9 Early Access*  build 178  is available at : - jdk.java.net/9/

A summary of all the changes in this build are listed here 
.


Changes which were introduced since the last availability email that may 
be of interest :


 * b175 - Module system implementation refresh**(6/2017 update)
 * b175 - no longer has "-ea" in the version string and the system
   property "java version" is now simply "9"
 o

   *java -version*

>java version "9"
>Java(TM) SE Runtime Environment (build 9+175)
>Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode)
 o

   *Bundle name changes:*  e.g. jdk-9+175_linux-x86_bin.tar.gz


*JDK 8u152 Early Access*  build 05 is available at : - jdk.java.net/8/ 



A summary of all the changes in this build are listed here 
.


Rgds,Rory

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland