streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: ApacheCon Recap & Next Steps
Date Thu, 14 Mar 2013 13:52:01 GMT
On Wed, Mar 13, 2013 at 3:20 PM, Chris Geer <chris@cxtsoftware.com> wrote:
> On Wed, Mar 13, 2013 at 8:41 AM, Matt Franklin <m.ben.franklin@gmail.com>wrote:
>
>> For all of you who missed it, Craig gave a nice intro into what we are
>> trying to accomplish with Streams at Apachecon [1].  At the conference
>> there was a fair bit of interest and what seemed to me like potential
>> alignment; however, there are some serious issues to discuss and work
>> to resolution.  The issues I heard are as follows:
>>
>> 1) Everyone is interested, few are engaged.
>>     There are quite a few people who could use this software, but
>> aside from Jason, we really haven't seen much activity in development
>> or architecture.
>>
>
> I'm one of the interested but not engaged yet. But I am interested in
> engaging if I can make it fit for our project.
>
>>
>> 2) The current code is not easy to engage with
>>     We need to lay out tutorials on how to get started and discuss
>> general architecture and package structure
>>
>> 3) We need processing pipelines for incoming and outgoing activities
>>     How these pipelines are created, managed (workflow?), parallelized
>> and augmented by custom components needs to be discussed
>>
>
> We do a lot of work with dynamically creating camel routes which could be
> used here potentially.
>
>>
>> 4) We need to support some kind of persistence
>>    Most people want to do ad-hoc querying rather than direct
>> subscription notification (though both should be supported IMO), but
>> we need persistence, indexes & a whole lot of thought to make this a
>> reality
>>
>> 5) Dependencies need help
>>    Someone brought up that all of our dependencies are versions old
>> and need to be upgraded
>>
>
> I think I might have made that comment. I believe this is because the
> current deployment is tied to ServiceMix which isn't updated very often.
> It's picking up the pace again but ServiceMix is a big beast with lots of
> dependencies so it's slow to catch up with all the latest libraries.
> ServiceMix 4.5 was just released which is using newer libraries which will
> help.
>
> ** I just saw Jason's follow-up where he seemed to be suggesting getting
> rid of OSGI support, so if that is the case the stuff below isn't important
> **
>
> 6) Code structure to support various deployments
>     Right now I understand that there is a desire to deploy either inside
> an OSGI container or standalone as a WAR file in any servlet container.
> That is a great goal but I'm not sure the code is structured in the best
> way to take advantage of both scenarios to it's fullest. I have a couple
> thoughts of some simple changes that would allow the project to be deployed
> in both places and still be able to take advantage of OSGI features in that
> environment.
>  - Split the API from the implementation in separate bundles. This can be
> done two ways, either each capability has two bundles (-api, -impl) or you
> have one API bundle that includes all the API code for the whole project.
> This decouples the implementation from the API so the implementation can be
> updated without affecting all the bundles that use it. The downside of not
> doing it is that every time a bundle with an API class in it is updated you
> have to reload all the bundles that use that class definition.
>  - Try to make the API/Implementations pure POJOs. There shouldn't be any
> common reason why you need to depend directly on OSGI classes if you use
> Blueprint for wiring (replace spring-osgi with blueprint). Having pure
> POJOs, with no OSGI or Spring dependencies, allows implementors to wire
> things up using the technology they see fit. (Might want to consider a
> profile here as well so that spring context file can be stripped. Otherwise
> you wind up with multiple instances of the same beans being created in OSGI)
>  - For WAR files (if needed) there would probably need to be a profile
> setup to build either OSGI or non-OSGI. In the OSGI mode it wouldn't embed
> all the libraries inside the WEB-INF/lib folder, instead it would use OSGI
> imports to get those dependencies. It can also lookup services to use
> instead of creating new versions of the beans.
>  - For configuration parameters, in the Blueprint file use configuration
> properties. You can provide the default in the blueprint file but it will
> publish that item to the OSGI Config Admin service so it can be updated
> with either config files or directly through the API/web console.

These suggestions seem very reasonable to me.  Any chance we can
convince you to implement them? :)

>
> On a different note, there seems to be a lot of NOTICES/DISCLAIMERS... in
> the project. Are those required in every module? I believe those can be
> removed from any module that is a <package>pom</package> type since that
> package structure doesn't generate a jar or use the src folder anyway.

We should be able to pull these in during the build process so that
they show up in the zip that gets released.

>
>>
>> Anyone have any thoughts on these issues and how we as a community can
>> move past them?  Did anyone else have other issues to add to the list?
>>
>> -Matt
>>
>> [1]:
>> http://archive.apachecon.com/na2013/presentations/26-Tuesday/Tapping_The_Stream/11:15-Apache%20Streams:%20Enterprise%20Social%20Integration.pdf
>>

Mime
View raw message