Code changes required after JDK-8291473
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Mon Aug 8 17:44:31 UTC 2022
After some internal discussion, we are going to do the following:
* create a "panama" branch, which contains the changes needed to run
jextract with the API contained in the Panama repo
* have (as now) a set of versioned branches, for jdk18 and jdk19
* when 20 becomes GA, we will create a new jdk20 branch, copy the
contents of the "panama" branch into it and make it the default branch
* we will _not_ provide binary snapshots for the "panama" branch, as
that's a "bleeding edge" sort of scenario (where you have to build the
panama repo manually to go with it as well)
Cheers
Maurizio
On 05/08/2022 12:31, Maurizio Cimadamore wrote:
> Hi Filip,
> due to various complex reasons, it is currently not possible for us to
> release binary snapshots using GitHub actions. All the binaries we
> publish come from an internal CI pipeline, which builds and test using
> predefined, well-known configurations, so that we can ensure
> repeatable results. While this is not set in stone, and OpenJDK is
> relatively new to GitHub workflows, I think that, for the time being,
> we have to work with what we've got.
>
> That said, nothing prevents us from creating several internal
> pipelines, one per jextract version, and add a new one every 6 months
> or so, perhaps with some policy to "garbage collect" old pipelines
> (e.g. maybe providing binaries up to JDK N-3 would be a good starting
> point?) - although I'd have to check with the infra team and see what
> solution they'd be most comfortable with.
>
> P.S. While it would be possible, in principle, for 3rd parties to
> build snapshots of jextract, I find that solution less ideal. Plugins
> such as yours need a stable link to work with. A 3rd party build might
> be a great place to get started (or where to get more frequent
> jextract binary updates, for example), but doesn't provide (by design)
> that kind of long-term commitment that some of the tools in the
> ecosystem would require, at least IMHO.
>
> Thanks
> Maurizio
>
> On 05/08/2022 11:23, Filip Krakowski wrote:
>> Hi,
>>
>> is it a question of maintainability (diverging branches in case of
>> patches, etc.), which would stand in the way of this, or a question
>> of the infrastructure that would be required? In the latter case, I
>> could try to set something up to accomplish the job of automatically
>> creating releases from each pushed tag matching a version number.
>>
>> Since the project is hosted on GitHub, I could implement a GitHub
>> Action, which would be triggered on each pushed tag. This Action
>> would then compile the code for different platforms (Linux, macOS,
>> Windows - GitHub provides images for each), create a release inside
>> the repository and attach the created binaries to it. The repository
>> already contains a GitHub Action for building and testing jextract,
>> which I could use as a starting point.
>>
>> Best regards,
>> Filip
>>
>> On 04.08.22 21:14, Maurizio Cimadamore wrote:
>>>
>>> On 04/08/2022 20:08, Filip Krakowski wrote:
>>>> Each branch would therefore only produce binaries when it receives
>>>> a new tag. Could this work?
>>>
>>> I'd have to check - my feeling is that, no that would not be possible.
>>>
>>> Another issue is that we'd need to keep updating the main github
>>> branch every few months (not a big issue).
>>>
>>> Maurizio
>>>
>>>
>>
More information about the jextract-dev
mailing list