search

ctron / package-drone

An OSGI first software artifact repository – Moved to the Eclipse Foundation
https://github.com/eclipse/packagedrone
Eclipse Public License 1.0
39 stars 13 forks source link

bundle information: package imports order #69

Closed maggu2810 closed 9 years ago

maggu2810 commented 9 years ago

Hello, would like to know what is the order of the "Package Imports" using "Home / Channel / Artifact / Bundle Information". It seems that this is not ordered. It differs from the order in the manifest and it is not ordered alpha-numerical. Would it be possible to allow to switch between different order (e.g. ascending / descending by name, the one of the manifest, ...)?

ctron commented 9 years ago

True .. it is not ordered! Is it possible, sure :smile:

The same is true for the package exports and bundle requirements. All are classes inside BundleInformation. All of them implement èqualsandhashCode` in order to be stored in a set. And that is what generates the random order.

The easiest thing would be to implement Comparable and sort them by name followed by version. However VersionRange is not comparable either. Another way would be to sort them right before viewing then. Which would be OK from my point of view.

That would be in the bundle de.dentrassi.pm.osgi.web, the class is OsgiController.

maggu2810 commented 9 years ago

Will have a look at, next week. Thanks

cornzy commented 9 years ago

we may first use a LinkedHashMap to keep original order. Second we may implement an optional alphabetical order.

ctron commented 9 years ago

That sounds like a good idea! So we would keep the order of the MANIFEST.MF. I would then suggest add a ' Comparator` implementation which takes care of sorting objects by name and version range. This could be a static instance which gets applied before the sets (which are converted to lists or arrays first) are passed on the to view model.

So I would suggest that the first step would be the LinkedHashMap which @cornzy suggested. Because then the extracted information in the meta data will also match the data from the manifest. And it should be an easy change.

maggu2810 commented 9 years ago

Is there any reason to use a map? There is no real key value pair if we want to hold a collection of package imports (package exports, bundle requirements). Why not using a list? We could use Collections.sort(...) if we want to sort the list later.

maggu2810 commented 9 years ago

@ctron Is a LinkedList ok? @cornzy Why you would like to use a LinkedHashMap?

cornzy commented 9 years ago

@maggu2810 using a LinkedHashMap instead of normal HashSet preserves the natural order from manifest.

maggu2810 commented 9 years ago

@cornzy Have you read my comment before the one you replied to? ;-) Sure a LinkedHashMap will keep the order, but a LinkedList will also keep the order. What is the reason for using a map, that is normally used to store key value pairs, instead of a list?

cornzy commented 9 years ago

Oh sorr! I alway thought about a LinkedHashSet! For any reason I always wrote map...

maggu2810 commented 9 years ago

Oh sorry! I previously considered that you want to write Set instead of Map, but it is a miracle I did not found LinkedHashSet. Sure, a Set is good for this, because multiple identicial entries should not exist. Will do it...

ctron commented 9 years ago

Hi,

A LinkedHashSet is fine. These entries should be unique, and the order is important and shod be stable.

A LinkedList would allow for duplicates, which would be OK from a point of view where the data is as it is.

However I would prefer to limit it to a set, in order to have unique exports/imports.