Hi all- I'm a long time user and current AMQ/SMX/Camel/CXF consultant hoping to get more time to be active on the dev side of things. I'm also a big proponent that getting the technology correct will lead to a better product (blueprint v spring). One of the strengths of SMX is the wide range of technologies that are supporting for deploying code projects, but it also has a down side for folks that are new to Java, new to the product or are new to integration altogether. I'm a huge fan of these products and all the great work many folks have put into them!
Notes from the field regarding my thoughts on SMX and SMX5, (apologies in advance for veering off the Scala topic): - For most users I've been to, getting the development infrastructure in place is 10x the effort vs getting the actual platform up and running. Teams will lock into a specific version and stay there for 6 mos to a year and only change when they have a *really* compelling reason (they'll code around bugs just to not change dev infrastructure). Code project templates, customer certified Maven repos, Jenkins, Sonar and other tooling integrations are the big hurdles in getting organizations successful with integration and messaging projects. Major technology changes have big and lasting impacts to users. Many users have skeleton project templates that they hand off to their junior coders (or off-shore teams) to fill in the blanks. Consider the impact of the message that SMX5 is moving to Scala as a **project-implementation technology**. BTW-- I vote +2 for the idea of supporting Java interfaces in SMX5 ;-). Please be mindful when communicating in blog posts, white papers, etc so users don't mistakenly think that they *need* to implement their projects in Scala. Managers will see headlines that say "SMX 5 moving to Scala" and they'll flip out thinking that they have to scrap all their SMX 3 or SMX 4 development infrastructure-- or worse, they'll deem SMX too volatile a platform for organizations to build around. Reasoning and explanation doesn't apply-- knee-jerk, distrust, irrationality and the latest blog post by some-schmo-named-Bob are the operatives here. In short, supporting Scala == good. Users getting scared that they *have* to move to Scala == bad. - Please be mindful that many users of these products do not always have a high level of programming knowledge. Many organizations have an administrative view towards integration, and not a programming view. - There is still quite a bit of confusion on the JBI->OSGi side of things, and when to use OSGI services (ie.. many folks think that OSGI services are the go-to "service" implementation in SMX). A really big customer went with SMX4, and explicitly declared "no Camel", b/c they didn't understand that Camel replaced the JBI servicing from SMX3. For SMX 5, it would be great to have consistent communication about what technology is the recommended for "your first SMX 5 project". - Johan's note about users certifying jar-by-jar is right on. I've seen two other large orgs that have that as well. Drivers for this are interpretations of Sarbaines-Oxley (right or wrong), legal considerations when redistributing a product that is SMX-based, or security policies. - The learning curve for SMX is steep for folks new to the product. Many things, like Maven deployments solve problems they don't even know they have yet. Has there been thought to usefully obscuring some of the various technologies from users? Karaf is great. Is it really a separate product, or more like a technology within a product? Do users need to know SMX uses OPS4J-related technologies? Do config files have to be labeled Aries, Felix, OPS4J, Karaf, ActiveMQ, Camel and ServiceMix (out of the box there are 3 files related to logging)? Are there simple ways we can obscure some of the technologies from the users to lower the learning curve and allow them to grow into the product one step at a time? In my simple view of things, I liken this to how Mozilla had the Gecko rendering engine as a technology that's used by several projects, but users just see the product "FireFox". Does it makes sense to leave the actual property keys tied to the technologies, but consider more unified naming for the config files themselves? I know it sounds like a very trivial thing, but anything we can do to have the code-project-level users spend less time dealing with the admin side of things, the better the perception will be. For example, keep the property named "org.ops4j.pax.url.mvn.localRepository", but stick it in a "maven.cfg" or similar. - Configuration. Many developers I've come across are not versed in using the Java debugger, so they rely on the alternative debugging approaches-- JMX, verbose logging, System.out.println, etc. Things like JMX enablement for all technologies (CXF, Jetty, etc) should be readily configurable. Default timeouts are a huge issue with so many different technologies being tied together. Many configuration options were hidden from users out of the box in SMX4, like PAX web SSL, and Maven fallback repos in PAX-url. Consider an effort to expose important config options into the config files, even if they are set to defaults or commented out. Geez, rant ran long, thanks for hangin' in there :-) Matt Pavlovich On Jul 12, 2011, at 11:15 AM, Johan Edstrom wrote: > A second comment would be : > > How do we deal with organizations that have started certifying Java and > components? > Pluggable infrastructure for multiple implementations? > > /je > > On Tue, Jul 12, 2011 at 10:04 AM, Johan Edstrom <[email protected]> wrote: > >> I have no problem whatsoever with Scala, I think that Apollo proved that. >> And if we write an integrations platform where something like scala >> provides >> significant improvements, why not use it? >> >> I also think the ones savvy in scala will have to abide a lot of stupid >> questions :) >> >> I do think that having a Java API is very important for existing customers >> otherwise the change from JBI->OSGi->Scala will be a bit of a whirlwind. >> >> I think scala would do best if needed under the hood. >> >> But here are my +1 - Things will always be changing. >> >> Just look at how everything went to Apache Aries Blueprint. >> >> /je >> >> >> On Jul 12, 2011, at 9:58 AM, Jean-Baptiste Onofré wrote: >> >>> Hi all, >>> >>> The low-hanging-fruit is a very good idea, and we added the same in >> Karaf. >>> >>> Maybe, it's time to launch a formal vote about the Scala usage in >> ServiceMix; wdyt ? >>> >>> Regards >>> JB >>> >>> >>> >>> On Tue 12/07/11 17:26 , Ioannis Canellos wrote:: >>> >>>> >>>> We'll still have plenty of Java code to go around in the other >>>> subprojects but for ServiceMix 5, we now have a very good opportunity >>>> to start with a new and clean codebase again and I think it definitely >>>> makes sense to start with Scala there. >>> >>> >>> I totally agree with Gert on this one. >>> >>> >>>> As for making it easier for >>>> people to start contributing, I think we should tag issues as 'low >>>> hanging fruit' in JIRA if we think those are good for people to start >>>> with and put that list on the website somewhere instead of holding >>>> back on technology to achieve the same goal. >>>> >>> >>> This is indeed a very interesting idea, which we might want to apply no >>> matter what language we end up using. >>> >>> -- >>> *Ioannis Canellos* >>> * >>> http://iocanel.blogspot.com >>> >>> Apache Karaf http://karaf.apache.org/> Committer & PMC >>> Apache ServiceMix http://servicemix.apache.org/> Committer >>> * >>> >>> >>> >>> >> >>
