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 :
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
....
and you have everything to develop your web front-end
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-starters/spring-boot-starter-web/pom.xml
This is contrary to the maven philosophy where you should explicitely
declare every artifact you are using to avoid the surprise of a dependency
change which removes / modifies some of them but it has the advantage to
keep your pom readable and the dependencies under control (of the
framework)
The mega BOM is here :
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-dependencies/pom.xml
And it imports some others boms
On Mon, Mar 12, 2018 at 1:05 AM, Hervé BOUTEMY <herve.bout...@free.fr>
wrote:
> 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 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 second is
> > >> yours?
> > >
> > > thre are 2 columns for decision: the first one means it's necessary,
> the
> > > second it's just a choice
> > > perhaps keeping only one column with good emoticon choices would have
> > > avoided confusion
> > >
> > >> Some consumer POMs may become BOM and there I would miss
> > >> dependencyManagement.
> > >
> > > an example please?
> >
> > a famous example are the bom's of the Spring / Spring Boot project...
> > these are the first which are coming into my mind...
> coordinates please
>
> Regards,
>
> Hervé
>
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > > Regards,
> > >
> > > Hervé
> > >
> > >> On Sun, Mar 11, 2018 at 6:03 PM, Hervé BOUTEMY <herve.bout...@free.fr
> >
> > >>
> > >> wrote:
> > >>> 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 existing Central repository users: build element
> is
> > >>> the
> > >>> main element that could be changed, adding new build
> > >>> features/configuration
> > >>> without affecting consumers.
> > >>>
> > >>> In addition to reviewing choices proposed for majority of POM
> elements,
> > >>> there
> > >>> are 4 elements that require more discussion:
> > >>> - contributors
> > >>> - mailingLists
> > >>> - repositories
> > >>> - profiles/activation
> > >>>
> > >>> Any thoughts?
> > >>>
> > >>> On the code, IMHO, the only missing part is a test of
> > >>> flatten-maven-plugin
> > >>> to
> > >>> check that everything works as expected in any situation.
> > >>> And I suppose a discussion on what we do for the xsd
> > >>>
> > >>> Then we should be able to use this strategy for our own artifacts,
> > >>> before
> > >>> updating POM model version in any newer Maven version starting with
> 3.6
> > >>> (yay!)
> > >>>
> > >>> Regards,
> > >>>
> > >>> Hervé
> > >>>
> > >>>
> > >>> [1] https://cwiki.apache.org/confluence/display/MAVEN/
> > >>> Build+vs+Consumer+POM
> > >>>
> > >>> [2] http://maven.apache.org/studies/consumer-pom/maven-consumer.html
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
