Hi Guillaume and Claus,
I think your points are valid and they might make me change my mind on this.
If I can put one more argument for changing the group ID that would be
that the `org.apache.came:xyz-starter` coordinate signals a starter
for Camel not for Spring Boot, but than again this is purely
subjective.
Are your opinions strongly held? Do you see a way for changing the
group ID for starters or any benefits at all in doing that?
Should we discuss moving Spring Boot starters to a different git
repository instead?
zoran
On Fri, Jun 14, 2019 at 9:04 AM Claus Ibsen <claus.ib...@gmail.com> wrote:
>
> On Fri, Jun 14, 2019 at 1:27 AM Guillaume Nodet <gno...@apache.org> wrote:
> >
> > 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...
> >
>
> Well said Guillaume
>
> I don't want to try to support two different spring boot versions at
> the same time. When a new big Spring Boot is released we upgrade to it
> at some point and drop the old (or if the old is still compatible its
> "best effort" support).
>
> I do like that everything is under the same group-id, then its all of
> a single Apache Camel release. I am not keen on projects that has a
> gazillion different group ids, and sometimes even many different
> versions, as if you know how to mix them together to get a working set
> you need, or how to use latest.
>
> At least with Camel its org.apache.camel, and then the same version
> across the board. And we also have a BOM for end users to use.
>
>
> I still fail to see what is the big reason for changing the group id,
> and then why only for these starters?
> They are already separated in their artefact id, with -starter.
>
> Also its more typing, i dont really like these maven dependencies that
> has very long group ids, and artifact ids. They are very long to type,
> and you forget what they are named - with Camel its just
> org.apache.camel ;) and then tools can assist you with the artifact
> ids.
>
>
> And then we have the problem with camel-spring-boot, should it then
> also be changed? And what about the maven archetype that creates a
> spring boot project? Or the spring boot examples? Okay I am being a
> bit silly with the last two, but camel-spring-boot is still
> org.apache.camel, or should it be the only component that is
> org.apache.camel.spring.boot
>
> Anyway if something is going to change its better to do it before 3.0 GA.
>
>
>
>
>
>
>
>
>
>
> > 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
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
Zoran Regvart
