[DISCUSS] Changing the Maven group ID for Spring Boot starters

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

Peter Palaga
Hi Zoran, inline...

On 13/06/2019 17:12, Zoran Regvart wrote:

> Hi Peter (again) :)
>
> On Thu, Jun 13, 2019 at 4:56 PM Peter Palaga <[hidden email]> wrote:
>> Given what you said, what are once again the benefits changing the
>> groupId of the SB starters?
>
> I've touched upon some of the benefits in my original e-mail[1], in
> short I think that having a separate namespace allows us some leeway
> in the future for having different kinds of starters. I was mostly
> prompted by this with the issue we had when we moved from supporting
> Spring Boot 1.5.x to supporting Spring Boot 2.x, if we had a separate
> namespace then, we could have had the possibility of supporting both
> versions, there were other reasons why this would be difficult, but
> not having separate namespace was one of them.

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 would like to have this option in the future, and doing this in
> Camel 3.x when we're allowing some breaking changes feels like the
> right moment to do it.
>
>> By breaking the 1:1:1 relationship between release cycle, groupId and
>> git repository, we will cause confusion and migration costs on the side
>> of the users and there certainly should exist benefits that outweight those.
>
> I know of several git repositories that release from one Maven graph
> with different group IDs, and I contribute to some of them, I've never
> experienced this issue, perhaps you can provide an example to make it
> a bit more clearer for me to reason about this?

Ok, let me try to give an example. Let's say you just joined projectX
that has something like the following in its dependencyManagement:

<dependency>
   <groupId>org.example</groupId>
   <artifactId>artifact-one</artifactId>
   <version>${org.example.version}</version>
<dependency>
<dependency>
   <!-- different groupId -->
   <groupId>org.example.foo</groupId>
   <artifactId>artifact-two</artifactId>
   <version>${org.example.version}</version>
<dependency>

Different groupId is a strong indicator of independent release cycle.
How much effort would it cost you to make sure that
${org.example.version} is correct for artifact-two in this particular
case? How would you proceed? Go to Maven Central and check that the
release dates of the two artifacts are roughly the same to conclude that
they really have the same release cycle? Is that maybe not reliable
enough? Maybe you'd rather make sure that the two artifacts were
released from the same git repo using the same git tag? How would you
figure out what is the correct git repository? I find this to be quite a
lot of work, that's it. I do not doubt it can work. It is just confusing
for the users.

Making all artifacts released together to have the same groupId is way
more common and it is safer to rely on it for the end users.

Thanks,

-- Peter

> zoran
>
> [1] https://mail-archives.apache.org/mod_mbox/camel-dev/201906.mbox/%3CCABD_Zr8z_iyw8O9o3xdNibkDwJa3ExzAj2RRSZu2hXag7MQumw%40mail.gmail.com%3E
>
> --
> Zoran Regvart
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

Andrea Cosentino-3
It's just a groupId name changed between camel version 2 and 3. To me, all
this discussion seems to be useless.



Il gio 13 giu 2019, 18:05 Peter Palaga <[hidden email]> ha scritto:

> Hi Zoran, inline...
>
> On 13/06/2019 17:12, Zoran Regvart wrote:
> > Hi Peter (again) :)
> >
> > On Thu, Jun 13, 2019 at 4:56 PM Peter Palaga <[hidden email]> wrote:
> >> Given what you said, what are once again the benefits changing the
> >> groupId of the SB starters?
> >
> > I've touched upon some of the benefits in my original e-mail[1], in
> > short I think that having a separate namespace allows us some leeway
> > in the future for having different kinds of starters. I was mostly
> > prompted by this with the issue we had when we moved from supporting
> > Spring Boot 1.5.x to supporting Spring Boot 2.x, if we had a separate
> > namespace then, we could have had the possibility of supporting both
> > versions, there were other reasons why this would be difficult, but
> > not having separate namespace was one of them.
>
> 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 would like to have this option in the future, and doing this in
> > Camel 3.x when we're allowing some breaking changes feels like the
> > right moment to do it.
> >
> >> By breaking the 1:1:1 relationship between release cycle, groupId and
> >> git repository, we will cause confusion and migration costs on the side
> >> of the users and there certainly should exist benefits that outweight
> those.
> >
> > I know of several git repositories that release from one Maven graph
> > with different group IDs, and I contribute to some of them, I've never
> > experienced this issue, perhaps you can provide an example to make it
> > a bit more clearer for me to reason about this?
>
> Ok, let me try to give an example. Let's say you just joined projectX
> that has something like the following in its dependencyManagement:
>
> <dependency>
>    <groupId>org.example</groupId>
>    <artifactId>artifact-one</artifactId>
>    <version>${org.example.version}</version>
> <dependency>
> <dependency>
>    <!-- different groupId -->
>    <groupId>org.example.foo</groupId>
>    <artifactId>artifact-two</artifactId>
>    <version>${org.example.version}</version>
> <dependency>
>
> Different groupId is a strong indicator of independent release cycle.
> How much effort would it cost you to make sure that
> ${org.example.version} is correct for artifact-two in this particular
> case? How would you proceed? Go to Maven Central and check that the
> release dates of the two artifacts are roughly the same to conclude that
> they really have the same release cycle? Is that maybe not reliable
> enough? Maybe you'd rather make sure that the two artifacts were
> released from the same git repo using the same git tag? How would you
> figure out what is the correct git repository? I find this to be quite a
> lot of work, that's it. I do not doubt it can work. It is just confusing
> for the users.
>
> Making all artifacts released together to have the same groupId is way
> more common and it is safer to rely on it for the end users.
>
> Thanks,
>
> -- Peter
>
> > zoran
> >
> > [1]
> https://mail-archives.apache.org/mod_mbox/camel-dev/201906.mbox/%3CCABD_Zr8z_iyw8O9o3xdNibkDwJa3ExzAj2RRSZu2hXag7MQumw%40mail.gmail.com%3E
> >
> > --
> > Zoran Regvart
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

Andrea Cosentino-3
The second artifact you are mentioning will be released under a different
release cycle and btw only for the first release of camel 3. If there will
be a new starter after that it will be for  3.1. Like we did in 2.x between
different versions, 2.23 vs 2.24 for example

Il gio 13 giu 2019, 19:03 Andrea Cosentino <[hidden email]> ha scritto:

> It's just a groupId name changed between camel version 2 and 3. To me, all
> this discussion seems to be useless.
>
>
>
> Il gio 13 giu 2019, 18:05 Peter Palaga <[hidden email]> ha scritto:
>
>> Hi Zoran, inline...
>>
>> On 13/06/2019 17:12, Zoran Regvart wrote:
>> > Hi Peter (again) :)
>> >
>> > On Thu, Jun 13, 2019 at 4:56 PM Peter Palaga <[hidden email]>
>> wrote:
>> >> Given what you said, what are once again the benefits changing the
>> >> groupId of the SB starters?
>> >
>> > I've touched upon some of the benefits in my original e-mail[1], in
>> > short I think that having a separate namespace allows us some leeway
>> > in the future for having different kinds of starters. I was mostly
>> > prompted by this with the issue we had when we moved from supporting
>> > Spring Boot 1.5.x to supporting Spring Boot 2.x, if we had a separate
>> > namespace then, we could have had the possibility of supporting both
>> > versions, there were other reasons why this would be difficult, but
>> > not having separate namespace was one of them.
>>
>> 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 would like to have this option in the future, and doing this in
>> > Camel 3.x when we're allowing some breaking changes feels like the
>> > right moment to do it.
>> >
>> >> By breaking the 1:1:1 relationship between release cycle, groupId and
>> >> git repository, we will cause confusion and migration costs on the side
>> >> of the users and there certainly should exist benefits that outweight
>> those.
>> >
>> > I know of several git repositories that release from one Maven graph
>> > with different group IDs, and I contribute to some of them, I've never
>> > experienced this issue, perhaps you can provide an example to make it
>> > a bit more clearer for me to reason about this?
>>
>> Ok, let me try to give an example. Let's say you just joined projectX
>> that has something like the following in its dependencyManagement:
>>
>> <dependency>
>>    <groupId>org.example</groupId>
>>    <artifactId>artifact-one</artifactId>
>>    <version>${org.example.version}</version>
>> <dependency>
>> <dependency>
>>    <!-- different groupId -->
>>    <groupId>org.example.foo</groupId>
>>    <artifactId>artifact-two</artifactId>
>>    <version>${org.example.version}</version>
>> <dependency>
>>
>> Different groupId is a strong indicator of independent release cycle.
>> How much effort would it cost you to make sure that
>> ${org.example.version} is correct for artifact-two in this particular
>> case? How would you proceed? Go to Maven Central and check that the
>> release dates of the two artifacts are roughly the same to conclude that
>> they really have the same release cycle? Is that maybe not reliable
>> enough? Maybe you'd rather make sure that the two artifacts were
>> released from the same git repo using the same git tag? How would you
>> figure out what is the correct git repository? I find this to be quite a
>> lot of work, that's it. I do not doubt it can work. It is just confusing
>> for the users.
>>
>> Making all artifacts released together to have the same groupId is way
>> more common and it is safer to rely on it for the end users.
>>
>> Thanks,
>>
>> -- Peter
>>
>> > zoran
>> >
>> > [1]
>> https://mail-archives.apache.org/mod_mbox/camel-dev/201906.mbox/%3CCABD_Zr8z_iyw8O9o3xdNibkDwJa3ExzAj2RRSZu2hXag7MQumw%40mail.gmail.com%3E
>> >
>> > --
>> > Zoran Regvart
>> >
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

Zoran Regvart-2
In reply to this post by Peter Palaga
Hi Peter,
thank you for voicing your opinions, I value your input

On Thu, Jun 13, 2019 at 6:05 PM Peter Palaga <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

gnodet
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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

Claus Ibsen-2
On Fri, Jun 14, 2019 at 1:27 AM Guillaume Nodet <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

Zoran Regvart-2
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 <[hidden email]> wrote:

>
> On Fri, Jun 14, 2019 at 1:27 AM Guillaume Nodet <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

Andrea Cosentino-3
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 <[hidden email]>
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 <[hidden email]> wrote:
> >
> > On Fri, Jun 14, 2019 at 1:27 AM Guillaume Nodet <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

Claus Ibsen-2
In reply to this post by Zoran Regvart-2
On Fri, Jun 14, 2019 at 9:27 AM Zoran Regvart <[hidden email]> wrote:

>
> 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?
>

No not strong, but if this was a vote I would voting -0.

At this point I dont see a compelling reason.
And I still prefer to have everything at org.apache.camel, which we
have always had.
And its all released together.


> Should we discuss moving Spring Boot starters to a different git
> repository instead?
>

Well yeah that is another thing. But as Andrea also says it adds more
complexity to the table.
We have a bunch of tools that generate -starter JARs, update doc
files, generate catalog metadata and so on.
Also it would cause a delayed release period as we may need to release
from 2 git repos when doing an Apache Camel release.
I would really be -1 against having different version / release
schedules for Apache Camel and the SB -starter JARs.
One of the big great things of Apache Camel is that its all in one
giant release,
and that you just use version X and then knows they work together.

But I don't want to be a dictator or that my opinion is stronger than
any other Camel PMC member or committer.
The majority of ppl here has reacted positive and casted a +1 vote.


> zoran
>
> On Fri, Jun 14, 2019 at 9:04 AM Claus Ibsen <[hidden email]> wrote:
> >
> > On Fri, Jun 14, 2019 at 1:27 AM Guillaume Nodet <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Changing the Maven group ID for Spring Boot starters

Andrea Cosentino-2
I'm ok on changing the groupId for the starters.

I'm totally -1 on moving the starters in a different repository now. 

I don't see any advantage in moving them in a different repository by the way.

--
Andrea Cosentino 
----------------------------------
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: [hidden email]
Twitter: @oscerd2
Github: oscerd






On Friday, June 14, 2019, 10:24:30 AM GMT+2, Claus Ibsen <[hidden email]> wrote:





On Fri, Jun 14, 2019 at 9:27 AM Zoran Regvart <[hidden email]> wrote:

>
> 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?
>

No not strong, but if this was a vote I would voting -0.

At this point I dont see a compelling reason.
And I still prefer to have everything at org.apache.camel, which we
have always had.
And its all released together.


> Should we discuss moving Spring Boot starters to a different git
> repository instead?
>

Well yeah that is another thing. But as Andrea also says it adds more
complexity to the table.
We have a bunch of tools that generate -starter JARs, update doc
files, generate catalog metadata and so on.
Also it would cause a delayed release period as we may need to release
from 2 git repos when doing an Apache Camel release.
I would really be -1 against having different version / release
schedules for Apache Camel and the SB -starter JARs.
One of the big great things of Apache Camel is that its all in one
giant release,
and that you just use version X and then knows they work together.

But I don't want to be a dictator or that my opinion is stronger than
any other Camel PMC member or committer.
The majority of ppl here has reacted positive and casted a +1 vote.


> zoran
>
> On Fri, Jun 14, 2019 at 9:04 AM Claus Ibsen <[hidden email]> wrote:
> >
> > On Fri, Jun 14, 2019 at 1:27 AM Guillaume Nodet <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
12