Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-78281257
@jvanzyl: You would not want the `test-jar` goal to package compiled test
classes instrumented by some reporting tool, would you ? So the forking logic
needs to
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-78283012
No, and I would not advocate the use of tools like that which would distort
the standard lifecycle and promote tools like Jacoco that do not require things
like that. As a
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-78290027
I totally agree with this. Do not cripple Maven to support bad ideas or
concepts. Supported by Maven as an indicator for something. Not supported by
Maven so not
Github user ChristianSchulte closed the pull request at:
https://github.com/apache/maven/pull/32
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-78341680
And I have been talking about this for years but have admittedly done
nothing yet. But I believe the direction to go is to make some example data
generators that can be
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-78226219
I am really no fan of adding just another workaround.
@Jason: Are you suggesting to split site rendering from report data
generation ? So the build
Github user hboutemy commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-78220459
thank you for your work: the bugs are fixed now, cobertura-maven-plugin and
m-site-p ITs pass
now back to the start of this PR :)
Christian: did you know
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-78277642
@ChristianSchulte Definitely more along the lines of what you describe
where there is no site lifecycle. I think this is a design error in allowing
non-build lifecycles.
Hervé,
After EclipseCon today I will look at the doco you started (much appreciated)
and fill in some information. I'll try once again to get the release staged as
well.
Do you think you can put the site plugin along with related plugins through
it's paces with master to make sure we didn't
Github user ifedorenko commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-78070683
http://jira.codehaus.org/browse/MNG-5783 should be fixed in master now.
I've provided explanation of the problem and links to the fix and corresponding
IT changes in
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-78013185
I chatted with Igor and he's going to try and change the way the classpath
is constructed for plugins. The issue here appears to be forking where SLF4J is
filtered out of
Github user hboutemy commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-77975130
another issue found regarding slf4j, this time with cobertura plugin,
during instrumentation http://jira.codehaus.org/browse/MNG-5783 created, with
the difference in
Github user hboutemy commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-77440946
yes, it was just fixed in http://jira.codehaus.org/browse/MNG-5779
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-77428933
I have no experience with the cobertura plugin. I just added
```
reportPlugin
groupIdorg.codehaus.mojo/groupId
Github user mcculls commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-77430685
@ChristianSchulte I believe that was recently fixed in master:
https://github.com/apache/maven/commit/57a6196422873eaf2f00a282b33894a74dcfd19c
---
If your project is set
Github user hboutemy commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-77110127
the current head is expected to be released soon: we'll need to investigate
before releasing, IMHO
comparing 3.2.5 to actual head, slf4j version did not change:
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-76933957
What's the state of the current head as of today ? I just wanted to test
the cobertura plugin but cannot build the site with Maven 3.2.6-SNAPSHOT due to
the
Github user hboutemy commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-76888558
Reporting is a key feature of Maven I strongly want to keep working (or fix
when we introduced problems while improving build consistency during Maven 3.x
refactoring)
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-75961215
The behaviour you describe you need is wrong and the I'm convinced at this
point that the site plugin should just be a stand-alone tool and was
implemented incorrectly in
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-75990941
There are situations the behaviour is not wrong, in my opinion. Resolution
for non project `packaging` related lifecycles, for example. Maven could
detect this
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-76013680
The crux of my argument is that Maven should not be doing anything other
than building, non build lifecycles were a mistake and have done nothing but
make the core more
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-76081933
Could not be more confusing.
Apache Maven is a software project management and comprehension tool. Based
on the concept of a project object model (POM),
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-76101706
There's nothing wrong with there being a site plugin, configuration for the
a site housed within the site plugin and running the site plugin. What is not
right is how it
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-76122905
```
parent
module1
module2
```
With Maven 3 I need to
```
cmdcd parent mvn site-deploy -N cd module1 mvn site-deploy
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-75848081
I am still convinced that it is a good idea to allow Maven 3 'mvn
site-deploy' to work the same way as Maven 2. What's the issue with that ?
---
If your project
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-75794059
Regarding the recent discussion about releasing 3.2.6 as 3.3.0: Could this
be part of 3.3.0, please ?
---
If your project is set up for it, you can reply to
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-75814137
I thought we agreed you were closing this pull request.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-75814030
No, I don't think it's a good idea to be honest.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user hboutemy commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-68146338
I completely understand Christian motivation: we have a problem when we
need interaction between non-default lifecycle and default lifecycle
this causes multiple
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67614958
Can you explain why this is needed?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67621081
I would need a way to disable workspace resolution mainly for the `site`
lifecycle.
cmd svn checkout .../tags/maven-3.0
cmd cd maven-3.0
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67621964
I'm not really in favour of this change. This seems entirely wrong to
change the way resolution works for the site plugin.
---
If your project is set up for it, you can
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67622663
It is re-enabling the following workflow in Maven 3.
cmd mvn release:prepare
cmd mvn release:perform
Wait until the artifacts are
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67625161
Maybe the proper solution would be to control this behaviour based on an
attribute of the lifecycle ? So a lifecycle can be flagged as producing
artifacts or as
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67625232
I don't agree. Why would you not want to build the site from the sources
for the tag of the release you're building?
---
If your project is set up for it, you can reply
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67625959
Maybe jump in IRC, probably easier to chat.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67625978
irc.codehaus.org #maven-dev
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67626029
Feeding the tagged sources to the reports is not an issue. Feeding
intermediate build results is. That's like the tagged sources changing with
every build.
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/32#issuecomment-67605975
Rebased and then pushed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not
39 matches
Mail list logo
