This rule is now live on OSSRH so no new deployments will be able with that
issue. I posted a little update notification yesterday and we also notified via
twitter and other means earlier.
http://central.sonatype.org/articles/2014/Nov/27/dependency-version-range-enforcement-live-on-ossrh/
In t
GitHub user diorcety opened a pull request:
https://github.com/apache/maven-plugins/pull/31
Fix file retreiving when using artifact in the reactor
If we add an artifact as dependency which is used in the reactor, then a
null pointer exception is thrown.
It's due to the fact tha
On Fri, Nov 28, 2014 at 1:28 AM, Manfred Moser wrote:
> To be honest I would be more inclined to remove the release profile from the
> super pom altogether ..
>
> manfred
>
+1, I would appreciate that too. However, in 2009 there was apperently
an attempt to remove the profile from the Super POM
On Thu, Nov 27, 2014 at 10:36 PM, Anders Hammar 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 definit
On 28 November 2014 at 08:16, Anders Hammar wrote:
> 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 used my laptop tethered to my phone.
The
+1 if they like to use Mavens infrastructure then they also need to play
according to those rules.
Anyone likes to talk with the Ivy guys? They have to fix this.
Another question is what we do with those existing poms in maven.central? Do we
convert them? What about sha1, md5 and asc in that c
+1
On Tue, Nov 25, 2014 at 11:57 AM, Stephen Connolly
wrote:
> For anyone who has been living under a rock, here is the background
>
> Background
> =
>
> I think everyone can agree that the site needs a reorganisation and a
> rewrite. Users cannot find what they need, and the end result i
Hi Jason,
For core I agree with you, and we have had discussions about this in
the past and have come to the conclusion that we need to batch close
issues to be able to see what issues really needs to be worked on.
The work Michael has been doing however is not restricted to core
issues, it cover
Hi!
> This lets you selectively forbid certain methods
The problem is that the methods used are perfectly fine. The API methods used
in our program do exist even in Java6. But they get coerced to different
methods when compiling with Java8. And those new methods do not exist in Java7
and ol
