Details
-
Type:
Task
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Story Points:1
-
Epic Link:
-
Sprint:Fall 6 : 28 Oct to 8 Nov, Fall 7 : 11 Nov to 22 Nov, Fall 8 : 25 Nov to 6 Dec
Description
When a user uploads a new App, it gets placed in the "pending apps" table in the database, which has a field "works_with".
This field is meant to contain a string indicating which version or version range of the IGB platform the App requires.
Currently, this value is being set to a default value of 9.1.0, the upcoming release of IGB.
Instead, this value should be set using the IGB platform version indicated in the App's repository.xml and MANIFEST.MF files. (App repository.xml and App MANIFEST.MF should contain the same information regarding imported dependencies.)
Potentially useful suggestions and comments:
- Seems like the repository.xml file would be much easier to parse because the data are more structured. Since we now require the repository.xml file to be included in the uploaded jar file, let's parse repository.xml to get the platform versions. Why not?
- For now, let's use the version syntax word-for-word as provided by the repository.xml file, e.g., [10.0.0,11.0.0) or whatever. We will report that to the user as-is. It's not very user-friendly, but I have a feeling biologists and users will "get" what it means. And later on we can come up with a more user-friendly format. For now, we just need to report the platform version to the user – and to us, for testing.
- We can use the repository.xml "require" tag with "name" equal to "package" to identify IGB platform dependencies.
Probably most packages that an IGB App can legally import from the platform has package structure of org.lorainelab.igb.*.
So we could maybe write a regex that would extract the version strings for every imported org.lorainelab.igb package used by an App.
We should look at all of them, and require that all such packages use the same version strings.
Attachments
Issue Links
- relates to
-
IGBF-1906 Make App's IGB dependencies more liberal
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Epic Link | IGBF-1388 [ 17463 ] |
| Rank | Ranked higher |
| Description |
When a user uploads a new App, it gets placed in the "pending apps" table int the database, which has a field "works_with".
This field is meant to contain a string indicating which version or version range of the IGB platform the App requires. Currently, this value is being set to a default value of 9.1.0, the upcoming release of IGB. Instead, this value should be set using the IGB platform version indicated in the App's repository.xml and MANIFEST.MF files. (App repository.xml and App MANIFEST.MF should contain the same information regarding imported dependencies.) Potentially useful suggestions: * Seems like the repository.xml file would be *much* easier to parse because the data are more structured. And you can use existing XML parsing tools. Since we now require the repository.xml file to be included in the uploaded jar file, let's parse repository.xml to get the platform versions. Why not? * For now, let's use the version syntax word-for-word as provided by the repository.xml file, e.g., [10.0.0,11.0.0) or whatever. We will report that to the user as-is. It's not very user-friendly, but I have a feeling biologists and users will "get" what it means. And later on we can come up with a more user-friendly format. For now, we just need to report the platform version to the user -- and to us, for testing. * You can use the repository.xml "require" tag with "name" equal to "package" to find the IGB platform dependencies. Probably (?) every package that an IGB App can legally import from the platform has package structure of org.lorainelab.igb.*, where "*" can be anything. So we could maybe write a regex that would extract the version strings for every imported org.lorainelab.igb package used by an App. We should look at all of them, and require that all such packages use the same version strings. |
When a user uploads a new App, it gets placed in the "pending apps" table int the database, which has a field "works_with".
This field is meant to contain a string indicating which version or version range of the IGB platform the App requires. Currently, this value is being set to a default value of 9.1.0, the upcoming release of IGB. Instead, this value should be set using the IGB platform version indicated in the App's repository.xml and MANIFEST.MF files. (App repository.xml and App MANIFEST.MF should contain the same information regarding imported dependencies.) Potentially useful suggestions: * Seems like the repository.xml file would be *much* easier to parse because the data are more structured. And you can use existing XML parsing tools. Since we now require the repository.xml file to be included in the uploaded jar file, let's parse repository.xml to get the platform versions. Why not? * For now, let's use the version syntax word-for-word as provided by the repository.xml file, e.g., [10.0.0,11.0.0) or whatever. We will report that to the user as-is. It's not very user-friendly, but I have a feeling biologists and users will "get" what it means. And later on we can come up with a more user-friendly format. For now, we just need to report the platform version to the user -- and to us, for testing. * You can use the repository.xml "require" tag with "name" equal to "package" to find the IGB platform dependencies. Probably every package that an IGB App can legally import from the platform has package structure of org.lorainelab.igb.*, where * is be anything. So we could maybe write a regex that would extract the version strings for every imported org.lorainelab.igb package used by an App. We should look at all of them, and require that all such packages use the same version strings. |
| Description |
When a user uploads a new App, it gets placed in the "pending apps" table int the database, which has a field "works_with".
This field is meant to contain a string indicating which version or version range of the IGB platform the App requires. Currently, this value is being set to a default value of 9.1.0, the upcoming release of IGB. Instead, this value should be set using the IGB platform version indicated in the App's repository.xml and MANIFEST.MF files. (App repository.xml and App MANIFEST.MF should contain the same information regarding imported dependencies.) Potentially useful suggestions: * Seems like the repository.xml file would be *much* easier to parse because the data are more structured. And you can use existing XML parsing tools. Since we now require the repository.xml file to be included in the uploaded jar file, let's parse repository.xml to get the platform versions. Why not? * For now, let's use the version syntax word-for-word as provided by the repository.xml file, e.g., [10.0.0,11.0.0) or whatever. We will report that to the user as-is. It's not very user-friendly, but I have a feeling biologists and users will "get" what it means. And later on we can come up with a more user-friendly format. For now, we just need to report the platform version to the user -- and to us, for testing. * You can use the repository.xml "require" tag with "name" equal to "package" to find the IGB platform dependencies. Probably every package that an IGB App can legally import from the platform has package structure of org.lorainelab.igb.*, where * is be anything. So we could maybe write a regex that would extract the version strings for every imported org.lorainelab.igb package used by an App. We should look at all of them, and require that all such packages use the same version strings. |
When a user uploads a new App, it gets placed in the "pending apps" table in the database, which has a field "works_with".
This field is meant to contain a string indicating which version or version range of the IGB platform the App requires. Currently, this value is being set to a default value of 9.1.0, the upcoming release of IGB. Instead, this value should be set using the IGB platform version indicated in the App's repository.xml and MANIFEST.MF files. (App repository.xml and App MANIFEST.MF should contain the same information regarding imported dependencies.) Potentially useful suggestions: * Seems like the repository.xml file would be *much* easier to parse because the data are more structured. Since we now require the repository.xml file to be included in the uploaded jar file, let's parse repository.xml to get the platform versions. Why not? * For now, let's use the version syntax word-for-word as provided by the repository.xml file, e.g., [10.0.0,11.0.0) or whatever. We will report that to the user as-is. It's not very user-friendly, but I have a feeling biologists and users will "get" what it means. And later on we can come up with a more user-friendly format. For now, we just need to report the platform version to the user -- and to us, for testing. * You can use the repository.xml "require" tag with "name" equal to "package" to find the IGB platform dependencies. Probably every package that an IGB App can legally import from the platform has package structure of org.lorainelab.igb.*, where * is be anything. So we could maybe write a regex that would extract the version strings for every imported org.lorainelab.igb package used by an App. We should look at all of them, and require that all such packages use the same version strings. |
| Description |
When a user uploads a new App, it gets placed in the "pending apps" table in the database, which has a field "works_with".
This field is meant to contain a string indicating which version or version range of the IGB platform the App requires. Currently, this value is being set to a default value of 9.1.0, the upcoming release of IGB. Instead, this value should be set using the IGB platform version indicated in the App's repository.xml and MANIFEST.MF files. (App repository.xml and App MANIFEST.MF should contain the same information regarding imported dependencies.) Potentially useful suggestions: * Seems like the repository.xml file would be *much* easier to parse because the data are more structured. Since we now require the repository.xml file to be included in the uploaded jar file, let's parse repository.xml to get the platform versions. Why not? * For now, let's use the version syntax word-for-word as provided by the repository.xml file, e.g., [10.0.0,11.0.0) or whatever. We will report that to the user as-is. It's not very user-friendly, but I have a feeling biologists and users will "get" what it means. And later on we can come up with a more user-friendly format. For now, we just need to report the platform version to the user -- and to us, for testing. * You can use the repository.xml "require" tag with "name" equal to "package" to find the IGB platform dependencies. Probably every package that an IGB App can legally import from the platform has package structure of org.lorainelab.igb.*, where * is be anything. So we could maybe write a regex that would extract the version strings for every imported org.lorainelab.igb package used by an App. We should look at all of them, and require that all such packages use the same version strings. |
When a user uploads a new App, it gets placed in the "pending apps" table in the database, which has a field "works_with".
This field is meant to contain a string indicating which version or version range of the IGB platform the App requires. Currently, this value is being set to a default value of 9.1.0, the upcoming release of IGB. Instead, this value should be set using the IGB platform version indicated in the App's repository.xml and MANIFEST.MF files. (App repository.xml and App MANIFEST.MF should contain the same information regarding imported dependencies.) Potentially useful suggestions: * Seems like the repository.xml file would be *much* easier to parse because the data are more structured. Since we now require the repository.xml file to be included in the uploaded jar file, let's parse repository.xml to get the platform versions. Why not? * For now, let's use the version syntax word-for-word as provided by the repository.xml file, e.g., [10.0.0,11.0.0) or whatever. We will report that to the user as-is. It's not very user-friendly, but I have a feeling biologists and users will "get" what it means. And later on we can come up with a more user-friendly format. For now, we just need to report the platform version to the user -- and to us, for testing. * We can use the repository.xml "require" tag with "name" equal to "package" to identify IGB platform dependencies. Probably every package that an IGB App can legally import from the platform has package structure of org.lorainelab.igb.*. So we could maybe write a regex that would extract the version strings for every imported org.lorainelab.igb package used by an App. We should look at all of them, and require that all such packages use the same version strings. |
| Description |
When a user uploads a new App, it gets placed in the "pending apps" table in the database, which has a field "works_with".
This field is meant to contain a string indicating which version or version range of the IGB platform the App requires. Currently, this value is being set to a default value of 9.1.0, the upcoming release of IGB. Instead, this value should be set using the IGB platform version indicated in the App's repository.xml and MANIFEST.MF files. (App repository.xml and App MANIFEST.MF should contain the same information regarding imported dependencies.) Potentially useful suggestions: * Seems like the repository.xml file would be *much* easier to parse because the data are more structured. Since we now require the repository.xml file to be included in the uploaded jar file, let's parse repository.xml to get the platform versions. Why not? * For now, let's use the version syntax word-for-word as provided by the repository.xml file, e.g., [10.0.0,11.0.0) or whatever. We will report that to the user as-is. It's not very user-friendly, but I have a feeling biologists and users will "get" what it means. And later on we can come up with a more user-friendly format. For now, we just need to report the platform version to the user -- and to us, for testing. * We can use the repository.xml "require" tag with "name" equal to "package" to identify IGB platform dependencies. Probably every package that an IGB App can legally import from the platform has package structure of org.lorainelab.igb.*. So we could maybe write a regex that would extract the version strings for every imported org.lorainelab.igb package used by an App. We should look at all of them, and require that all such packages use the same version strings. |
When a user uploads a new App, it gets placed in the "pending apps" table in the database, which has a field "works_with".
This field is meant to contain a string indicating which version or version range of the IGB platform the App requires. Currently, this value is being set to a default value of 9.1.0, the upcoming release of IGB. Instead, this value should be set using the IGB platform version indicated in the App's repository.xml and MANIFEST.MF files. (App repository.xml and App MANIFEST.MF should contain the same information regarding imported dependencies.) Potentially useful suggestions and comments: * Seems like the repository.xml file would be *much* easier to parse because the data are more structured. Since we now require the repository.xml file to be included in the uploaded jar file, let's parse repository.xml to get the platform versions. Why not? * For now, let's use the version syntax word-for-word as provided by the repository.xml file, e.g., [10.0.0,11.0.0) or whatever. We will report that to the user as-is. It's not very user-friendly, but I have a feeling biologists and users will "get" what it means. And later on we can come up with a more user-friendly format. For now, we just need to report the platform version to the user -- and to us, for testing. * We can use the repository.xml "require" tag with "name" equal to "package" to identify IGB platform dependencies. Probably most packages that an IGB App can legally import from the platform has package structure of org.lorainelab.igb.*. So we could maybe write a regex that would extract the version strings for every imported org.lorainelab.igb package used by an App. We should look at all of them, and require that all such packages use the same version strings. |
| Assignee | Noor Zahara [ noor91zahara ] |
| Status | To-Do [ 10305 ] | In Progress [ 3 ] |
| Attachment | Screen Shot 2019-11-04 at 2.16.23 PM.png [ 14479 ] |
| Attachment | Screen Shot 2019-11-06 at 1.55.23 PM.png [ 14481 ] | |
| Attachment | Screen Shot 2019-11-06 at 1.55.15 PM.png [ 14482 ] |
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Status | First Level Review in Progress [ 10301 ] | Needs 1st Level Review [ 10005 ] |
| Assignee | Noor Zahara [ noor91zahara ] |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Status | First Level Review in Progress [ 10301 ] | To-Do [ 10305 ] |
| Assignee | Noor Zahara [ noor91zahara ] |
| Link | This issue blocks IGBF-2109 [ IGBF-2109 ] |
| Status | To-Do [ 10305 ] | In Progress [ 3 ] |
| Link | This issue blocks IGBF-2110 [ IGBF-2110 ] |
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
| Assignee | Noor Zahara [ noor91zahara ] |
| Sprint | Fall 6 : 28 Oct to 8 Nov [ 77 ] | Fall 6 : 28 Oct to 8 Nov, Fall 7 : 11 Nov to 22 Nov [ 77, 78 ] |
| Rank | Ranked higher |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Status | First Level Review in Progress [ 10301 ] | Ready for Pull Request [ 10304 ] |
| Status | Ready for Pull Request [ 10304 ] | Pull Request Submitted [ 10101 ] |
| Status | Pull Request Submitted [ 10101 ] | Reviewing Pull Request [ 10303 ] |
| Status | Reviewing Pull Request [ 10303 ] | Merged Needs Testing [ 10002 ] |
| Assignee | Shamika Gajanan Kulkarni [ shamika ] |
| Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
| Status | Post-merge Testing In Progress [ 10003 ] | Merged Needs Testing [ 10002 ] |
| Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
| Status | Post-merge Testing In Progress [ 10003 ] | Merged Needs Testing [ 10002 ] |
| Assignee | Shamika Gajanan Kulkarni [ shamika ] |
| Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
| Status | Post-merge Testing In Progress [ 10003 ] | To-Do [ 10305 ] |
| Status | To-Do [ 10305 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Status | First Level Review in Progress [ 10301 ] | Ready for Pull Request [ 10304 ] |
| Status | Ready for Pull Request [ 10304 ] | Pull Request Submitted [ 10101 ] |
| Status | Pull Request Submitted [ 10101 ] | Reviewing Pull Request [ 10303 ] |
| Status | Reviewing Pull Request [ 10303 ] | Merged Needs Testing [ 10002 ] |
| Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
| Status | Post-merge Testing In Progress [ 10003 ] | Merged Needs Testing [ 10002 ] |
| Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
| Status | Post-merge Testing In Progress [ 10003 ] | To-Do [ 10305 ] |
| Status | To-Do [ 10305 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Status | First Level Review in Progress [ 10301 ] | To-Do [ 10305 ] |
| Assignee | Noor Zahara [ noor91zahara ] |
| Status | To-Do [ 10305 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
| Assignee | Noor Zahara [ noor91zahara ] | Ann Loraine [ aloraine ] |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Assignee | Ann Loraine [ aloraine ] | Noor Zahara [ noor91zahara ] |
| Status | First Level Review in Progress [ 10301 ] | To-Do [ 10305 ] |
| Status | To-Do [ 10305 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
| Assignee | Noor Zahara [ noor91zahara ] |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Status | First Level Review in Progress [ 10301 ] | Ready for Pull Request [ 10304 ] |
| Assignee | Noor Zahara [ noor91zahara ] |
| Status | Ready for Pull Request [ 10304 ] | Pull Request Submitted [ 10101 ] |
| Assignee | Noor Zahara [ noor91zahara ] |
| Status | Pull Request Submitted [ 10101 ] | Reviewing Pull Request [ 10303 ] |
| Status | Reviewing Pull Request [ 10303 ] | Merged Needs Testing [ 10002 ] |
| Sprint | Fall 6 : 28 Oct to 8 Nov, Fall 7 : 11 Nov to 22 Nov [ 77, 78 ] | Fall 6 : 28 Oct to 8 Nov, Fall 7 : 11 Nov to 22 Nov, Fall 8 : 25 Nov to 6 Dec [ 77, 78, 79 ] |
| Rank | Ranked higher |
| Assignee | Prutha Kulkarni [ prutha ] |
| Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
| Assignee | Prutha Kulkarni [ prutha ] | Noor Zahara [ noor91zahara ] |
| Resolution | Done [ 10000 ] | |
| Status | Post-merge Testing In Progress [ 10003 ] | Closed [ 6 ] |