[jira] [Commented] (IVY-1615) Ivy standalone : specify settings from URL
[
https://issues.apache.org/jira/browse/IVY-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16972976#comment-16972976
]
Jason A. Guild commented on IVY-1615:
-
See attached patch for code to implement this improvement.
> Ivy standalone : specify settings from URL
> --
>
> Key: IVY-1615
> URL: https://issues.apache.org/jira/browse/IVY-1615
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.5.0
>Reporter: Jason A. Guild
>Priority: Minor
> Labels: CLI, settings, standalone
> Attachments: cli_ivysettings_from_url.patch
>
>
> When using ivy in standalone mode via CLI, allow the {{-settings}} option to
> read xml settings from a URL instead of a filesystem path. This allows
> convenient access to centralized settings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IVY-1615) Ivy standalone : specify settings from URL
[
https://issues.apache.org/jira/browse/IVY-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason A. Guild updated IVY-1615:
Priority: Minor (was: Major)
> Ivy standalone : specify settings from URL
> --
>
> Key: IVY-1615
> URL: https://issues.apache.org/jira/browse/IVY-1615
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.5.0
>Reporter: Jason A. Guild
>Priority: Minor
> Labels: CLI, settings, standalone
> Attachments: cli_ivysettings_from_url.patch
>
>
> When using ivy in standalone mode via CLI, allow the {{-settings}} option to
> read xml settings from a URL instead of a filesystem path. This allows
> convenient access to centralized settings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IVY-1615) Ivy standalone : specify settings from URL
[
https://issues.apache.org/jira/browse/IVY-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason A. Guild updated IVY-1615:
Priority: Major (was: Minor)
> Ivy standalone : specify settings from URL
> --
>
> Key: IVY-1615
> URL: https://issues.apache.org/jira/browse/IVY-1615
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.5.0
>Reporter: Jason A. Guild
>Priority: Major
> Labels: CLI, settings, standalone
> Attachments: cli_ivysettings_from_url.patch
>
>
> When using ivy in standalone mode via CLI, allow the {{-settings}} option to
> read xml settings from a URL instead of a filesystem path. This allows
> convenient access to centralized settings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IVY-1615) Ivy standalone : specify settings from URL
[
https://issues.apache.org/jira/browse/IVY-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason A. Guild updated IVY-1615:
Attachment: cli_ivysettings_from_url.patch
> Ivy standalone : specify settings from URL
> --
>
> Key: IVY-1615
> URL: https://issues.apache.org/jira/browse/IVY-1615
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.5.0
>Reporter: Jason A. Guild
>Priority: Minor
> Labels: CLI, settings, standalone
> Attachments: cli_ivysettings_from_url.patch
>
>
> When using ivy in standalone mode via CLI, allow the {{-settings}} option to
> read xml settings from a URL instead of a filesystem path. This allows
> convenient access to centralized settings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IVY-1615) Ivy standalone : specify settings from URL
[
https://issues.apache.org/jira/browse/IVY-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason A. Guild updated IVY-1615:
Labels: CLI settings standalone (was: CLI standalone)
> Ivy standalone : specify settings from URL
> --
>
> Key: IVY-1615
> URL: https://issues.apache.org/jira/browse/IVY-1615
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.5.0
>Reporter: Jason A. Guild
>Priority: Minor
> Labels: CLI, settings, standalone
>
> When using ivy in standalone mode via CLI, allow the {{-settings}} option to
> read xml settings from a URL instead of a filesystem path. This allows
> convenient access to centralized settings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IVY-1615) Ivy standalone : specify settings from URL
Jason A. Guild created IVY-1615:
---
Summary: Ivy standalone : specify settings from URL
Key: IVY-1615
URL: https://issues.apache.org/jira/browse/IVY-1615
Project: Ivy
Issue Type: Improvement
Components: Core
Affects Versions: 2.5.0
Reporter: Jason A. Guild
When using ivy in standalone mode via CLI, allow the {{-settings}} option to
read xml settings from a URL instead of a filesystem path. This allows
convenient access to centralized settings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] Issue Comment Edited: (IVYDE-230) Shared Javadoc/Source attachments
[ https://issues.apache.org/jira/browse/IVYDE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799306#action_12799306 ] Jason A. Guild edited comment on IVYDE-230 at 1/12/10 6:23 PM: --- After submitting this question to ivy-user, I got a response from Nicolas Lalevee suggesting that this is not possible with the current IvyDE implementation. He related that this issue was discussed some time ago and an idea was considered to allow addition of extra metadata in the ivy.xml in the form of attributes on the artifacts published by the module. The extra metadata would indicate to IvyDE the explicit javadoc artifact to attach for use with each of the jar artifacts: This is a good possible approach. IvyDE/Ivy looks for javadoc artifacts to attach as part of its normal resolve process, probably as each artifact for the module is retrieved based on its name. I would suggest that a simple heuristic could be applied where IvyDE, as a final step in its resolution process, notices that only a single javadoc artifact exists for the module and attach it to all JAR artifacts for which no javadoc archives were found based on artifact name matching. was (Author: jaguild): After submitting this question to ivy-user, I got a response from Nicolas Lalevee suggesting that this is not possible with the current IvyDE implementation. He related that this issue was discussed some time ago and an idea was considered to allow addition of extra metadata in the ivy.xml in the form of attributes on the artifacts published by the module. The extra metadata would indicate to IvyDE indicate the source attachment to use for an artifact: This is a good possible approach. IvyDE/Ivy looks for javadoc artifacts to attach as part of its normal resolve process, probably as each artifact for the module is retrieved based on its name. I would suggest that a simple heuristic could be applied where IvyDE, as a final step in its resolution process, notices that only a single javadoc artifact exists for the module and attach it to all JAR artifacts for which no javadoc archives were found based on artifact name matching. > Shared Javadoc/Source attachments > - > > Key: IVYDE-230 > URL: https://issues.apache.org/jira/browse/IVYDE-230 > Project: IvyDE > Issue Type: Improvement > Components: classpath container >Affects Versions: 2.0.0.final > Environment: Eclipse 3.3, IvyDE (2.0.0.final), Ivy (2.1.0.final) >Reporter: Jason A. Guild >Priority: Minor > > It would be nice if IvyDE could attach javadoc artifacts to more than one jar > that is published by a module. > For example, consider a rather large module called 'foo'. It has multiple > parts and pieces, some of which may not be required for your particular > application. The 'foo' module publishes multiple JAR artifacts: > foo-a.jar > foo-b.jar > foo-c.jar > The 'foo' module, however, is unfortunately /closed/ and the javadocs are > provided to the developer in one large archive 'foo-doc.zip'. > We are using the default URL resolver against an Ivy repo located on our dev > web server. > The artifact pattern we are using in our ivy settings is: > pattern="http://XX/dev-repo/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]" > /> > After modifying the ivy.xml file for the 'foo' module to publish the docs > via: e:classifier="doc"/>. IvyDE/Ivy will then happily pull down the javadoc along > with all the other artifacts. But, none of the foo-a, foo-b, or foo-c > artifacts will have javadoc attachments in Eclipse (presumably because their > artifact basenames do not match). > Reorganizing the documentation into separate archives is not easy (or even > possible) without the source code. Therefore, it would be nice if IvyDE could > treat the single supplied javadoc artifact as a candidate for attachment on > each of the component JAR artifacts without having to fetch the (possibly > large) javadoc archive multiple times under different basenames. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-230) Shared Javadoc/Source attachments
[ https://issues.apache.org/jira/browse/IVYDE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799306#action_12799306 ] Jason A. Guild commented on IVYDE-230: -- After submitting this question to ivy-user, I got a response from Nicolas Lalevee suggesting that this is not possible with the current IvyDE implementation. He related that this issue was discussed some time ago and an idea was considered to allow addition of extra metadata in the ivy.xml in the form of attributes on the artifacts published by the module. The extra metadata would indicate to IvyDE indicate the source attachment to use for an artifact: This is a good possible approach. IvyDE/Ivy looks for javadoc artifacts to attach as part of its normal resolve process, probably as each artifact for the module is retrieved based on its name. I would suggest that a simple heuristic could be applied where IvyDE, as a final step in its resolution process, notices that only a single javadoc artifact exists for the module and attach it to all JAR artifacts for which no javadoc archives were found based on artifact name matching. > Shared Javadoc/Source attachments > - > > Key: IVYDE-230 > URL: https://issues.apache.org/jira/browse/IVYDE-230 > Project: IvyDE > Issue Type: Improvement > Components: classpath container >Affects Versions: 2.0.0.final > Environment: Eclipse 3.3, IvyDE (2.0.0.final), Ivy (2.1.0.final) >Reporter: Jason A. Guild >Priority: Minor > > It would be nice if IvyDE could attach javadoc artifacts to more than one jar > that is published by a module. > For example, consider a rather large module called 'foo'. It has multiple > parts and pieces, some of which may not be required for your particular > application. The 'foo' module publishes multiple JAR artifacts: > foo-a.jar > foo-b.jar > foo-c.jar > The 'foo' module, however, is unfortunately /closed/ and the javadocs are > provided to the developer in one large archive 'foo-doc.zip'. > We are using the default URL resolver against an Ivy repo located on our dev > web server. > The artifact pattern we are using in our ivy settings is: > pattern="http://XX/dev-repo/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]" > /> > After modifying the ivy.xml file for the 'foo' module to publish the docs > via: e:classifier="doc"/>. IvyDE/Ivy will then happily pull down the javadoc along > with all the other artifacts. But, none of the foo-a, foo-b, or foo-c > artifacts will have javadoc attachments in Eclipse (presumably because their > artifact basenames do not match). > Reorganizing the documentation into separate archives is not easy (or even > possible) without the source code. Therefore, it would be nice if IvyDE could > treat the single supplied javadoc artifact as a candidate for attachment on > each of the component JAR artifacts without having to fetch the (possibly > large) javadoc archive multiple times under different basenames. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVYDE-230) Shared Javadoc/Source attachments
Shared Javadoc/Source attachments - Key: IVYDE-230 URL: https://issues.apache.org/jira/browse/IVYDE-230 Project: IvyDE Issue Type: Improvement Components: classpath container Affects Versions: 2.0.0.final Environment: Eclipse 3.3, IvyDE (2.0.0.final), Ivy (2.1.0.final) Reporter: Jason A. Guild Priority: Minor It would be nice if IvyDE could attach javadoc artifacts to more than one jar that is published by a module. For example, consider a rather large module called 'foo'. It has multiple parts and pieces, some of which may not be required for your particular application. The 'foo' module publishes multiple JAR artifacts: foo-a.jar foo-b.jar foo-c.jar The 'foo' module, however, is unfortunately /closed/ and the javadocs are provided to the developer in one large archive 'foo-doc.zip'. We are using the default URL resolver against an Ivy repo located on our dev web server. The artifact pattern we are using in our ivy settings is: http://XX/dev-repo/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]" /> After modifying the ivy.xml file for the 'foo' module to publish the docs via: . IvyDE/Ivy will then happily pull down the javadoc along with all the other artifacts. But, none of the foo-a, foo-b, or foo-c artifacts will have javadoc attachments in Eclipse (presumably because their artifact basenames do not match). Reorganizing the documentation into separate archives is not easy (or even possible) without the source code. Therefore, it would be nice if IvyDE could treat the single supplied javadoc artifact as a candidate for attachment on each of the component JAR artifacts without having to fetch the (possibly large) javadoc archive multiple times under different basenames. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-104) Display all resolved libraries in order
[ https://issues.apache.org/jira/browse/IVYDE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631533#action_12631533 ] Jason A. Guild commented on IVYDE-104: -- bq. That is weird because in the 2.0.0.alpha1, it is possible. Could you check the version you are running ? (look for an "org.apache.ivyde.eclipse" in Help>About Eclipse SDK>Plugins Details) I am definitely running 2.0.0.alpha1 as reported by Help>About Eclipse SDK>Plugins Details. However, I am using a build from SVN that I produced myself which was several weeks ahead of the actual 2.0.0.alpha1 release so I don't 100% know that changes were made which affect my experience in the official alpha release. I'll try to make some time to install the official release and see if the problem still manifests itself. > Display all resolved libraries in order > --- > > Key: IVYDE-104 > URL: https://issues.apache.org/jira/browse/IVYDE-104 > Project: IvyDE > Issue Type: Improvement > Components: classpath container >Affects Versions: 2.0.0.alpha1 > Environment: Eclipse 3.3.2 >Reporter: Jason A. Guild >Priority: Minor > > The display listing of libraries resolved in Eclipse package explorer should > be in some kind of predictable order. It can be frustrating when you are > looking through a long list of libraries and can't see the one you are > looking for fast. > Right now, libraries are listed in what appears to be random order and should > either be in order of resolution or (preferrably) sorted order by library > name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (IVYDE-104) Display all resolved libraries in order
[ https://issues.apache.org/jira/browse/IVYDE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621305#action_12621305 ] jaguild edited comment on IVYDE-104 at 8/10/08 1:34 PM: --- Sorry for the confusion. I mixed multiple points together hastily. Editing and applying workspace-level options works just fine as you expect, including the "Order alphabetically the classpath entries" feature. However: # The feature is one of many (and last) on a busy property screen which caused me to miss it in the first place. It should be made more prominent. # I don't like the UI (a check box for that), because it doesn't give any indication what order the libraries will be display in when it is NOT checked...which was one reason for my opening this issue in the first place -- the displayed libraries didn't appear to be in any order to me. Instead, I propose this option be exposed as a drop box or radio group with two items "resolution", "alphabetical" to make it clear. If other orderings/groupings make sense (e.g. grouped by organization) then those should be listed there as well. In 2.00alpha1, enabling project-specific Ivy-configuration is broken for me. When I enable the project-specific configuration the whole plugin blows up and I lose my classpath container entirely. But that is beside the point...even if it was working properly, my other point is that the project-specific Ivy configuration page/screen does not ALSO have a way to specify an project-specific ordering for display of libraries which is separate from the workspace configuration. Perhaps this is not so important though. bq. Then about that shortcut in a context menu I am afraid that will not be possible in the general case. In the case the project is not configured "locally", and is relying on the global configuration, having a entry to configure the order locally has no sense. After thinking a bit about this, I see what you mean about the inconsistent semantics. I was attempting address my #1 above, thinking that adding an item to the context menu would make the option more prominent. Though my suggestions may not be optimal, I think my points #1 and #2 above are legitimate usability problems which should be addressed. Thanks for your patience. was (Author: jaguild): Sorry for the confusion. I mixed multiple points together hastily. Editing and applying workspace-level options works just fine as you expect, including the "Order alphabetically the classpath entries" feature. However: # The feature is one of many (and last) on a busy property screen which caused me to miss it in the first place. It should be made more prominent. # I don't like the UI (a check box for that), because it doesn't give any indication what order the libraries will be display in when it is NOT checked...which was one reason for my opening this issue in the first place -- the displayed libraries didn't appear to be in any order to me. Instead, I propose this option be exposed as a drop box or radio group with two items "resolution", "alphabetical" to make it clear. If other orderings/groupings make sense (e.g. grouped by organization) then those should be listed there as well. In 2.00alpha1, enabling project-specific Ivy-configuration is broken for me. When I enable the project-specific configuration the whole plugin blows up and I lose my classpath container entirely. But that is beside the point...even if it was working properly, my other point is that the project-specific Ivy configuration page/screen does not ALSO have a way to specify an project-specific ordering for display of libraries which is separate from the workspace configuration. Perhaps this is not so important though. bq. Then about that shortcut in a context menu I am afraid that will not be possible in the general case. In the case the project is not configured "locally", and is relying on the global configuration, having a entry to configure the order locally has no sense. After thinking a bit about this, I see what you mean about the inconsistent semantics. I was attempting address my #1 above, thinking that adding an item to the context menu would make the option more prominent. I think both of my po > Display all resolved libraries in order > --- > > Key: IVYDE-104 > URL: https://issues.apache.org/jira/browse/IVYDE-104 > Project: IvyDE > Issue Type: Improvement > Components: classpath container >Affects Versions: 2.0.0.alpha1 > Environment: Eclipse 3.3.2 >Reporter: Jason A. Guild >Priority: Minor > > The display listing of libraries resolved in Eclipse package explorer should > be in some kind of predictable order. It can be frustrating when you are > looking through a long list of librar
[jira] Commented: (IVYDE-104) Display all resolved libraries in order
[ https://issues.apache.org/jira/browse/IVYDE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621305#action_12621305 ] Jason A. Guild commented on IVYDE-104: -- Sorry for the confusion. I mixed multiple points together hastily. Editing and applying workspace-level options works just fine as you expect, including the "Order alphabetically the classpath entries" feature. However: # The feature is one of many (and last) on a busy property screen which caused me to miss it in the first place. It should be made more prominent. # I don't like the UI (a check box for that), because it doesn't give any indication what order the libraries will be display in when it is NOT checked...which was one reason for my opening this issue in the first place -- the displayed libraries didn't appear to be in any order to me. Instead, I propose this option be exposed as a drop box or radio group with two items "resolution", "alphabetical" to make it clear. If other orderings/groupings make sense (e.g. grouped by organization) then those should be listed there as well. In 2.00alpha1, enabling project-specific Ivy-configuration is broken for me. When I enable the project-specific configuration the whole plugin blows up and I lose my classpath container entirely. But that is beside the point...even if it was working properly, my other point is that the project-specific Ivy configuration page/screen does not ALSO have a way to specify an project-specific ordering for display of libraries which is separate from the workspace configuration. Perhaps this is not so important though. bq. Then about that shortcut in a context menu I am afraid that will not be possible in the general case. In the case the project is not configured "locally", and is relying on the global configuration, having a entry to configure the order locally has no sense. After thinking a bit about this, I see what you mean about the inconsistent semantics. I was attempting address my #1 above, thinking that adding an item to the context menu would make the option more prominent. I think both of my po > Display all resolved libraries in order > --- > > Key: IVYDE-104 > URL: https://issues.apache.org/jira/browse/IVYDE-104 > Project: IvyDE > Issue Type: Improvement > Components: classpath container >Affects Versions: 2.0.0.alpha1 > Environment: Eclipse 3.3.2 >Reporter: Jason A. Guild >Priority: Minor > > The display listing of libraries resolved in Eclipse package explorer should > be in some kind of predictable order. It can be frustrating when you are > looking through a long list of libraries and can't see the one you are > looking for fast. > Right now, libraries are listed in what appears to be random order and should > either be in order of resolution or (preferrably) sorted order by library > name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (IVYDE-104) Display all resolved libraries in order
[ https://issues.apache.org/jira/browse/IVYDE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason A. Guild reopened IVYDE-104: -- This issue was not about project-specific preferences for IvyDE. I understand that IvyDE supports this, but it's broken in 2.00alpha1 and doesn't appear to have an override for library ordering anyway, so please read on: It is about how to order the resolved libraries and I think IvyDE UI could stand improvements in this area. You should be able to use the context menu on the ivy.xml classpath icon in the package explorer to select an 'Order By' item and choose an ordering from a list of supported orderings. I'd imagine that the only two orderings that matter are resolution order and name order. That is my suggestion for an improvement. Please look more closely at issues before making an irrelevant offhand comment and closing it as "invalid". > Display all resolved libraries in order > --- > > Key: IVYDE-104 > URL: https://issues.apache.org/jira/browse/IVYDE-104 > Project: IvyDE > Issue Type: Improvement > Components: classpath container >Affects Versions: 2.0.0.alpha1 > Environment: Eclipse 3.3.2 >Reporter: Jason A. Guild >Priority: Minor > > The display listing of libraries resolved in Eclipse package explorer should > be in some kind of predictable order. It can be frustrating when you are > looking through a long list of libraries and can't see the one you are > looking for fast. > Right now, libraries are listed in what appears to be random order and should > either be in order of resolution or (preferrably) sorted order by library > name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-104) Display all resolved libraries in order
[ https://issues.apache.org/jira/browse/IVYDE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615706#action_12615706 ] Jason A. Guild commented on IVYDE-104: -- I just found that option, activated it, and it does seem to work. However it's a bit obscure to look in the workspace Ivy preferences for it. I was thinking you should be able to use the context menu on the ivy.xml classpath icon in the package explorer to select an 'Order By' item and choose an ordering from a list of supported orderings. I'd imagine that the only two orderings that matter are resolution order and name order. When IvyDE supports project-specific configurations for IvyDE, this ordering preference would be stored there and override whatever the workspace Ivy preferences have as defaults. > Display all resolved libraries in order > --- > > Key: IVYDE-104 > URL: https://issues.apache.org/jira/browse/IVYDE-104 > Project: IvyDE > Issue Type: Improvement > Components: classpath container >Affects Versions: 2.0.0.alpha1 > Environment: Eclipse 3.3.2 >Reporter: Jason A. Guild >Priority: Minor > > The display listing of libraries resolved in Eclipse package explorer should > be in some kind of predictable order. It can be frustrating when you are > looking through a long list of libraries and can't see the one you are > looking for fast. > Right now, libraries are listed in what appears to be random order and should > either be in order of resolution or (preferrably) sorted order by library > name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVYDE-104) Display all resolved libraries in order
Display all resolved libraries in order --- Key: IVYDE-104 URL: https://issues.apache.org/jira/browse/IVYDE-104 Project: IvyDE Issue Type: Improvement Components: classpath container Affects Versions: 2.0.0.alpha1 Environment: Eclipse 3.3.2 Reporter: Jason A. Guild Priority: Minor The display listing of libraries resolved in Eclipse package explorer should be in some kind of predictable order. It can be frustrating when you are looking through a long list of libraries and can't see the one you are looking for fast. Right now, libraries are listed in what appears to be random order and should either be in order of resolution or (preferrably) sorted order by library name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
