Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: softfail (athena.apache.org: transitioning domain of
 nicolas.lalevee@hibnet.org does not designate 216.86.168.178 as permitted
 sender)
From: Nicolas =?iso-8859-1?q?Lalev=E9e?= <nicolas.lalevee@hibnet.org>
To: "Ant Developers List" <dev@ant.apache.org>
Subject: Re: Improvements of the IvyDE updatesite
Date: Mon, 29 Sep 2008 11:57:44 +0200
User-Agent: KMail/1.9.10
References: <8F0452A4-5DE6-4F55-90BB-A448F2B1EC11@hibnet.org>
 <635a05060809290000s57efb084qa582233aa5e80cd2@mail.gmail.com>
In-Reply-To: <635a05060809290000s57efb084qa582233aa5e80cd2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200809291157.44126.nicolas.lalevee@hibnet.org>

Le lundi 29 septembre 2008, Xavier Hanin a =E9crit=A0:
> On Sun, Sep 28, 2008 at 4:32 PM, Nicolas Lalev=E9e
> <nicolas.lalevee@hibnet.org
>
> > 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 deploy=
ed
> > 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/di=
st
>/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 apac=
he
> > mirrors.
> >
> > WDYT ?
>
> This sounds perfect, I also thought that having the update site only on t=
he
> 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: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org


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