Re: Ivy - Latest snapshots will now be regularly available in Apache Maven Snapshot repository

[Nicolas Lalevée]

Awesome!

> Le 31 août 2017 à 10:43, Jaikiran Pai  a écrit :
> 
> Starting today, we now have an Ivy Jenkins job[1] which will publish our Ivy 
> snapshot artifactto Apache Maven Snapshots repository[2]. This job has been 
> configured to run after a successfulcompletion of our Ivy tests job (which 
> runs on *nix).
> 
> What this effectively means is that we now have regular Ivy snapshots 
> available as Maven artifacts in the Apache Maven snapshots repository. This 
> will allow users and other projects to test out (on a continuous basis) 
> latest Ivy snapshots and help catch any issues more quickly.
> 
> The Maven co-ordinates for the 2.5.0-SNAPSHOT (the current master version) 
> are:
> 
> org.apache.ivy
> ivy
> 2.5.0-SNAPSHOT
> 
> and can be found here 
> https://repository.apache.org/content/groups/snapshots/org/apache/ivy/ivy/2.5.0-SNAPSHOT/
> 
> [1] https://builds.apache.org/job/Ivy-Snapshot-Deploy/
> 
> [2] https://repository.apache.org/snapshots/
> 
> -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

Ivy - Latest snapshots will now be regularly available in Apache Maven Snapshot repository

[Jaikiran Pai]

Starting today, we now have an Ivy Jenkins job[1] which will publish our 
Ivy snapshot artifactto Apache Maven Snapshots repository[2]. This job 
has been configured to run after a successfulcompletion of our Ivy tests 
job (which runs on *nix).


What this effectively means is that we now have regular Ivy snapshots 
available as Maven artifacts in the Apache Maven snapshots repository. 
This will allow users and other projects to test out (on a continuous 
basis) latest Ivy snapshots and help catch any issues more quickly.


The Maven co-ordinates for the 2.5.0-SNAPSHOT (the current master 
version) are:


    org.apache.ivy
    ivy
    2.5.0-SNAPSHOT

and can be found here 
https://repository.apache.org/content/groups/snapshots/org/apache/ivy/ivy/2.5.0-SNAPSHOT/


[1] https://builds.apache.org/job/Ivy-Snapshot-Deploy/

[2] https://repository.apache.org/snapshots/

-Jaikiran


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

AW: AW: Repository access

[jhm]

Repos are renamed now:
easyant-* --> ant-easyant-*

I changed the url in my .git/config files and all works fine.
I updated the Jenkins job to reflect the new url.

After changing the repo name I also could push changes to ant-easyant-core, so 
I think 
write access to the other repos should work as well.


Jan

> -Ursprüngliche Nachricht-
> Von: Jean-Louis Boudart [mailto:jeanlouis.boud...@gmail.com]
> Gesendet: Dienstag, 10. Juni 2014 08:15
> An: Ant Developers List
> Betreff: Re: AW: Repository access
> 
> I just opened a new infra ticket as easyant is no longer in incubation.
> https://issues.apache.org/jira/browse/INFRA-7890
> 
> 
> 2014-06-08 11:20 GMT+02:00 Jan Matèrne (jhm) :
> 
> > Ticket closed:
> >  the asf-authorization-template is the place to add folks
> > to easyant incubator project. A PMC Chair can do this. If EasyAnt is
> > no longer an Incubator project then this auth needs to be removed and
> > merged with Ant. As a subproject of Ant all the git repos would need
> > to be renamed to be pre-pended with Ant- for auth to work - in the
> > same way as taglibs and Ivy are done now. Open an issue to have those
> > repos renamed
> >
> >
> > Next step by Conor ...
> >
> >
> > Jan
> >
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> > > Gesendet: Samstag, 7. Juni 2014 12:15
> > > An: 'Ant Developers List'
> > > Betreff: AW: AW: Repository access
> > >
> > > My personal test: write access to all ant-* repos, but no easyant-*
> > > repos.
> > > Maybe because I wasn't involved in the incubation phase?
> > >
> > > I opened https://issues.apache.org/jira/browse/INFRA-7877
> > >
> > >
> > > Jan
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Antoine Levy-Lambert [mailto:anto...@gmx.de]
> > > > Gesendet: Freitag, 6. Juni 2014 18:20
> > > > An: dev@ant.apache.org
> > > > Betreff: Re: AW: Repository access
> > > >
> > > > I do not think each commiter needs to do that but if you and
> > > > Jean-Louis go through this exercise and create an INFRA ticket
> > > > that would be very nice. As for me I have a lot of work in my day
> > > > job and on top of that I have caught an out of season cold, with
> > > > the temperature in New York going up and down and too much air
> > > conditioning at some places.
> > > >
> > > > Regards,
> > > >
> > > > Antoine
> > > >
> > > > Le 6 juin 2014 01:08, =?ISO-8859-1?Q?Jan_Mat=E8rne_=28jhm=29?=
> > > >  a écrit :
> > > > >
> > > > > Should we (each committer) try to commit/push to each repo
> > > > > before creating the issue?
> > > > > Maybe creating one file/repo (./git-access-test) where each
> > > > > committer places his name.
> > > > > Retest after the issue is resolved and finally delete that
> file.
> > > > >
> > > > > In that way INFRA doesnt need to act multiple times ...
> > > > >
> > > > > Jan
> > > > >
> > > > > > -Ursprüngliche Nachricht-
> > > > > > Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
> > > > > > Gesendet: Freitag, 6. Juni 2014 03:21
> > > > > > An: Ant Developers List
> > > > > > Betreff: Re: Repository access
> > > > > >
> > > > > > Hello Jean-Louis,
> > > > > >
> > > > > > please create the JIRA,
> > > > > >
> > > > > > Antoine
> > > > > > On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart
> > > > > >  wrote:
> > > > > >
> > > > > > > Same for me is there other repos having same issue?
> > > > > > >
> > > > > > > We need to create a INFRA jira for this.
> > > > > > >
> > > > > > >
> > > > > > > 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée
> > > > > > :
> > > > > > >
> > > > > > >> I couldn't commit the patch you suggested for the ivyde
> > > > > > >> updatesite
> > > > > > in
> > > > 

Re: AW: Repository access

[Jean-Louis Boudart]

I just opened a new infra ticket as easyant is no longer in incubation.
https://issues.apache.org/jira/browse/INFRA-7890


2014-06-08 11:20 GMT+02:00 Jan Matèrne (jhm) :

> Ticket closed:
>  the asf-authorization-template is the place to add folks to
> easyant incubator project. A PMC Chair can do this. If EasyAnt is no longer
> an Incubator project then this auth needs to be removed and merged with
> Ant. As a subproject of Ant all the git repos would need to be renamed to
> be pre-pended with Ant- for auth to work - in the same way as taglibs and
> Ivy are done now. Open an issue to have those repos renamed
>
>
> Next step by Conor ...
>
>
> Jan
>
>
>
> > -Ursprüngliche Nachricht-
> > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> > Gesendet: Samstag, 7. Juni 2014 12:15
> > An: 'Ant Developers List'
> > Betreff: AW: AW: Repository access
> >
> > My personal test: write access to all ant-* repos, but no easyant-*
> > repos.
> > Maybe because I wasn't involved in the incubation phase?
> >
> > I opened https://issues.apache.org/jira/browse/INFRA-7877
> >
> >
> > Jan
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Antoine Levy-Lambert [mailto:anto...@gmx.de]
> > > Gesendet: Freitag, 6. Juni 2014 18:20
> > > An: dev@ant.apache.org
> > > Betreff: Re: AW: Repository access
> > >
> > > I do not think each commiter needs to do that but if you and
> > > Jean-Louis go through this exercise and create an INFRA ticket that
> > > would be very nice. As for me I have a lot of work in my day job and
> > > on top of that I have caught an out of season cold, with the
> > > temperature in New York going up and down and too much air
> > conditioning at some places.
> > >
> > > Regards,
> > >
> > > Antoine
> > >
> > > Le 6 juin 2014 01:08, =?ISO-8859-1?Q?Jan_Mat=E8rne_=28jhm=29?=
> > >  a écrit :
> > > >
> > > > Should we (each committer) try to commit/push to each repo before
> > > > creating the issue?
> > > > Maybe creating one file/repo (./git-access-test) where each
> > > > committer places his name.
> > > > Retest after the issue is resolved and finally delete that file.
> > > >
> > > > In that way INFRA doesnt need to act multiple times ...
> > > >
> > > > Jan
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
> > > > > Gesendet: Freitag, 6. Juni 2014 03:21
> > > > > An: Ant Developers List
> > > > > Betreff: Re: Repository access
> > > > >
> > > > > Hello Jean-Louis,
> > > > >
> > > > > please create the JIRA,
> > > > >
> > > > > Antoine
> > > > > On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart
> > > > >  wrote:
> > > > >
> > > > > > Same for me is there other repos having same issue?
> > > > > >
> > > > > > We need to create a INFRA jira for this.
> > > > > >
> > > > > >
> > > > > > 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée
> > > > > :
> > > > > >
> > > > > >> I couldn't commit the patch you suggested for the ivyde
> > > > > >> updatesite
> > > > > in
> > > > > >> svn either. It must be read only.
> > > > > >>
> > > > > >> Nicolas
> > > > > >>
> > > > > >> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm) 
> > a
> > > > > écrit :
> > > > > >>
> > > > > >>> After ivyde-updatesite (svn) this is the 2nd repo where I
> > > > > >>> can't
> > > > > >> commit/push
> > > > > >>>
> > > > > >>> https://git-wip-us.apache.org/repos/asf/easyant-core.git
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> Is there any reason?
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> Jan
> > > > > >>>
> > > >

AW: AW: Repository access

[jhm]

Ticket closed:
 the asf-authorization-template is the place to add folks to easyant 
incubator project. A PMC Chair can do this. If EasyAnt is no longer an 
Incubator project then this auth needs to be removed and merged with Ant. As a 
subproject of Ant all the git repos would need to be renamed to be pre-pended 
with Ant- for auth to work - in the same way as taglibs and Ivy are done now. 
Open an issue to have those repos renamed


Next step by Conor ...


Jan



> -Ursprüngliche Nachricht-
> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> Gesendet: Samstag, 7. Juni 2014 12:15
> An: 'Ant Developers List'
> Betreff: AW: AW: Repository access
> 
> My personal test: write access to all ant-* repos, but no easyant-*
> repos.
> Maybe because I wasn't involved in the incubation phase?
> 
> I opened https://issues.apache.org/jira/browse/INFRA-7877
> 
> 
> Jan
> 
> > -Ursprüngliche Nachricht-
> > Von: Antoine Levy-Lambert [mailto:anto...@gmx.de]
> > Gesendet: Freitag, 6. Juni 2014 18:20
> > An: dev@ant.apache.org
> > Betreff: Re: AW: Repository access
> >
> > I do not think each commiter needs to do that but if you and
> > Jean-Louis go through this exercise and create an INFRA ticket that
> > would be very nice. As for me I have a lot of work in my day job and
> > on top of that I have caught an out of season cold, with the
> > temperature in New York going up and down and too much air
> conditioning at some places.
> >
> > Regards,
> >
> > Antoine
> >
> > Le 6 juin 2014 01:08, =?ISO-8859-1?Q?Jan_Mat=E8rne_=28jhm=29?=
> >  a écrit :
> > >
> > > Should we (each committer) try to commit/push to each repo before
> > > creating the issue?
> > > Maybe creating one file/repo (./git-access-test) where each
> > > committer places his name.
> > > Retest after the issue is resolved and finally delete that file.
> > >
> > > In that way INFRA doesnt need to act multiple times ...
> > >
> > > Jan
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
> > > > Gesendet: Freitag, 6. Juni 2014 03:21
> > > > An: Ant Developers List
> > > > Betreff: Re: Repository access
> > > >
> > > > Hello Jean-Louis,
> > > >
> > > > please create the JIRA,
> > > >
> > > > Antoine
> > > > On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart
> > > >  wrote:
> > > >
> > > > > Same for me is there other repos having same issue?
> > > > >
> > > > > We need to create a INFRA jira for this.
> > > > >
> > > > >
> > > > > 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée
> > > > :
> > > > >
> > > > >> I couldn't commit the patch you suggested for the ivyde
> > > > >> updatesite
> > > > in
> > > > >> svn either. It must be read only.
> > > > >>
> > > > >> Nicolas
> > > > >>
> > > > >> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm) 
> a
> > > > écrit :
> > > > >>
> > > > >>> After ivyde-updatesite (svn) this is the 2nd repo where I
> > > > >>> can't
> > > > >> commit/push
> > > > >>>
> > > > >>> https://git-wip-us.apache.org/repos/asf/easyant-core.git
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Is there any reason?
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Jan
> > > > >>>
> > > > >>
> > > > >>
> > > > >> --
> -
> > > > >> -
> > -
> > > > >> ---
> > > > -
> > > > >> 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/
> > > >
> > > >
> > > > -
> -
> > > > -
> > -
> > > > - 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
> 
> 
> 
> -
> 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: AW: Repository access

[jhm]

My personal test: write access to all ant-* repos, but no easyant-* repos.
Maybe because I wasn't involved in the incubation phase?

I opened https://issues.apache.org/jira/browse/INFRA-7877


Jan

> -Ursprüngliche Nachricht-
> Von: Antoine Levy-Lambert [mailto:anto...@gmx.de]
> Gesendet: Freitag, 6. Juni 2014 18:20
> An: dev@ant.apache.org
> Betreff: Re: AW: Repository access
> 
> I do not think each commiter needs to do that but if you and Jean-Louis
> go through this exercise and create an INFRA ticket that would be very
> nice. As for me I have a lot of work in my day job and on top of that I
> have caught an out of season cold, with the temperature in New York
> going up and down and too much air conditioning at some places.
> 
> Regards,
> 
> Antoine
> 
> Le 6 juin 2014 01:08, =?ISO-8859-1?Q?Jan_Mat=E8rne_=28jhm=29?=
>  a écrit :
> >
> > Should we (each committer) try to commit/push to each repo before
> > creating the issue?
> > Maybe creating one file/repo (./git-access-test) where each committer
> > places his name.
> > Retest after the issue is resolved and finally delete that file.
> >
> > In that way INFRA doesnt need to act multiple times ...
> >
> > Jan
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
> > > Gesendet: Freitag, 6. Juni 2014 03:21
> > > An: Ant Developers List
> > > Betreff: Re: Repository access
> > >
> > > Hello Jean-Louis,
> > >
> > > please create the JIRA,
> > >
> > > Antoine
> > > On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart
> > >  wrote:
> > >
> > > > Same for me is there other repos having same issue?
> > > >
> > > > We need to create a INFRA jira for this.
> > > >
> > > >
> > > > 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée
> > > :
> > > >
> > > >> I couldn't commit the patch you suggested for the ivyde
> > > >> updatesite
> > > in
> > > >> svn either. It must be read only.
> > > >>
> > > >> Nicolas
> > > >>
> > > >> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm)  a
> > > écrit :
> > > >>
> > > >>> After ivyde-updatesite (svn) this is the 2nd repo where I can't
> > > >> commit/push
> > > >>>
> > > >>> https://git-wip-us.apache.org/repos/asf/easyant-core.git
> > > >>>
> > > >>>
> > > >>>
> > > >>> Is there any reason?
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> Jan
> > > >>>
> > > >>
> > > >>
> > > >> 
> -
> > > >> ---
> > > -
> > > >> 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/
> > >
> > >
> > > ---
> -
> > > - 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



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

AW: AW: Repository access

[jhm]

My understanding of the current decission is:
- pull requests are possible
- there should be no automatically merge
- a committer has to merge the PR on his local repo an push that to the ASF 
repo.

Jan

> -Ursprüngliche Nachricht-
> Von: Andre-John Mas [mailto:andrejohn@gmail.com]
> Gesendet: Samstag, 7. Juni 2014 02:47
> An: Ant Developers List
> Betreff: Re: AW: Repository access
> 
> Can we not work with pull requests, in Git? At least this is an
> approach when working in GitHub.
> 
> André-John
> 
> Sent from my phone. Envoyé depuis mon téléphone.
> 
> > On 6 Jun 2014, at 12:19, Antoine Levy-Lambert  wrote:
> >
> > I do not think each commiter needs to do that but if you and Jean-
> Louis go through this exercise and create an INFRA ticket that would be
> very nice. As for me I have a lot of work in my day job and on top of
> that I have caught an out of season cold, with the temperature in New
> York going up and down and too much air conditioning at some places.
> >
> > Regards,
> >
> > Antoine
> >
> > Le 6 juin 2014 01:08, =?ISO-8859-1?Q?Jan_Mat=E8rne_=28jhm=29?=
>  a écrit :
> >>
> >> Should we (each committer) try to commit/push to each repo before
> >> creating the issue?
> >> Maybe creating one file/repo (./git-access-test) where each
> committer
> >> places his name.
> >> Retest after the issue is resolved and finally delete that file.
> >>
> >> In that way INFRA doesnt need to act multiple times ...
> >>
> >> Jan
> >>
> >>> -Ursprüngliche Nachricht-
> >>> Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
> >>> Gesendet: Freitag, 6. Juni 2014 03:21
> >>> An: Ant Developers List
> >>> Betreff: Re: Repository access
> >>>
> >>> Hello Jean-Louis,
> >>>
> >>> please create the JIRA,
> >>>
> >>> Antoine
> >>> On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart
> >>>  wrote:
> >>>
> >>>> Same for me is there other repos having same issue?
> >>>>
> >>>> We need to create a INFRA jira for this.
> >>>>
> >>>>
> >>>> 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée
> >>> :
> >>>>
> >>>>> I couldn't commit the patch you suggested for the ivyde
> updatesite
> >>> in
> >>>>> svn either. It must be read only.
> >>>>>
> >>>>> Nicolas
> >>>>>
> >>>>> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm)  a
> >>> écrit :
> >>>>>
> >>>>>> After ivyde-updatesite (svn) this is the 2nd repo where I can't
> >>>>> commit/push
> >>>>>>
> >>>>>> https://git-wip-us.apache.org/repos/asf/easyant-core.git
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Is there any reason?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Jan
> >>>>>
> >>>>>
> >>>>> -
> -
> >>>>> --
> >>> -
> >>>>> 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/
> >>>
> >>>
> >>> ---
> -
> >>> - 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
> >
> 
> -
> 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: AW: Repository access

[Andre-John Mas]

Can we not work with pull requests, in Git? At least this is an approach when 
working in GitHub. 

André-John

Sent from my phone. Envoyé depuis mon téléphone. 

> On 6 Jun 2014, at 12:19, Antoine Levy-Lambert  wrote:
> 
> I do not think each commiter needs to do that but if you and Jean-Louis go 
> through this exercise and create an INFRA ticket that would be very nice. As 
> for me I have a lot of work in my day job and on top of that I have caught an 
> out of season cold, with the temperature in New York going up and down and 
> too much air conditioning at some places.
> 
> Regards,
> 
> Antoine
> 
> Le 6 juin 2014 01:08, =?ISO-8859-1?Q?Jan_Mat=E8rne_=28jhm=29?= 
>  a écrit :
>> 
>> Should we (each committer) try to commit/push to each repo before creating 
>> the issue? 
>> Maybe creating one file/repo (./git-access-test) where each committer places 
>> his name. 
>> Retest after the issue is resolved and finally delete that file. 
>> 
>> In that way INFRA doesnt need to act multiple times ... 
>> 
>> Jan 
>> 
>>> -Ursprüngliche Nachricht- 
>>> Von: Antoine Levy Lambert [mailto:anto...@gmx.de] 
>>> Gesendet: Freitag, 6. Juni 2014 03:21 
>>> An: Ant Developers List 
>>> Betreff: Re: Repository access 
>>> 
>>> Hello Jean-Louis, 
>>> 
>>> please create the JIRA, 
>>> 
>>> Antoine 
>>> On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart 
>>>  wrote: 
>>> 
>>>> Same for me is there other repos having same issue? 
>>>> 
>>>> We need to create a INFRA jira for this. 
>>>> 
>>>> 
>>>> 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée
>>> : 
>>>> 
>>>>> I couldn't commit the patch you suggested for the ivyde updatesite
>>> in 
>>>>> svn either. It must be read only. 
>>>>> 
>>>>> Nicolas 
>>>>> 
>>>>> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm)  a
>>> écrit : 
>>>>> 
>>>>>> After ivyde-updatesite (svn) this is the 2nd repo where I can't
>>>>> commit/push 
>>>>>> 
>>>>>> https://git-wip-us.apache.org/repos/asf/easyant-core.git 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Is there any reason? 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Jan
>>>>> 
>>>>> 
>>>>>  
>>> - 
>>>>> 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/
>>> 
>>> 
>>> - 
>>> 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
> 

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

Re: AW: Repository access

[Antoine Levy-Lambert]

I do not think each commiter needs to do that but if you and Jean-Louis go 
through this exercise and create an INFRA ticket that would be very nice. As 
for me I have a lot of work in my day job and on top of that I have caught an 
out of season cold, with the temperature in New York going up and down and too 
much air conditioning at some places.

Regards,

Antoine

Le 6 juin 2014 01:08, =?ISO-8859-1?Q?Jan_Mat=E8rne_=28jhm=29?= 
 a écrit :
>
> Should we (each committer) try to commit/push to each repo before creating 
> the issue? 
> Maybe creating one file/repo (./git-access-test) where each committer places 
> his name. 
> Retest after the issue is resolved and finally delete that file. 
>
> In that way INFRA doesnt need to act multiple times ... 
>
> Jan 
>
> > -Ursprüngliche Nachricht- 
> > Von: Antoine Levy Lambert [mailto:anto...@gmx.de] 
> > Gesendet: Freitag, 6. Juni 2014 03:21 
> > An: Ant Developers List 
> > Betreff: Re: Repository access 
> > 
> > Hello Jean-Louis, 
> > 
> > please create the JIRA, 
> > 
> > Antoine 
> > On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart 
> >  wrote: 
> > 
> > > Same for me is there other repos having same issue? 
> > > 
> > > We need to create a INFRA jira for this. 
> > > 
> > > 
> > > 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée 
> > : 
> > > 
> > >> I couldn't commit the patch you suggested for the ivyde updatesite 
> > in 
> > >> svn either. It must be read only. 
> > >> 
> > >> Nicolas 
> > >> 
> > >> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm)  a 
> > écrit : 
> > >> 
> > >>> After ivyde-updatesite (svn) this is the 2nd repo where I can't 
> > >> commit/push 
> > >>> 
> > >>> https://git-wip-us.apache.org/repos/asf/easyant-core.git 
> > >>> 
> > >>> 
> > >>> 
> > >>> Is there any reason? 
> > >>> 
> > >>> 
> > >>> 
> > >>> 
> > >>> 
> > >>> Jan 
> > >>> 
> > >> 
> > >> 
> > >>  
> > - 
> > >> 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/ 
> > 
> > 
> > - 
> > 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: Repository access

[jhm]

Should we (each committer) try to commit/push to each repo before creating
the issue?
Maybe creating one file/repo (./git-access-test) where each committer places
his name.
Retest after the issue is resolved and finally delete that file.

In that way INFRA doesnt need to act multiple times ...

Jan

> -Ursprüngliche Nachricht-
> Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
> Gesendet: Freitag, 6. Juni 2014 03:21
> An: Ant Developers List
> Betreff: Re: Repository access
> 
> Hello Jean-Louis,
> 
> please create the JIRA,
> 
> Antoine
> On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart
>  wrote:
> 
> > Same for me is there other repos having same issue?
> >
> > We need to create a INFRA jira for this.
> >
> >
> > 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée
> :
> >
> >> I couldn't commit the patch you suggested for the ivyde updatesite
> in
> >> svn either. It must be read only.
> >>
> >> Nicolas
> >>
> >> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm)  a
> écrit :
> >>
> >>> After ivyde-updatesite (svn) this is the 2nd repo where I can't
> >> commit/push
> >>>
> >>> https://git-wip-us.apache.org/repos/asf/easyant-core.git
> >>>
> >>>
> >>>
> >>> Is there any reason?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Jan
> >>>
> >>
> >>
> >> 
> -
> >> 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/
> 
> 
> -
> 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: Repository access

[Antoine Levy Lambert]

Hello Jean-Louis,

please create the JIRA,

Antoine
On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart  
wrote:

> Same for me is there other repos having same issue?
> 
> We need to create a INFRA jira for this.
> 
> 
> 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée :
> 
>> I couldn't commit the patch you suggested for the ivyde updatesite in svn
>> either. It must be read only.
>> 
>> Nicolas
>> 
>> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm)  a écrit :
>> 
>>> After ivyde-updatesite (svn) this is the 2nd repo where I can't
>> commit/push
>>> 
>>> https://git-wip-us.apache.org/repos/asf/easyant-core.git
>>> 
>>> 
>>> 
>>> Is there any reason?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Jan
>>> 
>> 
>> 
>> -
>> 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/


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

Re: Repository access

[Jean-Louis Boudart]

Same for me is there other repos having same issue?

We need to create a INFRA jira for this.


2014-06-05 18:08 GMT+02:00 Nicolas Lalevée :

> I couldn't commit the patch you suggested for the ivyde updatesite in svn
> either. It must be read only.
>
> Nicolas
>
> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm)  a écrit :
>
> > After ivyde-updatesite (svn) this is the 2nd repo where I can't
> commit/push
> >
> > https://git-wip-us.apache.org/repos/asf/easyant-core.git
> >
> >
> >
> > Is there any reason?
> >
> >
> >
> >
> >
> > Jan
> >
>
>
> -
> 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: Repository access

[Nicolas Lalevée]

I couldn't commit the patch you suggested for the ivyde updatesite in svn 
either. It must be read only.

Nicolas

Le 5 juin 2014 à 07:57, Jan Matèrne (jhm)  a écrit :

> After ivyde-updatesite (svn) this is the 2nd repo where I can't commit/push
> 
> https://git-wip-us.apache.org/repos/asf/easyant-core.git
> 
> 
> 
> Is there any reason? 
> 
> 
> 
> 
> 
> Jan
> 


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

Repository access

[jhm]

After ivyde-updatesite (svn) this is the 2nd repo where I can't commit/push

https://git-wip-us.apache.org/repos/asf/easyant-core.git

 

Is there any reason? 

 

 

Jan

Re: Standard repository layout?

[Ben McCann]

Thanks Josh. Great to hear that SBT and Ivy largely use the same thing
there. Unfortunately Gradle uses something completely different. I've
submitted a pull request to
Gradleto allow setting an
option that would make it work the same way as Ivy and
SBT. Unfortunately they don't want to make it the default for backwards
compatibility, but at least it will be a little easier to make Gradle use
the correct layout.

-Ben


On Thu, Apr 10, 2014 at 9:06 AM, Josh Suereth wrote:

> Right, Ivy has a default for local in its ivysettings, but I think
> sbt/gradle just mimic this as opposed to use the raw ivy settings (I'm not
> fully aware of why sbt doesn't use it directly, I think so users can turn
> it off using sbt-only settings)
>
>
> Here's the Ivy 1.4 config for local:
>
> 
>  value="${ivy.default.ivy.user.dir}/local" override="false"/>
>   value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]"
> override="false"/>
>  value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]"
> override="false"/>
> 
> 
>  pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" />
>  pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}"
> />
> 
> 
> 
>
>
>
> Hope that helps answer "what default" is :)   As I said, we modify the
> artifact pattern slightly to handle sbt plugins and binary revisioning, but
> the pattern should be compatible with the above and only sbt has to care
> about sbt-plugins (theoretically).
>
>
>
>
> On Thu, Apr 10, 2014 at 11:58 AM, Ben McCann  wrote:
>
> > Hey Josh, thanks for the pointers.  I'm mainly curious about
> ~/.ivy2/local.
> >  I'm surprised you say you don't think there *is* a standard. Ivy must
> use
> > some pattern by default when publishing to ~/.ivy2/local, right?
>  Hopefully
> > for compatibility SBT would do the same thing as Ivy there.
> >
> > Thanks,
> > Ben
> >
> >
> > On Thu, Apr 10, 2014 at 5:48 AM, Josh Suereth  > >wrote:
> >
> > > Sorry, send that a bit too early, here's the hook to local where we
> adapt
> > > the pattern for sbt plugins:
> > >
> > >
> > >
> >
> https://github.com/sbt/sbt/blob/0.13/ivy/src/main/scala/sbt/Resolver.scala#L281-L285
> > >
> > >
> > > If you're not resolving sbt plugins, that shouldn't matter.
> > >
> > >
> > > On Thu, Apr 10, 2014 at 8:47 AM, Josh Suereth <
> joshua.suer...@gmail.com
> > > >wrote:
> > >
> > > > Ben -
> > > >
> > > > Do you mean "~/.ivy2/local" or  "~/.ivy2/cache"  ?
> > > >
> > > > AFAIK the cache bit is the same in sbt as for Ivy, caveat that we try
> > to
> > > > ignore what resolver an artifact came from in the store.  However,
> > > Gradle's
> > > > cache is a completely different beast, so the I don't think the two
> are
> > > > compatible.
> > > >
> > > > Now for the local-project, we could very-well have something
> > non-standard
> > > > in there, although I don't think there *is* a standard.  Here's the
> > > > code/pattern for resolving from the local repo:
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/Update.scala#L379-L387
> > > >
> > > >
> > >
> >
> https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/BootConfiguration.scala#L30-L32
> > > >
> > > > Also, for loading sbt-plugins we add the additional "scala/sbt"
> > universe
> > > > to the pattern:
> > > >
> > > >
> > > > Someone more qualified than I in the Ivy can answer whether that's a
> > > > "default" thing.
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Apr 10, 2014 at 3:00 AM, Ben McCann 
> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I'm using SBT and Gradle as build systems. I want them to publish to
> > and
> > > >> read from ~/.ivy2 but they use and expect default layouts and so
> they
> > do
> > > >> not cooperate well each other using this directory. I'm wondering
> > which
> > > >> one
> > > >> is right and which one is wrong.
> > > >>
> > > >> Also, I downloaded the latest ivy source to check what layout it
> > uses. I
> > > >> noticed the fields IvyRepResolver.DEFAULT_IVYPATTERN and
> > > >> IvyRepResolver.DEFAULT_IVYROOT are unused. Should they be removed?
> The
> > > >> latter points to what appears to be an abandoned domain as the page
> is
> > > >> filled with adds and a link stating "Buy this domain".
> > > >>
> > > >> Thanks,
> > > >> Ben
> > > >>
> > > >> --
> > > >> about.me/benmccann
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > about.me/benmccann
> >
>



-- 
about.me/benmccann

Re: Standard repository layout?

[Josh Suereth]

Right, Ivy has a default for local in its ivysettings, but I think
sbt/gradle just mimic this as opposed to use the raw ivy settings (I'm not
fully aware of why sbt doesn't use it directly, I think so users can turn
it off using sbt-only settings)


Here's the Ivy 1.4 config for local:















Hope that helps answer "what default" is :)   As I said, we modify the
artifact pattern slightly to handle sbt plugins and binary revisioning, but
the pattern should be compatible with the above and only sbt has to care
about sbt-plugins (theoretically).




On Thu, Apr 10, 2014 at 11:58 AM, Ben McCann  wrote:

> Hey Josh, thanks for the pointers.  I'm mainly curious about ~/.ivy2/local.
>  I'm surprised you say you don't think there *is* a standard. Ivy must use
> some pattern by default when publishing to ~/.ivy2/local, right?  Hopefully
> for compatibility SBT would do the same thing as Ivy there.
>
> Thanks,
> Ben
>
>
> On Thu, Apr 10, 2014 at 5:48 AM, Josh Suereth  >wrote:
>
> > Sorry, send that a bit too early, here's the hook to local where we adapt
> > the pattern for sbt plugins:
> >
> >
> >
> https://github.com/sbt/sbt/blob/0.13/ivy/src/main/scala/sbt/Resolver.scala#L281-L285
> >
> >
> > If you're not resolving sbt plugins, that shouldn't matter.
> >
> >
> > On Thu, Apr 10, 2014 at 8:47 AM, Josh Suereth  > >wrote:
> >
> > > Ben -
> > >
> > > Do you mean "~/.ivy2/local" or  "~/.ivy2/cache"  ?
> > >
> > > AFAIK the cache bit is the same in sbt as for Ivy, caveat that we try
> to
> > > ignore what resolver an artifact came from in the store.  However,
> > Gradle's
> > > cache is a completely different beast, so the I don't think the two are
> > > compatible.
> > >
> > > Now for the local-project, we could very-well have something
> non-standard
> > > in there, although I don't think there *is* a standard.  Here's the
> > > code/pattern for resolving from the local repo:
> > >
> > >
> > >
> >
> https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/Update.scala#L379-L387
> > >
> > >
> >
> https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/BootConfiguration.scala#L30-L32
> > >
> > > Also, for loading sbt-plugins we add the additional "scala/sbt"
> universe
> > > to the pattern:
> > >
> > >
> > > Someone more qualified than I in the Ivy can answer whether that's a
> > > "default" thing.
> > >
> > >
> > >
> > >
> > > On Thu, Apr 10, 2014 at 3:00 AM, Ben McCann  wrote:
> > >
> > >> Hi,
> > >>
> > >> I'm using SBT and Gradle as build systems. I want them to publish to
> and
> > >> read from ~/.ivy2 but they use and expect default layouts and so they
> do
> > >> not cooperate well each other using this directory. I'm wondering
> which
> > >> one
> > >> is right and which one is wrong.
> > >>
> > >> Also, I downloaded the latest ivy source to check what layout it
> uses. I
> > >> noticed the fields IvyRepResolver.DEFAULT_IVYPATTERN and
> > >> IvyRepResolver.DEFAULT_IVYROOT are unused. Should they be removed? The
> > >> latter points to what appears to be an abandoned domain as the page is
> > >> filled with adds and a link stating "Buy this domain".
> > >>
> > >> Thanks,
> > >> Ben
> > >>
> > >> --
> > >> about.me/benmccann
> > >>
> > >
> > >
> >
>
>
>
> --
> about.me/benmccann
>

Re: Standard repository layout?

[Ben McCann]

Hey Josh, thanks for the pointers.  I'm mainly curious about ~/.ivy2/local.
 I'm surprised you say you don't think there *is* a standard. Ivy must use
some pattern by default when publishing to ~/.ivy2/local, right?  Hopefully
for compatibility SBT would do the same thing as Ivy there.

Thanks,
Ben


On Thu, Apr 10, 2014 at 5:48 AM, Josh Suereth wrote:

> Sorry, send that a bit too early, here's the hook to local where we adapt
> the pattern for sbt plugins:
>
>
> https://github.com/sbt/sbt/blob/0.13/ivy/src/main/scala/sbt/Resolver.scala#L281-L285
>
>
> If you're not resolving sbt plugins, that shouldn't matter.
>
>
> On Thu, Apr 10, 2014 at 8:47 AM, Josh Suereth  >wrote:
>
> > Ben -
> >
> > Do you mean "~/.ivy2/local" or  "~/.ivy2/cache"  ?
> >
> > AFAIK the cache bit is the same in sbt as for Ivy, caveat that we try to
> > ignore what resolver an artifact came from in the store.  However,
> Gradle's
> > cache is a completely different beast, so the I don't think the two are
> > compatible.
> >
> > Now for the local-project, we could very-well have something non-standard
> > in there, although I don't think there *is* a standard.  Here's the
> > code/pattern for resolving from the local repo:
> >
> >
> >
> https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/Update.scala#L379-L387
> >
> >
> https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/BootConfiguration.scala#L30-L32
> >
> > Also, for loading sbt-plugins we add the additional "scala/sbt" universe
> > to the pattern:
> >
> >
> > Someone more qualified than I in the Ivy can answer whether that's a
> > "default" thing.
> >
> >
> >
> >
> > On Thu, Apr 10, 2014 at 3:00 AM, Ben McCann  wrote:
> >
> >> Hi,
> >>
> >> I'm using SBT and Gradle as build systems. I want them to publish to and
> >> read from ~/.ivy2 but they use and expect default layouts and so they do
> >> not cooperate well each other using this directory. I'm wondering which
> >> one
> >> is right and which one is wrong.
> >>
> >> Also, I downloaded the latest ivy source to check what layout it uses. I
> >> noticed the fields IvyRepResolver.DEFAULT_IVYPATTERN and
> >> IvyRepResolver.DEFAULT_IVYROOT are unused. Should they be removed? The
> >> latter points to what appears to be an abandoned domain as the page is
> >> filled with adds and a link stating "Buy this domain".
> >>
> >> Thanks,
> >> Ben
> >>
> >> --
> >> about.me/benmccann
> >>
> >
> >
>



-- 
about.me/benmccann

Re: Standard repository layout?

[Josh Suereth]

Sorry, send that a bit too early, here's the hook to local where we adapt
the pattern for sbt plugins:

https://github.com/sbt/sbt/blob/0.13/ivy/src/main/scala/sbt/Resolver.scala#L281-L285


If you're not resolving sbt plugins, that shouldn't matter.


On Thu, Apr 10, 2014 at 8:47 AM, Josh Suereth wrote:

> Ben -
>
> Do you mean "~/.ivy2/local" or  "~/.ivy2/cache"  ?
>
> AFAIK the cache bit is the same in sbt as for Ivy, caveat that we try to
> ignore what resolver an artifact came from in the store.  However, Gradle's
> cache is a completely different beast, so the I don't think the two are
> compatible.
>
> Now for the local-project, we could very-well have something non-standard
> in there, although I don't think there *is* a standard.  Here's the
> code/pattern for resolving from the local repo:
>
>
> https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/Update.scala#L379-L387
>
> https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/BootConfiguration.scala#L30-L32
>
> Also, for loading sbt-plugins we add the additional "scala/sbt" universe
> to the pattern:
>
>
> Someone more qualified than I in the Ivy can answer whether that's a
> "default" thing.
>
>
>
>
> On Thu, Apr 10, 2014 at 3:00 AM, Ben McCann  wrote:
>
>> Hi,
>>
>> I'm using SBT and Gradle as build systems. I want them to publish to and
>> read from ~/.ivy2 but they use and expect default layouts and so they do
>> not cooperate well each other using this directory. I'm wondering which
>> one
>> is right and which one is wrong.
>>
>> Also, I downloaded the latest ivy source to check what layout it uses. I
>> noticed the fields IvyRepResolver.DEFAULT_IVYPATTERN and
>> IvyRepResolver.DEFAULT_IVYROOT are unused. Should they be removed? The
>> latter points to what appears to be an abandoned domain as the page is
>> filled with adds and a link stating "Buy this domain".
>>
>> Thanks,
>> Ben
>>
>> --
>> about.me/benmccann
>>
>
>

Re: Standard repository layout?

[Josh Suereth]

Ben -

Do you mean "~/.ivy2/local" or  "~/.ivy2/cache"  ?

AFAIK the cache bit is the same in sbt as for Ivy, caveat that we try to
ignore what resolver an artifact came from in the store.  However, Gradle's
cache is a completely different beast, so the I don't think the two are
compatible.

Now for the local-project, we could very-well have something non-standard
in there, although I don't think there *is* a standard.  Here's the
code/pattern for resolving from the local repo:

https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/Update.scala#L379-L387
https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/BootConfiguration.scala#L30-L32

Also, for loading sbt-plugins we add the additional "scala/sbt" universe to
the pattern:


Someone more qualified than I in the Ivy can answer whether that's a
"default" thing.




On Thu, Apr 10, 2014 at 3:00 AM, Ben McCann  wrote:

> Hi,
>
> I'm using SBT and Gradle as build systems. I want them to publish to and
> read from ~/.ivy2 but they use and expect default layouts and so they do
> not cooperate well each other using this directory. I'm wondering which one
> is right and which one is wrong.
>
> Also, I downloaded the latest ivy source to check what layout it uses. I
> noticed the fields IvyRepResolver.DEFAULT_IVYPATTERN and
> IvyRepResolver.DEFAULT_IVYROOT are unused. Should they be removed? The
> latter points to what appears to be an abandoned domain as the page is
> filled with adds and a link stating "Buy this domain".
>
> Thanks,
> Ben
>
> --
> about.me/benmccann
>

Standard repository layout?

[Ben McCann]

Hi,

I'm using SBT and Gradle as build systems. I want them to publish to and
read from ~/.ivy2 but they use and expect default layouts and so they do
not cooperate well each other using this directory. I'm wondering which one
is right and which one is wrong.

Also, I downloaded the latest ivy source to check what layout it uses. I
noticed the fields IvyRepResolver.DEFAULT_IVYPATTERN and
IvyRepResolver.DEFAULT_IVYROOT are unused. Should they be removed? The
latter points to what appears to be an abandoned domain as the page is
filled with adds and a link stating "Buy this domain".

Thanks,
Ben

-- 
about.me/benmccann

Ivy to resolve dependencies against plain repository

[Akshat Bhargava]

Hi,

I have a repository which doesn't have ivy.xml and due to constraints we
cannot add any such file.
The repository has basic structure with only jars and no other files.
Using ivy can we map dependency to jars on such repository without making
any custom classes/ plugins ? If so, would be helpful in case you can point
me to something.

Thanks,
Akshat

Re: Testing of a mirrored Eclipse P2 repository

[Nicolas Lalevée]

After further investigation, I had a corrupted jar in the update I have build, 
probably corrupted when I uploaded it since I had a quite terrible connection 
at that time. The hash was not OK. Too bad Eclipse get crazy about it and 
redownloaded again and again...

It looks good now.

Nicolas

Le 6 nov. 2011 à 23:54, Nicolas Lalevée a écrit :

> Here is some update of the setup of the P2 repositories.
> I think I have finished the build scripts. I have done some tests, and I 
> don't know if it works.
> 
> Short story: Eclipse is doing weird stuff, I don't understand what it is 
> doing, I'll try to investigate deeper later.
> 
> Longer story:
> I have put some snapshot build of both Ivy and IvyDE and a p2 repo at 
> http://people.apache.org/~hibou/testp2/. It references my two snapshot 
> builds, plus some inexistent p2 repo on archive.apache.org, and I have my 
> snapshot builds declared as mirrored on the apache mirrors.
> 
> The first phase which is about gathering metadata of the plugins, everything 
> goes to people.a.o and archive.a.o, as expected.
> 
> Then when I ask Eclipse to effectively install my plugins, I nicely get the 
> mirror list.
> I have seen it try to get my plugins from the mirrors, the url looks good, 
> and it finds there obviously nothing. That's OK. At some point it ends up 
> trying to get the artifact not from the mirror but from people.a.o. The 
> plugins gets downloaded. Still OK.
> But then I have seen very weird stuff...
> It tried again to download the plugin from a mirror, hitting 404. And then it 
> downloaded the plugins about 10 times from people.a.o. Then it tried to get 
> from another mirror. Then again 10 times download from people. And again and 
> again for about 20 minutes.. until I canceled the install.
> If you may, I would say, wtf ?
> 
> Maybe Eclipse doesn't like when so many mirrors are returning 404 ? Or when 
> some repositories are missing ?
> I'll give another try later. Test with another site than people. Test without 
> mirroring, without archive.a.o, etc
> 
> 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

Testing of a mirrored Eclipse P2 repository

[Nicolas Lalevée]

Here is some update of the setup of the P2 repositories.
I think I have finished the build scripts. I have done some tests, and I 
don't know if it works.

Short story: Eclipse is doing weird stuff, I don't understand what it is doing, 
I'll try to investigate deeper later.

Longer story:
I have put some snapshot build of both Ivy and IvyDE and a p2 repo at 
http://people.apache.org/~hibou/testp2/. It references my two snapshot builds, 
plus some inexistent p2 repo on archive.apache.org, and I have my snapshot 
builds declared as mirrored on the apache mirrors.

The first phase which is about gathering metadata of the plugins, everything 
goes to people.a.o and archive.a.o, as expected.

Then when I ask Eclipse to effectively install my plugins, I nicely get the 
mirror list.
I have seen it try to get my plugins from the mirrors, the url looks good, and 
it finds there obviously nothing. That's OK. At some point it ends up trying to 
get the artifact not from the mirror but from people.a.o. The plugins gets 
downloaded. Still OK.
But then I have seen very weird stuff...
It tried again to download the plugin from a mirror, hitting 404. And then it 
downloaded the plugins about 10 times from people.a.o. Then it tried to get 
from another mirror. Then again 10 times download from people. And again and 
again for about 20 minutes.. until I canceled the install.
If you may, I would say, wtf ?

Maybe Eclipse doesn't like when so many mirrors are returning 404 ? Or when 
some repositories are missing ?
I'll give another try later. Test with another site than people. Test without 
mirroring, without archive.a.o, etc

Nicolas


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

Re: Sources of the ant jars into the maven repository

[Antoine Levy-Lambert]

We will see when we will do the next release.

Regards,

Antoine

On 4/19/2011 8:05 AM, Nicolas Lalevée wrote:

I have updated the build with the publication the source and javadoc jars 
(r1095053). I hope it will work fine with nexus since I am not used to use Ivy 
with nexus and I cannot actually test it.

Nicolas

Le 13 avr. 2011 à 14:36, Jesse Glick a écrit :


On 04/12/2011 02:06 PM, Nicolas Lalevée wrote:

Is there any objection regarding the publication of such jars ?

Please do so. In fact I am surprised that earlier releases were accepted into 
the Central repository without sources and Javadoc attached.

Note that you ought to be able to just run:

  mvn -f src/etc/poms/pom.xml -Prelease-profile -DskipTests install

but it seems to be broken. I tried to clean up src/etc/poms/ a while back. The main 
source of complexity is that there is a single source tree from which 22 JARs are built, 
and the division of sources into these JARs is not at all obvious. I proposed refactoring 
the tree into one source root per output JAR, each with its own classpath and 
dependencies, but there was no consensus among Ant committers to do so (thread: "Ant 
source tree reorganization").


-
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: Sources of the ant jars into the maven repository

[Nicolas Lalevée]

I have updated the build with the publication the source and javadoc jars 
(r1095053). I hope it will work fine with nexus since I am not used to use Ivy 
with nexus and I cannot actually test it.

Nicolas

Le 13 avr. 2011 à 14:36, Jesse Glick a écrit :

> On 04/12/2011 02:06 PM, Nicolas Lalevée wrote:
>> Is there any objection regarding the publication of such jars ?
> 
> Please do so. In fact I am surprised that earlier releases were accepted into 
> the Central repository without sources and Javadoc attached.
> 
> Note that you ought to be able to just run:
> 
>  mvn -f src/etc/poms/pom.xml -Prelease-profile -DskipTests install
> 
> but it seems to be broken. I tried to clean up src/etc/poms/ a while back. 
> The main source of complexity is that there is a single source tree from 
> which 22 JARs are built, and the division of sources into these JARs is not 
> at all obvious. I proposed refactoring the tree into one source root per 
> output JAR, each with its own classpath and dependencies, but there was no 
> consensus among Ant committers to do so (thread: "Ant source tree 
> reorganization").
> 
> 
> -
> 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: Sources of the ant jars into the maven repository

[Jesse Glick]

On 04/12/2011 02:06 PM, Nicolas Lalevée wrote:

Is there any objection regarding the publication of such jars ?


Please do so. In fact I am surprised that earlier releases were accepted into 
the Central repository without sources and Javadoc attached.

Note that you ought to be able to just run:

  mvn -f src/etc/poms/pom.xml -Prelease-profile -DskipTests install

but it seems to be broken. I tried to clean up src/etc/poms/ a while back. The main source of complexity is that there is a single source tree from which 22 JARs are 
built, and the division of sources into these JARs is not at all obvious. I proposed refactoring the tree into one source root per output JAR, each with its own classpath 
and dependencies, but there was no consensus among Ant committers to do so (thread: "Ant source tree reorganization").



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

Re: Sources of the ant jars into the maven repository

[wolfgang haefelinger]

> For what it's worth, a definite +1 from me.

+1

// Wolfgang

On Wed, Apr 13, 2011 at 1:18 PM, Steele, Richard  wrote:
> For what it's worth, a definite +1 from me.
>
> Rich
>
> 2011/4/12 Nicolas Lalevée 
>
>> Hi guys,
>>
>> The more I used automatic dependency management and working with open
>> source project, the more I expect to quickly have a development environment
>> in which I can debug. So I often expect to have the sources attached to the
>> jar I have automatically download. But for the ant jars, there are no source
>> attached.
>>
>> Currently the release of ant doesn't publish any source in the maven
>> repository via nexus. So I would like to change the build so that each ant
>> jar has its corresponding source jar. And I think I'll also make an
>> ant-1.8.3-javadocs.jar too. Theses jars would be only published to the maven
>> repository, they won't be part of the distribution tgz.
>>
>> Is there any objection regarding the publication of such jars ?
>>
>> Nicolas
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>



-- 
Wolfgang Häfelinger
häfelinger IT - Applied Information Technology
http://www.haefelinger.it

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

Re: Sources of the ant jars into the maven repository

[Steele, Richard]

For what it's worth, a definite +1 from me.

Rich

2011/4/12 Nicolas Lalevée 

> Hi guys,
>
> The more I used automatic dependency management and working with open
> source project, the more I expect to quickly have a development environment
> in which I can debug. So I often expect to have the sources attached to the
> jar I have automatically download. But for the ant jars, there are no source
> attached.
>
> Currently the release of ant doesn't publish any source in the maven
> repository via nexus. So I would like to change the build so that each ant
> jar has its corresponding source jar. And I think I'll also make an
> ant-1.8.3-javadocs.jar too. Theses jars would be only published to the maven
> repository, they won't be part of the distribution tgz.
>
> Is there any objection regarding the publication of such jars ?
>
> Nicolas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Sources of the ant jars into the maven repository

[Antoine Levy-Lambert]

This sounds good to me too.
Antoine

On 4/12/2011 2:45 PM, Dominique Devienne wrote:

2011/4/12 Nicolas Lalevée:

The more I used automatic dependency management and working with open source 
project, the more I expect to quickly have a development environment in which I 
can debug. So I often expect to have the sources attached to the jar I have 
automatically download. But for the ant jars, there are no source attached.

[DD] Agreed. I did something similar in a now defunct ad-hoc Ivy
look-alike, and it also guarantees access to the exact sources used to
produce the jar(s) without having to hunt for them in the SCM using a
tag or rev.


Currently the release of ant doesn't publish any source in the maven repository 
via nexus. So I would like to change the build so that each ant jar has its 
corresponding source jar. And I think I'll also make an ant-1.8.3-javadocs.jar 
too. Theses jars would be only published to the maven repository, they won't be 
part of the distribution tgz.

[DD] +1.


Is there any objection regarding the publication of such jars ?

[DD] Sounds reasonable to me. --DD




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

Re: Sources of the ant jars into the maven repository

[Dominique Devienne]

2011/4/12 Nicolas Lalevée :
> The more I used automatic dependency management and working with open source 
> project, the more I expect to quickly have a development environment in which 
> I can debug. So I often expect to have the sources attached to the jar I have 
> automatically download. But for the ant jars, there are no source attached.

[DD] Agreed. I did something similar in a now defunct ad-hoc Ivy
look-alike, and it also guarantees access to the exact sources used to
produce the jar(s) without having to hunt for them in the SCM using a
tag or rev.

> Currently the release of ant doesn't publish any source in the maven 
> repository via nexus. So I would like to change the build so that each ant 
> jar has its corresponding source jar. And I think I'll also make an 
> ant-1.8.3-javadocs.jar too. Theses jars would be only published to the maven 
> repository, they won't be part of the distribution tgz.

[DD] +1.

> Is there any objection regarding the publication of such jars ?

[DD] Sounds reasonable to me. --DD

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

Sources of the ant jars into the maven repository

[Nicolas Lalevée]

Hi guys,

The more I used automatic dependency management and working with open source 
project, the more I expect to quickly have a development environment in which I 
can debug. So I often expect to have the sources attached to the jar I have 
automatically download. But for the ant jars, there are no source attached.

Currently the release of ant doesn't publish any source in the maven repository 
via nexus. So I would like to change the build so that each ant jar has its 
corresponding source jar. And I think I'll also make an ant-1.8.3-javadocs.jar 
too. Theses jars would be only published to the maven repository, they won't be 
part of the distribution tgz.

Is there any objection regarding the publication of such jars ?

Nicolas


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

Issue Different Time Zone - IVY Repository

[Prakash Karnati]

Hi,

I have one query on IVY repository.

My Ivy repository is placed in a different time zone (Let's assume United 
States Central), And I am working in a different time zone (Let's assume 
India). Now I need to download the latest time stamped jar from the remote ivy 
repository to my workstation (located in India).

Problem being faced: Ivy on my workstation is not downloading the file from 
remote repository and is picking up the one in local repository because the 
clock on my workstation is on a different time zone that the clock on the 
remote repository.

What I would like to know is how to resolve dependencies and download latest 
jar across time zones.

And also I am attaching the ivysettings xml file.




Please send reply ASAP.


Prakkash K
Development | HJS
Mobile: +91 9620207756
Email: prakash.karn...@sprint.com
pkarn...@sapient.com
www.sapientnitro.com<http://www.sapientnitro.com/>





	
	
	 
	 
	
	
	
	

	
	http://144.226.220.254:8001/ivyrepository"; override="true"/>
	
	
	
	 
			 
			


			

	  
			


			
			



			  
			



			 
	  
	  
	

	
	
	 

	 
		
 
	 


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

Upload of ant 1.8.1 in maven2 repository

[Antoine Levy-Lambert]

Hi,

I have just seen that there is some inconsistency in the upload of ant 1.8.1 in 
the maven2 repository, the jars have been uploaded to new directories [1] but 
the maven-metadata.xml files have not been updated [2].

I have reported this to the repository team on a parallel email and will keep 
you posted.

Regards,

Antoine
[1] http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.8.1/
[2] http://repo1.maven.org/maven2/org/apache/ant/ant-parent/maven-metadata.xml

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

FishEye view of pache Ant repository

[Gilles Scokart]

I was not aware of it. Maybe others here might not be neither.

http://fisheye6.atlassian.com/browse/ant


-- 
Gilles Scokart

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: svn commit: r705232 [1/2] - in /ant/core/trunk/src/tests/antunit/taskdefs/cvs: ./ repository/ repository/CVSROOT/ repository/CVSROOT/Emptydir/ repository/antmodule1/

[Jan.Materne]

We could store a svn repo in that cvs for testing the svn tasks :-O

Jan 

>-Ursprüngliche Nachricht-
>Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
>Gesendet: Freitag, 17. Oktober 2008 09:50
>An: dev@ant.apache.org
>Betreff: Re: svn commit: r705232 [1/2] - in 
>/ant/core/trunk/src/tests/antunit/taskdefs/cvs: ./ repository/ 
>repository/CVSROOT/ repository/CVSROOT/Emptydir/ repository/antmodule1/
>
>On Fri, 17 Oct 2008, Gilles Scokart <[EMAIL PROTECTED]> wrote:
>
>> A CVS repository in Subversion...
>> Amazing :-)
>
>yeah, found it wierd as well.
>
>BTW, I think this wouldn't be possible if we still used CVS since CVS
>wouldn't have allowed me to check in the CVSROOT directory.
>
>Stefan
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r705232 [1/2] - in /ant/core/trunk/src/tests/antunit/taskdefs/cvs: ./ repository/ repository/CVSROOT/ repository/CVSROOT/Emptydir/ repository/antmodule1/

[Stefan Bodewig]

On Fri, 17 Oct 2008, Gilles Scokart <[EMAIL PROTECTED]> wrote:

> A CVS repository in Subversion...
> Amazing :-)

yeah, found it wierd as well.

BTW, I think this wouldn't be possible if we still used CVS since CVS
wouldn't have allowed me to check in the CVSROOT directory.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r705232 [1/2] - in /ant/core/trunk/src/tests/antunit/taskdefs/cvs: ./ repository/ repository/CVSROOT/ repository/CVSROOT/Emptydir/ repository/antmodule1/

[Gilles Scokart]

A CVS repository in Subversion...
Amazing :-)



2008/10/16  <[EMAIL PROTECTED]>:
> Author: bodewig
> Date: Thu Oct 16 06:00:46 2008
> New Revision: 705232
>
> URL: http://svn.apache.org/viewvc?rev=705232&view=rev
> Log:
> experimental local CVS repository as a testbed for CVS tests
>
> Added:
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#checkoutlist
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#commitinfo
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#config
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#cvswrappers
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#loginfo
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#modules
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#notify
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#postadmin
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#postproxy
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#posttag
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#postwatch
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#preproxy
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#rcsinfo
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#taginfo
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#verifymsg
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/Emptydir/
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/checkoutlist
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/checkoutlist,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/commitinfo
>    
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/commitinfo,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/config
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/config,v
>    
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/cvswrappers
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/cvswrappers,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/history
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/loginfo
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/loginfo,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/modules
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/modules,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/notify
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/notify,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/postadmin
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/postadmin,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/postproxy
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/postproxy,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/posttag
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/posttag,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/postwatch
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/postwatch,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/preproxy
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/preproxy,v
>    ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/rcsinfo
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/rcsinfo,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/taginfo
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/taginfo,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/val-tags
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/verifymsg
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/verifymsg,v
>ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/antmodule1/
>
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/antmodule1/foo.txt,v
>
> Added: 
> ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.#checkoutlist
> URL: 
> http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/taskdefs/cvs/repository/CVSROOT/.%23checkoutlist?rev=705232&view=auto


-- 
Gilles Scokart

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java src/java/org/apache/ivy/plugins/repository/ssh/SshRepository

[Maarten Coene]

publishPermissions is fine for me, we can use the "chmod mode" terminology in 
the documentation of this attribute.

Maarten

- Original Message 
From: Xavier Hanin <[EMAIL PROTECTED]>
To: Ant Developers List 
Sent: Friday, April 4, 2008 9:45:57 AM
Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt 
doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java 
src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java

On Fri, Apr 4, 2008 at 9:24 AM, Maarten Coene <[EMAIL PROTECTED]>
wrote:

> Btw, in the manual for chmod, they use the "mode" terminology for this
> kind of information.

Maybe it's only me then, but I think mode is too generic in this situation.
Moreover we have resolveMode option on the resolve task (introduced
recently), and I think we could later end up with the same kind of need on
publish, in which case we couldn't use publishMode to avoid the confusion if
we keep it for this attribute. What do you think?

Xavier


>
>
> Maarten
>
> - Original Message 
> From: Maarten Coene <[EMAIL PROTECTED]>
> To: Ant Developers List 
> Sent: Friday, April 4, 2008 9:19:57 AM
> Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt
> doc/resolver/ssh.html
> src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
>
> It was hardcoded to 0600 in Scp.java before I made this change. To keep it
> BC, I defaulted it to the same value. As far as I could see, the umask
> wasn't used. Since this attribute is only used for publishing modules, not
> for module retrieval, I think we should at least keep "publish" in the
> attribute name, but renaming 'mode' to 'permissions' (or something else) is
> fine for me.
>
> Maarten
>
> - Original Message 
> From: Xavier Hanin <[EMAIL PROTECTED]>
> To: dev@ant.apache.org
> Sent: Friday, April 4, 2008 8:51:18 AM
> Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt
> doc/resolver/ssh.html
> src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
>
> On Fri, Apr 4, 2008 at 12:49 AM, <[EMAIL PROTECTED]> wrote:
>
> > Author: maartenc
> > Date: Thu Apr  3 15:49:49 2008
> > New Revision: 644541
> >
> > URL: http://svn.apache.org/viewvc?rev=644541&view=rev
> > Log:
> > IMPROVEMENT: make it possible to specify permissions of published files
> > for the SSH resolver (IVY-764) + removal of some unused code
> >
> > Modified:
> >ant/ivy/core/trunk/CHANGES.txt
> >ant/ivy/core/trunk/doc/resolver/ssh.html
> >
> >
>  ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> >
> >
>  
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
> >
> > Modified: ant/ivy/core/trunk/CHANGES.txt
> > URL:
> >
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=644541&r1=644540&r2=644541&view=diff
> >
> >
> ==
> > --- ant/ivy/core/trunk/CHANGES.txt (original)
> > +++ ant/ivy/core/trunk/CHANGES.txt Thu Apr  3 15:49:49 2008
> > @@ -69,6 +69,7 @@
> >  - NEW: Add a new resolve mode (optionally per module) to utilize
> dynamic
> > constraint rule metadata (IVY-740)
> >  - NEW: Add transitive dependency version and branch override mechanism
> > (IVY-784)
> >
> > +- IMPROVEMENT: make it possible to specify permissions of published
> files
> > for the SSH resolver (IVY-764)
> >  - IMPROVEMENT: Load Ivy version number into some Ant property (IVY-790)
> >  - IMPROVEMENT: Make Ivy standalone runnable with no required
> dependencies
> > (IVY-757)
> >  - IMPROVEMENT: add branch attribute in ivy:install task (IVY-727)
> >
> > Modified: ant/ivy/core/trunk/doc/resolver/ssh.html
> > URL:
> >
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/doc/resolver/ssh.html?rev=644541&r1=644540&r2=644541&view=diff
> >
> >
> ==
> > --- ant/ivy/core/trunk/doc/resolver/ssh.html (original)
> > +++ ant/ivy/core/trunk/doc/resolver/ssh.html Thu Apr  3 15:49:49 2008
> > @@ -56,6 +56,8 @@
> > No, defaults to host given on the patterns, fail if none is
> > set
> > portThe port to connect to
> > No, defaults to 22
> > +publishModeA four digit string (e.g., 0644, see
> "man
> > chmod", "

Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java src/java/org/apache/ivy/plugins/repository/ssh/SshRepository

[Xavier Hanin]

On Fri, Apr 4, 2008 at 9:24 AM, Maarten Coene <[EMAIL PROTECTED]>
wrote:

> Btw, in the manual for chmod, they use the "mode" terminology for this
> kind of information.

Maybe it's only me then, but I think mode is too generic in this situation.
Moreover we have resolveMode option on the resolve task (introduced
recently), and I think we could later end up with the same kind of need on
publish, in which case we couldn't use publishMode to avoid the confusion if
we keep it for this attribute. What do you think?

Xavier


>
>
> Maarten
>
> - Original Message 
> From: Maarten Coene <[EMAIL PROTECTED]>
> To: Ant Developers List 
> Sent: Friday, April 4, 2008 9:19:57 AM
> Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt
> doc/resolver/ssh.html
> src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
>
> It was hardcoded to 0600 in Scp.java before I made this change. To keep it
> BC, I defaulted it to the same value. As far as I could see, the umask
> wasn't used. Since this attribute is only used for publishing modules, not
> for module retrieval, I think we should at least keep "publish" in the
> attribute name, but renaming 'mode' to 'permissions' (or something else) is
> fine for me.
>
> Maarten
>
> - Original Message 
> From: Xavier Hanin <[EMAIL PROTECTED]>
> To: dev@ant.apache.org
> Sent: Friday, April 4, 2008 8:51:18 AM
> Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt
> doc/resolver/ssh.html
> src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
>
> On Fri, Apr 4, 2008 at 12:49 AM, <[EMAIL PROTECTED]> wrote:
>
> > Author: maartenc
> > Date: Thu Apr  3 15:49:49 2008
> > New Revision: 644541
> >
> > URL: http://svn.apache.org/viewvc?rev=644541&view=rev
> > Log:
> > IMPROVEMENT: make it possible to specify permissions of published files
> > for the SSH resolver (IVY-764) + removal of some unused code
> >
> > Modified:
> >ant/ivy/core/trunk/CHANGES.txt
> >ant/ivy/core/trunk/doc/resolver/ssh.html
> >
> >
>  ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> >
> >
>  
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
> >
> > Modified: ant/ivy/core/trunk/CHANGES.txt
> > URL:
> >
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=644541&r1=644540&r2=644541&view=diff
> >
> >
> ==
> > --- ant/ivy/core/trunk/CHANGES.txt (original)
> > +++ ant/ivy/core/trunk/CHANGES.txt Thu Apr  3 15:49:49 2008
> > @@ -69,6 +69,7 @@
> >  - NEW: Add a new resolve mode (optionally per module) to utilize
> dynamic
> > constraint rule metadata (IVY-740)
> >  - NEW: Add transitive dependency version and branch override mechanism
> > (IVY-784)
> >
> > +- IMPROVEMENT: make it possible to specify permissions of published
> files
> > for the SSH resolver (IVY-764)
> >  - IMPROVEMENT: Load Ivy version number into some Ant property (IVY-790)
> >  - IMPROVEMENT: Make Ivy standalone runnable with no required
> dependencies
> > (IVY-757)
> >  - IMPROVEMENT: add branch attribute in ivy:install task (IVY-727)
> >
> > Modified: ant/ivy/core/trunk/doc/resolver/ssh.html
> > URL:
> >
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/doc/resolver/ssh.html?rev=644541&r1=644540&r2=644541&view=diff
> >
> >
> ==
> > --- ant/ivy/core/trunk/doc/resolver/ssh.html (original)
> > +++ ant/ivy/core/trunk/doc/resolver/ssh.html Thu Apr  3 15:49:49 2008
> > @@ -56,6 +56,8 @@
> > No, defaults to host given on the patterns, fail if none is
> > set
> > portThe port to connect to
> > No, defaults to 22
> > +publishModeA four digit string (e.g., 0644, see
> "man
> > chmod", "man open") specifying the permissions of the published files.
>  > class="since">(since 2.0)
> > +No, defaults to 0600
>
> Is it a good idea to give a default value to this attribute? This will
> break
> BC, it used to be using the umask, right? I wonder if the default
> shouldn't
> be "use the umask" to preserve BC. WDYT?
>
> BTW, I don't like the name "publishMode". What do you think of
> "permis

Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java src/java/org/apache/ivy/plugins/repository/ssh/SshRepository

[Maarten Coene]

Btw, in the manual for chmod, they use the "mode" terminology for this kind of 
information.

Maarten

- Original Message 
From: Maarten Coene <[EMAIL PROTECTED]>
To: Ant Developers List 
Sent: Friday, April 4, 2008 9:19:57 AM
Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt 
doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java 
src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java

It was hardcoded to 0600 in Scp.java before I made this change. To keep it BC, 
I defaulted it to the same value. As far as I could see, the umask wasn't used. 
Since this attribute is only used for publishing modules, not for module 
retrieval, I think we should at least keep "publish" in the attribute name, but 
renaming 'mode' to 'permissions' (or something else) is fine for me.

Maarten

- Original Message 
From: Xavier Hanin <[EMAIL PROTECTED]>
To: dev@ant.apache.org
Sent: Friday, April 4, 2008 8:51:18 AM
Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt 
doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java 
src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java

On Fri, Apr 4, 2008 at 12:49 AM, <[EMAIL PROTECTED]> wrote:

> Author: maartenc
> Date: Thu Apr  3 15:49:49 2008
> New Revision: 644541
>
> URL: http://svn.apache.org/viewvc?rev=644541&view=rev
> Log:
> IMPROVEMENT: make it possible to specify permissions of published files
> for the SSH resolver (IVY-764) + removal of some unused code
>
> Modified:
>ant/ivy/core/trunk/CHANGES.txt
>ant/ivy/core/trunk/doc/resolver/ssh.html
>
>  ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
>
>  
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
>
> Modified: ant/ivy/core/trunk/CHANGES.txt
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=644541&r1=644540&r2=644541&view=diff
>
> ==
> --- ant/ivy/core/trunk/CHANGES.txt (original)
> +++ ant/ivy/core/trunk/CHANGES.txt Thu Apr  3 15:49:49 2008
> @@ -69,6 +69,7 @@
>  - NEW: Add a new resolve mode (optionally per module) to utilize dynamic
> constraint rule metadata (IVY-740)
>  - NEW: Add transitive dependency version and branch override mechanism
> (IVY-784)
>
> +- IMPROVEMENT: make it possible to specify permissions of published files
> for the SSH resolver (IVY-764)
>  - IMPROVEMENT: Load Ivy version number into some Ant property (IVY-790)
>  - IMPROVEMENT: Make Ivy standalone runnable with no required dependencies
> (IVY-757)
>  - IMPROVEMENT: add branch attribute in ivy:install task (IVY-727)
>
> Modified: ant/ivy/core/trunk/doc/resolver/ssh.html
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/doc/resolver/ssh.html?rev=644541&r1=644540&r2=644541&view=diff
>
> ==
> --- ant/ivy/core/trunk/doc/resolver/ssh.html (original)
> +++ ant/ivy/core/trunk/doc/resolver/ssh.html Thu Apr  3 15:49:49 2008
> @@ -56,6 +56,8 @@
> No, defaults to host given on the patterns, fail if none is
> set
> portThe port to connect to
> No, defaults to 22
> +publishModeA four digit string (e.g., 0644, see "man
> chmod", "man open") specifying the permissions of the published files.  class="since">(since 2.0)
> +No, defaults to 0600

Is it a good idea to give a default value to this attribute? This will break
BC, it used to be using the umask, right? I wonder if the default shouldn't
be "use the umask" to preserve BC. WDYT?

BTW, I don't like the name "publishMode". What do you think of "permissions"
or "umask"?

Xavier



>
>  
>  
>  Child elements
>
> Modified:
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java?rev=644541&r1=644540&r2=644541&view=diff
>
> ==
> ---
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> (original)
> +++
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> Thu Apr  3 15:49:49 2008
> @@ -276,41 +276,6 @@
> fileInfo.setLastModified(modtime);
> }
>
> -private void sendBytes(Channel channel, byte[] data, String fileName,
> String mode)
> -throws IOException, RemoteScpException {
> -OutputStream os = channel.getOutputS

Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java src/java/org/apache/ivy/plugins/repository/ssh/SshRepository

[Xavier Hanin]

On Fri, Apr 4, 2008 at 9:19 AM, Maarten Coene <[EMAIL PROTECTED]>
wrote:

> It was hardcoded to 0600 in Scp.java before I made this change. To keep it
> BC, I defaulted it to the same value.

OK, I didn't see that, I thought it was using umask according to the
discussions on the issue. Sorry about that.


> As far as I could see, the umask wasn't used. Since this attribute is only
> used for publishing modules, not for module retrieval, I think we should at
> least keep "publish" in the attribute name, but renaming 'mode' to
> 'permissions' (or something else) is fine for me.

Indeed, so I prefer publishPermissions.

Xavier


>
> Maarten
>
> - Original Message 
> From: Xavier Hanin <[EMAIL PROTECTED]>
> To: dev@ant.apache.org
> Sent: Friday, April 4, 2008 8:51:18 AM
> Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt
> doc/resolver/ssh.html
> src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
>
> On Fri, Apr 4, 2008 at 12:49 AM, <[EMAIL PROTECTED]> wrote:
>
> > Author: maartenc
> > Date: Thu Apr  3 15:49:49 2008
> > New Revision: 644541
> >
> > URL: http://svn.apache.org/viewvc?rev=644541&view=rev
> > Log:
> > IMPROVEMENT: make it possible to specify permissions of published files
> > for the SSH resolver (IVY-764) + removal of some unused code
> >
> > Modified:
> >ant/ivy/core/trunk/CHANGES.txt
> >    ant/ivy/core/trunk/doc/resolver/ssh.html
> >
> >
>  ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> >
> >
>  
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
> >
> > Modified: ant/ivy/core/trunk/CHANGES.txt
> > URL:
> >
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=644541&r1=644540&r2=644541&view=diff
> >
> >
> ==
> > --- ant/ivy/core/trunk/CHANGES.txt (original)
> > +++ ant/ivy/core/trunk/CHANGES.txt Thu Apr  3 15:49:49 2008
> > @@ -69,6 +69,7 @@
> >  - NEW: Add a new resolve mode (optionally per module) to utilize
> dynamic
> > constraint rule metadata (IVY-740)
> >  - NEW: Add transitive dependency version and branch override mechanism
> > (IVY-784)
> >
> > +- IMPROVEMENT: make it possible to specify permissions of published
> files
> > for the SSH resolver (IVY-764)
> >  - IMPROVEMENT: Load Ivy version number into some Ant property (IVY-790)
> >  - IMPROVEMENT: Make Ivy standalone runnable with no required
> dependencies
> > (IVY-757)
> >  - IMPROVEMENT: add branch attribute in ivy:install task (IVY-727)
> >
> > Modified: ant/ivy/core/trunk/doc/resolver/ssh.html
> > URL:
> >
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/doc/resolver/ssh.html?rev=644541&r1=644540&r2=644541&view=diff
> >
> >
> ==
> > --- ant/ivy/core/trunk/doc/resolver/ssh.html (original)
> > +++ ant/ivy/core/trunk/doc/resolver/ssh.html Thu Apr  3 15:49:49 2008
> > @@ -56,6 +56,8 @@
> > No, defaults to host given on the patterns, fail if none is
> > set
> > portThe port to connect to
> > No, defaults to 22
> > +publishModeA four digit string (e.g., 0644, see
> "man
> > chmod", "man open") specifying the permissions of the published files.
>  > class="since">(since 2.0)
> > +No, defaults to 0600
>
> Is it a good idea to give a default value to this attribute? This will
> break
> BC, it used to be using the umask, right? I wonder if the default
> shouldn't
> be "use the umask" to preserve BC. WDYT?
>
> BTW, I don't like the name "publishMode". What do you think of
> "permissions"
> or "umask"?
>
> Xavier
>
>
>
> >
> >  
> >  
> >  Child elements
> >
> > Modified:
> >
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> > URL:
> >
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java?rev=644541&r1=644540&r2=644541&view=diff
> >
> >
> ==
> > ---
> >
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> > (original)
> > +++
> >
> ant/ivy/core/

Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java src/java/org/apache/ivy/plugins/repository/ssh/SshRepository

[Maarten Coene]

It was hardcoded to 0600 in Scp.java before I made this change. To keep it BC, 
I defaulted it to the same value. As far as I could see, the umask wasn't used. 
Since this attribute is only used for publishing modules, not for module 
retrieval, I think we should at least keep "publish" in the attribute name, but 
renaming 'mode' to 'permissions' (or something else) is fine for me.

Maarten

- Original Message 
From: Xavier Hanin <[EMAIL PROTECTED]>
To: dev@ant.apache.org
Sent: Friday, April 4, 2008 8:51:18 AM
Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt 
doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java 
src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java

On Fri, Apr 4, 2008 at 12:49 AM, <[EMAIL PROTECTED]> wrote:

> Author: maartenc
> Date: Thu Apr  3 15:49:49 2008
> New Revision: 644541
>
> URL: http://svn.apache.org/viewvc?rev=644541&view=rev
> Log:
> IMPROVEMENT: make it possible to specify permissions of published files
> for the SSH resolver (IVY-764) + removal of some unused code
>
> Modified:
>ant/ivy/core/trunk/CHANGES.txt
>ant/ivy/core/trunk/doc/resolver/ssh.html
>
>  ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
>
>  
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
>
> Modified: ant/ivy/core/trunk/CHANGES.txt
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=644541&r1=644540&r2=644541&view=diff
>
> ==
> --- ant/ivy/core/trunk/CHANGES.txt (original)
> +++ ant/ivy/core/trunk/CHANGES.txt Thu Apr  3 15:49:49 2008
> @@ -69,6 +69,7 @@
>  - NEW: Add a new resolve mode (optionally per module) to utilize dynamic
> constraint rule metadata (IVY-740)
>  - NEW: Add transitive dependency version and branch override mechanism
> (IVY-784)
>
> +- IMPROVEMENT: make it possible to specify permissions of published files
> for the SSH resolver (IVY-764)
>  - IMPROVEMENT: Load Ivy version number into some Ant property (IVY-790)
>  - IMPROVEMENT: Make Ivy standalone runnable with no required dependencies
> (IVY-757)
>  - IMPROVEMENT: add branch attribute in ivy:install task (IVY-727)
>
> Modified: ant/ivy/core/trunk/doc/resolver/ssh.html
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/doc/resolver/ssh.html?rev=644541&r1=644540&r2=644541&view=diff
>
> ==
> --- ant/ivy/core/trunk/doc/resolver/ssh.html (original)
> +++ ant/ivy/core/trunk/doc/resolver/ssh.html Thu Apr  3 15:49:49 2008
> @@ -56,6 +56,8 @@
> No, defaults to host given on the patterns, fail if none is
> set
> portThe port to connect to
> No, defaults to 22
> +publishModeA four digit string (e.g., 0644, see "man
> chmod", "man open") specifying the permissions of the published files.  class="since">(since 2.0)
> +No, defaults to 0600

Is it a good idea to give a default value to this attribute? This will break
BC, it used to be using the umask, right? I wonder if the default shouldn't
be "use the umask" to preserve BC. WDYT?

BTW, I don't like the name "publishMode". What do you think of "permissions"
or "umask"?

Xavier



>
>  
>  
>  Child elements
>
> Modified:
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java?rev=644541&r1=644540&r2=644541&view=diff
>
> ==
> ---
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> (original)
> +++
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> Thu Apr  3 15:49:49 2008
> @@ -276,41 +276,6 @@
> fileInfo.setLastModified(modtime);
> }
>
> -private void sendBytes(Channel channel, byte[] data, String fileName,
> String mode)
> -throws IOException, RemoteScpException {
> -OutputStream os = channel.getOutputStream();
> -InputStream is = new BufferedInputStream(
> -channel.getInputStream(), SEND_BYTES_BUFFER_LENGTH);
> -
> -try {
> -if (channel.isConnected()) {
> -channel.start();
> -} else {
> -channel.connect();
> -}
> -} catch (JSchException e1) {
> -throw (IOException) new IOException("Channel connection
> pro

Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANGES.txt doc/resolver/ssh.html src/java/org/apache/ivy/plugins/repository/ssh/Scp.java src/java/org/apache/ivy/plugins/repository/ssh/SshRepository

[Xavier Hanin]

On Fri, Apr 4, 2008 at 12:49 AM, <[EMAIL PROTECTED]> wrote:

> Author: maartenc
> Date: Thu Apr  3 15:49:49 2008
> New Revision: 644541
>
> URL: http://svn.apache.org/viewvc?rev=644541&view=rev
> Log:
> IMPROVEMENT: make it possible to specify permissions of published files
> for the SSH resolver (IVY-764) + removal of some unused code
>
> Modified:
>ant/ivy/core/trunk/CHANGES.txt
>ant/ivy/core/trunk/doc/resolver/ssh.html
>
>  ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
>
>  
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshRepository.java
>
> Modified: ant/ivy/core/trunk/CHANGES.txt
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=644541&r1=644540&r2=644541&view=diff
>
> ==
> --- ant/ivy/core/trunk/CHANGES.txt (original)
> +++ ant/ivy/core/trunk/CHANGES.txt Thu Apr  3 15:49:49 2008
> @@ -69,6 +69,7 @@
>  - NEW: Add a new resolve mode (optionally per module) to utilize dynamic
> constraint rule metadata (IVY-740)
>  - NEW: Add transitive dependency version and branch override mechanism
> (IVY-784)
>
> +- IMPROVEMENT: make it possible to specify permissions of published files
> for the SSH resolver (IVY-764)
>  - IMPROVEMENT: Load Ivy version number into some Ant property (IVY-790)
>  - IMPROVEMENT: Make Ivy standalone runnable with no required dependencies
> (IVY-757)
>  - IMPROVEMENT: add branch attribute in ivy:install task (IVY-727)
>
> Modified: ant/ivy/core/trunk/doc/resolver/ssh.html
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/doc/resolver/ssh.html?rev=644541&r1=644540&r2=644541&view=diff
>
> ==
> --- ant/ivy/core/trunk/doc/resolver/ssh.html (original)
> +++ ant/ivy/core/trunk/doc/resolver/ssh.html Thu Apr  3 15:49:49 2008
> @@ -56,6 +56,8 @@
> No, defaults to host given on the patterns, fail if none is
> set
> portThe port to connect to
> No, defaults to 22
> +publishModeA four digit string (e.g., 0644, see "man
> chmod", "man open") specifying the permissions of the published files.  class="since">(since 2.0)
> +No, defaults to 0600

Is it a good idea to give a default value to this attribute? This will break
BC, it used to be using the umask, right? I wonder if the default shouldn't
be "use the umask" to preserve BC. WDYT?

BTW, I don't like the name "publishMode". What do you think of "permissions"
or "umask"?

Xavier



>
>  
>  
>  Child elements
>
> Modified:
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> URL:
> http://svn.apache.org/viewvc/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java?rev=644541&r1=644540&r2=644541&view=diff
>
> ==
> ---
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> (original)
> +++
> ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/Scp.java
> Thu Apr  3 15:49:49 2008
> @@ -276,41 +276,6 @@
> fileInfo.setLastModified(modtime);
> }
>
> -private void sendBytes(Channel channel, byte[] data, String fileName,
> String mode)
> -throws IOException, RemoteScpException {
> -OutputStream os = channel.getOutputStream();
> -InputStream is = new BufferedInputStream(
> -channel.getInputStream(), SEND_BYTES_BUFFER_LENGTH);
> -
> -try {
> -if (channel.isConnected()) {
> -channel.start();
> -} else {
> -channel.connect();
> -}
> -} catch (JSchException e1) {
> -throw (IOException) new IOException("Channel connection
> problems").initCause(e1);
> -}
> -
> -readResponse(is);
> -
> -String cline = "C" + mode + " " + data.length + " " + fileName +
> "\n";
> -
> -os.write(cline.getBytes());
> -os.flush();
> -
> -readResponse(is);
> -
> -os.write(data, 0, data.length);
> -os.write(0);
> -os.flush();
> -
> -readResponse(is);
> -
> -os.write("E\n".getBytes());
> -os.flush();
> -}
> -
> private void sendFile(Channel channel, String localFile, String
> remoteName, String mode)
> throws IOException, RemoteScpException {
> byte[] buffer = new 

Re: Ivy Repository

[Nicolas Lalevée]

Le 30 déc. 07 à 11:37, Markus M. May a écrit :


Hello,

I got IVYDE from the repository and tried to build it. It tries to  
find IVY in the repository http://repo1.maven.org/maven2/apache  
which is non-existant.
I think as one of the primary projects using the reposoitory, we  
should definitly put IVY in the repository, right?


Anyway, I will now change the dependency, so that IVYDE uses the  
newest version of IVY on my local machine.


The dependencies of IvyDE have recently changed. Ivy is now an eclipse  
bundle, and so IvyDE depends on Ivy via the "Plug-in Dependencies". So  
as soon as you mount ivy and ivyde in Eclipse, the dependencies should  
be resolved automagically by Eclipse itself. You don't need anymore  
doing a "ant resolve".


Note also that IvyDE does not compile as there were some API change in  
Ivy. While providing a patch in IVYDE-68 I have fixed those.


cheers,
Nicolas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Ivy Repository

[Markus M. May]

Hello,

I got IVYDE from the repository and tried to build it. It tries to  
find IVY in the repository http://repo1.maven.org/maven2/apache which  
is non-existant.
I think as one of the primary projects using the reposoitory, we  
should definitly put IVY in the repository, right?


Anyway, I will now change the dependency, so that IVYDE uses the  
newest version of IVY on my local machine.


R,

Markus

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

intelligent repository cleaning (IVY-658)

[Xavier Hanin]

Hi,

I've started thinking at how to implement IVY-658, and it's not that easy to 
get information necessary to clean a repository intelligently.

To do so, we need to have information about the dependers of a module. If Ivy 
shines at finding dependees, it provides no way to access dependers, so this is 
something requiring some work.

To start with, I've developed a small prototype of a 
RepositoryManagementEngine, which actually loads all repository metadata in 
memory. First I didn't even consider that idea, because it doesn't scale. But 
since it was the easiest thing to start with, I gave it a try, and I now have 
something able to load a whole repository in memory, and able to return 
information such as the list of all modules with no dependers (the information 
needed for IVY-658). It could also be improved to easily to get other 
informations quickly, once everything is in memory it's pretty easy.

I'm currently doing my test on a linux box with sun jvm 1.4.2, accessing a 
NetApp filesystem repository (with very good performance). On this box I have 
this kind of results to load a repository of 1200 modules, 3000 module 
revisions: 40s, 60MB (memory usage is approximative, I've used an utility class 
based on [1]). If I extrapolate these results, here's what I get:
revstimememory
3k  40" 60MB
25k 6'  500MB
100k22' 2GB

I'm pretty happy with the time results (the environment is well suited for 
that, but since it's a repository maintenance task, I guess most people could 
run it very close to their repository data, during night or over a week-end).

As expected memory usage can more quickly become an issue. So I've done some 
investigation on memory usage, and it appears that the ModuleRevisionId have a 
significant impact on memory usage. Indeed these objects are used not only to 
identify the module revisions loaded, but also in each dependency descriptor to 
store the content of the requested module revision.

I've found that in my use case Ivy was creating around 50k instances of 
ModuleRevisionId. These objects being immutable, I've tried to use a strategy 
similar to String#intern() to reuse the same instance whenever possible. I'be 
then decreased the number to 6k instances, with a total memory used by the in 
memory repository information of 43MB (around 28% better).

Then I thought another area of improvement may be the dependency descriptors 
themselves (around 46k instances in my test case). In 
DefaultDependencyDescriptor, we create the instances of LinkedHashMap used to 
store information when we create the object. For the exclude rules, include 
rules and dependency artifacts, very frequently they are not used at all (never 
in my test case). So I've change DefaultDependencyDescriptor to init these 
attributes only when needed, and ended up with a 31MB footprint for the whole 
repository. So my new extrapolation is now:
revstimememory
3k  40" 31MB
25k 6'  260MB
100k22' 1.1GB

So I plan to commit these changes to Ivy trunk. The changes on 
DefaultDependencyDescriptor just makes the code slightly less readable, so I 
don't think it's an issue. For ModuleRevisionId, it introduces a very simple 
cache of instances based on a WeakHashMap. It means we have a get in a Map 
whenever we create a new ModuleRevisionId. I don't think it will impact the 
performance much, and may even decrease memory footprint for regular Ivy usage.

If you see any problem with that, feel free to let me know and we'll see how to 
address that differently.

BTW, the repository cleaning task is not done yet, just repository loading and 
basic analysis.

Xavier

 [1] 
http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFootprint.fm.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: Old CVS repository of Ant

[Jan.Materne]

Ant, as all Apache projects, have migrated in 2005/2006. I dont think that 
there are so "old" backups of the repository. But I am not sure about that ...


Jan 

>-Ursprüngliche Nachricht-
>Von: Beat Fluri [mailto:[EMAIL PROTECTED] 
>Gesendet: Freitag, 7. September 2007 14:55
>An: dev@ant.apache.org
>Betreff: Old CVS repository of Ant
>
>Hi,
>
>As a member of the Software Engineering group of the University  
>Zurich, Switzerland, I'm investigating the evolution of software  
>systems. For this, I'd like to use Ant as a case study.  
>Unfortunately, our tools are limited to CVS and not yet fully adapted  
>to Subversion. Is there a possibility to get an old version of the  
>former CVS repository of Ant? I would very appreciate to get Ant as a  
>case study.
>
>Thank you for your help.
>
>Best wishes,
>--Beat Fluri
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Old CVS repository of Ant

[Beat Fluri]

Hi,

As a member of the Software Engineering group of the University  
Zurich, Switzerland, I'm investigating the evolution of software  
systems. For this, I'd like to use Ant as a case study.  
Unfortunately, our tools are limited to CVS and not yet fully adapted  
to Subversion. Is there a possibility to get an old version of the  
former CVS repository of Ant? I would very appreciate to get Ant as a  
case study.


Thank you for your help.

Best wishes,
--Beat Fluri


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn repository access (svn dump)

[Andy Zaidman]

Hi there,
 
Together with a collegue of mine, Bart Van Rompaey, I am doing research on
how test code and production code co-evolve. Currently, we are focussing on
a number of open-source projects, mainly from Sourceforge, but we would like
to extend it to other projects as well, amongst others Apache projects. As
we are both avid Ant users, we would like to extend our research to Ant, but
for that we need your help: we would like to have access to the Ant
subversion repository.

As such, my question is: would it be possible to get a complete dump of the
svn of Ant. If needed, we can reserve some ftp space to upload this svn dump
to one of our university servers. 

Thank you in advance for your help!

Kind regards,

Bart Van Rompaey
http://www.win.ua.ac.be/~bvromp
Andy Zaidman
http://www.st.ewi.tudelft.nl/~zaidman



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Ant 1.7.0 jars in maven repository : now available

[Antoine Levy-Lambert]

Hi,

the Ant 1.7.0 jars are now available in the maven repository for maven2 based 
builds.

Note that the groupId is org.apache.ant, not ant like for ant 1.6.5.

Checksums fail though - I do not know the reasons but the colleagues at 
repository@ are aware of this.

Regards,

Antoine

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Upload of Ant to Maven repository [WAS: Re: Re: pgp key for signing files]

[Steve Loughran]

Antoine Levy-Lambert wrote:

Hi,

Steve had already sent an email to repository at apache dot org.

http://mail-archives.apache.org/mod_mbox/www-repository/200606.mbox/browser

Also,  Carlos Sanchez answered my JIRA issue, giving a pointer to :

http://www.apache.org/dev/release-publishing.html



see this too
http://jakarta.apache.org/commons/releases/index.html



http://www.apache.org/dist/java-repository/ant/jars is the source of
ibiblio.org regarding everything that comes from apache, so we do not
have to add uploads to other sites to ReleaseInstructions.

What we should do is  figure out how we are going to generate and upload
POM files (Maven project descriptors) to
http://www.apache.org/dist/java-repository/ant/jars. This possibly even
in 2 flavors for Maven 1 and Maven 2 ???



Pom2 files. they can downconvert.

This is roughly how we do it on smartfrog. If a project has a .pom file 
it gets copied with property expansion. Otherwise we  out a pom 
(this is ant1.6.5 compatible)



  
  
  
   depends="init,init-proxy,declare-extended-smartfrog-tasks">

   





location="${user.home}/.m2/repository" />





  
  
  
  
  

  






 
 
 
   



  
  
  

   
 
  
   

   
 
   

   
   
   
   

   

   

  
  
  
  
  





failonerror="false"/>


  


by default, stub poms declare no dependencies  *at all*.

for ant we could have a dir src/etc/pom into which the different pom 
templates for each component goes
e.g ant-junit.pom has a dependency on junit of ${junit.version}, and on 
ant-${ant.version}


the build

1. copies the templates with property expansion enabled (like 
"m2-copy-pom" above)

2. creates .md5 checksums of the poms and their artifacts
3. signs this stuff by 
4. scps the files and signatures to a location, the default being the 
apache repository, but with any other location supported.
5. could also have a stub announcement email in the same dir, do the 
same property-expanding-copy and GPG sign trick to produce authenticated 
email for the announcement


-steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Upload of Ant to Maven repository [WAS: Re: Re: pgp key for signing files]

[Antoine Levy-Lambert]

Hi,

Steve had already sent an email to repository at apache dot org.

http://mail-archives.apache.org/mod_mbox/www-repository/200606.mbox/browser

Also,  Carlos Sanchez answered my JIRA issue, giving a pointer to :

http://www.apache.org/dev/release-publishing.html

http://www.apache.org/dist/java-repository/ant/jars is the source of
ibiblio.org regarding everything that comes from apache, so we do not
have to add uploads to other sites to ReleaseInstructions.

What we should do is  figure out how we are going to generate and upload
POM files (Maven project descriptors) to
http://www.apache.org/dist/java-repository/ant/jars. This possibly even
in 2 flavors for Maven 1 and Maven 2 ???

On a related issue, we need to update ReleaseInstructions to take into
account that we moved to svn.

Regards,

Antoine

Antoine Levy-Lambert wrote:
> Hello,
>
> I have created an issue on the MAVEN JIRA to ask the MAVEN colleagues what 
> will be the procedure to upload Ant to the maven repository(ies).
>
> http://jira.codehaus.org/browse/MEV-412
>
> Steve, did you get any news from the repository colleagues ?
>
> Regards,
>
> Antoine
>
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Upload of Ant to Maven repository [WAS: Re: Re: pgp key for signing files]

[Antoine Levy-Lambert]

Hello,

I have created an issue on the MAVEN JIRA to ask the MAVEN colleagues what will 
be the procedure to upload Ant to the maven repository(ies).

http://jira.codehaus.org/browse/MEV-412

Steve, did you get any news from the repository colleagues ?

Regards,

Antoine

 Original-Nachricht 
Datum: Mon, 05 Jun 2006 17:03:13 +0100
Von: Steve Loughran <[EMAIL PROTECTED]>
An: Ant Developers List 
Betreff: Re: pgp key for signing files

> >> We also need to look at the release docs to see if it covers 
> >> distribution to the maven repository.
> > 
> > 
> > Does this directory [1] have something to do with Maven ?
> > There are instructions to populate it in the release instructions [2].
> > 
> > In any case I would be curious to know what is the use of this
> java-repository.
> 
> I'm checking with repository@apache.org, home of the repository police 
> -the "repo men" :)
> 
>  
> -steve
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r332493 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/

[stevel]

Author: stevel
Date: Fri Nov 11 00:49:12 2005
New Revision: 332493

URL: http://svn.apache.org/viewcvs?rev=332493&view=rev
Log:
delete the libraries prototype

Removed:
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r332492 - in /ant/core/trunk/src: etc/testcases/taskdefs/ main/org/apache/tools/ant/taskdefs/repository/ testcases/org/apache/tools/ant/taskdefs/

[stevel]

Author: stevel
Date: Fri Nov 11 00:44:54 2005
New Revision: 332492

URL: http://svn.apache.org/viewcvs?rev=332492&view=rev
Log:
delete the libraries prototype

Removed:
ant/core/trunk/src/etc/testcases/taskdefs/libraries.xml

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/AbsentFilesPolicy.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/AssertDownloaded.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/BaseLibraryPolicy.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/EnabledLibraryElement.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/EnabledLibraryElementList.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/ForceUpdatePolicy.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/HttpRepository.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/Libraries.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/Library.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/LibraryPolicy.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/MavenRepository.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/NoUpdatePolicy.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/Repository.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/RepositoryRef.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/ScheduledUpdatePolicy.java

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/repository/TimestampPolicy.java

ant/core/trunk/src/testcases/org/apache/tools/ant/taskdefs/LibrariesTest.java


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 14208] - [PATCH] StarTeam checkin and checkout tasks do not respect repository status flags

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=14208


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2005-10-06 19:44 ---


*** This bug has been marked as a duplicate of 35852 ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 14208] - [PATCH] StarTeam checkin and checkout tasks do not respect repository status flags

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=14208


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2005-09-19 22:31 ---
[EMAIL PROTECTED] reopened this bug without any explanation.  Perhaps it
is due to forced checkouts still ignoring status.  If this is the case, then
instead this bug should be resolved and marked as a duplicate of 35852 which has
resolution patches uploaded and ready to be committed.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 14208] - [PATCH] StarTeam checkin and checkout tasks do not respect repository status flags

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=14208


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC|[EMAIL PROTECTED]   |




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 14208] - [PATCH] StarTeam checkin and checkout tasks do not respect repository status flags

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=14208


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Little bit of repository surgery

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Apr 2005, Steve Loughran
> <[EMAIL PROTECTED]> wrote:
> 
> > Here is what I'm thinking,
> 
> Pretty much what I'd suggest as well (what, not how
> you plan to do).
> Also make maven2 the default.
> 
> > thoughts that may break anyone that has been using
> the task to
> > date. (which may be only me)
> 
> It probably will be only you ;-)

Not to be callous, but that's what happens in HEAD.  I
wouldn't worry about it.  Those on the bleeding-edge
should be able to adapt.  Beyond that, sounds fine to
me (FWIW).

-Matt

> 
> Stefan
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Little bit of repository surgery

[Steve Loughran]

Nicola Ken Barozzi wrote:
Steve Loughran wrote:
...
What do people think about my plan?

Any possibility of not duplicating code between Maven/MavenWagon and Ant?
Been discussed. I think I may use wagon in the smartfrog impl, but not 
the ant one.

(a) all the fetching is in tasks.Get already
(b) having zero dependencies makes it easier to rely on 
(c) apart from the fetching, there is security and path construction. 
The latter isnt complex, and verifies that the spec is valid. A bit like 
many standards bodies want two working impls of something before 
approving it as a standard.

-steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Little bit of repository surgery

[Nicola Ken Barozzi]

Steve Loughran wrote:
...
What do people think about my plan?
Any possibility of not duplicating code between Maven/MavenWagon and Ant?
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Little bit of repository surgery

[Stefan Bodewig]

On Mon, 11 Apr 2005, Steve Loughran <[EMAIL PROTECTED]> wrote:

> Here is what I'm thinking,

Pretty much what I'd suggest as well (what, not how you plan to do).
Also make maven2 the default.

> thoughts that may break anyone that has been using the task to
> date. (which may be only me)

It probably will be only you ;-)

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Little bit of repository surgery

[Steve Loughran]

Maven2 is out, with a new layout policy
* new remote: http://ibiblio.org/maven2
* local store ~/.m2/repository
* layout algorithm both local and remote:
* project/version/artifact-version[-classifier][.extension]
* every artifact has a .pom
where
 -project gets mapped from dotted to / : org.apache.ant would become 
org/apache/ant
 -classifier is something like "src" or "client"

The new layout is designed to scale much better, and a per-artifact POM 
is interesting.

This has the following implications for the  task
-a new local layout, if we match maven2
-a new attribute, classifier, in every library
-rework to move some of our naming policy around; the local filename 
policy is currently in the Library class, so doesn't change by repository.

Here is what I'm thinking, thoughts that may break anyone that has been 
using the task to date. (which may be only me)

1. Adopt the m2 local store, remote URL and layout policy.
2. Factor out local layout policy into its own interface/classes, with 
maven1,  maven2 and "flat" implementations,
3. Add classifier attribute to the library class.
4. support dotted project names
5. any other changes need to get this to work; some API changes in the 
classes.

I'm currently doing maven1&2 download code @work, for the smartfrog 
project there (*); I'll feed lessons (but not LGPL code) back into the 
ant stuff later on in the week.

What do people think about my plan?
(*) 
http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/smartfrog/src/org/smartfrog/services/os/java/
 -all the stuff with "not working" next to my name :)




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 18633] - starteam checkin task ignores the includes parameter for files not in repository

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=18633


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Optional Tasks  |Optional SCM tasks




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository ForceUpdatePolicy.java TimestampPolicy.java

[bodewig]

bodewig 2005/01/24 07:06:21

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
ForceUpdatePolicy.java TimestampPolicy.java
  Log:
  2005
  
  Revision  ChangesPath
  1.4   +15 -15
ant/src/main/org/apache/tools/ant/taskdefs/repository/ForceUpdatePolicy.java
  
  Index: ForceUpdatePolicy.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/ForceUpdatePolicy.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ForceUpdatePolicy.java21 Jan 2005 13:15:34 -  1.3
  +++ ForceUpdatePolicy.java24 Jan 2005 15:06:21 -  1.4
  @@ -1,19 +1,19 @@
   /*
  -* Copyright  2004 The Apache Software Foundation
  -*
  -*  Licensed under the Apache License, Version 2.0 (the "License");
  -*  you may not use this file except in compliance with the License.
  -*  You may obtain a copy of the License at
  -*
  -*  http://www.apache.org/licenses/LICENSE-2.0
  -*
  -*  Unless required by applicable law or agreed to in writing, software
  -*  distributed under the License is distributed on an "AS IS" BASIS,
  -*  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  -*  See the License for the specific language governing permissions and
  -*  limitations under the License.
  -*
  -*/
  + * Copyright 2004-2005 The Apache Software Foundation
  + *
  + *  Licensed under the Apache License, Version 2.0 (the "License");
  + *  you may not use this file except in compliance with the License.
  + *  You may obtain a copy of the License at
  + *
  + *  http://www.apache.org/licenses/LICENSE-2.0
  + *
  + *  Unless required by applicable law or agreed to in writing, software
  + *  distributed under the License is distributed on an "AS IS" BASIS,
  + *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  + *  See the License for the specific language governing permissions and
  + *  limitations under the License.
  + *
  + */
   package org.apache.tools.ant.taskdefs.repository;
   
   import org.apache.tools.ant.BuildException;
  
  
  
  1.4   +1 -1  
ant/src/main/org/apache/tools/ant/taskdefs/repository/TimestampPolicy.java
  
  Index: TimestampPolicy.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/TimestampPolicy.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- TimestampPolicy.java  21 Jan 2005 13:15:34 -  1.3
  +++ TimestampPolicy.java  24 Jan 2005 15:06:21 -  1.4
  @@ -1,5 +1,5 @@
   /*
  - * Copyright  2004 The Apache Software Foundation
  + * Copyright 2004-2005 The Apache Software Foundation
*
*  Licensed under the Apache License, Version 2.0 (the "License");
*  you may not use this file except in compliance with the License.
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository ScheduledUpdatePolicy.java

[Stefan Bodewig]

On Fri, 21 Jan 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:

> in src/etc/checkstyle/checkstyle, the linelength check is qualified
> to 100 chars from the default 80:

OK.  No idea who changed it (or even added that file), since I must
admit I've never used it so far.

Cheers

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository ScheduledUpdatePolicy.java

[Peter Reilly]

in src/etc/checkstyle/checkstyle, the linelength check is qualified to 
100 chars
from the default 80:

   
 
 
   
Peter
Stefan Bodewig wrote:
On 21 Jan 2005, <[EMAIL PROTECTED]> wrote:
 

 checkstyle: 100 char line limit
   

shouldn't that be 80?
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository ScheduledUpdatePolicy.java

[Stefan Bodewig]

On 21 Jan 2005, <[EMAIL PROTECTED]> wrote:

>   checkstyle: 100 char line limit

shouldn't that be 80?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository EnabledLibraryElementList.java LibraryPolicy.java ScheduledUpdatePolicy.java

[peterreilly]

peterreilly2005/01/21 06:35:45

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
EnabledLibraryElementList.java LibraryPolicy.java
ScheduledUpdatePolicy.java
  Log:
  date
  
  Revision  ChangesPath
  1.3   +1 -1  
ant/src/main/org/apache/tools/ant/taskdefs/repository/EnabledLibraryElementList.java
  
  Index: EnabledLibraryElementList.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/EnabledLibraryElementList.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- EnabledLibraryElementList.java21 Jan 2005 14:25:53 -  1.2
  +++ EnabledLibraryElementList.java21 Jan 2005 14:35:45 -  1.3
  @@ -1,5 +1,5 @@
   /*
  - * Copyright  2004 The Apache Software Foundation
  + * Copyright  2004-2005 The Apache Software Foundation
*
*  Licensed under the Apache License, Version 2.0 (the "License");
*  you may not use this file except in compliance with the License.
  
  
  
  1.5   +1 -1  
ant/src/main/org/apache/tools/ant/taskdefs/repository/LibraryPolicy.java
  
  Index: LibraryPolicy.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/LibraryPolicy.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- LibraryPolicy.java21 Jan 2005 14:30:37 -  1.4
  +++ LibraryPolicy.java21 Jan 2005 14:35:45 -  1.5
  @@ -1,5 +1,5 @@
   /*
  - * Copyright  2004 The Apache Software Foundation
  + * Copyright  2004-2005 The Apache Software Foundation
*
*  Licensed under the Apache License, Version 2.0 (the "License");
*  you may not use this file except in compliance with the License.
  
  
  
  1.5   +1 -1  
ant/src/main/org/apache/tools/ant/taskdefs/repository/ScheduledUpdatePolicy.java
  
  Index: ScheduledUpdatePolicy.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/ScheduledUpdatePolicy.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ScheduledUpdatePolicy.java21 Jan 2005 14:32:13 -  1.4
  +++ ScheduledUpdatePolicy.java21 Jan 2005 14:35:45 -  1.5
  @@ -1,5 +1,5 @@
   /*
  - * Copyright  2004 The Apache Software Foundation
  + * Copyright  2004-2005 The Apache Software Foundation
*
*  Licensed under the Apache License, Version 2.0 (the "License");
*  you may not use this file except in compliance with the License.
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository ScheduledUpdatePolicy.java

[peterreilly]

peterreilly2005/01/21 06:32:13

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
ScheduledUpdatePolicy.java
  Log:
  checkstyle: 100 char line limit
  
  Revision  ChangesPath
  1.4   +12 -7 
ant/src/main/org/apache/tools/ant/taskdefs/repository/ScheduledUpdatePolicy.java
  
  Index: ScheduledUpdatePolicy.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/ScheduledUpdatePolicy.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ScheduledUpdatePolicy.java22 Nov 2004 09:23:35 -  1.3
  +++ ScheduledUpdatePolicy.java21 Jan 2005 14:32:13 -  1.4
  @@ -33,8 +33,8 @@
   import java.util.Properties;
   
   /**
  - * This [EMAIL PROTECTED] 
org.apache.tools.ant.taskdefs.repository.LibraryPolicy} updates the files only 
when the schedule
  - * indicates that it should.
  + * This [EMAIL PROTECTED] 
org.apache.tools.ant.taskdefs.repository.LibraryPolicy} updates the files only
  + * when the schedule indicates that it should.
* 
* The default interval is eleven hours; it's prime, it encourages
* regular but not excessive days.
  @@ -53,10 +53,14 @@
*/
   private Properties markerFileToSave;
   
  -public static final String ERROR_NO_MARKER_FILE = "No marker file";
  -public static final String MARKER_MISMATCH = "No match between last 
update and current one";
  -public static final String INTERVAL_TRIGGERS_UPDATE = "Interval between 
updates is long; updating";
  -public static final String INTERVAL_SHORT_NO_UPDATE = "Interval between 
updates is short; no update";
  +public static final String ERROR_NO_MARKER_FILE
  += "No marker file";
  +public static final String MARKER_MISMATCH
  += "No match between last update and current one";
  +public static final String INTERVAL_TRIGGERS_UPDATE
  += "Interval between updates is long; updating";
  +public static final String INTERVAL_SHORT_NO_UPDATE
  += "Interval between updates is short; no update";
   
   
   public File getMarkerFile() {
  @@ -148,7 +152,8 @@
   markerFileToSave = now;
   return true;
   } catch (IOException e) {
  -throw new BuildException("Marker file " + 
markerFile.getAbsolutePath() + " access failed", e);
  +throw new BuildException(
  +"Marker file " + markerFile.getAbsolutePath() + " access 
failed", e);
   }
   }
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository LibraryPolicy.java

[peterreilly]

peterreilly2005/01/21 06:30:37

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
LibraryPolicy.java
  Log:
  no need to declare methods as public in a public interface
  100 line limit
  
  Revision  ChangesPath
  1.4   +6 -4  
ant/src/main/org/apache/tools/ant/taskdefs/repository/LibraryPolicy.java
  
  Index: LibraryPolicy.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/LibraryPolicy.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- LibraryPolicy.java22 Nov 2004 09:23:35 -  1.3
  +++ LibraryPolicy.java21 Jan 2005 14:30:37 -  1.4
  @@ -27,14 +27,16 @@
* Here is the use
* 
* Policies are executed in order of declaration.
  - * The [EMAIL PROTECTED] 
#beforeConnect(org.apache.tools.ant.taskdefs.repository.Libraries, 
java.util.ListIterator)} call,
  + * The [EMAIL PROTECTED] 
#beforeConnect(org.apache.tools.ant.taskdefs.repository.Libraries,
  + * java.util.ListIterator)} call,
* is called before any connection has been initiated; policies can 
manipulate
* the library list, set/reset their toFetch list, rename destination files, 
etc.
* If any policy returns false from the method, the connection does not 
proceed.
* This is not an error, provided the files are actually present.
* After running through the fetch of all files marked for download,
* every policy implementation will again be called in order of declaration.
  - * The [EMAIL PROTECTED] 
#afterFetched(org.apache.tools.ant.taskdefs.repository.Libraries, 
java.util.ListIterator)} method
  + * The [EMAIL PROTECTED] 
#afterFetched(org.apache.tools.ant.taskdefs.repository.Libraries,
  + * java.util.ListIterator)} method
* does not return anything.
* Either method can throw a BuildException to indicate some kind of 
error.
* 
  @@ -55,7 +57,7 @@
* @throws org.apache.tools.ant.BuildException
*  if needed
*/
  -public boolean beforeConnect(Libraries owner, ListIterator libraries);
  +boolean beforeConnect(Libraries owner, ListIterator libraries);
   
   /**
* method called after a successful connection process.
  @@ -63,7 +65,7 @@
* @param libraries
* @throws org.apache.tools.ant.BuildException
*/
  -public void afterFetched(Libraries owner, ListIterator libraries);
  +void afterFetched(Libraries owner, ListIterator libraries);
   
   
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository Library.java

[peterreilly]

peterreilly2005/01/21 06:27:28

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
Library.java
  Log:
  space around operands
  
  Revision  ChangesPath
  1.8   +5 -5  
ant/src/main/org/apache/tools/ant/taskdefs/repository/Library.java
  
  Index: Library.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/Library.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- Library.java  21 Jan 2005 13:15:34 -  1.7
  +++ Library.java  21 Jan 2005 14:27:28 -  1.8
  @@ -218,13 +218,13 @@
*/
   public void validate() {
   faultIfEmpty(project, ERROR_NO_PROJECT);
  -if(archive==null) {
  +if (archive == null) {
   //adopt the name of the project if no archive is specced
  -archive=project;
  +archive = project;
   }
   faultIfEmpty(version, ERROR_NO_VERSION);
  -if(suffix==null) {
  -suffix="";
  +if (suffix == null) {
  +suffix = "";
   }
   }
   
  @@ -250,7 +250,7 @@
   public void bind(File baseDir, boolean flatten) {
   validate();
   if (destinationName == null) {
  -if(flatten) {
  +if (flatten) {
   destinationName = getNormalFilename();
   } else {
   destinationName = getMavenPath('/');
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository EnabledLibraryElementList.java

[peterreilly]

peterreilly2005/01/21 06:25:54

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
EnabledLibraryElementList.java
  Log:
  remove _fields
  
  Revision  ChangesPath
  1.2   +10 -9 
ant/src/main/org/apache/tools/ant/taskdefs/repository/EnabledLibraryElementList.java
  
  Index: EnabledLibraryElementList.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/EnabledLibraryElementList.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- EnabledLibraryElementList.java18 Nov 2004 16:00:18 -  1.1
  +++ EnabledLibraryElementList.java21 Jan 2005 14:25:53 -  1.2
  @@ -44,8 +44,8 @@
* iterator through a list that skips everything that is not enabled
*/
   private static class EnabledIterator implements Iterator {
  -private Iterator _underlyingIterator;
  -private EnabledLibraryElement _next;
  +private Iterator underlyingIterator;
  +private EnabledLibraryElement next;
   
   
   /**
  @@ -54,7 +54,7 @@
* @param collection
*/
   EnabledIterator(Collection collection) {
  -_underlyingIterator = collection.iterator();
  +underlyingIterator = collection.iterator();
   }
   
   
  @@ -64,13 +64,14 @@
* @return
*/
   public boolean hasNext() {
  -while (_next == null && _underlyingIterator.hasNext()) {
  -EnabledLibraryElement candidate = (EnabledLibraryElement) 
_underlyingIterator.next();
  +while (next == null && underlyingIterator.hasNext()) {
  +EnabledLibraryElement candidate =
  +(EnabledLibraryElement) underlyingIterator.next();
   if (candidate.getEnabled()) {
  -_next = candidate;
  +next = candidate;
   }
   }
  -return (_next != null);
  +return (next != null);
   }
   
   /**
  @@ -82,8 +83,8 @@
   if (!hasNext()) {
   throw new NoSuchElementException();
   }
  -EnabledLibraryElement result = _next;
  -_next = null;
  +EnabledLibraryElement result = next;
  +next = null;
   return result;
   }
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository Libraries.java MavenRepository.java

[peterreilly]

peterreilly2005/01/21 06:03:46

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
Libraries.java MavenRepository.java
  Log:
  checkstyle - space around operators
  
  Revision  ChangesPath
  1.7   +10 -9 
ant/src/main/org/apache/tools/ant/taskdefs/repository/Libraries.java
  
  Index: Libraries.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/Libraries.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Libraries.java21 Jan 2005 13:15:34 -  1.6
  +++ Libraries.java21 Jan 2005 14:03:46 -  1.7
  @@ -99,13 +99,13 @@
* where maven stores stuff, and where we save stuff too, unless
* declared otherwise.
*/
  -public static final String MAVEN_LOCATION=".maven/repository";
  +public static final String MAVEN_LOCATION = ".maven/repository";
   
   /**
* name of the property which can provide an override of the repository 
dir
* from [EMAIL PROTECTED] #MAVEN_LOCATION}
*/
  -public static final String 
REPOSITORY_DIR_PROPERTY="ant.maven.repository.dir";
  +public static final String REPOSITORY_DIR_PROPERTY = 
"ant.maven.repository.dir";
   /**
* name of the property which can provide an override of the repository 
URL
*/
  @@ -134,8 +134,8 @@
   File mavenDir
   = new File(System.getProperty("user.home"), MAVEN_LOCATION);
   String propertyDir = 
getProject().getProperty(REPOSITORY_DIR_PROPERTY);
  -if(propertyDir!=null) {
  -mavenDir=getProject().resolveFile(propertyDir);
  +if (propertyDir != null) {
  +mavenDir = getProject().resolveFile(propertyDir);
   }
   return mavenDir;
   }
  @@ -359,11 +359,12 @@
*/
   public void validate() {
   if (destDir == null) {
  -destDir=locateDefaultDestDirectory();
  +destDir = locateDefaultDestDirectory();
   }
   if (repository == null) {
  -MavenRepository 
maven=(MavenRepository)getProject().createDataType(MavenRepository.TYPE_NAME);
  -repository=maven;
  +MavenRepository maven =
  +(MavenRepository) 
getProject().createDataType(MavenRepository.TYPE_NAME);
  +repository = maven;
   }
   Iterator it = libraries.iterator();
   while (it.hasNext()) {
  @@ -433,7 +434,7 @@
   
   if (isOffline()) {
   log("No retrieval, task is \"offline\"");
  -retrieve=false;
  +retrieve = false;
   }
   
   //see if we need to do a download
  @@ -568,7 +569,7 @@
   Library library = (Library) it.next();
   if (library.isToFetch()) {
   count++;
  -};
  +}
   }
   return count;
   }
  
  
  
  1.6   +4 -4  
ant/src/main/org/apache/tools/ant/taskdefs/repository/MavenRepository.java
  
  Index: MavenRepository.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/MavenRepository.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- MavenRepository.java  21 Jan 2005 07:12:52 -  1.5
  +++ MavenRepository.java  21 Jan 2005 14:03:46 -  1.6
  @@ -74,12 +74,12 @@
* @throws BuildException if unhappy
*/
   public void validate() {
  -if(getUrl()==null) {
  +if (getUrl() == null) {
   //we have no URL yet; so use the maven one
  -if(getProject()!=null) {
  -String urlProperty=getProject()
  +if (getProject() != null) {
  +String urlProperty = getProject()
   .getProperty(Libraries.REPOSITORY_URL_PROPERTY);
  -if(urlProperty!=null) {
  +if (urlProperty != null) {
   setUrl(urlProperty);
   } else {
   setUrl(MAVEN_URL);
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository Library.java

[Peter Reilly]

Using _setXX for method names does not look nice.
Perhaps use another name for set (assign?) or split
up the class into a configuration class presented to ant and
an implementation class that actually does the processing.
Peter
[EMAIL PROTECTED] wrote:
stevel  2005/01/20 15:09:15
 Modified:src/main/org/apache/tools/ant/taskdefs/repository
   Library.java
*/
 -public void setLibraryFile(File libraryFile) {
 -this.libraryFile = libraryFile;
 +public void _setLibraryFile(File file) {
 +this.libraryFile = file;
  }
  
  /**
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository Library.java

[stevel]

stevel  2005/01/20 15:09:15

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
Library.java
  Log:
  cleanup a few loose ends
  
  Revision  ChangesPath
  1.6   +5 -6  
ant/src/main/org/apache/tools/ant/taskdefs/repository/Library.java
  
  Index: Library.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/Library.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Library.java  6 Jan 2005 12:05:10 -   1.5
  +++ Library.java  20 Jan 2005 23:09:15 -  1.6
  @@ -72,7 +72,7 @@
   private String destinationName;
   
   /**
  - * file mapped to this one
  + * this is a file reference which is created during binding
*/
   private File libraryFile;
   
  @@ -190,11 +190,11 @@
   }
   
   /**
  - * set the library file.
  - * @param libraryFile
  + * set the library file. Hidden from Ant users.
  + * @param file
*/
  -public void setLibraryFile(File libraryFile) {
  -this.libraryFile = libraryFile;
  +public void _setLibraryFile(File file) {
  +this.libraryFile = file;
   }
   
   /**
  @@ -222,7 +222,6 @@
   //adopt the name of the project if no archive is specced
   archive=project;
   }
  -faultIfEmpty(archive, ERROR_NO_ARCHIVE);
   faultIfEmpty(version, ERROR_NO_VERSION);
   if(suffix==null) {
   suffix="";
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Stefan Bodewig]

On Wed, 8 Dec 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> So I suppose that chain of events would suggest that the answer to
> your question is "yes", though "finally understood" makes the Ant
> committers sound like a bunch of dinosaurs.  ;)
> 
>> No, I'm not saying that.
>> 
> Were you answering your own question there?

Nope, I probably didn't want to make it sounds as if the Ant
committers were a bunch dinosaurs ;-)

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository HttpRepository.java

[Stefan Bodewig]

On 13 Dec 2004, <[EMAIL PROTECTED]> wrote:

>   -URL url=basedir.toURL();
>   -setUrl(url.toExternalForm());
>   +URL u = basedir.toURL();
>   +setUrl(u.toExternalForm());

why not "setUrl(fileUtils.getFileURL(baseDir));"?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository HttpRepository.java

[bodewig]

bodewig 2004/12/13 00:59:42

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
HttpRepository.java
  Log:
  Make Jikes happy - shadowing of url
  
  Revision  ChangesPath
  1.5   +2 -2  
ant/src/main/org/apache/tools/ant/taskdefs/repository/HttpRepository.java
  
  Index: HttpRepository.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/HttpRepository.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- HttpRepository.java   1 Dec 2004 22:48:37 -   1.4
  +++ HttpRepository.java   13 Dec 2004 08:59:42 -  1.5
  @@ -99,8 +99,8 @@
*/
   public void setBaseDir(File basedir) {
   try {
  -URL url=basedir.toURL();
  -setUrl(url.toExternalForm());
  +URL u = basedir.toURL();
  +setUrl(u.toExternalForm());
   } catch (MalformedURLException e) {
   throw new BuildException(e);
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Matt Benson]

--- Russell Gold <[EMAIL PROTECTED]> wrote:
> On Wed, 8 Dec 2004 08:35:06 -0800 (PST), Matt Benson
> <[EMAIL PROTECTED]> wrote:
[SNIP]
> > tasks).  Unless I have misunderstood it
> dependencies
> > is more Maven-centric than  so I feel
[SNIP]
> I believe that you did misunderstand it. The
>  task is
> not Maven-centric. It simply borrowed a lot of
> concepts as a starting
> point, but those were never essential to its
> definition.

My apologies.  I hope the repository task ends up in a
form that is satisfactory to you as well.

-Matt



__ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Russell Gold]

On Wed, 8 Dec 2004 08:35:06 -0800 (PST), Matt Benson
<[EMAIL PROTECTED]> wrote:
> When Russell first brought his dependencies task to
> the table, I reiterated the general policy regarding
> the introduction of new tasks, especially where they
> interacted with software other than Ant (aka optional
> tasks).  Unless I have misunderstood it dependencies
> is more Maven-centric than  so I feel that
> position was applicable.

I believe that you did misunderstand it. The  task is
not Maven-centric. It simply borrowed a lot of concepts as a starting
point, but those were never essential to its definition.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Dec 2004, Matt Benson
> <[EMAIL PROTECTED]> wrote:
(edited for brevity)
> > See:
http://marc.theaimsgroup.com/?t=10935231277&r=1&w=2
> > (particularly DD's response)
> > and
>
http://marc.theaimsgroup.com/?l=ant-dev&m=109882328509244&w=2
> 
> So you are saying that Ant committers have finally
> understood that
> dependency management should be a core issue to Ant?
> 
When Russell first brought his dependencies task to
the table, I reiterated the general policy regarding
the introduction of new tasks, especially where they
interacted with software other than Ant (aka optional
tasks).  Unless I have misunderstood it dependencies
is more Maven-centric than  so I feel that
position was applicable.  DD agreed that this had been
a guiding principle but asserted that with time would
come the need for a task of this particular type and
lo, Steve began working on his task presumably within
the next two months.  So I suppose that chain of
events would suggest that the answer to your question
is "yes", though "finally understood" makes the Ant
committers sound like a bunch of dinosaurs.  ;)

> No, I'm not saying that.
> 
Were you answering your own question there?

> I do agree that any mechanism of dependency
> downloads could make
> antlib handling easier.
> 

Feels like some interesting possibilities, yes.

-Matt

> Stefan




__ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Stefan Bodewig]

On Tue, 7 Dec 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> 
>> On Mon, 6 Dec 2004, Matt Benson
>> <[EMAIL PROTECTED]> wrote:
>> 
>> > It's a sign of the times...
>> 
>> 
> 
> See:
> 
> http://marc.theaimsgroup.com/?t=10935231277&r=1&w=2
> (particularly DD's response)
> and
> http://marc.theaimsgroup.com/?l=ant-dev&m=109882328509244&w=2

So you are saying that Ant committers have finally understood that
dependency management should be a core issue to Ant?

No, I'm not saying that.

I do agree that any mechanism of dependency downloads could make
antlib handling easier.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Peter Reilly]

I think that for this to be really usefull, one would need to
use the  task.
See http://issues.apache.org/bugzilla/show_bug.cgi?id=28228
It does have some issues (sub-projects affecting
the main project, and when ant is used in an ide)
but it's benifits outweigh the drawbacks..
For example:

   junit.jar/>
   

   

Peter
Steve Loughran wrote:
On Tue, 7 Dec 2004 10:22:40 -0600, Groboclown <[EMAIL PROTECTED]>
wrote:
 

On Mon, 06 Dec 2004 22:27:12 +, Steve Loughran <[EMAIL PROTECTED]>
   

wrote:
 

Also, and this is important, you dont need to use it to download
 

stuff.
 

Instead you can use it to manage libraries that you depend on. (We
 

may
 

want to change behaviour to say if you dont specify a repository,
 

that
 

is exactly what you get)
 

That's great.  I just became a little cautious when I saw a bunch of
hard-coded references to the Maven style of paths.  If this stays
confined to the Maven repository, that's fine.
One thing I've always liked about Ant is that it doesn't dictate to
you any way to store your files (well, besides the ANT_HOME
directory).  This kind of thing seems to me like forcing the user into
the Maven world view.
   

No, no maven world view. And the task is very extensible; you can define
new repository types to bind to non-maven, even non-http repositories;
you can define new handlers (UpdatePolicies) to run before and after the
downloads. 

One thing on my todo list (*) is to add something to ant's build.xml to
fetch down the relevant binaries for all the optional tasks to build. We
could then do one for end users that pulls in the appropriate binaries
into an installation. Thoughts?
-steve
(*) none of which will get done this calendar year; I am off on holiday
with no laptop till january.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Steve Loughran]

On Tue, 7 Dec 2004 10:22:40 -0600, Groboclown <[EMAIL PROTECTED]>
wrote:
> On Mon, 06 Dec 2004 22:27:12 +, Steve Loughran <[EMAIL PROTECTED]>
wrote:
> 
> > Also, and this is important, you dont need to use it to download
stuff.
> > Instead you can use it to manage libraries that you depend on. (We
may
> > want to change behaviour to say if you dont specify a repository,
that
> > is exactly what you get)
> 
> That's great.  I just became a little cautious when I saw a bunch of
> hard-coded references to the Maven style of paths.  If this stays
> confined to the Maven repository, that's fine.
> 
> One thing I've always liked about Ant is that it doesn't dictate to
> you any way to store your files (well, besides the ANT_HOME
> directory).  This kind of thing seems to me like forcing the user into
> the Maven world view.
> 

No, no maven world view. And the task is very extensible; you can define
new repository types to bind to non-maven, even non-http repositories;
you can define new handlers (UpdatePolicies) to run before and after the
downloads. 

One thing on my todo list (*) is to add something to ant's build.xml to
fetch down the relevant binaries for all the optional tasks to build. We
could then do one for end users that pulls in the appropriate binaries
into an installation. Thoughts?


-steve

(*) none of which will get done this calendar year; I am off on holiday
with no laptop till january.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Groboclown]

On Mon, 06 Dec 2004 22:27:12 +, Steve Loughran <[EMAIL PROTECTED]> wrote:

> Also, and this is important, you dont need to use it to download stuff.
> Instead you can use it to manage libraries that you depend on. (We may
> want to change behaviour to say if you dont specify a repository, that
> is exactly what you get)

That's great.  I just became a little cautious when I saw a bunch of
hard-coded references to the Maven style of paths.  If this stays
confined to the Maven repository, that's fine.

One thing I've always liked about Ant is that it doesn't dictate to
you any way to store your files (well, besides the ANT_HOME
directory).  This kind of thing seems to me like forcing the user into
the Maven world view.

-- 
-Matt
"So whatever you do, don't be bored, this is
absolutely the most exciting time we could have
possibly hoped to be alive. And things are just
starting."  -- Waking Life

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> On Mon, 6 Dec 2004, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> 
> > It's a sign of the times...
> 
> 

See:

http://marc.theaimsgroup.com/?t=10935231277&r=1&w=2
(particularly DD's response)
and
http://marc.theaimsgroup.com/?l=ant-dev&m=109882328509244&w=2

-Matt
> 
> Stefan
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 




__ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Stefan Bodewig]

On Mon, 6 Dec 2004, Matt Benson <[EMAIL PROTECTED]> wrote:

> It's a sign of the times...



Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Russell Gold]

On Mon, 06 Dec 2004 22:27:12 +, Steve Loughran <[EMAIL PROTECTED]> wrote:
> >
> > One thing I can't find is why this is being put into ant core and not
> > an optional task.  Could anyone help me out here?  Thanks.
> 
> It's a bootstrapping thing. If its optional, well, its optional so it
> may not be there. Which makes it a lot harder to use the task to
> retrieve optional stuff.

Isn't that true about *every* optional task?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Steve Loughran]

> 
> One thing I can't find is why this is being put into ant core and not
> an optional task.  Could anyone help me out here?  Thanks.

It's a bootstrapping thing. If its optional, well, its optional so it
may not be there. Which makes it a lot harder to use the task to
retrieve optional stuff. 

Also, and this is important, you dont need to use it to download stuff.
Instead you can use it to manage libraries that you depend on. (We may
want to change behaviour to say if you dont specify a repository, that
is exactly what you get)

So you can say 

 
 




Because libraries actually verifies that each class is there, it is a
bit stricter about finding problems. And it lets you share a central
repository with other apps. 

-Steve




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository task

[Matt Benson]

It's a sign of the times...

-Matt

--- Groboclown <[EMAIL PROTECTED]> wrote:

> I've been out of the Ant developer discussions for
> about two or three
> months now (way too much going on), and I'm trying
> to get caught up on
> the repository task.
> 
> One thing I can't find is why this is being put into
> ant core and not
> an optional task.  Could anyone help me out here? 
> Thanks.
> 
> -- 
> -Matt
> "So whatever you do, don't be bored, this is
> absolutely the most exciting time we could have
> possibly hoped to be alive. And things are just
> starting."  -- Waking Life
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 




__ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

New repository task

[Groboclown]

I've been out of the Ant developer discussions for about two or three
months now (way too much going on), and I'm trying to get caught up on
the repository task.

One thing I can't find is why this is being put into ant core and not
an optional task.  Could anyone help me out here?  Thanks.

-- 
-Matt
"So whatever you do, don't be bored, this is
absolutely the most exciting time we could have
possibly hoped to be alive. And things are just
starting."  -- Waking Life

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: repository

[Stefan Bodewig]

On Tue, 23 Nov 2004, Russell Gold <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Nov 2004 14:05:35 +0100, Stefan Bodewig
> <[EMAIL PROTECTED]> wrote:
>> On Tue, 16 Nov 2004, Steve Loughran <[EMAIL PROTECTED]> wrote:
>> 
>> > I dont think security checking of Md5 checksums should be
>> > voluntary;
>> 
>> While I agree with this in principal, implementing it may be
>> difficult since the Maven-like repo at www.apache.org holds .MD5
>> files (or .md5 or .md5sum) that have been created by different
>> tools and thus have different formats.
> 
> Do you mean the repository under <http://www.apache.org/dist/> ?

More specifically <http://www.apache.org/dist/java-repository/> which
is the rsync master for Apache projects for the ibiblio Maven repo.

> For example, just comparing three java projects: ant, bcel, and
> struts, their versioned binaries are located at:
> 
> ant/binaries/apache-ant-1.6.2-bin.tar.gz
> jakarta/bcel/binaries/bcel-5.1.tar.gz
> struts/binaries/jakarta-struts-1.2.2.tar.gz

jakarta is a different beast since it an "umbrella" project.  If we
ever wanted to release Antidote or add new subprojects to Ant we'd
have to change our structure as well.

As for the names of the binaries, IMHO all of them should have apache
in their name if only for branding reasons, but we don't enforce this.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: repository

[Russell Gold]

On Wed, 17 Nov 2004 14:05:35 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Nov 2004, Steve Loughran <[EMAIL PROTECTED]> wrote:
> 
> > I dont think security checking of Md5 checksums should be voluntary;
> 
> While I agree with this in principal, implementing it may be difficult
> since the Maven-like repo at www.apache.org holds .MD5 files (or .md5 or
> .md5sum) that have been created by different tools and thus have
> different formats.

Do you mean the repository under <http://www.apache.org/dist/> ?

I would like to make a repository type to handle it, but it doesn't
show much consistency. For example, just comparing three java
projects: ant, bcel, and struts, their versioned binaries are located
at:

ant/binaries/apache-ant-1.6.2-bin.tar.gz
jakarta/bcel/binaries/bcel-5.1.tar.gz
struts/binaries/jakarta-struts-1.2.2.tar.gz

the only thing that you can count on is the existence of the binaries
directory and the version extension. You could consider ant to have
group/artifact as "ant/apache-ant" and struts to have
"struts/jakarta-struts" but bcel has an extra layer:
"jakarta/bcel/bcel"

Now there are workarounds here, but it sure doesn't make things easy-
and the paths tend to change over time. The ibiblio repository works
because it has a well-defined and consistent structure. The apache
repository does not seem to, even ignoring the checksum algorithm
problem.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository HttpRepository.java

[stevel]

stevel  2004/11/18 15:28:37

  Modified:src/main/org/apache/tools/ant/taskdefs/repository
HttpRepository.java
  Log:
  In use, you need to know why your build file has paused for so long.
  
  Revision  ChangesPath
  1.2   +1 -2  
ant/src/main/org/apache/tools/ant/taskdefs/repository/HttpRepository.java
  
  Index: HttpRepository.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/HttpRepository.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- HttpRepository.java   18 Nov 2004 16:25:03 -  1.1
  +++ HttpRepository.java   18 Nov 2004 23:28:37 -  1.2
  @@ -220,9 +220,8 @@
   public boolean fetch(Library library, boolean useTimestamp) throws 
IOException {
   
   String path = getRemoteLibraryURL(library);
  -logVerbose("Library URL=" + path);
  +log("Downloading "+path +" to "+ library.getAbsolutePath());
   URL remoteURL=new URL(path);
  -logVerbose("destination =" + library.getAbsolutePath());
   long start, finish;
   start = System.currentTimeMillis();
   boolean success=get(remoteURL, library.getLibraryFile(),useTimestamp,
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: repository

[Steve Loughran]

I've just checked in the much reworked repository. We have to be
somewhat grateful that whoever broke into my house and stole my work
laptop, left the home PC next to it, that being where this code was. 

Features

-now called  as it does more than just get them.

-now in oata.tasks.repository ; not optional

-LibraryPolicies interface for 'policies'; mostly update policies but
also a slick little bunny  for self
testing. 

-Files get downloaded into subdirectories.

Policies;
  -fetch everything; verify the fetches worked

  probe timestamps on all; fetch if changed

  absent ones only

  nothing gets fetched.

   //testing; diagnosis

 
   saves complete snapshot to a marker file; updates if that has
   changed or the elapsed time has elapsed. We could do more fine
   tuning here; days should mean 'tuesday, wednesday', not 24
   hours.

You can declare new datatypes and use them as policies; things like
mappers, filesets, signature verification can all go in. You can also
list them in order, semantics follow from the fact they are executed in
forward order before loading, reverse order after loading. 

All policies have an enabled flag; libraries have had if/unless replaced
with an enabled flag; they share a common interface and a list wrapper. 

Tests. 23 so far; could do with more, for things like schedule and just
file renaming. 

Todo: any hint of security. 

I'm also considering a policy that lets you assert that a particular
class exists in the library path:-

 (with nested resource and class attributes)

Failure to find a resource automatically raises a fault. this can be
done with  and  but a more declarative means may make
it more likely to be used. 

I havent done anything towards a common repository, though the use of
subdirs makes that fairly trivial (we add a default dest dir, and change
 to save to a temp file with rename afterwards). and I think the
default update policy is already . 

Comments as usual welcome. I think this stuff is ready to be used, with
the usual caveats about stability. I'm about to start using it at work,
which means we'll see how gump deals with it. 

Also: it needs documentation. More on that next.

-steve 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/repository GetLibrariesTest.java

[stevel]

stevel  2004/11/18 08:25:05

  Modified:src/main/org/apache/tools/ant/taskdefs defaults.properties
   src/main/org/apache/tools/ant/taskdefs/repository
AbsentFilesPolicy.java AssertDownloaded.java
BaseLibraryPolicy.java ForceUpdatePolicy.java
LibraryPolicy.java NoUpdatePolicy.java
ScheduledUpdatePolicy.java TimestampPolicy.java
   src/main/org/apache/tools/ant/types defaults.properties
  Added:   src/main/org/apache/tools/ant/taskdefs/repository
HttpRepository.java Libraries.java Library.java
MavenRepository.java Repository.java
RepositoryRef.java
   src/etc/testcases/taskdefs libraries.xml
   src/testcases/org/apache/tools/ant/taskdefs
LibrariesTest.java
  Removed: src/main/org/apache/tools/ant/taskdefs/optional/repository
GetLibraries.java HttpRepository.java Library.java
MavenRepository.java Repository.java
RepositoryRef.java
   src/etc/testcases/taskdefs/optional getlibraries.xml
   src/testcases/org/apache/tools/ant/taskdefs/optional/repository
GetLibrariesTest.java
  Log:
  1. Move from optional.repository to tasks.repository
  2. rename 
  
  Revision  ChangesPath
  1.160 +1 -1  
ant/src/main/org/apache/tools/ant/taskdefs/defaults.properties
  
  Index: defaults.properties
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/defaults.properties,v
  retrieving revision 1.159
  retrieving revision 1.160
  diff -u -r1.159 -r1.160
  --- defaults.properties   25 Oct 2004 23:13:38 -  1.159
  +++ defaults.properties   18 Nov 2004 16:25:03 -  1.160
  @@ -80,6 +80,7 @@
   presetdef=org.apache.tools.ant.taskdefs.PreSetDef
   macrodef=org.apache.tools.ant.taskdefs.MacroDef
   nice=org.apache.tools.ant.taskdefs.Nice
  +libraries=org.apache.tools.ant.taskdefs.repository.Libraries
   
   # optional tasks
   image=org.apache.tools.ant.taskdefs.optional.image.Image
  @@ -203,7 +204,6 @@
   scriptdef=org.apache.tools.ant.taskdefs.optional.script.ScriptDef
   ildasm=org.apache.tools.ant.taskdefs.optional.dotnet.Ildasm
   apt=org.apache.tools.ant.taskdefs.Apt
  -getlibraries=org.apache.tools.ant.taskdefs.optional.repository.GetLibraries
   
   # deprecated ant tasks (kept for back compatibility)
   starteam=org.apache.tools.ant.taskdefs.optional.scm.AntStarTeamCheckOut
  
  
  
  1.2   +1 -3  
ant/src/main/org/apache/tools/ant/taskdefs/repository/AbsentFilesPolicy.java
  
  Index: AbsentFilesPolicy.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/AbsentFilesPolicy.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- AbsentFilesPolicy.java18 Nov 2004 16:00:18 -  1.1
  +++ AbsentFilesPolicy.java18 Nov 2004 16:25:03 -  1.2
  @@ -16,8 +16,6 @@
*/
   package org.apache.tools.ant.taskdefs.repository;
   
  -import org.apache.tools.ant.taskdefs.optional.repository.GetLibraries;
  -
   import java.util.ListIterator;
   
   /**
  @@ -36,7 +34,7 @@
* @throws org.apache.tools.ant.BuildException
*  if needed
*/
  -public boolean beforeConnect(GetLibraries owner, ListIterator libraries) 
{
  +public boolean beforeConnect(Libraries owner, ListIterator libraries) {
   owner.markMissingLibrariesForFetch();
   return true;
   }
  
  
  
  1.2   +2 -3  
ant/src/main/org/apache/tools/ant/taskdefs/repository/AssertDownloaded.java
  
  Index: AssertDownloaded.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/repository/AssertDownloaded.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- AssertDownloaded.java 18 Nov 2004 16:00:18 -  1.1
  +++ AssertDownloaded.java 18 Nov 2004 16:25:03 -  1.2
  @@ -17,7 +17,6 @@
   package org.apache.tools.ant.taskdefs.repository;
   
   import org.apache.tools.ant.BuildException;
  -import org.apache.tools.ant.taskdefs.optional.repository.GetLibraries;
   
   import java.util.ListIterator;
   
  @@ -54,7 +53,7 @@
* @throws org.apache.tools.ant.BuildException
*  if needed
*/
  -public boolean beforeConnect(GetLibraries owner, ListIterator libraries) 
{
  +public boolean beforeConnect(Libraries owner, ListIterator libraries) {
   if(count==null) {
   throw new BuildException(ERROR_NO_COUNT);
   }
  @@ -70,7 +69,7 @@
* @throws org.apache.tools.ant.BuildException

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository - New directory

[Mario Luca Bernardi]

On Thursday 18 November 2004 16:44, [EMAIL PROTECTED] wrote:
> stevel  2004/11/18 07:44:18
> 
>   ant/src/main/org/apache/tools/ant/taskdefs/repository - New directory
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/repository - New directory

[stevel]

stevel  2004/11/18 07:44:18

  ant/src/main/org/apache/tools/ant/taskdefs/repository - New directory

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]