Github user asfgit closed the pull request at:
https://github.com/apache/maven-surefire/pull/68
---
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 feature
The 2.5.X range of the assembly plugin combined with maven-filtering
1.3 has gotten ferociously good at preserving file attributes (unix
mode bits and modification time), to the extent that it may have
gotten /too/ good, since it can now filter a file for line
endings/interpolation and still
I recently took a look at the release-profile in Maven's super POM.
It uses the jar goal of the maven-source-plugin to create the source
JAR. Wouldn't it be better to use the jar-no-fork goal for that?
For example, if a projects spends a lot of time in the
generate-sources phase, the jar goal
Hi Stefan,
On 11/27/14 7:39 PM, Stefan Ferstl wrote:
I recently took a look at the release-profile in Maven's super POM.
It uses the jar goal of the maven-source-plugin to create the source
JAR. Wouldn't it be better to use the jar-no-fork goal for that?
sounds definitively like a good
Hi!
Today I had a discussion with Robert about how we can solve a problem I had
over at Apache OpenWebBeans:
https://issues.apache.org/jira/browse/OWB-952
As a short summary: the classes provided in rt.jar of Java8 are slightly
different than the ones from Java7 and 6. Similar big differences
Hi folks,
recently I began fixing issues at work and let tests run on powerful
machines in the background. Unfortunately, I cannot really make any
progress here. More than 80 % of all unit/integration tests fail because
they are not self-contained. They all have Maven Central
Out of curiosity, why do you want to get exactly the same bytecode? Does
the code compiled with java8 not work under java7?
--
Regards,
Igor
On 2014-11-27, 15:39, Mark Struberg wrote:
Hi!
Today I had a discussion with Robert about how we can solve a problem I had
over at Apache OpenWebBeans:
Addition: if you want to reproduce this on a not locked down network.
Have a Nexus instance on your machine (localhost), run the testing once
to have all necessary dependencies. Disconnect your LAN/WLAN connection
and retry. It should fail with connection timeout.
I recently took a look at the release-profile in Maven's super POM.
It uses the jar goal of the maven-source-plugin to create the source
JAR. Wouldn't it be better to use the jar-no-fork goal for that?
sounds definitively like a good idea...to change that...
I have created an appropriate
I've been in the same position as you. My solution back then was to work on
Maven (and also some plugins) on my private MBP connecting to Internet
through other channels (an open guest network).
I don't know if the mrm-maven-plugin could solve some of this. It does for
plugin ITs, but is not used
Am 2014-11-27 um 22:46 schrieb Anders Hammar:
I've been in the same position as you. My solution back then was to work on
Maven (and also some plugins) on my private MBP connecting to Internet
through other channels (an open guest network).
Absolutely not an option here :-(
Github user Tibor17 closed the pull request at:
https://github.com/apache/maven-surefire/pull/71
---
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
It won't always work. Read a blog post detailing the problem once but can't
find it right now.
Looking at
http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198
there's a list of behavioural changes
On Thu, Nov 27, 2014, 22:33 Igor Fedorenko i...@ifedorenko.com
I think the number of ITs that need a connection to Maven Central is very few.
You need to explicitly use the template which gives you a settings with an
external connection. By default it's isolated. Now the bootstrapping to grab
stuff you need requires an external connection. I've worked
On 28 Nov 2014, at 10:32, Igor Fedorenko wrote:
Out of curiosity, why do you want to get exactly the same bytecode? Does
the code compiled with java8 not work under java7?
Mostly - it's due to method signature resolution. For instance in the JDK 5 -
6 change, some functions that used to take
On Thursday, 27 November 2014, Mark Derricutt m...@talios.com wrote:
On 28 Nov 2014, at 10:32, Igor Fedorenko wrote:
Out of curiosity, why do you want to get exactly the same bytecode? Does
the code compiled with java8 not work under java7?
Mostly - it's due to method signature
To be honest I would be more inclined to remove the release profile from the
super pom altogether ..
manfred
Anders Hammar wrote on 27.11.2014 13:36:
I recently took a look at the release-profile in Maven's super POM.
It uses the jar goal of the maven-source-plugin to create the source
There is also a very cool tool from the Lucene land, written by Uwe Schindler --
https://code.google.com/p/forbidden-apis/
This lets you selectively forbid certain methods from your codebase
(and the default list of forbidden methods has a strong rationale to
be discouraged -- locale-sensitive
18 matches
Mail list logo
