Hi,
Sorry for typos, I am writing on a mobile device. Some comments:
- a SPI is IMHO an interface to be implemented by service providers. If I understand correctly, the current usage of the term in the document sounds more like "service interface". As there are different rules for the versioning of SPIs, this would be an important difference - 4.6 mentions eclipse plugins and osgi bundles, I am not aware of a relevant difference from the POV of Tycho - 5.1 describes the ability to configure package visibilties and class paths. Although this is an important feature, I did not expect this for the respective requirement, but rather OSGIs ability to have the same bundle in different versions at runtime. - 5.2 "version ranges are seen as bad practice": in the Eclipse ecosystem, around 200 projects deliver over the 1000 bundles based on version ranges. OSGI defines clear rules about compatibility. The build should not configured with bundle dependencies, but with the target definition, which makes it reproducible. It is an open discussion, when and if upper version ranges should be set (e.g. Through the build), but I would consider it as bad practice to not use version ranges in OSGi. This is especially true, if products or features can be combined by adopters and users, as a fixed version might make that impossible. - Summary: it is really simple to transform a third party jar into a bundle. The main benefit of the orbit project is that the ip team reviews the compatibility of the license. Enabling any developer to include any kind of third party jar without review sounds dangerous in terms of the ip policy. - Summary: the section starting with "next comes..." Sounds a bit subjective. Building up a product including over 1000 bundles created by hundreds of developers is a complex problem per se, no matter which technology is used - summary: section " when it comes..." There is lots of public documentation about Tycho. I do not agree with the statements about testing. Running analyses, sonar and plain unit tests is not an issue at all (that would be really bad ;-). You can use any kind of maven plugin. This makes IMHO the last paragraph in section 6 irrelevant - summary : "to begin..." I am not sure if using different tools from many different vendors and different release cycles can be count as an advantage? - the additional meta data is considered to be a pain in the last section. However, important features, such a API definition and dependency management are based on it. The summary is very focussed on pointing out disadvantages of OSGi/tycho, with some of them I would disagree. A Matrix as Andreas suggested is a good idea to see a subjective comparison.
Just my two cents
Best regards
Jonas
Von meinem iPhone gesendet Dear all,
Any comments and feedback on the linked document (see attachment on previous message) are greatly appreciated.
Cheers, Andres
Dear all,
I’m attaching a rendered copy of the document to his message.
Cheers, Andres
Hello everyone,
As most of you have noticed, the recent Architecture Draft document makes no mention of OSGi at all. The main reason behind this is that the architecture per se is defined in terms of logical structures and not technologies (although some JSRs are mentioned however their usage does not contradict OSGi if it were to be a chosen technology). The architecture can be decided in 3 layers:
#1 paints a picture of how pieces fall together into the puzzle. This is what you currently see in the document. #2 defines the technologies that can fulfil the architecture. OSGi is a candidate technology. #3 defines the products that supply the technologies. Eclipse Equinox is a container that provides OSGi support.
Given that the majority of stakeholders have agreed so far that the architecture is sound, we can proceed with selecting the technologies that can realise it. Perhaps one of the reasons why the topic “why OSGi is not mentioned?” arises is that there’s a previous document (the OpenMDM Tag dated Feb 2014) where OSGi was a selected technology. This decision was made at a time where the requirements were known. However requirements have change since, most notably:
- do not reuse code from OpenMDM4. Components must be designed afresh. - UI independence. - remove dependency on CORBA as much as possible.
The proposed architecture addressed these concerns (you’ll find them listed as main drivers at the beginning of the document).
During a meeting of the Architecture project we decided to come up with a matrix of options to be able to select a candidate technology that can fulfil many of the architecture goals and design. The following entries were identified:
- service lifecycle. Start/Stop. Implies a bootstrapping mechanism or container of sorts. - configuration of services. - service discovery. - service connection. Services can establish a link (local and/remote) to other services in order to consume their behaviour. - dependencies between services. - failover. Shutdown a misbehaving service. Bring back a dead service. - supporting different versions of the same library in the same process. This means a service may bring dependencies whose versions are incompatible with another one within the same container, still both services can work in unison.
As you may notice OSGi and OSGi containers fulfil most of these requirements however there are other technologies that can make it happen too. Please remember that OSGi was proposed and developed at a time (more than 10 years ago) where alternatives were not ready. It’s 2015 and we have those alternatives at hand. We also have to think about the future of the platform as a whole.
Without further ado, I’d like to ask you if there are any other requirements that you may see must be covered by this matrix. I’ll compile all results and generate the matrix with candidate technologies for review next week. Please reply with suggestions at your earliest convenience.
Cheers, Andres
open-measured-data-wg mailing list
open-measured-data-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/open-measured-data-wg
|
