Hi Zoran, inline...
On 13/06/2019 17:12, Zoran Regvart wrote:
Hi Peter (again) :)
On Thu, Jun 13, 2019 at 4:56 PM Peter Palaga <ppal...@redhat.com> wrote:
Given what you said, what are once again the benefits changing the
groupId of the SB starters?
I've touched upon some of the benefits in my original e-mail[1], in
short I think that having a separate namespace allows us some leeway
in the future for having different kinds of starters. I was mostly
prompted by this with the issue we had when we moved from supporting
Spring Boot 1.5.x to supporting Spring Boot 2.x, if we had a separate
namespace then, we could have had the possibility of supporting both
versions, there were other reasons why this would be difficult, but
not having separate namespace was one of them.
I do not follow how having org.apache.camel.spring.boot "allows" for
having org.apache.camel.spring.boot{n} in the future. You can add
org.apache.camel.spring.boot{n} at any point in time with or without
having org.apache.camel.spring.boot. Are there any other implicit
benefits I do not see?
I would like to have this option in the future, and doing this in
Camel 3.x when we're allowing some breaking changes feels like the
right moment to do it.
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.
I know of several git repositories that release from one Maven graph
with different group IDs, and I contribute to some of them, I've never
experienced this issue, perhaps you can provide an example to make it
a bit more clearer for me to reason about this?
Ok, let me try to give an example. Let's say you just joined projectX
that has something like the following in its dependencyManagement:
<dependency>
<groupId>org.example</groupId>
<artifactId>artifact-one</artifactId>
<version>${org.example.version}</version>
<dependency>
<dependency>
<!-- different groupId -->
<groupId>org.example.foo</groupId>
<artifactId>artifact-two</artifactId>
<version>${org.example.version}</version>
<dependency>
Different groupId is a strong indicator of independent release cycle.
How much effort would it cost you to make sure that
${org.example.version} is correct for artifact-two in this particular
case? How would you proceed? Go to Maven Central and check that the
release dates of the two artifacts are roughly the same to conclude that
they really have the same release cycle? Is that maybe not reliable
enough? Maybe you'd rather make sure that the two artifacts were
released from the same git repo using the same git tag? How would you
figure out what is the correct git repository? I find this to be quite a
lot of work, that's it. I do not doubt it can work. It is just confusing
for the users.
Making all artifacts released together to have the same groupId is way
more common and it is safer to rely on it for the end users.
Thanks,
-- Peter
zoran
[1]
https://mail-archives.apache.org/mod_mbox/camel-dev/201906.mbox/%3CCABD_Zr8z_iyw8O9o3xdNibkDwJa3ExzAj2RRSZu2hXag7MQumw%40mail.gmail.com%3E
--
Zoran Regvart
