Sync the framework file and Java source files with Oxygen 20

[AlexJitianu]

Hi,

Certain TEI features introduced in new versions of Oxygen, for example the Image Map support, require some Java custom code that uses certain newly added Java API. Because this addon is marked as being compatible with Oxygen version 15.1, I haven't committed those new extensions into this project . As a result, right now, if you install this addon, you lose features (like the Image Map).

We try to preserve backwards compatibility as much as possible so I would like to commit these new extensions as well. What could happen, for example, are situations like this:

• someone using version 15.1 opens an document inside the author mode
• clicks on the Edit Image Map button
• he gets an error that there is an operation missing

Alex

[martindholmes]

@AlexJitianu Could you outline the options for us? Would we have to update the compatibility of the add-on to Oxygen 20? One reason (among others) that we provide the add-on is to enable people who can't afford to keep their Oxygen license completely up to date to continue to update their TEI codebase.

[AlexJitianu]

How about if we keep the master branch as the one compatible with older versions of Oxygen. I already created a branch named oxygen_integration on which I commit the latest Java code. I will take care to create tags (or branches) every time we make an Oxygen release.

Your release script will create builds for each of these tags and build an http://www.tei-c.org/release/oxygen/updateSite.oxygen that contains multiple entries for each release:

<xt:extension id="tei">
  <xt:location 
href="https://github.com/TEIC/oxygen-tei/releases/download/v8.0.0/oxygen-tei-3.3.0-7.44.0.zip"/>
  <xt:version>8.0.0</xt:version>
  <xt:oxy_version>15.2+</xt:oxy_version>
........
</xt:extension>
<xt:extension id="tei">
  <xt:location 
href="https://github.com/TEIC/oxygen-tei/releases/download/v8.0.0/oxygen-tei-3.3.0-7.44.0-oxygen20.zip"/>
  <xt:version>8.0.0</xt:version>
  <xt:oxy_version>20.0</xt:oxy_version>
........
</xt:extension>
<xt:extension id="tei">
  <xt:location 
href="https://github.com/TEIC/oxygen-tei/releases/download/v8.0.0/oxygen-tei-3.3.0-7.44.0-oxygen20_1.zip"/>
  <xt:version>8.0.0</xt:version>
  <xt:oxy_version>20.1</xt:oxy_version>
........
</xt:extension>

This way, no matter whihc version of Oxygen you are running, when installing the TEI add-on, you wont lose any functionality.

What do you say?

[martindholmes]

That sounds like a great idea. I'll me run it past the Council. To make sure I'm understanding correctly, this would be what we do:

1. The master branch always stays up to date with the latest Oxygen codebase.
2. For each new Oxygen release, a tag is created.
3. We build separate versions using the master and the tag versions, each version aimed at a specific version of Oxygen.
4. Our update file lists all those distinct versions, and any user updating their plugin will be offered the appropriate version.

Did I get that right?

[AlexJitianu]

Yes. Although I was referring to the oxygen_integration branch we can do it with the master branch as well. If I commit the latest Oxygen codebase on master then master becomes sort of a dev. But we could:

1. Tag the master branch as it is now as being compatible with version 15.2+.
2. Push the latest Oxygen codebase and tag it as being compatible with Oxygen version 20.
3. Repeat for every other Oxygen version
4. We should build just tags

We could create branches instead of tags but I'm not sure if it's really required...
oxygen_version_15_2
oxygen_version_20
oxygen_version_20.1

[martindholmes]

Best not to make master into a sort of dev. :-)

Here's another shot, then:

1. Make a tag of the current master as 15.2 (so master can be moved forward later without confusion).

2. Create tags for each significant Oxygen version change which may prevent an older version from installing the plugin, or will impact its behaviour.

3. Build stable versions of the plugin for release based on each of these, and put them in the update file.

4. Build our "bleeding edge" version against your oxygen_integration branch, so that we get some warning of any upcoming changes that may affect the plugin.

How's that?

[AlexJitianu]

Sounds good. Might be better not to put the "bleeding edge" release into the add-on, though. If we do add it, the people running the latest Oxygen version will always be prompted to install that version instead on the stable one.

[martindholmes]

We have a separate update file for the bleeding-edge release; it's only a few Council folks, me and a couple of other developers who use it.

[martindholmes]

One quick question: presumably in order to build these different versions of the plugin, we'll need to be building with different versions of the Oxygen jar file. Is that right?

[AlexJitianu]

Yes, that's true but the good news is that all these versions are available in our Maven repository: https://www.oxygenxml.com/maven/com/oxygenxml/oxygen/

[martindholmes]

@AlexJitianu As @raducoravu suggests, I think the TEI Council needs to coordinate with you so that we can figure out how best to move forward with the TEI plugin given the changes that keep coming with every Oxygen release. Your version of the TEI frameworks and ours have diverged considerably by this point. I'm going to ask TEI Council if one or more of them is willing to join in on this ticket to figure out what we should do to bring our versions of the TEI frameworks more in line with yours, and how we can avoid being taken by surprise every time an Oxygen release breaks functionality for us.

[AlexJitianu]

If I understand it correctly, the cause of these breaks are usually triggered by jar updates, when these jars are mentioned the the *.framework file. We have an internal issue recorded to hide version related tokens from behind wilcards in the *.framework file. When we do this, we can contribute the change here as well.
Also, if you decide it's time to move the compatibility from Oxygen 18.1 (the update was done on #43 ) to a newer version, perhaps 22.1, then I can synchronize the Java extensions and create a pull request.