Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdmbl-dev] Unexpected changes to OpenMDM API
Hi Angelika,

I’m confused about the download procedure. I suppose the link is https://projects.eclipse.org/projects/technology.mdmbl/downloads as https://www.eclipse.org/projects/tools/downloads.php?id=technology.mdmbl just goes in circles. The download button at https://www.openmdm.org/ points to https://www.eclipse.org/downloads/ which is nothing related to mdmbl. The yellow download button at https://projects.eclipse.org/projects/technology.mdmbl/downloads redirects to http://git.eclipse.org/c/mdmbl/org.eclipse.mdmbl.git/tree/Releases/V0.8 which is a link to Git visible on Gerrit.
Clicking on the zip results on a raw view of the zip file, not a download per se. 
Are we supposed to do a git checkout on that repository in order to download the zip file? I sure hoped binaries would be available from some other medium, like an FTP server, an artifact repository or a wiki page.

The version I’m referring to is the latest found at the source repository. As I mentioned there are a couple of tags such as 0.7 and 0.8, but the build sets version 1.0.0 and remains unchanged for a while. Thus if you build the mdmbl project from scratch you end up with an artifact that has 1.0.0 in its filename, not 0.8, hence the confusion.

Just for fun, I cloned the repository and unpacked the zip file. Inside I found org.eclipse.mdm.nucleus.war which contains

 43K Aug  7 06:45 nanocontainer-remoting-1.0-RC-1.jar
124K Sep  9 02:53 org.eclipse.mdm.api.base-1.0.0.jar
 48K Sep  9 02:53 org.eclipse.mdm.api.default-1.0.0.jar
896K Sep 10 02:53 org.eclipse.mdm.api.odsadapter-1.0.0.jar
5.1K Sep 11 02:58 org.eclipse.mdm.application-1.0.0.jar
 84K Sep 11 02:58 org.eclipse.mdm.businessobjects-1.0.0.jar
9.3K Sep 11 02:58 org.eclipse.mdm.connector-1.0.0.jar
 34K Sep 11 02:58 org.eclipse.mdm.filerelease-1.0.0.jar
 15K Sep 11 02:58 org.eclipse.mdm.freetextindexer-1.0.0.jar
 25K Sep 11 02:58 org.eclipse.mdm.preferences-1.0.0.jar
3.7K Sep 11 02:58 org.eclipse.mdm.property-1.0.0.jar

As you can appreciate all artifacts have 1.0.0 as version in their filenames. Running javap on the Core class yields

$ javap org.eclipse.mdm.api.base.model.Core
Compiled from "Core.java"
public interface org.eclipse.mdm.api.base.model.Core {
  public abstract java.lang.String getSourceName();
  public abstract java.lang.String getTypeName();
  public abstract java.lang.String getID();
  public abstract void setID(java.lang.String);
  public abstract java.util.Map<java.lang.String, org.eclipse.mdm.api.base.model.Value> getValues();
  public abstract void hideValues(java.util.Collection<java.lang.String>);
  public abstract java.util.Map<java.lang.String, org.eclipse.mdm.api.base.model.Value> getAllValues();
  public java.util.List<org.eclipse.mdm.api.base.model.FileLink> getAddedFileLinks();
  public java.util.List<org.eclipse.mdm.api.base.model.FileLink> getRemovedFileLinks();
  public void apply();
  public abstract org.eclipse.mdm.api.base.model.Core$EntityStore getMutableStore();
  public abstract org.eclipse.mdm.api.base.model.Core$EntityStore getPermanentStore();
  public abstract org.eclipse.mdm.api.base.model.Core$ChildrenStore getChildrenStore();
}

Thus the breaking change in binary compatibility is already found in v0.8. Any previous code that links to this version must now be updated to cope with the API changes.
In all fairness this breaking change was introduced in v0.7 (as shown in the releasenotes http://git.eclipse.org/c/mdmbl/org.eclipse.mdmbl.git/plain/Releases/V0.8/release_notes.md) due to https://openmdm.atlassian.net/browse/REQU-48.

Please bring this up with the QC as well. If there’s a document stating the rules of the game then it must be visible to everyone.

Cheers,
Andres

 
Andres Almiray
Canoo Engineering AG
Kirschgartenstrasse 5
CH-4051 Basel

Tel: +41 61 228 94 44
Fax: +41 61 228 94 49

andres.almiray@xxxxxxxxx
http://www.canoo.com

On 11 Oct 2017, at 19:20, Angelika Wittek, openMDM(R) <angelika.wittek.openmdm@xxxxxxxxx> wrote:

Hello Andres -

thank you for your email.

I'm not sure which version you are referring to - the current dev branches? This is work under construction and may create some issues. I recommend that you use the latest master (version 0.8) from the project download page.

I will take all your concerns into the next AC meeting on Friday. In any case, we will react on the recommendations of the AC.

On a personal note: Please refrain from personal attacks.

Thanks
Angelika Wittek

openMDM(R) EWG toolkit manager

mail: Angelika.Wittek.openMDM@xxxxxxxxx
phone: +49 1577 1900802
Am 11.10.2017 um 12:28 schrieb Andres Almiray:
[cross-posting from open-measured-data-wg@xxxxxxxxxxx]

Hello everyone,

We’re trying to build a version of the web client by grabbing the latest sources. There’s a break in binary compatibility brought by http://git.eclipse.org/c/gerrit/mdmbl/org.eclipse.mdm.api.base.git/commit/?id=14f7a9c9ee7c3e06963e5a8b581e5651c127bff8
The getID/setID methods were migrated from Long to String.

Why is this a problem? Because the project version did not change. Have a look at the project repository at http://git.eclipse.org/c/gerrit/mdmbl/org.eclipse.mdm.api.base.git/log/
The change was introduced by

2017-07-19 518738: Type of Entity-IDs (changed in api.base, api.default, api.ods)

It’s quite recent. Three commits later the repository was tagged with 0.7. 14 commits later it was tagged with 0.8 (on September 7th). Yet the project’s version is still set to 1.0.0.
So which is it? Is it 0.8? is it 1.0.0? Aren’t we supposed to be using semantic versioning for labeling project versions? If we are then the current state of the project is horribly broken. This “small change” should have prompted the project version to jump to 2.0.0-SNAPSHOT at the very least if semver is to be followed to the letter. If we’re not following semver, then what is it?

I ask then, what versioning scheme is in place and where do we get hold of the document that states it?

This commit appears to make a reference to bug ID 518738. Which issue tracker are we supposed to use? Eclipse’s bugzilla points to an Eclipse Neon & _javascript_ problem https://bugs.eclipse.org/bugs/show_bug.cgi?id=518738 
The mdmbl website points to Eclipse’s bugzilla if you want to report a bug or review bug reports. https://projects.eclipse.org/projects/technology.mdmbl/developer
The OpenMDM Jira instance doesn’t even reach that number https://openmdm.atlassian.net/projects/OMDM/issues/

You never ever, let me repeat that, NEVER EVER use version ranges at any time, for whatever reason!

Their usage lead to unreproducible builds and other potential incompatibility issues. Granted, Mockito is a project that evolves very, very fast, they push releases at least once a month, and as great as they try to keep things tidy they broke binary compatibility by moving around private APIs between 2.6.x and 2.7.0. This could happen again. Matthias, you’re exposing the project and every developer that wants to build the project to potential problems just because you couldn’t be bothered to pick a fix version for a dependency. If you didn’t pick the version range at least you signed of the commit. Please do not do this. This problem should have been spotted in a code review.

 
Andres Almiray
Canoo Engineering AG
Kirschgartenstrasse 5
CH-4051 Basel

Tel: +41 61 228 94 44
Fax: +41 61 228 94 49

andres.almiray@xxxxxxxxx
http://www.canoo.com 



_______________________________________________
mdmbl-dev mailing list
mdmbl-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdmbl-dev

_______________________________________________
mdmbl-dev mailing list
mdmbl-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdmbl-dev

Back to the top