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 Gr
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
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'
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'
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
> ch
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 creat
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
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 t
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.mb
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 propon
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 Gre
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 anyo
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, Simon
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
>
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 @
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,
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,
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:
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
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...@comm
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;
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 si
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:
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 thoug
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/con
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
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
r
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 t
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.o
> 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,
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 e
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
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
>> -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
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 i
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 Greg
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
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
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
> 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
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 Yan
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
>
> -
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
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 f
> 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.
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 lo
>> 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 s
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
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 w
> 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 onl
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 com
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://ww
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
>> 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
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 c
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 existin
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 i
>> 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
:)
--
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
>> 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
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
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 n
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 @ver
> 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
> B
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]
>
> Totall
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 mu
> 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
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, hav
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; fo
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-mai
$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, S
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.
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 th
> 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
--
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
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 ch
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 mi
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
- "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
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 Apac
80 matches
Mail list logo
