PTCInc / thingworx-gitbackup-extension

[Unofficial/Not supported] ThingWorx GitBackup Extension for storing your ThingWorx application code in a Git repository
MIT License
25 stars 11 forks source link

Invalid service name: ExportProjectEntities #6

Closed TG-JC closed 3 years ago

TG-JC commented 3 years ago

Exporting projects fails. In the UI, the export button shows the "please wait" animation forever. image

In Application logs, there are two failures regarding two missing services image

Thingworx version: ThingWorx 9.0.1-b103 Extension version: 4.0.1

Using Bitbucket Cloud. login/password verification passed. It was able to list repositories.

vrosu commented 3 years ago

I believe that you may have installed the 8.4/8.5 Extension package. Download the 9.0 specific release. Background info: the failing service belongs to a ThingShape (Git.Utility.ThingShape) that is assigned during one of the lifecycle methods in the Java extension. In 9.0 the signature of those methods changed, and the effect you see if you run the 8.x version is that the lifecycle method is no longer executed by the VM, which in turn causes the ThingShape not to be assigned to your GitBackup Thing.

stefan-lacatus commented 3 years ago

Small advice here, since i encountered this exact problem right now.

In GitHub, I'm used to going to https://github.com/PTCInc/thingworx-gitbackup-extension/releases/latest, or clicking on the release present on the left sidebar on the main page of the repo (that is a direct link to the latest release).

Because there are two separate releases, one for 8.4/8.5 and another for TWX 9, i ended up grabbing the latest (8.5), installing it into TWX 9, and wondering why it doesn't work.

For the future, it may be useful to have only one release, with multiple "assets" (one for twx9, another for older versions).

vrosu commented 3 years ago

I know, it is not ideal in the way those release links are displayed at the moment. The main reason I split them in two parallel releases was to force the user to be aware of the version that he is downloading because he would see the version number in the release title. Obviously, this process is not very effective.

There are some issues that stop me releasing a single package: -the source code attached to each release is the one that belongs to that branch, to have a 1:1 parity between release and source code. There is a new branch now, for 9.0 -if the user has two extension zip files, he/she could still be confused on which to choose for import (as you generally know that extensions working in lower versions work in higher versions). The big issue is the load of 8.x compatible extension in a 9.0 ThingWorx instance because in this case the extension metadata does not enforce a maximum version, just a minimum one.

I'm in favor of doing the following: -adding a note and link to the other version in each release (along the lines "if you are using ThingWorx version x.y, please download this release") -adding inside the description in the metadata.xml a comment similar to "Not for use in ThingWorx version x.y" -enforcing a minimum version in the 9.0 branch

I'm open for other suggestions ;)

stefan-lacatus commented 3 years ago

I understand your point now. Having separate releases would be fine, but your two suggestions of adding a note in the metadata and enforcing a minimum version would be good.

Additionally, looking at the code, it looks to me that there is no need for two branches. You should be able to have the initializeThing and stopThing method declared with both the ContextType param and without, and have the runtime implementation deal with calling the right method.

I can help out with this with a PR next week.

vrosu commented 3 years ago

I was also thinking about that, but then I'm only compiling against a single SDK version, which means the compilation would not be successful when I have the same method with two signatures. The method signature in the 9.0 was completely replaced (nut just an overload). I was thinking of adding manually both libraries (for 9.0 and 8.5) to make the compilation successful, but it was not that high of a priority at the moment.

vrosu commented 3 years ago

And wait with the PR, because today I will release a new version :)

TG-JC commented 3 years ago

I confirm I was using extension for 8.x. When I saw "8.4/8.5" in the title, I assumed it was upward compatible. I suggest that "latest" tag be used for version 4.0.1-9.0. In this case, people using 8.x series would wonder "where is 8.x version" and search in other releases.

By the way, I tried the 9.0 version yesterday, and I had the same issue. I will try again now with your latest release.

vrosu commented 3 years ago

Thanks - make sure to remove the old extension (deleting the created Things), restart the server, and then import the new version, create the things and try again. Check if in the newly created Git Things have that Git.Utility.ThingShape, that is the "trigger" that all works good. Just to be clear, it should work with 4.0.1, no need to wait for the new version.

TG-JC commented 3 years ago

Hi Vladimir, It works indeed better when server is restarted after extension removal.

vrosu commented 3 years ago

@stefan-lacatus 4.1.0 version is released

TG-JC commented 3 years ago

Installed successfully and working OK. Please note that GitRepository is coming in with smartparking. I removed it manually. image

vrosu commented 3 years ago

Weird. I'm opening a bug and mentioning you there.