Github user mikebrock commented on the pull request:
https://github.com/apache/maven/pull/20#issuecomment-46737130
I think that could be pretty cool. I see no reason why not.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as wel
+1 (non-binding)
2014-06-20 15:41 GMT+02:00 Jason van Zyl :
> Ok, I'll summarize the results over the weekend, write up the release
> notes and roll it out over the weekend.
>
> On Jun 20, 2014, at 3:30 AM, Arnaud Héritier wrote:
>
> > +1
> >
> > Tested on several projects for few days and no i
OK, I found the source.
next: doxia-sitetools does not build for me:
INFO] --- maven-enforcer-plugin:1.3.1:enforce
(enforce-bytecode-version) @ doxia-doc-renderer ---
[INFO] Artifact org.apache.xmlgraphics:batik-svg-dom:jar:1.7:compile
contains .class compiled with incorrect version
[INFO] Artifa
Well I've had this proposal in one form or another on and off for the past
2-3 years. Jason recently stated that he only wants to look at concrete
proposals as the first stab for what/how to extend the pom format... so
here is a very concrete example proposal ;-)
On 20 June 2014 16:50, Paul Bened
Ah, the woes of fragmented jars. That's the bane of EE dependency
management. Figuring out the superset/subset stuff is indeed terrible. Good
job, Stephen, to propose a solution for it.
Cheers,
Paul
On Fri, Jun 20, 2014 at 10:03 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
>
Well this started out from a need for a more effective .
The issue with is that you have to apply it to each and every
dependency... when what you really want to say is "see this dependency
here? well that is the same as X, Y and Z so don't pull them in from the
transitive dependencies"
If you l
I am having trouble understanding how grouping together artifacts that are
"equivalent" gain me anything in my project building. I am already doing
this in my POM today by excluding what's equivalent. Is this proposal
simply about adding semantic information to the POM so it's more apparent
what th
GitHub user Jentsch opened a pull request:
https://github.com/apache/maven-plugins/pull/24
Fix SBT dependencies information
With double '%' SBT tries to find the dependencies compiled with the
locally used Scala version[1]. Since most Maven projects doesn't use
Scala this res
Ok, I'll summarize the results over the weekend, write up the release notes and
roll it out over the weekend.
On Jun 20, 2014, at 3:30 AM, Arnaud Héritier wrote:
> +1
>
> Tested on several projects for few days and no issue encountered
>
>
> On Fri, Jun 20, 2014 at 8:51 AM, Olivier Lamy wro
Hi,
Fixed http://svn.apache.org/r1604171
So the output looks no like this:
libraryDependencies += "org.apache.maven.plugins.project-info-reports" %
"full-pom" % "1.0-SNAPSHOT"
Kind regards
Karl-Heinz Marbaise
On 6/20/14 3:28 PM, Karl Heinz Marbaise wrote:
Hi,
created an JIRA Issue for it:
Hi,
created an JIRA Issue for it:
http://jira.codehaus.org/browse/MPIR-296
Kind regards
Karl-Heinz Marbaise
On 6/20/14 2:30 PM, Jentsch wrote:
Hi,
I found little missleading dependency information for SBT generated by the
Info Reports Plugin[1].
I think the line 183 of DependencyInformationRe
For the purpose of this discussion I created a component (not necessary user
facing) call FDPFC which is "features dependent on pom format changes". I want
to be able to easily see of the 200 open issues in JIRA which ones relate to
this discussion.
I am going to sift through the issues this w
It went down hard today but I think fortunately I uncovered the issue.
The vm had hundreds of stuck puppet threads that slowly consumed all
the ram until ubuntu started kill -9'ing the pid. The slow death of
swap and ram likely explains a lot of the timeouts recently until
everything finally caved
Hi,
I found little missleading dependency information for SBT generated by the
Info Reports Plugin[1].
I think the line 183 of DependencyInformationReport.java[2] needs to be fixed
by replacing with %%:
renderDependencyInfo( "SBT", new Formatter().format( "libraryDependencies +=
\"%s\" %%
Hi,
first thanks to Igor and Tamás for the hints...
I've changed some of them...and now i'm faced with the following:
The output says "BUILD SUCCESS" but there are entries with "Skipped"...
[INFO] [INFO] Reading assembly descriptor:
src/assembly/src-zip-only-assembly.xml
Reading assembly d
Because users need to learn the new format.
The version number is not just for machines but for people too
On 20 June 2014 14:04, Igor Fedorenko wrote:
>
>
> On 2014-06-20, 7:59, Stephen Connolly wrote:
>
>> +1 on semver.
>>
>> Also if we change the schema or even the format (eg elements ->
>>
On 2014-06-20, 7:59, Stephen Connolly wrote:
+1 on semver.
Also if we change the schema or even the format (eg elements -> attributes,
xml -> DSL, etc) then we also bump the major even if there is a 1:1
bijection
If newer Maven versions can fully interpret new format without any loss
of con
"supplies" concept proposal
===
Introduction
The following is a proposal for Maven in a post-modelVersion-4.0.0 era. The
aim of this proposal is to simplify the management of dependency trees in
the decentralised era of artifact production that we find ourselv
+1 on semver.
Also if we change the schema or even the format (eg elements -> attributes,
xml -> DSL, etc) then we also bump the major even if there is a 1:1
bijection
On Friday, 20 June 2014, Igor Fedorenko wrote:
> I think ad-hoc aggregators are an interesting use case and I need to
> think a
I think ad-hoc aggregators are an interesting use case and I need to
think about it some more before I decide how I'd like to support it.
Anyways, all changes I currently have in mind are additions to the model
and reading older formats will not be a problem. Lets decide what to do
with truly inc
Components decide how often then are instantiated, so AssemblyArchiver
implementation(s) need to be changed.
You can use instantiationStrategy="per-lookup" to indicate new instance
is created each time component is injected. This is standard plexus/sisu
feature and should work on all Maven versio
In Plexus, you can make the plexus component "prototype" (as opposite of
current singleton) by adding
instantiationStrategy="per-lookup"
in that case, Plexus container will create new instance of the component
for every injection/lookup.
On Fri, Jun 20, 2014 at 1:20 PM, Karl Heinz Marbaise
w
Hi,
currently i'm working on a problem
(http://jira.codehaus.org/browse/MASSEMBLY-684) in the
maven-assembly-plugin which will fail if you use:
mvn -T2C clean package
after diving into that problem i found out that the components which are
being injected are always the same so far so good,
3 hints:
1. read Dan's explanations
/> If you set “setResolveTransitively(true)” then the/
/> ArtifactResolutionResponse would have all the deps available in it./
2. try Dan's code: it's pretty straightforward
3. explain what you want to see more than this code (which set everything to
let
cod
OK, so it will resolve from the reactor.
But is the ArtifactResolutionResult going to contain the dependencies of
the Artifact that I resolve?
On Fri, Jun 20, 2014 at 6:46 PM, Hervé BOUTEMY
wrote:
> Le vendredi 20 juin 2014 08:36:46 William Ferguson a écrit :
> > Hi Dan,
> >
> > if the Artifac
Le vendredi 20 juin 2014 08:36:46 William Ferguson a écrit :
> Hi Dan,
>
> if the ArtifactResolutionResult contains the deps for the Artifact in the
> request then that's exactly what I want. However I can't see that it does.
> What am I missing?
>
> NB the resolution also needs to be able to res
+1
Tested on several projects for few days and no issue encountered
On Fri, Jun 20, 2014 at 8:51 AM, Olivier Lamy wrote:
> +1
>
> --
> Olivier
> On Jun 18, 2014 2:04 AM, "Jason van Zyl" wrote:
>
> > Hi,
> >
> > Time to release Maven 3.2.2!
> >
> > Here is a link to Jira with 27 issues resolve
27 matches
Mail list logo
