You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2003/06/03 16:36:08 UTC
Jar Versions for an upcoming 2.3 rc
Hi,
I'm starting to work on some sort of release preparation for the
Turbine 2.3 code base. I did some checks on the jars that we use.
Currently we still depend on the following non-released or outdated
jars:
What We have Available Newer Version
on ibiblio?
commons-codec 1.0-dev 1.1 no
commons-configuration 20030311.152757 0.8.1 *1) no
commons-email 20030310.165926 no, sandbox yes
commons-fileupload 1.0-beta-1 1.0-beta-1 yes
commons-logging 1.0.2 1.0.3 yes
ecs 1.4.1 1.4.2 RC *5) no
javamail 1.3 1.3.1 *6) no
log4j 1.2.7 1.2.8 yes
stratum 1.0-b3 1.0-b3 *2) yes
torque 20030310.174947 3.1-alpha1 yes
velocity 1.3 1.3.1 yes
village 2.0-dev-20021111 2.0-dev-20021111 *3) yes
xalan 2.1.0 2.5.0 no
xerces 2.0.2 2.4.0 no
xerces (xmlParserAPIs) 2.0.2 *7) no
xmlrpc 1.2-a2 1.2-b1 *4) no
* 1) Eric is pushing for an 1.0 release in the commons proper. We
should definitely wait for this.
* 2) Any newer release unlikely, it is much more likely that stratum
will simply disappear post the turbine-2.3 release
* 3) Unlikely that there will ever be more work on this. Village seems to
be abandoned.
* 4) Some minor changes in CVS HEAD post 1.2-b1
* 5) The 1.4.2 release is pretty soon now. It contains some bug fixes and
should be considered.
* 6) Early Access Release available. Only bug fixes, no show stopper.
* 7) We should clean up the confusion around this jar and then add the correct
one.
This keeps us with the following groups of jars:
a) the easy ones: velocity, commons-logging, log4j
I committed the updates to the CVS. The tree still builds. ;-)
b) the missing ones: commons-codec, xalan, xerces
Newer versions are available but need to be pushed onto ibiblio.
Who is willing to do the grunt work to persuade the powers that
be to upload these jars?
c) The beta ones: commons-configuration, commons-email, commons-fileupload,
ecs, torque, xmlrpc
- c-c: Eric is pushing for an 1.0 release in commons-proper
My suggestion: I'm +1 on waiting for this
- c-e: "the usual suspects" (Daniel, JvZ, Jon, dIOn), no code changes
since two months. As the package is called "o.a.commons.mail", maybe
a release as "commons-mail" at some point later.
My suggestion: release with the snapshot jar. Alpha, Beta or
proper release highly unlikely unless any of
the current developer steps up and says otherwise.
- c-f: "the usual suspects" + some more developers. In beta stage
for over three months. Some work currently going on, some
CVS comments suggest an upcoming release candidate.
My suggestion: As we're waiting for commons-configuration, we
might sit tight as well on this. If we get an RC or even a
release in time, fine, if not, go with the beta.
- ecs Release 1.4.2 is right upon us. Robert suggested the 1.4.2
release any day now.
My suggestion: Wait for 1.4.2, then release with it.
- torque In 3.1-alpha-1 stage for a while. No work for the last
three weeks. Unfortunately some interoperability issues
with 3.0 and 3.1 templates.
My suggestion: Force Martin to do a 3.1 release. ;-)
No, really, this should be Martins' call. I personally would
release with 3.1-alpha-1 and damn the torpedoes, because
we will have to live with 3.1 and post-3.1 templates for
some time with turbine-2.3
The 2.3 code base builds and works with the 3.1-alpha-1 templates.
- xml-rpc The 1.2-b1 version (just as 1.2-a2 and a3) contain quite
some bug fixes. There is no visible schedule for a
1.2 release and no work on the repository for some time
(besides incorporating the codec release).
My suggestion: Release with the 1.2-b1 jar
d) the hopeless ones: village, stratum
- No releases planned or likely, no work happening on
the code bases.
My suggestion: Go with what we have, starting to fade
this code out.
e) the strange ones: xerces, xmlParserAPIs
- Clean up the confusion around the jars, get the most
current ones on ibiblio, release with the most current
release versions.
Please comment. I'd like to release with current jars because most
people starting to develop with Turbine 2.3 will copy the project.xml
file from turbine into their project. So we should have some up to
date jars here.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Jar Versions for an upcoming 2.3 rc
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Martin Poeschl" <mp...@marmot.at> writes:
>> Another thing (which might be more relevant to the Torque lists) that
>> came to my mind: As the village codebase itself seems to be dead, why
>> not move the relevant classes to Torque and start integrating them
>> more tightly to Torque. I know of some people who use torque and are
>> quite fed up with village.
>start a vote on the torque list and you'll get my +1
I'd say that this might be the call of the working-dogs / Whichever
Group people to allow us to move their code under an Apache umbrella.
Jon?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Jar Versions for an upcoming 2.3 rc
Posted by Martin Poeschl <mp...@marmot.at>.
> "Martin Poeschl" <mp...@marmot.at> writes:
>
>
>>> No, really, this should be Martins' call. I personally would
>>> release with 3.1-alpha-1 and damn the torpedoes, because
>>> we will have to live with 3.1 and post-3.1 templates for
>>> some time with turbine-2.3
>>>
>>> The 2.3 code base builds and works with the 3.1-alpha-1
>>> templates.
>
> Ah, that's cool. But the -alpha-1 still uses stratum, doesn't it? As
> far as I can see, as soon as Torque doesn't use stratum any longer,
> only the component service is left as a stratum user.
i'm just finishing the 3.0.1 release .. next step is to migrate HEAD to
avalon and to release a 3.1-beta1 ...
>
>>torque 3.1 should use the avalon interfaces instead of the stratum
>>versions .. after this change we can do a release ...
>>i haven't looked at the avalon component service .. so any help is
>> welcome
>>;-)
>
>>> d) the hopeless ones: village, stratum
>>>
>>> - No releases planned or likely, no work happening on
>>> the code bases.
>>>
>>> My suggestion: Go with what we have, starting to fade
>>> this code out.
>
>>all stratum stuff should be deprecated in 2.3!!
>
> If we get your avalon bases torque in time, we can deprecate the whole
> component service. It's main job is to get Torque running (and there
> are a few diehards that use Fulcrum with the 2.x core code). I'm all
> +1 on this.
>
> Another thing (which might be more relevant to the Torque lists) that
> came to my mind: As the village codebase itself seems to be dead, why
> not move the relevant classes to Torque and start integrating them
> more tightly to Torque. I know of some people who use torque and are
> quite fed up with village.
start a vote on the torque list and you'll get my +1
>
> Jon, are you still with us? Can you tell us something about the Torque
> future?
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Jar Versions for an upcoming 2.3 rc
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Martin Poeschl" <mp...@marmot.at> writes:
>> Hi,
>>
>> I'm starting to work on some sort of release preparation for the
>> Turbine 2.3 code base. I did some checks on the jars that we use.
>>
>> - torque In 3.1-alpha-1 stage for a while. No work for the last
>> three weeks. Unfortunately some interoperability issues
>> with 3.0 and 3.1 templates.
>>
>> My suggestion: Force Martin to do a 3.1 release. ;-)
>no problem .. i'll send my account number for donations ;-)
>> No, really, this should be Martins' call. I personally would
>> release with 3.1-alpha-1 and damn the torpedoes, because
>> we will have to live with 3.1 and post-3.1 templates for
>> some time with turbine-2.3
>>
>> The 2.3 code base builds and works with the 3.1-alpha-1
>> templates.
Ah, that's cool. But the -alpha-1 still uses stratum, doesn't it? As
far as I can see, as soon as Torque doesn't use stratum any longer,
only the component service is left as a stratum user.
>torque 3.1 should use the avalon interfaces instead of the stratum
>versions .. after this change we can do a release ...
>i haven't looked at the avalon component service .. so any help is welcome
>;-)
>> d) the hopeless ones: village, stratum
>>
>> - No releases planned or likely, no work happening on
>> the code bases.
>>
>> My suggestion: Go with what we have, starting to fade
>> this code out.
>all stratum stuff should be deprecated in 2.3!!
If we get your avalon bases torque in time, we can deprecate the whole
component service. It's main job is to get Torque running (and there
are a few diehards that use Fulcrum with the 2.x core code). I'm all
+1 on this.
Another thing (which might be more relevant to the Torque lists) that
came to my mind: As the village codebase itself seems to be dead, why
not move the relevant classes to Torque and start integrating them
more tightly to Torque. I know of some people who use torque and are
quite fed up with village.
Jon, are you still with us? Can you tell us something about the Torque
future?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Jar Versions for an upcoming 2.3 rc
Posted by Martin Poeschl <mp...@marmot.at>.
> Hi,
>
> I'm starting to work on some sort of release preparation for the
> Turbine 2.3 code base. I did some checks on the jars that we use.
>
> - torque In 3.1-alpha-1 stage for a while. No work for the last
> three weeks. Unfortunately some interoperability issues
> with 3.0 and 3.1 templates.
>
> My suggestion: Force Martin to do a 3.1 release. ;-)
no problem .. i'll send my account number for donations ;-)
> No, really, this should be Martins' call. I personally would
> release with 3.1-alpha-1 and damn the torpedoes, because
> we will have to live with 3.1 and post-3.1 templates for
> some time with turbine-2.3
>
> The 2.3 code base builds and works with the 3.1-alpha-1
> templates.
torque 3.1 should use the avalon interfaces instead of the stratum
versions .. after this change we can do a release ...
i haven't looked at the avalon component service .. so any help is welcome
;-)
> d) the hopeless ones: village, stratum
>
> - No releases planned or likely, no work happening on
> the code bases.
>
> My suggestion: Go with what we have, starting to fade
> this code out.
all stratum stuff should be deprecated in 2.3!!
>
> Please comment. I'd like to release with current jars because most
> people starting to develop with Turbine 2.3 will copy the project.xml
> file from turbine into their project. So we should have some up to
> date jars here.
+1
martin
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Jar Versions for an upcoming 2.3 rc
Posted by Quinton McCombs <qm...@nequalsone.com>.
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Tuesday, June 03, 2003 9:36 AM
> To: turbine-dev@jakarta.apache.org
> Subject: Jar Versions for an upcoming 2.3 rc
>
>
> Hi,
>
> I'm starting to work on some sort of release preparation for the
> Turbine 2.3 code base. I did some checks on the jars that we use.
>
> Currently we still depend on the following non-released or outdated
> jars:
>
> What We have Available
> Newer Version
>
> on ibiblio?
>
> commons-codec 1.0-dev 1.1
> no
> commons-configuration 20030311.152757 0.8.1 *1)
> no
> commons-email 20030310.165926 no, sandbox
> yes
> commons-fileupload 1.0-beta-1 1.0-beta-1
> yes
> commons-logging 1.0.2 1.0.3
> yes
> ecs 1.4.1 1.4.2 RC *5)
> no
> javamail 1.3 1.3.1 *6)
> no
> log4j 1.2.7 1.2.8
> yes
> stratum 1.0-b3 1.0-b3
> *2) yes
> torque 20030310.174947
> 3.1-alpha1 yes
> velocity 1.3 1.3.1
> yes
> village 2.0-dev-20021111
> 2.0-dev-20021111 *3) yes
> xalan 2.1.0 2.5.0
> no
> xerces 2.0.2 2.4.0
> no
> xerces (xmlParserAPIs) 2.0.2 *7)
> no
> xmlrpc 1.2-a2 1.2-b1
> *4) no
>
> * 1) Eric is pushing for an 1.0 release in the commons proper. We
> should definitely wait for this.
>
> * 2) Any newer release unlikely, it is much more likely that stratum
> will simply disappear post the turbine-2.3 release
>
> * 3) Unlikely that there will ever be more work on this.
> Village seems to
> be abandoned.
>
> * 4) Some minor changes in CVS HEAD post 1.2-b1
>
> * 5) The 1.4.2 release is pretty soon now. It contains some
> bug fixes and
> should be considered.
>
> * 6) Early Access Release available. Only bug fixes, no show stopper.
>
> * 7) We should clean up the confusion around this jar and
> then add the correct
> one.
>
> This keeps us with the following groups of jars:
>
> a) the easy ones: velocity, commons-logging, log4j
>
> I committed the updates to the CVS. The tree still builds. ;-)
Extensive testing... ;-)
> b) the missing ones: commons-codec, xalan, xerces
>
> Newer versions are available but need to be pushed onto ibiblio.
> Who is willing to do the grunt work to persuade the powers that
> be to upload these jars?
I would but I have no time right now.
> c) The beta ones: commons-configuration, commons-email,
> commons-fileupload,
> ecs, torque, xmlrpc
>
> - c-c: Eric is pushing for an 1.0 release in commons-proper
>
> My suggestion: I'm +1 on waiting for this
+1 on the wait as well.
> - c-e: "the usual suspects" (Daniel, JvZ, Jon, dIOn), no
> code changes
> since two months. As the package is called
> "o.a.commons.mail", maybe
> a release as "commons-mail" at some point later.
>
> My suggestion: release with the snapshot jar. Alpha, Beta or
> proper release highly unlikely unless any of
> the current developer steps up and
> says otherwise.
+1 on releasing with the snapshot.
The code is stable and well tested. Although there are no unit tests in
the CVS repo, I have them. The problem is that they actually send the
emails.
I don't really have the time to go through the process of getting it
promoted into commons proper. It is ready for release, IMHO.
> - c-f: "the usual suspects" + some more developers. In beta stage
> for over three months. Some work currently going on, some
> CVS comments suggest an upcoming release candidate.
>
> My suggestion: As we're waiting for
> commons-configuration, we
> might sit tight as well on this. If we get an RC or even a
> release in time, fine, if not, go with the beta.
+1
> - ecs Release 1.4.2 is right upon us. Robert suggested the 1.4.2
> release any day now.
>
> My suggestion: Wait for 1.4.2, then release with it.
+1
>
> - torque In 3.1-alpha-1 stage for a while. No work for the last
> three weeks. Unfortunately some interoperability issues
> with 3.0 and 3.1 templates.
> My suggestion: Force Martin to do a 3.1 release. ;-)
> No, really, this should be Martins' call. I personally would
> release with 3.1-alpha-1 and damn the torpedoes, because
> we will have to live with 3.1 and post-3.1 templates for
> some time with turbine-2.3
+0. I am okay with releasing with alpha-1 as long the final version is
not released before we complete our alpha stage.
> The 2.3 code base builds and works with the
> 3.1-alpha-1 templates.
>
> - xml-rpc The 1.2-b1 version (just as 1.2-a2 and a3) contain quite
> some bug fixes. There is no visible schedule for a
> 1.2 release and no work on the repository for some time
> (besides incorporating the codec release).
>
> My suggestion: Release with the 1.2-b1 jar
+1
> d) the hopeless ones: village, stratum
>
> - No releases planned or likely, no work happening on
> the code bases.
>
> My suggestion: Go with what we have, starting to fade
> this code out.
+1
> e) the strange ones: xerces, xmlParserAPIs
>
> - Clean up the confusion around the jars, get the most
> current ones on ibiblio, release with the most current
> release versions.
+1
> Please comment. I'd like to release with current jars because most
> people starting to develop with Turbine 2.3 will copy the project.xml
> file from turbine into their project. So we should have some up to
> date jars here.
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org