Community
Participate
Working Groups
Currently, the coordinate org.eclipse:osgi:3.0.0 comes after org.eclipse.zest:org.eclipse.zest.core:1.0.0 The sorting should be at least lexicographic, sorting first by groupId, then by artifactId, then by version. (More smarts in each group are also possible, but the above symptom would already be covered by sorting by groupId first, then by artifactId.)
I would like the sorting to be case insensitive, so that A:A:1.0.0 comes before b:b:1.0.0
Unless we get external contributions on this one, we have to postpone it for 2.3.0.
this is my first bug, please assign this bug to me
(In reply to varun gupta from comment #3) > this is my first bug, please assign this bug to me You can do so yourself. Just change "Assigned to" and change the bug's status. Anyhow, we are looking forward to see your contributions in Gerrit. Please don't hesitate to ask a question about this feature (in Bugzilla) or the general committer workflow (on the recommenders-dev mailing list).
please could you give me the link from where I could find the code for the feature
org.eclipse.zest:org.eclipse.zest.core:1.0.0 please verify org.eclipse.zest is groupId org.eclipse.zest is artifactId 1.0.0 is version
(In reply to varun gupta from comment #6) > org.eclipse.zest:org.eclipse.zest.core:1.0.0 > > please verify > org.eclipse.zest is groupId > org.eclipse.zest is artifactId org.eclipse.zest.core (the second part) is artifactId > 1.0.0 is version Aside from that, the above is correct.
(In reply to varun gupta from comment #5) > please could you give me the link from where I could find the code for the > feature The class to look for is ModelRepositoriesView. Start by looking at the treeViewer field and how it is set up. (I hope you are somewhat familiar with the JFace viewer framework; if not, please read some documentation/tutorials first.)
i have read the treeViewer field from the link http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fjface%2Fviewers%2FTreeViewer.html but i could not find the ModelRepositoriesView
(In reply to varun gupta from comment #9) > i have read the treeViewer field from the link > > http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc. > isv%2Freference%2Fapi%2Forg%2Feclipse%2Fjface%2Fviewers%2FTreeViewer.html > > but i could not find the ModelRepositoriesView Hi Varun. Did you check out the code of Eclipse Code Recommenders as described at [1]. You should then have a ModelRepositoriesView in your workspace (in project org.eclipse.recommenders.models.rcp). Hope this helps. [1] <https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/about/>
org.eclipse.recommenders.internal.models.rcp.ModelRepositoriesView this is the class which u want me to look at
(In reply to varun gupta from comment #11) > org.eclipse.recommenders.internal.models.rcp.ModelRepositoriesView > > this is the class which u want me to look at Exactly. Try to find our where the sorting happens and then change the comparison logic to take the structure (groupId:artifactId:version) into account.
could u briefly explain to me what this class does, because when i read the code its not easy to understand.
(In reply to varun gupta from comment #13) > could u briefly explain to me what this class does, because when i read the > code its not easy to understand. OK, the class is responsible for the UI of the Model Repositories view. In particular, the view shows KnownCoordinate objects. Now, one tiny part of this is fixing a sort order for the KnownCoordinates can be found in the createCoordiantes (note the type) method: return Ordering.natural().onResultOf(toStringRepresentation).sortedCopy(coordinates); If you don't understand what this line does, have a look at the Google Guava library and its Ordering class. Hope that helps.
createCoordiantes method has a string url as a parameter, what is it for because the pc variable already has the groupid, artifactid and version
(In reply to varun gupta from comment #15) > createCoordiantes method has a string url as a parameter, what is it for > because the pc variable already has the groupid, artifactid and version It is the URL of the repository in which the project coordinate was found. For the sorting, it's value should not matter; only groupId, artifactId, and version need to be taken into account.
what does ModelCoordinate parameter contain? our multimap coordinatesGroupedByProjectCoordinate has project coordinate which maps with ModelCoordinate so could u tell me how are the related?
is the ProjectCoordinate a string which is like this notation "groupid:artifactid:version"? and is the colon included
(In reply to varun gupta from comment #19) > is the ProjectCoordinate a string which is like this notation > "groupid:artifactid:version"? > and is the colon included A ProjectCoordinate is a ProjectCoordinate, that is an object with multiple fields, through of which are groupId, artifactId, and version.
sir, could u also explain the Known coordinate class that is what r the fields it has and how it is mapped with a string
sir, we could use a comparable interface for our KnownCoordinate class and implement a compareTo function and there we can specify the order that is groupid:artifactId:version and then we could simply apply Collection.sort to sort the list of all KnownCoordinate class objects
Varun, I think it's time that you write some code. At some point all your questions will get answered when you start writing the code and start looking into the details yourself - best with the aid of a debugger. This is what your should do anyways to figure out how things actually work. Please start writing a java.util.Comparator that takes the example coordinates given in comment 0 and comment 1 and write a unit test that verifies that the order meets your expectations. then commit it to gerrit so that we can review your code there. Please take your time to read through the documentation provided in the wiki and contributor guides. Familiarize yourself with the code (follow the contributor guide to see how to setup an Eclipse with the code in it) and write code. At some point you need to try out things :) Thanks and bye, Marcel
sir, i have written the code as a temporary class implementing the comparator interface,could u tell me how to commit the code
Please consult the last paragraph of [1]. You may also find the egit/gerrit user guide in the Eclipse wiki helpful. [1] https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/about/
are comments in the code i have wriiten or somewhere else
whatever you prefer. normally we use gerrit for comments. The code would certainly require several iterations and the comments in code will be removed over time. So start with whatever you have. Thanks.
sir what i have done is it somewhat right
You can see the comments in gerrit https://git.eclipse.org/r/#/c/37734/
sir i want to know what do u mean by Please make the Comparator into its own class, distinct from KnownCoordinate
(In reply to varun gupta from comment #30) > sir i want to know what do u mean by Please make the Comparator into its own > class, distinct from KnownCoordinate First of all, please discuss comments somebody made in Gerrit in Gerrit, not in Bugzilla. Anyway, what I meant is this: Please create a new class KnownCoordianteComparator implementing Comparator<KnownCoordinate>. Making KnownCoordinate itself implement Comparator is a bad idea.
sir,i wanted to know exactly what i should do in the JUnit test and as t have to check the comparator function "compare",so i need object of KnownCoordinate but should i make the url field and mcs field as anything because i only need the pc field
(In reply to varun gupta from comment #32) > sir,i wanted to know exactly what i should do in the JUnit test and as t > have to check the comparator function "compare",so i need object of > KnownCoordinate but should i make the url field and mcs field as anything > because i only need the pc field Maybe you can write a Comparator for ProjectCoordinate first. We the help of Guava's Ordering.onResultOf [1] you can then turn the Comparator<ProjectCoordinate> into a Comparator<KnownCoordinate>. Hope this helps. [1] <http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Ordering.html>
sir last time i implemented the KnownCoordinate comparator itself so it was working(i think so it was) so should i use the ordering thing or just use the previous one
sir,i am not able to understand the utility of the Ordering class. we could simply write a comparator of our own and use Collections.sort() method.The ordering class used also returns a comparator when we use from() method and we can use that comparator to sort our list again by Collections.sort()
Ordering class is only there to make things easier. The reason to have a ProjectCoordinateComparator instead of a KnownCoordinateComparator is that it is more generic, and might be useful elsewhere in the project. Then, with a Function object that takes a KnownCoordinate and outputs its pc field, this can be turned in a Comparator for KnownCoordinate using the Ordering.onResultOf. My advise is to start refactoring the code you have, making an own Comparator<KnownCoordinate> class with the code you already have. Afterwards you can still turn this into a Comparator<ProjectCoordinate> later. The Ordering class is there to combine Comparators or turn simple Comparators into more complex ones. It is not "needed", it is just convenient (for you and for us).
sir, i had committed on git three days ago and no one has reviewed my code so i could make changes(as the built failed),please look into it and tell me any problem you find
sir, i had committed on gerrit three days ago and no one has reviewed my code so i could make changes(as the built failed),please look into it and tell me any problem you find
Hi Varun, I see now. It would help if you amended your commits when you change them, instead of making a new commit. That way there is only one change in Gerrit that needs to be followed. Gerrit identifies the changes through the Change-Id, so when you locally amend your commit, keeping the Change-Id the same, Gerrit will associate the new change with the old one. Obviously once we have submitted your code to the codebase, you no longer amend that change ;-) Also, to see why the build failed, you should check what Hudson said, by clicking on the link for the build. You should do this shortly after, as by now the result is no longer available. It is possible to re-run the build, but I forgot how. Anyway, I am reviewing your change now.
hi,i have been committing my code on gerrit with the new line as you said but now my code is not getting commited
about the Junit test can you tell me what input should I use for the objects of KnownCoordinate class ?
can you provide me with a proper constraint of the values for the version field. example version a.b.c constraints for a, b and c;
Hi varun, as per http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html the format for versions is: <major version>.<minor version>.<incremental version>-<qualifier> where major, minor, and incremental version are numbers, and the qualifier can be any string, basically. From the examples given, I would say there are following things that you should be aware of: - The qualifier can be missing (and often is), in that case the dash won't be there, either. - The incremental version can be missing, then the last dot is missing, too: > For example, the version "1.3-beta-01" has a major version of 1, a minor version of 3, no incremental version and a qualifier of "beta-01". - it is legal to have some non-standard version (so basically forget all I said before): > If your version release number does not fit the standard introduced in this section, then your versions will be compared as strings; "1.0.1b" will be compared to "1.2.0b" using a String comparison. So, after all this, I think you should compare like this: Lexicographically, compare major version, then minor, then incremental, then qualifier. When these are numbers, compare as numbers, otherwise as strings. A missing something is always before the not-missing thing, except for the classifier: A missing classifier is later than an existing classifier. Makes sense? An additional gotcha is mentioned on the site I linked: > One gotcha for release version numbers is the ordering of the qualifiers. Take the version release numbers “1.2.3-alpha-2” and “1.2.3-alpha-10,” where the “alpha-2” build corresponds to the 2nd alpha build, and the “alpha-10” build corresponds to the 10th alpha build. Even though “alpha-10” should be considered more recent than “alpha-2,” Maven is going to sort “alpha-10” before “alpha-2” due to a known issue in the way Maven handles version numbers. >Maven is supposed to treat the number after the qualifier as a build number. In other words, the qualifier should be "alpha", and the build number should be 2. Even though Maven has been designed to separate the build number from the qualifier, this parsing is currently broken. As a result, "alpha-2" and "alpha-10" are compared using a String comparison, and "alpha-10" comes before "alpha-2" alphabetically. To get around this limitation, you will need to left-pad your qualified build numbers. If you use "alpha-02" and "alpha-10" this problem will go away, and it will continue to work once Maven properly parses the version build number. *Basically, read the site I linked.*
(In reply to Michael Kutschke from comment #43) > as per > http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom- > syntax.html > > the format for versions is: > > <major version>.<minor version>.<incremental version>-<qualifier> This is true of Maven version numbers, but not of the versions that are part of a ModelCoordinate or ProjectCoordinate. There, the version is always <major version>.<minor version>.<incremental version> There is no <qualifier> and none of the three numbers is optional.
i have commited a new patch but I am not able to attach the header files due to problem with my setup of gerrit .
For versions I need a little more clarity about the format. version1= x.y.z version2= a.b.c then are the types of a and x same, same for b and y and z and c. If the types are different that is one is a string and the other is an integer then how do you want the sorting to work?
(In reply to varun gupta from comment #46) > For versions I need a little more clarity about the format. > version1= x.y.z > version2= a.b.c > > then are the types of a and x same, same for b and y and z and c. > > If the types are different that is one is a string and the other is an > integer then how do you want the sorting to work? All strings are larger or lower (I don't care which way) than all numbers. For numbers: 1 < 2 < 10 < 20.
(In reply to Andreas Sewe from comment #47) > (In reply to varun gupta from comment #46) > > For versions I need a little more clarity about the format. > > version1= x.y.z > > version2= a.b.c > > > > then are the types of a and x same, same for b and y and z and c. > > > > If the types are different that is one is a string and the other is an > > integer then how do you want the sorting to work? > > All strings are larger or lower (I don't care which way) than all numbers. > For numbers: 1 < 2 < 10 < 20. Example: 1.2.3 and 1.2.beta, how can such versions be compared , when the type for the last field are different
(In reply to varun gupta from comment #48) > (In reply to Andreas Sewe from comment #47) > > (In reply to varun gupta from comment #46) > > > For versions I need a little more clarity about the format. > > > version1= x.y.z > > > version2= a.b.c > > > > > > then are the types of a and x same, same for b and y and z and c. > > > > > > If the types are different that is one is a string and the other is an > > > integer then how do you want the sorting to work? > > > > All strings are larger or lower (I don't care which way) than all numbers. > > For numbers: 1 < 2 < 10 < 20. > > Example: 1.2.3 and 1.2.beta, > how can such versions be compared , when the type for the last field are > different All strings are larger than all numbers. For example: 1 < 2 < 10 < 20 < alpha < beta < xyz
I have made the changes please have a look at the new commit
For a JUnit Test Case for the KnownCoordinateComparator Class, I would be needing to create the object for the KnownCoordinate Class, for which I would have to create one for the outer class that is the ModelReposioriesView class. So can i just set some default values for the constructor to ModelReposioriesView class and then send the fields that concern the KnownCoordinate class constructor.
For the Model Repositories View class , can you please explain me what the parameters of the constructors are to be considered for the JUnit Test For creating the object of inner class KnownCoordinate , I need to invoke the constructor of Model Repositories View ,so i needed to know which parameters should I consider as I dont need any of them for the test case, all I require is the Known Coordinate for the Junit test.
