[Commons Wiki] Update of "BuildSystems" by ChristianGrobmeier
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "BuildSystems" page has been changed by ChristianGrobmeier: http://wiki.apache.org/commons/BuildSystems?action=diff&rev1=21&rev2=22 Comment: ognl supports m2 || math|| Yes || No|| Yes * || ? || || || modeler || Yes || Yes * || Yes || || || || net || No|| No|| Yes * || ? || || - || ognl|| No|| No|| No|| Yes * || || + || ognl|| No|| No|| Yes || Yes * || || || pool|| Yes || Yes || Yes || Yes * || last release(1.6) used m3 || || primitives || Yes || Yes * || Yes || || || || proxy || No|| No|| Yes * || || || - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Commons Wiki] Update of "BuildSystems" by ChristianGrobmeier
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "BuildSystems" page has been changed by ChristianGrobmeier: http://wiki.apache.org/commons/BuildSystems?action=diff&rev1=22&rev2=23 Comment: updated digester || daemon || Yes || No|| Yes * || || || || dbcp|| Yes || Yes * || Yes || || || || dbutils || No|| No|| Yes * || ? || || - || digester|| Yes || Yes * || Yes || || || + || digester|| No|| ? || Yes || Yes * || Runs with wagon-ssh extension, uses M3 since Digester 3 || || discovery || Yes || Yes * || Yes || || || || el || Yes || Yes * || Yes || || || || email || No|| No|| Yes * || || || - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[all] Move Jelly to dormant/orphaned?
Hello, Jelly did not see any activity for nearly two years: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly Last release was in 01.2010. We had already discussion on a process to move proper components into another state, be it "dormant" or "inactive". I would like to resurrect this discussion. We have had a lots of discussion in the past: somebody wanted to progress with somehting, like graduating graph or using Java 5 in a component and the response sometimes was we have to less man power at Commons. Therefore I think we need to tell the people for which components they can expect releases and for which ones not. Otherwise outsiders may look at a huge bunch of components and see only little activity. Wouldn't it be better instead to show only a handful components which are actively developed? Looking at Jelly, it is orphaned. No releases, no releases to be expected. I would like to move it to dormant or to a new transition state, if people wish so, maybe called "orphaned" or "inactive" or whatever. What are your thoughts? Cheers Christian -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT][VOTE] Release Commons Pool 1.6-RC3.
On 9 January 2012 06:35, Gary Gregory wrote: > On Sun, Jan 8, 2012 at 10:03 PM, sebb wrote: >> On 8 January 2012 21:55, Gary Gregory wrote: >>> Hi All: >>> >>> I am pushing out 1.6 and it's time to click release out of Nexus. I >>> see that there are a ton of files there and the instructions say to >>> remove *-bin* and *-src*. Ok fine, I delete those one at a time, no >>> multiple selection allowed, one annoyance. >> >> Hopefully you copied them first, as they are needed for dist. > > They are already in /x1/www/www.apache.org/content/dist/commons/pool/ > OK. >> >>> Then I think to myself, hm, are the instructions complete? So I look >>> at what 1.5.7 files are in Maven Central and I notice that there are >>> no sha1 or md5 files. >> >> AFAIK, Maven does normally contain md5 and sha1 - see for example: >> >> http://repo1.maven.org/maven2/org/apache/commons/commons-jexl/2.1.1/ >> >>> So what do I, silly me? I delete them! When I then click release in >>> Nexus, I get: >>> >>> Staging ruleset evaluation on repository 'org.apache.commons-012 >>> (u:ggregory, a:24.250.160.61)' has failed. >>> >>> Staging Checksum Validation >>> >>> -Missing SHA1: >>> '/commons-pool/commons-pool/1.6/commons-pool-1.6.jar.sha1'. >>> -Missing MD5: '/commons-pool/commons-pool/1.6/commons-pool-1.6.jar.md5.' >>> -Missing SHA1: >>> '/commons-pool/commons-pool/1.6/commons-pool-1.6-javadoc.jar.sha1'. >>> -Missing MD5: >>> '/commons-pool/commons-pool/1.6/commons-pool-1.6-javadoc.jar.md5.' >>> -Missing SHA1: >>> '/commons-pool/commons-pool/1.6/commons-pool-1.6.pom.sha1'. >>> -Missing MD5: '/commons-pool/commons-pool/1.6/commons-pool-1.6.pom.md5.' >>> -Missing SHA1: >>> '/commons-pool/commons-pool/1.6/commons-pool-1.6-sources.jar.sha1'. >>> -Missing MD5: >>> '/commons-pool/commons-pool/1.6/commons-pool-1.6-sources.jar.md5.' >>> >>> !$#$@# I can't believe I shot myself in the foot! >>> >>> I have the sha1 and md5 files on my people.apache.org home dir. >>> >>> Can I copy them to Nexus? >> >> I don't think you can update the staging repo once it is closed. >> >> However, you may be able to create a new one using the existihg files, >> by using the Nexus Staging Upload feature. >> Create a bundle that contains copies of all the Maven files from Nexus >> + the recovered hashes. >> You can try using the Maven Repository plugin, but I had problems with >> that; it may be simpler to create the jar file manually. >> >> Or you can upload each file singly, but that quickly becomes boring... > > Here is what I did: All the files we voted on were copied from Nexus > (before I deleted the sha1's and md5's) with wget to my people.a.o > home dir per the wiki instructions. > > I copied them from my home dir down to my local machine. Then I used > the Nexus Staging Upload feature to upload the POM, and jars. The > files have been uploading for five minutes now which is very long. I'm > going to let it upload while I sleep and check in the AM (EST). > > If that does not work, I'll drop the previous repo and try again. If > that does not work, then I'm stuck with an RC4. Arg. As I already wrote, the vote was on the current staging repo. If you release from a new staging repo, then the vote is invalid. So I think you need to tie the files in the new staging area to the old staging area; you can do this by getting agreement on which sigs were used. But this *must* be done before deleting the staging area that was voted on. > Gary > > >> >> Nexus may prevent you from creating a new staging repo until you have >> dropped the old one. >> If so, be very careful not to delete the files till you have secured copies. >> >> The problem arises - how can you prove that the artifacts you release >> are the ones we voted on? >> Unless there is a valid PMC vote, the RM is personally responsible for >> the content of the release. >> That's not a risk I would be willing to take, but YMMV. >> >> It's a pity that you did not include hashes (or sigs) of the files in >> the vote e-mail, as that would be a way to prove that the voted-on >> artifacts were the ones that were re-staged. >> >> One possibility would be to add the .asc files to the vote e-mail, and >> ask the original voters to confirm that these correspond with the .asc >> files they voted on (i.e. the current contents of the Nexus staging >> repo). >> >>> Gary >>> >>> On Sun, Jan 8, 2012 at 12:42 PM, Gary Gregory >>> wrote: This vote passes with 5 +1s from the PMC: Simone Tripodi Oliver Heger Christian Grobmeier Jörg Schaible Gary Gregory No other votes were cast. Cheers, Gary On Wed, Jan 4, 2012 at 2:20 PM, Gary Gregory wrote: > Good day to you all: > > I have prepared Commons Pool 1.6-RC3. > > The only change from RC2 is that the build was run from a clean SVN > checkout > to avoid issues with using a mixed-revision working copy. > > The only changes from 1.5.7 are the addi
Re: [ALL] Supported Buildsystems of each component
On 8 January 2012 20:51, Christian Grobmeier wrote: > Could you try maven site too? I can confirm it works, though I just ran "mvn site", excluding the deploy phase (for obvious reasons) which I'm pretty sure that is the most critical due to the use of scp. Furthermore I don't know if the latter is really a blocker. Please let me know if you need further tests Twitter :http://www.twitter.com/m_cucchiara G+ :https://plus.google.com/107903711540963855921 Linkedin:http://www.linkedin.com/in/mauriziocucchiara Maurizio Cucchiara
Re: [ALL] Supported Buildsystems of each component
On Mon, Jan 9, 2012 at 2:25 PM, Maurizio Cucchiara wrote: > On 8 January 2012 20:51, Christian Grobmeier wrote: >> Could you try maven site too? > > I can confirm it works, though I just ran "mvn site", excluding the deploy > phase (for obvious reasons) which I'm pretty sure that is the most critical > due to the use of scp. > Furthermore I don't know if the latter is really a blocker. > Please let me know if you need further tests I think thats fine so far thank you so much. WIll need to install m2 again to test some of the other components :( Cheers Christian > > Twitter :http://www.twitter.com/m_cucchiara > G+ :https://plus.google.com/107903711540963855921 > Linkedin :http://www.linkedin.com/in/mauriziocucchiara > > Maurizio Cucchiara -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Move Jelly to dormant/orphaned?
I think the whole formality of project state should be replaced with a live activity widget like can be seen on other sites. Commit activity and such. If someone were thinking of contributing to a project, the incentive would be removed or seriously diminished by a dead/sleepy project state. Gary On Jan 9, 2012, at 6:59, Christian Grobmeier wrote: > Hello, > > Jelly did not see any activity for nearly two years: > http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly > > Last release was in 01.2010. > > We had already discussion on a process to move proper components into > another state, be it "dormant" or "inactive". I would like to > resurrect this discussion. We have had a lots of discussion in the > past: somebody wanted to progress with somehting, like graduating > graph or using Java 5 in a component and the response sometimes was we > have to less man power at Commons. > > Therefore I think we need to tell the people for which components they > can expect releases and for which ones not. Otherwise outsiders may > look at a huge bunch of components and see only little activity. > Wouldn't it be better instead to show only a handful components which > are actively developed? > > Looking at Jelly, it is orphaned. No releases, no releases to be > expected. I would like to move it to dormant or to a new transition > state, if people wish so, maybe called "orphaned" or "inactive" or > whatever. > > What are your thoughts? > > Cheers > Christian > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Move Jelly to dormant/orphaned?
On Mon, Jan 9, 2012 at 3:42 PM, Gary Gregory wrote: > I think the whole formality of project state should be replaced with a > live activity widget like can be seen on other sites. Commit activity > and such. If someone were thinking of contributing to a project, the > incentive would be removed or seriously diminished by a dead/sleepy > project state. Interesting idea. You mean something like that? https://www.ohloh.net/p/commons-compress Any ideas how we can get this data out from svn? Probably besides svn an interesting metric is the number of discussion on ml. Question is how realistic is it we get something hacked together in for example ruby? Cheers Christian > > Gary > > On Jan 9, 2012, at 6:59, Christian Grobmeier wrote: > >> Hello, >> >> Jelly did not see any activity for nearly two years: >> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly >> >> Last release was in 01.2010. >> >> We had already discussion on a process to move proper components into >> another state, be it "dormant" or "inactive". I would like to >> resurrect this discussion. We have had a lots of discussion in the >> past: somebody wanted to progress with somehting, like graduating >> graph or using Java 5 in a component and the response sometimes was we >> have to less man power at Commons. >> >> Therefore I think we need to tell the people for which components they >> can expect releases and for which ones not. Otherwise outsiders may >> look at a huge bunch of components and see only little activity. >> Wouldn't it be better instead to show only a handful components which >> are actively developed? >> >> Looking at Jelly, it is orphaned. No releases, no releases to be >> expected. I would like to move it to dormant or to a new transition >> state, if people wish so, maybe called "orphaned" or "inactive" or >> whatever. >> >> What are your thoughts? >> >> Cheers >> Christian >> >> -- >> http://www.grobmeier.de >> https://www.timeandbill.de >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Move Jelly to dormant/orphaned?
On 9 January 2012 14:42, Gary Gregory wrote: > I think the whole formality of project state should be replaced with a > live activity widget like can be seen on other sites. Commit activity > and such. If someone were thinking of contributing to a project, the > incentive would be removed or seriously diminished by a dead/sleepy > project state. I think the activity widget could be counter-productive. Component activity tends to go in phases; there may be several weeks with no activity and then a flurry. Also commits are only a small part of the health of a component. Activity monitors can work well for frequently occuring activities, but component health is much more complicated. To take a simple example, try measuring committer productivity by SVN commits. Some committers commit large chunks, some commit per file; and that may vary for a committer. Some commits are not "productive" - e.g. whitespace fixes, reverts of a bad commit. Some commits represent lots of investigation and skill, some may be much simpler. > Gary > > On Jan 9, 2012, at 6:59, Christian Grobmeier wrote: > >> Hello, >> >> Jelly did not see any activity for nearly two years: >> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly >> >> Last release was in 01.2010. >> >> We had already discussion on a process to move proper components into >> another state, be it "dormant" or "inactive". I would like to >> resurrect this discussion. We have had a lots of discussion in the >> past: somebody wanted to progress with somehting, like graduating >> graph or using Java 5 in a component and the response sometimes was we >> have to less man power at Commons. >> >> Therefore I think we need to tell the people for which components they >> can expect releases and for which ones not. Otherwise outsiders may >> look at a huge bunch of components and see only little activity. >> Wouldn't it be better instead to show only a handful components which >> are actively developed? >> >> Looking at Jelly, it is orphaned. No releases, no releases to be >> expected. I would like to move it to dormant or to a new transition >> state, if people wish so, maybe called "orphaned" or "inactive" or >> whatever. >> >> What are your thoughts? >> >> Cheers >> Christian >> >> -- >> http://www.grobmeier.de >> https://www.timeandbill.de >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT][VOTE] Release Commons Pool 1.6-RC3.
On Mon, Jan 9, 2012 at 7:35 AM, sebb wrote:
> On 9 January 2012 06:35, Gary Gregory wrote:
>> On Sun, Jan 8, 2012 at 10:03 PM, sebb wrote:
>>> On 8 January 2012 21:55, Gary Gregory wrote:
Hi All:
I am pushing out 1.6 and it's time to click release out of Nexus. I
see that there are a ton of files there and the instructions say to
remove *-bin* and *-src*. Ok fine, I delete those one at a time, no
multiple selection allowed, one annoyance.
>>>
>>> Hopefully you copied them first, as they are needed for dist.
>>
>> They are already in /x1/www/www.apache.org/content/dist/commons/pool/
>>
> OK.
>
>>>
Then I think to myself, hm, are the instructions complete? So I look
at what 1.5.7 files are in Maven Central and I notice that there are
no sha1 or md5 files.
>>>
>>> AFAIK, Maven does normally contain md5 and sha1 - see for example:
>>>
>>> http://repo1.maven.org/maven2/org/apache/commons/commons-jexl/2.1.1/
>>>
So what do I, silly me? I delete them! When I then click release in
Nexus, I get:
Staging ruleset evaluation on repository 'org.apache.commons-012
(u:ggregory, a:24.250.160.61)' has failed.
Staging Checksum Validation
-Missing SHA1:
'/commons-pool/commons-pool/1.6/commons-pool-1.6.jar.sha1'.
-Missing MD5: '/commons-pool/commons-pool/1.6/commons-pool-1.6.jar.md5.'
-Missing SHA1:
'/commons-pool/commons-pool/1.6/commons-pool-1.6-javadoc.jar.sha1'.
-Missing MD5:
'/commons-pool/commons-pool/1.6/commons-pool-1.6-javadoc.jar.md5.'
-Missing SHA1:
'/commons-pool/commons-pool/1.6/commons-pool-1.6.pom.sha1'.
-Missing MD5: '/commons-pool/commons-pool/1.6/commons-pool-1.6.pom.md5.'
-Missing SHA1:
'/commons-pool/commons-pool/1.6/commons-pool-1.6-sources.jar.sha1'.
-Missing MD5:
'/commons-pool/commons-pool/1.6/commons-pool-1.6-sources.jar.md5.'
!$#$@# I can't believe I shot myself in the foot!
I have the sha1 and md5 files on my people.apache.org home dir.
Can I copy them to Nexus?
>>>
>>> I don't think you can update the staging repo once it is closed.
>>>
>>> However, you may be able to create a new one using the existihg files,
>>> by using the Nexus Staging Upload feature.
>>> Create a bundle that contains copies of all the Maven files from Nexus
>>> + the recovered hashes.
>>> You can try using the Maven Repository plugin, but I had problems with
>>> that; it may be simpler to create the jar file manually.
>>>
>>> Or you can upload each file singly, but that quickly becomes boring...
>>
>> Here is what I did: All the files we voted on were copied from Nexus
>> (before I deleted the sha1's and md5's) with wget to my people.a.o
>> home dir per the wiki instructions.
>>
>> I copied them from my home dir down to my local machine. Then I used
>> the Nexus Staging Upload feature to upload the POM, and jars. The
>> files have been uploading for five minutes now which is very long. I'm
>> going to let it upload while I sleep and check in the AM (EST).
>>
>> If that does not work, I'll drop the previous repo and try again. If
>> that does not work, then I'm stuck with an RC4. Arg.
>
> As I already wrote, the vote was on the current staging repo. If you
> release from a new staging repo, then the vote is invalid.
>
> So I think you need to tie the files in the new staging area to the
> old staging area; you can do this by getting agreement on which sigs
> were used.
What is the difference b/w a "staging area" and a "staging repo"? The
staging repo is the dir in Nexus after a deploy, that's clear.
It seems that I cannot update a closed repo, which makes sense, I
would not expect to be able to do that.
So the best I can do is create a new repo with the same files and
close, and release it./
Right now, I cannot even do that, the Nexus upload was stuck in a loop
for 6 hours over night, so I killed that one. I was trying to upload
the POM with attached atrifacts.
Now it is looping ("Uploading..." dialog) on uploading a bundle zip I
created myself which contains the same files we voted on.
So killed that and create a bundle the maven way instead of using
WinRar: mvn javadoc:jar source:jar repository:bundle-create
Now it is looping uploading that! I'm not lucky today.
This is an abject failure. :( blech.
The cleanest thing is to RC again.
Gary
> But this *must* be done before deleting the staging area that was voted on.
>
>> Gary
>>
>>
>>>
>>> Nexus may prevent you from creating a new staging repo until you have
>>> dropped the old one.
>>> If so, be very careful not to delete the files till you have secured copies.
>>>
>>> The problem arises - how can you prove that the artifacts you release
>>> are the ones we voted on?
>>> Unless there is a valid PMC vote, the RM is personally responsible for
>>> the content of the release.
>>> That's not a risk I would be willing to take, but YMMV.
>>>
>>> It's a pity tha
Re: [all] Move Jelly to dormant/orphaned?
On Mon, Jan 9, 2012 at 9:58 AM, sebb wrote:
> On 9 January 2012 14:42, Gary Gregory wrote:
>> I think the whole formality of project state should be replaced with a
>> live activity widget like can be seen on other sites. Commit activity
>> and such. If someone were thinking of contributing to a project, the
>> incentive would be removed or seriously diminished by a dead/sleepy
>> project state.
>
> I think the activity widget could be counter-productive.
>
> Component activity tends to go in phases; there may be several weeks
> with no activity and then a flurry.
> Also commits are only a small part of the health of a component.
>
> Activity monitors can work well for frequently occuring activities,
> but component health is much more complicated.
>
> To take a simple example, try measuring committer productivity by SVN commits.
> Some committers commit large chunks, some commit per file; and that
> may vary for a committer.
> Some commits are not "productive" - e.g. whitespace fixes, reverts of
> a bad commit.
> Some commits represent lots of investigation and skill, some may be
> much simpler.
The idea for me is to get a heartbeat representation, not hard
numbers; something that can be automatically generated. If we do
decide to change the state of a component, it should be a more serious
step. A project can look asleep and be fine IMO, ready to go again.
IMO a project should be alive or dead, all this formality for
in-between states ("dormant" and whatnot) is not helpful. As soon as
someone commits, it's not dormant, and I should not have to officially
wake up (with a vote?) a commons project before committing to it IMO.
Project states, if wanted, should be on the Wiki in a list, "this is
how we feel about projects, but a committer can still commit and do
work"
2c,
Gary
>
>> Gary
>>
>> On Jan 9, 2012, at 6:59, Christian Grobmeier wrote:
>>
>>> Hello,
>>>
>>> Jelly did not see any activity for nearly two years:
>>> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly
>>>
>>> Last release was in 01.2010.
>>>
>>> We had already discussion on a process to move proper components into
>>> another state, be it "dormant" or "inactive". I would like to
>>> resurrect this discussion. We have had a lots of discussion in the
>>> past: somebody wanted to progress with somehting, like graduating
>>> graph or using Java 5 in a component and the response sometimes was we
>>> have to less man power at Commons.
>>>
>>> Therefore I think we need to tell the people for which components they
>>> can expect releases and for which ones not. Otherwise outsiders may
>>> look at a huge bunch of components and see only little activity.
>>> Wouldn't it be better instead to show only a handful components which
>>> are actively developed?
>>>
>>> Looking at Jelly, it is orphaned. No releases, no releases to be
>>> expected. I would like to move it to dormant or to a new transition
>>> state, if people wish so, maybe called "orphaned" or "inactive" or
>>> whatever.
>>>
>>> What are your thoughts?
>>>
>>> Cheers
>>> Christian
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Move Jelly to dormant/orphaned?
On Mon, Jan 9, 2012 at 9:55 AM, Christian Grobmeier wrote: > On Mon, Jan 9, 2012 at 3:42 PM, Gary Gregory wrote: >> I think the whole formality of project state should be replaced with a >> live activity widget like can be seen on other sites. Commit activity >> and such. If someone were thinking of contributing to a project, the >> incentive would be removed or seriously diminished by a dead/sleepy >> project state. > > Interesting idea. > > You mean something like that? > https://www.ohloh.net/p/commons-compress > > Any ideas how we can get this data out from svn? > Probably besides svn an interesting metric is the number of discussion on ml. > > Question is how realistic is it we get something hacked together in > for example ruby? This is another kind of visualization: http://sourceforge.net/projects/hsqldb/stats/scm?repo=SVNRepository I do not know what the best metric is, just that it would be nice to have /something/. See my other reply to Sebb in this thread. Thank you, Gary > > Cheers > Christian > >> >> Gary >> >> On Jan 9, 2012, at 6:59, Christian Grobmeier wrote: >> >>> Hello, >>> >>> Jelly did not see any activity for nearly two years: >>> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly >>> >>> Last release was in 01.2010. >>> >>> We had already discussion on a process to move proper components into >>> another state, be it "dormant" or "inactive". I would like to >>> resurrect this discussion. We have had a lots of discussion in the >>> past: somebody wanted to progress with somehting, like graduating >>> graph or using Java 5 in a component and the response sometimes was we >>> have to less man power at Commons. >>> >>> Therefore I think we need to tell the people for which components they >>> can expect releases and for which ones not. Otherwise outsiders may >>> look at a huge bunch of components and see only little activity. >>> Wouldn't it be better instead to show only a handful components which >>> are actively developed? >>> >>> Looking at Jelly, it is orphaned. No releases, no releases to be >>> expected. I would like to move it to dormant or to a new transition >>> state, if people wish so, maybe called "orphaned" or "inactive" or >>> whatever. >>> >>> What are your thoughts? >>> >>> Cheers >>> Christian >>> >>> -- >>> http://www.grobmeier.de >>> https://www.timeandbill.de >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
+1 and good luck ;-) On Mon, Jan 9, 2012 at 4:46 PM, Gary Gregory wrote: > Good day to you all: > > I have prepared Commons Pool 1.6-RC4. > > There is NO change from RC3. > > This RC exists because I blew up the Nexus staging repository for RC3 > and a new RC is needed for a clean release process. > > The only changes from 1.5.7 are the additions of generics and > therefore requires Java 5. > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ > > Site: > > https://people.apache.org/builds/commons/pool/1.6/RC4/ > > Binaries: > > https://repository.apache.org/content/repositories/orgapachecommons-043/ > > The link above includes checksum files. > > [ ] +1 release it > [ ] +0 almost, please fix: > [ ] -1 no because: > > This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. > > Changes: > o [POOL-208] Support Java 1.5 Generics in version 1.x. > > Thank you and happy new year, > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
My +1, Gary On Mon, Jan 9, 2012 at 10:46 AM, Gary Gregory wrote: > Good day to you all: > > I have prepared Commons Pool 1.6-RC4. > > There is NO change from RC3. > > This RC exists because I blew up the Nexus staging repository for RC3 > and a new RC is needed for a clean release process. > > The only changes from 1.5.7 are the additions of generics and > therefore requires Java 5. > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ > > Site: > > https://people.apache.org/builds/commons/pool/1.6/RC4/ > > Binaries: > > https://repository.apache.org/content/repositories/orgapachecommons-043/ > > The link above includes checksum files. > > [ ] +1 release it > [ ] +0 almost, please fix: > [ ] -1 no because: > > This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. > > Changes: > o [POOL-208] Support Java 1.5 Generics in version 1.x. > > Thank you and happy new year, > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
On 9 January 2012 15:46, Gary Gregory wrote: > Good day to you all: > > I have prepared Commons Pool 1.6-RC4. > > There is NO change from RC3. > > This RC exists because I blew up the Nexus staging repository for RC3 > and a new RC is needed for a clean release process. > > The only changes from 1.5.7 are the additions of generics and > therefore requires Java 5. > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ > > Site: > > https://people.apache.org/builds/commons/pool/1.6/RC4/ > > Binaries: > > https://repository.apache.org/content/repositories/orgapachecommons-043/ > > The link above includes checksum files. But these disappear when the staging repo is promoted or dropped, so this is not useful as a cross-check (if that's what's intended). > > [ ] +1 release it > [ ] +0 almost, please fix: > [ ] -1 no because: > > This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. > > Changes: > o [POOL-208] Support Java 1.5 Generics in version 1.x. > > Thank you and happy new year, > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT][VOTE] Release Commons Pool 1.6-RC3.
On 9 January 2012 15:09, Gary Gregory wrote:
> On Mon, Jan 9, 2012 at 7:35 AM, sebb wrote:
>> On 9 January 2012 06:35, Gary Gregory wrote:
>>> On Sun, Jan 8, 2012 at 10:03 PM, sebb wrote:
On 8 January 2012 21:55, Gary Gregory wrote:
> Hi All:
>
> I am pushing out 1.6 and it's time to click release out of Nexus. I
> see that there are a ton of files there and the instructions say to
> remove *-bin* and *-src*. Ok fine, I delete those one at a time, no
> multiple selection allowed, one annoyance.
Hopefully you copied them first, as they are needed for dist.
>>>
>>> They are already in /x1/www/www.apache.org/content/dist/commons/pool/
>>>
>> OK.
>>
> Then I think to myself, hm, are the instructions complete? So I look
> at what 1.5.7 files are in Maven Central and I notice that there are
> no sha1 or md5 files.
AFAIK, Maven does normally contain md5 and sha1 - see for example:
http://repo1.maven.org/maven2/org/apache/commons/commons-jexl/2.1.1/
> So what do I, silly me? I delete them! When I then click release in
> Nexus, I get:
>
> Staging ruleset evaluation on repository 'org.apache.commons-012
> (u:ggregory, a:24.250.160.61)' has failed.
>
> Staging Checksum Validation
>
> -Missing SHA1:
> '/commons-pool/commons-pool/1.6/commons-pool-1.6.jar.sha1'.
> -Missing MD5:
> '/commons-pool/commons-pool/1.6/commons-pool-1.6.jar.md5.'
> -Missing SHA1:
> '/commons-pool/commons-pool/1.6/commons-pool-1.6-javadoc.jar.sha1'.
> -Missing MD5:
> '/commons-pool/commons-pool/1.6/commons-pool-1.6-javadoc.jar.md5.'
> -Missing SHA1:
> '/commons-pool/commons-pool/1.6/commons-pool-1.6.pom.sha1'.
> -Missing MD5:
> '/commons-pool/commons-pool/1.6/commons-pool-1.6.pom.md5.'
> -Missing SHA1:
> '/commons-pool/commons-pool/1.6/commons-pool-1.6-sources.jar.sha1'.
> -Missing MD5:
> '/commons-pool/commons-pool/1.6/commons-pool-1.6-sources.jar.md5.'
>
> !$#$@# I can't believe I shot myself in the foot!
>
> I have the sha1 and md5 files on my people.apache.org home dir.
>
> Can I copy them to Nexus?
I don't think you can update the staging repo once it is closed.
However, you may be able to create a new one using the existihg files,
by using the Nexus Staging Upload feature.
Create a bundle that contains copies of all the Maven files from Nexus
+ the recovered hashes.
You can try using the Maven Repository plugin, but I had problems with
that; it may be simpler to create the jar file manually.
Or you can upload each file singly, but that quickly becomes boring...
>>>
>>> Here is what I did: All the files we voted on were copied from Nexus
>>> (before I deleted the sha1's and md5's) with wget to my people.a.o
>>> home dir per the wiki instructions.
>>>
>>> I copied them from my home dir down to my local machine. Then I used
>>> the Nexus Staging Upload feature to upload the POM, and jars. The
>>> files have been uploading for five minutes now which is very long. I'm
>>> going to let it upload while I sleep and check in the AM (EST).
>>>
>>> If that does not work, I'll drop the previous repo and try again. If
>>> that does not work, then I'm stuck with an RC4. Arg.
>>
>> As I already wrote, the vote was on the current staging repo. If you
>> release from a new staging repo, then the vote is invalid.
>>
>> So I think you need to tie the files in the new staging area to the
>> old staging area; you can do this by getting agreement on which sigs
>> were used.
>
> What is the difference b/w a "staging area" and a "staging repo"? The
> staging repo is the dir in Nexus after a deploy, that's clear.
Just a different name for the same thing; I was not being consistent.
> It seems that I cannot update a closed repo, which makes sense, I
> would not expect to be able to do that.
>
> So the best I can do is create a new repo with the same files and
> close, and release it./
Yes.
> Right now, I cannot even do that, the Nexus upload was stuck in a loop
> for 6 hours over night, so I killed that one. I was trying to upload
> the POM with attached atrifacts.
No idea why that should be.
> Now it is looping ("Uploading..." dialog) on uploading a bundle zip I
> created myself which contains the same files we voted on.
>
> So killed that and create a bundle the maven way instead of using
> WinRar: mvn javadoc:jar source:jar repository:bundle-create
But that creates new versions of the jars ...
> Now it is looping uploading that! I'm not lucky today.
>
> This is an abject failure. :( blech.
>
> The cleanest thing is to RC again.
The cleanest would be to re-create the staging area from the previous
files, but that may no longer be possible if you don't have the files.
And anyway, there's no way to tie the original vote to the replaced
files, now that the original staging r
Re: [all] Move Jelly to dormant/orphaned?
On Mon, Jan 9, 2012 at 4:42 PM, Gary Gregory wrote: > On Mon, Jan 9, 2012 at 9:55 AM, Christian Grobmeier > wrote: >> On Mon, Jan 9, 2012 at 3:42 PM, Gary Gregory wrote: >>> I think the whole formality of project state should be replaced with a >>> live activity widget like can be seen on other sites. Commit activity >>> and such. If someone were thinking of contributing to a project, the >>> incentive would be removed or seriously diminished by a dead/sleepy >>> project state. >> >> Interesting idea. >> >> You mean something like that? >> https://www.ohloh.net/p/commons-compress >> >> Any ideas how we can get this data out from svn? >> Probably besides svn an interesting metric is the number of discussion on ml. >> >> Question is how realistic is it we get something hacked together in >> for example ruby? > > This is another kind of visualization: > http://sourceforge.net/projects/hsqldb/stats/scm?repo=SVNRepository > > I do not know what the best metric is, just that it would be nice to > have /something/. See my other reply to Sebb in this thread. Having "something" which shows the current state of the component easily is already a good first step in my opinion. But I still think we need then to decide to move a component to another section or mark them otherwise as not active. It looks pretty bad if a user surfes the components and every second seems to be dead. Anyway... I just found this: commons-compress$ svn --xml -v log Returns a bunch of cool information. parsing this logfile might be enough already to aggregate. Perhaps a repos at labs.a.o might be a good place to start with that Cheers Christian > > Thank you, > Gary > >> >> Cheers >> Christian >> >>> >>> Gary >>> >>> On Jan 9, 2012, at 6:59, Christian Grobmeier wrote: >>> Hello, Jelly did not see any activity for nearly two years: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly Last release was in 01.2010. We had already discussion on a process to move proper components into another state, be it "dormant" or "inactive". I would like to resurrect this discussion. We have had a lots of discussion in the past: somebody wanted to progress with somehting, like graduating graph or using Java 5 in a component and the response sometimes was we have to less man power at Commons. Therefore I think we need to tell the people for which components they can expect releases and for which ones not. Otherwise outsiders may look at a huge bunch of components and see only little activity. Wouldn't it be better instead to show only a handful components which are actively developed? Looking at Jelly, it is orphaned. No releases, no releases to be expected. I would like to move it to dormant or to a new transition state, if people wish so, maybe called "orphaned" or "inactive" or whatever. What are your thoughts? Cheers Christian -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> >> -- >> http://www.grobmeier.de >> https://www.timeandbill.de >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
On Mon, Jan 9, 2012 at 11:55 AM, sebb wrote: > On 9 January 2012 15:46, Gary Gregory wrote: >> Good day to you all: >> >> I have prepared Commons Pool 1.6-RC4. >> >> There is NO change from RC3. >> >> This RC exists because I blew up the Nexus staging repository for RC3 >> and a new RC is needed for a clean release process. >> >> The only changes from 1.5.7 are the additions of generics and >> therefore requires Java 5. >> >> Tag: >> >> https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ >> >> Site: >> >> https://people.apache.org/builds/commons/pool/1.6/RC4/ >> >> Binaries: >> >> https://repository.apache.org/content/repositories/orgapachecommons-043/ >> >> The link above includes checksum files. > > But these disappear when the staging repo is promoted or dropped, so > this is not useful as a cross-check (if that's what's intended). Hm, I am not sure I understand. Cross check with what? The RC3 staging repos is gone, it was not salvageable by a mere Maven/Nexus mortal like me. This is a new RC with my guarantee that nothing has changed from the previous RC: the RC3 and RC4 tags contain the same version of the same files. Yes, the files were rebuilt by maven, but nothing changed in the source files. I am taking the conservative path with a new RC and vote instead of deploying to Nexus, closing, and releasing the repo, because as you mentioned, we vote on the contents of a specific Nexus staging repo. And yes the repo goes away after a release but that has always been like that. Are you suggesting a different process? Thank you, Gary > >> >> [ ] +1 release it >> [ ] +0 almost, please fix: >> [ ] -1 no because: >> >> This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. >> >> Changes: >> o [POOL-208] Support Java 1.5 Generics in version 1.x. >> >> Thank you and happy new year, >> Gary >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >> Spring Batch in Action: http://bit.ly/bqpbCK >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Move Jelly to dormant/orphaned?
On 9 January 2012 15:17, Gary Gregory wrote:
> On Mon, Jan 9, 2012 at 9:58 AM, sebb wrote:
>> On 9 January 2012 14:42, Gary Gregory wrote:
>>> I think the whole formality of project state should be replaced with a
>>> live activity widget like can be seen on other sites. Commit activity
>>> and such. If someone were thinking of contributing to a project, the
>>> incentive would be removed or seriously diminished by a dead/sleepy
>>> project state.
>>
>> I think the activity widget could be counter-productive.
>>
>> Component activity tends to go in phases; there may be several weeks
>> with no activity and then a flurry.
>> Also commits are only a small part of the health of a component.
>>
>> Activity monitors can work well for frequently occuring activities,
>> but component health is much more complicated.
>>
>> To take a simple example, try measuring committer productivity by SVN
>> commits.
>> Some committers commit large chunks, some commit per file; and that
>> may vary for a committer.
>> Some commits are not "productive" - e.g. whitespace fixes, reverts of
>> a bad commit.
>> Some commits represent lots of investigation and skill, some may be
>> much simpler.
>
> The idea for me is to get a heartbeat representation, not hard
> numbers; something that can be automatically generated. If we do
> decide to change the state of a component, it should be a more serious
> step.
In which case, the measure should not be published externally, as it
has no independent meaning.
Which is one of the objections I have to the widget idea - it can
easily give the wrong impression to outsiders.
> A project can look asleep and be fine IMO, ready to go again.
> IMO a project should be alive or dead, all this formality for
> in-between states ("dormant" and whatnot) is not helpful. As soon as
> someone commits, it's not dormant, and I should not have to officially
> wake up (with a vote?) a commons project before committing to it IMO.
Again, a single commit is not sufficient to show that a project is active.
Certainly in the past, there have been global commits to all projects,
e.g. to correct a problem with site generation.
> Project states, if wanted, should be on the Wiki in a list, "this is
> how we feel about projects, but a committer can still commit and do
> work"
That's a separate issue from attracting outside contributions.
But I think there are some components that are clearly not going to be
developed further, e.g. because the need for them has gone away.
> 2c,
> Gary
>
>>
>>> Gary
>>>
>>> On Jan 9, 2012, at 6:59, Christian Grobmeier wrote:
>>>
Hello,
Jelly did not see any activity for nearly two years:
http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly
Last release was in 01.2010.
We had already discussion on a process to move proper components into
another state, be it "dormant" or "inactive". I would like to
resurrect this discussion. We have had a lots of discussion in the
past: somebody wanted to progress with somehting, like graduating
graph or using Java 5 in a component and the response sometimes was we
have to less man power at Commons.
Therefore I think we need to tell the people for which components they
can expect releases and for which ones not. Otherwise outsiders may
look at a huge bunch of components and see only little activity.
Wouldn't it be better instead to show only a handful components which
are actively developed?
Looking at Jelly, it is orphaned. No releases, no releases to be
expected. I would like to move it to dormant or to a new transition
state, if people wish so, maybe called "orphaned" or "inactive" or
whatever.
What are your thoughts?
Cheers
Christian
--
http://www.grobmeier.de
https://www.timeandbill.de
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@common
Re: [all] Move Jelly to dormant/orphaned?
On 9 January 2012 17:04, Christian Grobmeier wrote: > On Mon, Jan 9, 2012 at 4:42 PM, Gary Gregory wrote: >> On Mon, Jan 9, 2012 at 9:55 AM, Christian Grobmeier >> wrote: >>> On Mon, Jan 9, 2012 at 3:42 PM, Gary Gregory wrote: I think the whole formality of project state should be replaced with a live activity widget like can be seen on other sites. Commit activity and such. If someone were thinking of contributing to a project, the incentive would be removed or seriously diminished by a dead/sleepy project state. >>> >>> Interesting idea. >>> >>> You mean something like that? >>> https://www.ohloh.net/p/commons-compress >>> >>> Any ideas how we can get this data out from svn? >>> Probably besides svn an interesting metric is the number of discussion on >>> ml. >>> >>> Question is how realistic is it we get something hacked together in >>> for example ruby? >> >> This is another kind of visualization: >> http://sourceforge.net/projects/hsqldb/stats/scm?repo=SVNRepository >> >> I do not know what the best metric is, just that it would be nice to >> have /something/. See my other reply to Sebb in this thread. > > Having "something" which shows the current state of the component > easily is already a good first step in my opinion. > > But I still think we need then to decide to move a component to > another section or mark them otherwise as not active. It looks pretty > bad if a user surfes the components and every second seems to be dead. > > Anyway... I just found this: > > commons-compress$ svn --xml -v log That's probably what OhLoh uses. > Returns a bunch of cool information. parsing this logfile might be > enough already to aggregate. > Perhaps a repos at labs.a.o might be a good place to start with that > Cheers > Christian > >> >> Thank you, >> Gary >> >>> >>> Cheers >>> Christian >>> Gary On Jan 9, 2012, at 6:59, Christian Grobmeier wrote: > Hello, > > Jelly did not see any activity for nearly two years: > http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly > > Last release was in 01.2010. > > We had already discussion on a process to move proper components into > another state, be it "dormant" or "inactive". I would like to > resurrect this discussion. We have had a lots of discussion in the > past: somebody wanted to progress with somehting, like graduating > graph or using Java 5 in a component and the response sometimes was we > have to less man power at Commons. > > Therefore I think we need to tell the people for which components they > can expect releases and for which ones not. Otherwise outsiders may > look at a huge bunch of components and see only little activity. > Wouldn't it be better instead to show only a handful components which > are actively developed? > > Looking at Jelly, it is orphaned. No releases, no releases to be > expected. I would like to move it to dormant or to a new transition > state, if people wish so, maybe called "orphaned" or "inactive" or > whatever. > > What are your thoughts? > > Cheers > Christian > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >>> -- >>> http://www.grobmeier.de >>> https://www.timeandbill.de >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >> Spring Batch in Action: http://bit.ly/bqpbCK >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Move Jelly to dormant/orphaned?
On Mon, Jan 9, 2012 at 12:12 PM, sebb wrote:
> On 9 January 2012 15:17, Gary Gregory wrote:
>> On Mon, Jan 9, 2012 at 9:58 AM, sebb wrote:
>>> On 9 January 2012 14:42, Gary Gregory wrote:
I think the whole formality of project state should be replaced with a
live activity widget like can be seen on other sites. Commit activity
and such. If someone were thinking of contributing to a project, the
incentive would be removed or seriously diminished by a dead/sleepy
project state.
>>>
>>> I think the activity widget could be counter-productive.
>>>
>>> Component activity tends to go in phases; there may be several weeks
>>> with no activity and then a flurry.
>>> Also commits are only a small part of the health of a component.
>>>
>>> Activity monitors can work well for frequently occuring activities,
>>> but component health is much more complicated.
>>>
>>> To take a simple example, try measuring committer productivity by SVN
>>> commits.
>>> Some committers commit large chunks, some commit per file; and that
>>> may vary for a committer.
>>> Some commits are not "productive" - e.g. whitespace fixes, reverts of
>>> a bad commit.
>>> Some commits represent lots of investigation and skill, some may be
>>> much simpler.
>>
>> The idea for me is to get a heartbeat representation, not hard
>> numbers; something that can be automatically generated. If we do
>> decide to change the state of a component, it should be a more serious
>> step.
>
> In which case, the measure should not be published externally, as it
> has no independent meaning.
>
> Which is one of the objections I have to the widget idea - it can
> easily give the wrong impression to outsiders.
>
>> A project can look asleep and be fine IMO, ready to go again.
>> IMO a project should be alive or dead, all this formality for
>> in-between states ("dormant" and whatnot) is not helpful. As soon as
>> someone commits, it's not dormant, and I should not have to officially
>> wake up (with a vote?) a commons project before committing to it IMO.
>
> Again, a single commit is not sufficient to show that a project is active.
> Certainly in the past, there have been global commits to all projects,
> e.g. to correct a problem with site generation.
>
>> Project states, if wanted, should be on the Wiki in a list, "this is
>> how we feel about projects, but a committer can still commit and do
>> work"
>
> That's a separate issue from attracting outside contributions.
>
> But I think there are some components that are clearly not going to be
> developed further, e.g. because the need for them has gone away.
Good point. But does that mean we need more states than alive and
dead? Thinking about The Princess Bride...
I was thinking of the edge case where someone wants a bug fix in a
sleepy project because they have to fix an older application that uses
the component directly or indirectly.
Gary
>
>> 2c,
>> Gary
>>
>>>
Gary
On Jan 9, 2012, at 6:59, Christian Grobmeier wrote:
> Hello,
>
> Jelly did not see any activity for nearly two years:
> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly
>
> Last release was in 01.2010.
>
> We had already discussion on a process to move proper components into
> another state, be it "dormant" or "inactive". I would like to
> resurrect this discussion. We have had a lots of discussion in the
> past: somebody wanted to progress with somehting, like graduating
> graph or using Java 5 in a component and the response sometimes was we
> have to less man power at Commons.
>
> Therefore I think we need to tell the people for which components they
> can expect releases and for which ones not. Otherwise outsiders may
> look at a huge bunch of components and see only little activity.
> Wouldn't it be better instead to show only a handful components which
> are actively developed?
>
> Looking at Jelly, it is orphaned. No releases, no releases to be
> expected. I would like to move it to dormant or to a new transition
> state, if people wish so, maybe called "orphaned" or "inactive" or
> whatever.
>
> What are your thoughts?
>
> Cheers
> Christian
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.or
Re: [VOTE] Release Commons Pool 1.6-RC4
On 9 January 2012 17:06, Gary Gregory wrote: > On Mon, Jan 9, 2012 at 11:55 AM, sebb wrote: >> On 9 January 2012 15:46, Gary Gregory wrote: >>> Good day to you all: >>> >>> I have prepared Commons Pool 1.6-RC4. >>> >>> There is NO change from RC3. >>> >>> This RC exists because I blew up the Nexus staging repository for RC3 >>> and a new RC is needed for a clean release process. >>> >>> The only changes from 1.5.7 are the additions of generics and >>> therefore requires Java 5. >>> >>> Tag: >>> >>> https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ >>> >>> Site: >>> >>> https://people.apache.org/builds/commons/pool/1.6/RC4/ >>> >>> Binaries: >>> >>> https://repository.apache.org/content/repositories/orgapachecommons-043/ >>> >>> The link above includes checksum files. >> >> But these disappear when the staging repo is promoted or dropped, so >> this is not useful as a cross-check (if that's what's intended). > > Hm, I am not sure I understand. Cross check with what? The RC3 staging > repos is gone, it was not salvageable by a mere Maven/Nexus mortal > like me. I've not use Nexus upload much - I only used it to release the Daemon jars from the existing binary release, but that worked fine. > This is a new RC with my guarantee that nothing has changed from the > previous RC: the RC3 and RC4 tags contain the same version of the same > files. Which is necessary (but not sufficient) to ensure the release is the same. > Yes, the files were rebuilt by maven, but nothing changed in > the source files. I am taking the conservative path with a new RC and > vote instead of deploying to Nexus, closing, and releasing the repo, > because as you mentioned, we vote on the contents of a specific Nexus > staging repo. And yes the repo goes away after a release but that has > always been like that. Are you suggesting a different process? I'm suggesting that having the actual hashes in the VOTE e-mail is better for traceability as the dist and Maven repo contents can be linked directly to the VOTE. I guess that one can also follow the Nexus promotion mail trail and tie it to the vote, but AFAICT that does not prove conclusively that the artifacts present in a repo are identical to the ones voted on. It would also have avoided needing to re-run the VOTE, had you (or someone else) been able to recreate the staging repo from the original files. > Thank you, > Gary > >> >>> >>> [ ] +1 release it >>> [ ] +0 almost, please fix: >>> [ ] -1 no because: >>> >>> This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. >>> >>> Changes: >>> o [POOL-208] Support Java 1.5 Generics in version 1.x. >>> >>> Thank you and happy new year, >>> Gary >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >>> Spring Batch in Action: http://bit.ly/bqpbCK >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Move Jelly to dormant/orphaned?
>>> Project states, if wanted, should be on the Wiki in a list, "this is >>> how we feel about projects, but a committer can still commit and do >>> work" >> >> That's a separate issue from attracting outside contributions. >> >> But I think there are some components that are clearly not going to be >> developed further, e.g. because the need for them has gone away. > > Good point. But does that mean we need more states than alive and > dead? Thinking about The Princess Bride... > > I was thinking of the edge case where someone wants a bug fix in a > sleepy project because they have to fix an older application that uses > the component directly or indirectly. He still can as he can do in dormant or sandbox components. No big deal for me. I am fine with putting a component to dormant instead of having a fourth state. It should be easy to put a component to sleep or wake it up again. Probably not even moving them in svn, jsut indicating in a "components health page" at commons.a.o > > Gary > >> >>> 2c, >>> Gary >>> > Gary > > On Jan 9, 2012, at 6:59, Christian Grobmeier wrote: > >> Hello, >> >> Jelly did not see any activity for nearly two years: >> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly >> >> Last release was in 01.2010. >> >> We had already discussion on a process to move proper components into >> another state, be it "dormant" or "inactive". I would like to >> resurrect this discussion. We have had a lots of discussion in the >> past: somebody wanted to progress with somehting, like graduating >> graph or using Java 5 in a component and the response sometimes was we >> have to less man power at Commons. >> >> Therefore I think we need to tell the people for which components they >> can expect releases and for which ones not. Otherwise outsiders may >> look at a huge bunch of components and see only little activity. >> Wouldn't it be better instead to show only a handful components which >> are actively developed? >> >> Looking at Jelly, it is orphaned. No releases, no releases to be >> expected. I would like to move it to dormant or to a new transition >> state, if people wish so, maybe called "orphaned" or "inactive" or >> whatever. >> >> What are your thoughts? >> >> Cheers >> Christian >> >> -- >> http://www.grobmeier.de >> https://www.timeandbill.de >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >>> Spring Batch in Action: http://bit.ly/bqpbCK >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
On Mon, Jan 9, 2012 at 12:26 PM, sebb wrote: > On 9 January 2012 17:06, Gary Gregory wrote: >> On Mon, Jan 9, 2012 at 11:55 AM, sebb wrote: >>> On 9 January 2012 15:46, Gary Gregory wrote: Good day to you all: I have prepared Commons Pool 1.6-RC4. There is NO change from RC3. This RC exists because I blew up the Nexus staging repository for RC3 and a new RC is needed for a clean release process. The only changes from 1.5.7 are the additions of generics and therefore requires Java 5. Tag: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ Site: https://people.apache.org/builds/commons/pool/1.6/RC4/ Binaries: https://repository.apache.org/content/repositories/orgapachecommons-043/ The link above includes checksum files. >>> >>> But these disappear when the staging repo is promoted or dropped, so >>> this is not useful as a cross-check (if that's what's intended). >> >> Hm, I am not sure I understand. Cross check with what? The RC3 staging >> repos is gone, it was not salvageable by a mere Maven/Nexus mortal >> like me. > > I've not use Nexus upload much - I only used it to release the Daemon > jars from the existing binary release, but that worked fine. > >> This is a new RC with my guarantee that nothing has changed from the >> previous RC: the RC3 and RC4 tags contain the same version of the same >> files. > > Which is necessary (but not sufficient) to ensure the release is the same. > >> Yes, the files were rebuilt by maven, but nothing changed in >> the source files. I am taking the conservative path with a new RC and >> vote instead of deploying to Nexus, closing, and releasing the repo, >> because as you mentioned, we vote on the contents of a specific Nexus >> staging repo. And yes the repo goes away after a release but that has >> always been like that. Are you suggesting a different process? > > I'm suggesting that having the actual hashes in the VOTE e-mail is > better for traceability as the dist and Maven repo contents can be > linked directly to the VOTE. Ok, so the contents of all *.sha1 and *.md5 should be in the VOTE email? Can you update the VOTE section of http://wiki.apache.org/commons/UsingNexus with exactly what you mean? This is all good stuff, let's improve our process. Thank you, Gary > > I guess that one can also follow the Nexus promotion mail trail and > tie it to the vote, but AFAICT that does not prove conclusively that > the artifacts present in a repo are identical to the ones voted on. > > It would also have avoided needing to re-run the VOTE, had you (or > someone else) been able to recreate the staging repo from the original > files. I tried to do a mvn deploy:deploy to redploy without building but could not get it to work. I'm sure there is some Maven black magic to do so but I did not take the time to figure that out. Gary > >> Thank you, >> Gary >> >>> [ ] +1 release it [ ] +0 almost, please fix: [ ] -1 no because: This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. Changes: o [POOL-208] Support Java 1.5 Generics in version 1.x. Thank you and happy new year, Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >> Spring Batch in Action: http://bit.ly/bqpbCK >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Release Commons Pool 1.6-RC4
On 9 January 2012 18:23, Gary Gregory wrote: > On Mon, Jan 9, 2012 at 12:26 PM, sebb wrote: >> On 9 January 2012 17:06, Gary Gregory wrote: >>> On Mon, Jan 9, 2012 at 11:55 AM, sebb wrote: On 9 January 2012 15:46, Gary Gregory wrote: > Good day to you all: > > I have prepared Commons Pool 1.6-RC4. > > There is NO change from RC3. > > This RC exists because I blew up the Nexus staging repository for RC3 > and a new RC is needed for a clean release process. > > The only changes from 1.5.7 are the additions of generics and > therefore requires Java 5. > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ > > Site: > > https://people.apache.org/builds/commons/pool/1.6/RC4/ > > Binaries: > > https://repository.apache.org/content/repositories/orgapachecommons-043/ > > The link above includes checksum files. But these disappear when the staging repo is promoted or dropped, so this is not useful as a cross-check (if that's what's intended). >>> >>> Hm, I am not sure I understand. Cross check with what? The RC3 staging >>> repos is gone, it was not salvageable by a mere Maven/Nexus mortal >>> like me. >> >> I've not use Nexus upload much - I only used it to release the Daemon >> jars from the existing binary release, but that worked fine. >> >>> This is a new RC with my guarantee that nothing has changed from the >>> previous RC: the RC3 and RC4 tags contain the same version of the same >>> files. >> >> Which is necessary (but not sufficient) to ensure the release is the same. >> >>> Yes, the files were rebuilt by maven, but nothing changed in >>> the source files. I am taking the conservative path with a new RC and >>> vote instead of deploying to Nexus, closing, and releasing the repo, >>> because as you mentioned, we vote on the contents of a specific Nexus >>> staging repo. And yes the repo goes away after a release but that has >>> always been like that. Are you suggesting a different process? >> >> I'm suggesting that having the actual hashes in the VOTE e-mail is >> better for traceability as the dist and Maven repo contents can be >> linked directly to the VOTE. > > Ok, so the contents of all *.sha1 and *.md5 should be in the VOTE email? Probably don't need both hashes. I've just realised that this would be easier if the Nexus mails included the hashes; one could just include the Nexus message in the vote. [Note: as it stands, the Nexus mail is not unique, because the numeric suffix is recycled.] I'll raise an enhancement request against Nexus. > Can you update the VOTE section of > http://wiki.apache.org/commons/UsingNexus with exactly what you mean? > > This is all good stuff, let's improve our process. > > Thank you, > Gary > >> >> I guess that one can also follow the Nexus promotion mail trail and >> tie it to the vote, but AFAICT that does not prove conclusively that >> the artifacts present in a repo are identical to the ones voted on. >> >> It would also have avoided needing to re-run the VOTE, had you (or >> someone else) been able to recreate the staging repo from the original >> files. > > I tried to do a mvn deploy:deploy to redploy without building but > could not get it to work. I'm sure there is some Maven black magic to > do so but I did not take the time to figure that out. > I just used Nexus upload to upload the Daemon jars; worked fine for me. > Gary > >> >>> Thank you, >>> Gary >>> > > [ ] +1 release it > [ ] +0 almost, please fix: > [ ] -1 no because: > > This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 > EST. > > Changes: > o [POOL-208] Support Java 1.5 Generics in version 1.x. > > Thank you and happy new year, > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >>> Spring Batch in Action: http://bit.ly/bqpbCK >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@
Re: [VOTE] Release Commons Pool 1.6-RC4
On 9 January 2012 15:46, Gary Gregory wrote: > Good day to you all: > > I have prepared Commons Pool 1.6-RC4. > > There is NO change from RC3. > > This RC exists because I blew up the Nexus staging repository for RC3 > and a new RC is needed for a clean release process. > > The only changes from 1.5.7 are the additions of generics and > therefore requires Java 5. > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ > > Site: > > https://people.apache.org/builds/commons/pool/1.6/RC4/ > > Binaries: > > https://repository.apache.org/content/repositories/orgapachecommons-043/ Unfortunately, the build details are not created properly: Implementation-Build: UNKNOWN_BRANCH@r??; 2012-01-04 10:31:47-0500 Are you using SVN 1.7? Not a blocker, but need to know why it occurred. > The link above includes checksum files. > > [ ] +1 release it > [ ] +0 almost, please fix: > [ ] -1 no because: > > This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. > > Changes: > o [POOL-208] Support Java 1.5 Generics in version 1.x. > > Thank you and happy new year, > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
On Jan 9, 2012, at 15:04, sebb wrote: > On 9 January 2012 15:46, Gary Gregory wrote: >> Good day to you all: >> >> I have prepared Commons Pool 1.6-RC4. >> >> There is NO change from RC3. >> >> This RC exists because I blew up the Nexus staging repository for RC3 >> and a new RC is needed for a clean release process. >> >> The only changes from 1.5.7 are the additions of generics and >> therefore requires Java 5. >> >> Tag: >> >> https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ >> >> Site: >> >> https://people.apache.org/builds/commons/pool/1.6/RC4/ >> >> Binaries: >> >> https://repository.apache.org/content/repositories/orgapachecommons-043/ > > Unfortunately, the build details are not created properly: > > Implementation-Build: UNKNOWN_BRANCH@r??; 2012-01-04 10:31:47-0500 > > Are you using SVN 1.7? > > Not a blocker, but need to know why it occurred. Yes, SVN 1.7. Gary > >> The link above includes checksum files. >> >> [ ] +1 release it >> [ ] +0 almost, please fix: >> [ ] -1 no because: >> >> This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. >> >> Changes: >> o [POOL-208] Support Java 1.5 Generics in version 1.x. >> >> Thank you and happy new year, >> Gary >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >> Spring Batch in Action: http://bit.ly/bqpbCK >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent pom - any more changes needed?
sebb wrote: > On 8 January 2012 16:43, Jörg Schaible wrote: >> sebb wrote: [snip] >> The main point for the profile was to suppress the failures of the >> buildnumber plugin automatically when building from the source tarball. > > With RC4, that can be achieved by defining buildNumber.skip=true. Fine. >> Actually the usage of the plugin means, that the release is not really >> repeatable (missing entries in the manifest) > > If you follow that logic to its conclusion, the buildNumber plugin is > effectively unusable. > >> unless checked out directly from the tag ... :-/ > > Which is what should *always* be done. > Releases should always be built from a clean checkout. > If not, they are not guaranteed repeatable, regardless of the use of > the buildNumber plugin. > There has recently been at least one Commons RC which was not built > from a clean checkout, and that caused the tag to differ from the > archives. > > The point of the manifest entry is to show what tag and revision was > used to build the release. > If the information happens to be missing, we are no worse off than > before, but if it is present, it can be potentially useful. Makes sense after all. Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Commons Wiki] Update of "BuildSystems" by ThomasVandahl
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "BuildSystems" page has been changed by ThomasVandahl: http://wiki.apache.org/commons/BuildSystems?action=diff&rev1=23&rev2=24 Comment: Added JCS || exec|| Yes || No|| Yes * || || || || fileupload || Yes || Yes * || Yes || || last release(1.2) used m2 || || io || Yes || Yes || Yes || Yes * || last release(2.1) used m3 || + || jcs || No|| No|| Yes * || || || || jci || No|| No|| Yes * || || || || jelly || Yes || Yes * || No|| || || || jexl|| No|| No|| Yes * || ? || || - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
On 9 January 2012 15:46, Gary Gregory wrote: > Good day to you all: > > I have prepared Commons Pool 1.6-RC4. I checked files with the following MD5 hashes: 70a1573d13d76fa3bafe4ee163904e24 commons-pool-1.6-bin.tar.gz a9b1b1faacbb81282f06e1e502e107d3 commons-pool-1.6-bin.zip e370c052057cf0b880328d732f55c277 commons-pool-1.6-javadoc.jar ff08a9ed698ec455d94a230a0084f155 commons-pool-1.6-sources.jar ef08ea62cad838d4149e40b1eae06d9a commons-pool-1.6-src.tar.gz 202a36a912f04b98ea10926962b4eab1 commons-pool-1.6-src.zip 5ca02245c829422176d23fa530e919cc commons-pool-1.6.jar 1f529ba9fb6b9a067ad7663a48931cb6 commons-pool-1.6.pom > There is NO change from RC3. RC3 and RC4 are identical. > This RC exists because I blew up the Nexus staging repository for RC3 > and a new RC is needed for a clean release process. > > The only changes from 1.5.7 are the additions of generics and > therefore requires Java 5. > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ > > Site: > > https://people.apache.org/builds/commons/pool/1.6/RC4/ > > Binaries: > > https://repository.apache.org/content/repositories/orgapachecommons-043/ Source archives agree with RC4 tag. > The link above includes checksum files. > > [ ] +1 release it > [X] +0 almost, please fix: Two issues to be fixed before any further release: - remove $Date SVN variables - ensure Implementation-Build: is correctly populated (CP 24 should fix this) > [ ] -1 no because: > > This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. > > Changes: > o [POOL-208] Support Java 1.5 Generics in version 1.x. > > Thank you and happy new year, > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [validator] Commons Validator 1.4.0 release
On Fri, 6 Jan 2012, Simone Tripodi wrote: I did some work on [validator] for the release but did not get through the issues since I'm not so familiar to [validator] so much... if you could have a look at them, I can continue providing my help. Looks like you've done loads, thanks! I've applied the two patches from Jacob, which I believe should fix the issues raised in the last release vote I think we should now be ready to try for the release. Are you able to build the RC? Cheers Nick - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
On Mon, Jan 9, 2012 at 5:39 PM, sebb wrote: > On 9 January 2012 15:46, Gary Gregory wrote: >> Good day to you all: >> >> I have prepared Commons Pool 1.6-RC4. > > I checked files with the following MD5 hashes: > > 70a1573d13d76fa3bafe4ee163904e24 commons-pool-1.6-bin.tar.gz > a9b1b1faacbb81282f06e1e502e107d3 commons-pool-1.6-bin.zip > e370c052057cf0b880328d732f55c277 commons-pool-1.6-javadoc.jar > ff08a9ed698ec455d94a230a0084f155 commons-pool-1.6-sources.jar > ef08ea62cad838d4149e40b1eae06d9a commons-pool-1.6-src.tar.gz > 202a36a912f04b98ea10926962b4eab1 commons-pool-1.6-src.zip > 5ca02245c829422176d23fa530e919cc commons-pool-1.6.jar > 1f529ba9fb6b9a067ad7663a48931cb6 commons-pool-1.6.pom > >> There is NO change from RC3. > > RC3 and RC4 are identical. > >> This RC exists because I blew up the Nexus staging repository for RC3 >> and a new RC is needed for a clean release process. >> >> The only changes from 1.5.7 are the additions of generics and >> therefore requires Java 5. >> >> Tag: >> >> https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ >> >> Site: >> >> https://people.apache.org/builds/commons/pool/1.6/RC4/ >> >> Binaries: >> >> https://repository.apache.org/content/repositories/orgapachecommons-043/ > > Source archives agree with RC4 tag. >> The link above includes checksum files. >> >> [ ] +1 release it >> [X] +0 almost, please fix: > > Two issues to be fixed before any further release: > - remove $Date SVN variables Replacing with $Id $ now... > - ensure Implementation-Build: is correctly populated (CP 24 should fix this) Don't you mean CP 23? Gary > >> [ ] -1 no because: >> >> This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. >> >> Changes: >> o [POOL-208] Support Java 1.5 Generics in version 1.x. >> >> Thank you and happy new year, >> Gary >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >> Spring Batch in Action: http://bit.ly/bqpbCK >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
On 10 January 2012 01:25, Gary Gregory wrote: > On Mon, Jan 9, 2012 at 5:39 PM, sebb wrote: >> On 9 January 2012 15:46, Gary Gregory wrote: >>> Good day to you all: >>> >>> I have prepared Commons Pool 1.6-RC4. >> >> I checked files with the following MD5 hashes: >> >> 70a1573d13d76fa3bafe4ee163904e24 commons-pool-1.6-bin.tar.gz >> a9b1b1faacbb81282f06e1e502e107d3 commons-pool-1.6-bin.zip >> e370c052057cf0b880328d732f55c277 commons-pool-1.6-javadoc.jar >> ff08a9ed698ec455d94a230a0084f155 commons-pool-1.6-sources.jar >> ef08ea62cad838d4149e40b1eae06d9a commons-pool-1.6-src.tar.gz >> 202a36a912f04b98ea10926962b4eab1 commons-pool-1.6-src.zip >> 5ca02245c829422176d23fa530e919cc commons-pool-1.6.jar >> 1f529ba9fb6b9a067ad7663a48931cb6 commons-pool-1.6.pom >> >>> There is NO change from RC3. >> >> RC3 and RC4 are identical. >> >>> This RC exists because I blew up the Nexus staging repository for RC3 >>> and a new RC is needed for a clean release process. >>> >>> The only changes from 1.5.7 are the additions of generics and >>> therefore requires Java 5. >>> >>> Tag: >>> >>> https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ >>> >>> Site: >>> >>> https://people.apache.org/builds/commons/pool/1.6/RC4/ >>> >>> Binaries: >>> >>> https://repository.apache.org/content/repositories/orgapachecommons-043/ >> >> Source archives agree with RC4 tag. >>> The link above includes checksum files. >>> >>> [ ] +1 release it >>> [X] +0 almost, please fix: >> >> Two issues to be fixed before any further release: >> - remove $Date SVN variables > > Replacing with $Id $ now... > >> - ensure Implementation-Build: is correctly populated (CP 24 should fix this) > > Don't you mean CP 23? Yes (hopefully - we'll soon find out if the fixes work everywhere!) > Gary > >> >>> [ ] -1 no because: >>> >>> This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. >>> >>> Changes: >>> o [POOL-208] Support Java 1.5 Generics in version 1.x. >>> >>> Thank you and happy new year, >>> Gary >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >>> Spring Batch in Action: http://bit.ly/bqpbCK >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-digester3 has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 12 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-digester3 : XML to Java Object Configuration - commons-digester3-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/digester/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html Work Name: build_apache-commons_commons-digester3 (Type: Build) Work ended in a state of : Failed Elapsed: 20 secs Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/digester] M2_HOME: /opt/maven2 - /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[28,26] package com.sun.mirror.util does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[37,15] cannot find symbol symbol: class AnnotationProcessor implements AnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[40,18] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[42,33] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[28,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[29,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[30,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[31,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[32,33] package com.sun.mirror.declaration does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[41,15] cannot find symbol symbol: class AnnotationProcessorFactory implements AnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[47,52] cannot find symbol symbol : class AnnotationTypeDeclaration location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[48,48] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/comm
Re: [VOTE] Release Commons Parent 23 based on RC4 (lazy consensus)
+1. Works with Commons Pool 1.x. For example: [INFO] --- buildnumber-maven-plugin:1.0:create (default) @ commons-pool --- [INFO] Checking for local modifications: skipped. [INFO] Updating project files from SCM: skipped. [INFO] Executing: cmd.exe /X /C "svn --non-interactive info" [INFO] Working directory: C:\svn\org\apache\commons\branches\pool-1.x [INFO] Storing buildNumber: 1227189 at timestamp: 1326162019912 [INFO] Executing: cmd.exe /X /C "svn --non-interactive info" [INFO] Working directory: C:\svn\org\apache\commons\branches\pool-1.x [INFO] Storing buildScmBranch: branches/POOL_1_X Tested with: svn, version 1.7.2-SlikSvn-1.7.2-X64 (SlikSvn/1.7.2) X64 compiled Dec 6 2011, 13:13:15 Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_29\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" Gary On Sun, Jan 8, 2012 at 6:17 AM, sebb wrote: > This is a VOTE to release commons-parent 23 based on RC4. > > As agreed previously, commons parent release votes operate on lazy > consensus, i.e. the vote is assumed to have passed if 72 hours have > elapsed without an objection. > > Changes since RC3: > The buildNumber profile is now activated unless the property > buildManager.skip=true > It no longer checks for the .svn directory. > > This is not perfect, but is better than CP22 and the plugin can now > easily be skipped if necessary. > > Release notes (including changes): > > https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-23-RC4/RELEASE-NOTES.txt > > Note: I did not update the Maven-3 section to configure the deploy > plugin, because I'm not able to test the change. > > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-23-RC4 > > Site: None. > > Maven artifacts: > > https://repository.apache.org/content/repositories/orgapachecommons-033/org/apache/commons/commons-parent/23/ > > [ ] -1 no, do not release it because ... > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Pool 1.6-RC4
On Mon, Jan 9, 2012 at 8:36 PM, sebb wrote: > On 10 January 2012 01:25, Gary Gregory wrote: >> On Mon, Jan 9, 2012 at 5:39 PM, sebb wrote: >>> On 9 January 2012 15:46, Gary Gregory wrote: Good day to you all: I have prepared Commons Pool 1.6-RC4. >>> >>> I checked files with the following MD5 hashes: >>> >>> 70a1573d13d76fa3bafe4ee163904e24 commons-pool-1.6-bin.tar.gz >>> a9b1b1faacbb81282f06e1e502e107d3 commons-pool-1.6-bin.zip >>> e370c052057cf0b880328d732f55c277 commons-pool-1.6-javadoc.jar >>> ff08a9ed698ec455d94a230a0084f155 commons-pool-1.6-sources.jar >>> ef08ea62cad838d4149e40b1eae06d9a commons-pool-1.6-src.tar.gz >>> 202a36a912f04b98ea10926962b4eab1 commons-pool-1.6-src.zip >>> 5ca02245c829422176d23fa530e919cc commons-pool-1.6.jar >>> 1f529ba9fb6b9a067ad7663a48931cb6 commons-pool-1.6.pom >>> There is NO change from RC3. >>> >>> RC3 and RC4 are identical. >>> This RC exists because I blew up the Nexus staging repository for RC3 and a new RC is needed for a clean release process. The only changes from 1.5.7 are the additions of generics and therefore requires Java 5. Tag: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC4/ Site: https://people.apache.org/builds/commons/pool/1.6/RC4/ Binaries: https://repository.apache.org/content/repositories/orgapachecommons-043/ >>> >>> Source archives agree with RC4 tag. The link above includes checksum files. [ ] +1 release it [X] +0 almost, please fix: >>> >>> Two issues to be fixed before any further release: >>> - remove $Date SVN variables >> >> Replacing with $Id $ now... OK, that's done. >> >>> - ensure Implementation-Build: is correctly populated (CP 24 should fix >>> this) >> >> Don't you mean CP 23? > > Yes (hopefully - we'll soon find out if the fixes work everywhere!) CP 23-SNAPSHOT works with Commons Pool trunk but I'm not sure yet if I want to cancel the RC for yet another RC... I'll see how it feels if I get clear headed in the AM from this cold. Gary > >> Gary >> >>> [ ] -1 no because: This VOTE is open for at least 72 hours, until Janurary 12 2011, 10:30 EST. Changes: o [POOL-208] Support Java 1.5 Generics in version 1.x. Thank you and happy new year, Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >> Spring Batch in Action: http://bit.ly/bqpbCK >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1229454 - in /commons/proper/pool/branches/POOL_1_X: checkstyle.xml doap_pool.rdf findbugs-exclude-filter.xml pom.xml
On 10 January 2012 02:46, wrote: > Author: ggregory > Date: Tue Jan 10 02:46:43 2012 > New Revision: 1229454 > > URL: http://svn.apache.org/viewvc?rev=1229454&view=rev > Log: > Use svn:keywords Id. > > Modified: > commons/proper/pool/branches/POOL_1_X/checkstyle.xml (props changed) > commons/proper/pool/branches/POOL_1_X/doap_pool.rdf (props changed) > commons/proper/pool/branches/POOL_1_X/findbugs-exclude-filter.xml (props > changed) > commons/proper/pool/branches/POOL_1_X/pom.xml (props changed) > > Propchange: commons/proper/pool/branches/POOL_1_X/checkstyle.xml > -- > --- svn:keywords (original) > +++ svn:keywords Tue Jan 10 02:46:43 2012 > @@ -1 +1 @@ > -Date Author Id Revision HeadURL No need to remove Revision; HeadURL can sometimes be useful > +Id > > Propchange: commons/proper/pool/branches/POOL_1_X/doap_pool.rdf > -- > --- svn:keywords (original) > +++ svn:keywords Tue Jan 10 02:46:43 2012 > @@ -1 +1 @@ > -Date Author Id Revision HeadURL > +Id > > Propchange: commons/proper/pool/branches/POOL_1_X/findbugs-exclude-filter.xml > -- > svn:keywords = Id > > Propchange: commons/proper/pool/branches/POOL_1_X/pom.xml > -- > svn:keywords = Id > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 331 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.189 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 11 seconds [INFO] Finished at: Tue Jan 10 05:29:50 UTC 2012 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.
