Moving the starters out of the current repository is not really
straightforward.
We have a lot of points related in the code.
Il giorno ven 14 giu 2019 alle ore 09:27 Zoran Regvart <zo...@regvart.com>
ha scritto:
> 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
>
