Publish artifacts on maven about aeron

[mjpt777]

Yes we plan to publish to Maven Central in the not too distant future.

Kewl. I had already "mavenized" Aeron by myself, but having Aeron on Maven
Central is much better, of course :-)

*Fortuna audaces adiuvat - hos solos ? *

On 24 November 2014 at 17:09, Martin Thompson [email protected]
wrote:

Yes we plan to publish to Maven Central in the not too distant future.

—
Reply to this email directly or view it on GitHub
#31 (comment).

[tmontgomery]

assigning to myself. We'll discuss timing of this for a 1.0 release.

[tmontgomery]

Should revisit this soon.

[MichaelDrogalis]

I'd greatly appreciate a Maven artifact before 1.0.

[mjpt777]

I think we can have a sweep of the current bugs and then look to doing a 0.1 release.

[MichaelDrogalis]

That'd be swell, I can make immediate use of that. Thanks @mjpt777!

[RuedigerMoeller]

messy task ahead :-)

2015-03-06 21:17 GMT+01:00 Michael Drogalis [email protected]:

I'd greatly appreciate a Maven artifact before 1.0.

—
Reply to this email directly or view it on GitHub
#31 (comment).

[brianfromoregon]

+1 :)

[mjpt777]

This will happen shortly when we release 0.1 beta.

[tmontgomery]

Watch this space....

[RuedigerMoeller]

drum roll

[erdem-aslan]

Finally :)

[tmontgomery]

It is done. Aeron 0.1 is submitted to maven.

Artifacts:

1. aeron-client for client only
2. aeron-driver for driver and client
3. aeron-all for client and driver and Agrona
4. aeron-tools and aeron-system-tests also included if desired

[RuedigerMoeller]

+1 ;) will experiment to lift aeron to an object-universe. I think I'll call it Egon :)

[mjpt777]

For mapping to the object universe, SBE has been improved for tighter integration.

[tmontgomery]

FYI, I will be doing a release of SBE tomorrow.

[MichaelDrogalis]

Hooray! Congrats everyone!

[krisskross]

Sweet!

[RichardWarburton]

Excellent stuff!

[RuedigerMoeller]

Haven't looked for a while into SBE. I thought about providing a generic SBE codec for fst-ser some time ago, this would enable to mix the convenience+productivity of a "top down approach" with performance and platform-neutrality of SBE's bottom up approach. However unsure on how to achieve this. Either generating SBE message layouts from classes or define a generic java-object message (don't know if this could be expressed with SBE).
(edit: .. SBE-IR !)

[mjpt777]

@RuedigerMoeller Objects directly mapping to messages is like objects directly mapping to database tables. There are fundamental differences which are best respected. I like to treat messages as first class and not pretend objects can be turned into messages by magic. To have clear separation of concerns a message should just contain the information that must be communicated and not be coupled to how it is transformed to and from object implementations. I get such bad feeling in my stomach when I see DTOs.

[RuedigerMoeller]

@mjpt777 I'd disagree here.
First, modelling a network connection as a stream of objects isn't that a leaky abstraction compared to what is done in the db-mapping domain.
Second, it depends on the productivity/flexibility/performance tradeoffs one is willing to make.

See:
By implementing the reactive-streams spec for kontraktor (just a few 100 lines of code) I get:

• remotable reactive streams for free (generic remoting)
• connectivity using tcp, websockets, [+http] for free
• Binary encoding or Json encoding for free.
• javascript cross platform connectivity (mostly for free)

at a reasonable end to end performance (up to 1.8 million remoted reactive stream msg per sec). The application on top deals with object-level streams and object level async remote calls, so I can run it on a load of different topologies (incl. single process). If I add e.g. an Aeron connector, existing code will profit immediately without requiring a change.

Will you run a low latency HFT app on that ? Probably not, but its possible to build a reasonable performing distributed application with very little amount of code and manpower, in addition level of distribution becomes kind of a deployment time decision, only pay for remoting if you actually need it.
Lifting the level of abstraction enables generic optimizations which would have to be done manually otherwise. So top-down abstraction has upsides and downsides same as Java vs. C.

[mjpt777]

@RuedigerMoeller We can agree to differ :-)

For me objects fundamentally have state and behaviour and they tend to exist within a graph of dependencies. Messages on the other hand should just be data represented in a cross language and cross platform manner. Messages should also be individually versioned, and belong to a interaction protocol that is versioned in itself.

Reactive streams is about reacting to events which are encapsulated in messages. Not about reacting to objects. We may implement in actual classes for an language but the semantics are different. I find that when the differences are respected then a lot of good properties flow. I'd put my messages in a shared context from a DDD perspective.

I'm not arguing against useful abstractions. I just think messages are a better abstraction for communication than objects.

[RuedigerMoeller]

@mjpt777 I agree regarding semantics of Objects vs Messages. I am talking of representation. An immutable class can be semantically treated as a message.
If one uses the class-level representation as a foundation of encoding/message generation it has the benefit that protocol behaviour can be developed at higher level (object/class universe) allowing to share a single behaviour implementation across various transports and wire formats.
That was the point I was trying to make regarding reactive streams (proof of concept): I implemented the behaviour once at high level (async rpc) and can use this with various network transports and encodings as well as in-process.

Versioning/cross platform: Depends, if its just streaming some data from one backoffice system to another, there might be some YAGNI ;) .