Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-1949

Enable user-specified file as input for markdown encoder plugin

        Details

        • Type: New Feature
        • Status: Closed (View Workflow)
        • Priority: Major
        • Resolution: Done
        • Affects Version/s: None
        • Fix Version/s: None
        • Labels:

          Description

          David Norris wrote a simple maven plugin called "bundle markdown encoder," currently released in our legacy maven repository called "repo3".

          The "bundle markdown encoder" translates a file called "README.md" in a project's root directory into base64-encoding and writes the output to the bundle-description field in the resulting MANIFEST file. To see how this looks, download any of the IGB App jar files from their Bitbucket repos and look at their MANIFEST files. (Recall that an OSGi bundle is nothing but a jar file with some extra meta-data adde to the MANIFEST.)

          This base64-encoding of the README.md file enables App Store and also IGB itself to display the README.md file to users. In App Store the README.md appears on an App's page, where developers can log in and edit it. (Once an App is deployed on App Store, the App Store "takes over" responsibility for maintaining the README.md.) In IGB, the README.md appears in the App Manager GUI when a user selects the App. Both App Store and App Manager GUI can read and render markdown properly.

          However, sometimes we want to use this top-level README.md as a way to communicate to developers, not users. This is because bitbucket and github both display this top-level README.md file to users when they visit the home page for a git repository. Normally, this README file gets used to explain to developers how they can contribute to a project. Users probably don't want to see this.

          Solution:

          • Let's modify the plugin so that a developer can specify the markdown file they want to base64-encoded.

          Also, write up a detailed testing strategy so that testers who may not be super-familiar with maven can check that your code is working as expected. This will include explaining to them how to run your new plugin without it being deployed publicly. For example, they could build it on their local and run mvn install to copy it to their local .m2 maven repository. And of course, for this to work, you have to increment the version.

          Bitbucket repository for the base 64 markdown encoder plugin:

            Attachments

              Activity

              Ascending order - Click to sort in descending order
              ann.loraine Ann Loraine created issue -
              ann.loraine Ann Loraine made changes -
              Field Original Value New Value
              Epic Link IGBF-1531 [ 17617 ]
              ann.loraine Ann Loraine made changes -
              Link This issue blocks IGBF-1948 [ IGBF-1948 ]
              ann.loraine Ann Loraine made changes -
              Assignee Ann Loraine [ aloraine ]
              ann.loraine Ann Loraine made changes -
              Description David Norris wrote a simple maven plugin called "bundle markdown encoder," currently released in our legacy maven repository called "repo3".

              The "bundle markdown encoder" base-64 encodes whatever README.md file it finds in a project's root directory and writes the output to the bundle-description field in the resulting MANIFEST file. This enables App Store and also IGB itself to display the README.md file. In App Store the README.md appears on an App's page. In IGB it appears in the App Manager GUI when a user selects the App.

              However, sometimes we want to use the README.md as a way to communicate to developers, not users. This is because bitbucket and github both display this top-level README.md file to users when they visit the home page for a git repository.

              Let's modify the plugin so that a developer can specify which README.md file they want to get base64-encoded.

              I have a book on maven that covers writing custom plugins. Read the chapter on plugins before starting to make sure you will follow best practices when adding this new feature to the plugin.

              Also, write up a detailed testing strategy so that testers who may not be super-familiar with maven can check that your code is working as expected. This will include explaining to them how to run your new plugin without it being deployed publicly. For example, they will probably need to build it on their local and run mvn install to make sure it shows up in their local .m2 maven repository.

              Bitbucket repository for the base 64 markdown encoder plugin:

              * https://bitbucket.org/lorainelab/bundlemarkdownencoder/src/master/               		David Norris wrote a simple maven plugin called "bundle markdown encoder," currently released in our legacy maven repository called "repo3".

              The "bundle markdown encoder" base-64 converts file called "README.md" in a project's root directory into base64 and writes the output to the bundle-description field in the resulting MANIFEST file.

              This enables App Store and also IGB itself to display the README.md file. In App Store the README.md appears on an App's page. In IGB it appears in the App Manager GUI when a user selects the App.

              However, sometimes we want to use this top-level README.md as a way to communicate to developers, not users. This is because bitbucket and github both display this top-level README.md file to users when they visit the home page for a git repository.

              Let's modify the plugin so that a developer can specify the markdown file they want to base64-encoded.

              I have a book on maven that covers writing custom plugins. Read the chapter on plugins before starting this to make sure you will follow best practices when adding this new feature to the plugin.

              Also, write up a detailed testing strategy so that testers who may not be super-familiar with maven can check that your code is working as expected. This will include explaining to them how to run your new plugin without it being deployed publicly. For example, they will probably need to build it on their local and run mvn install to make sure it shows up in their local .m2 maven repository. And of course, for this to work, you have to increment the version.

              Bitbucket repository for the base 64 markdown encoder plugin:

              * https://bitbucket.org/lorainelab/bundlemarkdownencoder/src/master/
              ann.loraine Ann Loraine made changes -
              Description David Norris wrote a simple maven plugin called "bundle markdown encoder," currently released in our legacy maven repository called "repo3".

              The "bundle markdown encoder" base-64 converts file called "README.md" in a project's root directory into base64 and writes the output to the bundle-description field in the resulting MANIFEST file.

              This enables App Store and also IGB itself to display the README.md file. In App Store the README.md appears on an App's page. In IGB it appears in the App Manager GUI when a user selects the App.

              However, sometimes we want to use this top-level README.md as a way to communicate to developers, not users. This is because bitbucket and github both display this top-level README.md file to users when they visit the home page for a git repository.

              Let's modify the plugin so that a developer can specify the markdown file they want to base64-encoded.

              I have a book on maven that covers writing custom plugins. Read the chapter on plugins before starting this to make sure you will follow best practices when adding this new feature to the plugin.

              Also, write up a detailed testing strategy so that testers who may not be super-familiar with maven can check that your code is working as expected. This will include explaining to them how to run your new plugin without it being deployed publicly. For example, they will probably need to build it on their local and run mvn install to make sure it shows up in their local .m2 maven repository. And of course, for this to work, you have to increment the version.

              Bitbucket repository for the base 64 markdown encoder plugin:

              * https://bitbucket.org/lorainelab/bundlemarkdownencoder/src/master/               		David Norris wrote a simple maven plugin called "bundle markdown encoder," currently released in our legacy maven repository called "repo3".

              The "bundle markdown encoder" translates a file called "README.md" in a project's root directory into base64-encoding and writes the output to the bundle-description field in the resulting MANIFEST file.

              This enables App Store and also IGB itself to display the README.md file. In App Store the README.md appears on an App's page. In IGB it appears in the App Manager GUI when a user selects the App.

              However, sometimes we want to use this top-level README.md as a way to communicate to developers, not users. This is because bitbucket and github both display this top-level README.md file to users when they visit the home page for a git repository.

              Let's modify the plugin so that a developer can specify the markdown file they want to base64-encoded.

              I have a book on maven that covers writing custom plugins. Read the chapter on plugins before starting this to make sure you will follow best practices when adding this new feature to the plugin.

              Also, write up a detailed testing strategy so that testers who may not be super-familiar with maven can check that your code is working as expected. This will include explaining to them how to run your new plugin without it being deployed publicly. For example, they will probably need to build it on their local and run mvn install to make sure it shows up in their local .m2 maven repository. And of course, for this to work, you have to increment the version.

              Bitbucket repository for the base 64 markdown encoder plugin:

              * https://bitbucket.org/lorainelab/bundlemarkdownencoder/src/master/
              ann.loraine Ann Loraine made changes -
              Description David Norris wrote a simple maven plugin called "bundle markdown encoder," currently released in our legacy maven repository called "repo3".

              The "bundle markdown encoder" translates a file called "README.md" in a project's root directory into base64-encoding and writes the output to the bundle-description field in the resulting MANIFEST file.

              This enables App Store and also IGB itself to display the README.md file. In App Store the README.md appears on an App's page. In IGB it appears in the App Manager GUI when a user selects the App.

              However, sometimes we want to use this top-level README.md as a way to communicate to developers, not users. This is because bitbucket and github both display this top-level README.md file to users when they visit the home page for a git repository.

              Let's modify the plugin so that a developer can specify the markdown file they want to base64-encoded.

              I have a book on maven that covers writing custom plugins. Read the chapter on plugins before starting this to make sure you will follow best practices when adding this new feature to the plugin.

              Also, write up a detailed testing strategy so that testers who may not be super-familiar with maven can check that your code is working as expected. This will include explaining to them how to run your new plugin without it being deployed publicly. For example, they will probably need to build it on their local and run mvn install to make sure it shows up in their local .m2 maven repository. And of course, for this to work, you have to increment the version.

              Bitbucket repository for the base 64 markdown encoder plugin:

              * https://bitbucket.org/lorainelab/bundlemarkdownencoder/src/master/               		David Norris wrote a simple maven plugin called "bundle markdown encoder," currently released in our legacy maven repository called "repo3".

              The "bundle markdown encoder" translates a file called "README.md" in a project's root directory into base64-encoding and writes the output to the bundle-description field in the resulting MANIFEST file. To see how this looks, download any of the IGB App jar files from their Bitbucket repos and look at their MANIFEST files. (Recall that an OSGi bundle is nothing but a jar file with some extra meta-data adde to the MANIFEST.)

              This base64-encoding of the README.md file enables App Store and also IGB itself to display the README.md file to users. In App Store the README.md appears on an App's page, where developers can log in and edit it. (Once an App is deployed on App Store, the App Store "takes over" responsibility for maintaining the README.md.) In IGB, the README.md appears in the App Manager GUI when a user selects the App. Both App Store and App Manager GUI can read and render markdown properly.

              However, sometimes we want to use this top-level README.md as a way to communicate to developers, not users. This is because bitbucket and github both display this top-level README.md file to users when they visit the home page for a git repository. Normally, this README file gets used to explain to developers how they can contribute to a project. Users probably don't want to see this.

              Solution:

              * Let's modify the plugin so that a developer can specify the markdown file they want to base64-encoded.

              I have a book on maven that covers writing custom plugins. Read the chapter on plugins before starting this to make sure you will follow best practices when adding this new feature to the plugin.

              Also, write up a detailed testing strategy so that testers who may not be super-familiar with maven can check that your code is working as expected. This will include explaining to them how to run your new plugin without it being deployed publicly. For example, they could build it on their local and run mvn install to copy it to their local .m2 maven repository. And of course, for this to work, you have to increment the version.

              Bitbucket repository for the base 64 markdown encoder plugin:

              * https://bitbucket.org/lorainelab/bundlemarkdownencoder/src/master/
              ann.loraine Ann Loraine made changes -
              Story Points 3 4
              ann.loraine Ann Loraine made changes -
              Description David Norris wrote a simple maven plugin called "bundle markdown encoder," currently released in our legacy maven repository called "repo3".

              The "bundle markdown encoder" translates a file called "README.md" in a project's root directory into base64-encoding and writes the output to the bundle-description field in the resulting MANIFEST file. To see how this looks, download any of the IGB App jar files from their Bitbucket repos and look at their MANIFEST files. (Recall that an OSGi bundle is nothing but a jar file with some extra meta-data adde to the MANIFEST.)

              This base64-encoding of the README.md file enables App Store and also IGB itself to display the README.md file to users. In App Store the README.md appears on an App's page, where developers can log in and edit it. (Once an App is deployed on App Store, the App Store "takes over" responsibility for maintaining the README.md.) In IGB, the README.md appears in the App Manager GUI when a user selects the App. Both App Store and App Manager GUI can read and render markdown properly.

              However, sometimes we want to use this top-level README.md as a way to communicate to developers, not users. This is because bitbucket and github both display this top-level README.md file to users when they visit the home page for a git repository. Normally, this README file gets used to explain to developers how they can contribute to a project. Users probably don't want to see this.

              Solution:

              * Let's modify the plugin so that a developer can specify the markdown file they want to base64-encoded.

              I have a book on maven that covers writing custom plugins. Read the chapter on plugins before starting this to make sure you will follow best practices when adding this new feature to the plugin.

              Also, write up a detailed testing strategy so that testers who may not be super-familiar with maven can check that your code is working as expected. This will include explaining to them how to run your new plugin without it being deployed publicly. For example, they could build it on their local and run mvn install to copy it to their local .m2 maven repository. And of course, for this to work, you have to increment the version.

              Bitbucket repository for the base 64 markdown encoder plugin:

              * https://bitbucket.org/lorainelab/bundlemarkdownencoder/src/master/               		David Norris wrote a simple maven plugin called "bundle markdown encoder," currently released in our legacy maven repository called "repo3".

              The "bundle markdown encoder" translates a file called "README.md" in a project's root directory into base64-encoding and writes the output to the bundle-description field in the resulting MANIFEST file. To see how this looks, download any of the IGB App jar files from their Bitbucket repos and look at their MANIFEST files. (Recall that an OSGi bundle is nothing but a jar file with some extra meta-data adde to the MANIFEST.)

              This base64-encoding of the README.md file enables App Store and also IGB itself to display the README.md file to users. In App Store the README.md appears on an App's page, where developers can log in and edit it. (Once an App is deployed on App Store, the App Store "takes over" responsibility for maintaining the README.md.) In IGB, the README.md appears in the App Manager GUI when a user selects the App. Both App Store and App Manager GUI can read and render markdown properly.

              However, sometimes we want to use this top-level README.md as a way to communicate to developers, not users. This is because bitbucket and github both display this top-level README.md file to users when they visit the home page for a git repository. Normally, this README file gets used to explain to developers how they can contribute to a project. Users probably don't want to see this.

              Solution:

              * Let's modify the plugin so that a developer can specify the markdown file they want to base64-encoded.

              Also, write up a detailed testing strategy so that testers who may not be super-familiar with maven can check that your code is working as expected. This will include explaining to them how to run your new plugin without it being deployed publicly. For example, they could build it on their local and run mvn install to copy it to their local .m2 maven repository. And of course, for this to work, you have to increment the version.

              Bitbucket repository for the base 64 markdown encoder plugin:

              * https://bitbucket.org/lorainelab/bundlemarkdownencoder/src/master/
              prutha Prutha Kulkarni (Inactive) made changes -
              Assignee Prutha Kulkarni [ prutha ]
              prutha Prutha Kulkarni (Inactive) made changes -
              Status Open [ 1 ] In Progress [ 3 ]
              prutha Prutha Kulkarni (Inactive) made changes -
              Assignee Prutha Kulkarni [ prutha ]
              prutha Prutha Kulkarni (Inactive) made changes -
              Status In Progress [ 3 ] Needs 1st Level Review [ 10005 ]
              ann.loraine Ann Loraine made changes -
              Status Needs 1st Level Review [ 10005 ] Open [ 1 ]
              ann.loraine Ann Loraine made changes -
              Assignee Prutha Kulkarni [ prutha ]
              prutha Prutha Kulkarni (Inactive) made changes -
              Status Open [ 1 ] In Progress [ 3 ]
              prutha Prutha Kulkarni (Inactive) made changes -
              Assignee Prutha Kulkarni [ prutha ]
              prutha Prutha Kulkarni (Inactive) made changes -
              Status In Progress [ 3 ] Needs 1st Level Review [ 10005 ]
              ann.loraine Ann Loraine made changes -
              Status Needs 1st Level Review [ 10005 ] Ready for Pull Request [ 10304 ]
              ann.loraine Ann Loraine made changes -
              Assignee Prutha Kulkarni [ prutha ]
              prutha Prutha Kulkarni (Inactive) made changes -
              Assignee Prutha Kulkarni [ prutha ]
              prutha Prutha Kulkarni (Inactive) made changes -
              Status Ready for Pull Request [ 10304 ] Pull Request Submitted [ 10101 ]
              ann.loraine Ann Loraine made changes -
              Workflow Loraine Lab Workflow [ 18673 ] Fall 2019 Workflow Update [ 19056 ]
              ann.loraine Ann Loraine made changes -
              Status Pull Request Submitted [ 10101 ] Reviewing Pull Request [ 10303 ]
              ann.loraine Ann Loraine made changes -
              Status Reviewing Pull Request [ 10303 ] Merged Needs Testing [ 10002 ]
              ann.loraine Ann Loraine made changes -
              Link This issue blocks IGBF-1948 [ IGBF-1948 ]
              ann.loraine Ann Loraine made changes -
              Sprint Fall 2019 Sprint 1 [ 72 ] Fall 2019 Sprint 1, Fall 2019 Sprint 2 [ 72, 73 ]
              ann.loraine Ann Loraine made changes -
              Rank Ranked higher
              ann.loraine Ann Loraine made changes -
              Sprint Fall 2019 Sprint 1, Fall 2019 Sprint 2 [ 72, 73 ] Fall 2019 Sprint 1, Fall 2019 Sprint 2, Fall 2019 Sprint 4 [ 72, 73, 74 ]
              ann.loraine Ann Loraine made changes -
              Rank Ranked higher
              ann.loraine Ann Loraine made changes -
              Status Merged Needs Testing [ 10002 ] Post-merge Testing In Progress [ 10003 ]
              ann.loraine Ann Loraine made changes -
              Status Post-merge Testing In Progress [ 10003 ] Closed [ 6 ]
              ann.loraine Ann Loraine made changes -
              Assignee Prutha Kulkarni [ prutha ]
              ann.loraine Ann Loraine made changes -
              Resolution Done [ 10000 ]
              ann.loraine Ann Loraine made changes -
              Workflow Fall 2019 Workflow Update [ 19056 ] Revised Fall 2019 Workflow Update [ 22464 ]

                People

                • Assignee:
                  prutha Prutha Kulkarni (Inactive)
                  Reporter:
                  ann.loraine Ann Loraine
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  Start watching this issue

                  Dates

                  • Created:
                    Updated: