Hi Jonas,
Please find answers inline
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
Right. this has been fixed to use SI where appropriate. - 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.
It’s not just the same bundle (logical name) but other bundles that rely on dependencies that intersect but require different (probably binary incompatible) versions. - 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.
Version ranges cause unreproducible builds, it’s in their nature. The only way to prevent version ranges from wreaking havoc is to strictly control all dependencies sources so that unwanted versions get added. This means *every* single vendor and customer must put additional rules in place, such as custom repository proxies in order to filter out unwanted versions. I agree that there’s a growing number of vendors and customers that already have such proxies, but what needs to happen here is asking to closing down the firehose with a tweezer. Banning version ranges solves the problem directly from the root. Our position on version ranges stands regardless of OSGi bundles or not, it applies to regular JAR dependencies too. - 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.
Yes, it’s relatively simple to transform any JAR dependency into an OSGi bundle, BND tools can take care of that. However you must locate compatible dependencies for the new bundle. There may be the case that such bundles already exist, or that an updated bundle must be produced. Also, those dependencies may be pulled in into the bundle’s private classpath. This is what many developers do (based on our experience with several customers) in order to avoid the next step: creating bundles for every other dependency because those dependencies are not bundles. This basically boils down to where do you draw the line when transforming a JAR into a bundle. - 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
This section is about the provisioning the development environment, that is, setting up the tool chain and IDE, not provisioning the product. - summary: section " when it comes..." There is lots of public documentation about Tycho.
The main site is poor even compared with standard Maven. 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
Not really, no. Tycho imposes it’s own conventions over Maven builds. Tests must be placed under different projects because the Tycho can’t find them if placed in the same project s the production code, this means that the standard location for src/test/java in the production bundle is useless. Tycho test forces the tests to be placed under src/main/java, again breaking the convention of src/test/java, where other tools expect it. It’s true that code quality tools could do better and rally inspect the project configuration and adapt to changes in the conventions, many of them do, but not all. This is why things go sour when your project deviates form the Maven conventions. It’s n inherent problem in the Maven space, Tycho makes it a bit worse by imposing a set of conventions that others tools can’t handle because they don’t react accordingly. - 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?
We can pick the best one that adapts to our needs, not the other way around. The number of options does not imply that OpenMDM components will be built using disparate set of tools, there must be a ”certified” stack and tool chain, with options for substitutions where applicable. - 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.
Yes, the metadata is needed by OSGi, after all is part of its specification. Tycho builds upon this definition and tries to make it work. A Matrix as Andreas suggested is a good idea to see a subjective comparison.
The matrix will be ready in the next version. 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
_______________________________________________
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
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
|
