Re: [CANCELED][VOTE] Release Ivy 2.4.0

2014-12-09 Thread Jean-Louis Boudart
I thought it was possible as it was done for xooki (which doesn't seems to
have trunk/tags/branches structure see
https://issues.apache.org/jira/browse/INFRA-7816).

If we need to find another solution then we should probably duplicate
styles on git as they do not move too often. We can then improve this by
adding some automation to replicate changes from our new reference (GIT) in
svn website like Nicolas has done when handling documentation of released
versions.

2014-12-09 5:33 GMT+01:00 Antoine Levy Lambert anto...@gmx.de:

 On the infrastructure list Gavin wrote that infra is not able to create
 the mirror of the styles folder of the ivy doc that has been requested by
 Jean-Louis.

 The reason being that infra can only create a mirror from a structure
 having tags and trunk.

 @Jean-Louis, would creating a new git repository that we would populate
 manually work ?

 Regards,

 Antoine


 On Dec 3, 2014, at 5:05 PM, JBaruch jbar...@jfrog.com wrote:

  documentation added.
 
  Baruch.
 
  --
  JFrog Developer Advocate
  www.jfrog.com
  +972544954353
  @jbaruch https://twitter.com/jbaruch/
  http://linkd.in/jbaruch
 
  On Wed, Dec 3, 2014 at 1:37 PM, JBaruch jbar...@jfrog.com wrote:
 
  Perfect, we are on it.
  On 3 Dec 2014 12:29, Nicolas Lalevée nicolas.lale...@hibnet.org
 wrote:
 
  I would still would like some doc.
 
  The doc in the code source is still broken and it make it difficult to
  know how it is rendered.
  In the mean time time, you could write a page. I will then ensure
 myself
  that is proper included in the doc and rendered when the build will be
  fixed. You can take this file as an exemple:
 
 
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=doc/resolver/ibiblio.html;h=80057c4816a3cabc79bee70c961c57adcee29d11;hb=HEAD
  
 
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=doc/resolver/ibiblio.html;h=80057c4816a3cabc79bee70c961c57adcee29d11;hb=HEAD
 
 
  Nicolas
 
  Le 2 déc. 2014 à 22:56, JBaruch jbar...@jfrog.com a écrit :
 
  Can we use this opportunity to sneak IVY-1474 in?
 
  Baruch.
 
  --
  JFrog Developer Advocate
  www.jfrog.com
  +972544954353
  @jbaruch https://twitter.com/jbaruch/
  http://linkd.in/jbaruch
 
  On Tue, Dec 2, 2014 at 6:19 PM, Nicolas Lalevée 
  nicolas.lale...@hibnet.org
  wrote:
 
  It was so obvious that this release candidate should be canceled
 that I
  forgot to officially set it. Here it is.
 
  I see that the infra ticket is resolved. Jean-Louis spotted some
 issues
  with it though. But I guess we will retry very soon.
 
  Nicolas
 
  Le 9 nov. 2014 à 17:56, Nicolas Lalevée nicolas.lale...@hibnet.org
 
  a
  écrit :
 
  I have built a release candidate for Ivy 2.4.0
 
  The git tag of this release is:
 
 
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=b7f132a46601cdecfc631052818cab7f498078d2
 
  The artifacts has been published to:
  https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7093
 
  Do you vote for the release of these binaries?
 
  [ ] Yes
  [ ] No
 
  Regards,
  Nicolas
 
 
 
 -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 


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




-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/


Re: [CANCELED][VOTE] Release Ivy 2.4.0

2014-12-09 Thread Stefan Bodewig
On 2014-12-09, Jean-Louis Boudart wrote:

 If we need to find another solution then we should probably duplicate
 styles on git as they do not move too often. We can then improve this by
 adding some automation to replicate changes from our new reference (GIT) in
 svn website like Nicolas has done when handling documentation of released
 versions.

I've migrated xmlunit from svn to git[1] using svn2git[2] quite easily,
so starting with a fresh git repo and the pushing such a migrated code
base would preserve all history.

If you really need to keep two copies around, then svn2git --rebase
might help with it - it would certainly be a manual step.

Stefan

[1] https://github.com/xmlunit/xmlunit
[2] https://github.com/nirvdrum/svn2git

Stefan

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



JDK 9 images are now modular with JDK 9 Early Access build 41

2014-12-09 Thread Rory O'Donnell

Hi Stefan,

The initial changesets for JEP 220: Modular Run-Time Images [1] are 
available

with JDK 9 early-access build 41 [2].

To summarize (please see the JEP for details):

- The jre subdirectory is no longer present in JDK images.

- The user-editable configuration files in the lib subdirectory
   have been moved to the new conf directory.

- The endorsed-standards override mechanism has been removed.

- The extension mechanism has been removed.

- rt.jar, tools.jar, and dt.jar have been removed.

- A new URI scheme for naming stored modules, classes, and resources
   has been defined.

- For tools that previously accessed rt.jar directly, a built-in NIO
   file-system provider has been defined to provide access to the 
class

   and resource files within a run-time image.

More details are available at Mark Reinhold's latest blog entry [3]

Rgds, Rory

[1] http://openjdk.java.net/jeps/220
[2] https://jdk9.java.net/download/
[3] http://mreinhold.org/blog/jigsaw-modular-images

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


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



Re: JDK 9 images are now modular with JDK 9 Early Access build 41

2014-12-09 Thread Stefan Bodewig
Hi all

I think there are a few things in this that may cause trouble for Ant or
our users.  I can already see people being puzzled over Ant complaining
it doesn't find tools.jar

https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/launch/Locator.java#L450

On 2014-12-09, Rory O'Donnell wrote:

 - The jre subdirectory is no longer present in JDK images.

might throw JavaEnvUtils off

 - rt.jar, tools.jar, and dt.jar have been removed.

see above

 - A new URI scheme for naming stored modules, classes, and resources
has been defined.

not sure what that means

I'm not totally sure I'll find time to look into this the coming
weekend, but we will most probably need to do something and ensure a
release is out before Java9 goes to the first betas.

Stefan

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



Re: [CANCELED][VOTE] Release Ivy 2.4.0

2014-12-09 Thread Jean-Louis Boudart
Thanks for pointers stefan, i never used svn2git but i'll have a closer
look.

We need to choose what will be our reference.

Let me give you some context :
This directory containing styles (css,etc...) is used by both website
(which is still in svn and published via svnpubsub) and project
documentation (which is in ivy's git repository). As infra was proposing
git-svn mirror it was a good compromise. Website could live using
svn:externals to fetch appropriate files, and project documentation could
use git submodules.

If we can't have this svn mirror i don't think we could move thoses file in
a new git repository as website will not be able to access it.

The ideal solutions to all this headaches would probably to have everything
in git (including ivy's website), unfortunatly as far as i know we can't
publish website via git @ASF for the moment. Infra offers a gitpubsub
feature but i read somewhere that we can't use it to publish websites.

Considering we're talking about a few files that doesn't move too often i
was suggesting duplicating them by hand and/or automating it via a script
during the release process.



2014-12-09 9:59 GMT+01:00 Stefan Bodewig bode...@apache.org:

 On 2014-12-09, Jean-Louis Boudart wrote:

  If we need to find another solution then we should probably duplicate
  styles on git as they do not move too often. We can then improve this by
  adding some automation to replicate changes from our new reference (GIT)
 in
  svn website like Nicolas has done when handling documentation of released
  versions.

 I've migrated xmlunit from svn to git[1] using svn2git[2] quite easily,
 so starting with a fresh git repo and the pushing such a migrated code
 base would preserve all history.

 If you really need to keep two copies around, then svn2git --rebase
 might help with it - it would certainly be a manual step.

 Stefan

 [1] https://github.com/xmlunit/xmlunit
 [2] https://github.com/nirvdrum/svn2git

 Stefan

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




-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/


Re: [CANCELED][VOTE] Release Ivy 2.4.0

2014-12-09 Thread Stefan Bodewig
On 2014-12-09, Jean-Louis Boudart wrote:

 This directory containing styles (css,etc...) is used by both website
 (which is still in svn and published via svnpubsub) and project
 documentation (which is in ivy's git repository). As infra was proposing
 git-svn mirror it was a good compromise. Website could live using
 svn:externals to fetch appropriate files, and project documentation could
 use git submodules.

 Considering we're talking about a few files that doesn't move too often i
 was suggesting duplicating them by hand and/or automating it via a script
 during the release process.

OK, I think I understand.  If this is really only needed for a release
build, having the build process fetch them from svn (which I think you
are suggesting) seems to be a good choice.

Stefan

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



Re: [CANCELED][VOTE] Release Ivy 2.4.0

2014-12-09 Thread Antoine Levy Lambert
Yes !!!

Antoine
On Dec 9, 2014, at 9:36 AM, Stefan Bodewig bode...@apache.org wrote:

 On 2014-12-09, Jean-Louis Boudart wrote:
 
 This directory containing styles (css,etc...) is used by both website
 (which is still in svn and published via svnpubsub) and project
 documentation (which is in ivy's git repository). As infra was proposing
 git-svn mirror it was a good compromise. Website could live using
 svn:externals to fetch appropriate files, and project documentation could
 use git submodules.
 
 Considering we're talking about a few files that doesn't move too often i
 was suggesting duplicating them by hand and/or automating it via a script
 during the release process.
 
 OK, I think I understand.  If this is really only needed for a release
 build, having the build process fetch them from svn (which I think you
 are suggesting) seems to be a good choice.
 
 Stefan
 


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



AW: [CANCELED][VOTE] Release Ivy 2.4.0

2014-12-09 Thread jhm
The ideal solutions to all this headaches would probably to have everything
in git (including ivy's website), unfortunatly as far as i know we can't
publish website via git @ASF for the moment. Infra offers a gitpubsub
feature but i read somewhere that we can't use it to publish websites.

Would a Jenkins job help here?
It could build the website from git and 'push' (not git push ;) it
somewhere.


Jan



 -Ursprüngliche Nachricht-
 Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
 Gesendet: Mittwoch, 10. Dezember 2014 01:18
 An: Ant Developers List
 Betreff: Re: [CANCELED][VOTE] Release Ivy 2.4.0
 
 Yes !!!
 
 Antoine
 On Dec 9, 2014, at 9:36 AM, Stefan Bodewig bode...@apache.org wrote:
 
  On 2014-12-09, Jean-Louis Boudart wrote:
 
  This directory containing styles (css,etc...) is used by both
 website
  (which is still in svn and published via svnpubsub) and project
  documentation (which is in ivy's git repository). As infra was
  proposing git-svn mirror it was a good compromise. Website could
 live
  using svn:externals to fetch appropriate files, and project
  documentation could use git submodules.
 
  Considering we're talking about a few files that doesn't move too
  often i was suggesting duplicating them by hand and/or automating it
  via a script during the release process.
 
  OK, I think I understand.  If this is really only needed for a
 release
  build, having the build process fetch them from svn (which I think
 you
  are suggesting) seems to be a good choice.
 
  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