Details
-
Type:
New Feature
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:
-
Story Points:4
-
Epic Link:
-
Sprint:Fall 2019 Sprint 1, Fall 2019 Sprint 2, Fall 2019 Sprint 3
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
| Field | Original Value | New Value |
|---|---|---|
| Epic Link | IGBF-1531 [ 17617 ] |
| Assignee | Ann Loraine [ aloraine ] |
| 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/ |
| 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/ |
| 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/ |
| Story Points | 3 | 4 |
| 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/ |
| Assignee | Prutha Kulkarni [ prutha ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
For the next steps, please add instructions on how to use the plugin to its README.md file in bitbucket, including example configurations you described above.
Prof. [~aloraine], README.md file changes can be seen at:
https://bitbucket.org/pkulka10/bundlemarkdownencoder_prutha/src/IGBF-1949/README.md
Submitting the ticket for first level review.
Thanks.
| Assignee | Prutha Kulkarni [ prutha ] |
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
Requests:
- Please include markdown file tags in example text for POM and indicate that README.md at top-level of the project is used if markdownFile tag is absent.
- Check how the README.md looks in a browser when user visits bitbucket. Check that XML is getting rendered properly.
| Status | Needs 1st Level Review [ 10005 ] | Open [ 1 ] |
| Assignee | Prutha Kulkarni [ prutha ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
Prof. [~aloraine], the XML is getting rendered properly.
Also, Moved the text which was mentioned in the "NOTE" to top of the file and included markdown file tags in the exmaple text for POM which was already present in the file.
https://bitbucket.org/pkulka10/bundlemarkdownencoder_prutha/src/IGBF-1949/
Please let me know if thats correct.
| Assignee | Prutha Kulkarni [ prutha ] |
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
| Status | Needs 1st Level Review [ 10005 ] | Ready for Pull Request [ 10304 ] |
| Assignee | Prutha Kulkarni [ prutha ] |
Prof. [~aloraine], I have submitted pull request for the same.
The code changes are present at https://bitbucket.org/lorainelab/bundlemarkdownencoder/pull-requests/1/igbf-1949/diff
Could you please merge it into bundle markdown encoder plugin master?
Thanks.
| Assignee | Prutha Kulkarni [ prutha ] |
| Status | Ready for Pull Request [ 10304 ] | Pull Request Submitted [ 10101 ] |
| Workflow | Loraine Lab Workflow [ 18673 ] | Fall 2019 Workflow Update [ 19056 ] |
| Status | Pull Request Submitted [ 10101 ] | Reviewing Pull Request [ 10303 ] |
| Status | Reviewing Pull Request [ 10303 ] | Merged Needs Testing [ 10002 ] |
| Sprint | Fall 2019 Sprint 1 [ 72 ] | Fall 2019 Sprint 1, Fall 2019 Sprint 2 [ 72, 73 ] |
| Rank | Ranked higher |
| 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 ] |
| Rank | Ranked higher |
Merged. The instructions added are very clear. See "Super Simple IGB App" for another example. Moving this to "Closed."
| Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
| Status | Post-merge Testing In Progress [ 10003 ] | Closed [ 6 ] |
| Assignee | Prutha Kulkarni [ prutha ] |
| Resolution | Done [ 10000 ] |
| Workflow | Fall 2019 Workflow Update [ 19056 ] | Revised Fall 2019 Workflow Update [ 22464 ] |
Prof. [~aloraine], I have checked the bundle markdown encoder plugin code.
The person who was previously working on it has already given a provision for user-specified file as input. The parameter is already in use and if not specified, it sets the default value to README.md file.
We just need to specify the name of the markdown file which we want to use like this in the "bundle-markdown-encoder" plugin tag of the "pom.xml" under "executions>execution" tag of the plugin wherever it is used:
<configuration>
<markdownFile>TESTMarkDown.md</markdownFile>
</configuration>
for example:
<plugin>
<groupId>org.lorainelab</groupId>
<artifactId>bundle-markdown-encoder</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<goals>
<goal>encodeMarkdown</goal>
</goals>
<configuration>
<markdownFile>TESTMarkDown.md</markdownFile>
</configuration>
</execution>
</executions>
</plugin>
We don't need to change anything in the plugin as it is working fine.
Also, found this useful link on how to create a maven bundle plugin from scratch:
https://maven.apache.org/guides/plugin/guide-java-plugin-development.html
Please let me know if there is anything else which I can do related to the same ticket.