Ivy first apache version

[Xavier Hanin <xa...@gmail.com>]

Hi all,

In the thread "Ivy future development" Steve and I have already agreed that
the first version of Ivy on Apache should focus on:
- package rename from fr.jayasoft to org.apache.ivy (I'm not sure for the
apache package, maybe we should use something different?)
- code refactorings aimed at code cleaning and better design, easing new
developers involvment

The reason for that is to be able to produce a first version on apache in a
short time, and to ease contributions to the code.

Do everybody agree on this focus? How could we name this version? 1.5?

Xavier

Re: Ivy first apache version

[Xavier Hanin <xa...@gmail.com>]

On 11/14/06, Steve Loughran <st...@apache.org> wrote:
>
> Xavier Hanin wrote:
> > On 11/13/06, easyproglife <ea...@gmail.com> wrote:
> >>
> >> Xavier,
> >>
> >> Changing packages names IMO is a major change. I don't think 1.5 is a
> >> good
> >> candidate for such a version.
> >>
> >> IMO, you should start from ivy 2.0 with apache package names.
> >
> >
> > On one hand I agree, 2.0 would better reflect the changes of package
> names
> > and the refactorings. On the other hand, a 2.0 with no major new feature
> > would not necessarily be well understood. Anyway, I have no strong
> opinion
> > on the subject, but Ivy 1.4 already break some code at API level, the
> main
> > difference here is that it would break all code :-)
>
>
> well, you could make the package renaming the 2.0 milestone. A lot of
> projects, commercial and OSS have trouble at v2.0, as its the
> uncontrolled feature edition. In Apache, Axis 2.0 is a case in point
> (though its really Apache SOAP 3.0), and Ant has never got to a 2.0
> release because it got so controversial.


Yes a real 2.0 version is scaring me for the moment, I think we should first
try to benefit from current Ivy code, without trying to rewrite and rethink
everything. Current Ivy version is far from being perfect but it works.
Trying to make a real 2.0 the first release (I mean, with a status release,
not a milestone) on apache would imply a big delay that I don't think Ivy
with its current community and popularity can really afford.

Xavier

Re: Ivy first apache version

[Steve Loughran <st...@apache.org>]

Xavier Hanin wrote:
> On 11/13/06, easyproglife <ea...@gmail.com> wrote:
>>
>> Xavier,
>>
>> Changing packages names IMO is a major change. I don't think 1.5 is a 
>> good
>> candidate for such a version.
>>
>> IMO, you should start from ivy 2.0 with apache package names.
> 
> 
> On one hand I agree, 2.0 would better reflect the changes of package names
> and the refactorings. On the other hand, a 2.0 with no major new feature
> would not necessarily be well understood. Anyway, I have no strong opinion
> on the subject, but Ivy 1.4 already break some code at API level, the main
> difference here is that it would break all code :-)


well, you could make the package renaming the 2.0 milestone. A lot of 
projects, commercial and OSS have trouble at v2.0, as its the 
uncontrolled feature edition. In Apache, Axis 2.0 is a case in point 
(though its really Apache SOAP 3.0), and Ant has never got to a 2.0 
release because it got so controversial.

> 
> That way, fixes to previous (backwards compatible) version would still be
>> able to be done on ivy 1.x branch.
>>
>> I know you are going to tell me that no more changes are planned on
>> 1.xbranch but from my experience in software development IT WILL BE!
>> (keep my
>> words :))
> 
> 
> What I do not see is how could a new version with fr.jayasoft packages be
> done? AFAIK nobody has the right to do so except jayasoft, and jayasoft
> won't. Now that we are incubating on Apache, we should try to make a new
> version with Apache package names as soon as possible, with only a small 
> set
> of changes, so that "1.x" developments could be made on the new apache
> stream.

I think you need to keep the old package around with a copy of the 
antlib (it can relay to the new antlib) so that old build files load it. 
So the jayasoft package would be empty but for the antlib declaration.

Re: Ivy first apache version

[Xavier Hanin <xa...@gmail.com>]

On 11/13/06, easyproglife <ea...@gmail.com> wrote:
>
> Xavier,
>
> Changing packages names IMO is a major change. I don't think 1.5 is a good
> candidate for such a version.
>
> IMO, you should start from ivy 2.0 with apache package names.


On one hand I agree, 2.0 would better reflect the changes of package names
and the refactorings. On the other hand, a 2.0 with no major new feature
would not necessarily be well understood. Anyway, I have no strong opinion
on the subject, but Ivy 1.4 already break some code at API level, the main
difference here is that it would break all code :-)

That way, fixes to previous (backwards compatible) version would still be
> able to be done on ivy 1.x branch.
>
> I know you are going to tell me that no more changes are planned on
> 1.xbranch but from my experience in software development IT WILL BE!
> (keep my
> words :))


What I do not see is how could a new version with fr.jayasoft packages be
done? AFAIK nobody has the right to do so except jayasoft, and jayasoft
won't. Now that we are incubating on Apache, we should try to make a new
version with Apache package names as soon as possible, with only a small set
of changes, so that "1.x" developments could be made on the new apache
stream.

I don't know how many extension to ivy have been written so far, but please
> don't break their code at 1.x branch.


I don't know either, but I'm afraid it's the price to pay with the move to
apache. This may imply that the migration to the first apache version will
take longer, because people using tools may have problems to migrate. I'm
afraid I do not see any good solution to that problem, simply because I see
no way to continue releasing jayasoft versions of Ivy... But maybe I'm
wrong?

Xavier

easyproglife.
>
> On 11/13/06, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > Hi all,
> >
> > In the thread "Ivy future development" Steve and I have already agreed
> > that
> > the first version of Ivy on Apache should focus on:
> > - package rename from fr.jayasoft to org.apache.ivy (I'm not sure for
> the
> > apache package, maybe we should use something different?)
> > - code refactorings aimed at code cleaning and better design, easing new
> > developers involvment
> >
> > The reason for that is to be able to produce a first version on apache
> in
> > a
> > short time, and to ease contributions to the code.
> >
> > Do everybody agree on this focus? How could we name this version? 1.5?
> >
> > Xavier
> >
> >
>
>

Re: Ivy first apache version

[Xavier Hanin <xa...@gmail.com>]

On 11/15/06, Kevin Jackson <fo...@gmail.com> wrote:
>
> Hi all,
>
> Sorry if this has been mentioned before, but I may have missed it.
>
> Did Ivy get into the Apache SVN yet?  I just want to check out the
> current code base to start learning about it.


No, we are still waiting for some paperwork to be done. For the moment you
can get it from http://svn.jayasoft.org/ivy/

Xavier

Thanks,
> Kev
>
> (PS I know I could 'browse' the apache incubator svn, but it's so slow
> from here and mvn is currently pulling down multi-gigs of plugins and
> I don't want to disturb it)
>

Re: Ivy first apache version

[Kevin Jackson <fo...@gmail.com>]

Hi all,

Sorry if this has been mentioned before, but I may have missed it.

Did Ivy get into the Apache SVN yet?  I just want to check out the
current code base to start learning about it.

Thanks,
Kev

(PS I know I could 'browse' the apache incubator svn, but it's so slow
from here and mvn is currently pulling down multi-gigs of plugins and
I don't want to disturb it)

Re: Ivy first apache version

[Xavier Hanin <xa...@gmail.com>]

On 11/15/06, easyproglife <ea...@gmail.com> wrote:
>
> On 11/14/06, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > On 11/14/06, easyproglife <ea...@gmail.com> wrote:
> > >
> >
> > The next step is to create a simple, thin, flexible and scalable
> > > architecture.
> >
> >
> > I'm obviously biased, but I'm not sure we should create a brand new
> > architecture for Ivy 2.0. It took a lot of time to create Ivy 1.x,
> > restarting from scratch with a brand new architecture seems very
> ambitious
> > (and dangerous) to me, at least at the time being. Moreover, what does
> it
> > mean to migrate Ivy to apache if it's only to create a brand new and
> > redesigned version. Why not create a completely different project? I
> would
> > be more for refactorings, with discussions about the target design, but
> > with
> > some respect to existing and working code - not because I'm
> sentimentally
> > attached to this code, but simply because I think it's the better way to
> > get
> > a 2.0 version a reality, and not only a dream :-)
>
>
> Sure! I agree. Ivy architecture is great! What I meant is to refactor
> where
> needed and to invest some more work towards a stable API.
> (One simple example: latest strategy API (on 1.3.1) gives you a list of
> revisions and a date. I expected to get also the requested status - e.g. "
> latest.integration" along as a parameter. This is a little refactor, not a
> full redesign. )
>
> What I mean flexible and scalable is for example evaluating how
> complicated
> it is to write a DB based repository. It could be direct SQL driven or
> wrapped by an HTTP server with dynamic content, in contrast to raw HTTP
> URLs
> as today. Thinking about such possible enhancements can lead to better
> design and architecture. That's what I meant and that's where I want to go
> by collaborating ideas using the Wiki.


Ok, so we are in sync with how I see the future of Ivy on apache. Let's
continue contributing and organizing ideas on the wiki, and see how we can
address them.
About the API I strongly agree too, there is work to do in this area to
stabilize them, so that Ivy can better be used from other tools, and more
easily be extended.

Xavier

easyproglife
>
>

Re: Ivy first apache version

[Xavier Hanin <xa...@gmail.com>]

On 11/16/06, Jesus M. Rodriguez <jm...@gmail.com> wrote:
>
> I agree with not gutting the architecture.  As a new IVY user and a long
> time yum/linux user, I'm familiar with package  (jar) dependencies.  I'm
> in the
> process of trying to integrate ivy with jpackage rpms (
> http://www.jpackage.org)
> to make it easier to create repositories.


Sounds interesting, keep us informed of your progress.

  The folks at jpackage have already
> done lots of work defining rpm level dependencies.
>
> It seems to me, as a user, that there are no good tools for creating an
> ivy repo unless you're using a public repo to start from.  Are there any
> tools projects out there?  Just curious.


None that I'm aware of.

Xavier

Keep up the great work!
>
> jesus rodriguez
>
>
> On 11/15/06, easyproglife <ea...@gmail.com> wrote:
> > On 11/14/06, Xavier Hanin <xa...@gmail.com> wrote:
> > >
> > > On 11/14/06, easyproglife <ea...@gmail.com> wrote:
> > > >
> > >
> > > The next step is to create a simple, thin, flexible and scalable
> > > > architecture.
> > >
> > >
> > > I'm obviously biased, but I'm not sure we should create a brand new
> > > architecture for Ivy 2.0. It took a lot of time to create Ivy 1.x,
> > > restarting from scratch with a brand new architecture seems very
> ambitious
> > > (and dangerous) to me, at least at the time being. Moreover, what does
> it
> > > mean to migrate Ivy to apache if it's only to create a brand new and
> > > redesigned version. Why not create a completely different project? I
> would
> > > be more for refactorings, with discussions about the target design,
> but
> > > with
> > > some respect to existing and working code - not because I'm
> sentimentally
> > > attached to this code, but simply because I think it's the better way
> to
> > > get
> > > a 2.0 version a reality, and not only a dream :-)
> >
> >
> > Sure! I agree. Ivy architecture is great! What I meant is to refactor
> where
> > needed and to invest some more work towards a stable API.
> > (One simple example: latest strategy API (on 1.3.1) gives you a list of
> > revisions and a date. I expected to get also the requested status - e.g.
> "
> > latest.integration" along as a parameter. This is a little refactor, not
> a
> > full redesign. )
> >
> > What I mean flexible and scalable is for example evaluating how
> complicated
> > it is to write a DB based repository. It could be direct SQL driven or
> > wrapped by an HTTP server with dynamic content, in contrast to raw HTTP
> URLs
> > as today. Thinking about such possible enhancements can lead to better
> > design and architecture. That's what I meant and that's where I want to
> go
> > by collaborating ideas using the Wiki.
> >
> > easyproglife
> >
> >
>

Re: Ivy first apache version

["Jesus M. Rodriguez" <jm...@gmail.com>]

I agree with not gutting the architecture.  As a new IVY user and a long
time yum/linux user, I'm familiar with package  (jar) dependencies.  I'm in the
process of trying to integrate ivy with jpackage rpms (http://www.jpackage.org)
to make it easier to create repositories.  The folks at jpackage have already
done lots of work defining rpm level dependencies.

It seems to me, as a user, that there are no good tools for creating an
ivy repo unless you're using a public repo to start from.  Are there any
tools projects out there?  Just curious.

Keep up the great work!

jesus rodriguez


On 11/15/06, easyproglife <ea...@gmail.com> wrote:
> On 11/14/06, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > On 11/14/06, easyproglife <ea...@gmail.com> wrote:
> > >
> >
> > The next step is to create a simple, thin, flexible and scalable
> > > architecture.
> >
> >
> > I'm obviously biased, but I'm not sure we should create a brand new
> > architecture for Ivy 2.0. It took a lot of time to create Ivy 1.x,
> > restarting from scratch with a brand new architecture seems very ambitious
> > (and dangerous) to me, at least at the time being. Moreover, what does it
> > mean to migrate Ivy to apache if it's only to create a brand new and
> > redesigned version. Why not create a completely different project? I would
> > be more for refactorings, with discussions about the target design, but
> > with
> > some respect to existing and working code - not because I'm sentimentally
> > attached to this code, but simply because I think it's the better way to
> > get
> > a 2.0 version a reality, and not only a dream :-)
>
>
> Sure! I agree. Ivy architecture is great! What I meant is to refactor where
> needed and to invest some more work towards a stable API.
> (One simple example: latest strategy API (on 1.3.1) gives you a list of
> revisions and a date. I expected to get also the requested status - e.g. "
> latest.integration" along as a parameter. This is a little refactor, not a
> full redesign. )
>
> What I mean flexible and scalable is for example evaluating how complicated
> it is to write a DB based repository. It could be direct SQL driven or
> wrapped by an HTTP server with dynamic content, in contrast to raw HTTP URLs
> as today. Thinking about such possible enhancements can lead to better
> design and architecture. That's what I meant and that's where I want to go
> by collaborating ideas using the Wiki.
>
> easyproglife
>
>

Re: Ivy first apache version

[easyproglife <ea...@gmail.com>]

On 11/14/06, Xavier Hanin <xa...@gmail.com> wrote:
>
> On 11/14/06, easyproglife <ea...@gmail.com> wrote:
> >
>
> The next step is to create a simple, thin, flexible and scalable
> > architecture.
>
>
> I'm obviously biased, but I'm not sure we should create a brand new
> architecture for Ivy 2.0. It took a lot of time to create Ivy 1.x,
> restarting from scratch with a brand new architecture seems very ambitious
> (and dangerous) to me, at least at the time being. Moreover, what does it
> mean to migrate Ivy to apache if it's only to create a brand new and
> redesigned version. Why not create a completely different project? I would
> be more for refactorings, with discussions about the target design, but
> with
> some respect to existing and working code - not because I'm sentimentally
> attached to this code, but simply because I think it's the better way to
> get
> a 2.0 version a reality, and not only a dream :-)


Sure! I agree. Ivy architecture is great! What I meant is to refactor where
needed and to invest some more work towards a stable API.
(One simple example: latest strategy API (on 1.3.1) gives you a list of
revisions and a date. I expected to get also the requested status - e.g. "
latest.integration" along as a parameter. This is a little refactor, not a
full redesign. )

What I mean flexible and scalable is for example evaluating how complicated
it is to write a DB based repository. It could be direct SQL driven or
wrapped by an HTTP server with dynamic content, in contrast to raw HTTP URLs
as today. Thinking about such possible enhancements can lead to better
design and architecture. That's what I meant and that's where I want to go
by collaborating ideas using the Wiki.

easyproglife

Re: Ivy first apache version

[Xavier Hanin <xa...@gmail.com>]

On 11/14/06, easyproglife <ea...@gmail.com> wrote:
>
> Ok.
>
> I see that since the API is already not so stable, the preferred way is to
> release ivy 1.5 or 1.6 just to engage the "ivy-under-apache" wheel.


Yes, that's the idea.

I also see the the wiki is ready, so my suggestion is to start organizing
> current ideas, collect new ideas and try organizing a vision about how ivy
> 2.0 should look like. This "2.0" activity can be done in parallel with the
> release of the new "ivy-under-apache" release.


I agree too, we can start the discussion about this 2.0 version in parallel,
and see where we go.

I want to contribute my knowledge and ideas to understand the community
> requirements.


Great!

I think we should learn a lesson from Maven in the negative way: it is more
> important to understand what feature NOT to include than what feature to
> include, in order to be fast, efficient and simple.
>
> I don't want to see Ivy as a big and wide product as Maven. I prefer doing
> the best dependency-management tool (as Ivy aimed to be) in the market,
> while keeping it thin, flexible and powerful.


I agree that Ivy should keep its focus on dependency management, and not try
to do anything else. I also agree that we should try to make it simple (to
use) flexible and powerful.

My inspirations are products like Ant, JUnit and Spring. The concentrate on
> a well defined goal, doing a great product and keep in mind to concentrate
> on their goal and not to be the ultimate product that "does it all" and
> "good for anyone".


For the "does it all" and "good for everyone", I'm not sure to share your
opinion. First, I don't think that Spring does not try to address that
(consider the number of ORM supported). Second I think that flexibility is
the ability to address different use cases, and Ivy has always tried to be
flexible, so tried to be "good for anyone" - "who wants to use a dependency
manager" :-) So I agree that we should keep Ivy focused solely on dependency
management, but I think that in this area it should try to stay flexible
(even if we improve the out of the box experience with better defaults
reflecting what is accepted as best practices - if we agree on them :-))

(Ant, for example, as written in their Wiki, is not aimed to be a "workflow"
> product. Despite the pressure, they didn't add looping, exception handling
> and other features. On the other hand, they allowed third party product
> like
> ant-contrib to enhance them, but without touching the core.)
>
> So my next step is to organize the great ideas we read in this mailing
> list
> into a list of community requirements. I expect people to help us
> prioritize
> the requirements and decide what should be and what should not be
> addressed
> by Ivy.


Organizing community ideas and feedback is great, this is something that
lacked to Ivy development so far. But we will have to be careful to avoid
trying to make the "best tool on earth that never reaches more than an alpha
version".

The next step is to create a simple, thin, flexible and scalable
> architecture.


I'm obviously biased, but I'm not sure we should create a brand new
architecture for Ivy 2.0. It took a lot of time to create Ivy 1.x,
restarting from scratch with a brand new architecture seems very ambitious
(and dangerous) to me, at least at the time being. Moreover, what does it
mean to migrate Ivy to apache if it's only to create a brand new and
redesigned version. Why not create a completely different project? I would
be more for refactorings, with discussions about the target design, but with
some respect to existing and working code - not because I'm sentimentally
attached to this code, but simply because I think it's the better way to get
a 2.0 version a reality, and not only a dream :-)

Let's start with the wiki. It's a great collaboration tool!


I agree

Xavier

easyproglife.
>
>
> On 11/13/06, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > On 11/13/06, Stephane Bailliez <sb...@gmail.com> wrote:
> > >
> > > easyproglife wrote:
> > > > Changing packages names IMO is a major change. I don't think 1.5 is
> a
> > > > good
> > > > candidate for such a version.
> > > > [...]
> > > > I don't know how many extension to ivy have been written so far, but
> > > > please
> > > > don't break their code at 1.x branch.
> > >
> > > I would not bother because nearly every release where you tried to use
> > > the API directly was broken with the next release simply because the
> > > architecture did not allow any difference between what's public and
> > > what's private so any little change was actually breaking something.
> >
> >
> > I agree.
> >
> > That's unnecessary to add ourselves more constraints than necessary at
> > > this stage.
> >
> >
> > +1
> >
> > Xavier
> >
> > -- stephane
> > >
> > >
> > >
> >
> >
>
>

Re: Ivy first apache version

[easyproglife <ea...@gmail.com>]

Ok.

I see that since the API is already not so stable, the preferred way is to
release ivy 1.5 or 1.6 just to engage the "ivy-under-apache" wheel.

I also see the the wiki is ready, so my suggestion is to start organizing
current ideas, collect new ideas and try organizing a vision about how ivy
2.0 should look like. This "2.0" activity can be done in parallel with the
release of the new "ivy-under-apache" release.

I want to contribute my knowledge and ideas to understand the community
requirements.

I think we should learn a lesson from Maven in the negative way: it is more
important to understand what feature NOT to include than what feature to
include, in order to be fast, efficient and simple.

I don't want to see Ivy as a big and wide product as Maven. I prefer doing
the best dependency-management tool (as Ivy aimed to be) in the market,
while keeping it thin, flexible and powerful.

My inspirations are products like Ant, JUnit and Spring. The concentrate on
a well defined goal, doing a great product and keep in mind to concentrate
on their goal and not to be the ultimate product that "does it all" and
"good for anyone".

(Ant, for example, as written in their Wiki, is not aimed to be a "workflow"
product. Despite the pressure, they didn't add looping, exception handling
and other features. On the other hand, they allowed third party product like
ant-contrib to enhance them, but without touching the core.)

So my next step is to organize the great ideas we read in this mailing list
into a list of community requirements. I expect people to help us prioritize
the requirements and decide what should be and what should not be addressed
by Ivy.

The next step is to create a simple, thin, flexible and scalable
architecture.

Let's start with the wiki. It's a great collaboration tool!

easyproglife.


On 11/13/06, Xavier Hanin <xa...@gmail.com> wrote:
>
> On 11/13/06, Stephane Bailliez <sb...@gmail.com> wrote:
> >
> > easyproglife wrote:
> > > Changing packages names IMO is a major change. I don't think 1.5 is a
> > > good
> > > candidate for such a version.
> > > [...]
> > > I don't know how many extension to ivy have been written so far, but
> > > please
> > > don't break their code at 1.x branch.
> >
> > I would not bother because nearly every release where you tried to use
> > the API directly was broken with the next release simply because the
> > architecture did not allow any difference between what's public and
> > what's private so any little change was actually breaking something.
>
>
> I agree.
>
> That's unnecessary to add ourselves more constraints than necessary at
> > this stage.
>
>
> +1
>
> Xavier
>
> -- stephane
> >
> >
> >
>
>

Re: Ivy first apache version

[Xavier Hanin <xa...@gmail.com>]

On 11/13/06, Stephane Bailliez <sb...@gmail.com> wrote:
>
> easyproglife wrote:
> > Changing packages names IMO is a major change. I don't think 1.5 is a
> > good
> > candidate for such a version.
> > [...]
> > I don't know how many extension to ivy have been written so far, but
> > please
> > don't break their code at 1.x branch.
>
> I would not bother because nearly every release where you tried to use
> the API directly was broken with the next release simply because the
> architecture did not allow any difference between what's public and
> what's private so any little change was actually breaking something.


I agree.

That's unnecessary to add ourselves more constraints than necessary at
> this stage.


+1

Xavier

-- stephane
>
>
>

Re: Ivy first apache version

[Stephane Bailliez <sb...@gmail.com>]

easyproglife wrote:
> Changing packages names IMO is a major change. I don't think 1.5 is a 
> good
> candidate for such a version.
> [...]
> I don't know how many extension to ivy have been written so far, but 
> please
> don't break their code at 1.x branch.

I would not bother because nearly every release where you tried to use 
the API directly was broken with the next release simply because the 
architecture did not allow any difference between what's public and 
what's private so any little change was actually breaking something.

That's unnecessary to add ourselves more constraints than necessary at 
this stage.


-- stephane

Re: Ivy first apache version

[easyproglife <ea...@gmail.com>]

Xavier,

Changing packages names IMO is a major change. I don't think 1.5 is a good
candidate for such a version.

IMO, you should start from ivy 2.0 with apache package names.

That way, fixes to previous (backwards compatible) version would still be
able to be done on ivy 1.x branch.

I know you are going to tell me that no more changes are planned on
1.xbranch but from my experience in software development IT WILL BE!
(keep my
words :))

I don't know how many extension to ivy have been written so far, but please
don't break their code at 1.x branch.

easyproglife.

On 11/13/06, Xavier Hanin <xa...@gmail.com> wrote:
>
> Hi all,
>
> In the thread "Ivy future development" Steve and I have already agreed
> that
> the first version of Ivy on Apache should focus on:
> - package rename from fr.jayasoft to org.apache.ivy (I'm not sure for the
> apache package, maybe we should use something different?)
> - code refactorings aimed at code cleaning and better design, easing new
> developers involvment
>
> The reason for that is to be able to produce a first version on apache in
> a
> short time, and to ease contributions to the code.
>
> Do everybody agree on this focus? How could we name this version? 1.5?
>
> Xavier
>
>

Re: Ivy first apache version

[Xavier Hanin <xa...@gmail.com>]

On 11/14/06, Steve Loughran <st...@apache.org> wrote:
>
> Eric Crahen wrote:
> > You're going to do an offical release where all you have done is changed
> > package names? Why not just bump the version, leave it in cvs as a
> > development branch and keep it there until significant effort and
> testing
> > has been done.
> >
> > I don't see what a quick release where you rename everything would do,
> it's
> > only of interest to developers. As a user of 1.4, the only reason I
> would
> > upgrade would be bugfixes. Changing around the package names just means
> > work
> > for me updating my taskdefs to match.
>
>
> As well as an an antlib, we could code some very thin classes in the
> original location that relay stuff to the new place. They would just
> extend the org.apache ones, maybe with a warning on <resolve> that you'd
> used the (deprecated) name.
>
> We'd need some ok from jayasoft to do this, or they could release a shim
> jar themselves that did the bridging.


The ok from jayasoft is not a problem, we can provide an antlib in the
jayasoft package for backward compatibility.

> Maybe this begs a broader question of should you simply freeze major
> > changes
> > on 1.4 and backport only major bug fixes, and do all new development in
> cvs
> > under a new major version which is in no rush to be released?
>
>
> The goal for a move to apache without big changes is to get a transition
> out of incubation without sitting down to do a big code roll. They
> always take longer than you think, even when you take that fact into
> account.


+1

What apache wants is not a new rewrite of the code, that is not a prereq
> to getting out of incubation. What is is (a) code that isnt contaminated
> with copyright and similar problems and (b) an active community of
> developers. There are lots of people on the list with opinions, so we
> are making a start.
>
> I have one other requirement, which we can start as soon as ivy is on
> SVN, That is "ivy builds on Gump". there is a static version of Ivy 1.3
> up there, but we need SVN_HEAD. Otherwise projects that use Ivy 1.4+
> don't build on gump:
>
>
> http://vmgump.apache.org/gump/public/antbook/antbook-diary-core/gump_work/build_antbook_antbook-diary-core.html
>
> I'd like to fix this this week. What is the current SVN status?


The current svn status on jayasoft site corresponds to Ivy 1.4.1, with
commit disabled. I've prepared an svn dump ready to be imported in apache,
I'm only waiting for maarten to get an apache username, so that people from
infrastructure can map his name in old jayasoft svn repo to his apache
username. Maarten sent his ICLA by snail mail about two weeks ago I think,
so it shouldn't take too much time to be registered. Then I hope Maarten
will be able to say which username he wants, but he is currently overbooked
with a very happy family event.

Xavier

I'll set
> up the gump descriptors unless Stefano, Stefan or Stephane want to. All
> apache committes whose name is a variant of Stephen gets commit rights
> to Gump :)
>
> -steve
>
> -steve
>
>
>
>

Re: Ivy first apache version

[Steve Loughran <st...@apache.org>]

Eric Crahen wrote:
> You're going to do an offical release where all you have done is changed
> package names? Why not just bump the version, leave it in cvs as a
> development branch and keep it there until significant effort and testing
> has been done.
> 
> I don't see what a quick release where you rename everything would do, it's
> only of interest to developers. As a user of 1.4, the only reason I would
> upgrade would be bugfixes. Changing around the package names just means 
> work
> for me updating my taskdefs to match.


As well as an an antlib, we could code some very thin classes in the 
original location that relay stuff to the new place. They would just 
extend the org.apache ones, maybe with a warning on <resolve> that you'd 
used the (deprecated) name.

We'd need some ok from jayasoft to do this, or they could release a shim 
jar themselves that did the bridging.

> Maybe this begs a broader question of should you simply freeze major 
> changes
> on 1.4 and backport only major bug fixes, and do all new development in cvs
> under a new major version which is in no rush to be released?


The goal for a move to apache without big changes is to get a transition 
out of incubation without sitting down to do a big code roll. They 
always take longer than you think, even when you take that fact into 
account.

What apache wants is not a new rewrite of the code, that is not a prereq 
to getting out of incubation. What is is (a) code that isnt contaminated 
with copyright and similar problems and (b) an active community of 
developers. There are lots of people on the list with opinions, so we 
are making a start.

I have one other requirement, which we can start as soon as ivy is on 
SVN, That is "ivy builds on Gump". there is a static version of Ivy 1.3 
up there, but we need SVN_HEAD. Otherwise projects that use Ivy 1.4+ 
don't build on gump:

http://vmgump.apache.org/gump/public/antbook/antbook-diary-core/gump_work/build_antbook_antbook-diary-core.html

I'd like to fix this this week. What is the current SVN status? I'll set 
up the gump descriptors unless Stefano, Stefan or Stephane want to. All 
apache committes whose name is a variant of Stephen gets commit rights 
to Gump :)

-steve

-steve

Re: Ivy first apache version

[Stephane Bailliez <sb...@gmail.com>]

Eric Crahen wrote:
> It was the talk of a quick interim release that sent me down that path.

Yeah my fault, verbiage was not probably appropriate.
When I said 'quick interim release' in my mind it was more about that 
things need to be done on the 1.x branch rather than doing straight some 
work about 2.0 and trying to do the next revolutionary stuff.

2.0 always have a problem getting out (Ant, Maven, Wicket, ... to get my 
point)

The 1.x code gives some excuse to start some work on it.

-- stephane

Re: Ivy first apache version

[Eric Crahen <er...@gmail.com>]

It was the talk of a quick interim release that sent me down that path.

On 11/13/06, Stephane Bailliez <sb...@gmail.com> wrote:
>
> Eric Crahen wrote:
> > You're going to do an offical release where all you have done is changed
> > package names? Why not just bump the version, leave it in cvs as a
> > development branch and keep it there until significant effort and
> testing
> > has been done.
>
> I don't think anyone said that.
>
> In addition there was:
>
> "- code refactorings aimed at code cleaning and better design, easing
> new  developers involvment "
>
> And leaving things in cvs means as well that no one will use it too.
> 'significant effort and testing' is empirical as well.
> Of course if we release things that constantly break previous version,
> it's no fun.
>
> Chicken and egg problem.
>
> -- stephane
>



-- 

- Eric

Re: Ivy first apache version

[Stephane Bailliez <sb...@gmail.com>]

Eric Crahen wrote:
> You're going to do an offical release where all you have done is changed
> package names? Why not just bump the version, leave it in cvs as a
> development branch and keep it there until significant effort and testing
> has been done.

I don't think anyone said that.

In addition there was:

"- code refactorings aimed at code cleaning and better design, easing 
new  developers involvment "

And leaving things in cvs means as well that no one will use it too. 
'significant effort and testing' is empirical as well.
Of course if we release things that constantly break previous version, 
it's no fun.

Chicken and egg problem.

-- stephane

Re: Ivy first apache version

[Eric Crahen <er...@gmail.com>]

You're going to do an offical release where all you have done is changed
package names? Why not just bump the version, leave it in cvs as a
development branch and keep it there until significant effort and testing
has been done.

I don't see what a quick release where you rename everything would do, it's
only of interest to developers. As a user of 1.4, the only reason I would
upgrade would be bugfixes. Changing around the package names just means work
for me updating my taskdefs to match.

Maybe this begs a broader question of should you simply freeze major changes
on 1.4 and backport only major bug fixes, and do all new development in cvs
under a new major version which is in no rush to be released?

On 11/13/06, Stephane Bailliez <sb...@gmail.com> wrote:
>
> Xavier Hanin wrote:
> > In the thread "Ivy future development" Steve and I have already agreed
> > that
> > the first version of Ivy on Apache should focus on:
> > - package rename from fr.jayasoft to org.apache.ivy (I'm not sure for
> the
> > apache package, maybe we should use something different?)
> > - code refactorings aimed at code cleaning and better design, easing new
> > developers involvment
> >
> > The reason for that is to be able to produce a first version on apache
> > in a
> > short time, and to ease contributions to the code.
> >
> > Do everybody agree on this focus? How could we name this version? 1.5?
>
> I agree. Don't name it 2.0, it is not. if you want name it 1.6 to
> reflect a 'more than 1.5'
>
> I think having a reasonably quick interim release is good and passing
> toward package naming gives us an excuse to break things a little bit.
> The quick interim release is sound to me for many reasons.
>
> - trying to do everything from scratch with all super ideas to do a p2p,
> micro revision, have super integration with maven etc, is food for
> problems. I've been involved since the very first day of maven and I
> know well how it started.
>
> - we have to build a community first and take confidence in the source
> code and what is already written to address weaknesses step by step and
> have more than one person really knowing what has to be done.
>
> -- stephane
>



-- 

- Eric

Re: Ivy first apache version

[Stephane Bailliez <sb...@gmail.com>]

Xavier Hanin wrote:
> In the thread "Ivy future development" Steve and I have already agreed 
> that
> the first version of Ivy on Apache should focus on:
> - package rename from fr.jayasoft to org.apache.ivy (I'm not sure for the
> apache package, maybe we should use something different?)
> - code refactorings aimed at code cleaning and better design, easing new
> developers involvment
>
> The reason for that is to be able to produce a first version on apache 
> in a
> short time, and to ease contributions to the code.
>
> Do everybody agree on this focus? How could we name this version? 1.5?

I agree. Don't name it 2.0, it is not. if you want name it 1.6 to 
reflect a 'more than 1.5'

I think having a reasonably quick interim release is good and passing 
toward package naming gives us an excuse to break things a little bit.
The quick interim release is sound to me for many reasons.

- trying to do everything from scratch with all super ideas to do a p2p, 
micro revision, have super integration with maven etc, is food for 
problems. I've been involved since the very first day of maven and I 
know well how it started.

- we have to build a community first and take confidence in the source 
code and what is already written to address weaknesses step by step and 
have more than one person really knowing what has to be done.

-- stephane