Re: Build vs Consumer POM study

Hello Chris, I do think that a consumer pom might be a good thing. It will provide backwards compatibility for current Maven, Gradle, sbt, kobalt etc. users and allow to improve the model for those using future Maven versions for building stuff. Best regards Mirko -- Sent from my mobile Chris G

Re: Build vs Consumer POM study

If I've read through (and understood !!!) this thread correctly, then I'd like to add this: As the discussions reflect the mature (read: wierd and wonderful!) ways that Maven is being used, then it is looking like more and more edge cases are coming up (eg, profiles), and that would appear to redu

Re: Build vs Consumer POM study

Hi Mirko, On Tue, 17 Apr 2018 04:44:57 + Mirko Friedenhagen wrote: > Hello Jörg, > > I understand your problem, however this is quite specific. AFAIK > currently profiles are *not* evaluated while resolving imported > dependencies, only those inherited, so this would be a very drastic > chan

Re: Build vs Consumer POM study

Hello Jörg, I understand your problem, however this is quite specific. AFAIK currently profiles are *not* evaluated while resolving imported dependencies, only those inherited, so this would be a very drastic change. For your eclipse example: maybe put OS specific stuff in modules and mark them a

Re: Build vs Consumer POM study

On Mon, 16 Apr 2018 21:46:21 + Mirko Friedenhagen wrote: > Hello, > > I do not see why profiles should be part of the consumer pom. If you're building a library based on SWT you have: - org.eclipse.swt:org.eclipse.swt.win32.win32.x84:3.106.0.v20170608-0516 - org.eclipse.swt:org.eclipse.swt.

Re: Build vs Consumer POM study

Hello, I do not see why profiles should be part of the consumer pom. That would require evaluating profiles on import and I do not think this to be a good idea. At work I created a division pom with own lifecycles and profiles to achieve automated packaging and upload/Maven-deploy of spring-boot

Re: Build vs Consumer POM study

On Wed, 14 Mar 2018 23:38:41 +0100, Hervé BOUTEMY wrote: Le mercredi 14 mars 2018, 09:10:20 CET Robert Scholte a écrit : The more I think about this, the more I believe we should approach this a little bit different. There are discussions which parts should be part and which shouldn't.

Re: Build vs Consumer POM study

Hello all, As you have reflected on earlier, it is possible although somewhat clunky to implement the Consumer vs Build POM today using the Maven Enforcer and a custom rule to identify the two types of POM. I have done one such implementation (found at GitHub

Re: Build vs Consumer POM study

Le jeudi 15 mars 2018, 11:18:35 CET Martijn Dashorst a écrit : > Just to throw this out there: > > The consumer POM should only contain the non-dynamic bits that can > change outside the scope of the artifacts that are described by the > POM. > > The consumer POM should consist of only the invari

Re: Build vs Consumer POM study

Just to throw this out there: The consumer POM should only contain the non-dynamic bits that can change outside the scope of the artifacts that are described by the POM. The consumer POM should consist of only the invariant parts of the released artifacts: coordinates, dependencies, license, Ther

Re: Build vs Consumer POM study

IMHO, in this case, the dependency should be defined in the profile in the consumer POM, with resolved property of the profile. I don't know if flatten-maven-plugin currently detects such a situation and is able to move the parametrized dependency in main section to non-parametrized dependency

Re: Build vs Consumer POM study

Le mercredi 14 mars 2018, 09:10:20 CET Robert Scholte a écrit : > The more I think about this, the more I believe we should approach this a > little bit different. > > There are discussions which parts should be part and which shouldn't. But > is this up to us/Maven? I don't get the intend here >

Re: Build vs Consumer POM study

Am Mon, 12 Mar 2018 01:12:52 +0100 schrieb Hervé BOUTEMY: [snip] >> > Why is required for consumers? I'm not aware how profiles >> > of a dependency ever play(ed) a role in my "dependent" project? >> I can remember we had a discussion about that..my first reaction would >> be saying no profiles

Re: Build vs Consumer POM study

The more I think about this, the more I believe we should approach this a little bit different. There are discussions which parts should be part and which shouldn't. But is this up to us/Maven? How about removing those bits that are useless, i.e build and reporting and I tend to agree on di

Re: Build vs Consumer POM study

Le mercredi 14 mars 2018, 01:37:38 CET Laird Nelson a écrit : > On Tue, Mar 13, 2018 at 5:34 PM Hervé BOUTEMY wrote: > > I don't see any issues with content provided: > > org.springframework.boot:spring- > > boot-dependencies has a "pom" packaging, then would be deployed directly > > as > > build

Re: Build vs Consumer POM study

Le mardi 13 mars 2018, 22:47:50 CET Michael Osipov a écrit : > Am 2018-03-13 um 18:23 schrieb Robert Scholte: > > On Tue, 13 Mar 2018 00:13:59 +0100, Hervé BOUTEMY > > > > wrote: > >> Hi Charles, > >> > >> Thanks for the feedback > >> > >> Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a éc

Re: Build vs Consumer POM study

On Tue, Mar 13, 2018 at 5:34 PM Hervé BOUTEMY wrote: > I don't see any issues with content provided: > org.springframework.boot:spring- > boot-dependencies has a "pom" packaging, then would be deployed directly as > build POM, containing dependencyManagement > I'm not sure, but I think the quest

Re: Build vs Consumer POM study

Le mardi 13 mars 2018, 21:59:56 CET Andreas Sewe a écrit : > Hi, > > as a user of Maven and a researcher analyzing what's in Maven central, I > would prefer to see > > > > in the "kept by choice" category as well. While may be > more useful for end-user facing tools, in this day and age of b

Re: Build vs Consumer POM study

I don't see any issues with content provided: org.springframework.boot:spring- boot-dependencies has a "pom" packaging, then would be deployed directly as build POM, containing dependencyManagement Regards, Hervé Le mardi 13 mars 2018, 12:25:21 CET Arnaud Héritier a écrit : > Spring Boot (but

Re: Build vs Consumer POM study

Am 2018-03-13 um 18:23 schrieb Robert Scholte: On Tue, 13 Mar 2018 00:13:59 +0100, Hervé BOUTEMY wrote: Hi Charles, Thanks for the feedback Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit : Hervé, Great work! Thank you: it took a lot of time and discussion :) Some possible a

Re: Build vs Consumer POM study

Hi, as a user of Maven and a researcher analyzing what's in Maven central, I would prefer to see in the "kept by choice" category as well. While may be more useful for end-user facing tools, in this day and age of badges pointing to CI servers on Github, I can still see this as useful for co

Re: Build vs Consumer POM study

Hi, > Naming Conventions > consumer pom must continue to be named pom.xml > build pom shall be called build.xml Please don't re-use a name already occupied by another build tool (in this case, Ant). Many IDEs associate editors based on file name and this would confuse them. Eclipse, for example,

Re: Build vs Consumer POM study

On Tue, 13 Mar 2018 00:13:59 +0100, Hervé BOUTEMY wrote: Hi Charles, Thanks for the feedback Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit : Hervé, Great work! Thank you: it took a lot of time and discussion :) Some possible additions for the wiki page: Naming Conventions

Re: Build vs Consumer POM study

Spring Boot (but others are doing too) is using a lot the dependencies with ~empty jar artifacts ( http://repo.maven.apache.org/maven2/org/springframework/boot/spring-boot-starter-web/2.0.0.RELEASE/ ) You declare something like : org.springframework.boot spring-boot-dependenc

Re: Build vs Consumer POM study

Le mardi 13 mars 2018, 06:11:20 CET Chas Honton a écrit : > Re: updating source plugin - > > For Apache projects, all sources required to build and test the release must > be part of the distribution. It would be useful to any Apache project that > desires to build a release through the source plu

Re: Build vs Consumer POM study

Re: updating source plugin - For Apache projects, all sources required to build and test the release must be part of the distribution. It would be useful to any Apache project that desires to build a release through the source plugin to have the build pom automatically packaged. For non-Apach

Re: Build vs Consumer POM study

Hi Charles, Thanks for the feedback Le lundi 12 mars 2018, 01:49:26 CET Charles Honton a écrit : > Hervé, > > Great work! Thank you: it took a lot of time and discussion :) > Some possible additions for the wiki page: > > Naming Conventions > consumer pom must continue to be named pom.xml > bu

Re: Build vs Consumer POM study

Hervé, Great work! Some possible additions for the wiki page: Naming Conventions consumer pom must continue to be named pom.xml build pom shall be called build.xml alternate build inputs could be build.json or build.yaml EcoSystem Impacts projects distributing source code through maven central

Re: Build vs Consumer POM study

Le dimanche 11 mars 2018, 22:48:18 CET Karl Heinz Marbaise a écrit : > Hi, > > On 11/03/18 22:37, Sander Verhagen wrote: > > This is a great proposal, even in its current form. But as a long term > > Maven user, > I have a few modest questions and remarks, though. (Sorry if you didn't > mean for n

Re: Build vs Consumer POM study

Le dimanche 11 mars 2018, 21:14:16 CET Karl Heinz Marbaise a écrit : > Hi Hervé, > > On 11/03/18 21:05, Hervé BOUTEMY wrote: > > Le dimanche 11 mars 2018, 20:36:15 CET Tibor Digana a écrit : > >> Why the column with build POM in table does not have all items green +? > > > > ok, I should probably

Re: Build vs Consumer POM study

Hi, On 11/03/18 22:37, Sander Verhagen wrote: This is a great proposal, even in its current form. But as a long term Maven user, > I have a few modest questions and remarks, though. (Sorry if you didn't mean for non-developer to chime in...) It's really good to hear from a Maven user. This i

Re: Build vs Consumer POM study

This is a great proposal, even in its current form. But as a long term Maven user, I have a few modest questions and remarks, though. (Sorry if you didn't mean for non-developer to chime in...) It would probably good to mandate some sort of still, and to have a hint of a strategy in place for

Re: Build vs Consumer POM study

Hi Hervé, On 11/03/18 21:05, Hervé BOUTEMY wrote: Le dimanche 11 mars 2018, 20:36:15 CET Tibor Digana a écrit : Why the column with build POM in table does not have all items green +? ok, I should probably simply not have put this column: it is confusing. Just ignore this column Why there ar

Re: Build vs Consumer POM study

Le dimanche 11 mars 2018, 20:40:39 CET Tibor Digana a écrit : > Is the consumer POM useful only for packaging=jar? no, it's useful for any packaging not =pom > Because which other packagings use to have transitive dependencies as well? remember: consumer POM is just an explicit reduction of curren

Re: Build vs Consumer POM study

Le dimanche 11 mars 2018, 20:36:15 CET Tibor Digana a écrit : > Why the column with build POM in table does not have all items green +? ok, I should probably simply not have put this column: it is confusing. Just ignore this column > Why there are two consumer POM's? Some is old proposal and secon

Re: Build vs Consumer POM study

Is the consumer POM useful only for packaging=jar? Because which other packagings use to have transitive dependencies as well? On Sun, Mar 11, 2018 at 8:36 PM, Tibor Digana wrote: > Why the column with build POM in table does not have all items green +? > Why there are two consumer POM's? Some i

Re: Build vs Consumer POM study

Why the column with build POM in table does not have all items green +? Why there are two consumer POM's? Some is old proposal and second is yours? Some consumer POMs may become BOM and there I would miss dependencyManagement. On Sun, Mar 11, 2018 at 6:03 PM, Hervé BOUTEMY wrote: > Hi, > > I wro

Build vs Consumer POM study

Hi, I wrote a Proposal in the Wiki about Build vs Consumer POM [1] and coded a simplified model for the Consumer POM [2] As written in the proposal, this would permit us to create new POM versions that change everything but not the Consumer POM part without breaking any compatibility with exist