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