camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ferraro (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-11247) camel-spring-boot - Improve BOM to work better with start.spring.io
Date Fri, 12 May 2017 07:13:04 GMT

    [ 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)

Mime
View raw message