I would like to share my current pom configuration which lets me to
build and test java8 apps on latest and greatest jdk9
This profile is activated when using jdk9.
This is based on a suggestion of Robert, its suggestion for the
javadoc plugin is working great with surefire too
jdk9
Le mercredi 17 mai 2017, 14:46:13 CEST Paul Hammant a écrit :
> > not to speak about read concurrency when one requires to use multiple
> > versions
> > of a lib. And of course, write concurrency is even harder.
>
> I'm not following, dude.
:)
I'm not sure I'm not mistaken for the read part: with
Maven Monitor was a Maven 2 artifact [1]
It was dropped in Maven 3 "as an artifact": code was moved to maven-core
during the Great Refactoring (TM) [2]
Then you'll see that EventMonitor has been deprecated, in favor of EventSpy in
Maven 3.0.2 I think: we should probably improve the javadoc...
H
Github user hboutemy commented on the issue:
https://github.com/apache/maven/pull/118
great, I'll merge your ideas with
https://github.com/apache/maven/commit/75b23eb01f913cf90d6ac4f9d2d5d7f6b9d69e1a
: removing the patching part will be a be a good benefit
issue tracked in ht
And as I'm comfortable advocating for a few Git-centric alternates, GitHub
could be a hosting platform for jars of classes too. I think I've
established that it is efficient for storing binary classes.
The https://github.com/paul-hammant/mc-xs-classes/releases page on the
mc-xs-classes I did for
The Maven-using developer community cares that the dependency downloader
does its think that the uploader/deploy does too. Some new releases of
those, and some back releases for the hard breaks (if any) going back in
time - Maven1, Maven2 and whatever.
Works well enough for Homebrew (https://githu
If you would run Central on git like that in a centralized manner you would
have to find someone that does that hosting for you and you would have to get
buy in from the community to use that - both extremely hard or impossible.
And if you dont do that but instead go with the distributed system
On Wed, 17 May 2017 12:38:53 +0200, Michael Osipov
wrote:
Here are some minor issues for 1.1.0:
MRESOLVER-22 Upgrade to Maven Parent 30
MRESOLVER-23 Avoid implicit primitive type casts
MRESOLVER-24 Turn some IllegalArgumentExceptions into
IllegalStateExceptions
Who seconds them?
3* +1
Actually I'm proposing a predictable structure on 'central :
g...@central.maven.org:
maven2/.git
(one minor fix versus previous description of the git:// location)
Or for the three separate variant:
g...@central.maven.org:
maven2/-classes.git
g...@central.maven.org:
maven2/-javadocs.git
g..
Having worked with repository managers and the implementation for various
formats on Nexus for years I think such a format is a bit like Bower. It is a
registry format that in turn points to git repositories that have the content.
>From a corporate usage and implementation point of view this is
I'm "just" unzipping the source, and committing those sources. Sure, I
delete the previous set first, but I merge the *rm* set and *add* set into
one commit with an --amend ->
# fn is xstream-1.4.3.jar and v is 1.4.3 for example
git("rm", "-r", "*")
git("commit", "-m", v)
Robert,
>From the blog entry:
*Actually changing Maven Central to do this*
The maven ‘deploy’ workflow and plugin would invisibly do a commit to (or
create of) a dedicated Git repo up on central.
For XStream, a new deployment would not go into
http://central.maven.org/maven2/com/thoughtworks/xs
thats my point: the golang approach does no magic at all. It simply stores
the source code and bases it on a convention. Just the files, and thats it.
--
-- Aldrin Leal, / http://about.me/aldrinleal
On Wed, May 17, 2017 at 2:38 PM, Paul Hammant wrote:
> Aldrin, The blog entry I wrote on saturd
Aldrin, The blog entry I wrote on saturday mulled classes, javadocs and
sources -
https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/ (re
your "way more than" comment).
The GH repo I linked you to earlier has all three in one repo (see the
branches drop-down) - https://github.c
On Wed, 17 May 2017 20:41:02 +0200, Paul Hammant wrote:
I would agree that it has the potential to be a new repository
implementation, Robert.
But I am not sure I follow your second sentence.
So suppose I want to add xstream-1.4.9 as dependency to my project. How
should Maven know it has to
I understand the approach is basically general, but maven artifacts are way
more than binary code (there's source and javadoc). I also understand its
an interesting option for distribution.
I really would like to see something close to what "go get" does. If not
github and bitbucket (and go get in
There is that, yes. And Git's general upper limits which are subject of "I
heard of a team that had a corruption at 2GB". I've field tested Git up to
7GB for a git-svn-clone myself (a team considering saying bye bye to Svn),
but wouldn't put that live versus hive off history to a R/O repo, and sta
Hervé,
on classes branch, splitting the jar into individual .class has IMHO a big
> drawback: we loose original jar and its signature
>
Agree. Git doesn't care about timestamps for classes in jars. Java doesn't
either, but SHA1 (etc) of the jar does.
Thus - the next iteration will reproduce even
Still, once github gets an outage, our repositories are basically
'left-padded' (taken offline)
--
-- Aldrin Leal, / http://about.me/aldrinleal
On Wed, May 17, 2017 at 1:35 PM, Paul Hammant wrote:
> Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files added
> to Git. Git makes 7
I would agree that it has the potential to be a new repository
implementation, Robert.
But I am not sure I follow your second sentence. Maybe I do. There is one
Git repo per group/artifact. That's true for whether it is the principal
artifact you're after or a transitive dep.
1. For https://githu
Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files added
to Git. Git makes 70% saving on bytes used ('bare' mode).
On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal wrote:
> Just a friendly reminder that git is not optimized for large files (for
> this, they made git-lfs). Plus, whe
I consider this as a new repository implementation. But this also implies
that in your pom, for every dependency you have to add a repository-entry
as well, right?
Robert
On Wed, 17 May 2017 17:10:49 +0200, Aldrin Leal wrote:
Just a friendly reminder that git is not optimized for large fi
Just a friendly reminder that git is not optimized for large files (for
this, they made git-lfs). Plus, when you do checkout a git repo, there's no
binary diffs - so if you've got plenty of releases, you'll be wasting a lot
of space/time in terms of transmission and storage.
--
-- Aldrin Leal, /
Given the version spread of Maven-Monitor above (v2.0.5 and v2.0.9 needed
to build v2.2.1) I'd love to get some advice to how to attach breakpoints
in use to see the pertinent methods invoked during a build. I mean I've
attached breakpoints and then done mvnDebug but the breakpoints are not hit.
We can agree to differ on what I'm suggesting and what the impact of that
would be :)
On Wed, May 17, 2017 at 8:59 AM, Brian Fox wrote:
> Even more than redefining what Central does, you're effectively describing
> a new, unofficial java class packaging and distribution mechanism. This
> seems l
Even more than redefining what Central does, you're effectively describing
a new, unofficial java class packaging and distribution mechanism. This
seems like it will violate signatures etc and make tracking of what you
actually have a nightmare.
On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY
wrot
Here are some minor issues for 1.1.0:
MRESOLVER-22 Upgrade to Maven Parent 30
MRESOLVER-23 Avoid implicit primitive type casts
MRESOLVER-24 Turn some IllegalArgumentExceptions into IllegalStateExceptions
Who seconds them?
-
To
Github user ebourg commented on the issue:
https://github.com/apache/maven/pull/109
#118 also upgrades SLF4J but goes a bit further by removing the patching
mechanism.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If y
Github user ebourg commented on the issue:
https://github.com/apache/maven/pull/118
It's better now, the levels and the exceptions are properly colored, and
SLF4J no longer complains about the duplicate StaticLoggerBinder.
---
If your project is set up for it, you can reply to this e
Github user ebourg commented on the issue:
https://github.com/apache/maven/pull/118
Understood, thank you. I've added a StaticLoggerBinder implementation but
now SLF4J complains that there are two StaticLoggerBinder on the classpath
(from maven-slf4j-provider and slf4j-simple). I'll t
30 matches
Mail list logo
