Re: [ALL] @authors tags
Henri Yandell wrote: > On Mon, Apr 4, 2011 at 10:31 PM, Henri Yandell wrote: >> On Mon, Apr 4, 2011 at 9:28 PM, Christian Grobmeier >> wrote: >>> On Mon, Apr 4, 2011 at 11:22 PM, Phil Steitz >>> wrote: On 4/4/11 2:18 PM, Torsten Curdt wrote: >> I thought we had settled on '@author Apache Software Foundation', > Did we? TBH I find that pretty pointless and nothing more than noise. > I'd be in favor of removing them all together. I agree with Torsten. I got stalled in DBCP/pool because at least some ppl thought we needed to get permission from all of the long gone @authors to nuke their tags. Personally, I am ready to just nuke 'em if others do not object. >>> >>> I am +1 for nuking and +1 for documenting the "no @author tags" decision >> >> +1, and done for Lang. > > Btw: > > for i in `find . -type f -name '*.java'`; do (echo 'g/@author/d'; echo > 'w') | ed $i; done > > and check with svn diff of course :) sed -i -s -e '/@author/d' `find . -type f -name '*.java'` SCNR :) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
- "Henri Yandell" a écrit : > On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory > wrote: > > On Apr 4, 2011, at 1:45, Simone Tripodi > wrote: > > > >> Hi Gary! > >> I honestly even thought about it, so sorry! :( Since Discovery > >> activity has not been hight since 2008, I just thought adding the > >> missing generics support and nothing more :( > >> I don't think that should be a blocking issue since we've been > >> "overlooked" them for a long time, BTW if we think the effort of > >> fixing the checkstyle warnings can help the component health, I'll > >> cancel this vote and rollout a new one as soon as I can. > >> WDYT? Many thanks in advance for your feedbacks! > >> Have a nice day, > >> Simo > > > > IMO a release should be a clean as possible. I also like the > release > > early release often pattern so you could fix it all next. I am not > > sure what your plans are for further releases. If you are working > > towards more releases toward a 1.0 then it's ok I suppose. > > I increasingly find that feels wrong. We're in the release > early/release often business and trying to over-polish not only > pushes > the release back, but it also decreases the release often as there > are > less items to do. > > Somewhere in my gut I feel it might be worse than that. There's a > "someone cares" level of quality to achieve, but minor imperfections > can drive community. The bugs in our software are our recruitment > drive, and getting rid of all of the low-hanging-fruit interferes > with > that. That seems insane if we put our business developer hats on, but > you have to remember that what we do also seems insane. I would never have thought about bugs as an incentive for newcomers. It does make sense. > > My take away on these internal gastric rumblings has been: > > * If you are the only committer actively working on a project; and > it's been that way for a while; then leave the warts. Focus on the > important subjects and get releases out. > * If you are newish to driving the project, fix the warnings. It's a > good practice and gets you into the code more. > * If there are lots of committers; fix some of the warnings. Lead by > example but don't do all the work. I think there is also another criterion: * if there is an overwhelming number of warnings, reduce it drastically to a manageable number There are two reasons for this criterion. The first reason is that when you have hundreds or thousands of javac/javadoc/eclipse/checkstyle/findbugs/clirr/Sebb warnings, it is easy to miss an important one hidden by numerous minor ones. The second reason is that when there are two many warnings, this may also drive wannabe committers away, either because they feel the current team is not interested in quality fixes or because they are afraid by the amount of work to fix things. Luc > > We have slowly increasing minutiae roadblocks to releases and I've > moved over the years from "it helps build quality" over to "it gets > in > the way of community development". > > Hen > > - > 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: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
On Tue, Apr 5, 2011 at 12:40 AM, wrote: > > - "Henri Yandell" a écrit : > >> On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory >> wrote: >> > On Apr 4, 2011, at 1:45, Simone Tripodi >> wrote: >> > >> >> Hi Gary! >> >> I honestly even thought about it, so sorry! :( Since Discovery >> >> activity has not been hight since 2008, I just thought adding the >> >> missing generics support and nothing more :( >> >> I don't think that should be a blocking issue since we've been >> >> "overlooked" them for a long time, BTW if we think the effort of >> >> fixing the checkstyle warnings can help the component health, I'll >> >> cancel this vote and rollout a new one as soon as I can. >> >> WDYT? Many thanks in advance for your feedbacks! >> >> Have a nice day, >> >> Simo >> > >> > IMO a release should be a clean as possible. I also like the >> release >> > early release often pattern so you could fix it all next. I am not >> > sure what your plans are for further releases. If you are working >> > towards more releases toward a 1.0 then it's ok I suppose. >> >> I increasingly find that feels wrong. We're in the release >> early/release often business and trying to over-polish not only >> pushes >> the release back, but it also decreases the release often as there >> are >> less items to do. >> >> Somewhere in my gut I feel it might be worse than that. There's a >> "someone cares" level of quality to achieve, but minor imperfections >> can drive community. The bugs in our software are our recruitment >> drive, and getting rid of all of the low-hanging-fruit interferes >> with >> that. That seems insane if we put our business developer hats on, but >> you have to remember that what we do also seems insane. > > I would never have thought about bugs as an incentive for newcomers. > > It does make sense. > >> >> My take away on these internal gastric rumblings has been: >> >> * If you are the only committer actively working on a project; and >> it's been that way for a while; then leave the warts. Focus on the >> important subjects and get releases out. >> * If you are newish to driving the project, fix the warnings. It's a >> good practice and gets you into the code more. >> * If there are lots of committers; fix some of the warnings. Lead by >> example but don't do all the work. > > I think there is also another criterion: > > * if there is an overwhelming number of warnings, reduce it drastically > to a manageable number > > There are two reasons for this criterion. The first reason is that when you > have > hundreds or thousands of javac/javadoc/eclipse/checkstyle/findbugs/clirr/Sebb > warnings, it is easy to miss an important one hidden by numerous minor ones. > The second reason is that when there are two many warnings, this may also > drive > wannabe committers away, either because they feel the current team is not > interested in quality fixes or because they are afraid by the amount of work > to > fix things. Agreed. It's not that fixing warnings are bad, it's that making them release blockers is an anti-pattern. The most painful thing btw is doing a new major version of a component - you get stuck in a "can't release" cycle. We need to solve that one, Lang 3.0 should have been pushing out monthly alphas (on apache.org and in Maven). Gary - that's my major advice for Commons Codec 2.0. Plan on an alpha release every month. Even pick the recurring day. Shove it through and keep it fast. Get the alphas on the Maven repos. Don't allow things to block the monthly release beyond Legal and badly fubar. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ALL] @version tag :)
Hi all guys, after the @author tag, I'm here to ask to clarify *to me* how @version shall be used in Commons :) I saw various usage across components: - In [digester] we just use $Id$ on top of the license header; - In [pool] we often used @version $Id$ in the class javadoc; - In [discovery] we mixed usage of @version $Id$, @version $Revision$ and @version $Revision$ $Date$ Which one fits better for our components? I'd say that @version $Id$ is the most complete, but let's reason about it together :P Since I'm taking care of [discovery], I'd like to fix once for all these minor issues :) Many thanks in advance, have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Very late, but I've been a tad busy in the new-parent department. Generally I agree with Phil's email. I don't really care though - I recognize that my main pain with Nexus is a) the experience to know not to trust magical systems & b) not being full of energy to follow yet another build system change. I'm sure Maven 3.0 will be coming and I'll have to find the time to look into that. I've a bunch of JIRA plugins that are basically dead now because Atlassian moved to OpenSocial and I don't have the time/interest to read up on OpenSocial. This is the same - major shifts are costly and I'm now in the 'can't keep up'. My time is worth more to me than the novelty of the features :) Sucks to be me. What I do care about is releasing often. Which is farcical given how few times I've released. I want to release every month. Every week if possible. With minimal effort as I don't have the time to waste building releases for code that is fine enough. If that means pressing some magic button and Nexus takes care of things; fine. I'm loathe to read the 7 pages of "How to Release updated for Nexus", but I recognize that a lot of that is my own lacking. That said 97% of it is boring as it's really How to Release [the Nexus version] and not the 10 line page that its title implies it should be). [Side note; this is insane: http://maven.apache.org/guides/mini/guide-encryption.html - I vomit every time it's implied I should put passwords in the Maven settings file] End of opinion :) Hen On Tue, Mar 29, 2011 at 7:50 AM, Phil Steitz wrote: > After another nightmare by an RM who has not cut a release in a > while, I think we need to do something. The documentation on the > Commons web pages describes a process that works. I suggest that we > standardize on that process, adding some simple automation scripts > that RMs can choose to use or not to use for the manual steps and > stop fussing with Nexus or the maven release plugin. I cut an RC > last night in 25 minutes (about 15 of which were spent waiting for > the [pool] tests to complete) and will likely spend about that same > amount of time deploying the artifacts to dist/ and what remains of > our simple, file-and-directory-based replication infrastructure to > get maven artifacts pushed to the maven repos. I do use a simple > shell script to manage invoking the maven commands and copying files > around to reduce the required time from, say an hour, to 25 > minutes. The script is in svn. > > I prefer the "manual" approach for the following reasons: > > 1. I know what it does. Exactly, every time. I know that exactly > the binaries that we vote on get deployed to dist/ and exactly the > committed tag is used to build everything. The process includes > local generation of artifacts that I can inspect and test locally > and verify sigs. I know at each step exactly what is being pushed > where. > > 2. I know that it works. Every time. No pom-tweaking, > plugin-munging or other half-success management required. > > 3. It has no commercial / proprietary dependencies. The scripts > are optional and are in any case, ASF-licensed, committed to svn. > > I know others have different opinions on this. It could be we need > to support both ways of cutting releases. I would ask, however, > that those arguing for the "automagical" approach take a hard look > at how many volunteer hours are being spent trying to get > maven/nexus to be a release manager and how comparatively little > time those of us who take the "manual" approach spend getting our > releases built and deployed. While I certainly can't claim to > produce perfect artifacts (much less code :), I will also point out > that the only major release quality problem that we have had > recently was the inadvertent release of a [net] version while > fiddling with the release plugin. I don't at all buy the argument > that the manual approach is "error-prone" as it allows more and > better opportunities for inspection by the RM and community at each > stage. > > Phil > > - > 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: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
Hi Henri, I agree with that policy, that's why I pushed the digester-05-RC1 so quickly (also because we've overlooked this problems since 2008 :P), BW what really blocked the release was the fact that I didn't discuss which JIRA issues should had been fixed before pushing a new release. So, taking advantage of the time, since discovery is very small in size, compared to other components, I thought it would have been nice having a fresh new clean codebase. Do you have more suggestion for me before pushing a new RC2? I would more than glad to follow a generally approved policy. Thanks in advance, have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 9:52 AM, Henri Yandell wrote: > On Tue, Apr 5, 2011 at 12:40 AM, wrote: >> >> - "Henri Yandell" a écrit : >> >>> On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory >>> wrote: >>> > On Apr 4, 2011, at 1:45, Simone Tripodi >>> wrote: >>> > >>> >> Hi Gary! >>> >> I honestly even thought about it, so sorry! :( Since Discovery >>> >> activity has not been hight since 2008, I just thought adding the >>> >> missing generics support and nothing more :( >>> >> I don't think that should be a blocking issue since we've been >>> >> "overlooked" them for a long time, BTW if we think the effort of >>> >> fixing the checkstyle warnings can help the component health, I'll >>> >> cancel this vote and rollout a new one as soon as I can. >>> >> WDYT? Many thanks in advance for your feedbacks! >>> >> Have a nice day, >>> >> Simo >>> > >>> > IMO a release should be a clean as possible. I also like the >>> release >>> > early release often pattern so you could fix it all next. I am not >>> > sure what your plans are for further releases. If you are working >>> > towards more releases toward a 1.0 then it's ok I suppose. >>> >>> I increasingly find that feels wrong. We're in the release >>> early/release often business and trying to over-polish not only >>> pushes >>> the release back, but it also decreases the release often as there >>> are >>> less items to do. >>> >>> Somewhere in my gut I feel it might be worse than that. There's a >>> "someone cares" level of quality to achieve, but minor imperfections >>> can drive community. The bugs in our software are our recruitment >>> drive, and getting rid of all of the low-hanging-fruit interferes >>> with >>> that. That seems insane if we put our business developer hats on, but >>> you have to remember that what we do also seems insane. >> >> I would never have thought about bugs as an incentive for newcomers. >> >> It does make sense. >> >>> >>> My take away on these internal gastric rumblings has been: >>> >>> * If you are the only committer actively working on a project; and >>> it's been that way for a while; then leave the warts. Focus on the >>> important subjects and get releases out. >>> * If you are newish to driving the project, fix the warnings. It's a >>> good practice and gets you into the code more. >>> * If there are lots of committers; fix some of the warnings. Lead by >>> example but don't do all the work. >> >> I think there is also another criterion: >> >> * if there is an overwhelming number of warnings, reduce it drastically >> to a manageable number >> >> There are two reasons for this criterion. The first reason is that when you >> have >> hundreds or thousands of javac/javadoc/eclipse/checkstyle/findbugs/clirr/Sebb >> warnings, it is easy to miss an important one hidden by numerous minor ones. >> The second reason is that when there are two many warnings, this may also >> drive >> wannabe committers away, either because they feel the current team is not >> interested in quality fixes or because they are afraid by the amount of work >> to >> fix things. > > Agreed. It's not that fixing warnings are bad, it's that making them > release blockers is an anti-pattern. > > The most painful thing btw is doing a new major version of a component > - you get stuck in a "can't release" cycle. We need to solve that one, > Lang 3.0 should have been pushing out monthly alphas (on apache.org > and in Maven). > > Gary - that's my major advice for Commons Codec 2.0. Plan on an alpha > release every month. Even pick the recurring day. Shove it through and > keep it fast. Get the alphas on the Maven repos. Don't allow things to > block the monthly release beyond Legal and badly fubar. > > Hen > > - > 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] @version tag :)
> after the @author tag, I'm here to ask to clarify *to me* how @version > shall be used in Commons :) *for me* using using all these $Id$ $Revision$ $Date$ stuff does not make much sense at all. @version should show the version of artifact. cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
How about no @Version tag or $Id" ? Stephen On 5 April 2011 09:16, Simone Tripodi wrote: > Hi all guys, > after the @author tag, I'm here to ask to clarify *to me* how @version > shall be used in Commons :) > I saw various usage across components: > > - In [digester] we just use $Id$ on top of the license header; > - In [pool] we often used @version $Id$ in the class javadoc; > - In [discovery] we mixed usage of @version $Id$, @version $Revision$ > and @version $Revision$ $Date$ > > Which one fits better for our components? > I'd say that @version $Id$ is the most complete, but let's reason > about it together :P > > Since I'm taking care of [discovery], I'd like to fix once for all > these minor issues :) > Many thanks in advance, have a nice day! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.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: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell wrote: > Very late, but I've been a tad busy in the new-parent department. You didn't publish a POM yet, did you? ;-) > What I do care about is releasing often. Which is farcical given how > few times I've released. I want to release every month. Every week if > possible. With minimal effort as I don't have the time to waste > building releases for code that is fine enough. I wouldn't want to do that without Maven and the release-plugin anymore. At work, we've got a project where we do exactly that. And a release includes publication to Nexus, a web site and a lot of other stuff, everything with relatively generic pom's. Compared to the almost unmaintainable Ant scripts with their thousands of lines that we used in the past, it is a lot better. In the special case of Apache, there are unfortunately some minor glitches. One is caused by the fact that we europeans are redirected to the european SVN mirror, rather than the original in the US. There is a workaround and I tend to forget it all the time. (I also do Apache releases rarely.) Another problem is the use of https URL's, although that should be handled in the parent POM nowadays, for both Maven 2 and 3. > [Side note; this is insane: > http://maven.apache.org/guides/mini/guide-encryption.html - I vomit > every time it's implied I should put passwords in the Maven settings > file] Totally agreed! Jochen -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
$id is not of interest for me. $id information can easily be found with svn blame/history. For me it can be nuked out - same for @version, i want @since instead On Tue, Apr 5, 2011 at 10:28 AM, Stephen Colebourne wrote: > How about no @Version tag or $Id" ? > Stephen > > On 5 April 2011 09:16, Simone Tripodi wrote: >> Hi all guys, >> after the @author tag, I'm here to ask to clarify *to me* how @version >> shall be used in Commons :) >> I saw various usage across components: >> >> - In [digester] we just use $Id$ on top of the license header; >> - In [pool] we often used @version $Id$ in the class javadoc; >> - In [discovery] we mixed usage of @version $Id$, @version $Revision$ >> and @version $Revision$ $Date$ >> >> Which one fits better for our components? >> I'd say that @version $Id$ is the most complete, but let's reason >> about it together :P >> >> Since I'm taking care of [discovery], I'd like to fix once for all >> these minor issues :) >> Many thanks in advance, have a nice day! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.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 > > -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
On Tue, Apr 5, 2011 at 10:28 AM, Torsten Curdt wrote: > @version should show the version of artifact. Isnt this the intention of @since? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
Hi all guys! @Torsten: I agree, question is that I have never understood why the common usage is putting SVN tags in @version javadoc, so since I noticed a mixed usage, I wondered which one is the commonly used; @Christian: I intended @version, because existing source have *a lot* of that tag; for @since instead the common usage seems to be correct BTW I would be +1 for NO @version and putting only @since Danke, alles gute! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 10:39 AM, Christian Grobmeier wrote: > On Tue, Apr 5, 2011 at 10:28 AM, Torsten Curdt wrote: >> @version should show the version of artifact. > > Isnt this the intention of @since? > > - > 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
[discovery] org.apache.commons.discovery.log?!?
Hi all guys, since I'm in the middle of the process of [discovery] review, I'd like to discuss a little about the 'log' package[1]: It is a commons-logging implementation wrapper that I don't understand the reason why it has be implemented :( Moreover the 90% of classes that use a Log instance, have a static setter method... I'd tend to remove that package and use commons-logging in the traditional way, WDYT? Many thanks in advance! Simo [1] http://s.apache.org/eDl http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
> I'd tend to remove that package and use commons-logging in the > traditional way, WDYT? Probably we should get rid of commons-logging to. Its pretty outdated, slf4j is more widely used. If we want to stick within apache code, I would take log4j - slf4j has a wrapper for it. But commons logging has no more sense meanwhile. Or did i miss something? > Many thanks in advance! > Simo > > [1] http://s.apache.org/eDl > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
Hallo Christian :) I didn't want to change too much thing for this maintenance release, so making existing stuff in a stable version would be fine, but I agree that next versions should switch to more updated dependencies. BTW you help me on saying that a commons-logging wrapper doesn't have too much sense to be maintained, WDYT? Thanks in advance, alles gute, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 11:31 AM, Christian Grobmeier wrote: >> I'd tend to remove that package and use commons-logging in the >> traditional way, WDYT? > > Probably we should get rid of commons-logging to. Its pretty outdated, > slf4j is more widely used. > If we want to stick within apache code, I would take log4j - slf4j has > a wrapper for it. > > But commons logging has no more sense meanwhile. Or did i miss something? > > > >> Many thanks in advance! >> Simo >> >> [1] http://s.apache.org/eDl >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > > -- > http://www.grobmeier.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
Passwords in Maven settings file [Was: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1]
On 5 April 2011 09:32, Jochen Wiedmann wrote: > On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell wrote: > >> [Side note; this is insane: >> http://maven.apache.org/guides/mini/guide-encryption.html - I vomit >> every time it's implied I should put passwords in the Maven settings >> file] > > Totally agreed! There are a couple of ways around that. 1) Use settings-security.xml to store the real settings-security.xml on a removable device. 2) It would be nice if Maven supported a keyserver of some kind (cf. Pageant for Putty), but it does not. However one can use the element to point to a server that returns the passwords. I wrote a Java app that acts as a simple keyserver; of course that needs its own password. If the device is not present, or the server is not running, you get a warning message when starting Maven builds. [When using the keyserver I normally give it a dummy password, as that avoids the time delay when Maven looks for the server; however one still gets warnings] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
> I didn't want to change too much thing for this maintenance release, > so making existing stuff in a stable version would be fine, but I > agree that next versions should switch to more updated dependencies. OK :-) If you create an issue, I might be able to help a bit with the logging stuff > BTW you help me on saying that a commons-logging wrapper doesn't have > too much sense to be maintained, WDYT? Yes, I think so Cheers Christian > Thanks in advance, alles gute, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Tue, Apr 5, 2011 at 11:31 AM, Christian Grobmeier > wrote: >>> I'd tend to remove that package and use commons-logging in the >>> traditional way, WDYT? >> >> Probably we should get rid of commons-logging to. Its pretty outdated, >> slf4j is more widely used. >> If we want to stick within apache code, I would take log4j - slf4j has >> a wrapper for it. >> >> But commons logging has no more sense meanwhile. Or did i miss something? >> >> >> >>> Many thanks in advance! >>> Simo >>> >>> [1] http://s.apache.org/eDl >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> >> -- >> http://www.grobmeier.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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
On 5 April 2011 09:55, Simone Tripodi wrote: > Hi all guys! > > @Torsten: I agree, question is that I have never understood why the > common usage is putting SVN tags in @version javadoc, so since I > noticed a mixed usage, I wondered which one is the commonly used; > > @Christian: I intended @version, because existing source have *a lot* > of that tag; for @since instead the common usage seems to be correct > > BTW I would be +1 for NO @version and putting only @since I think the intention of the @version tag is to identify code that is not stored in SVN - e.g. in a source archive. $Revision$ and $Id$ (or even $HeadUrl) are fine in @version comments, however please don't use $Date$ as that is expressed in local time. This really messes up release checking as the dates in source archives don't match the dates in SVN tag checkouts unless the same timezone is being used. > Danke, alles gute! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Tue, Apr 5, 2011 at 10:39 AM, Christian Grobmeier > wrote: >> On Tue, Apr 5, 2011 at 10:28 AM, Torsten Curdt wrote: >>> @version should show the version of artifact. >> >> Isnt this the intention of @since? >> >> - >> 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: [discovery] org.apache.commons.discovery.log?!?
On 5 April 2011 10:31, Christian Grobmeier wrote: >> I'd tend to remove that package and use commons-logging in the >> traditional way, WDYT? > > Probably we should get rid of commons-logging to. Its pretty outdated, > slf4j is more widely used. It's not outdated, it is just very stable, so has not needed a release. AIUI it's also very widely used as a dependency. > If we want to stick within apache code, I would take log4j - slf4j has > a wrapper for it. > > But commons logging has no more sense meanwhile. Or did i miss something? See above. If it aint broke, don't fix it. > > >> Many thanks in advance! >> Simo >> >> [1] http://s.apache.org/eDl >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > > -- > http://www.grobmeier.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] @version tag :)
On Tue, Apr 5, 2011 at 10:39, Christian Grobmeier wrote: > On Tue, Apr 5, 2011 at 10:28 AM, Torsten Curdt wrote: >> @version should show the version of artifact. > > Isnt this the intention of @since? No, @since shows when the class/method was added to the API TBH I don't see a good reason for @version and don't use it myself ...but if you want to express what version you are talking about in the javadocs I would suggest to use the artifact version instead of the magic tokens. cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
>> Probably we should get rid of commons-logging to. Its pretty outdated, >> slf4j is more widely used. > > It's not outdated, it is just very stable, so has not needed a release. > AIUI it's also very widely used as a dependency. would you recommend anybody to use commons-logging? I wouldn't. It seems to be common to use slf4j instead. Its to early for the attic, but its going in that direction. log4j has still a huge user base but my feeling tells me people are heading to logback if nothing happens in logging world. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
On 5 April 2011 10:49, sebb wrote: > On 5 April 2011 10:31, Christian Grobmeier wrote: >>> I'd tend to remove that package and use commons-logging in the >>> traditional way, WDYT? >> >> Probably we should get rid of commons-logging to. Its pretty outdated, >> slf4j is more widely used. > > It's not outdated, it is just very stable, so has not needed a release. > AIUI it's also very widely used as a dependency. Agreed. [logging] is widely used and stable, if not much liked. No need to change it or remove it. Stephen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
>> Probably we should get rid of commons-logging to. Its pretty outdated, >> slf4j is more widely used. > > It's not outdated, it is just very stable, must ... refuse ... to ... get ... dragged ... into ... another ... logging ... discussion :) must ... close ... gmail :) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
Hi all guys! I think we all should agree on adopting a common policy, it shouldn't be dependent by who takes care of a component. I see different opinion about @version tag usage, so what's next? shall we calla vote to make a definitive decision? I'm worried that this discussion could degenerate in a lng thread :P Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 11:52 AM, Torsten Curdt wrote: > On Tue, Apr 5, 2011 at 10:39, Christian Grobmeier wrote: >> On Tue, Apr 5, 2011 at 10:28 AM, Torsten Curdt wrote: >>> @version should show the version of artifact. >> >> Isnt this the intention of @since? > > No, @since shows when the class/method was added to the API > > TBH I don't see a good reason for @version and don't use it myself > ...but if you want to express what version you are talking about in > the javadocs I would suggest to use the artifact version instead of > the magic tokens. > > cheers, > Torsten > > - > 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] @version tag :)
Simone Tripodi wrote: > Hi all guys! > > @Torsten: I agree, question is that I have never understood why the > common usage is putting SVN tags in @version javadoc, so since I > noticed a mixed usage, I wondered which one is the commonly used; > > @Christian: I intended @version, because existing source have *a lot* > of that tag; for @since instead the common usage seems to be correct > > BTW I would be +1 for NO @version and putting only @since +1 @version contains cruft - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
Simone Tripodi wrote: > Hi all guys, > since I'm in the middle of the process of [discovery] review, I'd like > to discuss a little about the 'log' package[1]: It is a > commons-logging implementation wrapper that I don't understand the > reason why it has be implemented :( > Moreover the 90% of classes that use a Log instance, have a static > setter method... > > I'd tend to remove that package and use commons-logging in the > traditional way, WDYT? IIRC discovery was also used as a jar ca be put into lib/endorsed. Having references there to commons-logging (or slf4j) would be fatal. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
>> BTW I would be +1 for NO @version and putting only @since +1 > @version contains cruft +1 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
Christian Grobmeier wrote: >> I'd tend to remove that package and use commons-logging in the >> traditional way, WDYT? > > Probably we should get rid of commons-logging to. Why? > Its pretty outdated, > slf4j is more widely used. Not here in commons. slf4j is not used at all. > If we want to stick within apache code, I would take log4j - slf4j has > a wrapper for it. > > But commons logging has no more sense meanwhile. Or did i miss something? What gave you that impression? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
Hi Jorg, [discovery] has already been depending to commons-logging (at least from 0.4, released on 2008), I just limited to upgrade it to latest stable version. Any suggestion? I filled a new jira issue to discuss about it DISCOVERY-15 Danke, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 12:09 PM, Jörg Schaible wrote: > Simone Tripodi wrote: > >> Hi all guys, >> since I'm in the middle of the process of [discovery] review, I'd like >> to discuss a little about the 'log' package[1]: It is a >> commons-logging implementation wrapper that I don't understand the >> reason why it has be implemented :( >> Moreover the 90% of classes that use a Log instance, have a static >> setter method... >> >> I'd tend to remove that package and use commons-logging in the >> traditional way, WDYT? > > IIRC discovery was also used as a jar ca be put into lib/endorsed. Having > references there to commons-logging (or slf4j) would be fatal. > > - Jörg > > > - > 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] @version tag :)
On 5 April 2011 10:44, sebb wrote: > On 5 April 2011 09:55, Simone Tripodi wrote: >> Hi all guys! >> >> @Torsten: I agree, question is that I have never understood why the >> common usage is putting SVN tags in @version javadoc, so since I >> noticed a mixed usage, I wondered which one is the commonly used; >> >> @Christian: I intended @version, because existing source have *a lot* >> of that tag; for @since instead the common usage seems to be correct >> >> BTW I would be +1 for NO @version and putting only @since > > I think the intention of the @version tag is to identify code that is > not stored in SVN - e.g. in a source archive. > > $Revision$ and $Id$ (or even $HeadUrl) are fine in @version comments, > however please don't use $Date$ as that is expressed in local time. > This really messes up release checking as the dates in source archives > don't match the dates in SVN tag checkouts unless the same timezone is > being used. In case it's not obvious, I am -1 to banning @version, as it can be useful +1 to banning $Date$ in @version - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
> In case it's not obvious, I am > > -1 to banning @version, as it can be useful Could you elaborate on such a scenario? > +1 to banning $Date$ in @version IMO all SCM magic tokens should be banned from @version ...or for that matter pretty much everywhere. @version should not be banned but only discouraged to use ...unless really really necessary. My 2 cents - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @authors tags
On 5 April 2011 08:23, Jörg Schaible wrote: > Henri Yandell wrote: > >> On Mon, Apr 4, 2011 at 10:31 PM, Henri Yandell wrote: >>> On Mon, Apr 4, 2011 at 9:28 PM, Christian Grobmeier >>> wrote: On Mon, Apr 4, 2011 at 11:22 PM, Phil Steitz wrote: > On 4/4/11 2:18 PM, Torsten Curdt wrote: >>> I thought we had settled on '@author Apache Software Foundation', >> Did we? TBH I find that pretty pointless and nothing more than noise. >> I'd be in favor of removing them all together. > I agree with Torsten. I got stalled in DBCP/pool because at least > some ppl thought we needed to get permission from all of the long > gone @authors to nuke their tags. Personally, I am ready to just > nuke 'em if others do not object. I am +1 for nuking and +1 for documenting the "no @author tags" decision >>> >>> +1, and done for Lang. >> >> Btw: >> >> for i in `find . -type f -name '*.java'`; do (echo 'g/@author/d'; echo >> 'w') | ed $i; done >> >> and check with svn diff of course :) > > sed -i -s -e '/@author/d' `find . -type f -name '*.java'` > > SCNR :) +1 to removing @author tags, but I think the removed names should be added to the developer / contributor list or a readme file somewhere. Even if their code has been completely replaced, they have participated in the development of the component. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
Simone Tripodi wrote: > Hi Jorg, > [discovery] has already been depending to commons-logging (at least > from 0.4, released on 2008), I just limited to upgrade it to latest > stable version. > Any suggestion? No, got for it. IMHO it's a bad idea anyway to put discovery into endorsed libs... - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
>> But commons logging has no more sense meanwhile. Or did i miss something? > > What gave you that impression? No releases, no question, no discussion on commons-logging. Lack of development on Log4J Slf4J has a rising community and active development. commons-logging imho is the wrapper for a slowly dying log4j and a not usable sdk log. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
On Tue, Apr 5, 2011 at 1:21 PM, Christian Grobmeier wrote: > No releases, no question, no discussion on commons-logging. > Lack of development on Log4J > Slf4J has a rising community and active development. > > commons-logging imho is the wrapper for a slowly dying log4j and a not > usable sdk log. Whenever I find myself forced to using slf4j (mostly, because some damned application library forces me to), then it is inevitablly slf4j-log4j. In other words, I am simply using slf4j in exactly the manner you describe: As yet another wrapper over log4j. And why is that? Because log4j is the very, very successful de-facto standard for logging and every application server I have used in the last 10 years (notable exception: Tomcat, which for some unknown reason ships jul logging, but not slf4j) ships with Log4j built in. Thanks god, they do. The only purpose of slf4j seems to be to cause unneeded fragmentation and discussions like this, Christian, which you are stirring now for the nth time (n > 5, for sure). Jochen -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
> The only purpose of slf4j seems to be to cause unneeded fragmentation > and discussions like this, Christian, which you are stirring now for > the nth time (n > 5, for sure). Well, then lets close this discussion. Just want to add I am not a huge fan of slf4j for the reason you mentioned above. Sorry for bringing it up again. Cheers > > Jochen > > > > > -- > I Am What I Am And That's All What I Yam (Popeye) > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
Hi Christian, Christian Grobmeier wrote: >>> But commons logging has no more sense meanwhile. Or did i miss >>> something? >> >> What gave you that impression? > > No releases, What else should a thin wrapper do? > no question, It simply works now. > no discussion on commons-logging. What for? > Lack of development on Log4J > Slf4J has a rising community and active development. 2 of ~100 deps use now slf4j in your development and all we need is slf4j- jcl. > commons-logging imho is the wrapper for a slowly dying log4j and a not > usable sdk log. It enables our customers to use the logger implementation of their choice (incl. their internal ones). Nothing more, nothing less. So why should we switch to a different wrapper? That does not make sense. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
I like using $Id$ fwiw Gary On Apr 5, 2011, at 4:29, Stephen Colebourne wrote: > How about no @Version tag or $Id" ? > Stephen > > On 5 April 2011 09:16, Simone Tripodi wrote: >> Hi all guys, >> after the @author tag, I'm here to ask to clarify *to me* how @version >> shall be used in Commons :) >> I saw various usage across components: >> >> - In [digester] we just use $Id$ on top of the license header; >> - In [pool] we often used @version $Id$ in the class javadoc; >> - In [discovery] we mixed usage of @version $Id$, @version $Revision$ >> and @version $Revision$ $Date$ >> >> Which one fits better for our components? >> I'd say that @version $Id$ is the most complete, but let's reason >> about it together :P >> >> Since I'm taking care of [discovery], I'd like to fix once for all >> these minor issues :) >> Many thanks in advance, have a nice day! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.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 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
On Apr 5, 2011, at 4:39, Christian Grobmeier wrote: > On Tue, Apr 5, 2011 at 10:28 AM, Torsten Curdt wrote: >> @version should show the version of artifact. > > Isnt this the intention of @since? @since should show when the item was added. Gary > > - > 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] @authors tags
authors/contributors are enlisted on the pom in the and section http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 1:07 PM, sebb wrote: > On 5 April 2011 08:23, Jörg Schaible wrote: >> Henri Yandell wrote: >> >>> On Mon, Apr 4, 2011 at 10:31 PM, Henri Yandell wrote: On Mon, Apr 4, 2011 at 9:28 PM, Christian Grobmeier wrote: > On Mon, Apr 4, 2011 at 11:22 PM, Phil Steitz > wrote: >> On 4/4/11 2:18 PM, Torsten Curdt wrote: I thought we had settled on '@author Apache Software Foundation', >>> Did we? TBH I find that pretty pointless and nothing more than noise. >>> I'd be in favor of removing them all together. >> I agree with Torsten. I got stalled in DBCP/pool because at least >> some ppl thought we needed to get permission from all of the long >> gone @authors to nuke their tags. Personally, I am ready to just >> nuke 'em if others do not object. > > I am +1 for nuking and +1 for documenting the "no @author tags" decision +1, and done for Lang. >>> >>> Btw: >>> >>> for i in `find . -type f -name '*.java'`; do (echo 'g/@author/d'; echo >>> 'w') | ed $i; done >>> >>> and check with svn diff of course :) >> >> sed -i -s -e '/@author/d' `find . -type f -name '*.java'` >> >> SCNR :) > > +1 to removing @author tags, but I think the removed names should be > added to the developer / contributor list or a readme file somewhere. > Even if their code has been completely replaced, they have > participated in the development of the component. > > - > 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] @version tag :)
> I like using $Id$ fwiw Could you also explain *why* you like it? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
On Apr 5, 2011, at 5:45, sebb wrote: > On 5 April 2011 09:55, Simone Tripodi wrote: >> Hi all guys! >> >> @Torsten: I agree, question is that I have never understood why the >> common usage is putting SVN tags in @version javadoc, so since I >> noticed a mixed usage, I wondered which one is the commonly used; >> >> @Christian: I intended @version, because existing source have *a lot* >> of that tag; for @since instead the common usage seems to be correct >> >> BTW I would be +1 for NO @version and putting only @since > > I think the intention of the @version tag is to identify code that is > not stored in SVN - e.g. in a source archive. > > $Revision$ and $Id$ (or even $HeadUrl) are fine in @version comments, > however please don't use $Date$ as that is expressed in local time. > This really messes up release checking as the dates in source archives > don't match the dates in SVN tag checkouts unless the same timezone is > being used. I've dealt with that before. It's a pain. I like using a version tag with Id for archeological purposes. Gary > >> Danke, alles gute! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Tue, Apr 5, 2011 at 10:39 AM, Christian Grobmeier >> wrote: >>> On Tue, Apr 5, 2011 at 10:28 AM, Torsten Curdt wrote: @version should show the version of artifact. >>> >>> Isnt this the intention of @since? >>> >>> - >>> 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 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] org.apache.commons.discovery.log?!?
I switched from commons-logging/log4j to slf4j/logback time ago just my 2 cents Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 1:55 PM, Jörg Schaible wrote: > Hi Christian, > > Christian Grobmeier wrote: > But commons logging has no more sense meanwhile. Or did i miss something? >>> >>> What gave you that impression? >> >> No releases, > > What else should a thin wrapper do? > >> no question, > > It simply works now. > >> no discussion on commons-logging. > > What for? > >> Lack of development on Log4J >> Slf4J has a rising community and active development. > > 2 of ~100 deps use now slf4j in your development and all we need is slf4j- > jcl. > >> commons-logging imho is the wrapper for a slowly dying log4j and a not >> usable sdk log. > > It enables our customers to use the logger implementation of their choice > (incl. their internal ones). Nothing more, nothing less. So why should we > switch to a different wrapper? That does not make sense. > > - Jörg > > > - > 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] @version tag :)
On Tue, Apr 5, 2011 at 6:19 AM, sebb wrote: > On 5 April 2011 10:44, sebb wrote: > > On 5 April 2011 09:55, Simone Tripodi wrote: > >> Hi all guys! > >> > >> @Torsten: I agree, question is that I have never understood why the > >> common usage is putting SVN tags in @version javadoc, so since I > >> noticed a mixed usage, I wondered which one is the commonly used; > >> > >> @Christian: I intended @version, because existing source have *a lot* > >> of that tag; for @since instead the common usage seems to be correct > >> > >> BTW I would be +1 for NO @version and putting only @since > > > > I think the intention of the @version tag is to identify code that is > > not stored in SVN - e.g. in a source archive. > > > > $Revision$ and $Id$ (or even $HeadUrl) are fine in @version comments, > > however please don't use $Date$ as that is expressed in local time. > > This really messes up release checking as the dates in source archives > > don't match the dates in SVN tag checkouts unless the same timezone is > > being used. > > In case it's not obvious, I am > > -1 to banning @version, as it can be useful > Since $Id$ contains the user ID we I would an @version that contains the revision number. I find that useful. I like to see a revision number in the manifest too (if it's not there already), like http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html Gary > +1 to banning $Date$ in @version > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
Re: [ALL] @version tag :)
The only benefit of the @version tag is that it shows up in javadoc. The $Id$, if at the top of the file, does not. It's nice to see the subversion number in API documents. I prefer that since it lets me track down the actual version in a repository. Paul On Tue, Apr 5, 2011 at 8:58 AM, Gary Gregory wrote: > On Tue, Apr 5, 2011 at 6:19 AM, sebb wrote: > > > On 5 April 2011 10:44, sebb wrote: > > > On 5 April 2011 09:55, Simone Tripodi > wrote: > > >> Hi all guys! > > >> > > >> @Torsten: I agree, question is that I have never understood why the > > >> common usage is putting SVN tags in @version javadoc, so since I > > >> noticed a mixed usage, I wondered which one is the commonly used; > > >> > > >> @Christian: I intended @version, because existing source have *a lot* > > >> of that tag; for @since instead the common usage seems to be correct > > >> > > >> BTW I would be +1 for NO @version and putting only @since > > > > > > I think the intention of the @version tag is to identify code that is > > > not stored in SVN - e.g. in a source archive. > > > > > > $Revision$ and $Id$ (or even $HeadUrl) are fine in @version comments, > > > however please don't use $Date$ as that is expressed in local time. > > > This really messes up release checking as the dates in source archives > > > don't match the dates in SVN tag checkouts unless the same timezone is > > > being used. > > > > In case it's not obvious, I am > > > > -1 to banning @version, as it can be useful > > > > Since $Id$ contains the user ID we I would an @version that contains the > revision number. I find that useful. I like to see a revision number in the > manifest too (if it's not there already), like > > http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html > > Gary > > > > +1 to banning $Date$ in @version > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > -- > Thank you, > Gary > > http://garygregory.wordpress.com/ > http://garygregory.com/ > http://people.apache.org/~ggregory/ > http://twitter.com/GaryGregory >
Re: [ALL] @version tag :)
On Tue, Apr 5, 2011 at 10:27 AM, Paul Benedict wrote: > The only benefit of the @version tag is that it shows up in javadoc. The > $Id$, if at the top of the file, does not. It's nice to see the subversion > number in API documents. I prefer that since it lets me track down the > actual version in a repository. > +1 to Id at the top. Are we coming to a consensus to be documented? Gary > > Paul > > On Tue, Apr 5, 2011 at 8:58 AM, Gary Gregory > wrote: > > > On Tue, Apr 5, 2011 at 6:19 AM, sebb wrote: > > > > > On 5 April 2011 10:44, sebb wrote: > > > > On 5 April 2011 09:55, Simone Tripodi > > wrote: > > > >> Hi all guys! > > > >> > > > >> @Torsten: I agree, question is that I have never understood why the > > > >> common usage is putting SVN tags in @version javadoc, so since I > > > >> noticed a mixed usage, I wondered which one is the commonly used; > > > >> > > > >> @Christian: I intended @version, because existing source have *a > lot* > > > >> of that tag; for @since instead the common usage seems to be correct > > > >> > > > >> BTW I would be +1 for NO @version and putting only @since > > > > > > > > I think the intention of the @version tag is to identify code that is > > > > not stored in SVN - e.g. in a source archive. > > > > > > > > $Revision$ and $Id$ (or even $HeadUrl) are fine in @version comments, > > > > however please don't use $Date$ as that is expressed in local time. > > > > This really messes up release checking as the dates in source > archives > > > > don't match the dates in SVN tag checkouts unless the same timezone > is > > > > being used. > > > > > > In case it's not obvious, I am > > > > > > -1 to banning @version, as it can be useful > > > > > > > Since $Id$ contains the user ID we I would an @version that contains the > > revision number. I find that useful. I like to see a revision number in > the > > manifest too (if it's not there already), like > > > > > http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html > > > > Gary > > > > > > > +1 to banning $Date$ in @version > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > -- > > Thank you, > > Gary > > > > http://garygregory.wordpress.com/ > > http://garygregory.com/ > > http://people.apache.org/~ggregory/ > > http://twitter.com/GaryGregory > > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
Re: [ALL] @version tag :)
>> -1 to banning @version, as it can be useful >> > > Since $Id$ contains the user ID we I would an @version that contains the > revision number. -1 to that from me This thread has quite a bikeshedding potential if people do not come up with reason *why* they think particular things are useful. I for one can say why I don't think it is useful... I see two kind of people here: users and developers. Developers have checked out the sources via svn and have easy access to the revision. User only care about release numbers. While I have nothing against having the release revision in the manifest, the revision in each and every class files seems anything but useful to me. Lots of noise and only very rarely useful to very few. Less is more, people. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
On 4/5/11 12:52 AM, Henri Yandell wrote: > On Tue, Apr 5, 2011 at 12:40 AM, wrote: >> - "Henri Yandell" a écrit : >> >>> On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory >>> wrote: On Apr 4, 2011, at 1:45, Simone Tripodi >>> wrote: > Hi Gary! > I honestly even thought about it, so sorry! :( Since Discovery > activity has not been hight since 2008, I just thought adding the > missing generics support and nothing more :( > I don't think that should be a blocking issue since we've been > "overlooked" them for a long time, BTW if we think the effort of > fixing the checkstyle warnings can help the component health, I'll > cancel this vote and rollout a new one as soon as I can. > WDYT? Many thanks in advance for your feedbacks! > Have a nice day, > Simo IMO a release should be a clean as possible. I also like the >>> release early release often pattern so you could fix it all next. I am not sure what your plans are for further releases. If you are working towards more releases toward a 1.0 then it's ok I suppose. >>> I increasingly find that feels wrong. We're in the release >>> early/release often business and trying to over-polish not only >>> pushes >>> the release back, but it also decreases the release often as there >>> are >>> less items to do. >>> >>> Somewhere in my gut I feel it might be worse than that. There's a >>> "someone cares" level of quality to achieve, but minor imperfections >>> can drive community. The bugs in our software are our recruitment >>> drive, and getting rid of all of the low-hanging-fruit interferes >>> with >>> that. That seems insane if we put our business developer hats on, but >>> you have to remember that what we do also seems insane. >> I would never have thought about bugs as an incentive for newcomers. >> >> It does make sense. >> >>> My take away on these internal gastric rumblings has been: >>> >>> * If you are the only committer actively working on a project; and >>> it's been that way for a while; then leave the warts. Focus on the >>> important subjects and get releases out. >>> * If you are newish to driving the project, fix the warnings. It's a >>> good practice and gets you into the code more. >>> * If there are lots of committers; fix some of the warnings. Lead by >>> example but don't do all the work. >> I think there is also another criterion: >> >> * if there is an overwhelming number of warnings, reduce it drastically >> to a manageable number >> >> There are two reasons for this criterion. The first reason is that when you >> have >> hundreds or thousands of javac/javadoc/eclipse/checkstyle/findbugs/clirr/Sebb >> warnings, it is easy to miss an important one hidden by numerous minor ones. >> The second reason is that when there are two many warnings, this may also >> drive >> wannabe committers away, either because they feel the current team is not >> interested in quality fixes or because they are afraid by the amount of work >> to >> fix things. > Agreed. It's not that fixing warnings are bad, it's that making them > release blockers is an anti-pattern. +1 - but I don't recall us ever doing that, really. It took me several [pool] and [dbcp] releases to fill in all the missing javadoc (could be [dbcp] still has some) and while reviewers always pointed out the errors, I don't remember ever seeing a -1 based on checkstyle or even findbugs warnings. I would never -1 a release based on checkstyle errors alone. I agree with Luc's point though about too many broken windows masking the one where the rain is hitting the electrical stuff. Also, especially in Commons, like it or not, what we release are APIs and APIs are expressed in javadoc. The vast majority of what checkstyle complains about is missing javadoc. Some of that is "silly" but some points to significant documentation weakness and when you go to fix it, you see other errors that can really be confusing for users. So while I agree strongly with your point that checkstyle errors by themselves should never be release blockers, I hope we can summon the energy to "raise all the boats" to a decent level of quality over time and then just keep them there. > The most painful thing btw is doing a new major version of a component > - you get stuck in a "can't release" cycle. We need to solve that one, > Lang 3.0 should have been pushing out monthly alphas (on apache.org > and in Maven). Is that because of checkstyle warnings? What is stopping you pushing out the alphas? > Gary - that's my major advice for Commons Codec 2.0. Plan on an alpha > release every month. Even pick the recurring day. Shove it through and > keep it fast. Get the alphas on the Maven repos. Don't allow things to > block the monthly release beyond Legal and badly fubar. The only problem with that approach is how to communicate effectively with users so they know the API is not yet stable (until it is). Same issue with [lang] 3. Otherwise, there is no
Re: [ALL] @version tag :)
On Tue, Apr 5, 2011 at 4:35 PM, Torsten Curdt wrote: >>> -1 to banning @version, as it can be useful >>> >> >> Since $Id$ contains the user ID we I would an @version that contains the >> revision number. > > -1 to that from me -1 from me too I never have seen a reason to include this information. I can easily get the svn history if I need that kind of information. >...Lots of noise.. > Less is more, people. well said. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
On 4/5/11 3:25 AM, Torsten Curdt wrote: >> In case it's not obvious, I am >> >> -1 to banning @version, as it can be useful > Could you elaborate on such a scenario? > >> +1 to banning $Date$ in @version > IMO all SCM magic tokens should be banned from @version ...or for that > matter pretty much everywhere. As Java developers, we so rarely get to use $ in our code, so it would be a shame to see these little gems vanish from our sources ;) I honestly don't care. I have looked at $Date$ before to lazily see when a file was last modified, but that is unreliable and it is very easy to get that info from svn, so I am fine dropping all these little tokens from sources. I don't think we need a Commons-wide policy, though. Those who are bothered by them can remove them and no one seems likely to complain based on this thread. > @version should not be banned but only discouraged to use ...unless > really really necessary. Agreed - energy should go into making sure @since is there and correct. Phil > My 2 cents > > - > 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] @version tag :)
> As Java developers, we so rarely get to use $ in our code, so it > would be a shame to see these little gems vanish from our sources > ;) LOL - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @authors tags
The author information in the pom file is also redundant - it already exists in greater detail in the commit logs. -Adrian On 4/5/2011 5:31 AM, Simone Tripodi wrote: authors/contributors are enlisted on the pom in the and section http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 1:07 PM, sebb wrote: On 5 April 2011 08:23, Jörg Schaible wrote: Henri Yandell wrote: On Mon, Apr 4, 2011 at 10:31 PM, Henri Yandell wrote: On Mon, Apr 4, 2011 at 9:28 PM, Christian Grobmeier wrote: On Mon, Apr 4, 2011 at 11:22 PM, Phil Steitz wrote: On 4/4/11 2:18 PM, Torsten Curdt wrote: I thought we had settled on '@author Apache Software Foundation', Did we? TBH I find that pretty pointless and nothing more than noise. I'd be in favor of removing them all together. I agree with Torsten. I got stalled in DBCP/pool because at least some ppl thought we needed to get permission from all of the long gone @authors to nuke their tags. Personally, I am ready to just nuke 'em if others do not object. I am +1 for nuking and +1 for documenting the "no @author tags" decision +1, and done for Lang. Btw: for i in `find . -type f -name '*.java'`; do (echo 'g/@author/d'; echo 'w') | ed $i; done and check with svn diff of course :) sed -i -s -e '/@author/d' `find . -type f -name '*.java'` SCNR :) +1 to removing @author tags, but I think the removed names should be added to the developer / contributor list or a readme file somewhere. Even if their code has been completely replaced, they have participated in the development of the component. - 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] @authors tags
On Tue, Apr 5, 2011 at 5:35 PM, Adrian Crum wrote: > The author information in the pom file is also redundant - it already exists > in greater detail in the commit logs. 1.) Authors aren't necessarily committers. That's what the "contributors" section in the POM is for. 2.) Commit logs contain the authors user ID. Nothing less, but also nothing more. The POM allows to specify full name, email, timezone information, and the like. 3.) You aren't actually proposing that we grep the complete Apache commit logs in order to create a page like http://commons.apache.org/discovery/team-list.html dynamically, are you? Considering the multitude of projects and the frequency of running "mvn site", that would most likely kill the SVN server. -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @authors tags
I didn't propose anything - I simply stated that the information is redundant. Having all of that author information in the pom file is unnecessary, in my opinion. If I'm researching source code, all I care about is what was changed and why. The author of the change is inconsequential. If I really need to know who wrote the change I can follow the path from the commit log to the Jira issue to the contributor of the patch. In OFBiz we eliminated all author information from the source code and no one has missed it. We don't keep it on the website either. -Adrian On 4/5/2011 8:41 AM, Jochen Wiedmann wrote: On Tue, Apr 5, 2011 at 5:35 PM, Adrian Crum wrote: The author information in the pom file is also redundant - it already exists in greater detail in the commit logs. 1.) Authors aren't necessarily committers. That's what the "contributors" section in the POM is for. 2.) Commit logs contain the authors user ID. Nothing less, but also nothing more. The POM allows to specify full name, email, timezone information, and the like. 3.) You aren't actually proposing that we grep the complete Apache commit logs in order to create a page like http://commons.apache.org/discovery/team-list.html dynamically, are you? Considering the multitude of projects and the frequency of running "mvn site", that would most likely kill the SVN server. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Passwords in Maven settings file [Was: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1]
On Tue, Apr 5, 2011 at 2:37 AM, sebb wrote: > On 5 April 2011 09:32, Jochen Wiedmann wrote: >> On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell wrote: >> >>> [Side note; this is insane: >>> http://maven.apache.org/guides/mini/guide-encryption.html - I vomit >>> every time it's implied I should put passwords in the Maven settings >>> file] >> >> Totally agreed! > > There are a couple of ways around that. > > 1) Use settings-security.xml to store the real > settings-security.xml on a removable device. Vomiting more :) At least I know when I physically lose my laptop. The docs also need to be pushing "encrypted removable device" more. It's taken as read that people will do that. > 2) It would be nice if Maven supported a keyserver of some kind (cf. > Pageant for Putty), but it does not. However one can use the > element to point to a server that returns the passwords. > I wrote a Java app that acts as a simple keyserver; of course that > needs its own password. > > If the device is not present, or the server is not running, you get a > warning message when starting Maven builds. > [When using the keyserver I normally give it a dummy password, as that > avoids the time delay when Maven looks for the server; however one > still gets warnings] Entering at the command line is fine for me. :) Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @authors tags
What we need is yet another maven plugin (YAMP)! :) Gary On Apr 5, 2011, at 11:35, Adrian Crum wrote: > The author information in the pom file is also redundant - it already exists > in greater detail in the commit logs. > > -Adrian > > On 4/5/2011 5:31 AM, Simone Tripodi wrote: >> authors/contributors are enlisted on the pom in the and >> section >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Tue, Apr 5, 2011 at 1:07 PM, sebb wrote: >>> On 5 April 2011 08:23, Jörg Schaible wrote: Henri Yandell wrote: > On Mon, Apr 4, 2011 at 10:31 PM, Henri Yandell wrote: >> On Mon, Apr 4, 2011 at 9:28 PM, Christian Grobmeier >> wrote: >>> On Mon, Apr 4, 2011 at 11:22 PM, Phil Steitz >>> wrote: On 4/4/11 2:18 PM, Torsten Curdt wrote: >> I thought we had settled on '@author Apache Software Foundation', > Did we? TBH I find that pretty pointless and nothing more than noise. > I'd be in favor of removing them all together. I agree with Torsten. I got stalled in DBCP/pool because at least some ppl thought we needed to get permission from all of the long gone @authors to nuke their tags. Personally, I am ready to just nuke 'em if others do not object. >>> I am +1 for nuking and +1 for documenting the "no @author tags" decision >> +1, and done for Lang. > Btw: > > for i in `find . -type f -name '*.java'`; do (echo 'g/@author/d'; echo > 'w') | ed $i; done > > and check with svn diff of course :) sed -i -s -e '/@author/d' `find . -type f -name '*.java'` SCNR :) >>> +1 to removing @author tags, but I think the removed names should be >>> added to the developer / contributor list or a readme file somewhere. >>> Even if their code has been completely replaced, they have >>> participated in the development of the component. >>> >>> - >>> 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 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
On Apr 5, 2011, at 3:53, Henri Yandell wrote: > On Tue, Apr 5, 2011 at 12:40 AM, wrote: >> >> - "Henri Yandell" a écrit : >> >>> On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory >>> wrote: On Apr 4, 2011, at 1:45, Simone Tripodi >>> wrote: > Hi Gary! > I honestly even thought about it, so sorry! :( Since Discovery > activity has not been hight since 2008, I just thought adding the > missing generics support and nothing more :( > I don't think that should be a blocking issue since we've been > "overlooked" them for a long time, BTW if we think the effort of > fixing the checkstyle warnings can help the component health, I'll > cancel this vote and rollout a new one as soon as I can. > WDYT? Many thanks in advance for your feedbacks! > Have a nice day, > Simo IMO a release should be a clean as possible. I also like the >>> release early release often pattern so you could fix it all next. I am not sure what your plans are for further releases. If you are working towards more releases toward a 1.0 then it's ok I suppose. >>> >>> I increasingly find that feels wrong. We're in the release >>> early/release often business and trying to over-polish not only >>> pushes >>> the release back, but it also decreases the release often as there >>> are >>> less items to do. >>> >>> Somewhere in my gut I feel it might be worse than that. There's a >>> "someone cares" level of quality to achieve, but minor imperfections >>> can drive community. The bugs in our software are our recruitment >>> drive, and getting rid of all of the low-hanging-fruit interferes >>> with >>> that. That seems insane if we put our business developer hats on, but >>> you have to remember that what we do also seems insane. >> >> I would never have thought about bugs as an incentive for newcomers. >> >> It does make sense. >> >>> >>> My take away on these internal gastric rumblings has been: >>> >>> * If you are the only committer actively working on a project; and >>> it's been that way for a while; then leave the warts. Focus on the >>> important subjects and get releases out. >>> * If you are newish to driving the project, fix the warnings. It's a >>> good practice and gets you into the code more. >>> * If there are lots of committers; fix some of the warnings. Lead by >>> example but don't do all the work. >> >> I think there is also another criterion: >> >> * if there is an overwhelming number of warnings, reduce it drastically >> to a manageable number >> >> There are two reasons for this criterion. The first reason is that when you >> have >> hundreds or thousands of javac/javadoc/eclipse/checkstyle/findbugs/clirr/Sebb >> warnings, it is easy to miss an important one hidden by numerous minor ones. >> The second reason is that when there are two many warnings, this may also >> drive >> wannabe committers away, either because they feel the current team is not >> interested in quality fixes or because they are afraid by the amount of work >> to >> fix things. > > Agreed. It's not that fixing warnings are bad, it's that making them > release blockers is an anti-pattern. > > The most painful thing btw is doing a new major version of a component > - you get stuck in a "can't release" cycle. We need to solve that one, > Lang 3.0 should have been pushing out monthly alphas (on apache.org > and in Maven). > > Gary - that's my major advice for Commons Codec 2.0. Plan on an alpha > release every month. Even pick the recurring day. Shove it through and > keep it fast. Get the alphas on the Maven repos. Don't allow things to > block the monthly release beyond Legal and badly fubar. > I like it. Do alphas go through the same vote process? Gary > Hen > > - > 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: Fixing all warnings? [Was: [VOTE] Release Apache Commons Discovery 0.5-RC1]
On 4/5/11 10:14 AM, Gary Gregory wrote: > On Apr 5, 2011, at 3:53, Henri Yandell wrote: > >> On Tue, Apr 5, 2011 at 12:40 AM, wrote: >>> - "Henri Yandell" a écrit : >>> On Mon, Apr 4, 2011 at 5:13 AM, Gary Gregory wrote: > On Apr 4, 2011, at 1:45, Simone Tripodi wrote: >> Hi Gary! >> I honestly even thought about it, so sorry! :( Since Discovery >> activity has not been hight since 2008, I just thought adding the >> missing generics support and nothing more :( >> I don't think that should be a blocking issue since we've been >> "overlooked" them for a long time, BTW if we think the effort of >> fixing the checkstyle warnings can help the component health, I'll >> cancel this vote and rollout a new one as soon as I can. >> WDYT? Many thanks in advance for your feedbacks! >> Have a nice day, >> Simo > IMO a release should be a clean as possible. I also like the release > early release often pattern so you could fix it all next. I am not > sure what your plans are for further releases. If you are working > towards more releases toward a 1.0 then it's ok I suppose. I increasingly find that feels wrong. We're in the release early/release often business and trying to over-polish not only pushes the release back, but it also decreases the release often as there are less items to do. Somewhere in my gut I feel it might be worse than that. There's a "someone cares" level of quality to achieve, but minor imperfections can drive community. The bugs in our software are our recruitment drive, and getting rid of all of the low-hanging-fruit interferes with that. That seems insane if we put our business developer hats on, but you have to remember that what we do also seems insane. >>> I would never have thought about bugs as an incentive for newcomers. >>> >>> It does make sense. >>> My take away on these internal gastric rumblings has been: * If you are the only committer actively working on a project; and it's been that way for a while; then leave the warts. Focus on the important subjects and get releases out. * If you are newish to driving the project, fix the warnings. It's a good practice and gets you into the code more. * If there are lots of committers; fix some of the warnings. Lead by example but don't do all the work. >>> I think there is also another criterion: >>> >>> * if there is an overwhelming number of warnings, reduce it drastically >>> to a manageable number >>> >>> There are two reasons for this criterion. The first reason is that when you >>> have >>> hundreds or thousands of >>> javac/javadoc/eclipse/checkstyle/findbugs/clirr/Sebb >>> warnings, it is easy to miss an important one hidden by numerous minor ones. >>> The second reason is that when there are two many warnings, this may also >>> drive >>> wannabe committers away, either because they feel the current team is not >>> interested in quality fixes or because they are afraid by the amount of >>> work to >>> fix things. >> Agreed. It's not that fixing warnings are bad, it's that making them >> release blockers is an anti-pattern. >> >> The most painful thing btw is doing a new major version of a component >> - you get stuck in a "can't release" cycle. We need to solve that one, >> Lang 3.0 should have been pushing out monthly alphas (on apache.org >> and in Maven). >> >> Gary - that's my major advice for Commons Codec 2.0. Plan on an alpha >> release every month. Even pick the recurring day. Shove it through and >> keep it fast. Get the alphas on the Maven repos. Don't allow things to >> block the monthly release beyond Legal and badly fubar. >> > I like it. Do alphas go through the same vote process? Yes, anything we release requires a VOTE. Phil > Gary > >> Hen >> >> - >> 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: [pool] Site update
Hi Phil, sorry if I'm late on it due to the [discovery] (I'd like to put an end at least to one thing I touch :P) but I would suggest following the Mark Thomas' suggestion: - move the current /trunk on a branch, something like POOL_2_FEATURE; - move the current POOL_1_X to /trunk; - push the site; - apply on /trunk the generics/enumerations from POOL_2_FEATURE; (I need 1 evening to replicate the modifications here) - release :P WDYT? Thanks in advance! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Apr 4, 2011 at 5:23 PM, Simone Tripodi wrote: > Hi Phil! > I'm at work now, but this evening at home I'll be able start taking > care of 0) and 1)! > > Just for the record: time ago, in the commons-pool wiki page, I > reported some points we already discussed in the ML, I hope they can > help you for designing the roadmap. > > Have a nice day! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Apr 4, 2011 at 5:14 PM, Phil Steitz wrote: >> On 4/4/11 7:19 AM, Simone Tripodi wrote: >>> Hi Phil, >>> I think I can be helpful there, but I din't understand which steps are >>> needed to get the trunk in a better order, I would be glad to fix it! >>> Thanks in advance! :) >> Thanks, Simo! >> >> After cleaning up my local checkout, I see now that things are not >> as messy as I thought. Here are some things we need to get sorted >> to get a reasonable site build working from trunk. >> >> 0) temporarily disable clirr, as there is no earlier version of the >> artifact to compare against >> 1) fix many javadoc and checkstyle warnings >> 2) post-1.5.6 release cleanup - update changes.xml, release notes, >> doap, javadoc nav link >> >> I will take care of 2) if you don't beat me to it. Item 1) is not >> strictly necessary, but getting things a little better would be good >> before publishing the javadoc on the site. >> >> We should probably also add some text on the main page explaining >> the plan for 2.0. >> >> Phil >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Mon, Apr 4, 2011 at 4:08 PM, Phil Steitz wrote: On 4/4/11 4:25 AM, sebb wrote: > On 4 April 2011 07:36, Phil Steitz wrote: >> I will be sending the 1.5.6 release announcement shortly. When >> updating the pool website, I started by trying to use trunk, but >> found the output confusing, since we are in process of changing the >> groupId and package name. I decided, therefore, to publish based on >> the updated 1_5_X branch. Once we get the 2.0 sources consolidated >> and site build repaired, we can publish an updated version. The >> site now being replicated has correct download page, javadoc links, >> and reports corresponding to the 1.5.6 release. > I thought that is what people did anyway - generate the site from the tag? > I usually update trunk and generate the public site from trunk, so it reflects current development. The tag won't work in general, because any post-release updates - most importantly the version number - won't be reflected in the tag. In any case, the [pool] site now reflects the 1.5.x branch. Once we get our 2.0 house in a little better order, I think the site should be updated to reflect the new stuff. Phil >> Phil >> >> - >> 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 >>> - >>> 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: [pool] Site update
On 05/04/2011 20:05, Simone Tripodi wrote: > Hi Phil, > sorry if I'm late on it due to the [discovery] (I'd like to put an end > at least to one thing I touch :P) but I would suggest following the > Mark Thomas' suggestion: > > - move the current /trunk on a branch, something like POOL_2_FEATURE; > - move the current POOL_1_X to /trunk; > - push the site; > - apply on /trunk the generics/enumerations from POOL_2_FEATURE; (I > need 1 evening to replicate the modifications here) > - release :P > > WDYT? Thanks in advance! Release an alpha, +1. Release it labelled as anything else, -1; there are other API breaking changes we need to make before we release this as 2.0. Mark > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Apr 4, 2011 at 5:23 PM, Simone Tripodi > wrote: >> Hi Phil! >> I'm at work now, but this evening at home I'll be able start taking >> care of 0) and 1)! >> >> Just for the record: time ago, in the commons-pool wiki page, I >> reported some points we already discussed in the ML, I hope they can >> help you for designing the roadmap. >> >> Have a nice day! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Mon, Apr 4, 2011 at 5:14 PM, Phil Steitz wrote: >>> On 4/4/11 7:19 AM, Simone Tripodi wrote: Hi Phil, I think I can be helpful there, but I din't understand which steps are needed to get the trunk in a better order, I would be glad to fix it! Thanks in advance! :) >>> Thanks, Simo! >>> >>> After cleaning up my local checkout, I see now that things are not >>> as messy as I thought. Here are some things we need to get sorted >>> to get a reasonable site build working from trunk. >>> >>> 0) temporarily disable clirr, as there is no earlier version of the >>> artifact to compare against >>> 1) fix many javadoc and checkstyle warnings >>> 2) post-1.5.6 release cleanup - update changes.xml, release notes, >>> doap, javadoc nav link >>> >>> I will take care of 2) if you don't beat me to it. Item 1) is not >>> strictly necessary, but getting things a little better would be good >>> before publishing the javadoc on the site. >>> >>> We should probably also add some text on the main page explaining >>> the plan for 2.0. >>> >>> Phil Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Apr 4, 2011 at 4:08 PM, Phil Steitz wrote: > On 4/4/11 4:25 AM, sebb wrote: >> On 4 April 2011 07:36, Phil Steitz wrote: >>> I will be sending the 1.5.6 release announcement shortly. When >>> updating the pool website, I started by trying to use trunk, but >>> found the output confusing, since we are in process of changing the >>> groupId and package name. I decided, therefore, to publish based on >>> the updated 1_5_X branch. Once we get the 2.0 sources consolidated >>> and site build repaired, we can publish an updated version. The >>> site now being replicated has correct download page, javadoc links, >>> and reports corresponding to the 1.5.6 release. >> I thought that is what people did anyway - generate the site from the >> tag? >> > I usually update trunk and generate the public site from trunk, so > it reflects current development. The tag won't work in general, > because any post-release updates - most importantly the version > number - won't be reflected in the tag. In any case, the [pool] > site now reflects the 1.5.x branch. Once we get our 2.0 house in a > little better order, I think the site should be updated to reflect > the new stuff. > > Phil >>> Phil >>> >>> - >>> 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 > > - 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,
Re: [ALL] @authors tags
I guess I'll never understand the hate for this tag. If you don't like it, don't use it. But please don't remove the name of other developers without their consent. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
Le 05/04/2011 11:59, Simone Tripodi a écrit : Hi all guys! I think we all should agree on adopting a common policy, it shouldn't be dependent by who takes care of a component. I see different opinion about @version tag usage, so what's next? shall we calla vote to make a definitive decision? I'm worried that this discussion could degenerate in a lng thread :P Simo Well with this and the @author tags you've hit a nerve. Please wait a bit before starting the next discussion about brace placement, indentation size or Git migration ;) Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
I tend to use this syntax: @version $Revision$, $Date$ I don't use $Id$ because it's a bit long and verbose, but I don't mind if someone else uses it. Git proponents will probably argue to remove this tag because it interferes with the checksumming. Emmanuel Bourg Le 05/04/2011 10:16, Simone Tripodi a écrit : Hi all guys, after the @author tag, I'm here to ask to clarify *to me* how @version shall be used in Commons :) I saw various usage across components: - In [digester] we just use $Id$ on top of the license header; - In [pool] we often used @version $Id$ in the class javadoc; - In [discovery] we mixed usage of @version $Id$, @version $Revision$ and @version $Revision$ $Date$ Which one fits better for our components? I'd say that @version $Id$ is the most complete, but let's reason about it together :P Since I'm taking care of [discovery], I'd like to fix once for all these minor issues :) Many thanks in advance, have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.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] @authors tags
If anyone wants their @author tag put back into Lang, then please feel free to do so; or if you don't have commit access send me an email and I'll gladly do it. Hen On Tue, Apr 5, 2011 at 12:40 PM, Emmanuel Bourg wrote: > I guess I'll never understand the hate for this tag. If you don't like it, > don't use it. But please don't remove the name of other developers without > their consent. > > Emmanuel Bourg > > - > 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] @version tag :)
On Tue, Apr 5, 2011 at 12:53 PM, Emmanuel Bourg wrote: > Le 05/04/2011 11:59, Simone Tripodi a écrit : >> >> Hi all guys! >> I think we all should agree on adopting a common policy, it shouldn't >> be dependent by who takes care of a component. >> I see different opinion about @version tag usage, so what's next? >> shall we calla vote to make a definitive decision? >> I'm worried that this discussion could degenerate in a lng thread :P >> Simo > > Well with this and the @author tags you've hit a nerve. Please wait a bit > before starting the next discussion about brace placement, indentation size > or Git migration ;) I want to see what's next! I can't wait a bit, that's FOREVER! Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @authors tags
I thought I sent this link previously, but I can no longer such an email: http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3c4039f65e.7020...@atg.com%3E Does anyone have thoughts on this? This is the rule I thought Apache was following across the board, which is to remove @author tags so that contributors have better protection. I am not aware the policy changed. If so, please let me know. Paul On Tue, Apr 5, 2011 at 3:13 PM, Henri Yandell wrote: > If anyone wants their @author tag put back into Lang, then please feel > free to do so; or if you don't have commit access send me an email and > I'll gladly do it. > > Hen > > On Tue, Apr 5, 2011 at 12:40 PM, Emmanuel Bourg wrote: > > I guess I'll never understand the hate for this tag. If you don't like > it, > > don't use it. But please don't remove the name of other developers > without > > their consent. > > > > Emmanuel Bourg > > > > - > > 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] @authors tags
On 4/5/11 1:17 PM, Paul Benedict wrote: > I thought I sent this link previously, but I can no longer such an email: > http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3c4039f65e.7020...@atg.com%3E > > Does anyone have thoughts on this? This is the rule I thought Apache was > following across the board, which is to remove @author tags so that > contributors have better protection. The board never said we needed to or should *remove* them, they just said usage was "discouraged." Since the time of that note, we have not added any, to my knowledge, in Commons. The problem is what to do with those that pre-date the change in ASF "policy." Seems the right thing to do is to ask people if they are OK having their tags removed. That is a PITA because many are long gone. So many have remained in the older component sources. Phil > I am not aware the policy changed. If so, please let me know. > > Paul > > On Tue, Apr 5, 2011 at 3:13 PM, Henri Yandell wrote: > >> If anyone wants their @author tag put back into Lang, then please feel >> free to do so; or if you don't have commit access send me an email and >> I'll gladly do it. >> >> Hen >> >> On Tue, Apr 5, 2011 at 12:40 PM, Emmanuel Bourg wrote: >>> I guess I'll never understand the hate for this tag. If you don't like >> it, >>> don't use it. But please don't remove the name of other developers >> without >>> their consent. >>> >>> Emmanuel Bourg >>> >>> - >>> 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] @version tag :)
HAHHAHA be ready guys, next will be maybe remembered as the longest thread in commons :D http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 5, 2011 at 10:14 PM, Henri Yandell wrote: > On Tue, Apr 5, 2011 at 12:53 PM, Emmanuel Bourg wrote: >> Le 05/04/2011 11:59, Simone Tripodi a écrit : >>> >>> Hi all guys! >>> I think we all should agree on adopting a common policy, it shouldn't >>> be dependent by who takes care of a component. >>> I see different opinion about @version tag usage, so what's next? >>> shall we calla vote to make a definitive decision? >>> I'm worried that this discussion could degenerate in a lng thread :P >>> Simo >> >> Well with this and the @author tags you've hit a nerve. Please wait a bit >> before starting the next discussion about brace placement, indentation size >> or Git migration ;) > > I want to see what's next! I can't wait a bit, that's FOREVER! > > Hen > > - > 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] @authors tags
On Tue, Apr 5, 2011 at 4:23 PM, Phil Steitz wrote: > On 4/5/11 1:17 PM, Paul Benedict wrote: > > I thought I sent this link previously, but I can no longer such an email: > > > http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3c4039f65e.7020...@atg.com%3E > > > > Does anyone have thoughts on this? This is the rule I thought Apache was > > following across the board, which is to remove @author tags so that > > contributors have better protection. > > The board never said we needed to or should *remove* them, they just > said usage was "discouraged." Since the time of that note, we have > not added any, to my knowledge, in Commons. The problem is what to > do with those that pre-date the change in ASF "policy." Seems the > right thing to do is to ask people if they are OK having their tags > removed. That is a PITA because many are long gone. So many have > remained in the older component sources. > This is misleading to someone new looking at the source: all I see are the names of people no one can find or who insist to keep their names in there regardless of merit? That does not make sense. If we remove/change, do it, we do not need permission to remove names from @author tags. Gary > > Phil > > I am not aware the policy changed. If so, please let me know. > > > > Paul > > > > On Tue, Apr 5, 2011 at 3:13 PM, Henri Yandell > wrote: > > > >> If anyone wants their @author tag put back into Lang, then please feel > >> free to do so; or if you don't have commit access send me an email and > >> I'll gladly do it. > >> > >> Hen > >> > >> On Tue, Apr 5, 2011 at 12:40 PM, Emmanuel Bourg > wrote: > >>> I guess I'll never understand the hate for this tag. If you don't like > >> it, > >>> don't use it. But please don't remove the name of other developers > >> without > >>> their consent. > >>> > >>> Emmanuel Bourg > >>> > >>> - > >>> 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 > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
Re:
Sorry - this is/was me being opinionated that Checkstyle doesn't report errors, it reports warnings. Hen On Mon, Apr 4, 2011 at 4:57 AM, Gary Gregory wrote: > Gary >> Warnings :) > > Hm. The top of the report says 0 warnings and 329 errors. > Gary > >> >> On Sun, Apr 3, 2011 at 7:29 PM, Gary Gregory wrote: >>> Any thoughts on fixing the 300+ checkstyle errors? >>> >>> Gary >>> >>> On Sun, Apr 3, 2011 at 5:11 PM, Simone Tripodi >>> wrote: >>> Hi all guys! we haven't released a new version of Apache Commons Discovery since 2008 (!!!), since I recently had to use it in a project I thought it would have been fine having at least the Java5 generics support. So, after 2 days of hard work - and thanks for feedbacks from dev community - I'm here to propose a new release, please cast your votes! Many thanks in advance to everybody will take part to the vote process, all the best, Simo Release notes: http://people.apache.org/builds/commons/discovery/0.5/RC1/RELEASE-NOTES.txt Tag: http://svn.apache.org/repos/asf/commons/proper/discovery/tags/DISCOVERY_0_5_RC1/ Site: http://people.apache.org/builds/commons/discovery/0.5/RC1/site/ Binaries: http://people.apache.org/builds/commons/discovery/0.5/RC1/staged/commons-discovery/commons-discovery/0.5/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> -- >>> Thank you, >>> Gary >>> >>> http://garygregory.wordpress.com/ >>> http://garygregory.com/ >>> http://people.apache.org/~ggregory/ >>> 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] @version tag :)
On 5 April 2011 21:04, Emmanuel Bourg wrote: > I tend to use this syntax: > > @version $Revision$, $Date$ Please don't use $Date$, because it makes checking releases much harder. > I don't use $Id$ because it's a bit long and verbose, but I don't mind if > someone else uses it. > > Git proponents will probably argue to remove this tag because it interferes > with the checksumming. > > > Emmanuel Bourg > > > > Le 05/04/2011 10:16, Simone Tripodi a écrit : >> >> Hi all guys, >> after the @author tag, I'm here to ask to clarify *to me* how @version >> shall be used in Commons :) >> I saw various usage across components: >> >> - In [digester] we just use $Id$ on top of the license header; >> - In [pool] we often used @version $Id$ in the class javadoc; >> - In [discovery] we mixed usage of @version $Id$, @version $Revision$ >> and @version $Revision$ $Date$ >> >> Which one fits better for our components? >> I'd say that @version $Id$ is the most complete, but let's reason >> about it together :P >> >> Since I'm taking care of [discovery], I'd like to fix once for all >> these minor issues :) >> Many thanks in advance, have a nice day! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.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 > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @authors tags
On 5 April 2011 21:36, Gary Gregory wrote: > On Tue, Apr 5, 2011 at 4:23 PM, Phil Steitz wrote: > >> On 4/5/11 1:17 PM, Paul Benedict wrote: >> > I thought I sent this link previously, but I can no longer such an email: >> > >> http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3c4039f65e.7020...@atg.com%3E >> > >> > Does anyone have thoughts on this? This is the rule I thought Apache was >> > following across the board, which is to remove @author tags so that >> > contributors have better protection. >> >> The board never said we needed to or should *remove* them, they just >> said usage was "discouraged." Since the time of that note, we have >> not added any, to my knowledge, in Commons. The problem is what to >> do with those that pre-date the change in ASF "policy." Seems the >> right thing to do is to ask people if they are OK having their tags >> removed. That is a PITA because many are long gone. So many have >> remained in the older component sources. >> > > This is misleading to someone new looking at the source: all I see are the > names of people no one can find or who insist to keep their names in there > regardless of merit? That does not make sense. If we remove/change, do it, > we do not need permission to remove names from @author tags. +1, but just in case the authors object, having their name in a readme or pom will address that. > Gary > > >> >> Phil >> > I am not aware the policy changed. If so, please let me know. >> > >> > Paul >> > >> > On Tue, Apr 5, 2011 at 3:13 PM, Henri Yandell >> wrote: >> > >> >> If anyone wants their @author tag put back into Lang, then please feel >> >> free to do so; or if you don't have commit access send me an email and >> >> I'll gladly do it. >> >> >> >> Hen >> >> >> >> On Tue, Apr 5, 2011 at 12:40 PM, Emmanuel Bourg >> wrote: >> >>> I guess I'll never understand the hate for this tag. If you don't like >> >> it, >> >>> don't use it. But please don't remove the name of other developers >> >> without >> >>> their consent. >> >>> >> >>> Emmanuel Bourg >> >>> >> >>> - >> >>> 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 >> >> > > > -- > Thank you, > Gary > > http://garygregory.wordpress.com/ > http://garygregory.com/ > http://people.apache.org/~ggregory/ > 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] @authors tags
Le 05/04/2011 22:36, Gary Gregory a écrit : This is misleading to someone new looking at the source: all I see are the names of people no one can find or who insist to keep their names in there regardless of merit? That does not make sense. If we remove/change, do it, we do not need permission to remove names from @author tags. Memorials are filled with names of people no one can find, but somehow we don't erase them. (Does this validate a Godwin Point ?) Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
Le 05/04/2011 22:43, sebb a écrit : Please don't use $Date$, because it makes checking releases much harder. Could you elaborate on this sebb ? I saw your other message regarding the timezone but I don't really understand the issue it creates when you are checking a release. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
On 5 April 2011 21:57, Emmanuel Bourg wrote: > Le 05/04/2011 22:43, sebb a écrit : > >> Please don't use $Date$, because it makes checking releases much harder. > > Could you elaborate on this sebb ? I saw your other message regarding the > timezone but I don't really understand the issue it creates when you are > checking a release. The contents of the source archive should agree with the SVN tag - there should be no files in the archive that aren't in SVN or direcly derivable therefrom. [And yes, it does happen that stray files sometimes find their way into the source archive] When the SVN tag and source have different dates, every source file appears to be different from its SVN origin, which makes comparison very tedious. > Emmanuel Bourg > > - > 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] @version tag :)
2011/4/6 Emmanuel Bourg : > Le 05/04/2011 22:43, sebb a écrit : > >> Please don't use $Date$, because it makes checking releases much harder. > > Could you elaborate on this sebb ? I saw your other message regarding the > timezone but I don't really understand the issue it creates when you are > checking a release. Regarding my experience in the Apache Tomcat project, there are several issues with $Date$. Timezone is one of them. [1] http://marc.info/?l=tomcat-dev&m=124692524324646&w=2 In Apache Tomcat the discussion ended with me replacing all $Date$ with $Id$, because I felt that there was no consensus in removing this info. My experience in the 1.5+ years since that change is the following: 1) I do not remember seeing anyone using $$ keywords in the new java files. While we sometimes forget to set svn:eol-style property for the new files, the svn:keywords is not in the default autoprops configuration and thus will have to be set explicitly. 2) There were several occasions when a line with $Id$ tag was broken by autoformatting. If the file name is long, the "@version $Id $" line can be more that 80 characters and formatting the source code wrapped the second $ to the next line, breaking the keyword. 3) During this time there was no occasion when this $Id$ information in the source files were useful for me. Essentially it says how old is this file, but files do change often and a change set usually spawns several files. I think $Id$ tags are useful in textual documents like README, because it is good to review those from time to time and update stale information. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] @version tag :)
On 5 April 2011 22:39, Konstantin Kolinko wrote: > 2011/4/6 Emmanuel Bourg : >> Le 05/04/2011 22:43, sebb a écrit : >> >>> Please don't use $Date$, because it makes checking releases much harder. >> >> Could you elaborate on this sebb ? I saw your other message regarding the >> timezone but I don't really understand the issue it creates when you are >> checking a release. > > Regarding my experience in the Apache Tomcat project, > there are several issues with $Date$. Timezone is one of them. > > [1] http://marc.info/?l=tomcat-dev&m=124692524324646&w=2 > > In Apache Tomcat the discussion ended with me replacing all $Date$ > with $Id$, because I felt that there was no consensus in removing this > info. > > My experience in the 1.5+ years since that change is the following: > > 1) I do not remember seeing anyone using $$ keywords in the new java > files. While we sometimes forget to set svn:eol-style property for the > new files, the svn:keywords is not in the default autoprops > configuration and thus will have to be set explicitly. > > 2) There were several occasions when a line with $Id$ tag was broken > by autoformatting. > > If the file name is long, the "@version $Id $" line can be more that > 80 characters and formatting the source code wrapped the second $ to > the next line, breaking the keyword. Broken autoformatter ... > 3) During this time there was no occasion when this $Id$ information > in the source files were useful for me. Essentially it says how old > is this file, but files do change often and a change set usually > spawns several files. I agree, if you have access to a file in SVN then the $Id$ or $Revision$ generally serves little purpose, because SVN can provide the information, but it can be invaluable in tracing where a file has originated when the file is not in SVN. > I think $Id$ tags are useful in textual documents like README, because > it is good to review those from time to time and update stale > information. And again here, if the file is unpacked in a source tree which is not part of SVN, the $Id$ can be very useful in determining the source of the file. > Best regards, > Konstantin Kolinko > > - > 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
[discovery] going to 0.5-RC2
Hi all guys, I reduced the checkstyle errors from more than 300 to 45, follow below what is missing: * Missing package documentation file: I'd ignore them since package descriptions are defined in 'package-info.java' and correctly visualized in javadoc; * Expected @throws tag for 'Exception': I don't understand why they are reported, even if they are in the @throws tag :O What's next on Jira before 0.5-RC2: * DISCOVERY-16: consider it already done * DISCOVERY-7: don't have an idea yet how to solve it (if it makes sense to fix it) * DISCOVERY-6: we switched to Java5, can be overlooked? * DISCOVERY-3: thoughts? Now off to bad, thanks in advance for your feedbacks! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] going to 0.5-RC2
On Tue, Apr 5, 2011 at 6:34 PM, Simone Tripodi wrote: > Hi all guys, > I reduced the checkstyle errors from more than 300 to 45, follow below > what is missing: > Nice chunk to lop off! :) I do not use Discovery, otherwise I'd weigh in on the tickets. Gary > > * Missing package documentation file: I'd ignore them since package > descriptions are defined in 'package-info.java' and correctly > visualized in javadoc; > * Expected @throws tag for 'Exception': I don't understand why > they are reported, even if they are in the @throws tag :O > > What's next on Jira before 0.5-RC2: > > * DISCOVERY-16: consider it already done > * DISCOVERY-7: don't have an idea yet how to solve it (if it makes > sense to fix it) > * DISCOVERY-6: we switched to Java5, can be overlooked? > * DISCOVERY-3: thoughts? > > Now off to bad, thanks in advance for your feedbacks! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
Re: [discovery] going to 0.5-RC2
Hi Gary :) do you have please any suggestion how to fix the "Expected @throws tag for 'Exception'" even if the "@throws Exception" is set? Many thanks in advance!!! All the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Apr 6, 2011 at 3:23 AM, Gary Gregory wrote: > On Tue, Apr 5, 2011 at 6:34 PM, Simone Tripodi > wrote: > >> Hi all guys, >> I reduced the checkstyle errors from more than 300 to 45, follow below >> what is missing: >> > > Nice chunk to lop off! :) > > I do not use Discovery, otherwise I'd weigh in on the tickets. > > Gary > > >> >> * Missing package documentation file: I'd ignore them since package >> descriptions are defined in 'package-info.java' and correctly >> visualized in javadoc; >> * Expected @throws tag for 'Exception': I don't understand why >> they are reported, even if they are in the @throws tag :O >> >> What's next on Jira before 0.5-RC2: >> >> * DISCOVERY-16: consider it already done >> * DISCOVERY-7: don't have an idea yet how to solve it (if it makes >> sense to fix it) >> * DISCOVERY-6: we switched to Java5, can be overlooked? >> * DISCOVERY-3: thoughts? >> >> Now off to bad, thanks in advance for your feedbacks! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > Thank you, > Gary > > http://garygregory.wordpress.com/ > http://garygregory.com/ > http://people.apache.org/~ggregory/ > http://twitter.com/GaryGregory > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
