You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Daniel Le Berre <le...@cril.univ-artois.fr> on 2009/01/07 13:03:50 UTC
Information about version ranges management from Eclipse p2
Dear all,
There was a discussion about version ranges management a few weeks ago
on the ML.
I think that the following document from Eclipse p2 could be of interest:
http://wiki.eclipse.org/Equinox/p2/Proposals/Version_Type_Proposal
Daniel
--
Daniel Le Berre mailto:leberre@cril.univ-artois.fr
MCF, CRIL-CNRS UMR 8188, Universite d'Artois
http://www.cril.univ-artois.fr/~leberre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Information about version ranges management from Eclipse p2
Posted by Jason van Zyl <jv...@sonatype.com>.
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:leberre@cril.univ-artois.fr
> MCF, CRIL-CNRS UMR 8188, Universite d'Artois
> http://www.cril.univ-artois.fr/~leberre
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Information about version ranges management from Eclipse p2
Posted by Daniel Le Berre <le...@cril.univ-artois.fr>.
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:leberre@cril.univ-artois.fr
MCF, CRIL-CNRS UMR 8188, Universite d'Artois
http://www.cril.univ-artois.fr/~leberre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Information about version ranges management from Eclipse p2
Posted by Jason van Zyl <jv...@sonatype.com>.
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?
>
> 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'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 :-)
>
>
> Daniel
>
>> On 7-Jan-09, at 7:03 AM, Daniel Le Berre wrote:
>>
>>> Dear all,
>>>
>>> There was a discussion about version ranges management a few weeks
>>> ago
>>> on the ML.
>>>
>>> I think that the following document from Eclipse p2 could be of
>>> interest:
>>> http://wiki.eclipse.org/Equinox/p2/Proposals/Version_Type_Proposal
>>>
>>> Daniel
>>> --
>>> Daniel Le Berre mailto:leberre@cril.univ-artois.fr
>>> MCF, CRIL-CNRS UMR 8188, Universite d'Artois
>>> http://www.cril.univ-artois.fr/~leberre
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> Selfish deeds are the shortest path to self destruction.
>>
>> -- The Seven Samuari, Akira Kurosawa
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>
>
> --
> Daniel Le Berre mailto:leberre@cril.univ-artois.fr
> MCF, CRIL-CNRS UMR 8188, Universite d'Artois
> http://www.cril.univ-artois.fr/~leberre
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Information about version ranges management from Eclipse p2
Posted by Daniel Le Berre <le...@cril.univ-artois.fr>.
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.
This requires the use of SAT4J API directly, not through text files as
currently.
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'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?
Daniel
> On 7-Jan-09, at 7:03 AM, Daniel Le Berre wrote:
>
>> Dear all,
>>
>> There was a discussion about version ranges management a few weeks ago
>> on the ML.
>>
>> I think that the following document from Eclipse p2 could be of interest:
>> http://wiki.eclipse.org/Equinox/p2/Proposals/Version_Type_Proposal
>>
>> Daniel
>> --
>> Daniel Le Berre mailto:leberre@cril.univ-artois.fr
>> MCF, CRIL-CNRS UMR 8188, Universite d'Artois
>> http://www.cril.univ-artois.fr/~leberre
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> Selfish deeds are the shortest path to self destruction.
>
> -- The Seven Samuari, Akira Kurosawa
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
Daniel Le Berre mailto:leberre@cril.univ-artois.fr
MCF, CRIL-CNRS UMR 8188, Universite d'Artois
http://www.cril.univ-artois.fr/~leberre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Information about version ranges management from Eclipse p2
Posted by Jason van Zyl <jv...@sonatype.com>.
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?
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.
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?
On 7-Jan-09, at 7:03 AM, Daniel Le Berre wrote:
> Dear all,
>
> There was a discussion about version ranges management a few weeks ago
> on the ML.
>
> I think that the following document from Eclipse p2 could be of
> interest:
> http://wiki.eclipse.org/Equinox/p2/Proposals/Version_Type_Proposal
>
> Daniel
> --
> Daniel Le Berre mailto:leberre@cril.univ-artois.fr
> MCF, CRIL-CNRS UMR 8188, Universite d'Artois
> http://www.cril.univ-artois.fr/~leberre
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kurosawa
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org