I don't know what's on trunk so really can't say. But I see no issue in
truynk being work towards 3.0 and your branch is a small addition ot the
2.x stream which will be in 2.6.0. If it's a bug fix it should be 2.5.x.
>From my pow it's totally fine going Java 6 in v2.6. You don't have to go
v3.0 fo
Github user trask commented on the pull request:
https://github.com/apache/maven/pull/69#issuecomment-145730242
The nice thing about how maven-shade-plugin's "dependency reduced pom" used
to work, is that you could run mvn compile or mvn test from your parent module
(and so maven shad
Hi,
We solved 50 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12331679
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
Staging repo:
https://
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-
It is possible to use ClassRealmManagerDelegate to replace "bad"
slf4j-related plugin dependencies with compatible "good" dependencies.
This is what I do in my "better multithreaded logging" maven extension
and it works quite well from what I can tell.
--
Regards,
Igor
On Sun, Oct 4, 2015, at 10
Github user trask commented on the pull request:
https://github.com/apache/maven/pull/69#issuecomment-145723525
@ifedorenko, thanks for reviewing this. Any thoughts what we should do
with the downstream implication of this change?
https://issues.apache.org/jira/browse/MSHADE-206
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 r
+1
On 4 October 2015 at 20:18, Robert Scholte wrote:
> Hi,
>
> during the latest upgrade of the plugin-parent I faced several issues with
> the maven-eclipse-plugin.
> It will take quite some time to fix these issues, but is it worth
> maintaining it here?
> Nowadays the Maven support for Eclips
+1 to retire it at ASF
+1 to fork at MojoHaus to prepare if someone wants to maintain
Regards,
Hervé
Le dimanche 4 octobre 2015 11:18:55 Robert Scholte a écrit :
> Hi,
>
> during the latest upgrade of the plugin-parent I faced several issues with
> the maven-eclipse-plugin.
> It will take quite
Github user Tibor17 commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145664550
This feature has limitations own limitations, see the page after successful
release
https://maven.apache.org/surefire/maven-surefire-plugin/examples/skip-
So, I have this 2.6 branch, but it's tightly my Snappy obsession. So
is that what you all mean, or do you want a large subset of the trunk
in there, possibly up to and including the current end of the trunk?
On Mon, Oct 5, 2015 at 3:03 PM, Anders Hammar wrote:
> I agree with Robert; it would be g
I agree with Robert; it would be great to do lots of cleanup (remove
deprecated goals for starters) in a 3.0 version. So doing a v2.6 now would
keep that option open.
/Anders
On Mon, Oct 5, 2015 at 8:23 PM, Robert Scholte wrote:
> IIRC for maven-assembly-plugin most of the actions have been don
IIRC for maven-assembly-plugin most of the actions have been done as
stated in the migration strategy[1]
Due to not knowing about maven-artifact-transfer the plugin contains some
equivalent code, but the custom code doesn't work for all M3.0+ versions
(I think only 3.0.4 and above).
AFAIK i
Github user Tibor17 commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145584123
If it still does not help try with this URL
https://repository.apache.org/content/groups/snapshots
On Mon, Oct 5, 2015 at 4:38 PM, Benjamin Winterberg
Github user Tibor17 commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145583437
Maybe this helps
http://stackoverflow.com/questions/7713996/is-there-a-way-to-make-maven-download-snapshot-versions-automatically
On Mon, Oct 5, 2015
Github user Tibor17 commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145563402
Usually it works for me. I am not behind proxy and use default settings.xml.
On Mon, Oct 5, 2015 at 4:38 PM, Benjamin Winterberg <
notificati...@
Github user winterbe commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145549204
2.19-SNAPSHOT is not on central maven repo. Please give me a hint what repo
I have to use to get the SNAPSHOT version of failsafe plugin, then I'll test it
on m
On Mon, Oct 5, 2015 at 4:27 AM, Kristian Rosenvold
wrote:
> Personally I'd release 3.0.0 and stuff whatever nit-picky requirements
> are not met. Revert any changes that depends on code that is not yet
> ready for release. I think ultimately the large list of requirements
> is a nice way to just h
Github user Tibor17 commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145532182
Benjamin, do you expect slight changes, let me know.
Can you please declare Failsafe Version 2.19-SNAPSHOT and run your tests.
Let me know your impression.
Github user Tibor17 commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145510139
I will start the release maybe today or tomorrow. All depends on my spare
time.
On Mon, Oct 5, 2015 at 1:54 PM, Benjamin Winterberg <
notificati..
Github user winterbe commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145505027
Great, thanks for clarifying! :+1:
---
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 proj
Github user Tibor17 commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145497939
It will.
On Mon, Oct 5, 2015 at 12:43 PM, Benjamin Winterberg <
notificati...@github.com> wrote:
> Will skipAfterFailureCount also be availab
Github user winterbe commented on the pull request:
https://github.com/apache/maven-surefire/pull/103#issuecomment-145492582
Will `skipAfterFailureCount ` also be available in failsafe-plugin or only
for surefire-plugin?
---
If your project is set up for it, you can reply to this ema
Personally I'd release 3.0.0 and stuff whatever nit-picky requirements
are not met. Revert any changes that depends on code that is not yet
ready for release. I think ultimately the large list of requirements
is a nice way to just halt all progress.
It'll be at least a jdk 1.6 release no matter wh
24 matches
Mail list logo
