Fwiw, given the way the source tree is laid out, I don't foresee supporting
a new major version of spring-boot side-by-side with the current version.
The reason is that it would add another 200 artifacts to the build, which
is already way too big.
Depending on where the quarkus proposal go, we may already add a fair
number of artifacts to our build in the future, and it does not seem that
maven scales to thousands of artifacts very well ...
So if we ever need to switch to spring-boot 2 or 3 in the future, I think
we should not try to support both in the same source tree. If that ever
comes to this point, I think this would be a good incentive to move the
starters in a different git repo (even if that's not what we're discussing
here).
So I think the main argument for switching the groupId does not really hold.
While, having different groupIds in the build does not cause me any issue
as I know a bunch of other projects which have groupIds following a
hierarchy, I don't really see the benefit, unless we do that for other
parts of the project too: having examples with org.apache.camel.examples,
components with org.apache.camel.components, etc...
Le ven. 14 juin 2019 à 01:10, Zoran Regvart <zo...@regvart.com> a écrit :
> Hi Peter,
> thank you for voicing your opinions, I value your input
>
> On Thu, Jun 13, 2019 at 6:05 PM Peter Palaga <ppal...@redhat.com> wrote:
> > 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 think its the same argument you're trying to make, making it easier
> on the users, for instance migrating from
> `org.apache.camel.spring.boot` to a future
> `org.apache.camel.spring.boot3` would be a bit easier to do but I
> would argue also easier to discover and grasp. I think having a plan
> that makes this transition easier is a good thing.
>
> At some point we'll need to discuss how we're going to address Java
> modules and I think, even though it's early days, the issue of having
> `org.apache.camel` as the sole group ID will need to be addressed.
>
> It seems that your whole argument can be summarized by the following:
>
> > Different groupId is a strong indicator of independent release cycle.
>
> I don't find it universally true, contributors need to discover much
> more than the link between a group ID/version and git repository, and
> I think users generally don't perceive this as an issue as they are
> guided by documentation and examples. The argument is about perception
> which would make it by definition subjective.
>
> Your opinion does matter and I think I've tried to understand the
> motivation and the potential drawbacks/benefits from keeping the same
> group ID based on that, but I remain convinced that having a different
> group ID would be a better way.
>
> I don't think we can find an objective measurement to determine what
> would be the best thing to do, so I have to stay by my opinion.
>
> If there are no other issues anyone want's to bring on this topic, I
> will proceed with this in a few days, let's leave some time for folk
> to think about this and voice their concerns,
>
> Thank you :)
>
> zoran
> --
> Zoran Regvart
>
--
------------------------
Guillaume Nodet
