Hi Peter,
thank you for your feedback :)
On Thu, Jun 13, 2019 at 4:29 PM Peter Palaga <ppal...@redhat.com> wrote:
> as far as I can understand, moving the Spring Boot starters to a
> separate git repository is not a part of this plan, right?
No, we can't do that easily, starters are generated from component
code, having this across two repositories would make this more
complicated.
> 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.
We're discussing changing just the group ID, we're not discussing
having a separate release cycle or separate version for the starters.
Can you elaborate on how the version management would get more
difficult, perhaps there's something I'm not aware of?
> 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.
That's another reason to go with `org.apache.camel.spring.boot` as the
group ID, do you see any issues with that in Eclipse?
zoran
--
Zoran Regvart
