2016-05-11 15:45 GMT+02:00 Thomas Watson <[email protected]>: > I want to keep a copy of the spec source in the project because we will be > using the project to prototype OSGi R7. It helps to keep the source in the > project so we can get the very latest before the final spec is released. > The felix resolver impl is going to be the RI again so we need the freedom > to implement the proposed API before the spec is released and available in > maven. > > Moving up to Java 6 is fine. As you may guess I still have a vested > interest in making sure the source still compiles with Java 6 for some time > so please don't go beyond that. > > I don't see a big issue with the Util class. This should be completely > internal to the implementation. I do think we should avoid extra classes > if we can. I would even consider getting rid of the Util class completely > and just moving the static methods to the ResolverImpl. I mean we have > tons of other static methods, why are some stuck on a Util class and some > not? > > I'm pretty sure ResolverSession can be static so it should be fine to move > to a top level class if you want. But this is all a matter of style. Some > like to keep the number top level classes low. I don't really care one way > or the other. > > I'm more interested in investigating improvements to the Capabilities class > (I would rename this to Permutation). Here there was lots of work done by > Guillaume to significantly reduce the cost of copying the Permutation and > modifying it. He added a bunch of special copy on write collections. I > would instead like to implement a capability selection collection that > points to a constant list of capabilities and has an index to the currently > selected candidate for that permutation. That way there is no copying of > the constant list, instead we have a super lightweight collection that > points to the unmodifiable list of capabilities and just has an index. > Changing a Permutation would only involve incrementing that index instead > of removing from a copy on write list. We can then get rid of duplicate > capability lists since the list is unmodifiable it can be shared with > multiple selection index lists. >
If possible, that would be awesome. > > I also want to improve the the algorithm to ignore many permutations when > the sheer number of permutations gets "too high". Before moving to the > Felix resolver in Equinox we had an algorithm that detected that number of > permutations was "too high" and would start treating multiple requirements > that point to the identical list of matching capabilities as a "single" > requirement and would permute all the identical candidate lists at the same > time instead of trying each one individually. It is possible this would > remove some valid permutations, but I had never found a real world scenario > where this approach failed to find a valid solution if one existed. The > trick here is to come up with some policy that makes sense to determine the > number of permutations is getting "too high". > Sounds like a good idea too !!! > > Tom > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
