It's just a groupId name changed between camel version 2 and 3. To me, all
this discussion seems to be useless.
Il gio 13 giu 2019, 18:05 Peter Palaga <ppal...@redhat.com> ha scritto:
> 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
> >
>
>
