You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Antoine Lévy-Lambert <an...@antbuild.com> on 2003/09/12 11:58:39 UTC
[VOTE]: Getting 1.6 out the door
Hi,
I would like to propose a release plan for voting :
- features included in 1.6 : all the features currently present in head
- freeze date for 1.6 branch : Monday, September 22 13:00 GMT
- availability of ANT_16_B1 binaries : within one week of the freeze of the
branch.
The exact time will depend on whether I will have trouble with practical
issues from the build down to the signing of the jar files to the update of
the web site, of bugzilla, ...
- release manager : myself
(I hope this is OK, although I am not a PMC member).
So, if this release plan is voted, on Monday, September 22 I will create the
ANT_16_BRANCH tag.
The CVS Head will then become ant 1.7alpha
Cheers,
Antoine
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <de...@ant.apache.org>
Sent: Friday, August 29, 2003 2:08 PM
Subject: Re: Getting 1.6 out the door
> Peter is currently on vacation, I hope he'll be back soon enough to
> chime in.
>
> On Thu, 28 Aug 2003, Conor MacNeill <co...@cortexebusiness.com.au>
> wrote:
>
> > There will probably be a 1.6.1 release in between to clean up any
> > issues we discover in 1.6
>
> Maybe we should consequentyl call the first 1.6 release 1.6.0 then?
>
> > 2. antlib
> >
> > I think this should be in
>
> yes.
>
> > but I am not familiar with its state yet,
>
> I'm not happy with some code details but the overal functionality is
> there. We should be able to properly document it and see whether we
> all can agree that this is the antlib functionality we want. If we
> agree on it, we should put it into 1.6 - changing implementation
> details would be like fixing bugs IMHO.
>
> > nor do I think it has had enough testing
>
> Of course not.
>
> > Are we planning to antlib Ant's own optional jars?
>
> Not in 1.6(.0) IMHO.
>
> > In 1.7 I think we need to look at removing antlibs from the root
> > loader when their dependent jars are not available in ANT_HOME/lib.
>
> Yes.
>
> > Comments?
>
> The permissions stuff is causing some problems and we need to get the
> new Launcher tested in a wider audience. Gump doesn't use it, it
> still uses Main as its entry point and switching it to use Launcher
> will cause a lot of problems (if we do it right and don't cheat by
> adding ant.jar to CLASSPATH, that is).
>
> Stefan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by Magesh Umasankar <um...@apache.org>.
From: Antoine Lévy-Lambert
> Hi,
> I would like to propose a release plan for voting :
> - features included in 1.6 : all the features currently present in head
> - freeze date for 1.6 branch : Monday, September 22 13:00 GMT
> - availability of ANT_16_B1 binaries : within one week of the freeze of
the
> branch.
> The exact time will depend on whether I will have trouble with practical
> issues from the build down to the signing of the jar files to the update
of
> the web site, of bugzilla, ...
> - release manager : myself
>
> (I hope this is OK, although I am not a PMC member).
>
> So, if this release plan is voted, on Monday, September 22 I will create
> the ANT_16_BRANCH tag.
> The CVS Head will then become ant 1.7alpha
>
+1
Cheers,
Magesh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
On Fri, 12 Sep 2003 07:58 pm, Antoine Lévy-Lambert wrote:
> Hi,
> I would like to propose a release plan for voting :
> - features included in 1.6 : all the features currently present in head
> - freeze date for 1.6 branch : Monday, September 22 13:00 GMT
> - availability of ANT_16_B1 binaries : within one week of the freeze of the
> branch.
> The exact time will depend on whether I will have trouble with practical
> issues from the build down to the signing of the jar files to the update of
> the web site, of bugzilla, ...
> - release manager : myself
>
> (I hope this is OK, although I am not a PMC member).
>
> So, if this release plan is voted, on Monday, September 22 I will create
> the ANT_16_BRANCH tag.
> The CVS Head will then become ant 1.7alpha
>
+1
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 19 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> On Friday 19 September 2003 07:50, Stefan Bodewig wrote:
>> On Thu, 18 Sep 2003, Steve Loughran <st...@iseran.com> wrote:
>> > I'd also like Ant 1.6 to have try/catch; if we cannot easily
>> > reuse the ant contrib one,
>>
>> Have we even tried to?
>
> The issue was getting permission from the author.
authors.
The other thing should be asking the ant-contrib project admins
whether it was OK with them IMHO. You and I are mere mortals unlike
Matt and Curt 8-)
> (One Stefan Bodewig with mods by Dan Ritchey from the javadoc).
It's been more the other way around. The initial code has been Dan's
and I've modified it (quite a bit - the initial code could just catch
the exception but didn't have catch or finally blocks).
> In any case I think we should hold off this debate until
> 1.7 (if <try/catch> why not <if> ?).
fine with me.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by peter reilly <pe...@corvil.com>.
On Friday 19 September 2003 07:50, Stefan Bodewig wrote:
> On Thu, 18 Sep 2003, Steve Loughran <st...@iseran.com> wrote:
> > I'd also like Ant 1.6 to have try/catch; if we cannot easily reuse
> > the ant contrib one,
>
> Have we even tried to?
The issue was getting permission from the author. (One
Stefan Bodewig with mods by Dan Ritchey from the javadoc).
In any case I think we should hold off this debate until
1.7 (if <try/catch> why not <if> ?).
Peter
>
> > is it too hard to write our own?
>
> Given that I've written significant parts of the ant-contrib one, I'd
> say no. But the result would look very very close to the one in
> ant-contrib 8-)
>
> Stefan
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE]: Getting 1.6 out the door
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 18 Sep 2003, Steve Loughran <st...@iseran.com> wrote:
> I'd also like Ant 1.6 to have try/catch; if we cannot easily reuse
> the ant contrib one,
Have we even tried to?
> is it too hard to write our own?
Given that I've written significant parts of the ant-contrib one, I'd
say no. But the result would look very very close to the one in
ant-contrib 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by Steve Loughran <st...@iseran.com>.
Antoine Lévy-Lambert wrote:
> Hi,
> I would like to propose a release plan for voting :
> - features included in 1.6 : all the features currently present in head
> - freeze date for 1.6 branch : Monday, September 22 13:00 GMT
> - availability of ANT_16_B1 binaries : within one week of the freeze of the
> branch.
+1.
Before then I'd like to
-fix <csc> as previously discussed
-test <assert> support in java/junit to see it looks good.
I'd also like Ant 1.6 to have try/catch; if we cannot easily reuse the
ant contrib one, is it too hard to write our own?
> The exact time will depend on whether I will have trouble with practical
> issues from the build down to the signing of the jar files to the update of
> the web site, of bugzilla, ...
> - release manager : myself
>
> (I hope this is OK, although I am not a PMC member).
>
> So, if this release plan is voted, on Monday, September 22 I will create the
> ANT_16_BRANCH tag.
> The CVS Head will then become ant 1.7alpha
>
>
> Cheers,
>
> Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by peter reilly <pe...@corvil.com>.
On Wednesday 17 September 2003 12:59, Stefan Bodewig wrote:
> On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> > The <c:define.with.echo> element gets rejected in
> > UnknownElement#handleChildren() before
> > Antlib#addConfigured() is called for the <presetdef> element
> > of the antlib.
>
> I see. It seems we have a certain class of tasks with "what can be
> nested into the task depends on what has been nested into it before".
> <sequential> was the first with that problem and we fixed it by
> special casing TaskContainer.
>
> The way TaskContainer is treated here has always been a hack - well,
> most of the UnknownElement/RuntimeConfigurable combo is ;-) - and it
> sure felt better if we'd have a clean way to signal that an object
> needs to defer child creation. I now understand why you went the
> Taskcontaier route and would be OK with rejecting non AntlibInterface
> instances for now.
Ok I have modified Antlib.java to reject non AntlibInterface task
instances, will deal with types tomorrow.
Peter
>
> The alternative might by DynamicConfigurator which itself could defer
> the child creation.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE]: Getting 1.6 out the door
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> I wrote an Antlib with:
>
> public void addConfigured(AntlibInterface nestedTask) {
> System.out.println("Antlib: addConfigured");
> if (nestedTask instanceof Task) {
> setLocation(((Task) nestedTask).getLocation());
> }
> nestedTask.setURI(uri);
> nestedTask.setAntlibClassLoader(getClassLoader());
> if (nestedTask instanceof Task) {
> ((Task) nestedTask).perform();
> }
> }
>
> and tested it with an antlib:
>
> <antlib xmlns:c="ant:current">
> <presetdef name="define.with.echo">
> <typedef classtype="org.apache.tools.ant.taskdefs.Echo"/>
> </presetdef>
> <c:define.with.echo name="define.test"/>
> </antlib>
>
> The <c:define.with.echo> element gets rejected in
> UnknownElement#handleChildren() before
> Antlib#addConfigured() is called for the <presetdef> element
> of the antlib.
I see. It seems we have a certain class of tasks with "what can be
nested into the task depends on what has been nested into it before".
<sequential> was the first with that problem and we fixed it by
special casing TaskContainer.
The way TaskContainer is treated here has always been a hack - well,
most of the UnknownElement/RuntimeConfigurable combo is ;-) - and it
sure felt better if we'd have a clean way to signal that an object
needs to defer child creation. I now understand why you went the
Taskcontaier route and would be OK with rejecting non AntlibInterface
instances for now.
The alternative might by DynamicConfigurator which itself could defer
the child creation.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by peter reilly <pe...@corvil.com>.
On Wednesday 17 September 2003 12:22, Stefan Bodewig wrote:
> On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
>
>
> > I have done some more investigation. The reason why using defined
> > definitions do not work unless antlib is an taskcontainer is
> > UnknownElement#handleChildren. This loops tru the all unknown
> > elements and checks if the parent can handle them. After
> > handleChildren is called, the maybeConfigure is called which invokes
> > the defines if addConfigured(AntlibInterface) is used in antLib.
>
> So you need to supress/delay the invocation? I'm not sure I follow
> you, sorry.
Sorry my description was a little incoherent.
I wrote an Antlib with:
public void addConfigured(AntlibInterface nestedTask) {
System.out.println("Antlib: addConfigured");
if (nestedTask instanceof Task) {
setLocation(((Task) nestedTask).getLocation());
}
nestedTask.setURI(uri);
nestedTask.setAntlibClassLoader(getClassLoader());
if (nestedTask instanceof Task) {
((Task) nestedTask).perform();
}
}
and tested it with an antlib:
<antlib xmlns:c="ant:current">
<presetdef name="define.with.echo">
<typedef classtype="org.apache.tools.ant.taskdefs.Echo"/>
</presetdef>
<c:define.with.echo name="define.test"/>
</antlib>
The <c:define.with.echo> element gets rejected in
UnknownElement#handleChildren() before
Antlib#addConfigured() is called for the <presetdef> element
of the antlib.
Peter
>
> > A fix could be to keep antlib being a task container, but check
> > if the type of task/type is a AntlibInterface, and if not, to
> > reject the task/type.
>
> I don't think so. To me it seems that it should be possible for
> <antlib> to accept arbitrary AntlibInterface instances as children
> without resorting to TaskContainer. If Antlib can't do that, it feels
> as if something was not right ATM.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE]: Getting 1.6 out the door
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 17 Sep 2003, peter reilly <pe...@corvil.com> wrote:
[Stefan writes story about classes being loaded multiple times by the
same classloader but via different paths]
> Yikes!
To be fair, I should add that the <classloader> implementation doesn't
work for class loaders that are not AntClassLoaders, so you won't be
able to manipulate the system classloader - but the issues would be
the same.
> I have done some more investigation. The reason why using defined
> definitions do not work unless antlib is an taskcontainer is
> UnknownElement#handleChildren. This loops tru the all unknown
> elements and checks if the parent can handle them. After
> handleChildren is called, the maybeConfigure is called which invokes
> the defines if addConfigured(AntlibInterface) is used in antLib.
So you need to supress/delay the invocation? I'm not sure I follow
you, sorry.
> A fix could be to keep antlib being a task container, but check
> if the type of task/type is a AntlibInterface, and if not, to
> reject the task/type.
I don't think so. To me it seems that it should be possible for
<antlib> to accept arbitrary AntlibInterface instances as children
without resorting to TaskContainer. If Antlib can't do that, it feels
as if something was not right ATM.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by peter reilly <pe...@corvil.com>.
On Wednesday 17 September 2003 10:51, Stefan Bodewig wrote:
> On Mon, 15 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> >> In particular, I'm not too fond of the completely undocumented
> >> <classloader> task.
> >
> > It would be nice to get this fixed.
>
> I rather opposed to the idea of adding stuff to a class loader that
> has been used before - especially for the system classloader. I'm not
> sure whether there is something that could be fixed.
>
> <classloader> gets you into a position where you load the same class
> twice.
>
> <taskdef resource="...">
> <classpath>
> <pathelement location="my-tasks.jar"/>
> </classpath>
> </taskdef>
>
> and later you go and add my-tasks.jar to the system class loader via
> <classloader>. Suddenly the class is available in the same
> classloader twice (the one that loaded the tasks in <taskdef>) and
> some of them have already been loaded - and not from the system
> classloader that will be used in subsequent attempts.
Yikes!
>
> I'd rather stay away from this completely.
For 1.6 we should.
>
> >> Peter, we will have to get this "why is <antlib> a taskcontainer"
> >> question sorted out soon ;-)
> >
> > Like I said before, it is nice that one can use definers defined
> > in the same antlib.xml.
>
> I agree with this.
>
> > Having <antlib/> as a taskcontainer also allows arbitarary tasks
> > to be run, which may be an good or bad thing......
>
> I tend to see this as a bad thing. IMHO <antlib> should declare new
> elements, it should not send mails to the creator of the classes, scp
> the /etc/passwd file around or just simply compile stuff.
>
> It's not because it can be abused (even if my examples make it look
> like that was my concern) - I want to see the concerns separated
> properly. <antlib>'s job is not to compile tasks, that's what we use
> <javac> for. All it has to do is declaring element name to class
> mappings. Defining definers also creates such a new mapping.
I have done some more investigation.
The reason why using defined definitions do not work unless
antlib is an taskcontainer is UnknownElement#handleChildren. This
loops tru the all unknown elements and checks if the parent can
handle them. After handleChildren is called, the maybeConfigure
is called which invokes the defines if addConfigured(AntlibInterface)
is used in antLib.
A fix could be to keep antlib being a task container, but check
if the type of task/type is a AntlibInterface, and if not, to
reject the task/type.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 18 Sep 2003, Conor MacNeill <co...@cortexebusiness.com.au>
wrote:
> Since Costin has not chimed in, it is worth reading this message and
> Costin's followup
Interesting, you are raising the same point as me 8-)
The situation could be "fixed", if AntClassLoader would know whether
it has loaded any class/resource - and <classloader> would only work
on instances that haven't loaded anything yet.
This would take away the power to modify the core loader, of course -
but since the core loader doesn't have to be an AntClassLoader
instance and never is AFAICS, the task wouldn't work on that anyway.
The task as is may be useful to some but will cause more problems that
good for the uninitiated - thus I'd rather not like to see it in Ant's
core distribution. There is nothing in that task that would make it
unusable if it came from a different jar/antlib.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
On Wed, 17 Sep 2003 07:51 pm, Stefan Bodewig wrote:
> On Mon, 15 Sep 2003, peter reilly <pe...@corvil.com> wrote:
> >> In particular, I'm not too fond of the completely undocumented
> >> <classloader> task.
> >
> > It would be nice to get this fixed.
>
> I rather opposed to the idea of adding stuff to a class loader that
> has been used before - especially for the system classloader. I'm not
> sure whether there is something that could be fixed.
>
> <classloader> gets you into a position where you load the same class
> twice.
>
> <taskdef resource="...">
> <classpath>
> <pathelement location="my-tasks.jar"/>
> </classpath>
> </taskdef>
>
> and later you go and add my-tasks.jar to the system class loader via
> <classloader>. Suddenly the class is available in the same
> classloader twice (the one that loaded the tasks in <taskdef>) and
> some of them have already been loaded - and not from the system
> classloader that will be used in subsequent attempts.
>
> I'd rather stay away from this completely.
>
Since Costin has not chimed in, it is worth reading this message and Costin's
followup
http://marc.theaimsgroup.com/?l=ant-dev&m=104080215031773&w=2
In general, I'm not very comfortable with the <classloader> task as it can
cause untold havoc and subtle errors. Costin's counterpoint is that it is
perhaps useful for advanced users - this may have merit.
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 15 Sep 2003, peter reilly <pe...@corvil.com> wrote:
>> In particular, I'm not too fond of the completely undocumented
>> <classloader> task.
>
> It would be nice to get this fixed.
I rather opposed to the idea of adding stuff to a class loader that
has been used before - especially for the system classloader. I'm not
sure whether there is something that could be fixed.
<classloader> gets you into a position where you load the same class
twice.
<taskdef resource="...">
<classpath>
<pathelement location="my-tasks.jar"/>
</classpath>
</taskdef>
and later you go and add my-tasks.jar to the system class loader via
<classloader>. Suddenly the class is available in the same
classloader twice (the one that loaded the tasks in <taskdef>) and
some of them have already been loaded - and not from the system
classloader that will be used in subsequent attempts.
I'd rather stay away from this completely.
>> Peter, we will have to get this "why is <antlib> a taskcontainer"
>> question sorted out soon ;-)
>
> Like I said before, it is nice that one can use definers defined
> in the same antlib.xml.
I agree with this.
> Having <antlib/> as a taskcontainer also allows arbitarary tasks
> to be run, which may be an good or bad thing......
I tend to see this as a bad thing. IMHO <antlib> should declare new
elements, it should not send mails to the creator of the classes, scp
the /etc/passwd file around or just simply compile stuff.
It's not because it can be abused (even if my examples make it look
like that was my concern) - I want to see the concerns separated
properly. <antlib>'s job is not to compile tasks, that's what we use
<javac> for. All it has to do is declaring element name to class
mappings. Defining definers also creates such a new mapping.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by peter reilly <pe...@corvil.com>.
On Friday 12 September 2003 11:18, Stefan Bodewig wrote:
> On Fri, 12 Sep 2003, Antoine Lévy-Lambert <an...@antbuild.com>
>
> wrote:
> > - features included in 1.6 : all the features currently present in
> > head
+1
>
> +0
>
> In particular, I'm not too fond of the completely undocumented
> <classloader> task.
It would be nice to get this fixed.
>
> Peter, we will have to get this "why is <antlib> a taskcontainer"
> question sorted out soon ;-)
Like I said before, it is nice that one can use definers defined
in the same antlib.xml.
Having <antlib/> as a taskcontainer also allows arbitarary tasks
to be run, which may be an good or bad thing......
Peter
>
> > - freeze date for 1.6 branch : Monday, September 22 13:00 GMT
>
> which is rather soon given the number of open bug reports. But we
> have to get ready sometime.
>
> > - availability of ANT_16_B1 binaries : within one week of the freeze
> > of the branch.
>
> Oops. Again, given the number of open reports, this is really soon.
>
> May I suggest to create the 1.6 branch and limit it to bug fixing and
> doc changes but push the first beta at least one more week out.
> Otherwise we'll need quite a few betas before we are happy with the
> release, I'm afraid.
>
> > - release manager : myself
> >
> > (I hope this is OK, although I am not a PMC member).
>
> Fine with me, even though it may put you into the stange position that
> the release manager's vote on the release itself is not binding -
> technically.
>
> Ping me if you need help.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE]: Getting 1.6 out the door
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 12 Sep 2003, Antoine Lévy-Lambert <an...@antbuild.com>
wrote:
> - features included in 1.6 : all the features currently present in
> head
+0
In particular, I'm not too fond of the completely undocumented
<classloader> task.
Peter, we will have to get this "why is <antlib> a taskcontainer"
question sorted out soon ;-)
> - freeze date for 1.6 branch : Monday, September 22 13:00 GMT
which is rather soon given the number of open bug reports. But we
have to get ready sometime.
> - availability of ANT_16_B1 binaries : within one week of the freeze
> of the branch.
Oops. Again, given the number of open reports, this is really soon.
May I suggest to create the 1.6 branch and limit it to bug fixing and
doc changes but push the first beta at least one more week out.
Otherwise we'll need quite a few betas before we are happy with the
release, I'm afraid.
> - release manager : myself
>
> (I hope this is OK, although I am not a PMC member).
Fine with me, even though it may put you into the stange position that
the release manager's vote on the release itself is not binding -
technically.
Ping me if you need help.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE]: Getting 1.6 out the door
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
+1
i have no spare cycles in this timeframe (or the rest of this year
even) to devote to this release unless something is really pressing.
i would have loved the xdocs stuff gain momentum and be used, but by no
means should it hold up a release.
On Friday, September 12, 2003, at 05:58 AM, Antoine Lévy-Lambert wrote:
> Hi,
> I would like to propose a release plan for voting :
> - features included in 1.6 : all the features currently present in head
> - freeze date for 1.6 branch : Monday, September 22 13:00 GMT
> - availability of ANT_16_B1 binaries : within one week of the freeze
> of the
> branch.
> The exact time will depend on whether I will have trouble with
> practical
> issues from the build down to the signing of the jar files to the
> update of
> the web site, of bugzilla, ...
> - release manager : myself
>
> (I hope this is OK, although I am not a PMC member).
>
> So, if this release plan is voted, on Monday, September 22 I will
> create the
> ANT_16_BRANCH tag.
> The CVS Head will then become ant 1.7alpha
>
>
> Cheers,
>
> Antoine
>
>
> ----- Original Message -----
> From: "Stefan Bodewig" <bo...@apache.org>
> To: <de...@ant.apache.org>
> Sent: Friday, August 29, 2003 2:08 PM
> Subject: Re: Getting 1.6 out the door
>
>
>> Peter is currently on vacation, I hope he'll be back soon enough to
>> chime in.
>>
>> On Thu, 28 Aug 2003, Conor MacNeill <co...@cortexebusiness.com.au>
>> wrote:
>>
>>> There will probably be a 1.6.1 release in between to clean up any
>>> issues we discover in 1.6
>>
>> Maybe we should consequentyl call the first 1.6 release 1.6.0 then?
>>
>>> 2. antlib
>>>
>>> I think this should be in
>>
>> yes.
>>
>>> but I am not familiar with its state yet,
>>
>> I'm not happy with some code details but the overal functionality is
>> there. We should be able to properly document it and see whether we
>> all can agree that this is the antlib functionality we want. If we
>> agree on it, we should put it into 1.6 - changing implementation
>> details would be like fixing bugs IMHO.
>>
>>> nor do I think it has had enough testing
>>
>> Of course not.
>>
>>> Are we planning to antlib Ant's own optional jars?
>>
>> Not in 1.6(.0) IMHO.
>>
>>> In 1.7 I think we need to look at removing antlibs from the root
>>> loader when their dependent jars are not available in ANT_HOME/lib.
>>
>> Yes.
>>
>>> Comments?
>>
>> The permissions stuff is causing some problems and we need to get the
>> new Launcher tested in a wider audience. Gump doesn't use it, it
>> still uses Main as its entry point and switching it to use Launcher
>> will cause a lot of problems (if we do it right and don't cheat by
>> adding ant.jar to CLASSPATH, that is).
>>
>> Stefan
>>
>
>
> ---------------------------------------------------------------------
> 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