Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #11720 > unrolled thread

[Help] gradle-plugin-protobuf

Back to article view | Back to linux.debian.maint.java

Contents

  [Help] gradle-plugin-protobuf Samyak Jain <samyak.jn11@gmail.com> - 2020-06-23 14:20 +0200
    Re: [Help] gradle-plugin-protobuf Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-06-23 14:30 +0200
      Re: [Help] gradle-plugin-protobuf Samyak Jain <samyak.jn11@gmail.com> - 2020-06-23 19:00 +0200
        Re: [Help] gradle-plugin-protobuf Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-06-23 19:50 +0200
    Fwd: [Help] gradle-plugin-protobuf Olek Wojnar <olek@debian.org> - 2020-06-23 19:20 +0200
      Re: [Help] gradle-plugin-protobuf Thorsten Glaser <t.glaser@tarent.de> - 2020-06-23 22:00 +0200

#11720 — [Help] gradle-plugin-protobuf

[Multipart message — attachments visible in raw view] — view raw

Hey,

The package gradle-plugin-protobuf exists in Java-Team and hasn't been
updated in the past few years [1].

While parsing through dependencies for bundletools. Yesterday, on reviewing
through the same I found a problem which is creating the conflict. The
problem is that the upstream source package is moved from
ws.antonov.gradle.plugins:gradle-plugin-protobuf:0.9.1 [2]
to com.google.protobuf:protobuf-gradle-plugin:0.8.8 [3].

Therefore it is utter importance to update/switch to the latest upstream
available. I'm ready to help with the update until unless someone is doing
it, already.

Also, a quick question, what will be the most feasible manner for the
update? To archive the existing obsolete package and packaging the new
upstream source (as we have a new tag versioning) or just update on the top
of the existing repository (I don't know how feasible it would be).

Thanks and regards
Samyak Jain
(samyak-jn[m])

[1] https://tracker.debian.org/pkg/gradle-plugin-protobuf
[2] https://github.com/aantono/gradle-plugin-protobuf
[3] https://github.com/google/protobuf-gradle-plugin

[toc] | [next] | [standalone]

#11721

Hi Samyak,

gradle-plugin-protobuf is being used by libspring-java, so if you are
updating gradle-plugin-protobuf you will need to patch libspring-java
to use the new gradle-plugin-protobuf. And also the Debian version is
0.9.2-1, but the new google protobuf-gradle-plugin is 0.8.12 so you
will need to add Epoch to the version.
imho, it will be much easier to patch 'bundletool' to use
ws.antonov.gradle.plugins:gradle-plugin-protobuf.


-- 
Regards
Sudip


On Tue, Jun 23, 2020 at 1:12 PM Samyak Jain <samyak.jn11@gmail.com> wrote:
>
> Hey,
>
> The package gradle-plugin-protobuf exists in Java-Team and hasn't been updated in the past few years [1].
>
> While parsing through dependencies for bundletools. Yesterday, on reviewing through the same I found a problem which is creating the conflict. The problem is that the upstream source package is moved from ws.antonov.gradle.plugins:gradle-plugin-protobuf:0.9.1 [2]
> to com.google.protobuf:protobuf-gradle-plugin:0.8.8 [3].
>
> Therefore it is utter importance to update/switch to the latest upstream available. I'm ready to help with the update until unless someone is doing it, already.
>
> Also, a quick question, what will be the most feasible manner for the update? To archive the existing obsolete package and packaging the new upstream source (as we have a new tag versioning) or just update on the top of the existing repository (I don't know how feasible it would be).
>
> Thanks and regards
> Samyak Jain
> (samyak-jn[m])
>
> [1] https://tracker.debian.org/pkg/gradle-plugin-protobuf
> [2] https://github.com/aantono/gradle-plugin-protobuf
> [3] https://github.com/google/protobuf-gradle-plugin

[toc] | [prev] | [next] | [standalone]

#11722

[Multipart message — attachments visible in raw view] — view raw

Hi Sudip.


gradle-plugin-protobuf is being used by libspring-java, so if you are
> updating gradle-plugin-protobuf you will need to patch libspring-java
> to use the new gradle-plugin-protobuf. And also the Debian version is
> 0.9.2-1, but the new google protobuf-gradle-plugin is 0.8.12 so you
> will need to add Epoch to the version.
> imho, it will be much easier to patch 'bundletool' to use
> ws.antonov.gradle.plugins:gradle-plugin-protobuf.
>

Thanks for the heads-up, I'll see if bundletool can be tweaked accordingly.
Since there is a lot amount of changes with all the changes in the tag.
Isn't it
feasible to package it from scratch if we are doing it? It's just a
thought, as Olek suggested
by packaging it to a new repo won't cause conflict to the old dependent
package. (Thanks for the suggestions).

I'll see for the most feasible way, but in the long run, we need to switch
to the newer
gradle-plugin-protobuf, isn't it?

Thanks and regards
Samyak Jain
(samyak-jn[m])

[toc] | [prev] | [next] | [standalone]

#11724

Hi Samyak,

On Tue, Jun 23, 2020 at 5:56 PM Samyak Jain <samyak.jn11@gmail.com> wrote:
>
> Hi Sudip.
>
>
>> gradle-plugin-protobuf is being used by libspring-java, so if you are
>> updating gradle-plugin-protobuf you will need to patch libspring-java
>> to use the new gradle-plugin-protobuf. And also the Debian version is
>> 0.9.2-1, but the new google protobuf-gradle-plugin is 0.8.12 so you
>> will need to add Epoch to the version.
>> imho, it will be much easier to patch 'bundletool' to use
>> ws.antonov.gradle.plugins:gradle-plugin-protobuf.
>
>
> Thanks for the heads-up, I'll see if bundletool can be tweaked accordingly.
> Since there is a lot amount of changes with all the changes in the tag. Isn't it
> feasible to package it from scratch if we are doing it? It's just a thought, as Olek suggested
> by packaging it to a new repo won't cause conflict to the old dependent package. (Thanks for the suggestions).

Yes, totally agree with Olek about creating a new package.

>
> I'll see for the most feasible way, but in the long run, we need to switch to the newer
> gradle-plugin-protobuf, isn't it?

I just had a look at upstream libspring-java and they are not using
'gradle-plugin-protobuf' with the latest versions.


-- 
Regards
Sudip

[toc] | [prev] | [next] | [standalone]

#11723

[Multipart message — attachments visible in raw view] — view raw

Oops, meant to send to list...

---------- Forwarded message ---------
From: Olek Wojnar <olek@debian.org>
Date: Tue, Jun 23, 2020 at 12:20 PM
Subject: Re: [Help] gradle-plugin-protobuf
To: Samyak Jain <samyak.jn11@gmail.com>


Hi Samyak,

On Tue, Jun 23, 2020 at 8:12 AM Samyak Jain <samyak.jn11@gmail.com> wrote:

> While parsing through dependencies for bundletools. Yesterday, on
> reviewing through the same I found a problem which is creating the
> conflict. The problem is that the upstream source package is moved from
> ws.antonov.gradle.plugins:gradle-plugin-protobuf:0.9.1 [2]
> to com.google.protobuf:protobuf-gradle-plugin:0.8.8 [3].
>

I have opinions on Gradle. Specifically, I feel that the plugin
infrastructure makes it very convenient for normal users but makes it
rather unsuitable for Debian packaging. Or, at least,
extraordinarily painful.

Therefore it is utter importance to update/switch to the latest upstream
> available. I'm ready to help with the update until unless someone is doing
> it, already.
>
> Also, a quick question, what will be the most feasible manner for the
> update? To archive the existing obsolete package and packaging the new
> upstream source (as we have a new tag versioning) or just update on the top
> of the existing repository (I don't know how feasible it would be).
>

If you insist on using Gradle, I think that you should package the Google
plugin separately. The names are already different so it may create some
confusion (the least of the problems with Gradle) but it will not create a
conflict. Putting essentially a different software package into an existing
repository is a recipe for disaster, IMHO. Not to mention the discrepancy
with version numbers. This way existing packages that use the old plugin
can continue to do so and newer packages can use the newer plugin. I see no
need to force an immediate transition.

-Olek

[toc] | [prev] | [next] | [standalone]

#11725

On Tue, 23 Jun 2020, Olek Wojnar wrote:

> If you insist on using Gradle, I think that you should package the Google
> plugin separately.

Agreed.

> The names are already different so it may create some confusion (the

You do know that periods are valid in Debian package names, right?

So com.google.protobuf.protobuf-gradle-plugin (= 0.8.8-1) would work,
perhaps com.google.protobuf-gradle-plugin, and the other could be
renamed to ws.antonov.gradle.plugins.gradle-plugin-protobuf or maybe
ws.antonov.gradle-plugin-protobuf but…

> discrepancy with version numbers. This way existing packages that use
> the old plugin can continue to do so and newer packages can use the
> newer plugin. I see no need to force an immediate transition.

… transitioning away from the other (while it keeps its old name)
is of course better.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web