Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Story Points:2
-
Epic Link:
-
Sprint:Fall 2019 Sprint 2, Fall 2019 Sprint 3
Description
The IGB App recommended build pipeline creates MANIFEST.MF file with the attributes:
- Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App"
- Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator
- Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro)
Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve.
However, we need some way to create predictable paths to files and Apps.
Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store.
Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users.
For example, storage page for released apps should look like:
- /media/[Bundle-SymbolicName]/releases/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar
New URLs for Apps should look like:
[domain]/apps/[Bundle-SymbolicName]
In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean.
Attachments
Issue Links
Activity
| Field | Original Value | New Value |
|---|---|---|
| Epic Link | IGBF-1388 [ 17463 ] |
| Rank | Ranked higher |
| Description |
The IGB App recommended build pipeline creates MANIFEST.mf file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems, such as making it difficulty to change the human-friendly title of an App after it has been accepted. Anything user-facing ought to be easy to change and improve. However, we need some way to create paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi already to distinguish and resolve bundles. We should do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. New storage paths: pending apps: * /media/pending_releases/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar released apps: */media/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar Address 3) by placing uploaded logo images and screenshot images into the same subdirectory as the App they refer to. When new App releases are made, the App developer will upload new image files for their new released App version. For this task, modify App Store so that it no longer is using Bundle-Name for anything other than showing the user the name of the App. In addition, modify model fields and variable names to make it more clear where they came from and what they mean. Some suggestions: * name - Bundle_Name * symbolicname - Bundle_SymbolicName * version - Bundle_Version |
The IGB App recommended build pipeline creates MANIFEST.mf file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve. However, we need some way to create predictable paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. In addition, let's change how Apps are stored and addressed. New storage paths: pending apps: * /media/pending_releases/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar released apps: */media/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar New URLs for Apps: [domain]/apps/[Bundle-SymbolicName] In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean. Some suggestions: * name - Bundle_Name * symbolicname - Bundle_SymbolicName * version - Bundle_Version |
| Summary | Use Bundle-SymbolicName for folder name | Stop using Bundle-Name |
| Sprint | Fall 2019 Sprint 2 [ 73 ] |
| Description |
The IGB App recommended build pipeline creates MANIFEST.mf file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve. However, we need some way to create predictable paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. In addition, let's change how Apps are stored and addressed. New storage paths: pending apps: * /media/pending_releases/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar released apps: */media/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar New URLs for Apps: [domain]/apps/[Bundle-SymbolicName] In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean. Some suggestions: * name - Bundle_Name * symbolicname - Bundle_SymbolicName * version - Bundle_Version |
The IGB App recommended build pipeline creates MANIFEST.mf file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve. However, we need some way to create predictable paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. In addition, let's change how Apps are stored and addressed. New storage paths: pending apps: * /media/pending_releases/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar released apps: * /media/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar New URLs for Apps: [domain]/apps/[Bundle-SymbolicName] In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean. Some suggestions: * name - Bundle_Name * symbolicname - Bundle_SymbolicName * version - Bundle_Version |
| Story Points | 0.5 | 2 |
| Description |
The IGB App recommended build pipeline creates MANIFEST.mf file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve. However, we need some way to create predictable paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. In addition, let's change how Apps are stored and addressed. New storage paths: pending apps: * /media/pending_releases/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar released apps: * /media/[Bundle-SymbolicName]/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar New URLs for Apps: [domain]/apps/[Bundle-SymbolicName] In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean. Some suggestions: * name - Bundle_Name * symbolicname - Bundle_SymbolicName * version - Bundle_Version |
The IGB App recommended build pipeline creates MANIFEST.MF file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve. However, we need some way to create predictable paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. In addition, let's change how Apps are stored and addressed. Storage paths: pending apps: * /media/pending_releases/[Bundle-SymbolicName]/ ... ?? ... /[Bundle-SymbolicName]-[version].jar released apps: * /media/[Bundle-SymbolicName]/releases/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar New URLs for Apps: [domain]/apps/[Bundle-SymbolicName] In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean. Some suggestions: * fullname - Bundle_Name * symbolicname - Bundle_SymbolicName * version - Bundle_Version This affects: releases, pending_releases, apps |
| Status | Open [ 1 ] | To-Do [ 10305 ] |
| Sprint | Fall 2019 Sprint 2 [ 73 ] | Fall 2019 Sprint 2, Fall 2019 Sprint 4 [ 73, 74 ] |
| Rank | Ranked higher |
| Rank | Ranked higher |
| Rank | Ranked higher |
| Sprint | Fall 2019 Sprint 2, Fall 2019 Sprint 3 [ 73, 74 ] | Fall 2019 Sprint 2, Fall 2019 Sprint 4 [ 73, 75 ] |
| Sprint | Fall 2019 Sprint 2, Fall 2019 Sprint 4 [ 73, 75 ] | Fall 2019 Sprint 2, Fall 2019 Sprint 3 [ 73, 74 ] |
| Rank | Ranked higher |
| Description |
The IGB App recommended build pipeline creates MANIFEST.MF file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve. However, we need some way to create predictable paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. In addition, let's change how Apps are stored and addressed. Storage paths: pending apps: * /media/pending_releases/[Bundle-SymbolicName]/ ... ?? ... /[Bundle-SymbolicName]-[version].jar released apps: * /media/[Bundle-SymbolicName]/releases/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar New URLs for Apps: [domain]/apps/[Bundle-SymbolicName] In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean. Some suggestions: * fullname - Bundle_Name * symbolicname - Bundle_SymbolicName * version - Bundle_Version This affects: releases, pending_releases, apps |
The IGB App recommended build pipeline creates MANIFEST.MF file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve. However, we need some way to create predictable paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. Storage paths: pending apps: * /media/pending_releases/[Bundle-SymbolicName]/ ... ?? ... /[Bundle-SymbolicName]-[version].jar released apps: * /media/[Bundle-SymbolicName]/releases/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar New URLs for Apps: [domain]/apps/[Bundle-SymbolicName] In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean. Some suggestions: * fullname - Bundle_Name * symbolicname - Bundle_SymbolicName * version - Bundle_Version This affects: releases, pending_releases, apps |
| Description |
The IGB App recommended build pipeline creates MANIFEST.MF file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve. However, we need some way to create predictable paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. Storage paths: pending apps: * /media/pending_releases/[Bundle-SymbolicName]/ ... ?? ... /[Bundle-SymbolicName]-[version].jar released apps: * /media/[Bundle-SymbolicName]/releases/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar New URLs for Apps: [domain]/apps/[Bundle-SymbolicName] In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean. Some suggestions: * fullname - Bundle_Name * symbolicname - Bundle_SymbolicName * version - Bundle_Version This affects: releases, pending_releases, apps |
The IGB App recommended build pipeline creates MANIFEST.MF file with the attributes:
* Bundle-Name - human-friendly, user-facing App title, e.g., "Merge Annotation Track Operator" or "ProtAnnot" or "My New App" * Bundle-SymbolicName - used by OSGi run-time, e.g., merge-annotation-track-operator * Bundle-Version - used by OGGi run-time. IGB Apps must use semantic versioning syntax, e.g., 10.1.10 (major.minor.micro) Currently, App Store is using Bundle-Name to build paths to files in S3 and URLs to Apps pages. This creates many problems. For example, this make it hard to change the human-friendly title of an App after it has been submitted. This is bad because anything user-facing ought to be easy to change and improve. However, we need some way to create predictable paths to files and Apps. Instead of using Bundle-Name to create paths, let's use Bundle-SymbolicName instead. This value, together with Bundle-Version, is already being used by OSGi to distinguish and resolve bundles. We can do the same in App Store. Let's re-factor the internal App Store infrastructure to no longer use Bundle-Name for anything other than provide user-friendly text to display to users. For example, storage page for released apps should look like: * /media/[Bundle-SymbolicName]/releases/[Bundle-Version]/[Bundle-SymbolicName]-[version].jar New URLs for Apps should look like: [domain]/apps/[Bundle-SymbolicName] In addition, let's modify model fields and variable names to make it more clear where they came from and what they mean. |
| Assignee | Riddhi Jagdish Patil [ rpatil14 ] |
| Status | To-Do [ 10305 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
| Assignee | Riddhi Jagdish Patil [ rpatil14 ] |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Assignee | Ann Loraine [ aloraine ] |
| Status | First Level Review in Progress [ 10301 ] | Ready for Pull Request [ 10304 ] |
| Assignee | Ann Loraine [ aloraine ] | Riddhi Jagdish Patil [ rpatil14 ] |
| 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 | Riddhi Jagdish Patil [ rpatil14 ] |
| Assignee | Riddhi Jagdish Patil [ rpatil14 ] |
| 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 ] |
| Assignee | Riddhi Jagdish Patil [ rpatil14 ] |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Assignee | Ann Loraine [ aloraine ] |
| Status | First Level Review in Progress [ 10301 ] | Ready for Pull Request [ 10304 ] |
| Assignee | Ann Loraine [ aloraine ] | Riddhi Jagdish Patil [ rpatil14 ] |
| Comment |
[ Reviewed code - it is fine.
Because [~rpatil14] has deployed the branch on https://dev-appstore-6.bioviz.org, I was able to test the new functionality using "Merge Annotation Track Operator" which is released on this App Store. Testing results: 1) Started IGB 9.1.0: * build from the master branch * latest commit id 2ca25bb18bcfac819e230df0800dbd4ca1bacab5 (most recent commit) 2) Added repository URL https://dev-appstore-6.bioviz.org/obr/releases/ to IGB 3) Visited https://dev-appstore-6.bioviz.org/apps/merge-annotation-operator The blue "Install" button was visible. 4) Clicked "Install" 5) Button changed to "Installing..." and also changed color (lighter shade of blue) but did not change after that 6) I opened IGB App Manager GUI and noted that the Merge Annotation Track Operator failed to install The code has been changing so quickly that I'm not sure if the failure to install is due to the above branch, however! I think we should go ahead and merge these changes and then investigate why installation from App Store is failing. Moving on to t ] |
| Status | Ready for Pull Request [ 10304 ] | Pull Request Submitted [ 10101 ] |
| Assignee | Riddhi Jagdish Patil [ rpatil14 ] |
| Status | Pull Request Submitted [ 10101 ] | Reviewing Pull Request [ 10303 ] |
| Status | Reviewing Pull Request [ 10303 ] | Merged Needs Testing [ 10002 ] |
| Assignee | Sai Charan Reddy Vallapureddy [ svallapu ] |
| Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
| Resolution | Done [ 10000 ] | |
| Status | Post-merge Testing In Progress [ 10003 ] | Closed [ 6 ] |
| Assignee | Sai Charan Reddy Vallapureddy [ svallapu ] | Riddhi Jagdish Patil [ rpatil14 ] |
| Workflow | Fall 2019 Workflow Update [ 20749 ] | Revised Fall 2019 Workflow Update [ 22498 ] |