Thanks, Andrea, for the clarification.
Given what you said, what are once again the benefits changing the
groupId of the SB starters?
By breaking the 1:1:1 relationship between release cycle, groupId and
git repository, we will cause confusion and migration costs on the side
of the users and there certainly should exist benefits that outweight those.
Thanks,
-- Peter
On 13/06/2019 16:40, Andrea Cosentino wrote:
Hello Peter,
We can do this until we are under heavy development like we are now on
Camel 3.
The groupId won't change anymore once we release 3.0.0 final release. This
is why we are discussing this now.
For the second question, there is no plan to split and support multiple
different starters for different SB version. That was only a pour parler
about possible scenarios.
We can eventually think about it later, if it will be the case.
Moving to a different repository the Spring Boot starters is not part of
this discussion, because it's not something straightforward.
Cheers.
Il giorno gio 13 giu 2019 alle ore 16:35 Peter Palaga <ppal...@redhat.com>
ha scritto:
Hi Zoran,
as far as I can understand, moving the Spring Boot starters to a
separate git repository is not a part of this plan, right?
If so, I tend to think this is not a good idea. Here is why:
1. Having a 1:1:1 relationship between release cycle, groupId and git
repository seems to be the most common practice in the maven world.
Following common practices is an advantage on its own because it saves
time by not requiring to learn any local peculiarities.
Sticking with the practice of having 1:1:1 between release cycle,
groupId and git repository, allows the projects depending on Camel to
check that they manage the right version of our artifacts: if all
artifacts of one groupId (and nothing else) refer to the same
${camel.version} property, all is fine. But once you break the 1:1:1 in
some way, the versions management becomes a hell of nitty-gritty details
that even may change over time.
2. If this is going to lead to a situation in which we'll have the same
artifact id in multiple groupIds (something like
org.apache.camel.spring.boot1:starter-1 and
org.apache.camel.spring.boot2:starter-1) then Eclipse users (including
me) are going to stop liking you. Eclipse requires manual hacks in
situations like that. Having a different artifactId is much more painless.
Thanks,
-- Peter
On 12/06/2019 12:08, Zoran Regvart wrote:
Hi Cameleers,
we publish Spring Boot starters with the Maven group ID of
`org.apache.camel`, I think it would be better if we publish them with
another group ID, something like `org.apache.camel.spring.boot`.
My reasoning is that with time there might be other kinds of starters,
even within the Spring ecosystem, we might event add some versioning
information in the group ID, like `org.apache.camel.spring.boot2`,
this might open the doors for supporting multiple (possibly mutually
exclusive) versions of Spring Boot.
What do you think?
zoran
