Development version of oxygen-tei plugin available
Hi all, I now have a development build of the oxygen-tei add-on working. You can subscribe from here: <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen> If you're brave enough to try it, uninstall the regular version of the add-on before installing this one. I can also confirm that James was right: you can provide access to multiple versions of the plugin, allowing people to roll back to a previous version if something breaks, by providing multiple <xt:extension> elements in the updateSite.oxygen file. This seems to be working well with the URL above: if, when you're subscribing to the plugin (Help / Install New Add-Ons) you uncheck the "Show only the latest versions of the add-ons", you'll see there are three versions available. I have it set up so we'll keep the last ten versions available. I've subscribed myself, so I should be able to see if anything goes wrong. If you do test it, be aware that if you have transformation scenarios (for instance) that depend on the absolute location of the TEI extension framework, those paths will no longer work; Oxygen stores the add-on data in a path which includes a modified version of the URL of the updateSite.oxygen file. It's easy to change back to the standard TEI release, though. A new version of the plugin will be built and "released" every time the Stylesheets or P5 are rebuilt; the former triggers the latter, so the overall process takes quite a while, but the build of the oxygen-tei plugin itself takes only a few seconds. I'm copying Sebastian on this because my Jenkins is still reporting build failures and successes to him, as the Oxford one does to me, and I want to confirm that this should continue (or if it shouldn't, then what should happen instead). I'd also like to get this setup working on the Oxford Jenkins so we have some redundancy. The next step is to create some tests we can run in Oxygen to check core functionality of the add-on. I envisage this as an Oxygen project with a bunch of sample files that are transformed or otherwise manipulated and the results checked. These files would presumably live in the oxygen-tei repo. Cheers, Martin
Hi Martin and all, in my Oxy (Ubuntu Linux version) using the experimental Jenkins build of the framework I find a misleading "pom" (Mavent project file coming I guess from Jenky) type of TEI file in the open new file dialog box. Fabio 2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Hi all,
I now have a development build of the oxygen-tei add-on working. You can subscribe from here:
If you're brave enough to try it, uninstall the regular version of the add-on before installing this one.
I can also confirm that James was right: you can provide access to multiple versions of the plugin, allowing people to roll back to a previous version if something breaks, by providing multiple <xt:extension> elements in the updateSite.oxygen file. This seems to be working well with the URL above: if, when you're subscribing to the plugin (Help / Install New Add-Ons) you uncheck the "Show only the latest versions of the add-ons", you'll see there are three versions available. I have it set up so we'll keep the last ten versions available.
I've subscribed myself, so I should be able to see if anything goes wrong. If you do test it, be aware that if you have transformation scenarios (for instance) that depend on the absolute location of the TEI extension framework, those paths will no longer work; Oxygen stores the add-on data in a path which includes a modified version of the URL of the updateSite.oxygen file. It's easy to change back to the standard TEI release, though.
A new version of the plugin will be built and "released" every time the Stylesheets or P5 are rebuilt; the former triggers the latter, so the overall process takes quite a while, but the build of the oxygen-tei plugin itself takes only a few seconds.
I'm copying Sebastian on this because my Jenkins is still reporting build failures and successes to him, as the Oxford one does to me, and I want to confirm that this should continue (or if it shouldn't, then what should happen instead). I'd also like to get this setup working on the Oxford Jenkins so we have some redundancy.
The next step is to create some tests we can run in Oxygen to check core functionality of the add-on. I envisage this as an Oxygen project with a bunch of sample files that are transformed or otherwise manipulated and the results checked. These files would presumably live in the oxygen-tei repo.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
HI Fabio, Thanks for reporting this -- I have no idea where it's coming from, but I'll work on it. Can someone still subscribed to the stable release confirm that they don't see it? (File / New / TEI P5). Cheers, Martin On 15-02-03 11:12 AM, Fabio Ciotti wrote:
Hi Martin and all,
in my Oxy (Ubuntu Linux version) using the experimental Jenkins build of the framework I find a misleading "pom" (Mavent project file coming I guess from Jenky) type of TEI file in the open new file dialog box.
Fabio
2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Hi all,
I now have a development build of the oxygen-tei add-on working. You can subscribe from here:
If you're brave enough to try it, uninstall the regular version of the add-on before installing this one.
I can also confirm that James was right: you can provide access to multiple versions of the plugin, allowing people to roll back to a previous version if something breaks, by providing multiple <xt:extension> elements in the updateSite.oxygen file. This seems to be working well with the URL above: if, when you're subscribing to the plugin (Help / Install New Add-Ons) you uncheck the "Show only the latest versions of the add-ons", you'll see there are three versions available. I have it set up so we'll keep the last ten versions available.
I've subscribed myself, so I should be able to see if anything goes wrong. If you do test it, be aware that if you have transformation scenarios (for instance) that depend on the absolute location of the TEI extension framework, those paths will no longer work; Oxygen stores the add-on data in a path which includes a modified version of the URL of the updateSite.oxygen file. It's easy to change back to the standard TEI release, though.
A new version of the plugin will be built and "released" every time the Stylesheets or P5 are rebuilt; the former triggers the latter, so the overall process takes quite a while, but the build of the oxygen-tei plugin itself takes only a few seconds.
I'm copying Sebastian on this because my Jenkins is still reporting build failures and successes to him, as the Oxford one does to me, and I want to confirm that this should continue (or if it shouldn't, then what should happen instead). I'd also like to get this setup working on the Oxford Jenkins so we have some redundancy.
The next step is to create some tests we can run in Oxygen to check core functionality of the add-on. I envisage this as an Oxygen project with a bunch of sample files that are transformed or otherwise manipulated and the results checked. These files would presumably live in the oxygen-tei repo.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I can see that pom.xml file appearing in the build, but I'm not sure where it's coming from. It seems to be something to do with the P5 build that gets pulled in. Sebastian, do you recognize it? pom.xml ends up in templates/TEI P5. Cheers, Martin On 15-02-03 11:12 AM, Fabio Ciotti wrote:
Hi Martin and all,
in my Oxy (Ubuntu Linux version) using the experimental Jenkins build of the framework I find a misleading "pom" (Mavent project file coming I guess from Jenky) type of TEI file in the open new file dialog box.
Fabio
2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Hi all,
I now have a development build of the oxygen-tei add-on working. You can subscribe from here:
If you're brave enough to try it, uninstall the regular version of the add-on before installing this one.
I can also confirm that James was right: you can provide access to multiple versions of the plugin, allowing people to roll back to a previous version if something breaks, by providing multiple <xt:extension> elements in the updateSite.oxygen file. This seems to be working well with the URL above: if, when you're subscribing to the plugin (Help / Install New Add-Ons) you uncheck the "Show only the latest versions of the add-ons", you'll see there are three versions available. I have it set up so we'll keep the last ten versions available.
I've subscribed myself, so I should be able to see if anything goes wrong. If you do test it, be aware that if you have transformation scenarios (for instance) that depend on the absolute location of the TEI extension framework, those paths will no longer work; Oxygen stores the add-on data in a path which includes a modified version of the URL of the updateSite.oxygen file. It's easy to change back to the standard TEI release, though.
A new version of the plugin will be built and "released" every time the Stylesheets or P5 are rebuilt; the former triggers the latter, so the overall process takes quite a while, but the build of the oxygen-tei plugin itself takes only a few seconds.
I'm copying Sebastian on this because my Jenkins is still reporting build failures and successes to him, as the Oxford one does to me, and I want to confirm that this should continue (or if it shouldn't, then what should happen instead). I'd also like to get this setup working on the Oxford Jenkins so we have some redundancy.
The next step is to create some tests we can run in Oxygen to check core functionality of the add-on. I envisage this as an Oxygen project with a bunch of sample files that are transformed or otherwise manipulated and the results checked. These files would presumably live in the oxygen-tei repo.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Fixed it! Fabio, try updating your plugin, and you shouldn't see that "pom.xml" any more. Cheers, Martin On 15-02-03 01:19 PM, Martin Holmes wrote:
I can see that pom.xml file appearing in the build, but I'm not sure where it's coming from. It seems to be something to do with the P5 build that gets pulled in. Sebastian, do you recognize it? pom.xml ends up in templates/TEI P5.
Cheers, Martin
On 15-02-03 11:12 AM, Fabio Ciotti wrote:
Hi Martin and all,
in my Oxy (Ubuntu Linux version) using the experimental Jenkins build of the framework I find a misleading "pom" (Mavent project file coming I guess from Jenky) type of TEI file in the open new file dialog box.
Fabio
2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Hi all,
I now have a development build of the oxygen-tei add-on working. You can subscribe from here:
If you're brave enough to try it, uninstall the regular version of the add-on before installing this one.
I can also confirm that James was right: you can provide access to multiple versions of the plugin, allowing people to roll back to a previous version if something breaks, by providing multiple <xt:extension> elements in the updateSite.oxygen file. This seems to be working well with the URL above: if, when you're subscribing to the plugin (Help / Install New Add-Ons) you uncheck the "Show only the latest versions of the add-ons", you'll see there are three versions available. I have it set up so we'll keep the last ten versions available.
I've subscribed myself, so I should be able to see if anything goes wrong. If you do test it, be aware that if you have transformation scenarios (for instance) that depend on the absolute location of the TEI extension framework, those paths will no longer work; Oxygen stores the add-on data in a path which includes a modified version of the URL of the updateSite.oxygen file. It's easy to change back to the standard TEI release, though.
A new version of the plugin will be built and "released" every time the Stylesheets or P5 are rebuilt; the former triggers the latter, so the overall process takes quite a while, but the build of the oxygen-tei plugin itself takes only a few seconds.
I'm copying Sebastian on this because my Jenkins is still reporting build failures and successes to him, as the Oxford one does to me, and I want to confirm that this should continue (or if it shouldn't, then what should happen instead). I'd also like to get this setup working on the Oxford Jenkins so we have some redundancy.
The next step is to create some tests we can run in Oxygen to check core functionality of the add-on. I envisage this as an Oxygen project with a bunch of sample files that are transformed or otherwise manipulated and the results checked. These files would presumably live in the oxygen-tei repo.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Ok, pom.xml disappeared. I've tried things here and there and everything seems to work... f 2015-02-04 0:50 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Fixed it! Fabio, try updating your plugin, and you shouldn't see that "pom.xml" any more.
Cheers, Martin
On 15-02-03 01:19 PM, Martin Holmes wrote:
I can see that pom.xml file appearing in the build, but I'm not sure where it's coming from. It seems to be something to do with the P5 build that gets pulled in. Sebastian, do you recognize it? pom.xml ends up in templates/TEI P5.
Cheers, Martin
On 15-02-03 11:12 AM, Fabio Ciotti wrote:
Hi Martin and all,
in my Oxy (Ubuntu Linux version) using the experimental Jenkins build of the framework I find a misleading "pom" (Mavent project file coming I guess from Jenky) type of TEI file in the open new file dialog box.
Fabio
2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Hi all,
I now have a development build of the oxygen-tei add-on working. You can subscribe from here:
If you're brave enough to try it, uninstall the regular version of the add-on before installing this one.
I can also confirm that James was right: you can provide access to multiple versions of the plugin, allowing people to roll back to a previous version if something breaks, by providing multiple <xt:extension> elements in the updateSite.oxygen file. This seems to be working well with the URL above: if, when you're subscribing to the plugin (Help / Install New Add-Ons) you uncheck the "Show only the latest versions of the add-ons", you'll see there are three versions available. I have it set up so we'll keep the last ten versions available.
I've subscribed myself, so I should be able to see if anything goes wrong. If you do test it, be aware that if you have transformation scenarios (for instance) that depend on the absolute location of the TEI extension framework, those paths will no longer work; Oxygen stores the add-on data in a path which includes a modified version of the URL of the updateSite.oxygen file. It's easy to change back to the standard TEI release, though.
A new version of the plugin will be built and "released" every time the Stylesheets or P5 are rebuilt; the former triggers the latter, so the overall process takes quite a while, but the build of the oxygen-tei plugin itself takes only a few seconds.
I'm copying Sebastian on this because my Jenkins is still reporting build failures and successes to him, as the Oxford one does to me, and I want to confirm that this should continue (or if it shouldn't, then what should happen instead). I'd also like to get this setup working on the Oxford Jenkins so we have some redundancy.
The next step is to create some tests we can run in Oxygen to check core functionality of the add-on. I envisage this as an Oxygen project with a bunch of sample files that are transformed or otherwise manipulated and the results checked. These files would presumably live in the oxygen-tei repo.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Thanks Fabio! Anyone else willing to subscribe? If a few of us are using it, we'll notice when anything goes wrong. Advantages: get all the latest and greatest features of the Stylesheets and P5. Disadvantages: might break sometimes, but you can always roll back to a previous version. <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen> Cheers, Martin On 15-02-04 07:09 AM, Fabio Ciotti wrote:
Ok, pom.xml disappeared. I've tried things here and there and everything seems to work...
f
2015-02-04 0:50 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Fixed it! Fabio, try updating your plugin, and you shouldn't see that "pom.xml" any more.
Cheers, Martin
On 15-02-03 01:19 PM, Martin Holmes wrote:
I can see that pom.xml file appearing in the build, but I'm not sure where it's coming from. It seems to be something to do with the P5 build that gets pulled in. Sebastian, do you recognize it? pom.xml ends up in templates/TEI P5.
Cheers, Martin
On 15-02-03 11:12 AM, Fabio Ciotti wrote:
Hi Martin and all,
in my Oxy (Ubuntu Linux version) using the experimental Jenkins build of the framework I find a misleading "pom" (Mavent project file coming I guess from Jenky) type of TEI file in the open new file dialog box.
Fabio
2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Hi all,
I now have a development build of the oxygen-tei add-on working. You can subscribe from here:
If you're brave enough to try it, uninstall the regular version of the add-on before installing this one.
I can also confirm that James was right: you can provide access to multiple versions of the plugin, allowing people to roll back to a previous version if something breaks, by providing multiple <xt:extension> elements in the updateSite.oxygen file. This seems to be working well with the URL above: if, when you're subscribing to the plugin (Help / Install New Add-Ons) you uncheck the "Show only the latest versions of the add-ons", you'll see there are three versions available. I have it set up so we'll keep the last ten versions available.
I've subscribed myself, so I should be able to see if anything goes wrong. If you do test it, be aware that if you have transformation scenarios (for instance) that depend on the absolute location of the TEI extension framework, those paths will no longer work; Oxygen stores the add-on data in a path which includes a modified version of the URL of the updateSite.oxygen file. It's easy to change back to the standard TEI release, though.
A new version of the plugin will be built and "released" every time the Stylesheets or P5 are rebuilt; the former triggers the latter, so the overall process takes quite a while, but the build of the oxygen-tei plugin itself takes only a few seconds.
I'm copying Sebastian on this because my Jenkins is still reporting build failures and successes to him, as the Oxford one does to me, and I want to confirm that this should continue (or if it shouldn't, then what should happen instead). I'd also like to get this setup working on the Oxford Jenkins so we have some redundancy.
The next step is to create some tests we can run in Oxygen to check core functionality of the add-on. I envisage this as an Oxygen project with a bunch of sample files that are transformed or otherwise manipulated and the results checked. These files would presumably live in the oxygen-tei repo.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Hi Martin, Is there a Oxygen version requirement to try this out? I'm currently running 13... but will get an upgrade to 16 soon. Also, related: is it worth having my department getting me a license for 16 or is 17 coming out soon? Raff On Wed, Feb 4, 2015 at 11:16 AM, Martin Holmes <mholmes@uvic.ca> wrote:
Thanks Fabio! Anyone else willing to subscribe? If a few of us are using it, we'll notice when anything goes wrong. Advantages: get all the latest and greatest features of the Stylesheets and P5. Disadvantages: might break sometimes, but you can always roll back to a previous version.
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen>
Cheers, Martin
On 15-02-04 07:09 AM, Fabio Ciotti wrote:
Ok, pom.xml disappeared. I've tried things here and there and everything seems to work...
f
2015-02-04 0:50 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Fixed it! Fabio, try updating your plugin, and you shouldn't see that "pom.xml" any more.
Cheers, Martin
On 15-02-03 01:19 PM, Martin Holmes wrote:
I can see that pom.xml file appearing in the build, but I'm not sure where it's coming from. It seems to be something to do with the P5 build that gets pulled in. Sebastian, do you recognize it? pom.xml ends up in templates/TEI P5.
Cheers, Martin
On 15-02-03 11:12 AM, Fabio Ciotti wrote:
Hi Martin and all,
in my Oxy (Ubuntu Linux version) using the experimental Jenkins build of the framework I find a misleading "pom" (Mavent project file coming I guess from Jenky) type of TEI file in the open new file dialog box.
Fabio
2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Hi all,
I now have a development build of the oxygen-tei add-on working. You can subscribe from here:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen>
If you're brave enough to try it, uninstall the regular version of the add-on before installing this one.
I can also confirm that James was right: you can provide access to multiple versions of the plugin, allowing people to roll back to a previous version if something breaks, by providing multiple <xt:extension> elements in the updateSite.oxygen file. This seems to be working well with the URL above: if, when you're subscribing to the plugin (Help / Install New Add-Ons) you uncheck the "Show only the latest versions of the add-ons", you'll see there are three versions available. I have it set up so we'll keep the last ten versions available.
I've subscribed myself, so I should be able to see if anything goes wrong. If you do test it, be aware that if you have transformation scenarios (for instance) that depend on the absolute location of the TEI extension framework, those paths will no longer work; Oxygen stores the add-on data in a path which includes a modified version of the URL of the updateSite.oxygen file. It's easy to change back to the standard TEI release, though.
A new version of the plugin will be built and "released" every time the Stylesheets or P5 are rebuilt; the former triggers the latter, so the overall process takes quite a while, but the build of the oxygen-tei plugin itself takes only a few seconds.
I'm copying Sebastian on this because my Jenkins is still reporting build failures and successes to him, as the Oxford one does to me, and I want to confirm that this should continue (or if it shouldn't, then what should happen instead). I'd also like to get this setup working on the Oxford Jenkins so we have some redundancy.
The next step is to create some tests we can run in Oxygen to check core functionality of the add-on. I envisage this as an Oxygen project with a bunch of sample files that are transformed or otherwise manipulated and the results checked. These files would presumably live in the oxygen-tei repo.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Ok - just come across James's guide: http://blogs.it.ox.ac.uk/jamesc/2014/04/02/auto-update-your-tei-framework-in... Add on frameworks are available from version 14+, so I'll get that Oxygen 16 license :) On Wed, Feb 4, 2015 at 11:18 AM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:
Hi Martin,
Is there a Oxygen version requirement to try this out? I'm currently running 13... but will get an upgrade to 16 soon. Also, related: is it worth having my department getting me a license for 16 or is 17 coming out soon?
Raff
On Wed, Feb 4, 2015 at 11:16 AM, Martin Holmes <mholmes@uvic.ca> wrote:
Thanks Fabio! Anyone else willing to subscribe? If a few of us are using it, we'll notice when anything goes wrong. Advantages: get all the latest and greatest features of the Stylesheets and P5. Disadvantages: might break sometimes, but you can always roll back to a previous version.
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen>
Cheers, Martin
On 15-02-04 07:09 AM, Fabio Ciotti wrote:
Ok, pom.xml disappeared. I've tried things here and there and everything seems to work...
f
2015-02-04 0:50 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Fixed it! Fabio, try updating your plugin, and you shouldn't see that "pom.xml" any more.
Cheers, Martin
On 15-02-03 01:19 PM, Martin Holmes wrote:
I can see that pom.xml file appearing in the build, but I'm not sure where it's coming from. It seems to be something to do with the P5 build that gets pulled in. Sebastian, do you recognize it? pom.xml ends up in templates/TEI P5.
Cheers, Martin
On 15-02-03 11:12 AM, Fabio Ciotti wrote:
Hi Martin and all,
in my Oxy (Ubuntu Linux version) using the experimental Jenkins build of the framework I find a misleading "pom" (Mavent project file coming I guess from Jenky) type of TEI file in the open new file dialog box.
Fabio
2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
> > Hi all, > > I now have a development build of the oxygen-tei add-on working. You > can > subscribe from here: > > > <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ > lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen> > > > If you're brave enough to try it, uninstall the regular version of > the > add-on before installing this one. > > I can also confirm that James was right: you can provide access to > multiple > versions of the plugin, allowing people to roll back to a previous > version > if something breaks, by providing multiple <xt:extension> elements in > the > updateSite.oxygen file. This seems to be working well with the URL > above: > if, when you're subscribing to the plugin (Help / Install New > Add-Ons) you > uncheck the "Show only the latest versions of the add-ons", you'll > see there > are three versions available. I have it set up so we'll keep the last > ten > versions available. > > I've subscribed myself, so I should be able to see if anything goes > wrong. > If you do test it, be aware that if you have transformation scenarios > (for > instance) that depend on the absolute location of the TEI extension > framework, those paths will no longer work; Oxygen stores the add-on > data in > a path which includes a modified version of the URL of the > updateSite.oxygen > file. It's easy to change back to the standard TEI release, though. > > A new version of the plugin will be built and "released" every time > the > Stylesheets or P5 are rebuilt; the former triggers the latter, so the > overall process takes quite a while, but the build of the oxygen-tei > plugin > itself takes only a few seconds. > > I'm copying Sebastian on this because my Jenkins is still reporting > build > failures and successes to him, as the Oxford one does to me, and I > want to > confirm that this should continue (or if it shouldn't, then what > should > happen instead). I'd also like to get this setup working on the > Oxford > Jenkins so we have some redundancy. > > The next step is to create some tests we can run in Oxygen to check > core > functionality of the add-on. I envisage this as an Oxygen project > with a > bunch of sample files that are transformed or otherwise manipulated > and the > results checked. These files would presumably live in the oxygen-tei > repo. > > Cheers, > Martin > -- > tei-council mailing list > tei-council@lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived >
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Actually my manage add-ons screen lists Oxygen Version 15.2+ so there might be something in the current framework that is requiring even later oxygen. Glad my guide was helpful... do point people you know using oxygen (post 14+) to it as it is a really good way to get the tei framework updated. -James On 04/02/15 16:30, Raffaele Viglianti wrote:
Ok - just come across James's guide: http://blogs.it.ox.ac.uk/jamesc/2014/04/02/auto-update-your-tei-framework-in...
Add on frameworks are available from version 14+, so I'll get that Oxygen 16 license :)
On Wed, Feb 4, 2015 at 11:18 AM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:
Hi Martin,
Is there a Oxygen version requirement to try this out? I'm currently running 13... but will get an upgrade to 16 soon. Also, related: is it worth having my department getting me a license for 16 or is 17 coming out soon?
Raff
On Wed, Feb 4, 2015 at 11:16 AM, Martin Holmes <mholmes@uvic.ca> wrote:
Thanks Fabio! Anyone else willing to subscribe? If a few of us are using it, we'll notice when anything goes wrong. Advantages: get all the latest and greatest features of the Stylesheets and P5. Disadvantages: might break sometimes, but you can always roll back to a previous version.
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen>
Cheers, Martin
On 15-02-04 07:09 AM, Fabio Ciotti wrote:
Ok, pom.xml disappeared. I've tried things here and there and everything seems to work...
f
2015-02-04 0:50 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Fixed it! Fabio, try updating your plugin, and you shouldn't see that "pom.xml" any more.
Cheers, Martin
On 15-02-03 01:19 PM, Martin Holmes wrote:
I can see that pom.xml file appearing in the build, but I'm not sure where it's coming from. It seems to be something to do with the P5 build that gets pulled in. Sebastian, do you recognize it? pom.xml ends up in templates/TEI P5.
Cheers, Martin
On 15-02-03 11:12 AM, Fabio Ciotti wrote:
> Hi Martin and all, > > in my Oxy (Ubuntu Linux version) using the experimental Jenkins build > of the framework I find a misleading "pom" (Mavent project file > coming I guess from Jenky) type of TEI file in the open new file > dialog box. > > Fabio > > 2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>: > >> Hi all, >> >> I now have a development build of the oxygen-tei add-on working. You >> can >> subscribe from here: >> >> >> <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ >> lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen> >> >> >> If you're brave enough to try it, uninstall the regular version of >> the >> add-on before installing this one. >> >> I can also confirm that James was right: you can provide access to >> multiple >> versions of the plugin, allowing people to roll back to a previous >> version >> if something breaks, by providing multiple <xt:extension> elements in >> the >> updateSite.oxygen file. This seems to be working well with the URL >> above: >> if, when you're subscribing to the plugin (Help / Install New >> Add-Ons) you >> uncheck the "Show only the latest versions of the add-ons", you'll >> see there >> are three versions available. I have it set up so we'll keep the last >> ten >> versions available. >> >> I've subscribed myself, so I should be able to see if anything goes >> wrong. >> If you do test it, be aware that if you have transformation scenarios >> (for >> instance) that depend on the absolute location of the TEI extension >> framework, those paths will no longer work; Oxygen stores the add-on >> data in >> a path which includes a modified version of the URL of the >> updateSite.oxygen >> file. It's easy to change back to the standard TEI release, though. >> >> A new version of the plugin will be built and "released" every time >> the >> Stylesheets or P5 are rebuilt; the former triggers the latter, so the >> overall process takes quite a while, but the build of the oxygen-tei >> plugin >> itself takes only a few seconds. >> >> I'm copying Sebastian on this because my Jenkins is still reporting >> build >> failures and successes to him, as the Oxford one does to me, and I >> want to >> confirm that this should continue (or if it shouldn't, then what >> should >> happen instead). I'd also like to get this setup working on the >> Oxford >> Jenkins so we have some redundancy. >> >> The next step is to create some tests we can run in Oxygen to check >> core >> functionality of the add-on. I envisage this as an Oxygen project >> with a >> bunch of sample files that are transformed or otherwise manipulated >> and the >> results checked. These files would presumably live in the oxygen-tei >> repo. >> >> Cheers, >> Martin >> -- >> tei-council mailing list >> tei-council@lists.tei-c.org >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived >> -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
On 15-02-04 08:46 AM, James Cummings wrote:
Actually my manage add-ons screen lists Oxygen Version 15.2+ so there might be something in the current framework that is requiring even later oxygen.
The current stable release version of the plugin actually requires 15.2, I think, so that should probably be updated. Cheers, Martin
Glad my guide was helpful... do point people you know using oxygen (post 14+) to it as it is a really good way to get the tei framework updated.
-James
On 04/02/15 16:30, Raffaele Viglianti wrote:
Ok - just come across James's guide: http://blogs.it.ox.ac.uk/jamesc/2014/04/02/auto-update-your-tei-framework-in...
Add on frameworks are available from version 14+, so I'll get that Oxygen 16 license :)
On Wed, Feb 4, 2015 at 11:18 AM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:
Hi Martin,
Is there a Oxygen version requirement to try this out? I'm currently running 13... but will get an upgrade to 16 soon. Also, related: is it worth having my department getting me a license for 16 or is 17 coming out soon?
Raff
On Wed, Feb 4, 2015 at 11:16 AM, Martin Holmes <mholmes@uvic.ca> wrote:
Thanks Fabio! Anyone else willing to subscribe? If a few of us are using it, we'll notice when anything goes wrong. Advantages: get all the latest and greatest features of the Stylesheets and P5. Disadvantages: might break sometimes, but you can always roll back to a previous version.
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen>
Cheers, Martin
On 15-02-04 07:09 AM, Fabio Ciotti wrote:
Ok, pom.xml disappeared. I've tried things here and there and everything seems to work...
f
2015-02-04 0:50 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Fixed it! Fabio, try updating your plugin, and you shouldn't see that "pom.xml" any more.
Cheers, Martin
On 15-02-03 01:19 PM, Martin Holmes wrote:
> I can see that pom.xml file appearing in the build, but I'm not sure > where it's coming from. It seems to be something to do with the P5 > build > that gets pulled in. Sebastian, do you recognize it? pom.xml ends > up in > templates/TEI P5. > > Cheers, > Martin > > On 15-02-03 11:12 AM, Fabio Ciotti wrote: > >> Hi Martin and all, >> >> in my Oxy (Ubuntu Linux version) using the experimental Jenkins >> build >> of the framework I find a misleading "pom" (Mavent project file >> coming I guess from Jenky) type of TEI file in the open new file >> dialog box. >> >> Fabio >> >> 2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>: >> >>> Hi all, >>> >>> I now have a development build of the oxygen-tei add-on >>> working. You >>> can >>> subscribe from here: >>> >>> >>> <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ >>> lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen> >>> >>> >>> If you're brave enough to try it, uninstall the regular version of >>> the >>> add-on before installing this one. >>> >>> I can also confirm that James was right: you can provide access to >>> multiple >>> versions of the plugin, allowing people to roll back to a previous >>> version >>> if something breaks, by providing multiple <xt:extension> >>> elements in >>> the >>> updateSite.oxygen file. This seems to be working well with the URL >>> above: >>> if, when you're subscribing to the plugin (Help / Install New >>> Add-Ons) you >>> uncheck the "Show only the latest versions of the add-ons", you'll >>> see there >>> are three versions available. I have it set up so we'll keep >>> the last >>> ten >>> versions available. >>> >>> I've subscribed myself, so I should be able to see if anything >>> goes >>> wrong. >>> If you do test it, be aware that if you have transformation >>> scenarios >>> (for >>> instance) that depend on the absolute location of the TEI >>> extension >>> framework, those paths will no longer work; Oxygen stores the >>> add-on >>> data in >>> a path which includes a modified version of the URL of the >>> updateSite.oxygen >>> file. It's easy to change back to the standard TEI release, >>> though. >>> >>> A new version of the plugin will be built and "released" every >>> time >>> the >>> Stylesheets or P5 are rebuilt; the former triggers the latter, >>> so the >>> overall process takes quite a while, but the build of the >>> oxygen-tei >>> plugin >>> itself takes only a few seconds. >>> >>> I'm copying Sebastian on this because my Jenkins is still >>> reporting >>> build >>> failures and successes to him, as the Oxford one does to me, and I >>> want to >>> confirm that this should continue (or if it shouldn't, then what >>> should >>> happen instead). I'd also like to get this setup working on the >>> Oxford >>> Jenkins so we have some redundancy. >>> >>> The next step is to create some tests we can run in Oxygen to >>> check >>> core >>> functionality of the add-on. I envisage this as an Oxygen project >>> with a >>> bunch of sample files that are transformed or otherwise >>> manipulated >>> and the >>> results checked. These files would presumably live in the >>> oxygen-tei >>> repo. >>> >>> Cheers, >>> Martin >>> -- >>> tei-council mailing list >>> tei-council@lists.tei-c.org >>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >>> >>> PLEASE NOTE: postings to this list are publicly archived >>> -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
On 04/02/15 16:50, Martin Holmes wrote:
On 15-02-04 08:46 AM, James Cummings wrote:
Actually my manage add-ons screen lists Oxygen Version 15.2+ so there might be something in the current framework that is requiring even later oxygen.
The current stable release version of the plugin actually requires 15.2, I think, so that should probably be updated.
Blog post now updated to reflect this, I think. -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
Hi Raff, Our plugin is currently tied to Oxygen version 15.2 and above, so I don't think it's worth trying on 13. I don't know about Oxygen release schedules or versions. Cheers, Martin On 15-02-04 08:18 AM, Raffaele Viglianti wrote:
Hi Martin,
Is there a Oxygen version requirement to try this out? I'm currently running 13... but will get an upgrade to 16 soon. Also, related: is it worth having my department getting me a license for 16 or is 17 coming out soon?
Raff
On Wed, Feb 4, 2015 at 11:16 AM, Martin Holmes <mholmes@uvic.ca> wrote:
Thanks Fabio! Anyone else willing to subscribe? If a few of us are using it, we'll notice when anything goes wrong. Advantages: get all the latest and greatest features of the Stylesheets and P5. Disadvantages: might break sometimes, but you can always roll back to a previous version.
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen>
Cheers, Martin
On 15-02-04 07:09 AM, Fabio Ciotti wrote:
Ok, pom.xml disappeared. I've tried things here and there and everything seems to work...
f
2015-02-04 0:50 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
Fixed it! Fabio, try updating your plugin, and you shouldn't see that "pom.xml" any more.
Cheers, Martin
On 15-02-03 01:19 PM, Martin Holmes wrote:
I can see that pom.xml file appearing in the build, but I'm not sure where it's coming from. It seems to be something to do with the P5 build that gets pulled in. Sebastian, do you recognize it? pom.xml ends up in templates/TEI P5.
Cheers, Martin
On 15-02-03 11:12 AM, Fabio Ciotti wrote:
Hi Martin and all,
in my Oxy (Ubuntu Linux version) using the experimental Jenkins build of the framework I find a misleading "pom" (Mavent project file coming I guess from Jenky) type of TEI file in the open new file dialog box.
Fabio
2015-02-03 17:52 GMT+01:00 Martin Holmes <mholmes@uvic.ca>:
> > Hi all, > > I now have a development build of the oxygen-tei add-on working. You > can > subscribe from here: > > > <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/ > lastSuccessfulBuild/artifact/oxygen-tei/updateSite.oxygen> > > > If you're brave enough to try it, uninstall the regular version of the > add-on before installing this one. > > I can also confirm that James was right: you can provide access to > multiple > versions of the plugin, allowing people to roll back to a previous > version > if something breaks, by providing multiple <xt:extension> elements in > the > updateSite.oxygen file. This seems to be working well with the URL > above: > if, when you're subscribing to the plugin (Help / Install New > Add-Ons) you > uncheck the "Show only the latest versions of the add-ons", you'll > see there > are three versions available. I have it set up so we'll keep the last > ten > versions available. > > I've subscribed myself, so I should be able to see if anything goes > wrong. > If you do test it, be aware that if you have transformation scenarios > (for > instance) that depend on the absolute location of the TEI extension > framework, those paths will no longer work; Oxygen stores the add-on > data in > a path which includes a modified version of the URL of the > updateSite.oxygen > file. It's easy to change back to the standard TEI release, though. > > A new version of the plugin will be built and "released" every time > the > Stylesheets or P5 are rebuilt; the former triggers the latter, so the > overall process takes quite a while, but the build of the oxygen-tei > plugin > itself takes only a few seconds. > > I'm copying Sebastian on this because my Jenkins is still reporting > build > failures and successes to him, as the Oxford one does to me, and I > want to > confirm that this should continue (or if it shouldn't, then what > should > happen instead). I'd also like to get this setup working on the Oxford > Jenkins so we have some redundancy. > > The next step is to create some tests we can run in Oxygen to check > core > functionality of the add-on. I envisage this as an Oxygen project > with a > bunch of sample files that are transformed or otherwise manipulated > and the > results checked. These files would presumably live in the oxygen-tei > repo. > > Cheers, > Martin > -- > tei-council mailing list > tei-council@lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived >
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I've removed my old TEI P5 add on and installed this one. It downloaded and installed fine, oXygen restarted. It is confusing because the schemas referenced in the xml-model of course point to the current release, but behind the scenes it is using a copy of the schema downloaded from Jenkins. right? I tried to think of a way to test this and then I remembered global @resp. So mine seems to have updated seamlessly. Just waiting for an additional schema-changing thing to trigger an update... so I can update. The next question is whether we should be using precisely the same version numbering -- What I'm wondering is whether there is some way to embed the revision number in it. Currently the version A possible problem: When I go to Help -> Manage add-ons and *uncheck* both "show only compatible add-ons" and "show only latest versions of the add-ons" I get a list of versions 2.7.10, 2.7.9, 2.7.8 etc. but the status of all the earlier ones is 'Incompatible'. Any ideas why so? -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
HI James, On 15-02-04 08:36 AM, James Cummings wrote:
I've removed my old TEI P5 add on and installed this one. It downloaded and installed fine, oXygen restarted.
It is confusing because the schemas referenced in the xml-model of course point to the current release, but behind the scenes it is using a copy of the schema downloaded from Jenkins. right?
Yes, exactly. That's an inconsistency. We could re-work the build process so that it's pointing at Jenkins-based schemas, but that in itself is a little fragile. You don't want to be creating documents for the long term which point at schemas that are constantly changing. It's slightly complicated by the fact that if you link to a version of a known TEI schema (known to Oxygen), Oxygen often validates against the tei-c.org version. What does the team think? What would be the ideal behaviour here?
I tried to think of a way to test this and then I remembered global @resp.
So mine seems to have updated seamlessly. Just waiting for an additional schema-changing thing to trigger an update... so I can update. The next question is whether we should be using precisely the same version numbering -- What I'm wondering is whether there is some way to embed the revision number in it. Currently the version
That got cut off, but on the version number for the plugin: The first two digits come from the major and minor P5 versions (so 2.7). The overall number has to increment in order to allow updates to be different, so I just increment that last number with every build. The "official" release also has a relatively meaningless number for its third digit, I think (Sebastian will know). If anyone can think of another approach for this, it's easy to change.
A possible problem:
When I go to Help -> Manage add-ons and *uncheck* both "show only compatible add-ons" and "show only latest versions of the add-ons" I get a list of versions 2.7.10, 2.7.9, 2.7.8 etc. but the status of all the earlier ones is 'Incompatible'. Any ideas why so?
My guess is because you already have the latest one installed; if you removed it, they would all be compatible. Cheers, Martin
-James
On 04/02/15 16:48, Martin Holmes wrote:
Yes, exactly. That's an inconsistency. We could re-work the build process so that it's pointing at Jenkins-based schemas, but that in itself is a little fragile. You don't want to be creating documents for the long term which point at schemas that are constantly changing. It's slightly complicated by the fact that if you link to a version of a known TEI schema (known to Oxygen), Oxygen often validates against the tei-c.org version.
What does the team think? What would be the ideal behaviour here?
Keep it as is but validate against the jenkins version of the schema. That is what *seems* to be happening now. Presumably it only validates against the website when it can't find the other version? (At which point you have other problems because that is part of the framework it has downloaded...)
numbering -- What I'm wondering is whether there is some way to embed the revision number in it. Currently the version
That got cut off, but on the version number for the plugin:
Weird. Don't know why. I didn't say anything you didn't predict.
The first two digits come from the major and minor P5 versions (so 2.7). The overall number has to increment in order to allow updates to be different, so I just increment that last number with every build. The "official" release also has a relatively meaningless number for its third digit, I think (Sebastian will know). If anyone can think of another approach for this, it's easy to change.
Yes. What I'm suggesting is that you somehow incorporate the revision number of both SVN and GitHub. Currently the updateSite.oxygen file for each extension has something like: <xt:location href="teioxygen-2.7.0-7.29.0.zip"/> <xt:version>2.7.2</xt:version> I'm suggesting that we change it to the much less human-readable for the public, but potentially useful for us: <xt:location href="teioxygen-2.7.0r13126-7.29.0rc5c16b9.zip"/> <xt:version>2.7.0r13126-7.29.0rc5c16b9</xt:version> So that then we could see *precisely* which version of both TEI P5 and Stylesheets we are using. The problem comes if you tell me that xt:version has to be sequentially / numerically 'higher' than its predecessor....
My guess is because you already have the latest one installed; if you removed it, they would all be compatible.
You are entirely right. If I uninstall the current one I can then jump back to any of them. If only there was a clear relationship between the version number there and revisions in SVN ;-) -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
Hi James, On 15-02-04 09:05 AM, James Cummings wrote:
On 04/02/15 16:48, Martin Holmes wrote:
Yes, exactly. That's an inconsistency. We could re-work the build process so that it's pointing at Jenkins-based schemas, but that in itself is a little fragile. You don't want to be creating documents for the long term which point at schemas that are constantly changing. It's slightly complicated by the fact that if you link to a version of a known TEI schema (known to Oxygen), Oxygen often validates against the tei-c.org version.
What does the team think? What would be the ideal behaviour here?
Keep it as is but validate against the jenkins version of the schema. That is what *seems* to be happening now. Presumably it only validates against the website when it can't find the other version? (At which point you have other problems because that is part of the framework it has downloaded...)
I'll have to investigate, but if it's currently validating against the local (i.e. the plugin) copy of the schema, then you're right, that's what we want. I think the behaviour I've observed in the past is when you create a TEI file without xml-model, or xml-model points to something not available, Oxygen silently defaults to the tei-c schema.
numbering -- What I'm wondering is whether there is some way to embed the revision number in it. Currently the version
That got cut off, but on the version number for the plugin:
Weird. Don't know why. I didn't say anything you didn't predict.
The first two digits come from the major and minor P5 versions (so 2.7). The overall number has to increment in order to allow updates to be different, so I just increment that last number with every build. The "official" release also has a relatively meaningless number for its third digit, I think (Sebastian will know). If anyone can think of another approach for this, it's easy to change.
Yes. What I'm suggesting is that you somehow incorporate the revision number of both SVN and GitHub. Currently the updateSite.oxygen file for each extension has something like:
<xt:location href="teioxygen-2.7.0-7.29.0.zip"/> <xt:version>2.7.2</xt:version>
I'm suggesting that we change it to the much less human-readable for the public, but potentially useful for us:
<xt:location href="teioxygen-2.7.0r13126-7.29.0rc5c16b9.zip"/> <xt:version>2.7.0r13126-7.29.0rc5c16b9</xt:version>
The actual plugin download file name includes the date and time of the build: <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/> but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. An additional problem is that the Jenkins build process knows nothing about the version numbers of the Stylesheets and P5 repos; it just pulls the latest successful build archives (which don't contain that information) and uses them. You would think that the build script could just ask svn and git to find out the info from the local copies of the workspaces for those jobs, but in fact you can't because the local svn and git (which the script would call) have different versions from the Java tools used by Jenkins to check out code from the repos; if you try to run regular svn against a repo in a Jenkins job, it typically complains that your repo is old and needs to be updated before you can do anything; if you then update it, it's the wrong version for the Jenkins plugin. Sebastian may have some suggestions here, but given that we know the build date and time from the plugin file name, and those are tied to the plugin version by updateSite.oxygen, it's possible to find out which versions of the Stylesheets and P5 repos were current at the time of the build, I don't fancy disappearing down this particular rabbit hole. IN most cases, we're going to discover a problem, update our plugin, and if the problem is still there, that means it's there in the current version of the Stylesheets or P5.
So that then we could see *precisely* which version of both TEI P5 and Stylesheets we are using.
The problem comes if you tell me that xt:version has to be sequentially / numerically 'higher' than its predecessor....
My guess is because you already have the latest one installed; if you removed it, they would all be compatible.
You are entirely right. If I uninstall the current one I can then jump back to any of them. If only there was a clear relationship between the version number there and revisions in SVN ;-)
There is, as above: check plugin zip file name for your version in updateSite.oxygen, find date and time of build from that, then find out using svn or git what particular version of P5 or the Stylesheets was current at that time. I bet amount of time spent by everyone who has to do that manually (at 2 minutes a time) will be orders of magnitude smaller than the amount of time it would take me to erect some horribly-fragile process for the build script that attempts to determine it. Cheers, Martin
-James
I havent been following closely, so forgive me if this is a daft suggestion, but from my perspective all I want in Oxygen is two options: use the framework corresponding with the current release (this is what I currently have), or use the framework corresponding with the last good build on Jenkins. I cannot imagine a situation where I'd want to use a framework corresponding with the last but 2 good builds since the previous release! So is the plan eventually to have a URL for "last good build" analogous to what is currently at http://www.tei-c.org/release/oxygen/updateSite.oxygen <http://www.tei-c.org/release/oxygen/updateSite.oxygen> e.g. http://www.tei-c.org/release/oxygen/bleedingEdge.oxygen ? <http://www.tei-c.org/release/oxygen/updateSite.oxygen> On 04/02/15 17:59, Martin Holmes wrote:?: ? and if so
Hi James,
On 15-02-04 09:05 AM, James Cummings wrote:
On 04/02/15 16:48, Martin Holmes wrote:
Yes, exactly. That's an inconsistency. We could re-work the build process so that it's pointing at Jenkins-based schemas, but that in itself is a little fragile. You don't want to be creating documents for the long term which point at schemas that are constantly changing. It's slightly complicated by the fact that if you link to a version of a known TEI schema (known to Oxygen), Oxygen often validates against the tei-c.org version.
What does the team think? What would be the ideal behaviour here?
Keep it as is but validate against the jenkins version of the schema. That is what *seems* to be happening now. Presumably it only validates against the website when it can't find the other version? (At which point you have other problems because that is part of the framework it has downloaded...)
I'll have to investigate, but if it's currently validating against the local (i.e. the plugin) copy of the schema, then you're right, that's what we want. I think the behaviour I've observed in the past is when you create a TEI file without xml-model, or xml-model points to something not available, Oxygen silently defaults to the tei-c schema.
numbering -- What I'm wondering is whether there is some way to embed the revision number in it. Currently the version
That got cut off, but on the version number for the plugin:
Weird. Don't know why. I didn't say anything you didn't predict.
The first two digits come from the major and minor P5 versions (so 2.7). The overall number has to increment in order to allow updates to be different, so I just increment that last number with every build. The "official" release also has a relatively meaningless number for its third digit, I think (Sebastian will know). If anyone can think of another approach for this, it's easy to change.
Yes. What I'm suggesting is that you somehow incorporate the revision number of both SVN and GitHub. Currently the updateSite.oxygen file for each extension has something like:
<xt:location href="teioxygen-2.7.0-7.29.0.zip"/> <xt:version>2.7.2</xt:version>
I'm suggesting that we change it to the much less human-readable for the public, but potentially useful for us:
<xt:location href="teioxygen-2.7.0r13126-7.29.0rc5c16b9.zip"/> <xt:version>2.7.0r13126-7.29.0rc5c16b9</xt:version>
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. An additional problem is that the Jenkins build process knows nothing about the version numbers of the Stylesheets and P5 repos; it just pulls the latest successful build archives (which don't contain that information) and uses them. You would think that the build script could just ask svn and git to find out the info from the local copies of the workspaces for those jobs, but in fact you can't because the local svn and git (which the script would call) have different versions from the Java tools used by Jenkins to check out code from the repos; if you try to run regular svn against a repo in a Jenkins job, it typically complains that your repo is old and needs to be updated before you can do anything; if you then update it, it's the wrong version for the Jenkins plugin.
Sebastian may have some suggestions here, but given that we know the build date and time from the plugin file name, and those are tied to the plugin version by updateSite.oxygen, it's possible to find out which versions of the Stylesheets and P5 repos were current at the time of the build, I don't fancy disappearing down this particular rabbit hole. IN most cases, we're going to discover a problem, update our plugin, and if the problem is still there, that means it's there in the current version of the Stylesheets or P5.
So that then we could see *precisely* which version of both TEI P5 and Stylesheets we are using.
The problem comes if you tell me that xt:version has to be sequentially / numerically 'higher' than its predecessor....
My guess is because you already have the latest one installed; if you removed it, they would all be compatible.
You are entirely right. If I uninstall the current one I can then jump back to any of them. If only there was a clear relationship between the version number there and revisions in SVN ;-)
There is, as above: check plugin zip file name for your version in updateSite.oxygen, find date and time of build from that, then find out using svn or git what particular version of P5 or the Stylesheets was current at that time. I bet amount of time spent by everyone who has to do that manually (at 2 minutes a time) will be orders of magnitude smaller than the amount of time it would take me to erect some horribly-fragile process for the build script that attempts to determine it.
Cheers, Martin
-James
Hi Lou, The idea is that if you're a brave soul using the Jenkins build, there's the likelihood that once in a while it will break. When that happens, you want to be able to roll back to a previous working version of the plugin, so you can continue with your work, while you or someone else tracks down the problem and fixes it; then you can update again to the latest. We sincerely hope that we never release a broken version of the stable build, so the ability to roll back (which isn't currently included in the stable build) is not needed; but one reason for the whole Jenkins-test-build idea is to reduce the likelihood of that considerably. Cheers, Martin On 15-02-04 10:33 AM, Lou Burnard wrote:
I havent been following closely, so forgive me if this is a daft suggestion, but from my perspective all I want in Oxygen is two options: use the framework corresponding with the current release (this is what I currently have), or use the framework corresponding with the last good build on Jenkins. I cannot imagine a situation where I'd want to use a framework corresponding with the last but 2 good builds since the previous release!
So is the plan eventually to have a URL for "last good build" analogous to what is currently at http://www.tei-c.org/release/oxygen/updateSite.oxygen <http://www.tei-c.org/release/oxygen/updateSite.oxygen> e.g. http://www.tei-c.org/release/oxygen/bleedingEdge.oxygen ? <http://www.tei-c.org/release/oxygen/updateSite.oxygen>
On 04/02/15 17:59, Martin Holmes wrote:?: ? and if so
Hi James,
On 15-02-04 09:05 AM, James Cummings wrote:
On 04/02/15 16:48, Martin Holmes wrote:
Yes, exactly. That's an inconsistency. We could re-work the build process so that it's pointing at Jenkins-based schemas, but that in itself is a little fragile. You don't want to be creating documents for the long term which point at schemas that are constantly changing. It's slightly complicated by the fact that if you link to a version of a known TEI schema (known to Oxygen), Oxygen often validates against the tei-c.org version.
What does the team think? What would be the ideal behaviour here?
Keep it as is but validate against the jenkins version of the schema. That is what *seems* to be happening now. Presumably it only validates against the website when it can't find the other version? (At which point you have other problems because that is part of the framework it has downloaded...)
I'll have to investigate, but if it's currently validating against the local (i.e. the plugin) copy of the schema, then you're right, that's what we want. I think the behaviour I've observed in the past is when you create a TEI file without xml-model, or xml-model points to something not available, Oxygen silently defaults to the tei-c schema.
numbering -- What I'm wondering is whether there is some way to embed the revision number in it. Currently the version
That got cut off, but on the version number for the plugin:
Weird. Don't know why. I didn't say anything you didn't predict.
The first two digits come from the major and minor P5 versions (so 2.7). The overall number has to increment in order to allow updates to be different, so I just increment that last number with every build. The "official" release also has a relatively meaningless number for its third digit, I think (Sebastian will know). If anyone can think of another approach for this, it's easy to change.
Yes. What I'm suggesting is that you somehow incorporate the revision number of both SVN and GitHub. Currently the updateSite.oxygen file for each extension has something like:
<xt:location href="teioxygen-2.7.0-7.29.0.zip"/> <xt:version>2.7.2</xt:version>
I'm suggesting that we change it to the much less human-readable for the public, but potentially useful for us:
<xt:location href="teioxygen-2.7.0r13126-7.29.0rc5c16b9.zip"/> <xt:version>2.7.0r13126-7.29.0rc5c16b9</xt:version>
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. An additional problem is that the Jenkins build process knows nothing about the version numbers of the Stylesheets and P5 repos; it just pulls the latest successful build archives (which don't contain that information) and uses them. You would think that the build script could just ask svn and git to find out the info from the local copies of the workspaces for those jobs, but in fact you can't because the local svn and git (which the script would call) have different versions from the Java tools used by Jenkins to check out code from the repos; if you try to run regular svn against a repo in a Jenkins job, it typically complains that your repo is old and needs to be updated before you can do anything; if you then update it, it's the wrong version for the Jenkins plugin.
Sebastian may have some suggestions here, but given that we know the build date and time from the plugin file name, and those are tied to the plugin version by updateSite.oxygen, it's possible to find out which versions of the Stylesheets and P5 repos were current at the time of the build, I don't fancy disappearing down this particular rabbit hole. IN most cases, we're going to discover a problem, update our plugin, and if the problem is still there, that means it's there in the current version of the Stylesheets or P5.
So that then we could see *precisely* which version of both TEI P5 and Stylesheets we are using.
The problem comes if you tell me that xt:version has to be sequentially / numerically 'higher' than its predecessor....
My guess is because you already have the latest one installed; if you removed it, they would all be compatible.
You are entirely right. If I uninstall the current one I can then jump back to any of them. If only there was a clear relationship between the version number there and revisions in SVN ;-)
There is, as above: check plugin zip file name for your version in updateSite.oxygen, find date and time of build from that, then find out using svn or git what particular version of P5 or the Stylesheets was current at that time. I bet amount of time spent by everyone who has to do that manually (at 2 minutes a time) will be orders of magnitude smaller than the amount of time it would take me to erect some horribly-fragile process for the build script that attempts to determine it.
Cheers, Martin
-James
Yes, but my point is that in the unlikely (?) event of the bleedin-edge version being broken, I will be happy to roll back to the previous stable release until such time as it's fixed. On 04/02/15 18:52, Martin Holmes wrote:
Hi Lou,
The idea is that if you're a brave soul using the Jenkins build, there's the likelihood that once in a while it will break. When that happens, you want to be able to roll back to a previous working version of the plugin, so you can continue with your work, while you or someone else tracks down the problem and fixes it; then you can update again to the latest.
We sincerely hope that we never release a broken version of the stable build, so the ability to roll back (which isn't currently included in the stable build) is not needed; but one reason for the whole Jenkins-test-build idea is to reduce the likelihood of that considerably.
Cheers, Martin
On 15-02-04 10:33 AM, Lou Burnard wrote:
I havent been following closely, so forgive me if this is a daft suggestion, but from my perspective all I want in Oxygen is two options: use the framework corresponding with the current release (this is what I currently have), or use the framework corresponding with the last good build on Jenkins. I cannot imagine a situation where I'd want to use a framework corresponding with the last but 2 good builds since the previous release!
So is the plan eventually to have a URL for "last good build" analogous to what is currently at http://www.tei-c.org/release/oxygen/updateSite.oxygen <http://www.tei-c.org/release/oxygen/updateSite.oxygen> e.g. http://www.tei-c.org/release/oxygen/bleedingEdge.oxygen ? <http://www.tei-c.org/release/oxygen/updateSite.oxygen>
On 04/02/15 17:59, Martin Holmes wrote:?: ? and if so
Hi James,
On 15-02-04 09:05 AM, James Cummings wrote:
On 04/02/15 16:48, Martin Holmes wrote:
Yes, exactly. That's an inconsistency. We could re-work the build process so that it's pointing at Jenkins-based schemas, but that in itself is a little fragile. You don't want to be creating documents for the long term which point at schemas that are constantly changing. It's slightly complicated by the fact that if you link to a version of a known TEI schema (known to Oxygen), Oxygen often validates against the tei-c.org version.
What does the team think? What would be the ideal behaviour here?
Keep it as is but validate against the jenkins version of the schema. That is what *seems* to be happening now. Presumably it only validates against the website when it can't find the other version? (At which point you have other problems because that is part of the framework it has downloaded...)
I'll have to investigate, but if it's currently validating against the local (i.e. the plugin) copy of the schema, then you're right, that's what we want. I think the behaviour I've observed in the past is when you create a TEI file without xml-model, or xml-model points to something not available, Oxygen silently defaults to the tei-c schema.
numbering -- What I'm wondering is whether there is some way to embed the revision number in it. Currently the version
That got cut off, but on the version number for the plugin:
Weird. Don't know why. I didn't say anything you didn't predict.
The first two digits come from the major and minor P5 versions (so 2.7). The overall number has to increment in order to allow updates to be different, so I just increment that last number with every build. The "official" release also has a relatively meaningless number for its third digit, I think (Sebastian will know). If anyone can think of another approach for this, it's easy to change.
Yes. What I'm suggesting is that you somehow incorporate the revision number of both SVN and GitHub. Currently the updateSite.oxygen file for each extension has something like:
<xt:location href="teioxygen-2.7.0-7.29.0.zip"/> <xt:version>2.7.2</xt:version>
I'm suggesting that we change it to the much less human-readable for the public, but potentially useful for us:
<xt:location href="teioxygen-2.7.0r13126-7.29.0rc5c16b9.zip"/> <xt:version>2.7.0r13126-7.29.0rc5c16b9</xt:version>
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. An additional problem is that the Jenkins build process knows nothing about the version numbers of the Stylesheets and P5 repos; it just pulls the latest successful build archives (which don't contain that information) and uses them. You would think that the build script could just ask svn and git to find out the info from the local copies of the workspaces for those jobs, but in fact you can't because the local svn and git (which the script would call) have different versions from the Java tools used by Jenkins to check out code from the repos; if you try to run regular svn against a repo in a Jenkins job, it typically complains that your repo is old and needs to be updated before you can do anything; if you then update it, it's the wrong version for the Jenkins plugin.
Sebastian may have some suggestions here, but given that we know the build date and time from the plugin file name, and those are tied to the plugin version by updateSite.oxygen, it's possible to find out which versions of the Stylesheets and P5 repos were current at the time of the build, I don't fancy disappearing down this particular rabbit hole. IN most cases, we're going to discover a problem, update our plugin, and if the problem is still there, that means it's there in the current version of the Stylesheets or P5.
So that then we could see *precisely* which version of both TEI P5 and Stylesheets we are using.
The problem comes if you tell me that xt:version has to be sequentially / numerically 'higher' than its predecessor....
My guess is because you already have the latest one installed; if you removed it, they would all be compatible.
You are entirely right. If I uninstall the current one I can then jump back to any of them. If only there was a clear relationship between the version number there and revisions in SVN ;-)
There is, as above: check plugin zip file name for your version in updateSite.oxygen, find date and time of build from that, then find out using svn or git what particular version of P5 or the Stylesheets was current at that time. I bet amount of time spent by everyone who has to do that manually (at 2 minutes a time) will be orders of magnitude smaller than the amount of time it would take me to erect some horribly-fragile process for the build script that attempts to determine it.
Cheers, Martin
-James
Hi Lou, As far as I can see, there's no way to provide a single subscription file (updateSite.oxygen) that would combine both stable releases and bleedin' edge releases. You'd have to manage that manually. The reason is that within a single updateSite.oxgyen file, the version numbers have to be consecutive. The current stable release would be very old compared with the regularly-rebuilt bleedin' versions. I would hope that the bleedin version is not often unstable, so just rolling back to the version before the one that broke would be enough to get you started again, but only time will tell. In any case, uninstalling the bleedin version and reverting to the stable one is a two-minute job. Cheers, Martin On 15-02-04 12:25 PM, Lou Burnard wrote:
Yes, but my point is that in the unlikely (?) event of the bleedin-edge version being broken, I will be happy to roll back to the previous stable release until such time as it's fixed.
On 04/02/15 18:52, Martin Holmes wrote:
Hi Lou,
The idea is that if you're a brave soul using the Jenkins build, there's the likelihood that once in a while it will break. When that happens, you want to be able to roll back to a previous working version of the plugin, so you can continue with your work, while you or someone else tracks down the problem and fixes it; then you can update again to the latest.
We sincerely hope that we never release a broken version of the stable build, so the ability to roll back (which isn't currently included in the stable build) is not needed; but one reason for the whole Jenkins-test-build idea is to reduce the likelihood of that considerably.
Cheers, Martin
On 15-02-04 10:33 AM, Lou Burnard wrote:
I havent been following closely, so forgive me if this is a daft suggestion, but from my perspective all I want in Oxygen is two options: use the framework corresponding with the current release (this is what I currently have), or use the framework corresponding with the last good build on Jenkins. I cannot imagine a situation where I'd want to use a framework corresponding with the last but 2 good builds since the previous release!
So is the plan eventually to have a URL for "last good build" analogous to what is currently at http://www.tei-c.org/release/oxygen/updateSite.oxygen <http://www.tei-c.org/release/oxygen/updateSite.oxygen> e.g. http://www.tei-c.org/release/oxygen/bleedingEdge.oxygen ? <http://www.tei-c.org/release/oxygen/updateSite.oxygen>
On 04/02/15 17:59, Martin Holmes wrote:?: ? and if so
Hi James,
On 15-02-04 09:05 AM, James Cummings wrote:
On 04/02/15 16:48, Martin Holmes wrote:
Yes, exactly. That's an inconsistency. We could re-work the build process so that it's pointing at Jenkins-based schemas, but that in itself is a little fragile. You don't want to be creating documents for the long term which point at schemas that are constantly changing. It's slightly complicated by the fact that if you link to a version of a known TEI schema (known to Oxygen), Oxygen often validates against the tei-c.org version.
What does the team think? What would be the ideal behaviour here?
Keep it as is but validate against the jenkins version of the schema. That is what *seems* to be happening now. Presumably it only validates against the website when it can't find the other version? (At which point you have other problems because that is part of the framework it has downloaded...)
I'll have to investigate, but if it's currently validating against the local (i.e. the plugin) copy of the schema, then you're right, that's what we want. I think the behaviour I've observed in the past is when you create a TEI file without xml-model, or xml-model points to something not available, Oxygen silently defaults to the tei-c schema.
> numbering -- What I'm wondering is whether there is some way to > embed > the revision number in it. Currently the version
That got cut off, but on the version number for the plugin:
Weird. Don't know why. I didn't say anything you didn't predict.
The first two digits come from the major and minor P5 versions (so 2.7). The overall number has to increment in order to allow updates to be different, so I just increment that last number with every build. The "official" release also has a relatively meaningless number for its third digit, I think (Sebastian will know). If anyone can think of another approach for this, it's easy to change.
Yes. What I'm suggesting is that you somehow incorporate the revision number of both SVN and GitHub. Currently the updateSite.oxygen file for each extension has something like:
<xt:location href="teioxygen-2.7.0-7.29.0.zip"/> <xt:version>2.7.2</xt:version>
I'm suggesting that we change it to the much less human-readable for the public, but potentially useful for us:
<xt:location href="teioxygen-2.7.0r13126-7.29.0rc5c16b9.zip"/> <xt:version>2.7.0r13126-7.29.0rc5c16b9</xt:version>
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. An additional problem is that the Jenkins build process knows nothing about the version numbers of the Stylesheets and P5 repos; it just pulls the latest successful build archives (which don't contain that information) and uses them. You would think that the build script could just ask svn and git to find out the info from the local copies of the workspaces for those jobs, but in fact you can't because the local svn and git (which the script would call) have different versions from the Java tools used by Jenkins to check out code from the repos; if you try to run regular svn against a repo in a Jenkins job, it typically complains that your repo is old and needs to be updated before you can do anything; if you then update it, it's the wrong version for the Jenkins plugin.
Sebastian may have some suggestions here, but given that we know the build date and time from the plugin file name, and those are tied to the plugin version by updateSite.oxygen, it's possible to find out which versions of the Stylesheets and P5 repos were current at the time of the build, I don't fancy disappearing down this particular rabbit hole. IN most cases, we're going to discover a problem, update our plugin, and if the problem is still there, that means it's there in the current version of the Stylesheets or P5.
So that then we could see *precisely* which version of both TEI P5 and Stylesheets we are using.
The problem comes if you tell me that xt:version has to be sequentially / numerically 'higher' than its predecessor....
My guess is because you already have the latest one installed; if you removed it, they would all be compatible.
You are entirely right. If I uninstall the current one I can then jump back to any of them. If only there was a clear relationship between the version number there and revisions in SVN ;-)
There is, as above: check plugin zip file name for your version in updateSite.oxygen, find date and time of build from that, then find out using svn or git what particular version of P5 or the Stylesheets was current at that time. I bet amount of time spent by everyone who has to do that manually (at 2 minutes a time) will be orders of magnitude smaller than the amount of time it would take me to erect some horribly-fragile process for the build script that attempts to determine it.
Cheers, Martin
-James
Clearly we are talking at cross purposes. Is there any reason why you shouldn't have two subscription files? One for the stable release, one for the other? On 04/02/15 20:52, Martin Holmes wrote:
Hi Lou,
As far as I can see, there's no way to provide a single subscription file (updateSite.oxygen) that would combine both stable releases and bleedin' edge releases. You'd have to manage that manually. The reason is that within a single updateSite.oxgyen file, the version numbers have to be consecutive. The current stable release would be very old compared with the regularly-rebuilt bleedin' versions.
I would hope that the bleedin version is not often unstable, so just rolling back to the version before the one that broke would be enough to get you started again, but only time will tell. In any case, uninstalling the bleedin version and reverting to the stable one is a two-minute job.
Cheers, Martin
On 15-02-04 12:25 PM, Lou Burnard wrote:
Yes, but my point is that in the unlikely (?) event of the bleedin-edge version being broken, I will be happy to roll back to the previous stable release until such time as it's fixed.
On 04/02/15 18:52, Martin Holmes wrote:
Hi Lou,
The idea is that if you're a brave soul using the Jenkins build, there's the likelihood that once in a while it will break. When that happens, you want to be able to roll back to a previous working version of the plugin, so you can continue with your work, while you or someone else tracks down the problem and fixes it; then you can update again to the latest.
We sincerely hope that we never release a broken version of the stable build, so the ability to roll back (which isn't currently included in the stable build) is not needed; but one reason for the whole Jenkins-test-build idea is to reduce the likelihood of that considerably.
Cheers, Martin
On 15-02-04 10:33 AM, Lou Burnard wrote:
I havent been following closely, so forgive me if this is a daft suggestion, but from my perspective all I want in Oxygen is two options: use the framework corresponding with the current release (this is what I currently have), or use the framework corresponding with the last good build on Jenkins. I cannot imagine a situation where I'd want to use a framework corresponding with the last but 2 good builds since the previous release!
So is the plan eventually to have a URL for "last good build" analogous to what is currently at http://www.tei-c.org/release/oxygen/updateSite.oxygen <http://www.tei-c.org/release/oxygen/updateSite.oxygen> e.g. http://www.tei-c.org/release/oxygen/bleedingEdge.oxygen ? <http://www.tei-c.org/release/oxygen/updateSite.oxygen>
On 04/02/15 17:59, Martin Holmes wrote:?: ? and if so
Hi James,
On 15-02-04 09:05 AM, James Cummings wrote:
On 04/02/15 16:48, Martin Holmes wrote: > Yes, exactly. That's an inconsistency. We could re-work the build > process so that it's pointing at Jenkins-based schemas, but that in > itself is a little fragile. You don't want to be creating documents > for the long term which point at schemas that are constantly > changing. > It's slightly complicated by the fact that if you link to a > version of > a known TEI schema (known to Oxygen), Oxygen often validates > against > the tei-c.org version. > > What does the team think? What would be the ideal behaviour here?
Keep it as is but validate against the jenkins version of the schema. That is what *seems* to be happening now. Presumably it only validates against the website when it can't find the other version? (At which point you have other problems because that is part of the framework it has downloaded...)
I'll have to investigate, but if it's currently validating against the local (i.e. the plugin) copy of the schema, then you're right, that's what we want. I think the behaviour I've observed in the past is when you create a TEI file without xml-model, or xml-model points to something not available, Oxygen silently defaults to the tei-c schema.
>> numbering -- What I'm wondering is whether there is some way to >> embed >> the revision number in it. Currently the version > > That got cut off, but on the version number for the plugin:
Weird. Don't know why. I didn't say anything you didn't predict.
> The first two digits come from the major and minor P5 versions (so > 2.7). The overall number has to increment in order to allow > updates to > be different, so I just increment that last number with every > build. > The "official" release also has a relatively meaningless number for > its third digit, I think (Sebastian will know). If anyone can > think of > another approach for this, it's easy to change.
Yes. What I'm suggesting is that you somehow incorporate the revision number of both SVN and GitHub. Currently the updateSite.oxygen file for each extension has something like:
<xt:location href="teioxygen-2.7.0-7.29.0.zip"/> <xt:version>2.7.2</xt:version>
I'm suggesting that we change it to the much less human-readable for the public, but potentially useful for us:
<xt:location href="teioxygen-2.7.0r13126-7.29.0rc5c16b9.zip"/> <xt:version>2.7.0r13126-7.29.0rc5c16b9</xt:version>
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. An additional problem is that the Jenkins build process knows nothing about the version numbers of the Stylesheets and P5 repos; it just pulls the latest successful build archives (which don't contain that information) and uses them. You would think that the build script could just ask svn and git to find out the info from the local copies of the workspaces for those jobs, but in fact you can't because the local svn and git (which the script would call) have different versions from the Java tools used by Jenkins to check out code from the repos; if you try to run regular svn against a repo in a Jenkins job, it typically complains that your repo is old and needs to be updated before you can do anything; if you then update it, it's the wrong version for the Jenkins plugin.
Sebastian may have some suggestions here, but given that we know the build date and time from the plugin file name, and those are tied to the plugin version by updateSite.oxygen, it's possible to find out which versions of the Stylesheets and P5 repos were current at the time of the build, I don't fancy disappearing down this particular rabbit hole. IN most cases, we're going to discover a problem, update our plugin, and if the problem is still there, that means it's there in the current version of the Stylesheets or P5.
So that then we could see *precisely* which version of both TEI P5 and Stylesheets we are using.
The problem comes if you tell me that xt:version has to be sequentially / numerically 'higher' than its predecessor....
> My guess is because you already have the latest one installed; > if you > removed it, they would all be compatible.
You are entirely right. If I uninstall the current one I can then jump back to any of them. If only there was a clear relationship between the version number there and revisions in SVN ;-)
There is, as above: check plugin zip file name for your version in updateSite.oxygen, find date and time of build from that, then find out using svn or git what particular version of P5 or the Stylesheets was current at that time. I bet amount of time spent by everyone who has to do that manually (at 2 minutes a time) will be orders of magnitude smaller than the amount of time it would take me to erect some horribly-fragile process for the build script that attempts to determine it.
Cheers, Martin
-James
Because they would conflict with each other. e.g. the framework has a rule that says if the file starts with a TEI element in the TEI Namespace, then use the framework schema to validate it. But then you'd have two frameworks claiming that.... etc. -James On 04/02/15 21:18, Lou Burnard wrote:
Clearly we are talking at cross purposes. Is there any reason why you shouldn't have two subscription files? One for the stable release, one for the other?
On 04/02/15 20:52, Martin Holmes wrote:
Hi Lou,
As far as I can see, there's no way to provide a single subscription file (updateSite.oxygen) that would combine both stable releases and bleedin' edge releases. You'd have to manage that manually. The reason is that within a single updateSite.oxgyen file, the version numbers have to be consecutive. The current stable release would be very old compared with the regularly-rebuilt bleedin' versions.
I would hope that the bleedin version is not often unstable, so just rolling back to the version before the one that broke would be enough to get you started again, but only time will tell. In any case, uninstalling the bleedin version and reverting to the stable one is a two-minute job.
Cheers, Martin
On 15-02-04 12:25 PM, Lou Burnard wrote:
Yes, but my point is that in the unlikely (?) event of the bleedin-edge version being broken, I will be happy to roll back to the previous stable release until such time as it's fixed.
On 04/02/15 18:52, Martin Holmes wrote:
Hi Lou,
The idea is that if you're a brave soul using the Jenkins build, there's the likelihood that once in a while it will break. When that happens, you want to be able to roll back to a previous working version of the plugin, so you can continue with your work, while you or someone else tracks down the problem and fixes it; then you can update again to the latest.
We sincerely hope that we never release a broken version of the stable build, so the ability to roll back (which isn't currently included in the stable build) is not needed; but one reason for the whole Jenkins-test-build idea is to reduce the likelihood of that considerably.
Cheers, Martin
On 15-02-04 10:33 AM, Lou Burnard wrote:
I havent been following closely, so forgive me if this is a daft suggestion, but from my perspective all I want in Oxygen is two options: use the framework corresponding with the current release (this is what I currently have), or use the framework corresponding with the last good build on Jenkins. I cannot imagine a situation where I'd want to use a framework corresponding with the last but 2 good builds since the previous release!
So is the plan eventually to have a URL for "last good build" analogous to what is currently at http://www.tei-c.org/release/oxygen/updateSite.oxygen <http://www.tei-c.org/release/oxygen/updateSite.oxygen> e.g. http://www.tei-c.org/release/oxygen/bleedingEdge.oxygen ? <http://www.tei-c.org/release/oxygen/updateSite.oxygen>
On 04/02/15 17:59, Martin Holmes wrote:?: ? and if so
Hi James,
On 15-02-04 09:05 AM, James Cummings wrote: > On 04/02/15 16:48, Martin Holmes wrote: >> Yes, exactly. That's an inconsistency. We could re-work >> the build >> process so that it's pointing at Jenkins-based schemas, >> but that in >> itself is a little fragile. You don't want to be >> creating documents >> for the long term which point at schemas that are >> constantly >> changing. >> It's slightly complicated by the fact that if you link to a >> version of >> a known TEI schema (known to Oxygen), Oxygen often >> validates against >> the tei-c.org version. >> >> What does the team think? What would be the ideal >> behaviour here? > > Keep it as is but validate against the jenkins version of > the schema. > That is what *seems* to be happening now. Presumably it > only validates > against the website when it can't find the other version? > (At which > point you have other problems because that is part of the > framework it > has downloaded...)
I'll have to investigate, but if it's currently validating against the local (i.e. the plugin) copy of the schema, then you're right, that's what we want. I think the behaviour I've observed in the past is when you create a TEI file without xml-model, or xml-model points to something not available, Oxygen silently defaults to the tei-c schema.
>>> numbering -- What I'm wondering is whether there is >>> some way to >>> embed >>> the revision number in it. Currently the version >> >> That got cut off, but on the version number for the plugin: > > Weird. Don't know why. I didn't say anything you didn't > predict. > >> The first two digits come from the major and minor P5 >> versions (so >> 2.7). The overall number has to increment in order to allow >> updates to >> be different, so I just increment that last number with >> every build. >> The "official" release also has a relatively meaningless >> number for >> its third digit, I think (Sebastian will know). If >> anyone can >> think of >> another approach for this, it's easy to change. > > Yes. What I'm suggesting is that you somehow incorporate > the revision > number of both SVN and GitHub. Currently the > updateSite.oxygen > file for > each extension has something like: > > <xt:location href="teioxygen-2.7.0-7.29.0.zip"/> > <xt:version>2.7.2</xt:version> > > I'm suggesting that we change it to the much less > human-readable > for the > public, but potentially useful for us: > > <xt:location > href="teioxygen-2.7.0r13126-7.29.0rc5c16b9.zip"/> > <xt:version>2.7.0r13126-7.29.0rc5c16b9</xt:version>
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. An additional problem is that the Jenkins build process knows nothing about the version numbers of the Stylesheets and P5 repos; it just pulls the latest successful build archives (which don't contain that information) and uses them. You would think that the build script could just ask svn and git to find out the info from the local copies of the workspaces for those jobs, but in fact you can't because the local svn and git (which the script would call) have different versions from the Java tools used by Jenkins to check out code from the repos; if you try to run regular svn against a repo in a Jenkins job, it typically complains that your repo is old and needs to be updated before you can do anything; if you then update it, it's the wrong version for the Jenkins plugin.
Sebastian may have some suggestions here, but given that we know the build date and time from the plugin file name, and those are tied to the plugin version by updateSite.oxygen, it's possible to find out which versions of the Stylesheets and P5 repos were current at the time of the build, I don't fancy disappearing down this particular rabbit hole. IN most cases, we're going to discover a problem, update our plugin, and if the problem is still there, that means it's there in the current version of the Stylesheets or P5.
> So that then we could see *precisely* which version of > both TEI P5 and > Stylesheets we are using. > > The problem comes if you tell me that xt:version has to be > sequentially > / numerically 'higher' than its predecessor.... > > >> My guess is because you already have the latest one >> installed; if you >> removed it, they would all be compatible. > > You are entirely right. If I uninstall the current one I > can then jump > back to any of them. If only there was a clear > relationship between > the > version number there and revisions in SVN ;-)
There is, as above: check plugin zip file name for your version in updateSite.oxygen, find date and time of build from that, then find out using svn or git what particular version of P5 or the Stylesheets was current at that time. I bet amount of time spent by everyone who has to do that manually (at 2 minutes a time) will be orders of magnitude smaller than the amount of time it would take me to erect some horribly-fragile process for the build script that attempts to determine it.
Cheers, Martin
> -James > >
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
On 04/02/15 17:59, Martin Holmes wrote:
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. [snip]
Ok, I take your point here. How about (for our development version only) we give the version as a dateTime? That way it will always be bigger, and make human-readable sense? Also doesn't matter then if the change is coming from github or svn. It would be the dateTime at the point the zip is made and then that copied into the update file. Make sense? -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
On 15-02-04 01:25 PM, James Cummings wrote:
On 04/02/15 17:59, Martin Holmes wrote:
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. [snip]
Ok, I take your point here. How about (for our development version only) we give the version as a dateTime? That way it will always be bigger, and make human-readable sense? Also doesn't matter then if the change is coming from github or svn. It would be the dateTime at the point the zip is made and then that copied into the update file. Make sense?
Certainly; I'll give it a try. I don't know what Oxygen will do with it, though; I don't know what kind of version numbers they're expecting. Cheers, Martin
-James
On 15-02-04 01:25 PM, James Cummings wrote:
On 04/02/15 17:59, Martin Holmes wrote:
The actual plugin download file name includes the date and time of the build:
<http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/>
but I take your point; if it wasn't for the inherent horribleness of github identifiers I'd agree. [snip]
Ok, I take your point here. How about (for our development version only) we give the version as a dateTime?
Sorry James, just tried this and it won't work; Oxygen will only accept proper integers for its build numbering in extensions: Invalid update site. Cause: cvc-pattern-valid: Value '2.7.2015-02-07-161046' is not facet-valid with respect to pattern '\d+\.\d+\.\d+' for type '#AnonType_versionextension'. So I'm reverting to the original system, but I'm adding the build datetime to the xt:desription element so you can see it when you're installing. Cheers, Martin
That way it will always be bigger, and make human-readable sense? Also doesn't matter then if the change is coming from github or svn. It would be the dateTime at the point the zip is made and then that copied into the update file. Make sense?
-James
On 08/02/15 01:37, Martin Holmes wrote:
Sorry James, just tried this and it won't work; Oxygen will only accept proper integers for its build numbering in extensions:
Invalid update site. Cause: cvc-pattern-valid: Value '2.7.2015-02-07-161046' is not facet-valid with respect to pattern '\d+\.\d+\.\d+' for type '#AnonType_versionextension'.
Ah. I was assuming that you would do it as 2.7.20150207161046 without any extra punctuation.
So I'm reverting to the original system, but I'm adding the build datetime to the xt:desription element so you can see it when you're installing.
I'll test this when I get back to my desktop in Oxford (Weds) as that is the one that is subscribed to the jenkins version. ;-) -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
On 15-02-08 02:53 AM, James Cummings wrote:
On 08/02/15 01:37, Martin Holmes wrote:
Sorry James, just tried this and it won't work; Oxygen will only accept proper integers for its build numbering in extensions:
Invalid update site. Cause: cvc-pattern-valid: Value '2.7.2015-02-07-161046' is not facet-valid with respect to pattern '\d+\.\d+\.\d+' for type '#AnonType_versionextension'.
Ah. I was assuming that you would do it as 2.7.20150207161046 without any extra punctuation.
Could do, but actually if the objective is to see which one you have installed, the current approach is better; the Oxygen Manage Add-ons dialog shows the version number in a narrow column which would cut off anything after 2015, but the description shows below in a big text box.
So I'm reverting to the original system, but I'm adding the build datetime to the xt:desription element so you can see it when you're installing.
I'll test this when I get back to my desktop in Oxford (Weds) as that is the one that is subscribed to the jenkins version. ;-)
It's working for me. Cheers, Martin
-James
participants (5)
-
Fabio Ciotti -
James Cummings -
Lou Burnard -
Martin Holmes -
Raffaele Viglianti