The benefits are in what Zoran described in the starting email.
There will be anyway a migration effort for the end users once they'll pass
to Camel 3.
I believe we are limiting the migration effort already, changing a groupId
of a starter is not a big problem and it doesn't add too much effort on the
end users.
This is not confusion. This is what happens when you pass through a major
upgrade. The milestone release we released are just litte step through the
final release.
You need to consider the migration from 2.x to 3.x and there will be a bit
of migration effort already for the end users.
Il giorno gio 13 giu 2019 alle ore 16:56 Peter Palaga <ppal...@redhat.com>
ha scritto:
> 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
> >>>
> >>
> >>
> >
>
>
