osgi semantic versioning with baselining in enroute - p kriens

Post on 04-Jul-2015

191 Views

Category:

Technology

2 Downloads

Preview:

Click to see full reader

DESCRIPTION

OSGi Community Event 2014 Abstract: Most people consider versions tedious and boring. And they are right! However, that does not make them less important. Unless you always compile all your code together and never have to go back in time, versions are the threads that keep the systems together in a stable way. That is, if people did not make those stupid mistakes with versions ... Meet semantic versioning and baselining. Semantic versions provide a framework to automate version handling. This framework is used in bnd(tools) to automate most version handling. This presentation will show what OSGi semantic versions are and its extension to also semantically version contracts. It will demonstrate the bnd(tools) support which is part of enRoute to detect semantic version violations in real time as well as in the continuous build. Speaker Bio: Peter Kriens is an independent consultant since 1990.He currently works for the OSGi Alliance and jpm4j. During the eighties he developed advanced distributed systems for newspapers based on microcomputers based on, at the time very novel, object oriented technologies. For this experience in Objects he was hired by a number of international companies, including Adobe, Intel, Ericsson, IBM, and many others. During his work at Ericsson Research in 1998 he got involved with the OSGi specification; Later he became the primary editor for these specifications. In 2005 he was awarded the OSGi Fellows title. After taking a sabbatical in 2012 to develop jpm4j he returned to the OSGi Alliance to help increasing adoption. He is Dutch but decided to live in France.

TRANSCRIPT

Baselining with OSGi enRoute

Peter Kriens

Baselining with enRoute• Why baselining?

• Semantic versions

• Consumers & Providers

• Reports

• IDE Support

• Demo

Why Baselining?

3.80

DISCLAIMER!No children were harmed

for the next image …

Need more reasons?

NoClassDefFoundError

NoSuchFieldError

NoSuchFieldException

NoSuchMethodErrorNoSuchMethodException

UnsatisfiedLinkErrorUnsupportedClassVersionError

TypeNotPresentException

LinkageError

IllegalAccessError

ClassNotFoundException

AbstractMethodError

InstantiationError

Semantic Versioning

1.2.3.qual

MAJOR

MINOR

MICRO

who cares?

MAJOR

MINOR

MICRO

2.0.0 breaks everybody

1.3.0 backward compatible

1.2.4 no semantic change

Change to:1.2.3

Compatibility as in binary compatibility

Binary Compatibility• Reimplementing existing methods, constructors, and initializers to improve performance.

• Changing methods or constructors to return values on inputs for which they previously either threw exceptions that normally should not occur or failed by going into an infinite loop or causing a deadlock.

• Adding new fields, methods, or constructors to an existing class or interface.

• Deleting private fields, methods, or constructors of a class.

• When an entire package is updated, deleting default (package-only) access fields, methods, or constructors of classes and interfaces in the package.

• Reordering the fields, methods, or constructors in an existing type declaration.

• Moving a method upward in the class hierarchy.

• Reordering the list of direct superinterfaces of a class or interface.

• Inserting new class or interface types in the type hierarchy.

One example …

public interface Foo { void foo(); }

class FooImpl implements Foo { void foo(); }

class SomeCode { void bar(Foo f) { f.foo(); } }

public interface Foo { void foo(); void bar(); }

class FooImpl implements Foo { void foo(); }

class SomeCode { void bar(Foo f) { f.foo(); } }

interface Foo { void bar(); }

class FooImpl implements Foo { void foo(); }

class SomeCode { void bar(Foo f) { f.foo(); } }

All interfaces are created equal but some interfaces are

more equal than others …

org.osgi.service.eventadmin

Event!Admin!

Implement.

Event Admin

Event Handler

Event!Admin!

Observer

ProviderConsumer Contract

contract providerconsumer

• Consumers – Changes to the contract are usually backward compatible. Only MAJOR changes require a new implementation.

• Providers – Almost any change to the contract requires a new implementation. MAJOR and MINOR changes require a new implementation.

contract providerconsumer

1.2.3 [1.2,1.3)[1.2,2)

contract

1.3.0

contract

2.0.0

org.osgi.service.eventadmin

Event!Admin!

Implement.!

Event Admin

Event Handler

Event!Admin!

Observer!

ProviderConsumer Contract

org.osgi.service.eventadmin

Event!Admin!

Implement.![1.2,1.3)

Event Admin

Event Handler

Event!Admin!

Observer![1.2,2)

Provider Type

Consumer Type

org.osgi.service.eventadmin

Event!Admin!

Implement.![1.2,1.3)

Event Admin

Event Handler

Event!Admin!

Observer![1.2,2)

Provider Type

Consumer Type

[1.2,2) [1.2,1.3)

@ConsumerType public interface EventHandler { void handleEvent(Event event); }

@ProviderType public interface EventAdmin { void sendEvent(Event event); void postEvent(Event event); }

org.osgi.service.eventadmin

Event!Admin!

Implement.![1.2,1.3)

Event Admin

Event Handler

Event!Admin!

Observer![1.2,2)[1.2,2) [1.2,1.3)

1.2.31.3.02.0.0 ⊗⊗

— Java Language Specification

“We encourage development systems to provide facilities that alert developers to the

impact of changes on pre-existing binaries that cannot be recompiled.”

So we did …

bndlib

bndtools antmaven

older newer

[{…},{…},{…},…]

jpm gradle

bndtools

web

* com.liferay.portal.kernel.dao.search MINOR 6.2.0 6.2.0 6.3.0 VERSION INCREASE REQUIRED < class com.liferay.portal.kernel.dao.search.DisplayTerms + method isSearch() + return boolean !!com.liferay.portal.kernel.dao.search MINOR 6.3.0 6.2.0 6.3.0 - < class com.liferay.portal.kernel.dao.search.DisplayTerms + method isSearch() + return boolean - version 6.2.0 + version 6.3.0

ant

[INFO] PACKAGE_NAME DELTA CUR_VER BASE_VER REC_VER WARNINGS [INFO] = ================================================== ========== ========== ========== ========== ========== [INFO] * com.example.stuff changed 5.7.1 5.7.1 5.7.2 Version increase required [INFO] ~ class com.example.stuff.SomeImporter [INFO] ~ annotated org.apache.felix.scr.annotations.Properties [INFO] + property value=[org.apache.felix.scr.annotations.Property:TYPE:CLASS:] [INFO] - property value=[org.apache.felix.scr.annotations.Property:TYPE:CLASS:]

maven

Drums …

Conclusion

Pretty Cool, eh!

Q&A

top related