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
