Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/125
No, sorry, I can't "assign" this to anyone, you just have to wait for
somebody to review and merge this pull request.
---
If your project is set up for it, you can reply to this emai
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/125
The change looks reasonable but I don't use built-in multithreaded build
support myself and do not feel comfortable merging this change without proper
testing. I will have to defer to somebody
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/125
No, having IT failures are not normal, and [jenkins seems to be
happy](https://builds.apache.org/view/M-R/view/Maven%20Core%20ITs/job/core-integration-testing-maven-3-embedded/).
---
If your
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/125
Can you provide a regression test that demonstrates the problem and the fix?
Semi-related, I recently fixed similar problem in [Takari Smart
Builder](https://github.com/takari/takari-smart
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/116
Wow. That's backwards. I wonder what will happen if I push my change with
github's magic "fixes 116" pseudo comment. Guess there is one way to find out
:-)
---
If your project
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/116
Opened https://issues.apache.org/jira/browse/MNG-6233. If you any concerns
or suggestions, I suggest we continue the discussion there.
@jdillon I can't close this pull request
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/116
I have a commit on a local branch that fully converts
maven-resolver-provider to jsr330, I can push that to master if you can wait
few days. Either way we'll need a JIRA to track the changes
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/69
I am dead serious. I am not at liberty to disclose exact numbers, but lets
say our main codebase is in the same ballpark if we allow some room for growth.
So 5K modules is not "aspirational
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/69
I still vote -1 on this change.
While I appreciate "dependency reduced pom" usecase, I'd like the following
two concerns addressed first:
* Mutated pom.xml
Github user ifedorenko commented on the issue:
https://github.com/apache/maven/pull/110
spam?
---
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
Github user ifedorenko commented on the pull request:
https://github.com/apache/maven/pull/69#issuecomment-145722376
-1
The old behaviour allowed inconsistency between dependencies used to
calculate project build order and project dependencies used during the build.
It also
Github user ifedorenko commented on the pull request:
https://github.com/apache/maven/pull/69#issuecomment-145727506
I am not sure I fully understand the problem, but maven generally expects
project dependencies to stay the same during the build. If you need to suppress
certain storm
Github user ifedorenko commented on the pull request:
https://github.com/apache/maven/pull/60#issuecomment-123711202
What other options do we have? I guess we can create new `maven-versioning`
module, move `org.apache.maven.artifact.versioning` implementation there and
change maven
Github user ifedorenko commented on the pull request:
https://github.com/apache/maven/pull/57#issuecomment-120415902
What will happen when projects using new/custom version range resolution
strategy are deployed to shared repository like Central? Won't this break
consumers of project
Github user ifedorenko commented on the pull request:
https://github.com/apache/maven/pull/53#issuecomment-113485035
Maven is targeting java 7 already, try-with-resource is more appropriate
way to guarantee IO streams are closed.
---
If your project is set up for it, you can reply
Github user ifedorenko commented on the pull request:
https://github.com/apache/maven/pull/49#issuecomment-105632922
This seems to break org.apache.maven.it.MavenITmng3529QuotedCliArgTest
integration test. Will have a closer look later today.
---
If your project is set up
Github user ifedorenko commented on the pull request:
https://github.com/apache/maven/pull/40#issuecomment-89838717
@Stephan202 what is your usecase for having multiple maven or jvm options
for the same codebase? Is this to support svn (and similar) repositories that
effectively host
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
18 matches
Mail list logo