( I just replied using the wrong from: address, so it probably wont go
through. lets try again)
Kev Jackson wrote:
<classloader> to allow adding of jars to the current classloader
(would solve a /lot/ of problems at the cost of some
issues)[peter] (status RE "some issues" risk? -MJB)
Primarily, it can cause fun with IDEs.
*
Junit 4 integration to a level that Ant-dev and junit are happy.
Who can take care of what here ? Which are the key IDE bugs ?
I agree that this list as it stands is a little vague. Junit 4
integration would be another case of having special code to deal with a
Java5 environment.
I'm trying to set up a conf call with the junit team, to see how best to
go with the junit4 support. I am currently thinking
-<junit> stays 3.8.x only.
-we add a new junit antlib for junit4 support, design it to work on
1.6.5 and 1.7
-maybe hand off ownership of the antlib to the junit team, if they want
to gain that tight coupling and take on the costs.
>
So as part of the release target, openpgp is used to sign the archives
created - sounds good to me
Apache now requires signing by someone whose keys are cross
authenticated. We also need to push out beta JARs to the cvs.apache.org
maven1 repository, final ones to the big maven1/maven2 repo, with
half-decent .pom files. I can take ownership of creating all those pom
files if nobody else wants to take it on, as I use them a lot @work
(with ant, naturally)
- release instructions
the release instructions need to be updated for subversion. I never
created branches in subversion ...
Branching in svn is pretty easy, but as far as I know, svn does a lazy
copy - ie it doesn't copy files over to the branch until there's a
change recorded - just something to be aware of
- branches
we will need to decide if we will want to branch ant, and if yes when.
Experience from the 1.6 time showed that during a long time we did
double maintenance of 1.6 branch and HEAD.
We might want to delay the creation of a 1.7 branch until there is a say
at least 1.7.1 ...
- antlibs
do we want to release antunit, dotnet and svn antlibs at the same time ?
or parallel ?
Should each antlib be in principle like an independent project and have
its own release instructions ?
Since 1.7 is the first version to properly support antlibs, wouldn't it
make sense to release the first batch of ant libs at the same time, but
then after to have them on their own release schedules?
Seems good.
- dependencies of ant
we have removed from the build 4 external jars which were not to be
found anymore anywhere. Still, gathering the dependencies is a problem
for the release manager.
For instance to get the weblogic.jar I downloaded an eval version of
weblogic. (Lengthy process involving registration ...).
I have this jar if anyone needs it (WebLogic 8.1, I also have 9 too I
think). I agree that getting that particular jar is a pain - thankfully
we don't have any oracle dependencies - that website always makes me
want to kill kittens - I don't know how much user unfriendly they can be.
WL itself hurts. I know people hate jboss for its worst-in-class
classloader, but it doesnt make such a mess of your machine. Mind you,
I've never tried WebSphere.
Kev
---------------------------------------------------------------------
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]
