dependency, which was an
error as it is already available and usable in Debian. After restoring
it and adding two Kotlin JARs to the list of downloads it was possible
to rebuild Gradle with itself and a reduced set of pre-built
dependencies.
I then spent some time updating and reviewing t
d the code as a PR here
<https://github.com/MorMundHS-MA/gradle-maven-bootstrap/pull/2>
If you made that into a custom Gradle task like I did for
MakefileMakerTask you could get rid of the parser and the hardcoding in
SettingsParser, and possibly find ways to minimize the amount of manua
odule]:dependencies --configuration compileClasspath` to
get the module dependencies with each other. I think most poms are
unchanged from the generated code. I've uploaded the code as a PR here
<https://github.com/MorMundHS-MA/gradle-maven-bootstrap/pull/2>
On my side I've starte
Hi Moritz,
Le 2025-03-16 11:10, Moritz a écrit :
I got interested in the problem of bootstrapping a modern versions of
Gradle, mainly due to the old version available in Debian. As far as I
can tell, efforts have been mostly focused on using older versions to
bootstrap an up-to-date version
Hello everyone,
I got interested in the problem of bootstrapping a modern versions of
Gradle, mainly due to the old version available in Debian. As far as I
can tell, efforts have been mostly focused on using older versions to
bootstrap an up-to-date version. I wanted to explore the
Good evening,
Building a functioning gradle using a pre-built Kotlin 2.0.21 is a bit
more work than I expected.
Le 2025-03-07 18:39, Julien Plissonneau Duquène a écrit :
update the Kotlin package to 2.0.21 (renaming it kotlin2.0)
I've started to look around that release and tes
y, so while the bytecode was compatible with Java 8 it used
some API calls that were introduced in later JDKs instead of
reimplementing them as inline code. Using the JDK 11 again solved that
for the purpose of using that compiler for building Gradle.
Did you consider rebuilding the packages with J
Hi Emmanuel,
Le 2025-03-10 18:42, Emmanuel Bourg a écrit :
Did you consider rebuilding the packages with Java 8 since we still
have openjdk-8 in sid? We may even clone the gradle package to make a
Java 8 compatible version if that helps. Same thing with kotlin.
That's not needed fo
s its target for API
compatibility, so while the bytecode was compatible with Java 8 it used
some API calls that were introduced in later JDKs instead of
reimplementing them as inline code. Using the JDK 11 again solved that
for the purpose of using that compiler for building Gradle.
After fix
ixes in Kotlin's git history wasn't too difficult,
which is rather good news for its maintainability as a stable package.
Next I will have to fix that compiler and try again to see if I can
start to get some gradle build script class files (correctly) generated
or if it's ti
Hi Julien,
Le 21/02/2025 à 18:15, Julien Plissonneau Duquène a écrit :
Good evening,
All hopes to get Gradle 8 to work with the FrankenKotlin are not lost yet.
Le 2025-02-14 20:02, Julien Plissonneau Duquène a écrit :
test if that gradle will rebuild itself by next week, and then either
Good evening,
All hopes to get Gradle 8 to work with the FrankenKotlin are not lost
yet.
Le 2025-02-14 20:02, Julien Plissonneau Duquène a écrit :
test if that gradle will rebuild itself by next week, and then either
debug it (probable outcome)
After finishing to fix Gradle's buil
Hi Hans-Christoph,
Le 2025-02-19 07:48, Hans-Christoph Steiner a écrit :
Very exciting! Thanks for your status updates on this. Do you want
more visibility for them?
I think the visibility is just right at the moment, though I'm also
thinking about opening a Mastodon account somewhere (but
-team.pages.debian.net/blog/
Julien Plissonneau Duquène:
Good evening,
As I'm writing this, my current gradle 8 build is down to 2 (new) compilation
errors in kotlin-dsl (from over 60 last week).
Le 2025-02-07 19:40, Julien Plissonneau Duquène a écrit :
I'm already done with a f
Good evening,
As I'm writing this, my current gradle 8 build is down to 2 (new)
compilation errors in kotlin-dsl (from over 60 last week).
Le 2025-02-07 19:40, Julien Plissonneau Duquène a écrit :
I'm already done with a few modules and I'm currently on the most
touchy
es such as Kotlin.
I was hoping to meet some Gradle folks there, but as they were denied
their own stand and their talks due to fierce competition they didn't
show up (or maybe some did, but not publicly). Kotlin had their own
stand and I could talk a bit with them, though I abstained from boas
Good evening,
Some slow progresses were made since Monday towards getting a Gradle
build that doesn't depend on pre-built binaries from the upstream Gradle
and Kotlin projects.
Le 2025-01-27 19:25, Julien Plissonneau Duquène a écrit :
trying to figure out how to configure the whole
Le 2025-01-27 17:08, Hans-Christoph Steiner a écrit :
Great news! Congrats on hitting that major milestone!
Thank you! But I was overoptimistic... I forgot that it was still linked
to the Kotlin 2.0.20 bootstrap JARs and a Gradle plugin from the
previous released version. I realized that
Great news! Congrats on hitting that major milestone!
Julien Plissonneau Duquène:
Good evening,
Some great news for this week, as I got my "stage 0" gradle (the one that is
locally built by a pre-built binary distribution of Gradle from upstream) to
rebuild itself successfully.
Good evening,
Some great news for this week, as I got my "stage 0" gradle (the one
that is locally built by a pre-built binary distribution of Gradle from
upstream) to rebuild itself successfully.
Le 2025-01-17 19:22, Julien Plissonneau Duquène a écrit :
investigate the curr
old and the new versions on a system, and change
Gradle 4.4.1 packaging to make it use the old versions (mostly the same
scheme as the current Maven upgrade).
This is almost completed, I just need to carefully clean and rebase a
few git branches before pushing all that to Salsa. I will then need
missing in libmaven-resolver-1.6-java [1]
which also breaks the builds of a few other packages. After solving that
it was surprisingly easy to get Kotlin 1.3.31 to build with some
additional code backported from 1.3.50 (no additional patching
required), and even more surprising to see the Gradle
Good evening,
Not much progress was made on Gradle this week:
Le 2024-12-13 19:31, sre4e...@free.fr a écrit :
now I'm stuck on the (re)build of Kotlin 1.3.31 that currently FTBFS
I'm still there. I managed to use IDEA CE's debugger instead of jdb
which helps a lot and na
Le 17/12/2024 à 11:54, sre4e...@free.fr a écrit :
android-platform-tools-base has a FTBFS bug unresolved since Aug 2024,
is also severely outdated(2017), and overall same verdict as above.
Kotlin depends on libgradle-android-plugin-java which is built by
android-platform-tools-base, we can't
Hi,
For information:
Yesterday I tried to rebuild (on trixie) the 110 identified source
packages that depend on Gradle. That kept my low-end, second-hand laptop
busy for about 5 hours. Most packages (102, ~93%) were rebuilt without
issues. The 8 packages that failed to build OOTB were:
1
On 14.12.24 11:49, sre4e...@free.fr wrote:
Le 2024-12-14 10:48, Matthias Klose a écrit :
what about having two sets of packages? one set encapsulating the
bootstrap, which always stays in unstable, and one "production" set,
which then migrates to testing? Would that be better to keep the
boo
Le 2024-12-14 10:48, Matthias Klose a écrit :
what about having two sets of packages? one set encapsulating the
bootstrap, which always stays in unstable, and one "production" set,
which then migrates to testing? Would that be better to keep the
bootstrap knowledge up to date?
That's a poss
and I am a bit worried
about that as well. With Gradle, the work necessary to maintain the
bootstrapping in working condition will have to be weighted against the
work necessary to patch and downgrade the build scripts to make them
work with a previous release, which may or may not be that eas
Le 13/12/2024 à 19:31, sre4e...@free.fr a écrit :
That got me into rebuilding the Kotlin package, which I haven't achieved
so far. I started from what's in the `master` branch with the patches of
Vladimir Petko to rebuild with Java 21, repatched to rebuild with Java
11 as the installed Kotlin
with this plan.
Not very far indeed, as was expected: I quickly realized that Gradle now
depends on APIs that were introduced with Kotlin 1.3.50, not much later
than the current Debian version. After downloading the ~4GiB Kotlin git
repo (and running git gc --aggressive to claim back over 2 G
t now,
let me give some details about how I see future maintainer work wrt/
this.
The makefile is automatically generated by a new "makeMakefile" gradle
task that is added by the custom plugin. My goal is to make it work as
generated with no further postprocessing, especially no
about that
as well. With Gradle, the work necessary to maintain the bootstrapping in
working condition will have to be weighted against the work necessary to patch
and downgrade the build scripts to make them work with a previous release, which
may or may not be that easy depending on featu
Le 2024-12-09 14:32, Emmanuel Bourg a écrit :
I don't think we should try too hard to keep the bootstrapping logic in
the package, that'll most certainly be tedious to maintain over time.
Well that's indeed something to think about, and I am a bit worried
about that as we
Le 09/12/2024 à 12:08, sre4e...@free.fr a écrit :
As usual, comments and contributions are very welcome.
Sounds good so far. Regarding the bootstrapping, once the initial
version is uploaded I don't think we should try too hard to keep the
bootstrapping logic in the package, that'll most cer
Good day,
Some news about the ongoing work on Gradle packaging:
Le 2024-12-02 19:43, sre4e...@free.fr a écrit :
The build progressed a bit and now fails on the outdated Groovy
Last week the build progressed some more and now (using --continue)
generates 78 of the 83 (86 minus 3 dropped
Good evening,
Le 2024-11-22 18:25, sre4e...@free.fr a écrit :
Next week I will start working on a detailed action plan and PoC for
the rebootstrap, in between build runs and fixups.
Updating and then fixing the builds of various packages (not all of them
direct dependencies of Gradle) kept
Hi,
Le 2024-11-30 09:40, Markus Koschany a écrit :
I remember that upstream confirmed they only use nightly builds to
build gradle
Actually it's a bit more subtle than that: out of curiosity I extracted
the last 200 versions used to build Gradle [1], and it appears to be a
combinati
Hi,
Am Mittwoch, dem 27.11.2024 um 09:16 +0100 schrieb sre4e...@free.fr:
> [...]
> I would not follow that path today for Gradle unless working on a
> theoretical bootstrap. That would still be a difficult work, maybe even
> more difficult than the current releases, and the result
Le 2024-11-29 12:49, Emmanuel Bourg a écrit :
I'm not a big fan of potentially long lived experimental packages as it
makes updates in sid more complicated. For example let's say the
package foo has the version 1.0 in sid/testing and the version 3.0 in
experimental, the upstream and pristine-
Hi Julien,
On Fri, Nov 29, 2024 at 12:40:36PM +0100, sre4e...@free.fr wrote:
> By the way, any opinion about making that new gradle a "gradle8" package
> that provides "gradle"?
this would imho be good once things around gradle8 stabilize and people
had time to mi
Le 2024-11-29 11:58, Emmanuel Bourg a écrit :
Maybe jumping to recent and stable Gradle/Kotlin releases would be
easier, but does that even exist? Is there a couple a Gradle and Kotlin
releases that can be used to build each other (and themself).
I haven't checked Kotlin yet, but r
dependencies, gradle has a lot of
dependencies but several of them only have very few reverse-dependencies
other than gradle and sometimes kotlin.
I'm not a big fan of potentially long lived experimental packages as it
makes updates in sid more complicated. For example let's say the packag
deduplicate the dependencies later when the transition to
the newer Gradle is complete.
Or maybe we can keep all of them in experimental for a while, and
duplicate only those that prove (or are suspected eventually, after
discussing that) to be problematic? I would rather keep things as
Le 27/11/2024 à 09:16, sre4e...@free.fr a écrit :
Both Gradle and Kotlin are moving targets indeed, and they were moving
even faster around these releases according to their respective
histories, which probably explains why you (and nobody else as a fact)
weren't able to catch up: it
Le 26/11/2024 à 14:09, Markus Koschany a écrit :
I discarded the idea to upgrade Gradle to 6.x or even newer releases because
the main problem with Gradle for Debian is the complex interaction between its
(build)-dependencies. Since we only support one version of a library in
general, you will
Hi Hans-Cristoph,
Le 2024-11-26 13:37, Hans-Christoph Steiner a écrit :
Another thing I can offer is help with funding for doing this work, if
that is interesting to you. Specifically, NLnet's Mobifree fund
(https://nlnet.nl/mobifree/) is likely to fund this kind of work
because Grad
Hi Markus,
Thanks for the link to your repo, I will take a look.
Le 2024-11-26 14:09, Markus Koschany a écrit :
I discarded the idea to upgrade Gradle to 6.x or even newer releases
because
the main problem with Gradle for Debian is the complex interaction
between its
(build)-dependencies
Hi Julien,
First of all, thank you for working on Gradle. I have been working on it in the
past and together with Emmanuel we tried different approaches. Currently I
can't spend more time on it, but I have uploaded my last attempt to
https://salsa.debian.org/java-team/gradle-apo
perhaps
Emmanuel Bourg:
Hi Julien,
Le 04/11/2024 à 14:43, Julien Plissonneau Duquène a écrit :
This is to let you know that I am currently working on overhauling and
upgrading the gradle package to the upcoming 8.11 release. This is indeed
quite challenging and I am not yet to the point where I
;)
Next week I will start working on a detailed action plan and PoC for the
rebootstrap, in between build runs and fixups.
Have a nice week-end,
[1]:
https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11.1-wip/debian/wip/README.md
--
Julien Plissonneau Duquène
et the build to start compiling the project, it hangs in a
configuration stage. Currently investigating why, this is probably
related to some missing dependency.
MRs already opened are:
- that one [3] with configuration changes for repacking the source for
4.4.1 and preparing for imports, and also
Hi,
On 04/11/2024 14:43, Julien Plissonneau Duquène wrote:
maybe next week
Well it turned out that libnative-platform-java gave me a bit more work
than expected, but it now builds and tests with everything we currently
have in Debian (Gradle, Groovy, Spock etc). Still a few issues to solve
Hi Emmanuel,
On 08/11/2024 00:14, Emmanuel Bourg wrote:
Kotlin and Gradle are tightly coupled, and unless you are ready to
rewrite their build systems with something else and replace the Kotlin
code in Gradle, I don't think it's possible to bootstrap them separately.
I have pla
Hi Julien,
Le 04/11/2024 à 14:43, Julien Plissonneau Duquène a écrit :
This is to let you know that I am currently working on overhauling and
upgrading the gradle package to the upcoming 8.11 release. This is
indeed quite challenging and I am not yet to the point where I could
share a repo
Hi Toni,
On 04/11/2024 16:53, Toni Mueller wrote:
However, I would suggest to make a "gradle8" package
that could be installed in parallel with the existing Gradle.
I didn't think about that but that could be appropriate given that major
releases of Gradle tend to break
Hi Julien,
On Mon, Nov 04, 2024 at 02:43:08PM +0100, Julien Plissonneau Duquène wrote:
> This is to let you know that I am currently working on overhauling and
> upgrading the gradle package to the upcoming 8.11 release. This is indeed
I was also looking into this a few days ago, but I
Hi Julien,
Le 2024-11-04 à 08 h 43, Julien Plissonneau Duquène a écrit :
This is to let you know that I am currently working on overhauling and
upgrading the gradle package to the upcoming 8.11 release. This is
indeed quite challenging and I am not yet to the point where I could
share a repo
Hi,
This is to let you know that I am currently working on overhauling and
upgrading the gradle package to the upcoming 8.11 release. This is
indeed quite challenging and I am not yet to the point where I could
share a repo and let others experiment and contribute, but I hope to get
there in
A problem occurred evaluating project ':ADQLLib'.
>> > Could not set unknown property 'distributionBaseName' for object of
>> type org.gradle.api.distribution.internal.DefaultDistribution.
>> However, when looking in the Gradle docs, I find this as a valid
>
Hi Ole,
Le 08/12/2023 à 13:59, Ole Streicher a écrit :
Hi Andrius,
Andrius Merkys writes:
On 2023-12-08 13:03, Ole Streicher wrote:
I am trying to update the adql-java package to the newest upstream
(beta) version. As it is my first project using gradle, I sumbled upon a
number of problems
Hi Andrius,
Andrius Merkys writes:
> On 2023-12-08 13:03, Ole Streicher wrote:
>> I am trying to update the adql-java package to the newest upstream
>> (beta) version. As it is my first project using gradle, I sumbled upon a
>> number of problems: [...]
>
> I guess y
Hi Ole,
On 2023-12-08 13:03, Ole Streicher wrote:
I am trying to update the adql-java package to the newest upstream
(beta) version. As it is my first project using gradle, I sumbled upon a
number of problems:
One is that the plugin org.javacc.javacc is not available. I guess this
is because
Hi,
I am trying to update the adql-java package to the newest upstream
(beta) version. As it is my first project using gradle, I sumbled upon a
number of problems:
One is that the plugin org.javacc.javacc is not available. I guess this
is because it is not packaged yet, right? My solution here
Although Build Scans™ are a proprietary add-on to Gradle, they are very
useful in a FOSS CI environment. They make it very easy to find all the
information you need to troubleshoot a failing build or find ways to
optimize build scripts.
Unfortunately, the options for agreeing to the terms-of
> But we'll switch to Gradle if necessary in the future.
Typo: I meant Maven.
On 9/27/23 1:01 PM, Sean Gilligan wrote:
Hi Emmanuel,
FrankenGradle! That's a great name!
I know it's unlikely they are going to do anything, but I thought
there should at least be an up-to-dat
Hi Emmanuel,
FrankenGradle! That's a great name!
I know it's unlikely they are going to do anything, but I thought there
should at least be an up-to-date GitHub Issue for Gradle to look at and
for a discussion to hopefully occur.
bitcoinj has franken-build-scripts that use a grow
Hi Sean,
Thank you for your support, I'm glad someone appreciates our
FrankenGradle ;)
Gradle is difficult to upgrade in Debian for a variety of reasons. For
one thing it's a huge monolith and thus it's a bit all or nothing, if
one part is missing your are stuck. Maven i
Hi Everyone,
I appreciate the efforts of the Debian Java team and know that your job
is not easy.
I work on bitcoinj (Java) and we are (for better or worse) using Gradle
for our builds. We are stuck supporting Gradle 4.4.x, when the latest
version of Gradle 8.3 (or 8.4) is required to
12214
If gradle depends on kotlin, it’s not eligible for stable anyway
because kotlin currently depends on two unsupported JDKs that are
available in unstable for bootstrapping and (old…‑)stable support
but nothing else.
I agree, help with Kotlin would be really appreciated. At some point it start
g
>> > promising for bookworm.
>> >
>> > * kotlin FTBFS because of changes to support openjdk 17 #1012214
>>
>> If gradle depends on kotlin, it’s not eligible for stable anyway
>> because kotlin currently depends on two unsupported JDKs that are
>> available in
nges to support openjdk 17 #1012214
>
> If gradle depends on kotlin, it’s not eligible for stable anyway
> because kotlin currently depends on two unsupported JDKs that are
> available in unstable for bootstrapping and (old…‑)stable support
> but nothing else.
I agree, help with Kotlin wou
Hi Phil,
On Sat, Aug 20, 2022 at 05:10:10PM +0100, Phil Morrell wrote:
> Feel free to chat with me in #debian-java on irc/matrix and if anyone
> has permissions to the Salsa java-team, please could you add me there.
Done.
Cheers,
tony
signature.asc
Description: PGP signature
On Sat, 20 Aug 2022, Phil Morrell wrote:
> Hi all, documenting my observations as of today because it's not looking
> promising for bookworm.
>
> * kotlin FTBFS because of changes to support openjdk 17 #1012214
If gradle depends on kotlin, it’s not eligible for stable anyw
Hi all, documenting my observations as of today because it's not looking
promising for bookworm.
* kotlin FTBFS because of changes to support openjdk 17 #1012214
* gradle FTBFS since an upload of libjansi-java 2.4.0 #1013545
* gradle v6 has been (loosely) imported to the java-team repo
want to try to patch out as much as possible with
this package. Gradle builds include lots of things that will never be
used by the Debian packaging, like plugins for pushing files to maven
repos and generating test coverage reports. There are many java-team
packages that do this, here are some
Hey Sunday,
I think you still want to try to patch out as much as possible with this
package. Gradle builds include lots of things that will never be used by the
Debian packaging, like plugins for pushing files to maven repos and generating
test coverage reports. There are many java-team
with Debian Android-tools-team to
package and update Android sdk tools in Debian.
Currently I am attempting to package bundletool (
https://github.com/google/bundletool ), but I am stuck because it
depends on a much more recent version of gradle-plugin-protobuf. I
attempted to update gradle-plugin
dletool (
> https://github.com/google/bundletool ), but I am stuck because it
> depends on a much more recent version of gradle-plugin-protobuf. I
> attempted to update gradle-plugin-protobuf but couldn't. Please your
> help will be very appreciated.
>
> Find the details
gradle-plugin-protobuf. I
attempted to update gradle-plugin-protobuf but couldn't. Please your
help will be very appreciated.
Find the details of my attempt and findings here:
https://salsa.debian.org/android-tools-team/admin/-/issues/51
Regards,
Sonnie
OpenPGP_0x64C708814523D37
Happy to report that kotlin just made it into unstable.
https://tracker.debian.org/pkg/kotlin >
--
Happy hacking
Petter Reinholdtsen
Hello everyone,
We'd like to announce a Request for Bids[0] for a funded project that
directly helps Debian and the broader FOSS community. We've published
the RfB on the fediverse[1]. Everything you need to know is listed in
the RfB document itself which is in Salsa. If you need more informat
Hi,
Does this suffice to proceed?
On Fri, 17 Sept 2021 at 18:45, Philippe De Neve
wrote:
> Hi,
>
> Got the hint :-). I was not able to compile Gradle 6.4.1 due to a missing
> dependency, but it was possible for the latest release 7.2.0. I removed
> the gradle-enterprise-gradle-
Hi,
Got the hint :-). I was not able to compile Gradle 6.4.1 due to a missing
dependency, but it was possible for the latest release 7.2.0. I removed
the gradle-enterprise-gradle-plugin and I've put the adapted code on my
gitlab <https://gitlab.com/philippedn/gradle>. The changes
On Tue, Sep 14, 2021 at 11:59:55PM +0200, Philippe De Neve wrote:
> I was wondering why the Gradle version in buster/bullseye/bookworm/sid is
> 4.4.1. Latest release is 7.2.
Gradle 4.4.1 is the latest version before kotlin was added as a
build-dependency, which has been a known problem sinc
Hi,
On 2021-09-15 00:59, Philippe De Neve wrote:
> I was wondering why the Gradle version in buster/bullseye/bookworm/sid
> is 4.4.1. Latest release is 7.2.
Please see these bug reports for reference:
https://bugs.debian.org/926714
https://bugs.debian.org/933264
Best,
Andrius
Hi,
I was wondering why the Gradle version in buster/bullseye/bookworm/sid is
4.4.1. Latest release is 7.2.
Thanks,
Philippe De Neve
Le 12/03/2021 à 21:59, Raman Sarda a écrit :
> Is there a way we can go about updating gradle using some another way? I
> have worked on major part of the update last summer but seems we can't
> go any further without gradle enterprise plugin.
Are you sure this plugin i
Hii Markus!
I haven't followed all the discussions about the progress of introducing Kotlin
to Debian. This appears to be the major obstacle to maintain future Gradle
releases anyway. Where do we stand here?
Me and Samyak Jain had started on Gradle and Kotlin simultaneously last
year
On Fri, 12 Mar 2021, Markus Koschany wrote:
> If new releases of Gradle require proprietary plugins to function then we have
I somehow doubt that. I’d ask upstream how to best build Gradle without it
before resorting to drastic measures.
bye,
//mirabilos
--
Infrastrukturexperte • tar
Hello,
Am Samstag, den 13.03.2021, 02:29 +0530 schrieb Raman Sarda:
> Dear all,
> I have a few queries.
> Is there a way we can go about updating gradle using some another way? I have
> worked on major part of the update last summer but seems we can't go any
> further witho
Dear all,
I have a few queries.
Is there a way we can go about updating gradle using some another way? I
have worked on major part of the update last summer but seems we can't
go any further without gradle enterprise plugin.
I am trying to update gradle to 6.4.1 and it doesn't bu
Hey everyone!
I am trying to update gradle to version 6.4.1 as a part of my project for GSoC
2020. We currently have 4.4.1 in archives. I have fixed major issues and
converted all the patches to Kotlin as gradle shifted from Groovy to Koltin
after 4.4.1. Some of the patches have been removed
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, r
Hi Samyak,
On Tue, Jun 23, 2020 at 5:56 PM Samyak Jain 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-protobu
Oops, meant to send to list...
-- Forwarded message -
From: Olek Wojnar
Date: Tue, Jun 23, 2020 at 12:20 PM
Subject: Re: [Help] gradle-plugin-protobuf
To: Samyak Jain
Hi Samyak,
On Tue, Jun 23, 2020 at 8:12 AM Samyak Jain wrote:
> While parsing through dependencies
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.
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
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 s
Hi Vincent,
On Sat, Jun 20, 2020 at 5:34 AM Vincent Prat wrote:
> I agree that Gradle can be a pain to package software for Debian.
>
According to the documentation of the antonov protobuf gradle plugin [1],
> the name of the plugin is just "protobuf".
>
Ahhh... RTFM.
Hi,
I agree that Gradle can be a pain to package software for Debian.
According to the documentation of the antonov protobuf gradle plugin
[1], the name of the plugin is just "protobuf".
Maybe you could try this.
Best regards,
Vincent
[1] https://github.com/aantono/gradle-plugin-proto
1 - 100 of 295 matches
Mail list logo
