Home » Eclipse Projects » Orbit » ANTLR v3
| ANTLR v3 [message #2775] |
Tue, 11 July 2006 01:46  |
Eclipse User |
|
|
|
Originally posted by: dschaefer.qnx.com
One of the things I've been planning on doing is bring ANTLR version 3
through the Eclipse legal process for inclusion in the CDT. We plan on
using it for building parsers for new languages and language variants as
we add support for them. ANTLR version 2 failed the IP check, but
version 3 is a rewrite and carries the BSD license and should have a
better chance.
I know other projects have expressed interest in using ANTLR and it may
be a good candidate for this project as well.
Cheers,
Doug Schaefer
CDT Project Lead.
|
|
|
| Re: ANTLR v3 [message #6051 is a reply to message #2775] |
Thu, 31 August 2006 17:35  |
| Eclipse User |
|
|
|
Originally posted by: mail.richard-musiol.de
Hi,
at first I have to say that this is a very great project idea. The funny
thing is that I separated the libraries I use from my project some days
ago and thought that there should be such a library-plugin repository.
Now I've found it!
The issue with ANTLR 2 is bad, because other libraries depend on version
2. In my project I use ANTLR 3 so it is only an indirect problem for me.
Also, I want to suggest some other libraries:
- Groovy (http://groovy.codehaus.org)
- ASM (http://asm.objectweb.org/)
- maybe Cobertura (http://cobertura.sourceforge.net)
I don't know if they fulfill your criterias for being added to your
project, so please tell me your opinion.
Another thing which seems important to me is how you will handle
versions which are not downward compatible. Examples are ANTLR 3 or
JUnit 4. As for JUnit it is solved by adding the "4" to the id
"org.junit". So what I want to point out is that you should choose a
naming scheme, e.g. "org.antlr3".
Bye,
Richard Musiol
Doug Schaefer schrieb:
> One of the things I've been planning on doing is bring ANTLR version 3
> through the Eclipse legal process for inclusion in the CDT. We plan on
> using it for building parsers for new languages and language variants as
> we add support for them. ANTLR version 2 failed the IP check, but
> version 3 is a rewrite and carries the BSD license and should have a
> better chance.
>
> I know other projects have expressed interest in using ANTLR and it may
> be a good candidate for this project as well.
>
> Cheers,
> Doug Schaefer
> CDT Project Lead.
|
|
|
| Re: ANTLR v3 [message #6065 is a reply to message #6051] |
Fri, 01 September 2006 02:10 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Richard Musiol wrote:
> Another thing which seems important to me is how you will handle
> versions which are not downward compatible. Examples are ANTLR 3 or
> JUnit 4. As for JUnit it is solved by adding the "4" to the id
> "org.junit". So what I want to point out is that you should choose a
> naming scheme, e.g. "org.antlr3".
You are right that this is important. We have yet to really come up
with a convention that works. Bundles have version numbers so we really
should not have to work the numbers into the symbolic name. In any
event, there are good arguments on both sides and this sort of
discussion should definitely be had. I just want it to be clear that
the choice for junit need not set the model.
Jeff
|
|
|
| Re: ANTLR v3 [message #6158 is a reply to message #6065] |
Sun, 03 September 2006 19:02 |
 Kenneth Ã?lwing
Messages: 167
Registered: July 2009 |
Senior Member |
|
|
Hi folks,
I'm of the general opinion that projects like Orbit that intends to deal
with a completely open set of libraries, should *not* try to define the 'one
and only' way to handle version numbers, naming etc. One size does not fit
all, unfortunately (though, I fully agree that the world would be a better
place if there was - at least in this context ;-)
In Buckminster we take the general approach that naming and version numbers,
among other things, are 'soft' and handled through extpoints that abstracts
out the actual implementations so as to be able to specify that a given
component (i.e. lib, module, subsystem, package, project or whatever other
name you want to put on it) can be declared as to what 'standard' it follows
in order to allow name translation and version magnitude comparison etc. At
runtime, the correct implementation is invoked and will do the appropriate
operation.
A mechanism based on that mindset will be the most flexible, and will avoid
*imposing* a format that all might not want to follow. The last is important
too - rather than saying 'the component must contain a descriptor called
"foo.bar"', Buckminster tries to 'go with the flow' and is able to read
several different descriptors (like Eclipse plugin.xml, feature.xml etc, and
Maven POM's to mention a few) and in runtime translate to the Buckminster
canonical format. For components with no history, they can obviously contain
the canonical format (what we call a 'cspec') directly.
In short, what I'm saying is that while there should still be a 'preferred'
or 'best practice' approach, it should not be mandatory. As an example, the
version comparators we have today in Buckminster are 'String' (pure string
comparisons), and OSGi style - so at this time, for anything else, 'someone'
needs to write a comparator implementation for it.
ken1
"Jeff McAffer" <jeff_mcaffer@REMOVE.ca.ibm.com> wrote in message
news:ed84u4$bri$1@utils.eclipse.org...
> Richard Musiol wrote:
>> Another thing which seems important to me is how you will handle versions
>> which are not downward compatible. Examples are ANTLR 3 or JUnit 4. As
>> for JUnit it is solved by adding the "4" to the id "org.junit". So what I
>> want to point out is that you should choose a naming scheme, e.g.
>> "org.antlr3".
>
> You are right that this is important. We have yet to really come up with
> a convention that works. Bundles have version numbers so we really should
> not have to work the numbers into the symbolic name. In any event, there
> are good arguments on both sides and this sort of discussion should
> definitely be had. I just want it to be clear that the choice for junit
> need not set the model.
>
> Jeff
|
|
|
| Re: ANTLR v3 [message #6171 is a reply to message #6158] |
Mon, 04 September 2006 00:14 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
ken1 (Kenneth Ölwing) wrote:
> Hi folks,
>
> I'm of the general opinion that projects like Orbit that intends to deal
> with a completely open set of libraries, should *not* try to define the 'one
> and only' way to handle version numbers, naming etc. One size does not fit
> all, unfortunately (though, I fully agree that the world would be a better
> place if there was - at least in this context ;-)
In general I agree however the point at hand is the value of the OSGi
Bundle-SymbolicName and Bundle-Version headers. For better or worse,
both of these have specific semantics as defined in the OSGi spec. As
such, the choice for these values may turn out to be important. Clearly
people can do what they want but we should have a convention.
Orbit is about defining/providing OSGi bundled versions of non-bundled
JARs. We cannot get into changing how bundles are identified or
versioned. Introducing the abstraction you outline would be cool but is
either a runtime or provisioning issue best dealt with in Equinox and
the wider OSGi community. Here we are just trying to provide a bundle.
Jeff
|
|
|
| Re: ANTLR v3 [message #6260 is a reply to message #6171] |
Mon, 04 September 2006 06:22 |
|
Jeff McAffer wrote:
> ken1 (Kenneth Ölwing) wrote:
>> Hi folks,
>>
>> I'm of the general opinion that projects like Orbit that intends to
>> deal with a completely open set of libraries, should *not* try to
>> define the 'one and only' way to handle version numbers, naming etc.
>> One size does not fit all, unfortunately (though, I fully agree that
>> the world would be a better place if there was - at least in this
>> context ;-)
>
> In general I agree however the point at hand is the value of the OSGi
> Bundle-SymbolicName and Bundle-Version headers. For better or worse,
> both of these have specific semantics as defined in the OSGi spec. As
> such, the choice for these values may turn out to be important. Clearly
> people can do what they want but we should have a convention.
>
> Orbit is about defining/providing OSGi bundled versions of non-bundled
> JARs. We cannot get into changing how bundles are identified or
> versioned. Introducing the abstraction you outline would be cool but is
> either a runtime or provisioning issue best dealt with in Equinox and
> the wider OSGi community. Here we are just trying to provide a bundle.
>
Buckminster has a similar goal. We want to provide jars as installable features and since
the update manager and the whole Eclipse infra-structure is built with the assumption that
everything uses OSGi style versions, we need to come up with an unambiguous way of mapping
arbitrary (non-conformant) version numbers.
We are thinking of using an extension point where new version types can be installed. The
interface that this extension point must adhere to is basically:
boolean canHandle(String version);
String toOSGiVersion(String version);
String fromOSGiVersion(String osgiVersion);
The first method returns false if the type is unable to parse the input.
Each time a version is encountered, a chain of such instances should be perused. The first
one that returns true on a call to canHandle() will be used. The first instance in that
chain is of course the OSGi version type itself. The last instance will always return true.
It is a String type that simply convert the version to 1.0.0.<original version>, i.e. it
uses the version as the OSGi qualifier part (possibly mangling '.'s to underscore or
similar, escaping etc. must be in place too in order to permit bidirectional translation).
I see two problems with this approach though:
1. The chain of versions must be ordered to give predictable results. How would that
ordering come in place?
2. Who controls adding of types? The user of Eclipse, Orbit?, Buckminster?, Eclipse?
In Buckminster those issues are easy to resolve. We plan to define a list in a provider (an
entity that appoints a repository using a specific reader type and component type) that
denotes that the provider will support specific versions in a specific order. If Orbit can
be seen as one provider, then Orbit could have one preset list like this. If Orbit is to
become more dynamic, then I think you should use Buckminster :-)
In any case, I think it's essential that we have the same take on how the mappings will be
performed.
Thoughs?
Regards,
Thomas Hallgren
|
|
|
| Re: ANTLR v3 [message #7541 is a reply to message #6260] |
Thu, 07 September 2006 13:58 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
This makes sense. The question I have though is where do you see this
being integrated? It would be challenging to put the version
translation at the OSGi level (e.g., the extension registry does not
exist at that level). So the translation has to happen either when
bundles are built or when they are provisioned. Both of those seem like
possibilities.
Perhaps you could outline the process by which some external JAR comes
in and is converted to a bundle and where/when/how the translation happens?
Jeff
Thomas Hallgren wrote:
> Jeff McAffer wrote:
>> ken1 (Kenneth Ölwing) wrote:
>>> Hi folks,
>>>
>>> I'm of the general opinion that projects like Orbit that intends to
>>> deal with a completely open set of libraries, should *not* try to
>>> define the 'one and only' way to handle version numbers, naming etc.
>>> One size does not fit all, unfortunately (though, I fully agree that
>>> the world would be a better place if there was - at least in this
>>> context ;-)
>>
>> In general I agree however the point at hand is the value of the OSGi
>> Bundle-SymbolicName and Bundle-Version headers. For better or worse,
>> both of these have specific semantics as defined in the OSGi spec. As
>> such, the choice for these values may turn out to be important.
>> Clearly people can do what they want but we should have a convention.
>>
>> Orbit is about defining/providing OSGi bundled versions of non-bundled
>> JARs. We cannot get into changing how bundles are identified or
>> versioned. Introducing the abstraction you outline would be cool but
>> is either a runtime or provisioning issue best dealt with in Equinox
>> and the wider OSGi community. Here we are just trying to provide a
>> bundle.
>>
> Buckminster has a similar goal. We want to provide jars as installable
> features and since the update manager and the whole Eclipse
> infra-structure is built with the assumption that everything uses OSGi
> style versions, we need to come up with an unambiguous way of mapping
> arbitrary (non-conformant) version numbers.
>
> We are thinking of using an extension point where new version types can
> be installed. The interface that this extension point must adhere to is
> basically:
>
> boolean canHandle(String version);
>
> String toOSGiVersion(String version);
>
> String fromOSGiVersion(String osgiVersion);
>
> The first method returns false if the type is unable to parse the input.
>
> Each time a version is encountered, a chain of such instances should be
> perused. The first one that returns true on a call to canHandle() will
> be used. The first instance in that chain is of course the OSGi version
> type itself. The last instance will always return true. It is a String
> type that simply convert the version to 1.0.0.<original version>, i.e.
> it uses the version as the OSGi qualifier part (possibly mangling '.'s
> to underscore or similar, escaping etc. must be in place too in order to
> permit bidirectional translation).
>
> I see two problems with this approach though:
>
> 1. The chain of versions must be ordered to give predictable results.
> How would that ordering come in place?
>
> 2. Who controls adding of types? The user of Eclipse, Orbit?,
> Buckminster?, Eclipse?
>
> In Buckminster those issues are easy to resolve. We plan to define a
> list in a provider (an entity that appoints a repository using a
> specific reader type and component type) that denotes that the provider
> will support specific versions in a specific order. If Orbit can be seen
> as one provider, then Orbit could have one preset list like this. If
> Orbit is to become more dynamic, then I think you should use Buckminster
> :-)
>
> In any case, I think it's essential that we have the same take on how
> the mappings will be performed.
>
> Thoughs?
>
> Regards,
> Thomas Hallgren
>
|
|
|
| Re: ANTLR v3 [message #7560 is a reply to message #7541] |
Mon, 18 September 2006 13:17 |
|
Hi Jeff,
Sorry for a somewhat late reply on this. I've been traveling (Eclipse Build Workshop in
Portland).
Jeff McAffer wrote:
> This makes sense. The question I have though is where do you see this
> being integrated? It would be challenging to put the version
> translation at the OSGi level (e.g., the extension registry does not
> exist at that level). So the translation has to happen either when
> bundles are built or when they are provisioned. Both of those seem like
> possibilities.
>
> Perhaps you could outline the process by which some external JAR comes
> in and is converted to a bundle and where/when/how the translation happens?
>
The way I envision it would happen using Buckminster is that we provide a customization to
the update manager that would be able to scan a repository, say the Maven repo at IBiblio.
The information that it obtains would be presented as a set of features. Each feature would
correspond to one bundle that in turn corresponds to the jar and use the same name as for
the bundle with an added '.feature' postfix. The feature and bundle would use the same version.
The overhead incurred using a feature is motivated by the fact that features are the only
things that the update manager can manage.
The mapping between the bundle and the jar file would in our case be automatic. The name
and version mapping would be performed using the Buckminster resolver map where a set of
rules or direct mappings (group-id, artifact-id, in case of maven) can be added.
If this is similar to what Orbit is about to do manually, then the rules applied for name
mapping, version mapping etc. should be the same.
Regards,
Thomas Hallgren
> Thomas Hallgren wrote:
>> Buckminster has a similar goal. We want to provide jars as installable
>> features and since the update manager and the whole Eclipse
>> infra-structure is built with the assumption that everything uses OSGi
>> style versions, we need to come up with an unambiguous way of mapping
>> arbitrary (non-conformant) version numbers.
>>
>> We are thinking of using an extension point where new version types
>> can be installed. The interface that this extension point must adhere
>> to is basically:
>>
>> boolean canHandle(String version);
>>
>> String toOSGiVersion(String version);
>>
>> String fromOSGiVersion(String osgiVersion);
>>
>> The first method returns false if the type is unable to parse the input.
>>
>> Each time a version is encountered, a chain of such instances should
>> be perused. The first one that returns true on a call to canHandle()
>> will be used. The first instance in that chain is of course the OSGi
>> version type itself. The last instance will always return true. It is
>> a String type that simply convert the version to 1.0.0.<original
>> version>, i.e. it uses the version as the OSGi qualifier part
>> (possibly mangling '.'s to underscore or similar, escaping etc. must
>> be in place too in order to permit bidirectional translation).
>>
>> I see two problems with this approach though:
>>
>> 1. The chain of versions must be ordered to give predictable results.
>> How would that ordering come in place?
>>
>> 2. Who controls adding of types? The user of Eclipse, Orbit?,
>> Buckminster?, Eclipse?
>>
>> In Buckminster those issues are easy to resolve. We plan to define a
>> list in a provider (an entity that appoints a repository using a
>> specific reader type and component type) that denotes that the
>> provider will support specific versions in a specific order. If Orbit
>> can be seen as one provider, then Orbit could have one preset list
>> like this. If Orbit is to become more dynamic, then I think you should
>> use Buckminster :-)
>>
>> In any case, I think it's essential that we have the same take on how
>> the mappings will be performed.
>>
>> Thoughs?
>>
>> Regards,
>> Thomas Hallgren
>>
|
|
| | |
| Re: ANTLR v3 [message #561461 is a reply to message #6065] |
Sun, 03 September 2006 19:02 |
Kenneth Ã?lwing
Messages: 167
Registered: July 2009 |
Senior Member |
|
|
Hi folks,
I'm of the general opinion that projects like Orbit that intends to deal
with a completely open set of libraries, should *not* try to define the 'one
and only' way to handle version numbers, naming etc. One size does not fit
all, unfortunately (though, I fully agree that the world would be a better
place if there was - at least in this context ;-)
In Buckminster we take the general approach that naming and version numbers,
among other things, are 'soft' and handled through extpoints that abstracts
out the actual implementations so as to be able to specify that a given
component (i.e. lib, module, subsystem, package, project or whatever other
name you want to put on it) can be declared as to what 'standard' it follows
in order to allow name translation and version magnitude comparison etc. At
runtime, the correct implementation is invoked and will do the appropriate
operation.
A mechanism based on that mindset will be the most flexible, and will avoid
*imposing* a format that all might not want to follow. The last is important
too - rather than saying 'the component must contain a descriptor called
"foo.bar"', Buckminster tries to 'go with the flow' and is able to read
several different descriptors (like Eclipse plugin.xml, feature.xml etc, and
Maven POM's to mention a few) and in runtime translate to the Buckminster
canonical format. For components with no history, they can obviously contain
the canonical format (what we call a 'cspec') directly.
In short, what I'm saying is that while there should still be a 'preferred'
or 'best practice' approach, it should not be mandatory. As an example, the
version comparators we have today in Buckminster are 'String' (pure string
comparisons), and OSGi style - so at this time, for anything else, 'someone'
needs to write a comparator implementation for it.
ken1
"Jeff McAffer" <jeff_mcaffer@REMOVE.ca.ibm.com> wrote in message
news:ed84u4$bri$1@utils.eclipse.org...
> Richard Musiol wrote:
>> Another thing which seems important to me is how you will handle versions
>> which are not downward compatible. Examples are ANTLR 3 or JUnit 4. As
>> for JUnit it is solved by adding the "4" to the id "org.junit". So what I
>> want to point out is that you should choose a naming scheme, e.g.
>> "org.antlr3".
>
> You are right that this is important. We have yet to really come up with
> a convention that works. Bundles have version numbers so we really should
> not have to work the numbers into the symbolic name. In any event, there
> are good arguments on both sides and this sort of discussion should
> definitely be had. I just want it to be clear that the choice for junit
> need not set the model.
>
> Jeff
|
|
| |
| Re: ANTLR v3 [message #561597 is a reply to message #6171] |
Mon, 04 September 2006 06:22 |
|
Jeff McAffer wrote:
> ken1 (Kenneth Ölwing) wrote:
>> Hi folks,
>>
>> I'm of the general opinion that projects like Orbit that intends to
>> deal with a completely open set of libraries, should *not* try to
>> define the 'one and only' way to handle version numbers, naming etc.
>> One size does not fit all, unfortunately (though, I fully agree that
>> the world would be a better place if there was - at least in this
>> context ;-)
>
> In general I agree however the point at hand is the value of the OSGi
> Bundle-SymbolicName and Bundle-Version headers. For better or worse,
> both of these have specific semantics as defined in the OSGi spec. As
> such, the choice for these values may turn out to be important. Clearly
> people can do what they want but we should have a convention.
>
> Orbit is about defining/providing OSGi bundled versions of non-bundled
> JARs. We cannot get into changing how bundles are identified or
> versioned. Introducing the abstraction you outline would be cool but is
> either a runtime or provisioning issue best dealt with in Equinox and
> the wider OSGi community. Here we are just trying to provide a bundle.
>
Buckminster has a similar goal. We want to provide jars as installable features and since
the update manager and the whole Eclipse infra-structure is built with the assumption that
everything uses OSGi style versions, we need to come up with an unambiguous way of mapping
arbitrary (non-conformant) version numbers.
We are thinking of using an extension point where new version types can be installed. The
interface that this extension point must adhere to is basically:
boolean canHandle(String version);
String toOSGiVersion(String version);
String fromOSGiVersion(String osgiVersion);
The first method returns false if the type is unable to parse the input.
Each time a version is encountered, a chain of such instances should be perused. The first
one that returns true on a call to canHandle() will be used. The first instance in that
chain is of course the OSGi version type itself. The last instance will always return true.
It is a String type that simply convert the version to 1.0.0.<original version>, i.e. it
uses the version as the OSGi qualifier part (possibly mangling '.'s to underscore or
similar, escaping etc. must be in place too in order to permit bidirectional translation).
I see two problems with this approach though:
1. The chain of versions must be ordered to give predictable results. How would that
ordering come in place?
2. Who controls adding of types? The user of Eclipse, Orbit?, Buckminster?, Eclipse?
In Buckminster those issues are easy to resolve. We plan to define a list in a provider (an
entity that appoints a repository using a specific reader type and component type) that
denotes that the provider will support specific versions in a specific order. If Orbit can
be seen as one provider, then Orbit could have one preset list like this. If Orbit is to
become more dynamic, then I think you should use Buckminster :-)
In any case, I think it's essential that we have the same take on how the mappings will be
performed.
Thoughs?
Regards,
Thomas Hallgren
|
|
|
| Re: ANTLR v3 [message #561680 is a reply to message #6260] |
Thu, 07 September 2006 13:58 |
Jeff McAffer
Messages: 104
Registered: July 2009 |
Senior Member |
|
|
This makes sense. The question I have though is where do you see this
being integrated? It would be challenging to put the version
translation at the OSGi level (e.g., the extension registry does not
exist at that level). So the translation has to happen either when
bundles are built or when they are provisioned. Both of those seem like
possibilities.
Perhaps you could outline the process by which some external JAR comes
in and is converted to a bundle and where/when/how the translation happens?
Jeff
Thomas Hallgren wrote:
> Jeff McAffer wrote:
>> ken1 (Kenneth Ölwing) wrote:
>>> Hi folks,
>>>
>>> I'm of the general opinion that projects like Orbit that intends to
>>> deal with a completely open set of libraries, should *not* try to
>>> define the 'one and only' way to handle version numbers, naming etc.
>>> One size does not fit all, unfortunately (though, I fully agree that
>>> the world would be a better place if there was - at least in this
>>> context ;-)
>>
>> In general I agree however the point at hand is the value of the OSGi
>> Bundle-SymbolicName and Bundle-Version headers. For better or worse,
>> both of these have specific semantics as defined in the OSGi spec. As
>> such, the choice for these values may turn out to be important.
>> Clearly people can do what they want but we should have a convention.
>>
>> Orbit is about defining/providing OSGi bundled versions of non-bundled
>> JARs. We cannot get into changing how bundles are identified or
>> versioned. Introducing the abstraction you outline would be cool but
>> is either a runtime or provisioning issue best dealt with in Equinox
>> and the wider OSGi community. Here we are just trying to provide a
>> bundle.
>>
> Buckminster has a similar goal. We want to provide jars as installable
> features and since the update manager and the whole Eclipse
> infra-structure is built with the assumption that everything uses OSGi
> style versions, we need to come up with an unambiguous way of mapping
> arbitrary (non-conformant) version numbers.
>
> We are thinking of using an extension point where new version types can
> be installed. The interface that this extension point must adhere to is
> basically:
>
> boolean canHandle(String version);
>
> String toOSGiVersion(String version);
>
> String fromOSGiVersion(String osgiVersion);
>
> The first method returns false if the type is unable to parse the input.
>
> Each time a version is encountered, a chain of such instances should be
> perused. The first one that returns true on a call to canHandle() will
> be used. The first instance in that chain is of course the OSGi version
> type itself. The last instance will always return true. It is a String
> type that simply convert the version to 1.0.0.<original version>, i.e.
> it uses the version as the OSGi qualifier part (possibly mangling '.'s
> to underscore or similar, escaping etc. must be in place too in order to
> permit bidirectional translation).
>
> I see two problems with this approach though:
>
> 1. The chain of versions must be ordered to give predictable results.
> How would that ordering come in place?
>
> 2. Who controls adding of types? The user of Eclipse, Orbit?,
> Buckminster?, Eclipse?
>
> In Buckminster those issues are easy to resolve. We plan to define a
> list in a provider (an entity that appoints a repository using a
> specific reader type and component type) that denotes that the provider
> will support specific versions in a specific order. If Orbit can be seen
> as one provider, then Orbit could have one preset list like this. If
> Orbit is to become more dynamic, then I think you should use Buckminster
> :-)
>
> In any case, I think it's essential that we have the same take on how
> the mappings will be performed.
>
> Thoughs?
>
> Regards,
> Thomas Hallgren
>
|
|
|
| Re: ANTLR v3 [message #561701 is a reply to message #7541] |
Mon, 18 September 2006 13:17 |
|
Hi Jeff,
Sorry for a somewhat late reply on this. I've been traveling (Eclipse Build Workshop in
Portland).
Jeff McAffer wrote:
> This makes sense. The question I have though is where do you see this
> being integrated? It would be challenging to put the version
> translation at the OSGi level (e.g., the extension registry does not
> exist at that level). So the translation has to happen either when
> bundles are built or when they are provisioned. Both of those seem like
> possibilities.
>
> Perhaps you could outline the process by which some external JAR comes
> in and is converted to a bundle and where/when/how the translation happens?
>
The way I envision it would happen using Buckminster is that we provide a customization to
the update manager that would be able to scan a repository, say the Maven repo at IBiblio.
The information that it obtains would be presented as a set of features. Each feature would
correspond to one bundle that in turn corresponds to the jar and use the same name as for
the bundle with an added '.feature' postfix. The feature and bundle would use the same version.
The overhead incurred using a feature is motivated by the fact that features are the only
things that the update manager can manage.
The mapping between the bundle and the jar file would in our case be automatic. The name
and version mapping would be performed using the Buckminster resolver map where a set of
rules or direct mappings (group-id, artifact-id, in case of maven) can be added.
If this is similar to what Orbit is about to do manually, then the rules applied for name
mapping, version mapping etc. should be the same.
Regards,
Thomas Hallgren
> Thomas Hallgren wrote:
>> Buckminster has a similar goal. We want to provide jars as installable
>> features and since the update manager and the whole Eclipse
>> infra-structure is built with the assumption that everything uses OSGi
>> style versions, we need to come up with an unambiguous way of mapping
>> arbitrary (non-conformant) version numbers.
>>
>> We are thinking of using an extension point where new version types
>> can be installed. The interface that this extension point must adhere
>> to is basically:
>>
>> boolean canHandle(String version);
>>
>> String toOSGiVersion(String version);
>>
>> String fromOSGiVersion(String osgiVersion);
>>
>> The first method returns false if the type is unable to parse the input.
>>
>> Each time a version is encountered, a chain of such instances should
>> be perused. The first one that returns true on a call to canHandle()
>> will be used. The first instance in that chain is of course the OSGi
>> version type itself. The last instance will always return true. It is
>> a String type that simply convert the version to 1.0.0.<original
>> version>, i.e. it uses the version as the OSGi qualifier part
>> (possibly mangling '.'s to underscore or similar, escaping etc. must
>> be in place too in order to permit bidirectional translation).
>>
>> I see two problems with this approach though:
>>
>> 1. The chain of versions must be ordered to give predictable results.
>> How would that ordering come in place?
>>
>> 2. Who controls adding of types? The user of Eclipse, Orbit?,
>> Buckminster?, Eclipse?
>>
>> In Buckminster those issues are easy to resolve. We plan to define a
>> list in a provider (an entity that appoints a repository using a
>> specific reader type and component type) that denotes that the
>> provider will support specific versions in a specific order. If Orbit
>> can be seen as one provider, then Orbit could have one preset list
>> like this. If Orbit is to become more dynamic, then I think you should
>> use Buckminster :-)
>>
>> In any case, I think it's essential that we have the same take on how
>> the mappings will be performed.
>>
>> Thoughs?
>>
>> Regards,
>> Thomas Hallgren
>>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 19:41:45 GMT 2024
Powered by FUDForum. Page generated in 0.03861 seconds |
] 
Search
Help
Register
Login
Home
