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 me
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 sou
On Thursday, 27 November 2014, Mark Derricutt 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 resolution. For i
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 ta
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 aroun
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 wrote:
> Out of curi
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 feature
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 :-(
--
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 e
> 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
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.
-
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:
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
hardcoded/config
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 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 i
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" g
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 preser
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
18 matches
Mail list logo
