[
https://issues.apache.org/jira/browse/CAMEL-11247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007729#comment-16007729
]
Nicola Ferraro commented on CAMEL-11247:
----------------------------------------
I don't know if we are talking about the same problem with Jetty, but I do
think that managing maven BOMs is not a perfect science, since you have to deal
with what others do.
There are still many projects that tend to put everything in their BOMs and
this becomes a problem when such BOMs start being used worldwide. For example,
this one is particularly full of external stuff, causing us a lot of trouble:
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-dependencies/pom.xml
(I'm just kidding :D)
Unfortunately, Camel can live also without spring-boot, and we upgrade
dependencies on other libraries frequently. Users run Camel from a simple main,
on Karaf or other platforms. We cannot create a single set of artifacts that
are valid everywhere. We have "standard" modules for plain main, "features" for
karaf, "modules" for Wildfly (that's external to Apache, but it's "big") and
"starters" for spring-boot. The BOM we are now trying to create is called
camel-spring-boot-bom because it is intended to be used with spring-boot, and
so it contains the "starters" only...
Jetty was an example, but there are other issues to consider. Once you
establish that ALL spring-boot applications must have a specific version of
Jackson or Gson (and you do so), we have to take into account that there can be
some modules that cannot work with that specific version of Jackson (usually
trivial API incompatibilities), unless you upgrade/downgrade a third library,
sometimes one that is transitively imported by the module, and since it's
probably a library you're even not aware of, you cannot add it to the
spring-boot BOM.
We control such versions in the "camel-spring-boot-dependencies" BOM, that now
is the suggested BOM for using camel on spring-boot. Once we find a version
mismatch, we fix it. Recently we have removed some modules that were causing
such issues, so the amount of mismatches is much lower, but the mechanism works
when needed.
Agreed, cooperation is the best thing in this context, so for case of missing
artifacts in the spring-boot list, I'll be happy to report them in the future.
Thanks for the suggestion.
About the "${project.version}" and the other dependency: I think they will
never create problems to the users. But I can change them to make the code more
readable. The parent is causing two more maven lookups. Versions can only be
overridden if you use the Camel BOM as parent project, and it will never be the
case.
The real problem with the minimal BOM is that I forgot how deep the Maven hell
is (and my last comment about transitive dependencies on the starters is
wrong). BOMs imported in dependent libraries are completely ignored, so even if
our starters import the "camel-spring-boot-dependencies" BOM, it is not used at
all when the starter is imported in the user application. What I need to do is
to review the "camel-spring-boot-dependencies" BOM, since we have removed a lot
of stuff from there, and check if I can move stuff from there to the starters
that are using that dependencies, so that everything can work also with the
minimal BOM (or no BOM at all). If we change strategy and manage
incompatibilities directly in the starters (since we should not have global
incompatibilities now), we may obtain a minimal BOM by reducing
"camel-spring-boot-dependencies" one, so no changes for our users.
> camel-spring-boot - Improve BOM to work better with start.spring.io
> -------------------------------------------------------------------
>
> Key: CAMEL-11247
> URL: https://issues.apache.org/jira/browse/CAMEL-11247
> Project: Camel
> Issue Type: Improvement
> Components: camel-spring-boot, camel-spring-boot-starters
> Reporter: Claus Ibsen
> Assignee: Nicola Ferraro
> Fix For: 2.20.0
>
>
> See this PR
> https://github.com/spring-io/initializr/pull/425#issuecomment-299801788
> I tried locally to set the initializer to use our current BOM for spring-boot
> starters, but the project it generates causes the mvn to not build.
> We should IMHO try to get this working so we can use a BOM in the
> start.spring.io wizard so people get a nicer project build out of the box.
> Which is also what the Spring guys is asking for.
> You can try the initializer locally, by following instructions at
> https://github.com/spring-io/initializr#running-the-app-locally
> Then you can thinker in the yml file to setup a Camel BOM
> https://github.com/spring-io/initializr/blob/master/initializr-service/src/main/resources/application.yml
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
