we discussed your points at the AC call today. You will get an
answer next week.
For the other pages: they link to the official Eclipse downloads.
And as you probably know, the mdmbl project is still in the
incubation phase, that means there is no official release out, so
there is nothing to find.
Best regards
Hi Angelika,
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.
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
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:
Hello everyone,
The getID/setID methods were migrated
from Long to String.
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?
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
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.
_______________________________________________
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
_______________________________________________
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
