On 7-Jan-09, at 11:32 AM, Daniel Le Berre wrote:
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
That's cool. Definitely interested in the outcome of that and I know
Sonatype would be willing to help support that effort as well.
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:[email protected]
MCF, CRIL-CNRS UMR 8188, Universite d'Artois
http://www.cril.univ-artois.fr/~leberre
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
