Added profile "code-coverage" to run cobertura-maven-plugin #833

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants
@vbauer
Contributor

vbauer commented Feb 22, 2014

It could be useful to check code coverage and cobertura-maven-plugin will do it.

I've added new profile "code-coverage". You need to activate it and run "mvn clean package" to build report about code coverage. Report about code coverage is available in "target/site/cobertura".

image

@stefanbirkner

This comment has been minimized.

Show comment
Hide comment
@stefanbirkner

stefanbirkner Feb 23, 2014

Contributor

IMHO the best way to add coverage reports is to wait for #785 and add it to the generated site. Maven profiles are not meant for activating build features.

I don't like specifying version numbers by properties. It's overhead that is not needed.

Contributor

stefanbirkner commented Feb 23, 2014

IMHO the best way to add coverage reports is to wait for #785 and add it to the generated site. Maven profiles are not meant for activating build features.

I don't like specifying version numbers by properties. It's overhead that is not needed.

@stefanbirkner stefanbirkner added the maven label Feb 23, 2014

@Tibor17

This comment has been minimized.

Show comment
Hide comment
@Tibor17

Tibor17 Feb 23, 2014

Contributor

First of all we need to get #787 pushed to master.
We do not need extra profile for code coverage because it should be included in the reporting section of POM.
Then pls remove properties you added, it has no reason on the top since they are used just once. Pls inline them.
After the #787 is pushed, I am open to vote for a code coverage plugin.

Contributor

Tibor17 commented Feb 23, 2014

First of all we need to get #787 pushed to master.
We do not need extra profile for code coverage because it should be included in the reporting section of POM.
Then pls remove properties you added, it has no reason on the top since they are used just once. Pls inline them.
After the #787 is pushed, I am open to vote for a code coverage plugin.

@vbauer

This comment has been minimized.

Show comment
Hide comment
@vbauer

vbauer Feb 24, 2014

Contributor

About properties: They are used just once, but it is much easier to manage them (to update versions). Each of them in one section, so you shouldn't scan all pom.xml manually.

So, to check updated plugins you need:

  1. Run "mvn versions:display-plugin-updates"
  2. Open properties section
  3. Update needed plugins
Contributor

vbauer commented Feb 24, 2014

About properties: They are used just once, but it is much easier to manage them (to update versions). Each of them in one section, so you shouldn't scan all pom.xml manually.

So, to check updated plugins you need:

  1. Run "mvn versions:display-plugin-updates"
  2. Open properties section
  3. Update needed plugins
@kcooney

This comment has been minimized.

Show comment
Hide comment
@kcooney

kcooney Feb 24, 2014

Member

If the properties are used once, I would also prefer that they not be in the properties section. I would rather have each plugin standalone. The properties section is essentially a bunch of global variables.

I will ask the other maintainers to see who is the best one to review pom changes.

Member

kcooney commented Feb 24, 2014

If the properties are used once, I would also prefer that they not be in the properties section. I would rather have each plugin standalone. The properties section is essentially a bunch of global variables.

I will ask the other maintainers to see who is the best one to review pom changes.

@vbauer

This comment has been minimized.

Show comment
Hide comment
@vbauer

vbauer Feb 24, 2014

Contributor

Actually, properties section is a little bit complicated than a bunch of global variables. You can reassign some properties in profiles or sub-modules. It is also plus in favor of using properties section. :)

Contributor

vbauer commented Feb 24, 2014

Actually, properties section is a little bit complicated than a bunch of global variables. You can reassign some properties in profiles or sub-modules. It is also plus in favor of using properties section. :)

@stefanbirkner

This comment has been minimized.

Show comment
Hide comment
@stefanbirkner

stefanbirkner Feb 24, 2014

Contributor

That's right, but we don't use profiles and we don't have a multi-module project.

Contributor

stefanbirkner commented Feb 24, 2014

That's right, but we don't use profiles and we don't have a multi-module project.

@vbauer

This comment has been minimized.

Show comment
Hide comment
@vbauer

vbauer Feb 24, 2014

Contributor

We can move it in build (or reporting) section, but it will take additional time for building project.

Contributor

vbauer commented Feb 24, 2014

We can move it in build (or reporting) section, but it will take additional time for building project.

@stephenc

This comment has been minimized.

Show comment
Hide comment
@stephenc

stephenc Feb 27, 2014

Contributor

This heavy use of properties when they are only used once is a real maven anti-pattern IMHO. But then I'm only on the Apache Maven Project Management Committee so my opinion is probably not relevant!

Contributor

stephenc commented Feb 27, 2014

This heavy use of properties when they are only used once is a real maven anti-pattern IMHO. But then I'm only on the Apache Maven Project Management Committee so my opinion is probably not relevant!

@vbauer vbauer closed this Feb 27, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment