Antony Riley over at osjava.org (thus my 'we'). I just talked with
Torsten on IM and he feels it's easiest to stay with the mojo's.
Sounds good to me.
Hen
On 5/20/06, Brett Porter [EMAIL PROTECTED] wrote:
Who wrote jardiff? If there's a chance the Maven plugin can be
maintained within that
On 5/21/06, Dion Gillard [EMAIL PROTECTED] wrote:
Guys,
this sounds like bike shed paint discussion.
It's more of a water cooler discussion - and I think it's pretty good
community stuff.
For example, I wrote the FAQ report off (never having used it), but
given that Martin has positive
Well it does, if the user remembers to upgrade all three plugins instead
of just one of them :)
--
Dennis Lundberg
Lukas Theussl wrote:
Version 1.9 of the m1 changelog plugin also introduced the
maven.changelog.date=lastRelease option, which will set the date
automatically to the last
Guys,
this sounds like bike shed paint discussion.
We're under resourced here as it is.
Do we really have extra volunteers waiting to frack about making reports
consistent?
Does it really make it easier for our users? I haven't seen complaints about
inconsistent maven reports lately.
AFAICT,
Dion Gillard wrote:
Guys,
this sounds like bike shed paint discussion.
Well, in that case I want mine blue ;)
We're under resourced here as it is.
Do we really have extra volunteers waiting to frack about making reports
consistent?
Does it really make it easier for our users? I haven't
On Sun, 2006-05-21 at 22:06 +0200, Dennis Lundberg wrote:
Dion Gillard wrote:
snip
We're under resourced here as it is.
Do we really have extra volunteers waiting to frack about making reports
consistent?
Does it really make it easier for our users? I haven't seen complaints
about
Martin Cooper wrote:
- findbugs (same as pmd?)
I would rather see this as + than -.
CheckStyle, PMD and findbugs have some overlap, but each one
has also unique code quality tests. There are a few more
utilities of this kind, and there's even a Java Code Meta
Checker which consolidates their
Dennis Lundberg [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Dion Gillard wrote:
Guys,
this sounds like bike shed paint discussion.
Well, in that case I want mine blue ;)
Paint mine green ;-).
We're under resourced here as it is.
Do we really have extra volunteers
Unfortunately codehaus was down when I wanted to commit. So it's still
sitting in Jira ..and on my disk
I don't know if its desirable, but I'm pretty sure we'd be happy to
have the plugin live with jardiff itself if you wanted that.
What do you mean? Bringing it over to jakarta/commons?
On 5/19/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
I would like to start a discussion about trying to unify which Maven
reports should be used for each commons component.
Source health
+ checkstyle (code formatting)
+ jdepend (quality metrics)
+ pmd/cpd (bugs, code duplication, coding
Lukas Theussl wrote:
Hi,
Just a few comments from an outsider:
- I think the simian report is far more advanced than CPD and much
easier to read (on the other hand it's also heavier in resources)
- Since you have recently switched to JIRA I'd suggest you have a look
at the jira plugin
Henri Yandell wrote:
Answering inline from the point of view of the published website.
CI-wise, I think everything should be turned on.
On 5/19/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hello
I would like to start a discussion about trying to unify which Maven
reports should be used for
Brett Porter wrote:
Dennis Lundberg wrote:
I have also tried to categorize and describe each report,
borrowing/stealing a lot from chapter 6 in the new book Better Builds
with Maven.
Why would you want to do that? :D
Oh, I don't know, maybe because it is a great book. It really is very
Sandy McArthur wrote:
On 5/19/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
I would like to start a discussion about trying to unify which Maven
reports should be used for each commons component.
Source health
+ checkstyle (code formatting)
+ jdepend (quality metrics)
+ pmd/cpd (bugs, code
Stephen Colebourne wrote:
Dennis Lundberg wrote:
Changes since last release
+ clirr (binary compatibility)
- jdiff (same as clirr)
These are not the same as I would need both to produce a release (clirr
for compatability, jdiff for since tags).
Oh, I didn't know that.
Neither needs to be
Hi Dennis,
basically I am in compliance with you list except:
+ developer-activity (SCM activity per developer)
+ file-activity (SCM activity per file)
I don't see much value in them. They just report activities for the last 30
days and even worse, they are not reproduceable, e.g. if you
Who wrote jardiff? If there's a chance the Maven plugin can be
maintained within that project, and Torsten can still contribute to it,
I'm all for it. Jetty does this very successfully.
- Brett
Torsten Curdt wrote:
Unfortunately codehaus was down when I wanted to commit. So it's still
Dennis Lundberg wrote:
Common setting would be good, but I will not go there just yet. I feel
the flames burning already :)
It's a good point. I thought there was an agreed standard, but there
probably isn't. Which is good, because then I can sneak in the Maven
style with lots of whitespace
Jörg Schaible wrote:
Hi Dennis,
basically I am in compliance with you list except:
+ developer-activity (SCM activity per developer)
+ file-activity (SCM activity per file)
I don't see much value in them. They just report activities for the last 30
days and even worse, they are not
Version 1.9 of the m1 changelog plugin also introduced the
maven.changelog.date=lastRelease option, which will set the date
automatically to the last release found in changes.xml. I was under the
impression that this should work the same for file-/dev-activity and
changelog reports. If not,
On 5/19/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hello
I would like to start a discussion about trying to unify which Maven
reports should be used for each commons component. The reasons I find
for unifying the reports are these:
- Makes it easy for our users if we are consistent - they
On 5/19/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hello
I would like to start a discussion about trying to unify which Maven
reports should be used for each commons component. The reasons I find
for unifying the reports are these:
- Makes it easy for our users if we are consistent - they
Dennis Lundberg wrote:
Changes since last release
+ clirr (binary compatibility)
- jdiff (same as clirr)
These are not the same as I would need both to produce a release (clirr
for compatability, jdiff for since tags).
Neither needs to be part of the regular website though.
Stephen
Hi,
Just a few comments from an outsider:
- I think the simian report is far more advanced than CPD and much
easier to read (on the other hand it's also heavier in resources)
- Since you have recently switched to JIRA I'd suggest you have a look
at the jira plugin which I find very pretty
Answering inline from the point of view of the published website.
CI-wise, I think everything should be turned on.
On 5/19/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hello
I would like to start a discussion about trying to unify which Maven
reports should be used for each commons component.
Dennis Lundberg wrote:
I have also tried to categorize and
describe each report, borrowing/stealing a lot from chapter 6 in the new
book Better Builds with Maven.
Why would you want to do that? :D
+ checkstyle (code formatting)
+ pmd/cpd (bugs, code duplication, coding standards)
Agree,
+ checkstyle (code formatting)
+ pmd/cpd (bugs, code duplication, coding standards)
Agree, and think commons should specify common settings for both (the
pmd ones might be harder to agree on though, so might vary).
Uh ...I think checkstyle might be a hard one. And TBH I think that's
not
On 5/19/06, Torsten Curdt [EMAIL PROTECTED] wrote:
+ clirr (binary compatibility)
You might also look at Torsten's recent work on jardiff for Maven 2.
Unfortunately codehaus was down when I wanted to commit. So it's still
sitting in Jira ..and on my disk
I don't know if its desirable,
28 matches
Mail list logo
