search

zazuko / xrm

A friendly language for mappings to RDF
MIT License
1 stars 0 forks source link

Eclipse Update Site #13

Closed mchlrch closed 4 years ago

mchlrch commented 5 years ago

The "New Xtext Project" wizard created a couple of modules for providing an update site. Need to have a look and check what's missing.

com.zazuko.rdfmapping.dsl.feature com.zazuko.rdfmapping.dsl.repository

Also, we need to document installation instructions for users.

Another thing to consider is that we will likely have breaking changes in the DSL sooner or later. How can we enable the user to choose when to update? Do we need to maintain multiple versions on the update site?

nicky508 commented 5 years ago

The update site is mainly about the repository and the feature repositories. Within the feature repository the feature.xml is important and from the repository the category.xml is necessary. I played around and for now I created a Zazuko category with the RdfMapping DSL. When the plugin is exported and used as a local repository under the install new software option, one sees the Zazuko category with the plugin and I was able to install it successfully. Later on, I guess it should be put under a url resource I guess. I will write a install instruction for the DSL plugin based on the update site.

nicky508 commented 5 years ago

Something to be aware of: Eclipse is caching heavily. So, when a change has been made, it will cost some effort to make it work. Thinks which help: restarting eclipse, exporting the plugin multiple times and reloading the install repository (in eclipse install new software)

nicky508 commented 5 years ago

Another thing to consider is that we will likely have breaking changes in the DSL sooner or later. How can we enable the user to choose when to update? Do we need to maintain multiple versions on the update site?

I think it is now problem to have different versions within the update site. It will be up to the user to decide whether he will use a newer version and the need to change his already created mapping because of some DSL change. Or keep with the current version, because it will satisfy his needs and no need for changes?

It is also fairly easy to create a separate project for a update site. Which looks like the category.xml from the project. In this site categories could be added and the plugins could be added.

mchlrch commented 5 years ago

Nice. I saw that additional repositories can be added in category.xml. If the Xtext updatesite is added there, then I think installation of the RdfMapping DSL would be possible into a bare Eclipse that doesn't have the Xtext features installed yet. Could you try that out?

nicky508 commented 5 years ago

It works. I added the Xtext repository. Faced some errors, since the eclipse version I use normally is way to old (mars). This means that when I use a clean install without Xtext (downloaded the newest plain version) and installed the plugin as instructed in the readme. It automatically finds the Xtext and makes it work.

After installing create project from tab general. Add a file with extension .xrm and do the DSL stuff. After saving, eclipse asks, whether it is a Xtext project. A src-gen folder is created with the rml and r2rml files.

mchlrch commented 5 years ago

@nicky508 I saw that you described the process for exporting the updatesite in the README. Goal would be to have this as automated as possible. Did you try running the maven builds too? If the updatesite can be built with maven, then this would be the preferrable way and the README should be adjusted accordingly.

mchlrch commented 5 years ago

Right now, plugin and feature have version 1.0.0. This is fine for me, what do you think @ktk?

mchlrch commented 5 years ago

@nicky508 I changed the vendor info in the plugins from My Company to zazuko.com

ktk commented 5 years ago

@mchlrch my idea was to use something below 1.0. we could do 0.9 for example. My concern is that we might break the syntax after we get issue #12 fixed.

But I'm not completely against it, we can also say the first "real" release will be 2.x with issue #12

ktk commented 5 years ago

Could we put the generated code somewhere so I can try installing it?

nicky508 commented 5 years ago

I changed the version to 0.9.0 to prevent maven from giving errors about being out of sync in versioning. The version number should not only be changed in the feature.xml but also in the manifest files of the different repositories.

nicky508 commented 5 years ago

Could we put the generated code somewhere so I can try installing it?

If I am correct with the new install/build instructions it should also work on your side. Would be nice if you could try (are the instructions clear enough)?

ktk commented 5 years ago

@nicky508 it's more that I am at the customer and don't have the time for that :-D

nicky508 commented 5 years ago

Let`s give it a shot

Created a temp link with the plugin: https://cloudbox.netage.nl/f/d785975925/?dl=1 Extract and follow from step two: https://github.com/zazuko/rdf-mapping-dsl/tree/13_update_site

nicky508 commented 5 years ago

@nicky508 I saw that you described the process for exporting the updatesite in the README. Goal would be to have this as automated as possible. Did you try running the maven builds too? If the updatesite can be built with maven, then this would be the preferrable way and the README should be adjusted accordingly.

It basically works with maven now. So only mvn clean install is necessary, in the repository map -> target the plugin is stored and one is able to install it in a fresh eclipse.

mchlrch commented 5 years ago

I investigated a bit in how to keep multiple versions on the update site. This can be done with a composite repository. This post has some good information about that (especially the goals described in the proposed directory structure).

I tried a less elaborate approach. Resulting in multiple versions available for installation : image

In this case, the composite repository is basically two additional XML files, pointing to the simple P2 snapshot folders that are built from with the _.respository module:

mira@blinky:~/updatesite-test2$ tree
.
├── 0.9.0
│   ├── artifacts.jar
│   ├── artifacts.xml.xz
│   ├── content.jar
│   ├── content.xml.xz
│   ├── features
│   │   └── com.zazuko.rdfmapping.dsl.feature_0.9.0.201907301322.jar
│   ├── p2.index
│   └── plugins
│       ├── com.zazuko.rdfmapping.dsl_0.9.0.201907301322.jar
│       ├── com.zazuko.rdfmapping.dsl.ide_0.9.0.201907301322.jar
│       └── com.zazuko.rdfmapping.dsl.ui_0.9.0.201907301322.jar
├── 1.0.0
│   ├── artifacts.jar
│   ├── artifacts.xml.xz
│   ├── content.jar
│   ├── content.xml.xz
│   ├── features
│   │   └── com.zazuko.rdfmapping.dsl.feature_1.0.0.201907301431.jar
│   ├── p2.index
│   └── plugins
│       ├── com.zazuko.rdfmapping.dsl_1.0.0.201907301431.jar
│       ├── com.zazuko.rdfmapping.dsl.ide_1.0.0.201907301431.jar
│       └── com.zazuko.rdfmapping.dsl.ui_1.0.0.201907301431.jar
├── compositeArtifacts.xml
└── compositeContent.xml

mira@blinky:~/updatesite-test2$ cat compositeArtifacts.xml
<?xml version='1.0' encoding='UTF-8'?>
<?compositeArtifactRepository version='1.0.0'?>
<repository name='Zazuko'
    type='org.eclipse.equinox.internal.p2.artifact.repository.CompositeArtifactRepository' version='1.0.0'>
  <properties size='1'>
    <property name='p2.timestamp' value='1243822502442'/>
  </properties>
  <children size='2'>
    <child location='0.9.0'/>
    <child location='1.0.0'/>
  </children>
</repository>

mira@blinky:~/updatesite-test2$ cat compositeContent.xml 
<?xml version='1.0' encoding='UTF-8'?>
<?compositeMetadataRepository version='1.0.0'?>
<repository name='Zazuko'
    type='org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository' version='1.0.0'>
  <properties size='1'>
    <property name='p2.timestamp' value='1243822502501'/>
  </properties>
  <children size='2'>
    <child location='0.9.0'/>
    <child location='1.0.0'/>
  </children>
</repository>

I think it makes sense to update the composite XMLs manually for now. This gives us some of the flexibility described in the blog post mentioned above.

@nicky508 Did you encounter other options for publishing multiple versions concurrently?

mchlrch commented 5 years ago

I changed the version to 0.9.0 to prevent maven from giving errors about being out of sync in versioning. The version number should not only be changed in the feature.xml but also in the manifest files of the different repositories.

There is a plugin that makes this easier. tycho-versions-plugin takes care of updating all the necessary files. I will also document this in the README

mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=1.0.1-SNAPSHOT
nicky508 commented 5 years ago

I investigated a bit in how to keep multiple versions on the update site. This can be done with a composite repository. This post has some good information about that (especially the goals described in the proposed directory structure).

I tried a less elaborate approach. Resulting in multiple versions available for installation : image

In this case, the composite repository is basically two additional XML files, pointing to the simple P2 snapshot folders that are built from with the _.respository module:

mira@blinky:~/updatesite-test2$ tree
.
├── 0.9.0
│   ├── artifacts.jar
│   ├── artifacts.xml.xz
│   ├── content.jar
│   ├── content.xml.xz
│   ├── features
│   │   └── com.zazuko.rdfmapping.dsl.feature_0.9.0.201907301322.jar
│   ├── p2.index
│   └── plugins
│       ├── com.zazuko.rdfmapping.dsl_0.9.0.201907301322.jar
│       ├── com.zazuko.rdfmapping.dsl.ide_0.9.0.201907301322.jar
│       └── com.zazuko.rdfmapping.dsl.ui_0.9.0.201907301322.jar
├── 1.0.0
│   ├── artifacts.jar
│   ├── artifacts.xml.xz
│   ├── content.jar
│   ├── content.xml.xz
│   ├── features
│   │   └── com.zazuko.rdfmapping.dsl.feature_1.0.0.201907301431.jar
│   ├── p2.index
│   └── plugins
│       ├── com.zazuko.rdfmapping.dsl_1.0.0.201907301431.jar
│       ├── com.zazuko.rdfmapping.dsl.ide_1.0.0.201907301431.jar
│       └── com.zazuko.rdfmapping.dsl.ui_1.0.0.201907301431.jar
├── compositeArtifacts.xml
└── compositeContent.xml

mira@blinky:~/updatesite-test2$ cat compositeArtifacts.xml
<?xml version='1.0' encoding='UTF-8'?>
<?compositeArtifactRepository version='1.0.0'?>
<repository name='Zazuko'
    type='org.eclipse.equinox.internal.p2.artifact.repository.CompositeArtifactRepository' version='1.0.0'>
  <properties size='1'>
    <property name='p2.timestamp' value='1243822502442'/>
  </properties>
  <children size='2'>
    <child location='0.9.0'/>
    <child location='1.0.0'/>
  </children>
</repository>

mira@blinky:~/updatesite-test2$ cat compositeContent.xml 
<?xml version='1.0' encoding='UTF-8'?>
<?compositeMetadataRepository version='1.0.0'?>
<repository name='Zazuko'
    type='org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository' version='1.0.0'>
  <properties size='1'>
    <property name='p2.timestamp' value='1243822502501'/>
  </properties>
  <children size='2'>
    <child location='0.9.0'/>
    <child location='1.0.0'/>
  </children>
</repository>

I think it makes sense to update the composite XMLs manually for now. This gives us some of the flexibility described in the blog post mentioned above.

@nicky508 Did you encounter other options for publishing multiple versions concurrently? The only other way I found was, creating a update site project which will also provide some webpage like frontend, in which you could add different plugins. But it is not handling the versions like just other plugins.

mchlrch commented 5 years ago

The changes from branch origin/13_update_site are in master now, in the consolidated commit 54d2e402f26064829acb02960c234f73f3994478

I did a mixed reset starting on commit 17df3383a769864a2a4a9294e1b48265d9cf58fd (branch origin/13_update_site) down to commit 40bc9634c0aa57ebad5815c3c731cd2fef2a66a6 and dropped the changes not belonging to the update-site.

Any further changes should be based off master and branch origin/13_update_site should be abandoned.

mchlrch commented 4 years ago

This got resolved a while ago already. Closing now