Le mercredi 24 août 2016 13:50:33 Robert Scholte a écrit :
> I realized last ApacheCon that I wasn't clear about my definiton of the
> consumer-pom.
> I don't think it should be a flattened pom with only the dependency
> information. Instead it shouldn't be a pom (matching the pom.xsd) at all.
IMH
On 24 August 2016 at 04:50, Robert Scholte wrote:
> I realized last ApacheCon that I wasn't clear about my definiton of the
> consumer-pom.
> I don't think it should be a flattened pom with only the dependency
> information. Instead it shouldn't be a pom (matching the pom.xsd) at all.
>
I am no
+1: here is my voice
On 8/24/16, Karl Heinz Marbaise wrote:
> Hi,
>
> We solved 33 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12331760
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2
Hi,
We solved 33 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12331760
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority
Hi Björn,
On 24/08/16 08:57, Björn Höfling wrote:
Hi Karl Heinz,
On Tue, 23 Aug 2016 21:51:11 +0200
Karl Heinz Marbaise wrote:
Hi Björn,
On 23/08/16 08:25, Björn Höfling wrote:
I want to build maven without haven _ANY_ maven/plugin binary. How
can I do that?
First you can do that only ti
Am 08/24/16 um 08:23 schrieb Hervé BOUTEMY:
> version ranges: I hate version ranges... :)
> notice: what is the issue with version ranges? the generated consumer pom can
> contain version ranges, since it is a long-standing feature
It would be really cool if the whole dependency resolution could
I realized last ApacheCon that I wasn't clear about my definiton of the
consumer-pom.
I don't think it should be a flattened pom with only the dependency
information. Instead it shouldn't be a pom (matching the pom.xsd) at all.
Maybe it should be called something like consumer-dom (dependency
On Wed, Aug 24, 2016 at 11:08 AM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> On Wed, Aug 24, 2016 at 8:41 AM, Fred Cooke wrote:
> > Fair call re embedded pom, however it's quite convenient to just browse
> to
> > it and read.
> I'd like to vent another opinion: the build pom makes it
On Wed, Aug 24, 2016 at 8:41 AM, Fred Cooke wrote:
> Fair call re embedded pom, however it's quite convenient to just browse to
> it and read.
I'd like to vent another opinion: the build pom makes it hard to grok
the information I need as a consumer of a library. I really don't need
to wade throu
The consumer Pom is for machine to machine, it should be human readable
because that is nice, but intent is never human generated.
Switching to this separation allows us to be more radical in the changes to
the build Pom.
The only reason we deploy packaging Pom's build Pom is for inheritance. If
I still find it a bit off that the original real POM won't always be
directly available anymore.
Other tools create fake POMs because they *have* to - there's no other
option.
I feel like some fidelity would be lost. Diffability would be lost (from a
scenario where there's nothing to diff).
Unre
11 matches
Mail list logo
