Re: This list is going to be closed down

[Nicolas Lalevée]

Le jeudi 6 décembre 2007, Stefan Bodewig a écrit :
> Dear subscriber,
>
> in the future Ivy's development will be discussed on the
> dev@ant.apache.org mailing list (in fact, it already is).
>
> This list is going to be closed down, so if you are interested in
> following or contributing to the future of Ivy, please subscribe to
> dev@ant.apache.org by sending an email to
> [EMAIL PROTECTED]
>
> Cheers
>
> Stefan

So this page should be updated accordingly :

http://ant.apache.org/ivy/mailing-lists.html

cheers,
Nicolas

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

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]

IvyDE sources

[Nicolas Lalevée]

Hi,

The IvyDE sources are not very patch friendly because of the space vs  
tabs indentation and the missing svn:eol-style property. The following  
command just return nothing within the IvyDE trunk.

find . -iname "*.java" -exec svn pl {} \;

So could a developer make a big "Format" on every IvyDE sources and  
add the proper "native" value to the svn:eol-style property ?
I looked into Jira, the only available patch is IVYDE-43, which is  
outdated because it is against IvyDE 1.2. So I think it is a good time  
to do it.


cheers,
Nicolas


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

Re: IvyDE sources

[Nicolas Lalevée]

Le lundi 14 janvier 2008, Xavier Hanin a écrit :
> On Jan 7, 2008 1:59 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > On Jan 7, 2008 12:59 PM, Nicolas Lalevée
> > <[EMAIL PROTECTED]>
> >
> > wrote:
> > > Hi,
> > >
> > > The IvyDE sources are not very patch friendly because of the space vs
> > > tabs indentation and the missing svn:eol-style property. The following
> > > command just return nothing within the IvyDE trunk.
> > > find . -iname "*.java" -exec svn pl {} \;
> > >
> > > So could a developer make a big "Format" on every IvyDE sources and
> > > add the proper "native" value to the svn:eol-style property ?
> > > I looked into Jira, the only available patch is IVYDE-43, which is
> > > outdated because it is against IvyDE 1.2. So I think it is a good time
> > > to do it.
> >
> > You're absolutely right. I'll try to do it in the coming days.
>
> Done, sorry for the delay.

Well, thank you to take time to do it. :)

Nicolas

> > Xavier
> >
> > > cheers,
> > > Nicolas
> > >
> > >
> > > -----
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

ResolveReport API

[Nicolas Lalevée]

Hi,

I have a question about the Ivy API. In IvyDE, to compute the classpath there 
is:

ResolveReport r = _ivy.resolve(ivyURL, new ResolveOptions().setConfs(_confs)); 
all.addAll(Arrays.asList(r.getAllArtifactsReports()));

But it seems that the download reports contains also the evicted modules : so 
the classpath may contains different versions of same library.
Is that expected, so there is an IvyDE bug, or it is an Ivy one ?

cheers,
Nicolas

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

Re: [jira] Commented: (IVY-704) In the ResolveReport class, add the possibility to filter the evicted module while getting the list of DownloadArtifact

[Nicolas Lalevée]

Answering in ant-dev, because this might be a larger topic.

Le 19 janv. 08 à 07:56, Xavier Hanin (JIRA) a écrit :



   [ https://issues.apache.org/jira/browse/IVY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560662 
#action_12560662 ]


Xavier Hanin commented on IVY-704:
--

{quote}
does it means that some evicted modules will still be returned by  
ResolveReport#getArtifactsReports(DownloadStatus, boolean) ?

{quote}
Yes, but not fully evicted (by fully evicted I mean evicted in all  
configurations). The rationale behind this is that I think this  
method should return the same set of artifacts as what you get if  
you use a retrieve or a cachepath task. So as soon as one artifact  
is not evicted in one conf, you get it with retrieve if you retrieve  
all confs.


{quote}
the eviction information is in the conf which contains the not  
evicted one.

{quote}
Mmm, this seems ok to me: a module revision is usually evicted in  
favor of another one in one given configuration, so in this  
configuration report we have to store both the selected module and  
the evicted one. That's where the withEvicted you implemented is  
used, and that's fine. Am I missing something?




In fact I was assuming that in the list of artifact returned by a  
retrieve task, there won't be any duplicate entry, even with different  
version, because they will conflict.


I have a such ivy.xml on which I do a resolve for every conf on, and  
then I have duplicate entries in IvyDE. And from the ivy reports,  
there is effectively a configuration where the should-be-evicted  
artifact is resolved without being evicted.


Then what does mean doing a single resolve on several conf. As you  
explained, in the actual implementation it is just a aggregation of  
several independent resolve tasks, each task on one conf. As a user I  
would expect that a multi-conf retrieve will generate a coherent  
classpath. It would be similar to creating a new conf, making it  
depends on the confs I really want, and then doing a resolve on it.


(continuing thinking loudly)

But my conf maybe wrong in fact. Having two confs which produce two  
same artifacts without the same version seems wrong. We can imagine  
two different confs named withJetty5 and withJetty6. And of course  
they should not be retrieved jointly.
Maybe Ivy should trigger a warn/error ? Or at least the ant task and  
IvyDE ?



Nicolas, discovering the complexity of the dependency management


In the ResolveReport class, add the possibility to filter the  
evicted module while getting the list of DownloadArtifact

---

   Key: IVY-704
   URL: https://issues.apache.org/jira/browse/IVY-704
   Project: Ivy
Issue Type: Improvement
Components: Core
  Affects Versions: 2.0.0-beta-2
      Reporter: Nicolas Lalevée
   Fix For: 2.0.0-beta-2

   Attachments: IVY-704-r612799.patch


As disscussed here : 
http://mail-archives.apache.org/mod_mbox/ant-dev/200801.mbox/[EMAIL PROTECTED]
In order to get the list of artifacts which are part of the  
dependencies of a module, it will be useful to have a function in  
the ResolveReport class to get the download reports without the  
ones from the evited modules.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.




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

Re: [jira] Commented: (IVY-704) In the ResolveReport class, add the possibility to filter the evicted module while getting the list of DownloadArtifact

[Nicolas Lalevée]

Le lundi 21 janvier 2008, Xavier Hanin a écrit :
> On Jan 19, 2008 2:44 PM, Nicolas Lalevée <[EMAIL PROTECTED]>
>
> wrote:
> > Answering in ant-dev, because this might be a larger topic.
> >
> > Le 19 janv. 08 à 07:56, Xavier Hanin (JIRA) a écrit :
> > >[
> >
> > https://issues.apache.org/jira/browse/IVY-704?page=com.atlassian.jira.plu
> >gin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560662
> >
> > > #action_12560662 ]
> > >
> > > Xavier Hanin commented on IVY-704:
> > > --
> > >
> > > {quote}
> > > does it means that some evicted modules will still be returned by
> > > ResolveReport#getArtifactsReports(DownloadStatus, boolean) ?
> > > {quote}
> > > Yes, but not fully evicted (by fully evicted I mean evicted in all
> > > configurations). The rationale behind this is that I think this
> > > method should return the same set of artifacts as what you get if
> > > you use a retrieve or a cachepath task. So as soon as one artifact
> > > is not evicted in one conf, you get it with retrieve if you retrieve
> > > all confs.
> > >
> > > {quote}
> > > the eviction information is in the conf which contains the not
> > > evicted one.
> > > {quote}
> > > Mmm, this seems ok to me: a module revision is usually evicted in
> > > favor of another one in one given configuration, so in this
> > > configuration report we have to store both the selected module and
> > > the evicted one. That's where the withEvicted you implemented is
> > > used, and that's fine. Am I missing something?
> >
> > In fact I was assuming that in the list of artifact returned by a
> > retrieve task, there won't be any duplicate entry, even with different
> > version, because they will conflict.
> >
> > I have a such ivy.xml on which I do a resolve for every conf on, and
> > then I have duplicate entries in IvyDE. And from the ivy reports,
> > there is effectively a configuration where the should-be-evicted
> > artifact is resolved without being evicted.
> >
> > Then what does mean doing a single resolve on several conf. As you
> > explained, in the actual implementation it is just a aggregation of
> > several independent resolve tasks, each task on one conf. As a user I
> > would expect that a multi-conf retrieve will generate a coherent
> > classpath. It would be similar to creating a new conf, making it
> > depends on the confs I really want, and then doing a resolve on it.
> >
> > (continuing thinking loudly)
> >
> > But my conf maybe wrong in fact. Having two confs which produce two
> > same artifacts without the same version seems wrong. We can imagine
> > two different confs named withJetty5 and withJetty6. And of course
> > they should not be retrieved jointly.
> > Maybe Ivy should trigger a warn/error ? Or at least the ant task and
> > IvyDE ?
> >
> >
> > Nicolas, discovering the complexity of the dependency management
>
> Configurations in Ivy are considered isolated. Resolving or retrieving
> several confs at a time is only a shortcut for doing the same thing with
> each conf at a time. I don't know if it's the best thing to do or not, but
> at least it's consistent, and it works like that since the beginning. Any
> time resolving several confs at a time has an impact this is considered a
> bug and we fix it. So if you really want your confs to be resolved at once
> and conflict management to occur between them, you need to create another
> conf extending the others.
>
> Now should we add a warning/error when we find conflicts between confs? I
> don't know. It seems indeed that it would benefit some (most?) users, since
> the use case where someone need different versions for different confs
> seems to be rare. But we should be able to disable this behavior.

Finally it seems that it should be the user of the core API (ant task or 
IvyDE) which should warn the end user, so yes the current API should stay the 
same without trigerring a warn.
I will put it to IvyDE.

cheers,
Nicolas

> Xavier
>
> > >> In the ResolveReport class, add the possibility to filter the
> > >> evicted module while getting the list of DownloadArtifact
> >
> > -
> >--
> >
> > >>Key: IVY-704
> > >>URL: https://issues.apache.org/jira/browse/IVY-704
> > >>

Re: Building IvyDE

[Nicolas Lalevée]

Le 8 févr. 08 à 18:57, Matt Benson a écrit :



--- Xavier Hanin <[EMAIL PROTECTED]> wrote:


We don't have automated scripts for that yet, but
here is the procedure I
follow:
1) Open Ivy and IvyDE projects in eclipse
2) In IvyDE project, open plugin.xml with PDE editor
(should be the default)
3) In the "exporting" section choose export wizard
4) export IvyDE only (not Ivy)

Then you will get IvyDE plugin packaged in zip. To
install you need to put
both this plugin and Ivy itself (build from trunk
for instance, using "ant
jar") which is an OSGi bundle and as such is
recognized by Eclipse equinox.


I'm assuming I'll install IvyDE like any other
plugin... but where is it I need to put the Ivy jar?


In fact ivy.jar is a bundle, so a sort of eclipse plugin. So you have  
to install it next to the ivyde plugin.



Also, I saw where somebody else said they were using a
build from Xooctory... but builds.xoocode.org seems to
be down.  Am I looking in the right place?


Xavier's builds are there :
http://xoocode.org/downloads/tools/

Nicolas




Thanks,
Matt



HTH,

Xavier

On Feb 8, 2008 4:37 PM, Matt Benson
<[EMAIL PROTECTED]> wrote:


how?









Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.




http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ







-

To unsubscribe, e-mail:

[EMAIL PROTECTED]

For additional commands, e-mail:

[EMAIL PROTECTED]






--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/





  


Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs

-
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: Building IvyDE

[Nicolas Lalevée]

Le 8 févr. 08 à 20:08, Matt Benson a écrit :


Still breaks.  Same problem.  :(

-Matt

--- Matt Benson <[EMAIL PROTECTED]> wrote:



--- Xavier Hanin <[EMAIL PROTECTED]> wrote:


On Feb 8, 2008 7:43 PM, Matt Benson
<[EMAIL PROTECTED]> wrote:



--- Nicolas Lalevée

<[EMAIL PROTECTED]>

wrote:



Le 8 févr. 08 à 18:57, Matt Benson a écrit :



--- Xavier Hanin <[EMAIL PROTECTED]>

wrote:



We don't have automated scripts for that

yet,

but

here is the procedure I
follow:
1) Open Ivy and IvyDE projects in eclipse
2) In IvyDE project, open plugin.xml with

PDE

editor

(should be the default)
3) In the "exporting" section choose export

wizard

4) export IvyDE only (not Ivy)



Okay, guys... I did all this and I get a bunch

of

errors in a build log about Ivy classes not

being

found.  What am I missing?


I'm not sure, maybe you need to have Ivy available
as a bundle in eclipse
where you make the export. Now that I say this it
sounds strange, but I've
just noticed I have ivy jar in my eclipse plugins
directory, so it may be
the difference...



I've already built my Ivy jar so I'll dump it in and
report back.  :)



Eclipse needs somewhere the Ivy plugin, so either already installed in  
the eclipse from which you try to build, either as a dependency in the  
workspace (as pure source project, or a binary fragment).
So Matt, just import the Ivy project into your eclipse, and try export  
IvyDE.


Nicolas





-Matt



Xavier

[SNIP]







Looking for last minute shopping deals?
Find them fast with Yahoo! Search.


http://tools.search.yahoo.com/newsearch/category.php?category=shopping




-

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






  


Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs

-
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: Add maven2 resolver?

[Nicolas Lalevée]

Le 8 févr. 08 à 21:29, Adrian Sandor a écrit :

Hi, IMHO it would be much better to build a clean, well-organized  
and reliable ivy repository instead of supporting that maven  
garbage. By the way, why was IvyRep abandoned? I think that would be  
the best solution, to have an official ivy rep., ideally containing  
artifacts too.
I have nothing against [better] supporting maven reps for those who  
prefer it, but I don't see why it should have a higher priority than  
supporting an ivy rep.
Anyway, I've never used maven (and from what I read about it, I  
avoided a world of suffering), and during the few minutes I spent  
with the ibiblio resolver before ditching it, I found these main  
problems:

- bad org names
- very old versions for some modules
- source and javadoc artifacts not supported (except by IvyDE)
Therefore the only solution was to manually build an "enterprise  
repository" from scratch.


Well, to build a "entreprise repository", you will need some  
"entreprise maintainers". And looking at the number of artifacts  
available on ibiblio, for me it is a kind of magic to have Ivy support  
maven repositories. And we have to admit that maven is more popular  
than Ivy, so people will still continue to publish maven artifacts,  
even non maven-built projects as Lucene.


And on the contrary, we could imagine to have some ivy.xml just next  
to the pom.xml on the maven repositories, so we could have a IvyRep2  
with not that much effort from the developer (non necessarily ivy  
ones) community.


Nicolas

This could be avoided if an IvyRep was maintained (at least I could  
do "install").


Just a new user's opinion :)

Adrian

- Original Message 
From: Xavier Hanin <[EMAIL PROTECTED]>
To: Ant Developers List 
Sent: Saturday, February 9, 2008 2:44:15 AM
Subject: Add maven2 resolver?


Hi,

Now
that
Ivy
is
using
maven
2
repository
as
default
public
repository,
and
that
we
see
many
people
trying
to
leverage
maven
2
repositories,
I'm
wondering
if
we
shouldn't
introduce
a
maven2
resolver.
This
resolver
would
basically
be
the
equivalent
of
ibiblio
resolver
with
m2compatible
set
to
true.
The
advantage
is
a
better
name,
and
we
can
make
also
other
improvements.
For
instance,
we
could
set
checkConsistency
to
false
on
this
resolver,
since
pretty
often
people
complain
about
inconsitencies
in
maven2
repo
(see
for
instance
last
comments
on
[1]).
We
may
also
set
the
changingPattern
to
make
SNAPSHOT
dependencies
work
(more
than
that
needs
to
be
done,
this
should
be
addressed
in
IVY-501).
We
may
even
try
to
make
this
resolver
leverage
maven2
cache,
for
people
who
work
with
both
Ivy
and
maven
2
on
the
same
machine.

WDYT?

Xavier

[1]
http://tapestryjava.blogspot.com/2007/11/maven-wont-get-fooled-again.html
--
Xavier
Hanin
-
Independent
Java
Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/






  


Looking for last minute shopping deals?
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping



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

Re: Add maven2 resolver?

[Nicolas Lalevée]

Le 9 févr. 08 à 08:56, Xavier Hanin a écrit :

On Feb 8, 2008 11:01 PM, Nicolas Lalevée <[EMAIL PROTECTED] 
>

wrote:



Le 8 févr. 08 à 21:29, Adrian Sandor a écrit :


Hi, IMHO it would be much better to build a clean, well-organized
and reliable ivy repository instead of supporting that maven
garbage. By the way, why was IvyRep abandoned? I think that would be
the best solution, to have an official ivy rep., ideally containing
artifacts too.
I have nothing against [better] supporting maven reps for those who
prefer it, but I don't see why it should have a higher priority than
supporting an ivy rep.
Anyway, I've never used maven (and from what I read about it, I
avoided a world of suffering), and during the few minutes I spent
with the ibiblio resolver before ditching it, I found these main
problems:
- bad org names
- very old versions for some modules
- source and javadoc artifacts not supported (except by IvyDE)
Therefore the only solution was to manually build an "enterprise
repository" from scratch.


Well, to build a "entreprise repository", you will need some
"entreprise maintainers". And looking at the number of artifacts
available on ibiblio, for me it is a kind of magic to have Ivy  
support

maven repositories. And we have to admit that maven is more popular
than Ivy, so people will still continue to publish maven artifacts,
even non maven-built projects as Lucene.


Agreed, this is a big advantage of leveraging maven 2 repo.




And on the contrary, we could imagine to have some ivy.xml just next
to the pom.xml on the maven repositories, so we could have a IvyRep2
with not that much effort from the developer (non necessarily ivy
ones) community.


Yes, but even maintaining ivy files require a strong community if we  
want to
have good quality metadata. That's what we tried with Ivyrep, while  
Ivy was
being sponsored by Jayasoft. But it was just too much work compared  
to the

result on investment. I still think that implementing a good maven 2
compatibility is less work than trying to build our own clean  
repository,
and it helps users to migrate from maven 2 too. So I still think  
having a
good maven 2 compatibility is mandatory for Ivy 2 final. Once we'll  
have a
large user community or some sponsorship, we will probably  
reconsider the

case of public official Ivy repository.



Yes, I totally agree, I was just considering adding the possibility to  
the maven2 resolver to also try to look for an ivy.xml just next to  
the pom.xml (I haven't looked to the technical consequences though).  
Then the maven2 community could also be an Ivy community. So the  
Ivyrep Adrian is looking for could be nothing more than the ibiblio one.


Nicolas




This could be avoided if an IvyRep was maintained (at least I could
do "install").

Just a new user's opinion :)

Adrian

- Original Message 
From: Xavier Hanin <[EMAIL PROTECTED]>
To: Ant Developers List 
Sent: Saturday, February 9, 2008 2:44:15 AM
Subject: Add maven2 resolver?


Hi,

Now
that
Ivy
is
using
maven
2
repository
as
default
public
repository,
and
that
we
see
many
people
trying
to
leverage
maven
2
repositories,
I'm
wondering
if
we
shouldn't
introduce
a
maven2
resolver.
This
resolver
would
basically
be
the
equivalent
of
ibiblio
resolver
with
m2compatible
set
to
true.
The
advantage
is
a
better
name,
and
we
can
make
also
other
improvements.
For
instance,
we
could
set
checkConsistency
to
false
on
this
resolver,
since
pretty
often
people
complain
about
inconsitencies
in
maven2
repo
(see
for
instance
last
comments
on
[1]).
We
may
also
set
the
changingPattern
to
make
SNAPSHOT
dependencies
work
(more
than
that
needs
to
be
done,
this
should
be
addressed
in
IVY-501).
We
may
even
try
to
make
this
resolver
leverage
maven2
cache,
for
people
who
work
with
both
Ivy
and
maven
2
on
the
same
machine.

WDYT?

Xavier

[1]


http://tapestryjava.blogspot.com/2007/11/maven-wont-get-fooled-again.html

--
Xavier
Hanin
-
Independent
Java
Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/











Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php? 
category=shopping



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





--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/



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

Re: [DISCUSS] release Ivy 2.0.0-beta2?

[Nicolas Lalevée]

Le mercredi 20 février 2008, Gilles Scokart a écrit :
> Will we release only ivy or also ivyde ?

This would be a good idea, but I don't think IvyDE is ready to be released.
IVYDE-70 fix an anoying bug but also change the way the configuration is 
stored, so it should be included in the next release. But due to the fact 
that it is a quite big internal change, I will be confident to do a release 
only after at least a week of use with the fix.
There is also IVYDE-77 which should be investigated before the release.

So I would say that an IvyDE release should not happened in the next one or 
two weeks.

Nicolas

>
> Gilles
>
> 2008/2/15, Adrian Sandor <[EMAIL PROTECTED]>:
> > Xavier Hanin wrote:
> > > > I attached a patch to IVY-399, please review.
> > >
> > > I don't have time to review in details right now, but at first glance
> > > it seems to be a very good job!
> >
> > Thanks!
> > Take your time, no problem. Just hope to see it in beta 2 :)
> >
> >
> > Adrian



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Re: [VOTE][RESULT] add Nicolas Lalevée as committer

[Nicolas Lalevée]

Le jeudi 21 février 2008, Xavier Hanin a écrit :
> Hi All,
>
> With 13 binding +1, 1 non binding, and one "accordez moi", I'm pleased to
> announce that this vote passed successfully.
>
> Nicolas, we are honoured to welcome you as a new Apache Ant committer.
>
> I will contact you in private to give you some details on what you need to
> do now to wear your ASF committer hat :-)
>
> Welcome aboard!


I am honoured to be part of the Apache family. :)

Following the tradition let's introduce myself.

I am 27 years old, french, and I live in Toulouse, while being in the heart a 
mediterranean as all my childhood was in front of the see.

I started to not only use computers but try to improve them with a Ti-89 
calculator [1]. So I started at a very low level with some 68k asm, and then 
I quickly learned C to avoid some headache.

Then I discovered Java in my french engineering school which I found pretty 
cool in transforming segmentation faults into NPEs. After my graduation I did 
an internship at Anyware Technologies where I discovered the web 
applications, the open source and the Apache Foundation via Sylvain Wallez. 
Thank you Sylvain for introducing me to the Apache projects, but most of all 
to the community aspect of the foundation.

Working on different projects I learned first about Cocoon, then I did some 
Eclipse plugins. After that I deeply looked into Lucene, also OpenRDF, and 
learned about Ivy after some maven frustration. I also get interested by 
Husdon, did an Ivy plugin and became a committer there. Then little on my own 
(I would like to thank my managers to allow me to do so) I decided to try to 
make IvyDE work because I was bugging me and a lot of my colleagues, forcing 
us to use some tricks. I had some difficulties to enter into the Eclipse JDT 
framework, but some thread on the ivy user mailing list keep me investigating 
bugs. Now that I know deeper Eclipse, I will continue to improve IvyDE 
because I think that even if Ant + Ivy can be a standalone core build system, 
tools for users do make the difference between a application and a great 
application.

Thank you everyone!

Nicolas

[1] http://www.hibnet.org/ti.php

PS: special dedication to my father who wrote me a dedication in his 
book : "you have to contribute to the open source !". Done dad ! ;)

>
> Xavier
>
> On Wed, Feb 13, 2008 at 10:35 AM, Xavier Hanin <[EMAIL PROTECTED]>
>
> wrote:
> > Hi All,
> >
> > Nicolas Lalevée has contributed a lot of patches to Ivy and IvyDE [1 to
> > 10], and has been actively involved in several discussions, especially
> > about IvyDE. He is always fair when giving his opinion, and often try to
> > help other users.
> >
> > IvyDE is a subproject of Ivy considered as highly important by several
> > users [11], and Nicolas is greatly helping to improve it.
> >
> > So I think he would make a good addition to our developer team, hence
> > this is a vote to make him a new committer.
> >
> > Even though only votes cast by PMC members are binding [12], all votes
> > are welcome and important to us.
> >
> > Here's my vote: +1
> >
> > Xavier
> >
> > [1] https://issues.apache.org/jira/browse/IVY-704
> > [2] https://issues.apache.org/jira/browse/IVY-702
> > [3] https://issues.apache.org/jira/browse/IVY-646
> > [4] https://issues.apache.org/jira/browse/IVYDE-62
> > [5] https://issues.apache.org/jira/browse/IVYDE-69
> > [6] https://issues.apache.org/jira/browse/IVYDE-66
> > [7] https://issues.apache.org/jira/browse/IVYDE-64
> > [8] https://issues.apache.org/jira/browse/IVYDE-76
> > [9] https://issues.apache.org/jira/browse/IVYDE-68
> > [10] https://issues.apache.org/jira/browse/IVYDE-63
> > [11] http://www.nabble.com/ivyde-again-td15352211.html#a15352211
> > [12] http://ant.apache.org/bylaws.html#Decision%20Making
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Re: [EasyAnt] first proof of concept

[Nicolas Lalevée]

Le 1 févr. 08 à 20:31, Xavier Hanin a écrit :


Hi,

Some time ago I've launched a discussion about a new Ant+Ivy based  
build
system, that I called EasyAnt. Based on the discussion we've had so  
far,

I've developed a small proof of concept, which is available here:
http://people.apache.org/~xavier/easyant-POC-0.1.zip

If you have some time, please have a look, there's a README file at  
the root

of the main directory in the zip, explaining how to try it, and how it
works.

I'd appreciate to get some feedback on the concepts developed, and
especially those requiring changes in Ant: mainly use and extends  
mode for
Import and the phase concept (explained in the README and more  
extensively

in the todo.txt).

Xavier
PS: don't pay too much attention to the code itself, it's rather  
ugly and

undocumented, but it's just a POC :-)


I like the idea but as an end user I had a very bad user experience is  
using maven because it resolve the build before using it. And it seems  
to be reproduced here. I would prefer a tool like the linux  
distributions are using. There is a special tool to manage the  
download of the latest component, resolving dependencies so ensuring  
that the downloaded tools are consistent.
For instance we could imagine having some targets easyant:init and  
esayant:update which should be similar to an "apt-get install" and an  
"apt-get dist-upgrade". So after successfully calling these targets  
the end user will be able to use its build system offline without  
worring of the consistent state of its build system.
Then there are the "apt-get update" and the "apt-cache search"  
features which would be very cool, but I wonder how Ivy could support  
that.


Then about the implementation, here are some few questions:

I don't understand exactly what is the module.ivy in the exemple. Is  
it a strict equivalent to the pom.xml, so it will replace a build.xml  
+ ivy.xml ?


Then quoting the README:
"The idea is to have a very limited options of customizing the build  
in the Ivy file: settings
properties, and telling which main build module shold be imported. If  
you need more, you have to use

a module.ant file."

Why not just having a module.ant ?
And then why naming it module.ant, couldn't it be a classic  
build.xml ? What will be the difference for the end user?


Nicolas


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

Re: Ivy 2.0 planning

[Nicolas Lalevée]

Le jeudi 28 février 2008, Xavier Hanin a écrit :
> Hi,
>
> Ivy 2.0 beta 2 being around the corner, I've reviewed some of the current
> open issues in JIRA. I've marked all open bugs to be fixed in 2.0, as I
> would like to make 2.0 final as stable and clean as possible. I even think
> that fixing bugs should be our main focus now toward 2.0 final. The current
> feature set is pretty good, so if we don't want to dilute too much our
> effort and the time frame for 2.0 final, I think focusing on bug fix is a
> good option. I don't say we should stop developing features, sometimes we
> may have some needs or specific interest in some new features. Moreover
> fixing bugs is not the most entertaining thing to do, so we'll probably
> need some rest with more interesting stuff :-).
>
> So, do you guys agree with this plan?

+1

Just one note about not stopping adding features.

I follow the Lucene community, and they have an interesting workflow for 
commits. With every feature or bug fix there is a Jira issue. Then someone do 
a patch and attach it to the issue. So the patch generally get reviewed and 
commented by sevral commiters, a patch is always commited only one or two 
days after it has been proposed. And in a release period, only bug fix patchs 
are commited, the feature ones wait the final release to be public.

I don't think we should have a such complete workflow, I don't think there are 
enought active people here, not yet. But at least for new feature in a 
release period I think it would be a good practice to only do patchs but not 
commit them.

WDYT ?

Nicolas

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

Re: [jira] Commented: (IVYDE-82) Empty containers disappear with Eclipse 3.3

[Nicolas Lalevée]

Le mardi 4 mars 2008, Xavier Hanin a écrit :
> On Tue, Mar 4, 2008 at 11:42 AM, Nicolas Lalevée (JIRA) <[EMAIL PROTECTED]>
>
> wrote:
> >[
> > https://issues.apache.org/jira/browse/IVYDE-82?page=com.atlassian.jira.pl
> >ugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574924#acti
> >on_12574924]
> >
> > Nicolas Lalevée commented on IVYDE-82:
> > --
> >
> > I have found some code in m2eclipse, the Maven eclipse plugin that
> > conatins a workaround to an eclipse missing feature. It refers to
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=154071
> >
> > I have tested the workaround, it make eclipse work better, even if as
> > explain in the Maven plugin code a refresh of the project might be
> > needed.
> >
> > I cannot provide a patch as my working copy of IvyDE contains too many
> > patch, maybe I should give a try to have a local svn-git repo.
>
> I hope your ICLA will be processed soon, so that you can apply your changes
> and contribute more easily. Be patient, voluntary based maintenance
> sometimes suffer from some slowness, we all are busy people after all.

yep, I am maybe too impatient ;)
Thanks for your time thought.

Nicolas

>
> Xavier
>
> > > Empty containers disappear with Eclipse 3.3
> > > ---
> > >
> > > Key: IVYDE-82
> > > URL: https://issues.apache.org/jira/browse/IVYDE-82
> > >     Project: IvyDE
> > >  Issue Type: Bug
> > >Affects Versions: 1.3.0
> > > Environment: with the IVYDE-70 patch
> > > Eclipse 3.3, Eclipse 3.4M4
> > >Reporter: Nicolas Lalevée
> > >
> > > If the resolved dependencies are empty, due to an empty dependency tree
> >
> > or some dependencies errors, then the class path container disappears.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Re: AW: [VOTE][RESULT] add Nicolas Lalevée as committer

[Nicolas Lalevée]

Le lundi 25 février 2008, [EMAIL PROTECTED] a écrit :
> > > With 13 binding +1, 1 non binding, and one "accordez moi",
> >
> > I'm pleased to
> >
> > > announce that this vote passed successfully.
> > >
> > > Nicolas, we are honoured to welcome you as a new Apache Ant committer.
> > >
> > > I will contact you in private to give you some details on what you need
> > > to do now to wear your ASF committer hat :-)
> > >
> > > Welcome aboard!
> >
> > I am honoured to be part of the Apache family. :)
> >
> > Following the tradition let's introduce myself.
> >
> > I am 27 years old, french, and I live in Toulouse, while
> > being in the heart a
> > mediterranean as all my childhood was in front of the see.
> >
> > I started to not only use computers but try to improve them
> > with a Ti-89
> > calculator [1]. So I started at a very low level with some
> > 68k asm, and then
> > I quickly learned C to avoid some headache.
> >
> > Then I discovered Java in my french engineering school which
> > I found pretty
> > cool in transforming segmentation faults into NPEs. After my
> > graduation I did
> > an internship at Anyware Technologies where I discovered the web
> > applications, the open source and the Apache Foundation via
> > Sylvain Wallez.
> > Thank you Sylvain for introducing me to the Apache projects,
> > but most of all
> > to the community aspect of the foundation.
> >
> > Working on different projects I learned first about Cocoon,
> > then I did some
> > Eclipse plugins. After that I deeply looked into Lucene, also
> > OpenRDF, and
> > learned about Ivy after some maven frustration. I also get
> > interested by
> > Husdon, did an Ivy plugin and became a committer there. Then
> > little on my own
> > (I would like to thank my managers to allow me to do so) I
> > decided to try to
> > make IvyDE work because I was bugging me and a lot of my
> > colleagues, forcing
> > us to use some tricks. I had some difficulties to enter into
> > the Eclipse JDT
> > framework, but some thread on the ivy user mailing list keep
> > me investigating
> > bugs. Now that I know deeper Eclipse, I will continue to
> > improve IvyDE
> > because I think that even if Ant + Ivy can be a standalone
> > core build system,
> > tools for users do make the difference between a application
> > and a great
> > application.
> >
> > Thank you everyone!
> >
> > Nicolas
> >
> > [1] http://www.hibnet.org/ti.php
> >
> > PS: special dedication to my father who wrote me a dedication in his
> > book : "you have to contribute to the open source !". Done dad ! ;)
>
> Welcome Nicolas.
> Maybe you could update the committer page when you have commit rights.

I got my commits rights, it is time to test them :)

But I am not sure which page you are talking about. There is this one :
http://ant.apache.org/contributors.html

But I don't see Xavier, Maarten or Gilles over there.
And as far as I know there isn't a such page on the ivy site.

So only reference to them I have found is there:
https://svn.apache.org/repos/asf/ant/ivy/core/trunk/RELEASE_NOTES

Nicolas

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

Re: svn commit: r640867 - in /ant/ivy/core/trunk: CHANGES.txt RELEASE_NOTES

[Nicolas Lalevée]

Le mardi 25 mars 2008, Xavier Hanin a écrit :
> On Tue, Mar 25, 2008 at 4:55 PM, <[EMAIL PROTECTED]> wrote:
> > Author: hibou
> > Date: Tue Mar 25 08:55:08 2008
> > New Revision: 640867
> >
> > URL: http://svn.apache.org/viewvc?rev=640867&view=rev
> > Log:
> > - moved my name from the contributor list to the committer list
> > - unified space and tabs use
> >
> > Modified:
> >ant/ivy/core/trunk/CHANGES.txt
> >ant/ivy/core/trunk/RELEASE_NOTES
> >
> > Modified: ant/ivy/core/trunk/CHANGES.txt
> > URL:
> > http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=640867&r1
> >=640866&r2=640867&view=diff
> >
> > =
> >= --- ant/ivy/core/trunk/CHANGES.txt (original)
> > +++ ant/ivy/core/trunk/CHANGES.txt Tue Mar 25 08:55:08 2008
> > @@ -8,6 +8,7 @@
> >  Committers
> >Maarten Coene
> >Xavier Hanin
> > +   Nicolas LalevÃ(c)e
>
> It seems you have an encoding problem. We use ISO-8859-1 encoding. Could
> you check that you use the same, and commit again with the properly encoded
> é ?

yep, I just saw it and it is already fixed and committed.

Nicolas

>
> Xavier
>
> >Gilles Scokart
> >
> >  Contributors
> > @@ -33,7 +34,6 @@
> >Christer Jonsson
> >Matthias Kilian
> >Gregory Kisling
> > -   Nicolas Lalevée
> >Tat Leung
> >Costin Leau
> >Antoine Levy-Lambert
> >
> > Modified: ant/ivy/core/trunk/RELEASE_NOTES
> > URL:
> > http://svn.apache.org/viewvc/ant/ivy/core/trunk/RELEASE_NOTES?rev=640867&;
> >r1=640866&r2=640867&view=diff
> >
> > =
> >= --- ant/ivy/core/trunk/RELEASE_NOTES (original)
> > +++ ant/ivy/core/trunk/RELEASE_NOTES Tue Mar 25 08:55:08 2008
> > @@ -154,20 +154,20 @@
> >  Committers
> >Maarten Coene
> >Xavier Hanin
> > +   Nicolas LalevÃ(c)e
> >Gilles Scokart
> >
> >  Contributors
> > -Andrea Bernardo Ciddio
> > -Mikkel Bjerg
> > -Mirko Bulovic
> > -Danno Ferrin
> > -Benjamin Francisoud
> > -   Nicolas Lalevée
> > -Markus M. May
> > -Adrian Sandor
> > -Ruslan Shevchenko
> > -Johan Stuyts
> > -
> > +   Andrea Bernardo Ciddio
> > +   Mikkel Bjerg
> > +   Mirko Bulovic
> > +   Danno Ferrin
> > +   Benjamin Francisoud
> > +   Markus M. May
> > +   Adrian Sandor
> > +   Ruslan Shevchenko
> > +   Johan Stuyts
> > +
> >  8. List of Changes in this Release
> >
> >  For a full release history of Ivy see the file CHANGES.txt



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Jira permissions

[Nicolas Lalevée]

Hi,

I got commit rights, and everything works like a charm apart some encoding 
issues :)

Then about Jira, shouldn't I have more edition right ? Like assigning myself 
to an issue ?

And it seems that I can edit some workflow :
https://issues.apache.org/jira/browse/IVYDE-70
But not on this one:
https://issues.apache.org/jira/browse/IVYDE-39

Did something strange happen when the jira database was imported from 
Jayasoft ?

Nicolas

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

Re: Jira permissions

[Nicolas Lalevée]

Le mercredi 26 mars 2008, Xavier Hanin a écrit :
> On Tue, Mar 25, 2008 at 6:33 PM, Nicolas Lalevée <
>
> [EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I got commit rights, and everything works like a charm apart some
> > encoding issues :)
> >
> > Then about Jira, shouldn't I have more edition right ? Like assigning
> > myself
> > to an issue ?
> >
> > And it seems that I can edit some workflow :
> > https://issues.apache.org/jira/browse/IVYDE-70
> > But not on this one:
> > https://issues.apache.org/jira/browse/IVYDE-39
> >
> > Did something strange happen when the jira database was imported from
> > Jayasoft ?
>
> No, the difference is that you are the reporter of one issue and not the
> other. But I've changed your privileges, you should now have proper rights
> on all Ivy and IvyDE issues. Please tell me if you still have any problem.

it works like a charm.
thanks !

Nicolas

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

Re: svn commit: r640878 - in /ant/ivy/core/trunk: CHANGES.txt RELEASE_NOTES

[Nicolas Lalevée]

Le mercredi 26 mars 2008, Xavier Hanin a écrit :
> On Tue, Mar 25, 2008 at 6:34 PM, Peter Reilly <[EMAIL PROTECTED]>
>
> wrote:
> > Text files do not specify an encoding.
> > It this utf-8 or win1252 or latin1 ?
>
> I think it's latin1 (ISO-8859-1)

yep, that's it.

Note that I don't mind not having the accent on my last name for this kind of 
file. I prefer not having accent than having some (?) character.

Nicolas

>
> Xavier
>
> > Peter
> >
> > On Tue, Mar 25, 2008 at 4:11 PM,  <[EMAIL PROTECTED]> wrote:
> > > Author: hibou
> > >  Date: Tue Mar 25 09:11:41 2008
> > >  New Revision: 640878
> > >
> > >  URL: http://svn.apache.org/viewvc?rev=640878&view=rev
> > >  Log:
> > >  Encoding fix
> > >
> > >  Modified:
> > > ant/ivy/core/trunk/CHANGES.txt
> > > ant/ivy/core/trunk/RELEASE_NOTES
> > >
> > >  Modified: ant/ivy/core/trunk/CHANGES.txt
> > >  URL:
> >
> > http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=640878&r1
> >=640877&r2=640878&view=diff
> >
> > 
> > =
> >=
> >
> > >  --- ant/ivy/core/trunk/CHANGES.txt (original)
> > >  +++ ant/ivy/core/trunk/CHANGES.txt Tue Mar 25 09:11:41 2008
> > >  @@ -8,7 +8,7 @@
> > >   Committers
> > > Maarten Coene
> > > Xavier Hanin
> > >  -   Nicolas LalevÃ(c)e
> > >  +   Nicolas Lalevée
> > > Gilles Scokart
> > >
> > >   Contributors
> > >
> > >  Modified: ant/ivy/core/trunk/RELEASE_NOTES
> > >  URL:
> >
> > http://svn.apache.org/viewvc/ant/ivy/core/trunk/RELEASE_NOTES?rev=640878&;
> >r1=640877&r2=640878&view=diff
> >
> > 
> > =
> >=
> >
> > >  --- ant/ivy/core/trunk/RELEASE_NOTES (original)
> > >  +++ ant/ivy/core/trunk/RELEASE_NOTES Tue Mar 25 09:11:41 2008
> > >  @@ -154,7 +154,7 @@
> > >   Committers
> > > Maarten Coene
> > > Xavier Hanin
> > >  -   Nicolas LalevÃ(c)e
> > >  +   Nicolas Lalevée
> > > Gilles Scokart
> > >
> > >   Contributors
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Re: svn commit: r640878 - in /ant/ivy/core/trunk: CHANGES.txt RELEASE_NOTES

[Nicolas Lalevée]

Le mercredi 26 mars 2008, Xavier Hanin a écrit :
> On Wed, Mar 26, 2008 at 9:27 AM, Nicolas Lalevée <
>
> [EMAIL PROTECTED]> wrote:
> > Le mercredi 26 mars 2008, Xavier Hanin a écrit :
> > > On Tue, Mar 25, 2008 at 6:34 PM, Peter Reilly <
> >
> > [EMAIL PROTECTED]>
> >
> > > wrote:
> > > > Text files do not specify an encoding.
> > > > It this utf-8 or win1252 or latin1 ?
> > >
> > > I think it's latin1 (ISO-8859-1)
> >
> > yep, that's it.
> >
> > Note that I don't mind not having the accent on my last name for this
> > kind of
> > file. I prefer not having accent than having some (?) character.
>
> And do you mind if you don't have the accent in a HTML file? Because the
> release notes are copy/pasted to an html page when we release a new
> version. I realize that in last release your name has a strange character:
> http://ant.apache.org/ivy/history/latest-milestone/release-notes.html

ah. Then why not having directly an html file in the svn more than a txt ? So 
we can put some HTML entities and this would avoid manual insertion of the 
links and hx tags while releasing. And if the txt file is still needed, some 
service usefull service exist: http://cgi.w3.org/cgi-bin/html2txt

Nicolas

>
> Xavier
>
> > Nicolas
> >
> > > Xavier
> > >
> > > > Peter
> > > >
> > > > On Tue, Mar 25, 2008 at 4:11 PM,  <[EMAIL PROTECTED]> wrote:
> > > > > Author: hibou
> > > > >  Date: Tue Mar 25 09:11:41 2008
> > > > >  New Revision: 640878
> > > > >
> > > > >  URL: http://svn.apache.org/viewvc?rev=640878&view=rev
> > > > >  Log:
> > > > >  Encoding fix
> > > > >
> > > > >  Modified:
> > > > > ant/ivy/core/trunk/CHANGES.txt
> > > > > ant/ivy/core/trunk/RELEASE_NOTES
> > > > >
> > > > >  Modified: ant/ivy/core/trunk/CHANGES.txt
> > > > >  URL:
> >
> > http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=640878&r1
> >
> > > >=640877&r2=640878&view=diff
> >
> > =
> >
> > > >=
> > > >
> > > > >  --- ant/ivy/core/trunk/CHANGES.txt (original)
> > > > >  +++ ant/ivy/core/trunk/CHANGES.txt Tue Mar 25 09:11:41 2008
> > > > >  @@ -8,7 +8,7 @@
> > > > >   Committers
> > > > > Maarten Coene
> > > > > Xavier Hanin
> > > > >  -   Nicolas LalevÃ(c)e
> > > > >  +   Nicolas Lalevée
> > > > > Gilles Scokart
> > > > >
> > > > >   Contributors
> > > > >
> > > > >  Modified: ant/ivy/core/trunk/RELEASE_NOTES
> > > > >  URL:
> >
> > http://svn.apache.org/viewvc/ant/ivy/core/trunk/RELEASE_NOTES?rev=640878&;
> >
> > > >r1=640877&r2=640878&view=diff
> >
> > =
> >
> > > >=
> > > >
> > > > >  --- ant/ivy/core/trunk/RELEASE_NOTES (original)
> > > > >  +++ ant/ivy/core/trunk/RELEASE_NOTES Tue Mar 25 09:11:41 2008
> > > > >  @@ -154,7 +154,7 @@
> > > > >   Committers
> > > > > Maarten Coene
> > > > > Xavier Hanin
> > > > >  -   Nicolas LalevÃ(c)e
> > > > >  +   Nicolas Lalevée
> > > > > Gilles Scokart
> > > > >
> > > > >   Contributors
> > > >
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Nicolas LALEVÉE
> > ANYWARE TECHNOLOGIES
> > Tel : +33 (0)5 61 00 52 90
> > Fax : +33 (0)5 61 00 51 46
> > http://www.anyware-tech.com
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

IvyDE source headers

[Nicolas Lalevée]

Hi,

I am adding missing Apache License headers in the sources files of IvyDE. In 
some file [1] there is:

Copyright Jayasoft 2005 - All rights reserved

Can I assume that I can replace them safely with the Apache License ?

Nicolas

[1] 
https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/src/java/org/apache/ivyde/eclipse/ui/console/IvyConsole.java

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

Re: IvyDE source headers

[Nicolas Lalevée]

Le lundi 31 mars 2008, Xavier Hanin a écrit :
> On Mon, Mar 31, 2008 at 3:25 PM, Nicolas Lalevée <
>
> [EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am adding missing Apache License headers in the sources files of IvyDE.
> > In
> > some file [1] there is:
> >
> > Copyright Jayasoft 2005 - All rights reserved
> >
> > Can I assume that I can replace them safely with the Apache License ?
>
> Sure, Jayasoft donated all the code to the ASF, I simply forgot to update
> headers in IvyDE. BTW, I wrote a small ruby script to add license headers
> to Ivy. Feel free to use it if you need:
> http://xhab.blogspot.com/2007/03/adding-license-header-to-whole-code.html

Great !

thanks,
Nicolas

>
> Xavier
>
> > Nicolas
> >
> > [1]
> >
> > https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/src/java/org/apache/
> >ivyde/eclipse/ui/console/IvyConsole.java
> >
> > ---------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Re: documentation

[Nicolas Lalevée]

Le 11 avr. 08 à 20:17, Jean-Claude Cerebro a écrit :

I agree.

In this case then, I would suggest we get a wiki that we can freely  
edit and
the core ivyteam can pick and choose what they want to include into  
the main

docs.  Confluence is a great option
and codehaus uses this.

I didn't realize the process involved a JIRA issue.  If that's the  
case then

that acts as a
deterrent to update docs in my opinion.



Well, per se a Jira issue is not required. It is just simpler for  
tracking down patches.
Note also that if a wiki is setup I don't think the current reference  
documentation will migrate to the wiki. The wiki would be an  
additional documentation, with different rights management. So  
changing the reference documentation will still need the patch process.


By the way, a user contributed documentation area is a good idea. At  
Apache there is MoinMoin and Confluence available:

http://wiki.apache.org/general/
http://cwiki.apache.org/confluence/dashboard.action

Personally I do prefer Confluence.

Nicolas





On Fri, Apr 11, 2008 at 11:46 AM, Brown, Carlton <
[EMAIL PROTECTED]> wrote:

I find the documentation is fairly complete in terms of content.   
It's
much better than some projects I could mention.  However, in many  
places

it lacks context and organization.  It's essentially organized around
the schema of ivy files and settings files, which is not the most
intuitive if you don't already know your way around the schema.

I'm willing to contribute documentation myself, but IMO the current
process is just too cumbersome, i.e. check out the source, edit the  
file

(using xooki which has its own issues), create a patch, open a JIRA,
check in a patch, wait for the patch to be accepted or rejected.  I
would have submitted many documentation improvements already if it
weren't for this heavyweight process.

Documentation changes are low-risk, it makes no sense to protect it  
as
tightly as source code.  Maybe let's have a public documentation  
branch
where everyone can submit documentation, then a committer can  
review and

merge changes to the mainline as time permits.


-Original Message-
From: Jean-Claude Cerebro [mailto:[EMAIL PROTECTED]
Sent: Friday, April 11, 2008 1:16 PM
To: [EMAIL PROTECTED]
Subject: Re: documentation

Hello Ivy Mailing List,

Based on these responses my feeling is that Xavier is taking
the brunt of the efforts for Ivy and that we need to be more
collaborative in helping solve issues raised.

Looking at the emails it seems that Xavier has a great deal
of domain-specific knowledge for ivy that needs to be
translated into docs on the ivy web site.

My suggestion is that if we end up having issues solved from
the mailing list we translate them into docs on a ivy web site.

For me, what's lacking is a use-case page because since Ivy
is so flexible without seeing options and the ways people are
doing things, its hard for me to know how best to use it.

For example Shawn, looks like he just spent six hours or so
trying to fix a cache problem that wasn't apparent from
reading the docs.  Wouldn't this be a great thing to put on
the docs in a more accessible way?

As well as the email with file extensions without artifacts?

Jean-Claude


On Fri, Apr 11, 2008 at 5:58 AM, Roman Legat
<[EMAIL PROTECTED]> wrote:


I'd like to mention on that:

There is a lot of (good) documentation, which is good

starting point.

What could be reworked is the structure. Sometimes it's

kind of hard

to find the things you're looking for.
What clearly is a mess right now is finding the right documentation
for the version you are using. In some places, the documentation is
outdated, or tutorials are referring to an older release.

The reason

for this is that ivy currently is in the process of

becoming 2.0.0 and

migrating to apache. So we have to live with that for a while until
things become more stable.

Nevertheless, it is up to every user to improve documentation, ivy
even provides a rather simple mechanism for changing and sending
documentation diffs.
So, if you
find a old reference, misspelling, outdated stuff - report it. That
saves precious time for 2.0.0.

What I am missing are alternative writings on ivy/ivyde besides the
project documentation. Blogs, tutorial, stuff like that from people
using ivy. How are you using it? What are your problems,

how do you solve them?

How do you setup your environment?

Roman

 Original-Nachricht 

Datum: Fri, 11 Apr 2008 13:32:49 +0200
Von: "Xavier Hanin" <[EMAIL PROTECTED]>
An: [EMAIL PROTECTED]
Betreff: Re: documentation



On Thu, Apr 10, 2008 at 2:19 AM, Jean-Claude Cerebro <
[EMAIL PROTECTED]> wrote:


Hi Xavier,


Did you notice you sent this e-mail to a mailing list?

Why am I the

only one to be fortunate enough to get your greetings ;-)



As a newbie just staring with Ivy I must say that I

love Ivy but

I'm disappointed, not with the capability of Ivy but with the

documentation.


Although the level of co

Upgrading the version of IvyDE

[Nicolas Lalevée]

Hi,

I would like to upgrade the version of IvyDE to 2.0. The trunk version is 
currently tagged to be an 1.3. I would like to make this upgrade for sevral 
reasons:
- the trunk version of IvyDE is relying on Ivy 2 whereas the last released 
version of IvyDE (1.2.1) is using Ivy 1.4.1. From a user point of view this 
will be easier to understand which version of IvyDE match which version of 
Ivy.
- the plugin ID of IvyDE changed. For the 1.2.1 it was 
org.jayasoft.ivyde.eclipse and now it is org.apache.ivyde.eclipse. So users 
won't be able to update their plugins. Actually they will appear as two 
different plugins.
- recently, due to a major bug fix (IVYDE-70), the preference are not managed 
the same way, the way to configure IvyDE changed. Having a version upgrade 
will make user aware of big changes.

I also think that some other refactoring may appear (IVYDE-32), so I think 
that IvyDE require a new version number regarding these big changes.

WDYT ?

Nicolas

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

Re: Is our objective for 2.0 too ambitious? (was Re: Ivy 2.0 planning)

[Nicolas Lalevée]

Le jeudi 17 avril 2008, Xavier Hanin a écrit :
> On Thu, Apr 17, 2008 at 3:32 AM, Bruce Atherton <[EMAIL PROTECTED]> wrote:
> > I think you have to accept that there will be bugs. After all, would you
> > halt the whole release if a minor bug was found the day before it was due
> > to be published?
> >
> > But there are different categories of bugs. Some are so serious that you
> > don't want to roll a release with it no matter what. This category really
> > should result in pulling a release the day before publishing. Then there
> > is a descending scale after that.
> >
> > My suggestion would be to use the Priority field for this purpose. Here
> > is how I use the Jira priorities:
> >  - Anything labeled "Blocker" should be fixed ASAP. It might be impacting
> > other developers working from the tip or perhaps breaking Gump.
> >  - "Critical" is for anything that has to be fixed before a release can
> > go out.
> >  - "Major" issues should be targeted for fixing for a release and their
> > number kept as low as possible, but if any ended up in a release you
> > wouldn't lose sleep over it.
> >  - "Minor" issues are the "nice-to-haves".
> >  - "Trivial" issues are ones that someone has complained about but the
> > developers don't see that fixing them would significantly improve the
> > product.
> >
> > If you have some sort of standard like that to go by, I think you can
> > fairly rapidly differentiate the bugs and then define a release as: No
> > Blockers or Criticals, and as few Majors as is practical to accomplish
> > within the time span available. The number of Minors and Trivials are
> > ignored.
>
> That sounds like a good practice. What do others think? How do we proceed
> to classify the open bugs?

I am in favor of a such classification too. About the process to classify 
them, I would say that it would be the same process as fixing issues. A 
committer get interested to an issue, try to found out to what's behind, and 
then decides its priority. And the other committers check via the 
[EMAIL PROTECTED] list.

Nicolas

>
> Xavier
>
> > Xavier Hanin wrote:
> > > More than one month ago we agreed to focus on bug fixing for 2.0 final
> > > (see
> > > my original mail below).
> > > At that time we had about 80+ issues targeted at 2.0.
> > > Since then it seems we have fixed 57 issues:
> > >
> > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> > >d=12310580&fixfor=12313012
> > >
> > > But we still have 64 issues to fix, which shows that new issues comes
> > > up (or
> > > some where retargeted or created to detail issues being fixed).
> > >
> > > This leads me to one question: is our objective to fix all open bugs
> > > for 2.0
> > > too ambitious?
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Re: Upgrading the version of IvyDE

[Nicolas Lalevée]

ok, thanks for your votes.
So I committed the new version number. And I will rename in Jira the version 
1.3.0 to 2.0.0.

cheers,
Nicolas


Le jeudi 17 avril 2008, Gilles Scokart a écrit :
> +1
>
> On 16/04/2008, Nicolas Lalevée <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >  I would like to upgrade the version of IvyDE to 2.0. The trunk version
> > is currently tagged to be an 1.3. I would like to make this upgrade for
> > sevral reasons:
> >  - the trunk version of IvyDE is relying on Ivy 2 whereas the last
> > released version of IvyDE (1.2.1) is using Ivy 1.4.1. From a user point
> > of view this will be easier to understand which version of IvyDE match
> > which version of Ivy.
> >  - the plugin ID of IvyDE changed. For the 1.2.1 it was
> >  org.jayasoft.ivyde.eclipse and now it is org.apache.ivyde.eclipse. So
> > users won't be able to update their plugins. Actually they will appear as
> > two different plugins.
> >  - recently, due to a major bug fix (IVYDE-70), the preference are not
> > managed the same way, the way to configure IvyDE changed. Having a
> > version upgrade will make user aware of big changes.
> >
> >  I also think that some other refactoring may appear (IVYDE-32), so I
> > think that IvyDE require a new version number regarding these big
> > changes.
> >
> >  WDYT ?
> >
> >  Nicolas
> >
> >  ---------
> >  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Re: Is our objective for 2.0 too ambitious? (was Re: Ivy 2.0 planning)

[Nicolas Lalevée]

Le jeudi 17 avril 2008, Xavier Hanin a écrit :
> On Thu, Apr 17, 2008 at 10:38 AM, Nicolas Lalevée <
>
> [EMAIL PROTECTED]> wrote:
> > Le jeudi 17 avril 2008, Xavier Hanin a écrit :
> > > On Thu, Apr 17, 2008 at 3:32 AM, Bruce Atherton <[EMAIL PROTECTED]>
> >
> > wrote:
> > > > I think you have to accept that there will be bugs. After all, would
> >
> > you
> >
> > > > halt the whole release if a minor bug was found the day before it was
> >
> > due
> >
> > > > to be published?
> > > >
> > > > But there are different categories of bugs. Some are so serious that
> >
> > you
> >
> > > > don't want to roll a release with it no matter what. This category
> >
> > really
> >
> > > > should result in pulling a release the day before publishing. Then
> >
> > there
> >
> > > > is a descending scale after that.
> > > >
> > > > My suggestion would be to use the Priority field for this purpose.
> >
> > Here
> >
> > > > is how I use the Jira priorities:
> > > >  - Anything labeled "Blocker" should be fixed ASAP. It might be
> >
> > impacting
> >
> > > > other developers working from the tip or perhaps breaking Gump.
> > > >  - "Critical" is for anything that has to be fixed before a release
> >
> > can
> >
> > > > go out.
> > > >  - "Major" issues should be targeted for fixing for a release and
> >
> > their
> >
> > > > number kept as low as possible, but if any ended up in a release you
> > > > wouldn't lose sleep over it.
> > > >  - "Minor" issues are the "nice-to-haves".
> > > >  - "Trivial" issues are ones that someone has complained about but
> > > > the developers don't see that fixing them would significantly improve
> > > > the product.
> > > >
> > > > If you have some sort of standard like that to go by, I think you can
> > > > fairly rapidly differentiate the bugs and then define a release as:
> > > > No Blockers or Criticals, and as few Majors as is practical to
> > > > accomplish within the time span available. The number of Minors and
> > > > Trivials are ignored.
> > >
> > > That sounds like a good practice. What do others think? How do we
> >
> > proceed
> >
> > > to classify the open bugs?
> >
> > I am in favor of a such classification too. About the process to classify
> > them, I would say that it would be the same process as fixing issues. A
> > committer get interested to an issue, try to found out to what's behind,
> > and
> > then decides its priority. And the other committers check via the
> > [EMAIL PROTECTED] list.
>
> But how do we know that the issue priority has been reviewed, especially if
> it doesn't change?

ha, good point :)

So I guess the review have to be done by some volonteers, the list of 
remaining issues being shared between them.
I think I can get some time at the end of next week to help.

Nicolas

>
> Xavier
>
> > Nicolas
> >
> > > Xavier
> > >
> > > > Xavier Hanin wrote:
> > > > > More than one month ago we agreed to focus on bug fixing for 2.0
> >
> > final
> >
> > > > > (see
> > > > > my original mail below).
> > > > > At that time we had about 80+ issues targeted at 2.0.
> > > > > Since then it seems we have fixed 57 issues:
> >
> > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> >
> > > > >d=12310580&fixfor=12313012
> > > > >
> > > > > But we still have 64 issues to fix, which shows that new issues
> >
> > comes
> >
> > > > > up (or
> > > > > some where retargeted or created to detail issues being fixed).
> > > > >
> > > > > This leads me to one question: is our objective to fix all open
> > > > > bugs for 2.0
> > > > > too ambitious?
> > > >
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Nicolas LALEVÉE
> > ANYWARE TECHNOLOGIES
> > Tel : +33 (0)5 61 00 52 90
> > Fax : +33 (0)5 61 00 51 46
> > http://www.anyware-tech.com
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

IvyDE build

[Nicolas Lalevée]

To everyone who is using a trunk version of IvyDE, I have introduced a build 
system so you will be able to build it yourself (IVYDE-88). The build system 
is based on the Eclipse one, so in order to build IvyDE you must have a 
Eclipse installation (I have tested with Eclipse 3.2 and 3.3). And further 
more you need to have an Ivy 2 bundle installed in the Eclipse installation.

Basically to install Ivy 2 into Eclipse, get somehow the Ivy jar that you want 
to use (by building it yourself of getting it from the download page). And 
then copy it into the plugins directory. So do something like:
cp ivy.jar ./eclipse/plugins/org.apache.ivy_2.0.0.jar

Note that the layout changed under ivyde/trunk. Now the main plugin sources 
are under the directory org.apache.ivyde.eclipse.

So to build IvyDE:
- go into your working copy of the trunk: cd /ivyde/trunk
- run: ant build -DbaseLocation=.../tools/eclipse

The baseLocation property is mandatory: it defines the path of you Eclipse 
install you want to build with.

Then in the created directory "work" you will find a timestamped directory 
(something like 200804171513) in which you will find the zip archive ready to 
be unzip in a Eclipse install.

   ** -- **

Then I have some general questions.

I have changed the svn repsoitory layout. Everything which was under 
ivyde/trunk is now under ivyde/trunk/org.apache.ivyde.eclipse. So the 
CHANGES.txt is there. Shouldn't it be moved to the upper directory ? 
under /ivyde/trunk ?
There is also LICENSE.txt. But I think it should stay there, shouldn't it ?
And there is the doc directory which contains the site documentation. I think 
it could also be moved. WDYT ?

This is an introduction mail to the IvyDE build, but we mostly need a 
documentation in the web site. So I would like to add a page and also make 
the IvyDE website have a similar hierarchy to the Ivy one. So we would have 
a "Documentation" and "Get involved" categories.
Currently there is
* Home
o Editor
o Classpath Container
o Use with maven poms
* Download
* Issue Tracking

So it would become:
* Home
* Download
* Documentation
o Editor
o Classpath Container
o Use with maven poms
* Get Involved
o Issue Tracking
o Building

WDYT ?

And finally I have a xooki question. First is there any documentation about 
xooki apart from these pages ?
http://xooki.sourceforge.net/
http://ant.apache.org/ivy/write-doc.html
And how do I add a main category ? Should I edit directly the json ?


cheers,
Nicolas

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

Re: Is our objective for 2.0 too ambitious? (was Re: Ivy 2.0 planning)

[Nicolas Lalevée]

Le 18 avr. 08 à 12:07, Xavier Hanin a écrit :

On Fri, Apr 18, 2008 at 8:48 AM, Gilles Scokart <[EMAIL PROTECTED]>  
wrote:


On 17/04/2008, Nicolas Lalevée <[EMAIL PROTECTED]>  
wrote:


But how do we know that the issue priority has been reviewed,

especially if

it doesn't change?



ha, good point :)



Maybe updating the target release...  Using the release 2.0-RC1 and
creating a new release named 'later'.


This is the easiest thing to do, it doesn't require changing the  
workflow.
BTW, instead of creating a release named 'later', we can simply use  
the
"Unknown" entry, which let issues appear as "unscheduled" in Ivy  
page on

JIRA.

If I sumup the proposal is that any committer can review any issue  
currently
marked with fix for 2.0, change its priority if required, and change  
the fix
for to 2.0-RC1 if the priority is blocker or critical, and Unknown  
if the
priority is lower. All issues will be considered reviewed once  
there's no

more issue with fix for 2.0.

Do we all agree to use this strategy?


Sounds good.
+1

Nicolas





Xavier






--
Gilles Scokart

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





--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/



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

Re: IvyDE build

[Nicolas Lalevée]

Le 18 avr. 08 à 10:40, Xavier Hanin a écrit :


On Thu, Apr 17, 2008 at 6:15 PM, Nicolas Lalevée <
[EMAIL PROTECTED]> wrote:

To everyone who is using a trunk version of IvyDE, I have  
introduced a

build
system so you will be able to build it yourself (IVYDE-88). The build
system
is based on the Eclipse one, so in order to build IvyDE you must  
have a
Eclipse installation (I have tested with Eclipse 3.2 and 3.3). And  
further

more you need to have an Ivy 2 bundle installed in the Eclipse
installation.

Basically to install Ivy 2 into Eclipse, get somehow the Ivy jar  
that you

want
to use (by building it yourself of getting it from the download  
page). And

then copy it into the plugins directory. So do something like:
cp ivy.jar ./eclipse/plugins/org.apache.ivy_2.0.0.jar

Note that the layout changed under ivyde/trunk. Now the main plugin
sources
are under the directory org.apache.ivyde.eclipse.

So to build IvyDE:
- go into your working copy of the trunk: cd /ivyde/trunk
- run: ant build -DbaseLocation=.../tools/eclipse

The baseLocation property is mandatory: it defines the path of you  
Eclipse

install you want to build with.

Then in the created directory "work" you will find a timestamped  
directory
(something like 200804171513) in which you will find the zip  
archive ready

to
be unzip in a Eclipse install.


Good job! I haven't had time to test yet, but it's nice to have a  
clean

scripted build for IvyDE!


Well, it is not that clean. There are some useless copy of the sources  
and the requirement to have Ivy in the plugins directory.

But yeah, at least it is a reproductible build. :)









 ** -- **

Then I have some general questions.

I have changed the svn repsoitory layout. Everything which was under
ivyde/trunk is now under ivyde/trunk/org.apache.ivyde.eclipse. So the
CHANGES.txt is there. Shouldn't it be moved to the upper directory ?
under /ivyde/trunk ?


It depends what you put in this changes file, and how things are  
released.
ATM IvyDE is only an eclipse plugin, so I think keeping the  
CHANGES.txt in

the org.apache.ivyde.eclipse directory makes sense.




There is also LICENSE.txt. But I think it should stay there,  
shouldn't it

?


I think so too.


ok, so let's keep them where they are.






And there is the doc directory which contains the site  
documentation. I

think
it could also be moved. WDYT ?


It makes sense to move it under ivyde/trunk. Maybe it could be  
renamed to
site instead of doc, since it contains the whole IvyDE site, and not  
only
documentation (in Ivy core we have separated the site from the doc).  
Note
that we will have to update the svn:externals property on ivy site  
directory

to point to the new location.


Ah. In fact already I broke it with the last change. Moving again the  
doc folder will actually fix it.







This is an introduction mail to the IvyDE build, but we mostly need a
documentation in the web site. So I would like to add a page and  
also make
the IvyDE website have a similar hierarchy to the Ivy one. So we  
would

have
a "Documentation" and "Get involved" categories.
Currently there is
* Home
  o Editor
  o Classpath Container
  o Use with maven poms
* Download
* Issue Tracking

So it would become:
* Home
* Download
* Documentation
  o Editor
  o Classpath Container
  o Use with maven poms
* Get Involved
  o Issue Tracking
  o Building

WDYT ?


+1. We could even add a page called mailing lists, telling that they  
are

shared with Ivy core and pointing to the right location.


Yep good idea.
And then about the actual folders layout, why not splitting  
documentation and site as Ivy does ? And so introduce history, and  
keeping the IvyDE 1.2 doc on the web site.

The folders in svn would look like:

ivyde/
  site/
index.html (an new home page which would be "version agnostic")
...
documentation/ (svn:external to trunk/doc)
history/
  1.2.0 (svn:external to branches/1.2.0/doc)
  trunk/
org.apache.ivyde.eclipse/
org.apache.ivyde.feature/
builder/
doc/
  branches/
1.2.0/
  doc/
index.html  (svn cp of trunk/org.apache.eclipse.ivyde/doc/)
cp_container.html (svn cp)
editor.html (svn cp)
maven.html (svn cp)


And then have /ant/ivy/site/ivyde be an svn:externals to /ant/ivy/ 
ivyde/site
Or maybe we could even avoid that external reference and put directly  
the main ivyde pages into /ant/ivy/site/ivyde.


WDYT ?

And by the way, how the live site is updated ? Does every change in  
svn is automatically propagated to the web site ?


Nicolas









And finally I have a xooki question. First is there any documentation
about
xooki apart from these pages ?
http://xooki.sourceforge.net/
http://ant.apache.org/ivy/write-doc.html


Nope, nothing else. But I can answer questions :-)


he :)

And as you spread your knowledge

Re: [VOTE] migrate Ivy's wiki to Confluence

[Nicolas Lalevée]

Le mercredi 23 avril 2008, Xavier Hanin a écrit :
> Hi,
>
> There's been a discussion recently about Ivy's documentation, which end up
> discussing user contributed documentation and especially the wiki.
>
> It seems 2 Ivy committers would prefer to use Confluence for Ivy wiki:
> http://markmail.org/message/n4mvsmowb3ujlyeg
>
> Moreover, some users expressed their opinion about this preference too:
> http://markmail.org/message/kjbzcqukzhqrowwt
>
> I already expressed the reasons why I'd like to migrate:
> "First, in JIRA we have activated the wiki syntax, which is the same as
> confluence one. So using confluence it would be only one wiki syntax to
> learn for both the wiki and issues. Secondly, I think with confluence you
> have a rich text editor, which can be useful for people who don't want to
> learn the syntax, or for tables which are cumbersome to write and maintain
> in wiki syntax. Lastly, I much prefer the look of confluence pages over *
> MoinMoin*."
>
> So I'd like to start a vote to see if migrating Ivy's wiki to confluence is
> possible.

So as expected, here is my +1

Nicolas


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

Re: [VOTE] migrate Ivy's wiki to Confluence

[Nicolas Lalevée]

Le mercredi 23 avril 2008, Maarten Coene a écrit :
> Are we going to use confluence as a replacement for our current website
> (http://ant.apache.org/ivy), or only as a replacement for our wiki
> (http://wiki.apache.org/ivy/) ?

The vote is only for the wiki. We didn't discussed about changing the way we 
are editing the website. For me the website is cool as it is.

Nicolas


>
> Maarten
>
>
> - Original Message 
> From: Paul King <[EMAIL PROTECTED]>
> To: Ant Developers List 
> Sent: Wednesday, April 23, 2008 4:36:07 PM
> Subject: Re: [VOTE] migrate Ivy's wiki to Confluence
>
>
> If you can move straight in to Confluence 2.8, that will let you
> do page ordering which helps a lot if you want to export your
> site to PDF as a User Guide/PDF manual. It also seems to do
> a slightly better job formatting code examples.
>
> Cheers, Paul.
>
> Archie Cobbs wrote:
> > Not sure if my vote counts, but +1 from me in any case :-)
> >
> > -Archie
> >
> > On Wed, Apr 23, 2008 at 2:41 AM, Xavier Hanin <[EMAIL PROTECTED]>
> >
> > wrote:
> >> Hi,
> >>
> >> There's been a discussion recently about Ivy's documentation, which end
> >> up discussing user contributed documentation and especially the wiki.
> >>
> >> It seems 2 Ivy committers would prefer to use Confluence for Ivy wiki:
> >> http://markmail.org/message/n4mvsmowb3ujlyeg
> >>
> >> Moreover, some users expressed their opinion about this preference too:
> >> http://markmail.org/message/kjbzcqukzhqrowwt
> >>
> >> I already expressed the reasons why I'd like to migrate:
> >> "First, in JIRA we have activated the wiki syntax, which is the same as
> >> confluence one. So using confluence it would be only one wiki syntax to
> >> learn for both the wiki and issues. Secondly, I think with confluence
> >> you have a rich text editor, which can be useful for people who don't
> >> want to learn the syntax, or for tables which are cumbersome to write
> >> and maintain in wiki syntax. Lastly, I much prefer the look of
> >> confluence pages over * MoinMoin*."
> >>
> >> So I'd like to start a vote to see if migrating Ivy's wiki to confluence
> >> is
> >> possible.
> >>
> >> Xavier
> >> --
> >> Xavier Hanin - Independent Java Consultant
> >> http://xhab.blogspot.com/
> >> http://ant.apache.org/ivy/
> >> http://www.xoocode.org/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
>  
> ___
>_ Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile.  Try it now. 
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
> -
> 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: [VOTE] migrate Ivy's wiki to Confluence

[Nicolas Lalevée]

So there are finally :
binding +1: 5
other +1 : 1


Le 30 avr. 08 à 23:05, Antoine Levy-Lambert a écrit :


+1

Antoine
 Original-Nachricht 

Datum: Fri, 25 Apr 2008 07:43:47 +0200
Von: "Xavier Hanin" <[EMAIL PROTECTED]>
An: "Ant Developers List" 
Betreff: Re: [VOTE] migrate Ivy\'s wiki to Confluence



Obviously, here's my own +1.

It seems we have agreed to make this migration, but we still have  
to wait

for April 30th to respect usual vote timeframe.

I'll be in vacation next week, with no internet access. So if this  
vote

ends
up like we can expect, it would be nice if somebody could ask infra  
to

create the confluence wiki. Otherwise I'll do this when I come back.


I was offline too for some vacation too :)

Did you send any email, or should I do it ?

cheers,
Nicolas






Xavier

On Wed, Apr 23, 2008 at 9:41 AM, Xavier Hanin  
<[EMAIL PROTECTED]>

wrote:


Hi,

There's been a discussion recently about Ivy's documentation,  
which end

up

discussing user contributed documentation and especially the wiki.

It seems 2 Ivy committers would prefer to use Confluence for Ivy  
wiki:

http://markmail.org/message/n4mvsmowb3ujlyeg

Moreover, some users expressed their opinion about this preference  
too:

http://markmail.org/message/kjbzcqukzhqrowwt

I already expressed the reasons why I'd like to migrate:
"First, in JIRA we have activated the wiki syntax, which is the  
same as
confluence one. So using confluence it would be only one wiki  
syntax to
learn for both the wiki and issues. Secondly, I think with  
confluence

you
have a rich text editor, which can be useful for people who don't  
want

to

learn the syntax, or for tables which are cumbersome to write and

maintain
in wiki syntax. Lastly, I much prefer the look of confluence pages  
over

*

MoinMoin*."

So I'd like to start a vote to see if migrating Ivy's wiki to  
confluence

is

possible.

Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/





--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/


-
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: Including builder resolver in ivy

[Nicolas Lalevée]

Le 6 mai 08 à 18:27, Xavier Hanin a écrit :

On Mon, May 5, 2008 at 7:04 PM, Archie Cobbs <[EMAIL PROTECTED]>  
wrote:


I'd like to propose that the new "builder" resolver be included in  
ivy. In
order to do this however, other developers need to vote yes or no.  
So I'd

ask that you please let the list know your opinion.

Quick summary:

The Builder Resolver is a new Ivy resolver that supports downloading,
extracting and repackaging (as necessary) artifacts on-demand. It  
allows

for
a clearer separation between two jobs which don't necessarily go  
together:
maintaining Ivy meta-data, and hosting the actual artifacts. In  
addition,

it's easy to use the builder resolver to build a normal repository
containing artifacts.

The most important aspect of this new resolver is that it makes it  
much
easier to create and maintain a public Ivy repository, something  
that IMHO
is sorely lacking right now.  And the Ivy RoundUp project is  
already doing

just that (note Ivy RoundUp is a completely separate project from ivy
itself).

Some links...

* Builder resolver
patch<
http://ivyroundup.googlecode.com/svn/wiki/files/builder-resolver.patch 
>

* Builder resolver
documentation

This has also been discussed recently in a couple of threads
(here<
http://www.nabble.com/Ivy-RoundUp-Repository---feedback-requested-td16704469.html

and

here 

Re: Including builder resolver in ivy

[Nicolas Lalevée]

Le 6 mai 08 à 18:43, Archie Cobbs a écrit :


On Tue, May 6, 2008 at 11:27 AM, Xavier Hanin <[EMAIL PROTECTED]>
wrote:

I'd like to propose that the new "builder" resolver be included in  
ivy.

In
order to do this however, other developers need to vote yes or no.  
So

I'd

ask that you please let the list know your opinion.


The only thing I dislike with this resolver is its name. The  
'builder'

name
makes people think this resolver compiles modules, while it just  
repackage

them if necessary. Hence I prefer to use another name.



Another possible name that might better convey what it does is  
"Extractor

Resolver".

I don't really have any strong preference on the name though.



From the IvyRoundUp documentation:
Athough named the "builder" resolver, the only build operations  
currently supported are extracting files from archives, packaging  
files into archives, and moving and copying files. In the future more  
general build operations may be supported, once appropriate security  
controls are in place.


So I would say that it is *packaging* modules into an Ivy publishable  
structure. A packaging process that can, for some module just do some  
copy, jar and unjar, and for others some possible call to javac.


Then I am in favor of renaming it PackagerResolver.

Nicolas


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

Re: [VOTE] migrate Ivy's wiki to Confluence

[Nicolas Lalevée]

Le 7 mai 08 à 14:14, Xavier Hanin a écrit :

On Wed, May 7, 2008 at 12:03 PM, Nicolas Lalevée <[EMAIL PROTECTED] 
>

wrote:


So there are finally :
binding +1: 5
other +1 : 1


Le 30 avr. 08 à 23:05, Antoine Levy-Lambert a écrit :

+1


Antoine
 Original-Nachricht 


Datum: Fri, 25 Apr 2008 07:43:47 +0200
Von: "Xavier Hanin" <[EMAIL PROTECTED]>
An: "Ant Developers List" 
Betreff: Re: [VOTE] migrate Ivy\'s wiki to Confluence



Obviously, here's my own +1.


It seems we have agreed to make this migration, but we still have  
to

wait
for April 30th to respect usual vote timeframe.

I'll be in vacation next week, with no internet access. So if this
vote
ends
up like we can expect, it would be nice if somebody could ask  
infra to
create the confluence wiki. Otherwise I'll do this when I come  
back.





I was offline too for some vacation too :)

Did you send any email, or should I do it ?


I didn't, vas y :-)


I checked there:
http://www.apache.org/dev/reporting-issues.html#new-wiki
and there:
http://cwiki.apache.org/confluence/display/CWIKI/Index#Index-HowdowerequestaCWIKISpace%3F
No mail needed, just a jira issue.

Then here would be the space info :

Project Name: Apache Ivy
Keyword: IVY
Admin: ???

So I need "the cwiki account name of a PMC member (preferably the PMC  
chair) who will help administer the space".

Any volunteer ?

cheers,
Nicolas





Xavier





cheers,
Nicolas







Xavier

On Wed, Apr 23, 2008 at 9:41 AM, Xavier Hanin <[EMAIL PROTECTED] 
>

wrote:

Hi,


There's been a discussion recently about Ivy's documentation,  
which

end


up


discussing user contributed documentation and especially the wiki.

It seems 2 Ivy committers would prefer to use Confluence for Ivy
wiki:
http://markmail.org/message/n4mvsmowb3ujlyeg

Moreover, some users expressed their opinion about this preference
too:
http://markmail.org/message/kjbzcqukzhqrowwt

I already expressed the reasons why I'd like to migrate:
"First, in JIRA we have activated the wiki syntax, which is the  
same

as
confluence one. So using confluence it would be only one wiki  
syntax

to
learn for both the wiki and issues. Secondly, I think with
confluence


you


have a rich text editor, which can be useful for people who don't
want


to


learn the syntax, or for tables which are cumbersome to write and


maintain


in wiki syntax. Lastly, I much prefer the look of confluence pages
over


*


MoinMoin*."

So I'd like to start a vote to see if migrating Ivy's wiki to
confluence


is


possible.

Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/






--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/



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





--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/



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

Building the Ivy site

[Nicolas Lalevée]

Hi,

I was trying to build the site, but I got some js error about a 
missing "print". Does it rings a bell to anyone ?

cheers,
Nicolas

[EMAIL PROTECTED] ~/dev/ivy/svn/site $ LANG=en ant
Buildfile: build.xml

init-imported-history:

copy-resources:

generate-site:
[xooki:generate] May 19, 2008 7:35:29 AM org.apache.bsf.BSFManager exec
[xooki:generate] SEVERE: Exception :
[xooki:generate] java.security.PrivilegedActionException: 
org.apache.bsf.BSFException: JavaScript Error: Internal Error: 
org.mozilla.javascript.EcmaError: ReferenceError: "print" is not defined.
[xooki:generate]at java.security.AccessController.doPrivileged(Native 
Method)
[xooki:generate]at org.apache.bsf.BSFManager.exec(BSFManager.java:491)
[xooki:generate]at 
org.apache.tools.ant.util.optional.ScriptRunner.executeScript(ScriptRunner.java:103)
[xooki:generate]at 
org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:347)
[xooki:generate]at 
org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
[xooki:generate]at 
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[xooki:generate]at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown 
Source)
[xooki:generate]at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[xooki:generate]at java.lang.reflect.Method.invoke(Method.java:597)
[xooki:generate]at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
[xooki:generate]at org.apache.tools.ant.Task.perform(Task.java:348)
[xooki:generate]at 
org.apache.tools.ant.Target.execute(Target.java:357)
[xooki:generate]at 
org.apache.tools.ant.Target.performTasks(Target.java:385)
[xooki:generate]at 
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
[xooki:generate]at 
org.apache.tools.ant.Project.executeTarget(Project.java:1298)
[xooki:generate]at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[xooki:generate]at 
org.apache.tools.ant.Project.executeTargets(Project.java:1181)
[xooki:generate]at org.apache.tools.ant.Main.runBuild(Main.java:698)
[xooki:generate]at org.apache.tools.ant.Main.startAnt(Main.java:199)
[xooki:generate]at 
org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[xooki:generate]at 
org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
[xooki:generate] Caused by: org.apache.bsf.BSFException: JavaScript Error: 
Internal Error: org.mozilla.javascript.EcmaError: ReferenceError: "print" is 
not defined.
[xooki:generate]at 
org.apache.bsf.engines.javascript.JavaScriptEngine.handleError(JavaScriptEngine.java:195)
[xooki:generate]at 
org.apache.bsf.engines.javascript.JavaScriptEngine.eval(JavaScriptEngine.java:147)
[xooki:generate]at 
org.apache.bsf.util.BSFEngineImpl.exec(BSFEngineImpl.java:141)
[xooki:generate]at 
org.apache.bsf.BSFManager$6.run(BSFManager.java:493)
[xooki:generate]... 21 more

BUILD FAILED
/home/nicolasl/dev/ivy/svn/site/build.xml:68: 
org.mozilla.javascript.EcmaError: ReferenceError: "print" is not defined.

Total time: 1 second

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

Releasing IvyDE

[Nicolas Lalevée]

Hi,

Recently there were some users complaining that there is no release of IvyDE 
compatible with Ivy 2. [1] [2]

I know that IvyDE is not stable. See some major issues in Jira. For some 
people it is even getting less stable: [3]

But then I wonder if we could still do an alpha release, just to get people 
less annoyed by the 1.2 version which has some terrible issues [2], and 
probably more bug report, and hopefully more people interested in 
contributing.

WDYT ?

Nicolas

[1] 
http://mail-archives.apache.org/mod_mbox/ant-ivy-user/200805.mbox/[EMAIL 
PROTECTED]
[2] https://issues.apache.org/jira/browse/IVYDE-65
[3] 
http://mail-archives.apache.org/mod_mbox/ant-ivy-user/200805.mbox/[EMAIL 
PROTECTED]

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

Re: Building the Ivy site

[Nicolas Lalevée]

Le lundi 19 mai 2008, Xavier Hanin a écrit :
> On Mon, May 19, 2008 at 9:39 AM, Nicolas Lalevée
> <[EMAIL PROTECTED]>
>
> wrote:
> > Hi,
> >
> > I was trying to build the site, but I got some js error about a
> > missing "print". Does it rings a bell to anyone ?
>
> Which version of ant and java do you use? Here is the result of ant
> -diagnostics on my machine, on which "ant generate-site" works fine:
> -
>  --- Ant diagnostics report ---
> Apache Ant version 1.7.0 compiled on August 29 2007
>
> ---
>  Implementation Version
> ---
> core tasks : null
> optional tasks : not available
>
> ---
>  ANT PROPERTIES
> ---
> ant.version: Apache Ant version 1.7.0 compiled on August 29 2007
> ant.java.version: 1.6
> ant.core.lib: /usr/share/ant/lib/ant.jar
> ant.home: /usr/share/ant
>
> ---
>  ANT_HOME/lib jar listing
> ---
> ant.home: /usr/share/ant
> ant-bootstrap.jar (16489 bytes)
> ant-apache-bcel.jar (8784 bytes)
> tomcat5.5-jkstatus-ant.jar (30910 bytes)
> ant-antlr.jar (5912 bytes)
> catalina5.5-ant-jmx.jar (23730 bytes)
> ant-apache-resolver.jar (4064 bytes)
> ant-commons-logging.jar (4035 bytes)
> ant-jdepend.jar (8290 bytes)
> catalina5.5-ant.jar (26632 bytes)
> ant-junit.jar (94264 bytes)
> ant-swing.jar (6715 bytes)
> ant.jar (1327716 bytes)
> ant-apache-regexp.jar (3743 bytes)
> ant-apache-bsf.jar (4047 bytes)
> ant-trax.jar (6908 bytes)
> ant-launcher.jar (11814 bytes)
> ant-apache-log4j.jar (3042 bytes)
> ant-javamail.jar (7166 bytes)
> junit.jar (68448 bytes)
> ant-nodeps.jar (436656 bytes)
> ant-jmf.jar (6599 bytes)
> ant-commons-net.jar (47957 bytes)
> ant-apache-oro.jar (40144 bytes)
> ant-jsch.jar (30640 bytes)
>
> ---
>  USER_HOME/.ant/lib jar listing
> ---
> user.home: /home/xavier
> jsch-0.1.38.jar (177748 bytes)
> ivy.jar (898423 bytes)
>
> ---
>  Tasks availability
> ---
> image : Not Available (the implementation class is not present)
> wlrun : Not Available (the implementation class is not present)
> stlist : Not Available (the implementation class is not present)
> netrexxc : Not Available (the implementation class is not present)
> starteam : Not Available (the implementation class is not present)
> stylebook : Not Available (the implementation class is not present)
> stlabel : Not Available (the implementation class is not present)
> jdepend : Missing dependency jdepend.xmlui.JDepend
> stcheckin : Not Available (the implementation class is not present)
> stcheckout : Not Available (the implementation class is not present)
> ejbc : Not Available (the implementation class is not present)
> wlstop : Not Available (the implementation class is not present)
> ddcreator : Not Available (the implementation class is not present)
> A task being missing/unavailable should only matter if you are trying to
> use it
>
> ---
>  org.apache.env.Which diagnostics
> ---
> Not available.
> Download it at http://xml.apache.org/commons/
>
> ---
>  XML Parser information
> ---
> XML Parser : org.apache.xerces.jaxp.SAXParserImpl
> XML Parser Location: /usr/share/java/xercesImpl.jar
> Namespace-aware parser : org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
> Namespace-aware parser Location: /usr/share/java/xercesImpl.jar
>
> ---
>  System properties
> ---
> java.runtime.name : Java(TM) SE Runtime Environment
> sun.boot.library.path : /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386
> java.vm.version : 1.6.0_03-b05
> ant.library.dir : /usr/share/ant/lib
> java.vm.vendor : Sun Microsystems Inc.
> java.vendor.url : http://java.sun.com/
> path.separator : :
> java.vm.name : Java HotSpot(TM) Server VM
> file.encoding.pkg : sun.io
> user.country : US
> sun.java.launcher : SUN_STANDARD
> sun.os.patch.level : unknown
> java.vm.specification.name : Java Virtual Machine Specification
> user.dir : /home/xavier/Documents/ant+ivy/ivy-site
> java.runtime.version : 1.6.0_03-b05
> java.awt.graphicsenv : sun.awt.X11GraphicsEnvironmen

Re: Building the Ivy site

[Nicolas Lalevée]

Le mardi 20 mai 2008, Xavier Hanin a écrit :
> On Tue, May 20, 2008 at 12:40 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]>
>
> wrote:
> > Le lundi 19 mai 2008, Xavier Hanin a écrit :
> > > On Mon, May 19, 2008 at 9:39 AM, Nicolas Lalevée
> > > <[EMAIL PROTECTED]>
> > >
> > > wrote:
> > > > Hi,
> > > >
> > > > I was trying to build the site, but I got some js error about a
> > > > missing "print". Does it rings a bell to anyone ?
> > >
> > > Which version of ant and java do you use? Here is the result of ant
> > > -diagnostics on my machine, on which "ant generate-site" works fine:
> > > ---
> > >-- --- Ant diagnostics report ---
> > > Apache Ant version 1.7.0 compiled on August 29 2007
> > >
> > > ---
> > >  Implementation Version
> > > ---
> > > core tasks : null
> > > optional tasks : not available
> > >
> > > ---
> > >  ANT PROPERTIES
> > > ---
> > > ant.version: Apache Ant version 1.7.0 compiled on August 29 2007
> > > ant.java.version: 1.6
> > > ant.core.lib: /usr/share/ant/lib/ant.jar
> > > ant.home: /usr/share/ant
> > >
> > > ---
> > >  ANT_HOME/lib jar listing
> > > ---
> > > ant.home: /usr/share/ant
> > > ant-bootstrap.jar (16489 bytes)
> > > ant-apache-bcel.jar (8784 bytes)
> > > tomcat5.5-jkstatus-ant.jar (30910 bytes)
> > > ant-antlr.jar (5912 bytes)
> > > catalina5.5-ant-jmx.jar (23730 bytes)
> > > ant-apache-resolver.jar (4064 bytes)
> > > ant-commons-logging.jar (4035 bytes)
> > > ant-jdepend.jar (8290 bytes)
> > > catalina5.5-ant.jar (26632 bytes)
> > > ant-junit.jar (94264 bytes)
> > > ant-swing.jar (6715 bytes)
> > > ant.jar (1327716 bytes)
> > > ant-apache-regexp.jar (3743 bytes)
> > > ant-apache-bsf.jar (4047 bytes)
> > > ant-trax.jar (6908 bytes)
> > > ant-launcher.jar (11814 bytes)
> > > ant-apache-log4j.jar (3042 bytes)
> > > ant-javamail.jar (7166 bytes)
> > > junit.jar (68448 bytes)
> > > ant-nodeps.jar (436656 bytes)
> > > ant-jmf.jar (6599 bytes)
> > > ant-commons-net.jar (47957 bytes)
> > > ant-apache-oro.jar (40144 bytes)
> > > ant-jsch.jar (30640 bytes)
> > >
> > > ---
> > >  USER_HOME/.ant/lib jar listing
> > > ---
> > > user.home: /home/xavier
> > > jsch-0.1.38.jar (177748 bytes)
> > > ivy.jar (898423 bytes)
> > >
> > > ---
> > >  Tasks availability
> > > ---
> > > image : Not Available (the implementation class is not present)
> > > wlrun : Not Available (the implementation class is not present)
> > > stlist : Not Available (the implementation class is not present)
> > > netrexxc : Not Available (the implementation class is not present)
> > > starteam : Not Available (the implementation class is not present)
> > > stylebook : Not Available (the implementation class is not present)
> > > stlabel : Not Available (the implementation class is not present)
> > > jdepend : Missing dependency jdepend.xmlui.JDepend
> > > stcheckin : Not Available (the implementation class is not present)
> > > stcheckout : Not Available (the implementation class is not present)
> > > ejbc : Not Available (the implementation class is not present)
> > > wlstop : Not Available (the implementation class is not present)
> > > ddcreator : Not Available (the implementation class is not present)
> > > A task being missing/unavailable should only matter if you are trying
> > > to use it
> > >
> > > ---
> > >  org.apache.env.Which diagnostics
> > > ---
> > > Not available.
> > > Download it at http://xml.apache.org/commons/
> > >
> > > ---
> > >  XML Parser information
> > > ---
> > > XM

Re: Building the Ivy site

[Nicolas Lalevée]

Le 20 mai 08 à 14:46, Nicolas Lalevée a écrit :


Le mardi 20 mai 2008, Xavier Hanin a écrit :

On Tue, May 20, 2008 at 12:40 PM, Nicolas Lalevée
<[EMAIL PROTECTED]>

wrote:

Le lundi 19 mai 2008, Xavier Hanin a écrit :

On Mon, May 19, 2008 at 9:39 AM, Nicolas Lalevée
<[EMAIL PROTECTED]>

wrote:

Hi,

I was trying to build the site, but I got some js error about a
missing "print". Does it rings a bell to anyone ?


Which version of ant and java do you use? Here is the result of ant
-diagnostics on my machine, on which "ant generate-site" works  
fine:

---
-- --- Ant diagnostics report ---
Apache Ant version 1.7.0 compiled on August 29 2007

---
Implementation Version
---
core tasks : null
optional tasks : not available

---
ANT PROPERTIES
---
ant.version: Apache Ant version 1.7.0 compiled on August 29 2007
ant.java.version: 1.6
ant.core.lib: /usr/share/ant/lib/ant.jar
ant.home: /usr/share/ant

---
ANT_HOME/lib jar listing
---
ant.home: /usr/share/ant
ant-bootstrap.jar (16489 bytes)
ant-apache-bcel.jar (8784 bytes)
tomcat5.5-jkstatus-ant.jar (30910 bytes)
ant-antlr.jar (5912 bytes)
catalina5.5-ant-jmx.jar (23730 bytes)
ant-apache-resolver.jar (4064 bytes)
ant-commons-logging.jar (4035 bytes)
ant-jdepend.jar (8290 bytes)
catalina5.5-ant.jar (26632 bytes)
ant-junit.jar (94264 bytes)
ant-swing.jar (6715 bytes)
ant.jar (1327716 bytes)
ant-apache-regexp.jar (3743 bytes)
ant-apache-bsf.jar (4047 bytes)
ant-trax.jar (6908 bytes)
ant-launcher.jar (11814 bytes)
ant-apache-log4j.jar (3042 bytes)
ant-javamail.jar (7166 bytes)
junit.jar (68448 bytes)
ant-nodeps.jar (436656 bytes)
ant-jmf.jar (6599 bytes)
ant-commons-net.jar (47957 bytes)
ant-apache-oro.jar (40144 bytes)
ant-jsch.jar (30640 bytes)

---
USER_HOME/.ant/lib jar listing
---
user.home: /home/xavier
jsch-0.1.38.jar (177748 bytes)
ivy.jar (898423 bytes)

---
Tasks availability
---
image : Not Available (the implementation class is not present)
wlrun : Not Available (the implementation class is not present)
stlist : Not Available (the implementation class is not present)
netrexxc : Not Available (the implementation class is not present)
starteam : Not Available (the implementation class is not present)
stylebook : Not Available (the implementation class is not present)
stlabel : Not Available (the implementation class is not present)
jdepend : Missing dependency jdepend.xmlui.JDepend
stcheckin : Not Available (the implementation class is not present)
stcheckout : Not Available (the implementation class is not  
present)

ejbc : Not Available (the implementation class is not present)
wlstop : Not Available (the implementation class is not present)
ddcreator : Not Available (the implementation class is not present)
A task being missing/unavailable should only matter if you are  
trying

to use it

---
org.apache.env.Which diagnostics
---
Not available.
Download it at http://xml.apache.org/commons/

---
XML Parser information
---
XML Parser : org.apache.xerces.jaxp.SAXParserImpl
XML Parser Location: /usr/share/java/xercesImpl.jar
Namespace-aware parser :


org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser


Namespace-aware parser Location: /usr/share/java/xercesImpl.jar

---
System properties
---
java.runtime.name : Java(TM) SE Runtime Environment
sun.boot.library.path : /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/ 
i386

java.vm.version : 1.6.0_03-b05
ant.library.dir : /usr/share/ant/lib
java.vm.vendor : Sun Microsystems Inc.
java.vendor.url : http://java.sun.com/
path.separator : :
java.vm.name : Java HotSpot(TM) Server VM
file.encoding.pkg : sun.io
user.country : US
sun.java.launcher : SUN_STANDARD
sun.os.patch.level : unknown
java.vm.specification.name : Java Virtual Machine Specification
user.dir : /home/xavier/Documents/ant+ivy/ivy-site
java.runtime.version : 1.6.0_03-b05
java.awt.graphicsenv : sun.awt.X11GraphicsEnvironment
java.endorsed.dirs : /usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/ 
endorsed

os.arch : i386
java.io.tmpdir : /tmp
line.separator :

java.vm.specification.vendor : Sun Microsystems Inc.
os.name : Linux
ant.home : /usr/share/ant
sun.jnu.encoding : UTF-8
java.library.path :


/usr/lib/jvm/java-6-sun-1.6.0.03/jre/lib/i386/server:/usr/lib/jvm/ 
java-6-

su

n-1.6.0.03/jre/lib/i386:/usr/lib/jvm/java-6-sun

IvyDE site svn path

[Nicolas Lalevée]

Hi,

In subversion, there is an external link from ivy/site/ivyde to ivy/ 
ivyde/site. This link seems useless, we should svn move it instead.  
And this makes relative path to common images, css and js more  
difficult to manage.

Any objection to remove it and svn move it ?

Nicolas


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

Re: Releasing IvyDE

[Nicolas Lalevée]

Le mardi 20 mai 2008, Gilles Scokart a écrit :
> I didn't use IvyDE, but I'm +1 for an alpha or beta release seeing
> that recent bug reports starts to be reported against "The latest
> build (May 16 from www.hibnet.org)" [1] or from xoocode [2].
>
> [1] https://issues.apache.org/jira/browse/IVYDE-93
> [2] https://issues.apache.org/jira/browse/IVYDE-90
>
> 2008/5/19 Maarten Coene <[EMAIL PROTECTED]>:
> > +1 for an IvyDE release.
> > I'd prefer a beta release instead of an alpha release though...
> >

As there is no objection since last week, let's go for an IvyDE release !

As suggested by Xavier, I vonlonteer to be the release manager.

Marteen raised a question about the name of the release. For me, "alpha" 
means "release that developers know it to be unstable" and "beta" is 
for "developers think it has minor bugs but is stable, then let's the users 
test it".
For me it is unstable, mainly due to IVYDE-82 and currently I saw that 
IVYDE-54 can freaks out Eclipse.
So I vote for "alpha".

Then about the release, in order to follow the Apache guidelines, some work 
need to be done about packaging the source of IvyDE. I will look about how 
the sources are usually packaged for the Eclipse plugins. We should probably 
have different kind of packaging: the source got from an updatesite, and the 
full sources which also contains the build system.

We will also probably need an Apache Ivy updatsite. For the few tests I have 
done with my own one, it is not working properly, updates are not detected... 
Some investigation will be needed here too.

About the documentation, I have finished migrating the IvyDE website, so now 
there is the "history" category, like the Ivy site. I think we should publish 
it as soon as we get an IvyDE release adopted. WDYT ?

And the documentation in the binary distribution. Could a simple link to the 
website be enought ? Or should we push the html doc into the zip ?

In the Apache doc, I can read:
> If svn:externals is used, check carefully that a tag is referenced. This 
ensure that all the source for the release is fixed. If the target of a 
svn:externals changes then the release will no longer be complete 
reproducible.
So shouldn't xooki be released somehow ?

Does anybody see any other points that need to be addressed before starting to 
build a release ?

Nicolas


> >
> > - Original Message 
> > From: Xavier Hanin <[EMAIL PROTECTED]>
> > To: Ant Developers List 
> > Sent: Monday, May 19, 2008 6:19:40 PM
> > Subject: Re: Releasing IvyDE
> >
> > On Mon, May 19, 2008 at 4:49 PM, Nicolas Lalevée
> > <[EMAIL PROTECTED]>
> >
> > wrote:
> >> Hi,
> >>
> >> Recently there were some users complaining that there is no release of
> >> IvyDE
> >> compatible with Ivy 2. [1] [2]
> >>
> >> I know that IvyDE is not stable. See some major issues in Jira. For some
> >> people it is even getting less stable: [3]
> >>
> >> But then I wonder if we could still do an alpha release, just to get
> >> people less annoyed by the 1.2 version which has some terrible issues
> >> [2], and probably more bug report, and hopefully more people interested
> >> in contributing.
> >>
> >> WDYT ?
> >
> > I'm  a strong +1 to get an alpha release of IvyDE out. I don't have much
> > time currently though, but according to the high quality of the job
> > you've done so far on IvyDE and its build system, I'm confident you are
> > able to be the release manager for this version if you want.
> >
> > Xavier
> >
> >> Nicolas
> >>
> >> [1]
> >>
> >> http://mail-archives.apache.org/mod_mbox/ant-ivy-user/200805.mbox/%3cB03
> >>[EMAIL PROTECTED] [2]
> >> https://issues.apache.org/jira/browse/IVYDE-65
> >> [3]
> >>
> >> http://mail-archives.apache.org/mod_mbox/ant-ivy-user/200805.mbox/%3cDA8
> >>[EMAIL PROTECTED]
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Re: [ivy] IVYDE release?

[Nicolas Lalevée]

Le lundi 2 juin 2008, Scheper, Erik-Berndt a écrit :
> Hi,
>
> I was wondering what the current status of the planned IVYDE release is.
> Personally I think it would be nice if the suggested alpha release would be
> built on top of an an updated official IVY release (either as beta 3 or as
> rc1). Then we would have both in sync.
>
> Any other comments, suggestions?

I don't think we need to synchronize anything. IvyDE and Ivy are two different 
bundles in Eclipse. So here we can release a ivyde Eclipse feature with ivyde 
2.0 alpha1 and Ivy 2.0 beta2. And when Ivy 2.0 RC1 will go out, we can 
release another ivyde Eclipse feature with ivyde 2.0 alpha1 and Ivy 2.0RC1.

Another solution is to create a Eclipse feature for Ivy, and making the IvyDE 
feature depends on it. I don't know what is the best thought.

So both case will be more flexible, and keep our releasing work less painfull.

Nicolas

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

Re: Setting up Eclipse update site

[Nicolas Lalevée]

Le jeudi 29 mai 2008, Stefan Bodewig a écrit :
> On Wed, 28 May 2008, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> > There are a few thing to take into considerations :
> >
> > 1. An eclipse update site must provide a site map page [1] that has
> > to change when a new version come.  2. The site map give the
> > possibility to reference an other file that contains a list of
> > mirrors.
> >
> > So, we have to choose what we want to archive and mirror :
> > - The jars
> > - The site.xml
> > - The mirror file
> >
> > I guess that we should mirror the jars,
>
> absolutely.
>
> > but I'm not sure about the site.xml and the page that list the
> > mirrors.
>
> If we make the page that lists the mirrors a CGI on the site (just
> like the downloadpages) we might be fine.
>
> Will Eclipse use the mirrors of that list or is it a user choice?  If
> it is a user choice then the main page should be a CGI as well and
> point to the mirrored jars so that Eclipse users would be forced to do
> something explicitly if they want to download the jars from
> apache.org.

I have found this interesting page:
http://incubator.apache.org/guides/releasing-eclipse-update-site.html

There even a link to a build.xml that create the files for the update site. I 
didn't took time to look at it closely though.

By the way, I have found some other docs about releasing, licencing, mirroring 
etc, in the "incubator" website. Does those docs are irrelevent for graduated 
project ? Or I can rely on them (apart from the release vote process) ?

Nicolas, reading apache docs

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

Re: Ivy confluence wiki

[Nicolas Lalevée]

Le lundi 9 juin 2008, Xavier Hanin a écrit :
> On Mon, Jun 9, 2008 at 3:00 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> > Two questions :
> > - Who has write access ?
> > - Will we receive email notifications of changes ?
>
> Well, I don't know, I'm supposed to be in the admin group for this space,
> but I haven't found how to check / modify this kind of thing. I've only
> managed to update the page yet. Any help from somebody who knows confluence
> admin would be welcome.

I don't know the admin interface of Confluence, but I found this:
http://confluence.atlassian.com/display/CONF20/Assigning+Space+Permissions

Nicolas

>
> Xavier
>
> > I have signed up, but I didn't find how to modify the page.
> >
> > Gilles
> >
> > 2008/6/9 Xavier Hanin <[EMAIL PROTECTED]>:
> > > On Tue, Jun 3, 2008 at 9:29 AM, Xavier Hanin <[EMAIL PROTECTED]>
> >
> > wrote:
> > >> On Wed, May 7, 2008 at 6:03 PM, Nicolas Lalevée <
> > >>
> > >> [EMAIL PROTECTED]> wrote:
> > >>> I checked there:
> > >>> http://www.apache.org/dev/reporting-issues.html#new-wiki
> > >>> and there:
> >
> > http://cwiki.apache.org/confluence/display/CWIKI/Index#Index-Howdowereque
> >staCWIKISpace%3F
> >
> > >>> No mail needed, just a jira issue.
> > >>>
> > >>> Then here would be the space info :
> > >>>
> > >>> Project Name: Apache Ivy
> > >>> Keyword: IVY
> > >>> Admin: ???
> > >>>
> > >>> So I need "the cwiki account name of a PMC member (preferably the PMC
> > >>> chair) who will help administer the space".
> > >>> Any volunteer ?
> > >>
> > >> I just got the answer from Conor, so both Conor and I volunteer. I
> >
> > created
> >
> > >> the JIRA request:
> > >> https://issues.apache.org/jira/browse/INFRA-1634
> > >
> > > The confluence wiki for Ivy is now opened:
> > > http://cwiki.apache.org/confluence/display/IVY/Index
> > >
> > > Feel free to contribute!
> > >
> > > Xavier
> > >
> > >> <https://issues.apache.org/jira/browse/INFRA-1634>
> > >>
> > >> Xavier
> > >>
> > >>> cheers,
> > >>> Nicolas
> > >>>
> > >>>> Xavier
> > >>>>
> > >>>>> cheers,
> > >>>>> Nicolas
> > >>>>>
> > >>>>>>> Xavier
> > >>>>>>>
> > >>>>>>> On Wed, Apr 23, 2008 at 9:41 AM, Xavier Hanin <
> >
> > [EMAIL PROTECTED]
> >
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>>> There's been a discussion recently about Ivy's documentation,
> >
> > which
> >
> > >>>>>>>> end
> > >>>>>>>>
> > >>>>>>>>  up
> > >>>>>>>
> > >>>>>>>  discussing user contributed documentation and especially the
> > >>>>>>> wiki.
> > >>>>>>>
> > >>>>>>>> It seems 2 Ivy committers would prefer to use Confluence for Ivy
> > >>>>>>>> wiki:
> > >>>>>>>> http://markmail.org/message/n4mvsmowb3ujlyeg
> > >>>>>>>>
> > >>>>>>>> Moreover, some users expressed their opinion about this
> > >>>>>>>> preference too:
> > >>>>>>>> http://markmail.org/message/kjbzcqukzhqrowwt
> > >>>>>>>>
> > >>>>>>>> I already expressed the reasons why I'd like to migrate:
> > >>>>>>>> "First, in JIRA we have activated the wiki syntax, which is the
> >
> > same
> >
> > >>>>>>>> as
> > >>>>>>>> confluence one. So using confluence it would be only one wiki
> >
> > syntax
> >
> > >>>>>>>> to
> > >>>>>>>> learn for both the wiki and issues. Secondly, I think with
> > >>>&g

[VOTE] Release of Apache IvyDE 2.0.0.alpha1

[Nicolas Lalevée]

Hi,

I am pleased to announce that I have a version of IvyDE ready to be released. 
You will find the files in my home directory on people.apache.org
/home/hibou/ivyde-release

About the released files:
two files are classic release files:
* apache-ivyde-sources-2.0.0.alpha1.zip: the source distribution.
  it includes every files which is needed to build that distribution
* org.apache.ivyde.feature-2.0.0.alpha1.zip: the binary distribution.
  it includes the files ready to be deployed into an Eclipse install

Then there are the files deployed into the IvyDE update site. First few words 
on the update site. It will deployed at the URL:
http://ant.apache.org/ivy/ivyde/updatesite
Then, the files that will be effectively there, so in www.apache.org:
* the site.xml: discribe the deployed features
* the digest.zip: the compress manifest of every features (optimized eclipse 
update site)
* eclipse-update--xml.cgi and eclipse-update--xml.html: the files that defines 
the apache mirrors for Eclipse.
And the binary files packaged for the updatesite (the jar and jar.pack.gz) 
will be in the apache dist directory. More precisely the plugins and features 
directories and all of their files will be in dist/ant/ivy/ivyde/updatesite/

One note on the packaging of Ivy as an Eclipse updatable plug-in. Due to two 
bugs in the packaging of Ivy (IVY-828,IVY-802), a repackaging is needed. The 
repackaging I have done can be reproduced with the target install-ivy. It is 
based on the official 2.0.0.beta2 release.

If you want to reproduce the build, just do:
ant /release dist -DbaseLocation=$YOUR_ECLIPSE_HOME

If you want to test the update site, just get locally the "updatesite" 
directory from the release, and in Eclipse, setup a "local site" that point 
to your local copy of the "updatesite" directory.

About verifying the signatures, you will find mine there:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7BF8BE8E
But I am not sure how to update the KEYS file. I have found how to append my 
public key:
(gpg --list-sigs  && gpg --armor --export ) >> KEYS
But then should I just re-copy it into /www/www.apache.org/dist/ant/common on 
people.apache.org ? There is no commit or whatever, right ?

Last but not least, your vote:
+1 : you agree with the release
+0 : you agree but the next release should contain some fixes
-1 : you don't agree, there is a blocker issue with the release

so +1 for me (non binding)

Nicolas

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

Re: [VOTE] Release of Apache IvyDE 2.0.0.alpha1

[Nicolas Lalevée]

Le jeudi 19 juin 2008, Xavier Hanin a écrit :
> On Wed, Jun 18, 2008 at 6:42 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]>
>
> wrote:
> > Hi,
> >
> > I am pleased to announce that I have a version of IvyDE ready to be
> > released.
> > You will find the files in my home directory on people.apache.org
> > /home/hibou/ivyde-release
> >
> > About the released files:
> > two files are classic release files:
> > * apache-ivyde-sources-2.0.0.alpha1.zip: the source distribution.
> >  it includes every files which is needed to build that distribution
> > * org.apache.ivyde.feature-2.0.0.alpha1.zip: the binary distribution.
> >  it includes the files ready to be deployed into an Eclipse install
> >
> > Then there are the files deployed into the IvyDE update site. First few
> > words
> > on the update site. It will deployed at the URL:
> > http://ant.apache.org/ivy/ivyde/updatesite
> > Then, the files that will be effectively there, so in www.apache.org:
> > * the site.xml: discribe the deployed features
> > * the digest.zip: the compress manifest of every features (optimized
> > eclipse
> > update site)
> > * eclipse-update--xml.cgi and eclipse-update--xml.html: the files that
> > defines
> > the apache mirrors for Eclipse.
> > And the binary files packaged for the updatesite (the jar and
> > jar.pack.gz) will be in the apache dist directory. More precisely the
> > plugins and features
> > directories and all of their files will be in
> > dist/ant/ivy/ivyde/updatesite/
> >
> > One note on the packaging of Ivy as an Eclipse updatable plug-in. Due to
> > two
> > bugs in the packaging of Ivy (IVY-828,IVY-802), a repackaging is needed.
> > The
> > repackaging I have done can be reproduced with the target install-ivy. It
> > is
> > based on the official 2.0.0.beta2 release.
> >
> > If you want to reproduce the build, just do:
> > ant /release dist -DbaseLocation=$YOUR_ECLIPSE_HOME
> >
> > If you want to test the update site, just get locally the "updatesite"
> > directory from the release, and in Eclipse, setup a "local site" that
> > point to your local copy of the "updatesite" directory.
> >
> > About verifying the signatures, you will find mine there:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7BF8BE8E
> > But I am not sure how to update the KEYS file. I have found how to append
> > my
> > public key:
> > (gpg --list-sigs  && gpg --armor --export ) >> KEYS
> > But then should I just re-copy it into
> > /www/www.apache.org/dist/ant/commonon people.apache.org ? There is no
> > commit or whatever, right ?
> >
> > Last but not least, your vote:
> > +1 : you agree with the release
> > +0 : you agree but the next release should contain some fixes
> > -1 : you don't agree, there is a blocker issue with the release
>
> Good job Nicolas! I've made some tests, and I have a couple of comments:
> 1) the sources distribution is not building, bacause the
> META-INF/MANIFEST.MF file is missing in org.apache.ivyde.eclipse

good catch, I will fix it

> 2) I've tested both deploying the feature manually and with the update site
> and it works well. However, there's something strange happening: I don't
> see the Ivy entry in the project properties. Therefore I can't change the
> ivyde settings per project.

That is expected, the configuration changed with IVYDE-70. You can now 
configure by:
* a right click on the ivy container and select "configure"
* in the java build path configuration, select the ivy container in libraries, 
and click "edit"

> So I'd prefer to fix these issues before making this release public. If
> point #2 is not a blocking issue for an alpha release. #1 is more a problem
> IMO.
>
> WDYT?

I agree, I should redo the release. I also missed that in the zip containing 
the binaries, the ivy feature and the ivy jar are missing.

Nicolas

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

Re: [VOTE] Release of Apache IvyDE 2.0.0.alpha1

[Nicolas Lalevée]

Le jeudi 19 juin 2008, Scheper, Erik-Berndt a écrit :
> By the way, I noticed that the IVYDE roadmap,
> http://issues.apache.org/jira/browse/IVYDE?report=com.atlassian.jira.plugin
>.system.project:roadmap-panel , does not contain a version for this release.
>
> It would be nice if you could create it, and assign all resolved issues to
> the release. This would help greatly in testing the alpha release.

good catch. Actually I will rename the 2.0.0 version to 2.0.0.alpha1
And the issues not fixed I will move them to a new 2.0 version.

> I have tried to download the files, but cannot find your home dir.
> Can you please post the entire URL?

these are in my UNIX home directory on people.apache.org, only committers have 
access to it.

(a release to be accepted by the PMC should be more visible to the public ? as 
far as I remember the apache guidelines it should not)

Nicolas

>
> ________
>
> Van: Nicolas Lalevée [mailto:[EMAIL PROTECTED]
> Verzonden: wo 18-6-2008 18:42
> Aan: dev@ant.apache.org
> Onderwerp: [VOTE] Release of Apache IvyDE 2.0.0.alpha1
>
>
>
> Hi,
>
> I am pleased to announce that I have a version of IvyDE ready to be
> released. You will find the files in my home directory on people.apache.org
> /home/hibou/ivyde-release
>
> About the released files:
> two files are classic release files:
> * apache-ivyde-sources-2.0.0.alpha1.zip: the source distribution.
>   it includes every files which is needed to build that distribution
> * org.apache.ivyde.feature-2.0.0.alpha1.zip: the binary distribution.
>   it includes the files ready to be deployed into an Eclipse install
>
> Then there are the files deployed into the IvyDE update site. First few
> words on the update site. It will deployed at the URL:
> http://ant.apache.org/ivy/ivyde/updatesite
> Then, the files that will be effectively there, so in www.apache.org:
> * the site.xml: discribe the deployed features
> * the digest.zip: the compress manifest of every features (optimized
> eclipse update site)
> * eclipse-update--xml.cgi and eclipse-update--xml.html: the files that
> defines the apache mirrors for Eclipse.
> And the binary files packaged for the updatesite (the jar and jar.pack.gz)
> will be in the apache dist directory. More precisely the plugins and
> features directories and all of their files will be in
> dist/ant/ivy/ivyde/updatesite/
>
> One note on the packaging of Ivy as an Eclipse updatable plug-in. Due to
> two bugs in the packaging of Ivy (IVY-828,IVY-802), a repackaging is
> needed. The repackaging I have done can be reproduced with the target
> install-ivy. It is based on the official 2.0.0.beta2 release.
>
> If you want to reproduce the build, just do:
> ant /release dist -DbaseLocation=$YOUR_ECLIPSE_HOME
>
> If you want to test the update site, just get locally the "updatesite"
> directory from the release, and in Eclipse, setup a "local site" that point
> to your local copy of the "updatesite" directory.
>
> About verifying the signatures, you will find mine there:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7BF8BE8E
> But I am not sure how to update the KEYS file. I have found how to append
> my public key:
> (gpg --list-sigs  && gpg --armor --export ) >> KEYS
> But then should I just re-copy it into /www/www.apache.org/dist/ant/common
> on people.apache.org ? There is no commit or whatever, right ?
>
> Last but not least, your vote:
> +1 : you agree with the release
> +0 : you agree but the next release should contain some fixes
> -1 : you don't agree, there is a blocker issue with the release
>
> so +1 for me (non binding)
>
> Nicolas
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> Disclaimer:
>
> This message contains information that may be privileged or confidential
> and is the property of Sogeti Nederland B.V. or its Group members. It is
> intended only for the person to whom it is addressed. If you are not the
> intended recipient, you are not authorized to read, print, retain, copy,
> disseminate, distribute, or use this message or any part thereof. If you
> receive this message in error, please notify the sender immediately and
> delete all copies of this message.
>
>
>
>
> Disclaimer:
> This message contains information that may be privileged or confidential
> and is the property of Sogeti Nederland B.V. or its Group members. It is
> intended only for the person to whom it is addressed. If you are not the
> intended recipient, you are not authorized to read, print, retain, copy,
> disseminate, distribute, or use this message or any part thereof. If you
> receive this message in error, please notify the sender immediately and
> delete all copies of this message.



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

Re: [VOTE] Release of Apache IvyDE 2.0.0.alpha1

[Nicolas Lalevée]

Le jeudi 19 juin 2008, Scheper, Erik-Berndt a écrit :
> This effectively means you do not want non-committers to test this proposed
> alpha release. Personally I believe this contradicts to the Apache Release
> FAQ http://www.apache.org/dev/release.html which states:
>
> During the process of developing software and preparing a release, various
> packages are made available to the developer community for testing
> purposes. (...) Test Packages are not Apache releases. All releases require
> due process and official approval. Test packages are for testing ongoing
> development and should only be discussed on the project development lists.
>
> Then again, if you do not want developer testing, I'm fine with it.

I prefer exposing them publically actually. I just wanted to follow Apache 
guidelines. I think I have just misread them, I read "commiters community" 
instead of "developer community".
The next vote for release will be more public.

Nicolas


> 
>
> Van: Nicolas Lalevée [mailto:[EMAIL PROTECTED]
> Verzonden: do 19-6-2008 17:06
> Aan: Ant Developers List
> Onderwerp: Re: [VOTE] Release of Apache IvyDE 2.0.0.alpha1
>
> Le jeudi 19 juin 2008, Scheper, Erik-Berndt a écrit :
> > By the way, I noticed that the IVYDE roadmap,
> > http://issues.apache.org/jira/browse/IVYDE?report=com.atlassian.jira.plug
> >in .system.project:roadmap-panel , does not contain a version for this
> > release.
> >
> > It would be nice if you could create it, and assign all resolved issues
> > to the release. This would help greatly in testing the alpha release.
>
> good catch. Actually I will rename the 2.0.0 version to 2.0.0.alpha1
> And the issues not fixed I will move them to a new 2.0 version.
>
> > I have tried to download the files, but cannot find your home dir.
> > Can you please post the entire URL?
>
> these are in my UNIX home directory on people.apache.org, only committers
> have access to it.
>
> (a release to be accepted by the PMC should be more visible to the public ?
> as far as I remember the apache guidelines it should not)
>
> Nicolas
>
> > 
> >
> > Van: Nicolas Lalevée [mailto:[EMAIL PROTECTED]
> > Verzonden: wo 18-6-2008 18:42
> > Aan: dev@ant.apache.org
> > Onderwerp: [VOTE] Release of Apache IvyDE 2.0.0.alpha1
> >
> >
> >
> > Hi,
> >
> > I am pleased to announce that I have a version of IvyDE ready to be
> > released. You will find the files in my home directory on
> > people.apache.org /home/hibou/ivyde-release
> >
> > About the released files:
> > two files are classic release files:
> > * apache-ivyde-sources-2.0.0.alpha1.zip: the source distribution.
> >   it includes every files which is needed to build that distribution
> > * org.apache.ivyde.feature-2.0.0.alpha1.zip: the binary distribution.
> >   it includes the files ready to be deployed into an Eclipse install
> >
> > Then there are the files deployed into the IvyDE update site. First few
> > words on the update site. It will deployed at the URL:
> > http://ant.apache.org/ivy/ivyde/updatesite
> > Then, the files that will be effectively there, so in www.apache.org:
> > * the site.xml: discribe the deployed features
> > * the digest.zip: the compress manifest of every features (optimized
> > eclipse update site)
> > * eclipse-update--xml.cgi and eclipse-update--xml.html: the files that
> > defines the apache mirrors for Eclipse.
> > And the binary files packaged for the updatesite (the jar and
> > jar.pack.gz) will be in the apache dist directory. More precisely the
> > plugins and features directories and all of their files will be in
> > dist/ant/ivy/ivyde/updatesite/
> >
> > One note on the packaging of Ivy as an Eclipse updatable plug-in. Due to
> > two bugs in the packaging of Ivy (IVY-828,IVY-802), a repackaging is
> > needed. The repackaging I have done can be reproduced with the target
> > install-ivy. It is based on the official 2.0.0.beta2 release.
> >
> > If you want to reproduce the build, just do:
> > ant /release dist -DbaseLocation=$YOUR_ECLIPSE_HOME
> >
> > If you want to test the update site, just get locally the "updatesite"
> > directory from the release, and in Eclipse, setup a "local site" that
> > point to your local copy of the "updatesite" directory.
> >
> > About verifying the signatures, you will find mine there:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7BF8BE8E
> > But I am not sure how to update the KEYS fi

[VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

Here the second try to release IvyDE.

You can now found the new build here:
http://people.apache.org/~hibou/ivyde-2.0.0.alpha1/
You can test the updatesite in Eclipse with that URL:
http://people.apache.org/~hibou/ivyde-2.0.0.alpha1/updatesite

In this build, I have fixed two issues.
* the sources were missing a file which makes the build fail
* the binaries of Ivy where not available in the binary package  
org.apache.ivyde.feature-2.0.0.alpha1.zip. As an easy fix, I did not  
tried to include ivy binaries into the ivyde feature zip, I just make  
the build create another zip, the ivy feature zip  
org.apache.ivy.feature-2.0.0.beta2.zip. Actually I think that this  
part of the build should probably be transfered to the Ivy build, so  
that the Ivy feature is released with every Ivy release.


Your vote:
+1 : you agree with the release
+0 : you agree but the next release should contain some fixes
-1 : you don't agree, there is a blocker issue with the release

so +1 for me (non binding)

Nicolas


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

Re: [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

Le lundi 23 juin 2008, Xavier Hanin a écrit :
> On Sun, Jun 22, 2008 at 11:23 PM, Nicolas Lalevée <
>
> [EMAIL PROTECTED]> wrote:
> > Here the second try to release IvyDE.
> >
> > You can now found the new build here:
> > http://people.apache.org/~hibou/ivyde-2.0.0.alpha1/<http://people.apache.
> >org/%7Ehibou/ivyde-2.0.0.alpha1/> You can test the updatesite in Eclipse
> > with that URL:
> > http://people.apache.org/~hibou/ivyde-2.0.0.alpha1/updatesite<http://peop
> >le.apache.org/%7Ehibou/ivyde-2.0.0.alpha1/updatesite>
> >
> > In this build, I have fixed two issues.
> > * the sources were missing a file which makes the build fail
> > * the binaries of Ivy where not available in the binary package
> > org.apache.ivyde.feature-2.0.0.alpha1.zip. As an easy fix, I did not
> > tried to include ivy binaries into the ivyde feature zip, I just make the
> > build create another zip, the ivy feature zip
> > org.apache.ivy.feature-2.0.0.beta2.zip. Actually I think that this part
> > of the build should probably be transfered to the Ivy build, so that the
> > Ivy feature is released with every Ivy release.
> >
> > Your vote:
> > +1 : you agree with the release
> > +0 : you agree but the next release should contain some fixes
> > -1 : you don't agree, there is a blocker issue with the release
>
> +1
>
> I've tested the binary release, the update site, and building the sources
> with ant 1.7 + ivy 2.0.0-beta2, and everything works fine.
>
> In the sources everything seems fine too but I haven't run rat. One minor
> thing: in the CHANGES.txt, there's still a "version in svn" instead of
> "2.0.0.alpha1".

arg. I fixed it in svn.

thanks for reviewing,
Nicolas

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

Re: [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

Le 23 juin 08 à 20:37, Gilles Scokart a écrit :


I run RAT on the source distribution.  Some headers are missing for
.classpath and .project files.  Maybe features.properties should have
it also.  I don't know for change.txt and manifest.mf

The report can be found :
http://people.apache.org/~gscokart/ivyde-sources-2_0_0_alpha1.rat

I would not say that this is blocking issues, so I'm +0.



I have fixed them in svn.

thanks for reporting,


Nicolas





Gilles

2008/6/22 Nicolas Lalevée <[EMAIL PROTECTED]>:

Here the second try to release IvyDE.

You can now found the new build here:
http://people.apache.org/~hibou/ivyde-2.0.0.alpha1/
You can test the updatesite in Eclipse with that URL:
http://people.apache.org/~hibou/ivyde-2.0.0.alpha1/updatesite

In this build, I have fixed two issues.
* the sources were missing a file which makes the build fail
* the binaries of Ivy where not available in the binary package
org.apache.ivyde.feature-2.0.0.alpha1.zip. As an easy fix, I did  
not tried
to include ivy binaries into the ivyde feature zip, I just make the  
build

create another zip, the ivy feature zip
org.apache.ivy.feature-2.0.0.beta2.zip. Actually I think that this  
part of
the build should probably be transfered to the Ivy build, so that  
the Ivy

feature is released with every Ivy release.

Your vote:
+1 : you agree with the release
+0 : you agree but the next release should contain some fixes
-1 : you don't agree, there is a blocker issue with the release

so +1 for me (non binding)

Nicolas


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






--
Gilles Scokart

-
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: [VOTE] Release of Apache IvyDE 2.0.0.alpha1

[Nicolas Lalevée]

Le 27 juin 08 à 21:02, Kirby Files a écrit :



On Wed, Jun 18, 2008 at 6:42 PM, Nicolas Lalevée <[EMAIL PROTECTED]>
wrote:


Hi,

I am pleased to announce that I have a version of IvyDE ready to be
released.
You will find the files in my home directory on people.apache.org
/home/hibou/ivyde-release


I tried out this release, and it no longer seemed to automatically  
find an
ivysettings.xml file in my project (in the top-level directory). I  
had to
manually configure IvyDE with my settings file. Is this a deliberate  
change?
It was nice to be able to just check a project out of source control  
and

immediately have everything working.


I have just retested, it works fine for me.
You should check that in the path of the ivysettings in the global  
configuration is blank, and that in the local configuration of your  
project you have not selected the "Enable project specific settings"



Also, is there any plan to add a CleanCache action to the IvyDE  
context
menu? Especially since Ivy caches "negative" information (for  
instance, if

my repository web server is down, it caches the non-existence of each
artifact on that server -- once the web server is back up, the only  
way to

make it resolve is to clean the cache from the command line).


nothing planed about it, but it is a great idea that you should add in  
the Jira :)



thanks for testing,
Nicolas



--
View this message in context: 
http://www.nabble.com/-VOTE--Release-of-Apache-IvyDE-2.0.0.alpha1-tp17987032p18161817.html
Sent from the Ant - Dev mailing list archive at Nabble.com.


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

[Result] [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

After one week of vote, here are the results:
3 binding +1
2 non binding +1

The release is accepted !

So now I will push the binaries in dist.
I will regenerate entirely the ivyde website, which will include the  
updatesite with its mirror configuration.
I will tag the trunk branch (we talked about tagging xooki, but I  
don't know where...? and actually I am reconsidering it as xooki is  
not changing that much, is it really needed ?)
And finally sent an announcement (after discussing it on the mailing  
list)


Nicolas


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

Re: [Result] [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

Le mardi 1 juillet 2008, Xavier Hanin a écrit :
> On Mon, Jun 30, 2008 at 7:18 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]>
>
> wrote:
> > After one week of vote, here are the results:
> > 3 binding +1
> > 2 non binding +1
> >
> > The release is accepted !
>
> Great! Congratulations to the whole team and especially you, Nicolas!
>
> > So now I will push the binaries in dist.
> > I will regenerate entirely the ivyde website, which will include the
> > updatesite with its mirror configuration.
>
> That sounds nice.
>
> > I will tag the trunk branch (we talked about tagging xooki, but I don't
> > know where...? and actually I am reconsidering it as xooki is not
> > changing that much, is it really needed ?)
>
> We didn't tag it for Ivy releases, but it would be better to do it. But
> indeed I don't know where is the best place to tag it. Maybe we'd need to
> first reorganize the content of site sources. Sg like:
> ivy/site/ivy -> Ivy web site (currently in ivy/site)
> ivy/site/ivyde -> IvyDE web site (as today)
> ivy/site/xooki/trunk -> xooki version used in ivy sites
> ivy/site/xooki/tags/xxx -> tagged versions of xooki, which should be used
> for release branches documentation using an svn:externals
>
> But I think it can wait for the next release (either of Ivy or IvyDE).

I think so too.

So I have tagged, the binaries are publically available in dist. There is 
still my pending question about the KEYS file:
About verifying the signatures, you will find mine there:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7BF8BE8E
But I am not sure how to update the KEYS file. I have found how to append my 
public key:
(gpg --list-sigs  && gpg --armor --export ) >> KEYS
But then should I just re-copy it into /www/www.apache.org/dist/ant/common on 
people.apache.org ? There is no commit or whatever, right ?

I have regenerated the web site. For testing I have put it there:
http://ant.apache.org/ivy/ivyde.new/
There is an issue with the updatesite which I am currently fixing (at least 
the mirrors setup is working :) ). But I have an issue with the download 
page:
http://ant.apache.org/ivy/ivyde.new/download.html is not redirecting to the 
cgi. And  
http://ant.apache.org/ivy/ivyde.new/download.cgi is redirecting me to 
http://www.apache.org/dist/ .
But the updatesite mirror configuration is working like a charm... 
(http://ant.apache.org/ivy/ivyde.new/updatesite/eclipse-update--xml.cgi)

Any help will be appreciated.


Nicolas

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

Re: [Result] [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

Le mardi 1 juillet 2008, Scheper, Erik-Berndt a écrit :
> Hi,
>
> I have tested the release and it seems to work fine for me. Thanks!
> One comment however: the IVYDE Jira has not been updated (yet) to indicate
> this release.

yeah, I missed that, thanks for raising it.

Nicolas

>
> Regards,
> Erik-Berndt
>
>
> ________
>
> Van: Nicolas Lalevée [mailto:[EMAIL PROTECTED]
> Verzonden: di 1-7-2008 14:28
> Aan: Ant Developers List
> Onderwerp: Re: [Result] [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take
> 2)
>
> Le mardi 1 juillet 2008, Xavier Hanin a écrit :
> > On Mon, Jun 30, 2008 at 7:18 PM, Nicolas Lalevée
> > <[EMAIL PROTECTED]>
> >
> > wrote:
> > > After one week of vote, here are the results:
> > > 3 binding +1
> > > 2 non binding +1
> > >
> > > The release is accepted !
> >
> > Great! Congratulations to the whole team and especially you, Nicolas!
> >
> > > So now I will push the binaries in dist.
> > > I will regenerate entirely the ivyde website, which will include the
> > > updatesite with its mirror configuration.
> >
> > That sounds nice.
> >
> > > I will tag the trunk branch (we talked about tagging xooki, but I don't
> > > know where...? and actually I am reconsidering it as xooki is not
> > > changing that much, is it really needed ?)
> >
> > We didn't tag it for Ivy releases, but it would be better to do it. But
> > indeed I don't know where is the best place to tag it. Maybe we'd need to
> > first reorganize the content of site sources. Sg like:
> > ivy/site/ivy -> Ivy web site (currently in ivy/site)
> > ivy/site/ivyde -> IvyDE web site (as today)
> > ivy/site/xooki/trunk -> xooki version used in ivy sites
> > ivy/site/xooki/tags/xxx -> tagged versions of xooki, which should be used
> > for release branches documentation using an svn:externals
> >
> > But I think it can wait for the next release (either of Ivy or IvyDE).
>
> I think so too.
>
> So I have tagged, the binaries are publically available in dist. There is
> still my pending question about the KEYS file:
> About verifying the signatures, you will find mine there:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7BF8BE8E
> But I am not sure how to update the KEYS file. I have found how to append
> my public key:
> (gpg --list-sigs  && gpg --armor --export ) >> KEYS
> But then should I just re-copy it into /www/www.apache.org/dist/ant/common
> on people.apache.org ? There is no commit or whatever, right ?
>
> I have regenerated the web site. For testing I have put it there:
> http://ant.apache.org/ivy/ivyde.new/
> There is an issue with the updatesite which I am currently fixing (at least
> the mirrors setup is working :) ). But I have an issue with the download
> page:
> http://ant.apache.org/ivy/ivyde.new/download.html is not redirecting to the
> cgi. And
> http://ant.apache.org/ivy/ivyde.new/download.cgi is redirecting me to
> http://www.apache.org/dist/ .
> But the updatesite mirror configuration is working like a charm...
> (http://ant.apache.org/ivy/ivyde.new/updatesite/eclipse-update--xml.cgi)
>
> Any help will be appreciated.
>
>
> Nicolas
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> Disclaimer:
> This message contains information that may be privileged or confidential
> and is the property of Sogeti Nederland B.V. or its Group members. It is
> intended only for the person to whom it is addressed. If you are not the
> intended recipient, you are not authorized to read, print, retain, copy,
> disseminate, distribute, or use this message or any part thereof. If you
> receive this message in error, please notify the sender immediately and
> delete all copies of this message.



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

Re: Ivy 2.0 roadmap

[Nicolas Lalevée]

Le 25 juin 08 à 13:24, Xavier Hanin a écrit :


Hi,

Following the discussion we had already in April or May, I've  
reviewed all
issues targeted at 2.0, postponed some of them, and target others to  
2.0-RC1
so that we can more clearly see what we need to do before releasing  
2.0-RC1.

ATM there are 29 open issues targeted at RC1, feel free to discuss my
choices here.


I have done a little review, I didn't spotted anything weird.

I just saw that strangely tagged issue: IVY-552. I think we should tag  
it fixed by IVY-399





I'll try to spend time this afternoon to get some of those 29 issues  
fixed.
I still think we really need to get a 2.0 final as soon as possible,  
some of
the remaining issues are easy to fix, some may take a little longer,  
but

with a good community effort we should be able to be done within a
reasonable timeframe and enjoy a successful 2.0 version!


+1 !

Nicolas


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

Re: Ivy confluence Wiki

[Nicolas Lalevée]

Le 30 juin 08 à 12:16, Xavier Hanin a écrit :


Hi All,

Ivy confluence wiki is finally up, and ready to welcome users  
contributions

(you just need to be registered to add and edit pages). Changes
notifications are sent to our notification ml. If some of you can  
test it
works properly, I'll then announce the change of Wiki on the ivy- 
user list

and change the link on our web site.


I have tested it (I will take time to complete the page I created),  
and it works like a charm.


Nicolas


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

Re: [Result] [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

Le mercredi 2 juillet 2008, Xavier Hanin a écrit :
> On Wed, Jul 2, 2008 at 12:07 PM, Xavier Hanin <[EMAIL PROTECTED]>
>
> wrote:
> > While wanting to update Ivy site to reflect the change for wiki link, I
> > forgot it updates ivyde site too... Hence I've updated IvyDE site with
> > the changes you were testing in ivyde.new. I think we can keep it like
> > that, hopefully we'll soon find the trick to get download.cgi fixed.

ok, it is by the way nearly ready to be deployed.

but then could you grant the ant group some write permission please ?
I have still some fixes to do on the updatesite

> The site has been updated, download.html redirects to download.cgi, but we
> still get redirected to http://www.apache.org/dist/
>
> Looking back at the problems I had when I set up download.cgi for Ivy, I've
> removed the square brackets used in download.html content, because it's a
> source of problem for the python mirror script. But last time I faced this
> problem of square brackets I got HTTP 500 errors, not a redirection to
> http://www.apache.org/dist/. So I don't know if it will be fixed with that
> or know, we have to wait for the site to be synced from minotaur to public.

ok, thanks for the fix and having a look to it.

Nicolas

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

Re: [Result] [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

Le mercredi 2 juillet 2008, Xavier Hanin a écrit :
> On Tue, Jul 1, 2008 at 2:28 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]>
>
> wrote:
> > Le mardi 1 juillet 2008, Xavier Hanin a écrit :
> > > On Mon, Jun 30, 2008 at 7:18 PM, Nicolas Lalevée
> > > <[EMAIL PROTECTED]>
> > >
> > > wrote:
> > > > After one week of vote, here are the results:
> > > > 3 binding +1
> > > > 2 non binding +1
> > > >
> > > > The release is accepted !
> > >
> > > Great! Congratulations to the whole team and especially you, Nicolas!
> > >
> > > > So now I will push the binaries in dist.
> > > > I will regenerate entirely the ivyde website, which will include the
> > > > updatesite with its mirror configuration.
> > >
> > > That sounds nice.
> > >
> > > > I will tag the trunk branch (we talked about tagging xooki, but I
> > > > don't know where...? and actually I am reconsidering it as xooki is
> > > > not changing that much, is it really needed ?)
> > >
> > > We didn't tag it for Ivy releases, but it would be better to do it. But
> > > indeed I don't know where is the best place to tag it. Maybe we'd need
> > > to first reorganize the content of site sources. Sg like:
> > > ivy/site/ivy -> Ivy web site (currently in ivy/site)
> > > ivy/site/ivyde -> IvyDE web site (as today)
> > > ivy/site/xooki/trunk -> xooki version used in ivy sites
> > > ivy/site/xooki/tags/xxx -> tagged versions of xooki, which should be
> > > used for release branches documentation using an svn:externals
> > >
> > > But I think it can wait for the next release (either of Ivy or IvyDE).
> >
> > I think so too.
> >
> > So I have tagged, the binaries are publically available in dist. There is
> > still my pending question about the KEYS file:
> > About verifying the signatures, you will find mine there:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7BF8BE8E
> > But I am not sure how to update the KEYS file. I have found how to append
> > my
> > public key:
> > (gpg --list-sigs  && gpg --armor --export ) >> KEYS
> > But then should I just re-copy it into
> > /www/www.apache.org/dist/ant/commonon people.apache.org ? There is no
> > commit or whatever, right ?
> >
> > I have regenerated the web site. For testing I have put it there:
> > http://ant.apache.org/ivy/ivyde.new/
> > There is an issue with the updatesite which I am currently fixing (at
> > least the mirrors setup is working :) ). But I have an issue with the
> > download page:
> > http://ant.apache.org/ivy/ivyde.new/download.html is not redirecting to
> > the
> > cgi.
>
> This is because you need to include download-redirect.js script. I've fixed
> it in svn.
>
> > And
> > http://ant.apache.org/ivy/ivyde.new/download.cgi is redirecting me to
> > http://www.apache.org/dist/ .
>
> This is strange, I've checked the download.cgi on people.a.o and it seems
> fine. I've however made some changes in svn: set svn:eol-style and
> svn:executable properties, and removed the end of line at the end of the
> file to make it the exact copy of the download.cgi  we have in Ivy site. I
> suggest you update ivyde.new with the current target/ivyde site in svn and
> see if it works better.
>
> BTW, since svn:eol-style is missing on files you added in svn, I'm
> wondering if you have configured your svn client as suggested here:
> http://www.apache.org/dev/version-control.html
>
> If you haven't already, I think it would be nice to do.

Actually I did, but not on the machine I used to deploy the web site :p
I will fix that.

Nicolas

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

Re: IvyDE website

[Nicolas Lalevée]

Le mercredi 2 juillet 2008, Scheper, Erik-Berndt a écrit :
> Oh, and one more thing: there is no link from the IVY site to the IVYDE
> site (at least: I can't find it). So you have to know IVYDE exists,
> otherwise you can't find it.

Actually there is one:
http://ant.apache.org/ivy/links.html
But I agree with you, it should be more visible, maybe an entry in the toc ?

> Two minor comments on the newly published IvyDE website (regardless of
> download locations):
>
> 1. The editor page
> (http://ant.apache.org/ivy/ivyde/history/latest-milestone/editor.html) has
> a topic on Html rendering:
> Ivy editor is a multi tabs editor. Located on the bottom of the editor you
> will found a tab named preview that allows to view the ivy file as an html
> file. (...)
> I can't find this tab. Am I missing something?

This tab has been disabled. I don't know really why as it as been done before 
in integration of Ivy into Apache.

> 2. However, I do find the Ivy Report view (under show views in eclipse).
> This is not (yet) documented on the IvyDE site, though it's very nice.

I have opened an issue to update that page:
https://issues.apache.org/jira/browse/IVYDE-100

thanks for reporting,

Nicolas

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

Re: [CONF] Apache Ivy (Apache Ant subproject) : Index (page edited)

[Nicolas Lalevée]

Le mercredi 2 juillet 2008, [EMAIL PROTECTED] a écrit :
>  Page Edited : IVY : Index
> Index has been edited by Michael Kebe (Jul 02, 2008).
> (View changes)

http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=87798&originalVersion=5&revisedVersion=6

Does anybody knows what is the purpose of this change ?

Nicolas

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

Re: [Result] [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

Le mercredi 2 juillet 2008, Xavier Hanin a écrit :
> On Tue, Jul 1, 2008 at 2:28 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]>
>
> wrote:
> > So I have tagged, the binaries are publically available in dist. There is
> > still my pending question about the KEYS file:
> > About verifying the signatures, you will find mine there:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7BF8BE8E
> > But I am not sure how to update the KEYS file. I have found how to append
> > my
> > public key:
> > (gpg --list-sigs  && gpg --armor --export ) >> KEYS
> > But then should I just re-copy it into
> > /www/www.apache.org/dist/ant/commonon people.apache.org ? There is no
> > commit or whatever, right ?
>
> Sorry for the late reply, I didn't recall myself what we do for keys, but
> I've found back Stefan's tip when I released Ivy. The KEYS file to update
> is in svn, here:
> https://svn.apache.org/repos/asf/ant/core/trunk/KEYS
>
> Update this file, commit, and if I understand correctly the online
> version<http://www.apache.org/dist/ant/KEYS>will be updated
> automatically.

I have updated https://svn.apache.org/repos/asf/ant/core/trunk/KEYS
But it didn't get updated.
Then I wanted to update it manually and I have found that this file 
http://www.apache.org/dist/ant/KEYS is actually corresponding to this file in 
svn:
https://svn.apache.org/repos/asf/ant/antlibs/common/trunk/KEYS

should I update this one too ?

Nicolas

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

[DISCUSS] IvyDE 2.0.0.apha1 announcement

[Nicolas Lalevée]

Hi, here is the proposal for the announcement:

July 2008 - The Apache IvyDE project is please to announce its 2.0.0 alpha1 
release, the first Apache release for IvyDE.

IvyDE is an Eclipse plugin that help you manage your classpath with Apache 
Ivy. So you will handle directly your jar dependencies into Eclipse, with an 
dedicated editor of ivy.xml files, with completion.

The status of this version is alpha, meaning that developers know there are 
some bugs. But we wanted, with some users, this first Apache release to get 
out in order to have a first released version compatible with a 2.0 version 
of Ivy. We also hope that it will bring more users, so more testing, bug 
report and feedback, and also some contributions.

Download the 2.0.0.alpha1 release files at: 
http://ant.apache.org/ivy/ivyde/download.cgi

Or use the IvyDE updatesite http://ant.apache.org/ivy/ivyde/updatesite

Issues and contributions should be reported to: 
https://issues.apache.org/jira/browse/IVYDE

More information can be found on the IvyDE website: 
http://ant.apache.org/ivy/ivyde

Nicolas (2.0.0.alpha1 release manager)

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

Re: [DISCUSS] IvyDE 2.0.0.apha1 announcement

[Nicolas Lalevée]

Le jeudi 3 juillet 2008, Xavier Hanin a écrit :
> The announcement is fine for me. Just one minor thing I would add: when you
> say "to have a first released version compatible with a 2.0 version of Ivy.
> " I would add: "(IvyDE 2.0.0.alpha1 is currently shipped with Ivy
> 2.0.0.beta2)." to make it clear that Ivy 2.0 final is not released yet.

good point. I will add this.

Nicolas

>
> Xavier
>
> On Thu, Jul 3, 2008 at 10:39 AM, Nicolas Lalevée
> <[EMAIL PROTECTED]>
>
> wrote:
> > Hi, here is the proposal for the announcement:
> >
> > July 2008 - The Apache IvyDE project is please to announce its 2.0.0
> > alpha1 release, the first Apache release for IvyDE.
> >
> > IvyDE is an Eclipse plugin that help you manage your classpath with
> > Apache Ivy. So you will handle directly your jar dependencies into
> > Eclipse, with an
> > dedicated editor of ivy.xml files, with completion.
> >
> > The status of this version is alpha, meaning that developers know there
> > are some bugs. But we wanted, with some users, this first Apache release
> > to get out in order to have a first released version compatible with a
> > 2.0 version of Ivy. We also hope that it will bring more users, so more
> > testing, bug report and feedback, and also some contributions.
> >
> > Download the 2.0.0.alpha1 release files at:
> > http://ant.apache.org/ivy/ivyde/download.cgi
> >
> > Or use the IvyDE updatesite http://ant.apache.org/ivy/ivyde/updatesite
> >
> > Issues and contributions should be reported to:
> > https://issues.apache.org/jira/browse/IVYDE
> >
> > More information can be found on the IvyDE website:
> > http://ant.apache.org/ivy/ivyde
> >
> > Nicolas (2.0.0.alpha1 release manager)
> >
> > -
> > 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: [Result] [VOTE] Release of Apache IvyDE 2.0.0.alpha1 (take 2)

[Nicolas Lalevée]

Le 3 juil. 08 à 20:57, Xavier Hanin a écrit :

On Thu, Jul 3, 2008 at 10:35 AM, Nicolas Lalevée <[EMAIL PROTECTED] 
>

wrote:


Le mercredi 2 juillet 2008, Xavier Hanin a écrit :

On Tue, Jul 1, 2008 at 2:28 PM, Nicolas Lalevée
<[EMAIL PROTECTED]>

wrote:
So I have tagged, the binaries are publically available in dist.  
There

is

still my pending question about the KEYS file:
About verifying the signatures, you will find mine there:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7BF8BE8E
But I am not sure how to update the KEYS file. I have found how to

append

my
public key:
(gpg --list-sigs  && gpg --armor --export )  
>>

KEYS

But then should I just re-copy it into
/www/www.apache.org/dist/ant/commonon people.apache.org ? There  
is no

commit or whatever, right ?


Sorry for the late reply, I didn't recall myself what we do for  
keys, but
I've found back Stefan's tip when I released Ivy. The KEYS file to  
update

is in svn, here:
https://svn.apache.org/repos/asf/ant/core/trunk/KEYS

Update this file, commit, and if I understand correctly the online
version<http://www.apache.org/dist/ant/KEYS>will be updated
automatically.


I have updated https://svn.apache.org/repos/asf/ant/core/trunk/KEYS
But it didn't get updated.
Then I wanted to update it manually and I have found that this file
http://www.apache.org/dist/ant/KEYS is actually corresponding to  
this file

in
svn:
https://svn.apache.org/repos/asf/ant/antlibs/common/trunk/KEYS

should I update this one too ?


I see that my key is in both, so I guess updating it too is better.  
I was

probably wrong with the first location I give, sorry about that.


I updated it, it didn't seemed to be updated automatically, so I  
updated it myself.

It is now publicly available, let's announce the release !

cheers,
Nicolas


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

[ANNOUNCE] Apache IvyDE 2.0.0.alpha1 available

[Nicolas Lalevée]

July 5th 2008 - The Apache IvyDE project is please to announce its  
2.0.0 alpha1 release, the first Apache release for IvyDE.


IvyDE is an Eclipse plugin that help you manage your classpath with  
Apache Ivy. So you will handle directly your jar dependencies into  
Eclipse, with an dedicated editor of ivy.xml files, with completion.


The status of this version is alpha, meaning that developers know  
there are some bugs. But we wanted, with some users, this first Apache  
release to get out in order to have a first released version  
compatible with a 2.0 version of Ivy (IvyDE 2.0.0.alpha1 is currently  
shipped with Ivy 2.0.0.beta2). We also hope that this first release  
will bring more users, so more testing, bug report and feedback, and  
also some contributions.


Download the 2.0.0.alpha1 release files at:
http://ant.apache.org/ivy/ivyde/download.cgi

Or use the IvyDE updatesite http://ant.apache.org/ivy/ivyde/updatesite

Issues and contributions should be reported to:
https://issues.apache.org/jira/browse/IVYDE

More information can be found on the IvyDE website:
http://ant.apache.org/ivy/ivyde

Nicolas (2.0.0.alpha1 release manager)


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

Re: Extracting common ide features from IvyDE

[Nicolas Lalevée]

Le vendredi 11 juillet 2008, Xavier Hanin a écrit :
> Hi,
>
> As you may already know I'm currently working on Ivybeans [1], a kind of
> IvyDE for Netbeans for which we have won a grant from Sun [2].
>
> In this plugin I need to implement features very similar to what has been
> done in IvyDE, like code completion for Ivy files. I also need to implement
> some features which are not currently supported by IvyDE like settings
> files code completion, or a way to easily add dependencies to an existing
> Ivy file.
>
> These features are somewhat IDE agnostic (or at least can be based on
> common roots), and I think it would benefit both community and all users if
> we shared what can be shared. So I consider refactoring some code in IvyDE
> (especially code used for code completion) to make it reusable (actually
> I've already done the refactoring...).

Can I have a look to that new package ?
In fact I was asking myself if a such refactoring could be integrated into 
Ivy.

> I'd move this code to a 
> org.apache.ivyde.common package, which could be used by any IDE plugin
> developer. The next step would be to move this package in a separate
> module, so that other plugin developers can use it without embedding the
> whole eclipse plugin. Then I could add new features to this common package,
> which would ease the reuse of work I do for Netbeans plugin in eclipse
> plugin.
>
> So, do you think it makes sense to do that? Any objection?

No objection on the idea of sharing common code. The question is then how.

Nicolas

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

Re: Extracting common ide features from IvyDE

[Nicolas Lalevée]

Le lundi 14 juillet 2008, Xavier Hanin a écrit :
> On Fri, Jul 11, 2008 at 1:55 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]>
>
> wrote:
> > Le vendredi 11 juillet 2008, Xavier Hanin a écrit :
> > > Hi,
> > >
> > > As you may already know I'm currently working on Ivybeans [1], a kind
> > > of IvyDE for Netbeans for which we have won a grant from Sun [2].
> > >
> > > In this plugin I need to implement features very similar to what has
> > > been done in IvyDE, like code completion for Ivy files. I also need to
> >
> > implement
> >
> > > some features which are not currently supported by IvyDE like settings
> > > files code completion, or a way to easily add dependencies to an
> > > existing Ivy file.
> > >
> > > These features are somewhat IDE agnostic (or at least can be based on
> > > common roots), and I think it would benefit both community and all
> > > users
> >
> > if
> >
> > > we shared what can be shared. So I consider refactoring some code in
> >
> > IvyDE
> >
> > > (especially code used for code completion) to make it reusable
> > > (actually I've already done the refactoring...).
> >
> > Can I have a look to that new package ?
> > In fact I was asking myself if a such refactoring could be integrated
> > into Ivy.
>
> Sure, for the moment I've commited the code to IvyBeans:
> http://code.google.com/p/ivybeans/source/browse/trunk/ivybeans/ivy-libs/src
>/org/apache/ivyde/common/
>
> Obviously the eclipse specific bits are missing from there, but you should
> get the idea pretty easily.

got it.
So yes there are code that would be great to share.

Then I am wondering: should it have its own release cycle, or included in 
Ivy of IvyDE's ones ?
Having it own release cycle, it brings more release work, and more 
dependency handling (on IvyDE part).
Having it included in IvyDE seems to be overkill compared to the need of 
Ivybeans.
Then there is the inclusion in Ivy: would it make sense to have some code 
completion algorithm on Ivy ? I don't think it would hurt.

So I am in favor in integrating that common.ide in Ivy. Then I would prefer 
keeping it in IvyDE. And last have a new project with its own release cycle.

Just my feelings, I won't put any veto there.

Nicolas

>
> Xavier
>
> > > I'd move this code to a
> > > org.apache.ivyde.common package, which could be used by any IDE plugin
> > > developer. The next step would be to move this package in a separate
> > > module, so that other plugin developers can use it without embedding
> > > the whole eclipse plugin. Then I could add new features to this common
> >
> > package,
> >
> > > which would ease the reuse of work I do for Netbeans plugin in eclipse
> > > plugin.
> > >
> > > So, do you think it makes sense to do that? Any objection?
> >
> > No objection on the idea of sharing common code. The question is then
> > how.
> >
> > Nicolas
> >
> > -
> > 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: Extracting common ide features from IvyDE

[Nicolas Lalevée]

Le 23 juil. 08 à 19:58, Xavier Hanin a écrit :

On Wed, Jul 23, 2008 at 5:52 PM, Nicolas Lalevée <[EMAIL PROTECTED] 
>

wrote:


Le lundi 14 juillet 2008, Xavier Hanin a écrit :

On Fri, Jul 11, 2008 at 1:55 PM, Nicolas Lalevée
<[EMAIL PROTECTED]>

wrote:

Le vendredi 11 juillet 2008, Xavier Hanin a écrit :

Hi,

As you may already know I'm currently working on Ivybeans [1], a  
kind

of IvyDE for Netbeans for which we have won a grant from Sun [2].

In this plugin I need to implement features very similar to what  
has
been done in IvyDE, like code completion for Ivy files. I also  
need

to


implement


some features which are not currently supported by IvyDE like

settings

files code completion, or a way to easily add dependencies to an
existing Ivy file.

These features are somewhat IDE agnostic (or at least can be  
based on

common roots), and I think it would benefit both community and all
users


if

we shared what can be shared. So I consider refactoring some  
code in


IvyDE


(especially code used for code completion) to make it reusable
(actually I've already done the refactoring...).


Can I have a look to that new package ?
In fact I was asking myself if a such refactoring could be  
integrated

into Ivy.


Sure, for the moment I've commited the code to IvyBeans:


http://code.google.com/p/ivybeans/source/browse/trunk/ivybeans/ivy-libs/src

/org/apache/ivyde/common/

Obviously the eclipse specific bits are missing from there, but you

should

get the idea pretty easily.


got it.
So yes there are code that would be great to share.

Then I am wondering: should it have its own release cycle, or  
included in

Ivy of IvyDE's ones ?


That's a good question. I think it would deserve its own release  
cycle, to
avoid making any IDE plugin developed on this basis too tied to  
release

cycle of either Ivy or IvyDE.



Having it own release cycle, it brings more release work,


Indeed.



and more
dependency handling (on IvyDE part).


Yes, but I think it shouldn't be a show stopper.



Having it included in IvyDE seems to be overkill compared to the  
need of

Ivybeans.


Agreed.



Then there is the inclusion in Ivy: would it make sense to have  
some code

completion algorithm on Ivy ? I don't think it would hurt.


It wouldn't hurt too much, even though I think ivy.jar is already big
enough, and we should start trying to watch its size.


Yep the more code there is the more maintenance it needs.


The main problem IMO
is that it would then have the same release cycles, whilst the  
evolution

needs may be very different.


I don't now really what would be the new features of common.ide. But  
as you are wondering about it, it probably means that you expect some  
new features brought by IvyBeans ;).








So I am in favor in integrating that common.ide in Ivy. Then I  
would prefer

keeping it in IvyDE. And last have a new project with its own release
cycle.


I think I prefer to either put it in IvyDE, or really split it as a  
separate
project. Maybe even a project hosted somewhere else. After all ASF  
is not
against having dependencies on Apache licensed libraries which are  
not from
the ASF. The advantage I see with hosting it elsewhere is that it  
would be

much easier to have people using the library in any plugin become a
committer on the library.


I have to admit that I don't "like" having some new external  
dependencies. But I have no strong argument to show :p


So my order of preferences is kept inside IvyDE, then having it in  
another project.


And what about common.ide included in IvyDE's release cycle, and  
having an independent build ?
It would be an new project org.apache.ivy.common.ide under the trunk  
directory of IvyDE. Used by IvyDE it would be just another plugin it  
depends on. But it would have a standalone build.xml that you can  
build yourself the jar, and then import that jar into IvyBeans, just  
like Solr does with Lucene (http://svn.apache.org/repos/asf/lucene/solr/tags/release-1.2.0/lib/ 
). And that component would have it own Change.txt, as it could have  
somehow independent features.


NIcolas







Just my feelings, I won't put any veto there.

Nicolas



Xavier


I'd move this code to a
org.apache.ivyde.common package, which could be used by any IDE

plugin
developer. The next step would be to move this package in a  
separate
module, so that other plugin developers can use it without  
embedding

the whole eclipse plugin. Then I could add new features to this

common


package,


which would ease the reuse of work I do for Netbeans plugin in

eclipse

plugin.

So, do you think it makes sense to do that? Any objection?


No objection on the idea of sharing common code. The question is  
then

how.

Nicolas

-
To u

Re: svn commit: r679119 - in /ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse: ./ src/java/org/apache/ivyde/eclipse/cpcontainer/ src/java/org/apache/ivyde/eclipse/ui/preferences/

[Nicolas Lalevée]

Le jeudi 24 juillet 2008, Xavier Hanin a écrit :
> On Wed, Jul 23, 2008 at 6:03 PM, <[EMAIL PROTECTED]> wrote:
> > Author: hibou
> > Date: Wed Jul 23 09:03:45 2008
> > New Revision: 679119
> >
> > URL: http://svn.apache.org/viewvc?rev=679119&view=rev
> > Log:
> > IVYDE-105 : Retrieve after resolve feature does not clean target
> > directory first
> >  - added a button in the UI to "synchronize" the retrieve
>
> [...]
>
> > ---
> > ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/ec
> >lipse/ui/preferences/IvyPreferencePage.java (original)
> > +++
> > ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/ec
> >lipse/ui/preferences/IvyPreferencePage.java Wed Jul 23 09:03:45 2008
> > @@ -56,6 +56,8 @@
> >
> > private StringFieldEditor _pattern;
> >
> > +private BooleanFieldEditor _retreiveSync;
>
> There's a typo here, it should be _retrieveSync

arg, this is the second time I did that spell mistake.

>
> > +
> > public IvyPreferencePage() {
> > super(GRID);
> > setPreferenceStore(IvyPlugin.getDefault().getPreferenceStore());
> > @@ -123,6 +125,7 @@
> > b.addSelectionListener(new SelectionAdapter() {
> > public void widgetSelected(SelectionEvent e) {
> > _pattern.setEnabled(b.getSelection(), parent);
> > +_retreiveSync.setEnabled(b.getSelection(),
> > parent);
> > }
> > });
> > }
> > @@ -131,8 +134,11 @@
> > fieldParent);
> >
> > _pattern.setEnabled(getPreferenceStore().getBoolean(PreferenceConstants.D
> >O_RETRIEVE), fieldParent);
> > +_retreiveSync = new
> > BooleanFieldEditor(PreferenceConstants.RETRIEVE_SYNC,
> > +"Delete old retrieved artifacts", fieldParent);
> > addField(doR);
> > addField(_pattern);
> > +addField(_retreiveSync);
> >
> > new Label(fieldParent, SWT.NONE); // space
> > explanation = new Label(fieldParent, SWT.NONE);
> >
> > Modified:
> > ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/ec
> >lipse/ui/preferences/PreferenceConstants.java URL:
> > http://svn.apache.org/viewvc/ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse
> >/src/java/org/apache/ivyde/eclipse/ui/preferences/PreferenceConstants.java
> >?rev=679119&r1=679118&r2=679119&view=diff
> >
> > =
> >= ---
> > ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/ec
> >lipse/ui/preferences/PreferenceConstants.java (original)
> > +++
> > ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/ec
> >lipse/ui/preferences/PreferenceConstants.java Wed Jul 23 09:03:45 2008
> > @@ -48,6 +48,8 @@
> >
> > public static final String RETRIEVE_PATTERN = "retreive.pattern";
> >
> > +public static final String RETRIEVE_SYNC = "retreive.sync";
> > +
>
> Same typo as above for the constant value. But I also realize we have the
> same typo for the retrieve pattern value. I'd prefer fixing it, but it
> would be a backward incompatible change with alpha1. But alpha1 is only an
> alpha, so I'd still prefer fixing it, unless you have another opinion.

Actually I think we can fix and keep it backward compatible: write the 
property with the fixed spell, but read both form.
I will fix it.

cheers,
Nicolas

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

Re: Extracting common ide features from IvyDE

[Nicolas Lalevée]

Le jeudi 24 juillet 2008, Xavier Hanin a écrit :
> On Thu, Jul 24, 2008 at 8:13 AM, Nicolas Lalevée
> <[EMAIL PROTECTED]>
>
> wrote:
> > [...]
> >
> >
> >  The main problem IMO
> >
> >> is that it would then have the same release cycles, whilst the evolution
> >> needs may be very different.
> >
> > I don't now really what would be the new features of common.ide. But as
> > you are wondering about it, it probably means that you expect some new
> > features brought by IvyBeans ;).
>
> For IvyBeans it's not the problem since I'm a committer on IvyDE too, I can
> do pretty much what I want (and yes I have some new feature, well, at least
> one, settings code completion). But if in the future people want to use
> IvyDE commons in another plugin (let's say IDEA) and want to improve
> something they will need to go through the "provide patch" line. Not that
> much a problem but I think in the case of a small library reused by several
> plugins it can slow down development.
>
> >>> So I am in favor in integrating that common.ide in Ivy. Then I would
> >>> prefer
> >>> keeping it in IvyDE. And last have a new project with its own release
> >>> cycle.
> >>
> >> I think I prefer to either put it in IvyDE, or really split it as a
> >> separate
> >> project. Maybe even a project hosted somewhere else. After all ASF is
> >> not against having dependencies on Apache licensed libraries which are
> >> not from
> >> the ASF. The advantage I see with hosting it elsewhere is that it would
> >> be much easier to have people using the library in any plugin become a
> >> committer on the library.
> >
> > I have to admit that I don't "like" having some new external
> > dependencies. But I have no strong argument to show :p
> >
> > So my order of preferences is kept inside IvyDE, then having it in
> > another project.
> >
> > And what about common.ide included in IvyDE's release cycle, and having
> > an independent build ?
> > It would be an new project org.apache.ivy.common.ide under the trunk
> > directory of IvyDE. Used by IvyDE it would be just another plugin it
> > depends on. But it would have a standalone build.xml that you can build
> > yourself the jar, and then import that jar into IvyBeans, just like Solr
> > does with Lucene
> > (http://svn.apache.org/repos/asf/lucene/solr/tags/release-1.2.0/lib/).
> > And that component would have it own Change.txt, as it could have somehow
> > independent features.
>
> That sounds like the easiest thing to setup for now, so I'm ok to go this
> way, then later we may decide to move the project out if we see that
> there's a real need from the community.

sounds good

>
> So I'll proceed with thesee changes in the coming days, unless you (or
> someone else) object before.

please do.

cheers,
Nicolas


>
> Xavier
>
> > NIcolas
> >
> >>> Just my feelings, I won't put any veto there.
> >>>
> >>> Nicolas
> >>>
> >>>> Xavier
> >>>>
> >>>>  I'd move this code to a
> >>>>
> >>>>>> org.apache.ivyde.common package, which could be used by any IDE
> >>>>>
> >>>>> plugin
> >>>>
> >>>> developer. The next step would be to move this package in a separate
> >>>>
> >>>>>> module, so that other plugin developers can use it without embedding
> >>>>>> the whole eclipse plugin. Then I could add new features to this
> >>>>>
> >>>>> common
> >>>>>
> >>>>>
> >>>>> package,
> >>>>>
> >>>>>  which would ease the reuse of work I do for Netbeans plugin in
> >>>>>
> >>>>> eclipse
> >>>>
> >>>> plugin.
> >>>>
> >>>>>> So, do you think it makes sense to do that? Any objection?
> >>>>>
> >>>>> No objection on the idea of sharing common code. The question is then
> >>>>> how.
> >>>>>
> >>>>> Nicolas
> >>>>>
> >>>>> -
> >>>>> 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]
> >>
> >> --
> >> Xavier Hanin - Independent Java Consultant
> >> http://xhab.blogspot.com/
> >> http://ant.apache.org/ivy/
> >> http://www.xoocode.org/
> >
> > -
> > 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: Ivy, IvyDE and thread safety?

[Nicolas Lalevée]

Le jeudi 24 juillet 2008, Gilles Scokart a écrit :
> Up to now, I think Ivy has mostly be used in a single thread.  When
> used from ant, even if it is possible to have multiple tasks running
> in parallel, I doubdt it has ever been extensively used.
>
> There is thus a risk that some part of the code are not thread safe.
>
> I'm wondering what is actually the risk when Ivy is used from IvyDE?
> Does IvyDE will likely invoke Ivy from multiple thread in parallel?

The IvyResolveJob of IvyDE is synchronized to be run only one at a time, 
ensured by Eclipse. So when computing the classpath of the java projects, 
there won't be any thread issue.
But Ivy is also used for ivy file completion and ivy file parsing. I don't 
know how far the code in Eclipse can use them with multiple thread. But 
whatever, the synchronization point here will be the end user that won't be 
able to edit files threadedly. :p
So I don't think Ivy is used in a threaded way in IvyDE.

Nicolas

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

Re: Ivy 2.0 RC1 planning

[Nicolas Lalevée]

Le 26 août 08 à 15:56, Xavier Hanin a écrit :


Hi,

I've been working on the remaining issues targetted to 2.0-RC1, and  
only a

few are remaining.

We have:
IVY-835   ant task downloads wrong jars from maven  
repositories
IVY-675  Wrong graph of nodes is logged when circular dependency is  
detected

IVY-349  Endless recursion in Report
 => those are about to be closed as cannot reproduce if no new  
activity

happens soon

IVY-652  Ivy constructs incorrect URL if artifact path contains spaces
 => This one Maarten you seem to have already made good progress, any
insight on the remaining time?

IVY-387  Absolute and relative path
IVY-232  Incorrect directory path resolve when running from a  
different

directory
 => These two are rather old, assigned to you Gilles. Any progress on
these? Do you need help?

IVY-872  Improve performance
 => This one is new and assigned to you Gilles. I don't think this  
should
be a show stopper for 2.0, and can be postponed to 2.0.1 if it takes  
too

long to implement

So I think we're pretty close to be able to enter in 2.0 release  
candidates
cycles, to finally get 2.0 out! Do you see any other outstanding  
issue which
should get in 2.0? Would you agree with a plan trying to get 2.0 RC1  
out
before mid september? Then how do you see the release candidates  
cycles
going on? I'd be in favour of trying to keep the cycles short (sg  
like every
2 weeks), and if no outstanding bug is reported in a cycle, then we  
release
2.0 final with the same source code as the last RC. What do you  
think of

this plan?


fine for me !

I have just a little issue that I would like to be addressed before  
the release. It is about the OSGi version number of the rc and final  
version. Version numbers in the OSGi environment needs to be ordered  
alphabetically. Currently the OSGi version of the Ivy bundle is  
2.0.0.rc1_$TIMESTAMP. So for the final version, we will have issues to  
find a name "upper" than that one. I think we should better take  
2.0.0.candidate1_$TIMESTAMP (it is still upper than "beta") and then  
for the final : 2.0.0.final_$TIMESTAMP.


Another point, this one non blocker for the release, but it will be  
cool if you can also release Ivy into the IvyDE update site  
simultaneously.
Ivy has been re-packaged for the update site with the last release of  
IvyDE. It would be cool to have it updated to the update without  
involving a release of IvyDE. So I think that the best way to process  
is to move the update site build process from the IvyDE build system  
to the site build system. So the process would be:

- build the release of Ivy
- copy the new jar to /svn/ant/ivy/site/ivyde/updatesite/plugins/ (the  
entire updatesite will be in svn, jars and .md5)
- update manually the site.xml in site/ivyde/updatesite/ so it  
references the new version
- ant generate-ivy-feature optimize-updatesite checksum-updatesite  
sign-updatesite

- commit the regenerated stuff
After the release is voted:
- there would be a classic site deployment, as the site include the  
main updatesite
- the updatesite mirrors can be updated in updating /www/www.apache.org/dist/ant/ivyde/updatesite 
 on people.apache.org


If no one object I will take care of setting up this, put proper  
detailed doc about the process in the wiki.
Note that this process is not blocker against an Ivy release, we could  
have some delay between releasing Ivy and having it published into the  
updatesite. But I have no doubt that some users will quickly ask to  
have it updated on the Eclipse side :)


Nicolas


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

Re: change default value for alwaysCheckExactRevision

[Nicolas Lalevée]

Le 28 août 08 à 10:33, Xavier Hanin a écrit :

On Thu, Aug 28, 2008 at 10:04 AM, Gilles Scokart  
<[EMAIL PROTECTED]> wrote:



Now that the default is true, it means that if someone specify a
version latest.integration, ivy will first look if the ivy file can  
be

found using the 'latest.integration' token.
If it is false, ivy will directly list the revisions, and according  
to

the latest strategy find the latest one.

The performance impact on file system resolver is minor (just one
file.exist per latest.integration dependency).  But might be bigger
with http (or other) remote repository.

The effect of changing the default value will be that the people that
use repositories containing an explicit text 'latest.integration' in
their pattern will have to adpat their settings.

I'm not sure how many people use this kind of repository.  And I'm  
not
even sure if ivy has support to publish to this kind of repository.  
We

should maybe poll the ivy user community (I'm not sure it would give
any result, but we can try).


I don't know if polling the community is worth it. I'm not talking  
about
discarding this feature, but only changing the default. I may be  
wrong, but
I suspect that less than 1% of Ivy users actually use this feature  
(it may
even be 0). Even if it's 10%, I still think the default should be  
false. But
if you really think we should poll the community first, I'm ok, I  
just don't

want to loose too much time for a minor change like this.


As the final release is not yet out, I think it is safe to change the  
default and put a note in the documentation about that change.


Nicolas





Xavier





Gilles


2008/8/26 Xavier Hanin <[EMAIL PROTECTED]>:

Hi,

I've already suggested this a couple of times, I'd like to change  
the
default value of alwaysCheckExactRevision from true to false. IMO  
this is
almost never actually used, slightly degrades performance and  
sometimes

lead

to annoying bugs like invalid URLs (which should be fixed now). So,

anyone

against the idea of changing this default value?

Xavier

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/





--
Gilles Scokart

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





--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/



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

Re: Ivy 2.0 RC1 planning

[Nicolas Lalevée]

Le 28 août 08 à 17:48, Xavier Hanin a écrit :


On Thu, Aug 28, 2008 at 5:31 PM, Nicolas Lalevée <[EMAIL PROTECTED]

wrote:




Le 26 août 08 à 15:56, Xavier Hanin a écrit :


Hi,


I've been working on the remaining issues targetted to 2.0-RC1,  
and only a

few are remaining.

We have:
IVY-835   ant task downloads wrong jars from maven
repositories
IVY-675  Wrong graph of nodes is logged when circular dependency is
detected
IVY-349  Endless recursion in Report
=> those are about to be closed as cannot reproduce if no new  
activity

happens soon

IVY-652  Ivy constructs incorrect URL if artifact path contains  
spaces

=> This one Maarten you seem to have already made good progress, any
insight on the remaining time?

IVY-387  Absolute and relative path
IVY-232  Incorrect directory path resolve when running from a  
different

directory
=> These two are rather old, assigned to you Gilles. Any progress on
these? Do you need help?

IVY-872  Improve performance
=> This one is new and assigned to you Gilles. I don't think this  
should
be a show stopper for 2.0, and can be postponed to 2.0.1 if it  
takes too

long to implement

So I think we're pretty close to be able to enter in 2.0 release
candidates
cycles, to finally get 2.0 out! Do you see any other outstanding  
issue

which
should get in 2.0? Would you agree with a plan trying to get 2.0  
RC1 out
before mid september? Then how do you see the release candidates  
cycles
going on? I'd be in favour of trying to keep the cycles short (sg  
like

every
2 weeks), and if no outstanding bug is reported in a cycle, then we
release
2.0 final with the same source code as the last RC. What do you  
think of

this plan?



fine for me !

I have just a little issue that I would like to be addressed before  
the
release. It is about the OSGi version number of the rc and final  
version.
Version numbers in the OSGi environment needs to be ordered  
alphabetically.
Currently the OSGi version of the Ivy bundle is 2.0.0.rc1_ 
$TIMESTAMP. So for
the final version, we will have issues to find a name "upper" than  
that one.
I think we should better take 2.0.0.candidate1_$TIMESTAMP (it is  
still upper

than "beta") and then for the final : 2.0.0.final_$TIMESTAMP.


Good point. Maybe for the OSGi bundle version we could use cr  
instead of rc:
2.0.0.cr1_$TIMESTAMP. Some projects use candidate release instead of  
release

candidate, so this is pretty well accepted and understood.


ok. It is fine for me too.








Another point, this one non blocker for the release, but it will be  
cool if

you can also release Ivy into the IvyDE update site simultaneously.
Ivy has been re-packaged for the update site with the last release of
IvyDE. It would be cool to have it updated to the update without  
involving a
release of IvyDE. So I think that the best way to process is to  
move the
update site build process from the IvyDE build system to the site  
build

system. So the process would be:
- build the release of Ivy
- copy the new jar to /svn/ant/ivy/site/ivyde/updatesite/plugins/  
(the

entire updatesite will be in svn, jars and .md5)
- update manually the site.xml in site/ivyde/updatesite/ so it  
references

the new version
- ant generate-ivy-feature optimize-updatesite checksum-updatesite
sign-updatesite
- commit the regenerated stuff
After the release is voted:
- there would be a classic site deployment, as the site include the  
main

updatesite
- the updatesite mirrors can be updated in updating /www/
www.apache.org/dist/ant/ivyde/updatesite on people.apache.org

If no one object I will take care of setting up this, put proper  
detailed

doc about the process in the wiki.
Note that this process is not blocker against an Ivy release, we  
could have

some delay between releasing Ivy and having it published into the
updatesite. But I have no doubt that some users will quickly ask to  
have it

updated on the Eclipse side :)


That sounds like a good plan, very useful for IvyDE users. About  
documenting
the process, I'd prefer if this could go on the Ivy release  
documentation

page:
http://ant.apache.org/ivy/history/trunk/dev/makerelease.html


I forgot about that page.
So I think I will create a page just next to it, and add a new step  
that points to the new page in makerelease.html, as the update site  
release process should also work when releasing IvyDE.


Nicolas





Xavier





Nicolas



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





--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/



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

IvyDE and checkstyle

[Nicolas Lalevée]

Hi,

I have added some checkstyle configuration in IvyDE. It is actually  
the same as the Ivy one.
So now a lot of errors are popuping up. I will drastically reduce the  
number soon. As the change set is quite important, yell if you have a  
patch locally that need to be committed before I do (probably this  
week end).


cheers
Nicolas


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

Re: [VOTE] Ivy 2.0.0-rc1 Release

[Nicolas Lalevée]

Le mardi 16 septembre 2008, Xavier Hanin a écrit :
> I have built a release candidate for Ivy 2.0.0-rc1
>
> You can download it from this URL:
> http://people.apache.org/~xavier/ivy/staging/2.0.0-rc1/
>
> A maven 2 staging repo with this release is available here:
> http://people.apache.org/~xavier/m2-staging-repo/
> A staging eclipse update site with this release is available here:
> http://people.apache.org/~xavier/updatesite-staging/
> The bundle version is 2.0.0.cr1.
>
> Do you vote for the release of these binaries?
>

+1

> [X] Yes
> [ ] No

I have tested successfully Ivy in ant and in an Eclipse environment with the 
released IvyDE-alpha1.

I have just concerns about the deployment of the updatesite.

First the staging updatesite won't work as expected, as it is still pointing 
to the apache mirrors, which don't contains yet the new binaries. So the 
Eclipse update installer won't show the new Ivy RC1. Actually this staging 
updatesite will only work correctly as soon as deployed also on the mirrors, 
which make it not a very staging one. 
It is in fact my fault, the documentation talk about non mirroring of the 
staging updatesite, but the way to resolve it assume that the site.xml have 
relative urls, but the current one have absolute ones. I will fix it.

And I have found an issue with the signature of an artifact:
updatesite-staging/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar.pack.gz
I think that you launch the optimize task, but it was not signed again. I 
think the better way to work with it is to svn-revert the changes done by the 
optimize task for the already released jars, and then no need to sign it 
again.
I will update the documentation about this step.

Nicolas

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

Re: [VOTE] Ivy 2.0.0-rc1 Release

[Nicolas Lalevée]

Le mardi 16 septembre 2008, Xavier Hanin a écrit :
> On Tue, Sep 16, 2008 at 4:14 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]
>
> > wrote:
> >
> > Le mardi 16 septembre 2008, Xavier Hanin a écrit :
> > > I have built a release candidate for Ivy 2.0.0-rc1
> > >
> > > You can download it from this URL:
> > > http://people.apache.org/~xavier/ivy/staging/2.0.0-rc1/
> > >
> > > A maven 2 staging repo with this release is available here:
> > > http://people.apache.org/~xavier/m2-staging-repo/
> > > A staging eclipse update site with this release is available here:
> > > http://people.apache.org/~xavier/updatesite-staging/
> > > The bundle version is 2.0.0.cr1.
> > >
> > > Do you vote for the release of these binaries?
> >
> > +1
> >
> > > [X] Yes
> > > [ ] No
> >
> > I have tested successfully Ivy in ant and in an Eclipse environment with
> > the
> > released IvyDE-alpha1.
> >
> > I have just concerns about the deployment of the updatesite.
> >
> > First the staging updatesite won't work as expected, as it is still
> > pointing
> > to the apache mirrors, which don't contains yet the new binaries. So the
> > Eclipse update installer won't show the new Ivy RC1. Actually this
> > staging updatesite will only work correctly as soon as deployed also on
> > the mirrors,
> > which make it not a very staging one.
> > It is in fact my fault, the documentation talk about non mirroring of the
> > staging updatesite, but the way to resolve it assume that the site.xml
> > have relative urls, but the current one have absolute ones. I will fix
> > it.
>
> Indeed, I dumbly followed the steps in the documentation you wrote. If you
> can tell me what to put in the site.xml, I'll update it so that others can
> test it.

I have fixed the site.xml in svn. Just svn update it (the changes should be 
merged with your local ones), and scp it to the staging updatesite.

> > And I have found an issue with the signature of an artifact:
> >
> > updatesite-staging/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar.pack
> >.gz I think that you launch the optimize task, but it was not signed
> > again. I think the better way to work with it is to svn-revert the
> > changes done by the
> > optimize task for the already released jars, and then no need to sign it
> > again.
>
> Indeed, I only signed the new release, I thought the current IvyDE release
>  wouldn't be touched. Hence I've svn reverted these files on my working
> copy, and uploaded them in the update site. Since this is not what the vote
> is really on anyway, I don't think we need to cast a new vote. If anybody
> thinks casting a new vote is necessary, please tell me so.

I don't think a new vote is needed too, that's why I still voted +1.

cheers,
Nicolas


>
> Xavier
>
> > I will update the documentation about this step.
> >
> > Nicolas
> >
> > -
> > 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: AW: svn commit: r697019 - in /ant/ivy/ivyde/trunk: org.apache.ivyde.eclipse/ org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/ test/ivy-base-dir/ test/ivy-base-dir/settings/

[Nicolas Lalevée]

Le vendredi 19 septembre 2008, [EMAIL PROTECTED] a écrit :
> >Modified:
> >ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/
>
> eclipse/cpcontainer/IvyClasspathContainerConfiguration.java
>
> >@@ -480,14 +492,17 @@
> > }
> >
> > if (file.lastModified() != ivySettingsLastModified) {
> >-ivy = new Ivy();
> >+IvySettings ivySettings = new IvySettings();
> >+if (javaProject != null) {
> >+
>
> ivySettings.setBaseDir(javaProject.getProject().getLocation().toFile());
>
> >+}
> > if (ivySettingsLastModified == -1) {
> > Message.info("\n\n");
> > } else {
> > Message.info("\n\nIVYDE: ivysettings has changed,
>
> configuring ivy again\n");
>
> The info message completely in lower case?

is there any worry about it ?

> Why just the two new lines when -1?

The two new lines are I think because we are probably starting a new resolve 
session, so this need to be somehow visible.
And -1 means that the file has not been loaded yet, so there is no reloading 
to log about.

Nicolas

>
>
> Jan
>
> -
> 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: AW: AW: svn commit: r697019 - in /ant/ivy/ivyde/trunk: org.apache.ivyde.eclipse/ org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/ test/ivy-base-dir/ test/ivy-base-dir/settin

[Nicolas Lalevée]

Le vendredi 19 septembre 2008, [EMAIL PROTECTED] a écrit :
> >> > if (ivySettingsLastModified == -1) {
> >> > Message.info("\n\n");
> >> > } else {
> >> > Message.info("\n\nIVYDE: ivysettings has changed,
> >>
> >> The info message completely in lower case?
> >
> >is there any worry about it ?
>
> Not really. But if you present a log message (like the Exception
> strings)
> I think it would be better to write
>   Message.info("\n\nIVYDE: Ivy-settings has changed, configuring
> Ivy again\n");
> Or is "ivysettings" a technical term?

well, in Ivy's literature, I used to read about some "ivyconf", so with the 
new terminology, it becames "ivysettings". It looks understandable for me.
But I don't have any objection to change every occurence of it into "Ivy 
settings".

Nicolas

>
> >> Why just the two new lines when -1?
> >
> >The two new lines are I think because we are probably starting
> >a new resolve
> >session, so this need to be somehow visible.
> >And -1 means that the file has not been loaded yet, so there
> >is no reloading
> >to log about.
>
> Ok, thanks
>
>
> Jan
>
> -
> 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: [IVYDE] build failure

[Nicolas Lalevée]

Le lundi 22 septembre 2008, Martin Gainty a écrit :
> Erik-
>
> wondering if you
> ant install-ivy
>
> as suggested at
> https://issues.apache.org/jira/browse/IVYDE-65?page=com.atlassian.jira.plug
>in.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607344#action_1
>2607344
>thanks, Martin

I think that you don't have ivy installed in Eclipse too, Erik.
ant install-ivy won't solve you issue thought, as it will install the beta2. I 
will take time to improve that task so it can support some "lastest-dev" 
versions.
You have to copy the ivy RC1 jar manually to:
D:\java-apps\eclipse-RCP-3.4.1.RC2\plugins\org.apache.ivy_cr1.jar

Nicolas


> __
> Disclaimer and confidentiality note
> Everything in this e-mail and any attachments relates to the official
> business of Sender. This transmission is of a confidential nature and
> Sender does not endorse distribution to any party other than intended
> recipient. Sender does not necessarily endorse content contained within
> this transmission.
>
> > Subject: [IVYDE] build failure
> > Date: Mon, 22 Sep 2008 16:48:59 +0200
> > From: [EMAIL PROTECTED]
> > To: dev@ant.apache.org
> >
> > Hi,
> >
> > I'm having a problem with the suggested IVY rc1 in combination with IVY
> > DE. I've noticed that the IVYDE classpath container doesn't contain items
> > downloaded from a remote maven repository using IVY-RC1
> >
> > Therefore I tried to build the IVYDE from trunk, using the ivy rc1.
> > However, this failed miserably with the following error:
> >
> >  [java]
> >  [java] generateScript:
> >  [java] [eclipse.buildScript] Problem occurred while considering
> > plugin: IvyDE Eclipse Plug-in. [java]
> >  [java] BUILD FAILED
> >  [java]
> > D:\java-apps\eclipse-RCP-3.4.1.RC2\plugins\org.eclipse.pde.build_3.4.1.R3
> >4x_v20080805\scripts\build.xml:24: The following error occurred hile
> > executing this line:
> >  [java]
> > D:\java-apps\eclipse-RCP-3.4.1.RC2\plugins\org.eclipse.pde.build_3.4.1.R3
> >4x_v20080805\scripts\build.xml:64: The following error occurred hile
> > executing this line:
> >  [java] D:\java-apps\ivyde\builder\component\customTargets.xml:28:
> > The following error occurred while executing this line: [java]
> > D:\java-apps\ivyde\builder\component\allElements.xml:30: The following
> > error occurred while executing this line: [java]
> > D:\java-apps\eclipse-RCP-3.4.1.RC2\plugins\org.eclipse.pde.build_3.4.1.R3
> >4x_v20080805\scripts\genericTargets.xml:88: Unable to find plug n:
> > org.apache.ivyde.eclipse_0.0.0. Please check the error log for more
> > details. [java]
> >  [java] Total time: 2 seconds
> >
> >
> > I successfully built IVYDE from trunk before, but now it fails (using
> > Eclipse 3.4 SR1 RC2 for the first time). Any suggestions?
> >
> > Regards,
> > Erik-Berndt
> >
> > Disclaimer:
> >
> > This message contains information that may be privileged or confidential
> > and is the property of Sogeti Nederland B.V. or its Group members. It is
> > intended only for the person to whom it is addressed. If you are not the
> > intended recipient, you are not authorized to read, print, retain, copy,
> > disseminate, distribute, or use this message or any part thereof. If you
> > receive this message in error, please notify the sender immediately and
> > delete all copies of this message.
>
> _
> Get more out of the Web. Learn 10 hidden secrets of Windows Live.
> http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!5
>50F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008



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

Re: [CONF] Apache Ivy (Apache Ant subproject) : new (page created)

[Nicolas Lalevée]

Le vendredi 26 septembre 2008, Xavier Hanin a écrit :
> On Wed, Sep 24, 2008 at 11:37 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > On Wed, 24 Sep 2008, <[EMAIL PROTECTED]> wrote:
> > > Page Created : IVY : new
> > >
> > > new has been created by thiru (Sep 24, 2008).
> > >
> > > Content:
> > >
> > > hi
> >
> > I lack permissions to remove the page, could anybody else please do it
> > (and/or grant my account [EMAIL PROTECTED] karma to do so in the
> > future)?
>
> I've removed the page. I've also added page removal right to ivy-committers
> group, but I don't know how to view and edit group members...

I have found this:
http://confluence.atlassian.com/display/CONF25/Adding+or+Removing+a+User+from+a+Group

Nicolas

>
> Xavier
>
> > Thanks
> >
> >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: [ANN] Apache Ivy 2.0.0-rc1 released

[Nicolas Lalevée]

Le 26 sept. 08 à 13:03, Xavier Hanin a écrit :


Sep 26, 2008 - The Apache Ivy project is pleased to announce its
2.0.0 rc 1 version, the first release candidate for 2.0.0 final  
release.


Ivy is a tool for managing (recording, tracking, resolving and
reporting) project dependencies, characterized by flexibility,
configurability, and tight integration with Apache Ant.

This is a release candidate for 2.0.0 final, meaning that no changes
except bug fixes will occur before 2.0.0 final.
Problems found at this phase can be fixed in the final release, so now
is a good time to download and use it. If no outstanding bugs are  
reported
in the coming weeks, this release candidate will be promoted as  
2.0.0 final.


Key changes in this 2.0.0-rc1 version are
* enhanced Maven2 compatibility, with several bug fixes and more
pom features covered
* better and more homogeneous relative paths handling
* better support for local builds
* 80+ bug fixes as documented in Jira and in the release notes

Issues should be reported to:
https://issues.apache.org/jira/browse/IVY

Download the 2.0.0-rc1 release files at:
http://ant.apache.org/ivy/download.cgi

More information can be found on the Ivy website:
http://ant.apache.org/ivy/

Regards,
Xavier Hanin (2.0.0-rc1 release mgr)



Xavier, did you deployed the updatesite "mirrors" ?

I can site that the main updatesite is deployed:
http://ant.apache.org/ivy/ivyde/updatesite/

But I don't see the update there:
http://www.apache.org/dist/ant/ivyde/updatesite/
whereas the Ivy distrib has been updated:
http://www.apache.org/dist/ant/ivy/2.0.0-rc1/

I can take care of it, as the new updatesite is in svn.

I am also reconsidering some steps of the doc I wrote:
http://ant.apache.org/ivy/history/latest-milestone/dev/updatesite.html
For instance I don't think this is a good idea to do a backup of the  
updatesite on www.apache.org/dist as it would mean that the backup  
will be archived. And we probably don't want that.
There is also other points that need improvements I think, I'll start  
another thread about it.


Nicolas


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

Improvements of the IvyDE updatesite

[Nicolas Lalevée]

Now that we have a little more experience with the maintenance of an  
Eclipse updatesite, I see some points that needs improvements.


During the release of Ivy, there was a period when the updatesite is  
somehow "released" with the new jars and waiting for the vote, but not  
in svn, only on the release manager's machine. I think we should  
improve that and do some release branches for the updatesite.


Another point that seems to me now just complicating the release  
process for no real usefullness. The main Eclipse updatesite is there:
http://ant.apache.org/ivy/ivyde/updatesite, whereas the jars are  
deployed on the "mirrors", on http://www.apache.org/dist/ant/ivyde/updatesite 
. Actually there is no need to have the update site deployed on  
ant.apache.org/ivy/ivyde. Everything can be handled on www.apache.org/dist/ant/ivyde/ 
. In fact we can already use http://www.apache.org/dist/ant/ivyde/updatesite 
 as the main updatesite of IvyDE. We can merge them, so the main  
updatesite will also be the mirror one, this will simplify the  
deployment of the updatesite. And from the end user point of view it  
will just be another url.


So my proposal:
 - deprecate now (but not disable it) http://ant.apache.org/ivy/ivyde/updatesite 
 and recommand to use http://ant.apache.org/ivy/ivyde/updatesite
 - create http://svn.apache.org/repos/asf/ant/ivy/updatesite with a  
trunk-branches-tags structure
 - move the updatesite build system from the site build system to  
that new updatesite "project", so the deprecated updatesite will be  
manual partial copy of that new main one.

 - update the release doc accordingly

And once we decide to disable the update site on ant.apache.org remove  
the updatesite artifacts from the site, so it would be not accessible  
anymore, and just keep the cgi script that compute the urls of the  
apache mirrors.


WDYT ?

Nicolas


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

Re: Improvements of the IvyDE updatesite

[Nicolas Lalevée]

Le lundi 29 septembre 2008, Xavier Hanin a écrit :
> On Sun, Sep 28, 2008 at 4:32 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]
>
> > wrote:
> >
> > Now that we have a little more experience with the maintenance of an
> > Eclipse updatesite, I see some points that needs improvements.
> >
> > During the release of Ivy, there was a period when the updatesite is
> > somehow "released" with the new jars and waiting for the vote, but not in
> > svn, only on the release manager's machine. I think we should improve
> > that and do some release branches for the updatesite.
> >
> > Another point that seems to me now just complicating the release process
> > for no real usefullness. The main Eclipse updatesite is there:
> > http://ant.apache.org/ivy/ivyde/updatesite, whereas the jars are deployed
> > on the "mirrors", on http://www.apache.org/dist/ant/ivyde/updatesite.
> > Actually there is no need to have the update site deployed on
> > ant.apache.org/ivy/ivyde. Everything can be handled on
> > www.apache.org/dist/ant/ivyde/. In fact we can already use
> > http://www.apache.org/dist/ant/ivyde/updatesite as the main updatesite of
> > IvyDE. We can merge them, so the main updatesite will also be the mirror
> > one, this will simplify the deployment of the updatesite. And from the
> > end user point of view it will just be another url.
> >
> > So my proposal:
> >  - deprecate now (but not disable it)
> > http://ant.apache.org/ivy/ivyde/updatesite and recommand to use
> > http://ant.apache.org/ivy/ivyde/updatesite
>
> Typo: "recommand to use
> http://www.apache.org/dist/ant/ivyde/updatesite";<http://www.apache.org/dist
>/ant/ivyde/updatesite>

good catch :)

Nicolas

>
> > <http://ant.apache.org/ivy/ivyde/updatesite>
> >  - create http://svn.apache.org/repos/asf/ant/ivy/updatesite with a
> > trunk-branches-tags structure
> >  - move the updatesite build system from the site build system to that
> > new updatesite "project", so the deprecated updatesite will be manual
> > partial copy of that new main one.
> >  - update the release doc accordingly
> >
> > And once we decide to disable the update site on ant.apache.org remove
> > the updatesite artifacts from the site, so it would be not accessible
> > anymore, and just keep the cgi script that compute the urls of the apache
> > mirrors.
> >
> > WDYT ?
>
> This sounds perfect, I also thought that having the update site only on the
> release manager account during the release process was not a good thing,
> your changes will be a good improvement.
>
> Xavier
>
> > Nicolas
> >
> >
> > -
> > 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: [ANN] Apache Ivy 2.0.0-rc1 released

[Nicolas Lalevée]

Le lundi 29 septembre 2008, Xavier Hanin a écrit :
> On Sun, Sep 28, 2008 at 4:15 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]
>
> > wrote:
> >
> >
> > Le 26 sept. 08 à 13:03, Xavier Hanin a écrit :
> >
> >
> >  Sep 26, 2008 - The Apache Ivy project is pleased to announce its
> >
> >> 2.0.0 rc 1 version, the first release candidate for 2.0.0 final release.
> >>
> >> Ivy is a tool for managing (recording, tracking, resolving and
> >> reporting) project dependencies, characterized by flexibility,
> >> configurability, and tight integration with Apache Ant.
> >>
> >> This is a release candidate for 2.0.0 final, meaning that no changes
> >> except bug fixes will occur before 2.0.0 final.
> >> Problems found at this phase can be fixed in the final release, so now
> >> is a good time to download and use it. If no outstanding bugs are
> >> reported in the coming weeks, this release candidate will be promoted as
> >> 2.0.0 final.
> >>
> >> Key changes in this 2.0.0-rc1 version are
> >> * enhanced Maven2 compatibility, with several bug fixes and more
> >> pom features covered
> >> * better and more homogeneous relative paths handling
> >> * better support for local builds
> >> * 80+ bug fixes as documented in Jira and in the release notes
> >>
> >> Issues should be reported to:
> >> https://issues.apache.org/jira/browse/IVY
> >>
> >> Download the 2.0.0-rc1 release files at:
> >> http://ant.apache.org/ivy/download.cgi
> >>
> >> More information can be found on the Ivy website:
> >> http://ant.apache.org/ivy/
> >>
> >> Regards,
> >> Xavier Hanin (2.0.0-rc1 release mgr)
> >
> > Xavier, did you deployed the updatesite "mirrors" ?
> >
> > I can site that the main updatesite is deployed:
> > http://ant.apache.org/ivy/ivyde/updatesite/
> >
> > But I don't see the update there:
> > http://www.apache.org/dist/ant/ivyde/updatesite/
> > whereas the Ivy distrib has been updated:
> > http://www.apache.org/dist/ant/ivy/2.0.0-rc1/
>
> You're right, I haven't updated the update site. Actually I wasn't sure of
> what I've put in svn for the update site, so I didn't want to propagate it
> to dist.

The updatesite in svn is clean :)

I have pushed the new update site, Eclipse 3.4 already detects that an update 
of Ivy is available, but it will be fully functionnal as soon as the mirrors 
get the new artifacts.

Nicolas


>
> > I can take care of it, as the new updatesite is in svn.
>
> Ok, thanks.
>
> Xavier
>
> > I am also reconsidering some steps of the doc I wrote:
> > http://ant.apache.org/ivy/history/latest-milestone/dev/updatesite.html
> > For instance I don't think this is a good idea to do a backup of the
> > updatesite on www.apache.org/dist as it would mean that the backup will
> > be archived. And we probably don't want that.
> > There is also other points that need improvements I think, I'll start
> > another thread about it.
> >
> > Nicolas
> >
> >
> >
> > -
> > 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: [jira] Commented: (IVYDE-51) IvyDE doesn't set the ${basedir} property

[Nicolas Lalevée]

Le 22 sept. 08 à 10:08, Nicolas Lalevée (JIRA) a écrit :



   [ https://issues.apache.org/jira/browse/IVYDE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633165 
#action_12633165 ]


Nicolas Lalevée commented on IVYDE-51:
--

Yes, you can use {{${ivy.basedir}}}. But I don't think we can close  
this issue yet, the {{basedir}} property should be set. And the  
remaining question is where it should be set. In IvyDE, or in Ivy on  
the call of {{IvySetting#setBaseDir(File)}} ?


I think it would be a good idea to do it in Ivy.
Any objection ?

Nicolas





IvyDE doesn't set the ${basedir} property
-

   Key: IVYDE-51
   URL: https://issues.apache.org/jira/browse/IVYDE-51
   Project: IvyDE
Issue Type: Improvement
Components: classpath container
  Affects Versions: 2.0.0.alpha1
  Reporter: Maarten Coene

IvyDE doesn't specify the ${basedir} property when resolving the  
dependencies.
This means that it's not possible to resolve jar files in a  
[project]/lib directory.

For instance, the following resolver doesn't work:
{code}

 


{code}
Maarten


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.




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

Re: [jira] Commented: (IVYDE-51) IvyDE doesn't set the ${basedir} property

[Nicolas Lalevée]

Le mercredi 1 octobre 2008, Maarten Coene a écrit :
> I have some questions:
>
> What is the meaning of this ${basedir} property in Ivy?
> Is it different than the ${basedir} property from Ant?

no, it would have the exact same meaning. And with IVY-232, when running in 
ant, the ivy.basedir is set from the value of basedir which comes from ant.

> And why have 2 properties which have the same value (${ivy.basedir} and
> ${basedir}) ?

Actually it comes from the ivy.properties:
https://svn.apache.org/repos/asf/ant/ivy/core/trunk/src/java/org/apache/ivy/core/settings/ivy.properties

It set the property ivy.project.dir from the value of the property basedir. So 
in fact we have here 3 differents properties that should have the same value.

Nicolas


>
> Maarten
>
>
>
>
> - Original Message 
> From: Xavier Hanin <[EMAIL PROTECTED]>
> To: Ant Developers List 
> Sent: Wednesday, October 1, 2008 8:06:55 AM
> Subject: Re: [jira] Commented: (IVYDE-51) IvyDE doesn't set the ${basedir}
> property
>
> On Tue, Sep 30, 2008 at 9:28 PM, Nicolas Lalevée
> <[EMAIL PROTECTED]
>
> > wrote:
> >
> > Le 22 sept. 08 à 10:08, Nicolas Lalevée (JIRA) a écrit :
> >>   [
> >> https://issues.apache.org/jira/browse/IVYDE-51?page=com.atlassian.jira.p
> >>lugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633165#ac
> >>tion_12633165 ]
> >>
> >> Nicolas Lalevée commented on IVYDE-51:
> >> --
> >>
> >> Yes, you can use {{${ivy.basedir}}}. But I don't think we can close this
> >> issue yet, the {{basedir}} property should be set. And the remaining
> >> question is where it should be set. In IvyDE, or in Ivy on the call of
> >> {{IvySetting#setBaseDir(File)}} ?
> >
> > I think it would be a good idea to do it in Ivy.
> > Any objection ?
>
> No objection, as long as you don't override it if already defined.
>
> Xavier
>
> > Nicolas
> >
> >>  IvyDE doesn't set the ${basedir} property
> >>
> >>> -
> >>>
> >>>   Key: IVYDE-51
> >>>   URL: https://issues.apache.org/jira/browse/IVYDE-51
> >>>   Project: IvyDE
> >>>Issue Type: Improvement
> >>>Components: classpath container
> >>>  Affects Versions: 2.0.0.alpha1
> >>>  Reporter: Maarten Coene
> >>>
> >>> IvyDE doesn't specify the ${basedir} property when resolving the
> >>> dependencies.
> >>> This means that it's not possible to resolve jar files in a
> >>> [project]/lib directory.
> >>> For instance, the following resolver doesn't work:
> >>> {code}
> >>> 
> >>>  >>> pattern="${ivy.project.dir}/lib/[artifact](-[revision]).[ext]" />
> >>> 
> >>> {code}
> >>> Maarten
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> You can reply to this email to add a comment to the issue online.
> >
> > -
> > 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: Next step in Ivy 2.0 release process

[Nicolas Lalevée]

Le jeudi 16 octobre 2008, Gilles Scokart a écrit :
> 2008/10/15 Maarten Coene <[EMAIL PROTECTED]>:
> > Hi,
> >
> > Ivy-2.0.0-RC1 is out for some time now. What will be the next step?
> >
> > - create a new RC2 release containing some (or all) of the bugfixes which
> > have been committed into SVN trunk and maybe some open issues which
> > aren't fixed yet - create a 2.0.0 final release based on RC1
> >
> > I'm in favor for a new RC2 containing everything from SVN trunk. What do
> > others think?
>
> +1.  Only bug fixing have been commited to the trunk.  And I think
> some justify a second RC.

+1

Nicolas

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

Re: Next step in Ivy 2.0 release process

[Nicolas Lalevée]

Le vendredi 17 octobre 2008, Maarten Coene a écrit :
> ok, unless someone else volunteers, I'll try to make a RC2 next week.
>
> There are still some open issues I want to include in this release:
> - IVY-943: Allow authentication credentials to be specified in settings
> file. -> or should I not add it because it's not really a bug, but the
> provided code change is very simple and very low-risk - IVY-881: Ivy
> incorrectly searches for an artifact if it contains / in the name -> only
> if there is a patch ready before I start creating RC2 - IVY-931: What to do
> if Ivy can't find the parent of a POM -> if no-one objects, I let Ivy fail
> if the parent POM cannot be found
>
> Are there other open issues that should make it into RC2?

Sorry for the late reply, I nearly forgot about IVY-953. I think it should be 
integrated too. I can have it fix quickly.

Nicolas


>
> Maarten
>
>
>
>
> - Original Message 
> From: Gilles Scokart <[EMAIL PROTECTED]>
> To: Ant Developers List 
> Sent: Thursday, October 16, 2008 10:39:29 AM
> Subject: Re: Next step in Ivy 2.0 release process
>
> 2008/10/15 Maarten Coene <[EMAIL PROTECTED]>:
> > Hi,
> >
> > Ivy-2.0.0-RC1 is out for some time now. What will be the next step?
> >
> > - create a new RC2 release containing some (or all) of the bugfixes which
> > have been committed into SVN trunk and maybe some open issues which
> > aren't fixed yet - create a 2.0.0 final release based on RC1
> >
> > I'm in favor for a new RC2 containing everything from SVN trunk. What do
> > others think?
>
> +1.  Only bug fixing have been commited to the trunk.  And I think
> some justify a second RC.



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

Re: [VOTE] Ivy 2.0.0-rc2 Release

[Nicolas Lalevée]

I am not able to verify the signed artifacts as I don't have your  
public key, and I cannot find it in the ant KEYS file (http://www.apache.org/dist/ant/KEYS 
).

Have you published it somewhere else ?
Though every else worked fine for me for this release.

Nicolas

Le 28 oct. 08 à 23:53, Maarten Coene a écrit :


I have built a second release candidate for Ivy 2.0.0

You can download it from this URL:
http://people.apache.org/~maartenc/ivy/staging/2.0.0-rc2/

A maven 2 staging repo with this release is available here:
http://people.apache.org/~maartenc/m2-staging-repo/

A staging eclipse update site with this release is available here:
http://people.apache.org/~maartenc/updatesite-staging/
The bundle version is 2.0.0.cr2.

Do you vote for the release of these binaries?

[ ] Yes
[ ] No

Regards,

Maarten Coene,
Ivy 2.0.0-rc2 release manager





-
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: [VOTE] Ivy 2.0.0-rc2 Release

[Nicolas Lalevée]

Le dimanche 2 novembre 2008, Maarten Coene a écrit :
> ok, I've added my public key to the KEYS file.
> Could you try to verify the signed artifacts again?

verified successfully.
So here is my +1

Nicolas


>
> Maarten
>
>
>
>
> - Original Message 
> From: Nicolas Lalevée <[EMAIL PROTECTED]>
> To: Ant Developers List 
> Sent: Sunday, November 2, 2008 4:56:09 PM
> Subject: Re: [VOTE] Ivy 2.0.0-rc2 Release
>
> I am not able to verify the signed artifacts as I don't have your
> public key, and I cannot find it in the ant KEYS file
> (http://www.apache.org/dist/ant/KEYS ).
> Have you published it somewhere else ?
> Though every else worked fine for me for this release.
>
> Nicolas
>
> Le 28 oct. 08 à 23:53, Maarten Coene a écrit :
> > I have built a second release candidate for Ivy 2.0.0
> >
> > You can download it from this URL:
> > http://people.apache.org/~maartenc/ivy/staging/2.0.0-rc2/
> >
> > A maven 2 staging repo with this release is available here:
> > http://people.apache.org/~maartenc/m2-staging-repo/
> >
> > A staging eclipse update site with this release is available here:
> > http://people.apache.org/~maartenc/updatesite-staging/
> > The bundle version is 2.0.0.cr2.
> >
> > Do you vote for the release of these binaries?
> >
> > [ ] Yes
> > [ ] No
> >
> > Regards,
> >
> > Maarten Coene,
> > Ivy 2.0.0-rc2 release manager
> >
> >
> >
> >
> >
> > -
> > 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]
>
>
>
>
> -
> 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]

IvyDE 2.0 roadmap

[Nicolas Lalevée]

I would like to discuss about the next release of IvyDE.

The last release of IvyDE was made 4 months ago, there are some  
important bug fixes that make IvyDE a lot more stable, so I think it  
is a good time to get an IvyDE release now.
Thought I don't think that that next release is enough tested to be  
flagged as "2.0 final", I think a "beta" state is more appropriate,  
there are still opened and unresolved bugs. And the current  
implementation of the "resolve in workspace" is a little bit hacky. I  
would see that release as a milestone in a stable 2.0 roadmap.


For that beta release, I would like to take time to include IVYDE-120  
(make IvyDE work in Eclipse 3.2), and also IVYDE-119 (little  
refactoring of the UI, maybe together with IVYDE-106 (choose the  
configuration used during retrieve)).


After that beta out, I think we should focus then on a 2.0 final,  
making every bugs fixed, having a correct "resolve in workspace"  
implementation.


WDYT ?

Nicolas


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

Re: IvyDE 2.0 roadmap

[Nicolas Lalevée]

Le 11 nov. 08 à 10:49, Scheper, Erik-Berndt a écrit :


Hi,

Declaring ivyde as beta seems fine to me. I don't have many problems  
with the latest version.


What about IVYDE-128 and IVYDE-130? These are currently in the 2.0  
roadmap.
Although I must say that I have no idea how to reproduce IVYDE-130.  
I certainly have never seen anything like it.


for IVYDE-128, see my comment, it is already working for maven  
repositories, which is the main use case. Now it may exist some use  
case for some broken Ivy repositories, but it would be simpler to fix  
the repo I think, "qxo" (is it you Erik ?) should confirm it.


IVYDE-130: I have yet no idea how to fix it.

Then both are included in the 2.0 final roadmap, but it don't see the  
necessity to have them in the beta.
As soon as enough people agree with the roadmap, I will update Jira  
accordingly.


Nicolas








Regards,
Erik-Berndt




Van: Maarten Coene [mailto:[EMAIL PROTECTED]
Verzonden: ma 10-11-2008 23:24
Aan: Ant Developers List
Onderwerp: Re: IvyDE 2.0 roadmap



Sounds good to me

Maarten




- Original Message 
From: Nicolas Lalevée <[EMAIL PROTECTED]>
To: Ant Developers List 
Sent: Monday, November 10, 2008 11:15:48 PM
Subject: IvyDE 2.0 roadmap

I would like to discuss about the next release of IvyDE.

The last release of IvyDE was made 4 months ago, there are some  
important bug fixes that make IvyDE a lot more stable, so I think it  
is a good time to get an IvyDE release now.
Thought I don't think that that next release is enough tested to be  
flagged as "2.0 final", I think a "beta" state is more appropriate,  
there are still opened and unresolved bugs. And the current  
implementation of the "resolve in workspace" is a little bit hacky.  
I would see that release as a milestone in a stable 2.0 roadmap.


For that beta release, I would like to take time to include  
IVYDE-120 (make IvyDE work in Eclipse 3.2), and also IVYDE-119  
(little refactoring of the UI, maybe together with IVYDE-106 (choose  
the configuration used during retrieve)).


After that beta out, I think we should focus then on a 2.0 final,  
making every bugs fixed, having a correct "resolve in workspace"  
implementation.


WDYT ?

Nicolas


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




Disclaimer:
This message contains information that may be privileged or  
confidential and is the property of Sogeti Nederland B.V. or its  
Group members. It is intended only for the person to whom it is  
addressed. If you are not the intended recipient, you are not  
authorized to read, print, retain, copy, disseminate, distribute, or  
use this message or any part thereof. If you receive this message in  
error, please notify the sender immediately and delete all copies of  
this message.


-
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: IvyDE 2.0 roadmap

[Nicolas Lalevée]

Le 11 nov. 08 à 11:49, Scheper, Erik-Berndt a écrit :

Well, 'qxo' is definitely not me (or I would know how to reproduce  
IVYDE-130 ;-)


ok :)



And I agree with  your comment on IVYDE-128. Personally I have  
absolutely no need for this to be fixed.


I was just wondering what to do with these two issues as they are  
currently part of the 2.0 roadmap.


One other question just came to my mind: what about ivy 2.0 final?  
Should the ivyde beta wait for 2.0 final or not? Personally I don't  
feel the need for this but maybe someone disagrees.


I see no technical reason to have them released synchronously, as each  
new Ivy version is also available in the IvyDE update site.
But there can be some "marketing" reasons: "Here is the final version  
of Ivy 2 ! and yeah ! look ! there is also a new version of IvyDE !" :)
For my part, I don't mind waiting a little bit, I am pretty confident  
that the next version of Ivy will be a final version.


Nicolas





Regards,
Erik-Berndt


________

Van: Nicolas Lalevée [mailto:[EMAIL PROTECTED]
Verzonden: di 11-11-2008 11:23
Aan: Ant Developers List
Onderwerp: Re: IvyDE 2.0 roadmap




Le 11 nov. 08 à 10:49, Scheper, Erik-Berndt a écrit :


Hi,

Declaring ivyde as beta seems fine to me. I don't have many problems
with the latest version.

What about IVYDE-128 and IVYDE-130? These are currently in the 2.0
roadmap.
Although I must say that I have no idea how to reproduce IVYDE-130.
I certainly have never seen anything like it.


for IVYDE-128, see my comment, it is already working for maven
repositories, which is the main use case. Now it may exist some use
case for some broken Ivy repositories, but it would be simpler to fix
the repo I think, "qxo" (is it you Erik ?) should confirm it.

IVYDE-130: I have yet no idea how to fix it.

Then both are included in the 2.0 final roadmap, but it don't see the
necessity to have them in the beta.
As soon as enough people agree with the roadmap, I will update Jira
accordingly.

Nicolas








Regards,
Erik-Berndt




Van: Maarten Coene [mailto:[EMAIL PROTECTED]
Verzonden: ma 10-11-2008 23:24
Aan: Ant Developers List
Onderwerp: Re: IvyDE 2.0 roadmap



Sounds good to me

Maarten




- Original Message 
From: Nicolas Lalevée <[EMAIL PROTECTED]>
To: Ant Developers List 
Sent: Monday, November 10, 2008 11:15:48 PM
Subject: IvyDE 2.0 roadmap

I would like to discuss about the next release of IvyDE.

The last release of IvyDE was made 4 months ago, there are some
important bug fixes that make IvyDE a lot more stable, so I think it
is a good time to get an IvyDE release now.
Thought I don't think that that next release is enough tested to be
flagged as "2.0 final", I think a "beta" state is more appropriate,
there are still opened and unresolved bugs. And the current
implementation of the "resolve in workspace" is a little bit hacky.
I would see that release as a milestone in a stable 2.0 roadmap.

For that beta release, I would like to take time to include
IVYDE-120 (make IvyDE work in Eclipse 3.2), and also IVYDE-119
(little refactoring of the UI, maybe together with IVYDE-106 (choose
the configuration used during retrieve)).

After that beta out, I think we should focus then on a 2.0 final,
making every bugs fixed, having a correct "resolve in workspace"
implementation.

WDYT ?

Nicolas


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




Disclaimer:
This message contains information that may be privileged or
confidential and is the property of Sogeti Nederland B.V. or its
Group members. It is intended only for the person to whom it is
addressed. If you are not the intended recipient, you are not
authorized to read, print, retain, copy, disseminate, distribute, or
use this message or any part thereof. If you receive this message in
error, please notify the sender immediately and delete all copies of
this message.

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




Disclaimer:
This message contains information that may be privileged or  
confidential and is the property of Sogeti Nederland B.V. or its  
Group members. It is intended only for the person to whom it is  
addressed. If you are not the intended recipient, you are not  
authorized to read, print, retain, copy, disseminate, distribu

[Announce] IvyDE updatesite URL change

[Nicolas Lalevée]

Hi IvyDE users,

The current url used for the IvyDE updatesite is:
http://ant.apache.org/ivy/ivyde/udapetsite

For operational reason, it is a little painful to maintain it there, so 
we will now use a new main url:

http://www.apache.org/dist/ivyde/udapetsite

Compared to the old one, there won't be any difference, apart from the 
url itself.


You can switch now, the old one is still alive and will be maintained 
for some time but is deprecated.


cheers,
Nicolas


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