Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export/Import v2 #356

Closed
tomas-knap opened this issue Apr 13, 2015 · 5 comments
Closed

Export/Import v2 #356

tomas-knap opened this issue Apr 13, 2015 · 5 comments

Comments

@tomas-knap
Copy link

Goal:
User needs to be able to import exported pipelines even on systems which have newer versions of Core, API (DevEnv) or DPUs. But not vice versa.

In other words:
It should be possible to import pipeline using older version of DPU then the version of the DPU being available on the target system

Details:
https://team.eea.sk/wiki/pages/viewpage.action?pageId=113837857

User stories 81 - 85
sto_82v1: Import pipeline from zip file containing no DPU JARs

* Time needed to be solved: 3-5 MD*

Further constraints regarding export/import and same names of DPU templates:

  1. When importing 3rd level DPU template, if the 3rd level DPU with the same name and same JAR file/parent already exists, the import of the DPU template will fail. If there is 3rd level DPU template with a different parent, there is no problem.
  2. When importing 2nd level DPU template, if the DPU template with the same name exists, the import will fail
  3. When importing 2nd level DPU template, if the DPU template with the same artifactID exists, the import will fail (so it is not possible to have two 2nd level DPU templates with different name but pointing to the same JAR file. Also it is not possible to have two 2nd level DPU templates with the different name but pointing to the same artifact, but different versions) (Motivation: currently, DPU JAR files are stored on the filesystem using artifactID/jar name, so allowing two different DPU templates pointing to the same JAR would be confusing when updating versions)
  4. I can create two 3rd level DPU templates with the same name. I can do that, but it is not a wise decision. (Better approach would be to enforce unique names of 3rd level DPU templates within one 2nd level DPU template, but not needed now)

Current behavior is as follows:

  1. holds, 2) has to be verified. 3) has to be verified, 4) holds
@tomas-knap
Copy link
Author

Related: #196
Related: #177

@jindrichmynarz
Copy link

I'm trying to import a pipeline that uses uv-t-filesToRdf-1.6.0.jar. The UV instance into that I'm importing the pipeline provides uv-t-filesToRdf-2.0.1.jar. Based on our prior conversation with @tomas-knap, I'd assume that uv-t-filesToRdf-2.0.1.jar should be able to handle configuration from uv-t-filesToRdf-1.6.0.jar. However, that is not the case. If I try to import this pipeline the uv-t-filesToRdf-1.6.0.jar is shown in the list of the "DPUs which are missing in system. Install them before import".

I'm using UV 2.0.2 installed via 1.0.1 version of the odn-simple Debian package.

@tomas-knap
Copy link
Author

@skrchnavy We should solve this issues and related issues in release 2.2.0, because if we do not solve it, it will cause lots of troubles in the future when migrating from one instance to another

@tomas-knap
Copy link
Author

@jindrichmynarz Lets wait for solution of this issue, then we can test

mvi-eea-sk added a commit that referenced this issue Sep 2, 2015
forgot to commit some changes
mvi-eea-sk added a commit that referenced this issue Sep 2, 2015
fix: pipeline.xml doesn't export jarDirectory in template
mvi-eea-sk added a commit that referenced this issue Sep 2, 2015
…ces that use the configuration of its template

In system the pipeline is imported to, DPU template with matching name was found, but they have different configuration. Two different import strategies are available:
1. to use the DPU template of the system it is imported to and lose the original configuration (the pipeline may not work the way as in the original system)
2. to replace the DPU instance configuration so it will work exactly as in the system it is imported from
@tomas-knap
Copy link
Author

I think #521 meets this only partially. Will check what is addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants