Jason van Zyl a écrit : > > > On 7-Jan-09, at 10:10 AM, Daniel Le Berre wrote: > >> Jason van Zyl a écrit : >>> >>> I was talking about this with Brian a few days ago when I saw this pass >>> by the p2 list. >>> >>> At least in the case of Maven and Eclipse going forward in the future I >>> don't see any downside to just using the same versioning scheme as OSGi. >>> If it makes things easier for interoperability then I'm all for it. We >>> would have to support our current scheme but anyone going forward could >>> just use the x.y.z.qualifier notation. I realize that p2 would have >>> touchpoints for things like RPMs and does this proposal cover that as >>> well? >> >> I think so. I do not know the details. >> >>> In the proposal it says there is a SAT4J solution forthcoming and this >>> is something I've talked to Oleg about. If you could declaratively state >>> the strategy with a grammar, or XML file and generate version parsing >>> schemes and dependency resolvers which I see consisting of the correctly >>> generated equations that would be very cool and something everyone could >>> use. >> >> We are working with Genuitec on explanation support for p2. > > You mean on the p2 dev list?
Nope. We have a research contract with them: http://lenettoyeur-on-eclipse.blogspot.com/2008/12/genuitec-sat4j-and-p2.html >> >> This requires the use of SAT4J API directly, not through text files as >> currently. >> > > That's fine, we're using the APIs directly too. I'm just saying in the > future if there was a descriptor and TCK folks could implement their > down solutions. > >> So we are also working on making life easier for the end users by hiding >> all current gory details on SAT and let it work with domain object. >> We are still usure of the best way to express the optimization scheme: >> hiding the weights used to the end user by just allowing simple >> preferences among domain object or giving more flexibility to the end >> user by letting him do whatever he wants. > > I don't think we'll be able to avoid the API in the short term, and > something simple yet possibly incomplete should be made so we can explore. I agree. >> >> >>> I'm committed to trying to attain some meaningful level of operability >>> between Maven and OSGi. As far as runtime modularity I believe OSGi has >>> won (I have other things to say about the programming model) and it >>> would be useful to have some mechanism for describing how the resolution >>> would work and then generate the necessary machinery. >>> >>> The SAT4J solution is this the discussion you're having on the linux >>> mailing lists? >> >> p2 SAT4J solution is a tailored solution, and a new specific one is >> currently needed for the OmniVersion resolver. >> >> By linux mailing list I guess you mean the Mancoosi project mailing list? > > Oleg just mentioned a linux mailing list so I suppose this is the one :-) > Well, I am following that work, but p2 one is specific to p2. -- Daniel Le Berre mailto:lebe...@cril.univ-artois.fr MCF, CRIL-CNRS UMR 8188, Universite d'Artois http://www.cril.univ-artois.fr/~leberre --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
