Thanks! I think you summarized my points with Scala much better than I did :)
On Jul 12, 2011, at 1:00 PM, Matt Pavlovich wrote: > 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 >>>> * >>>> >>>> >>>> >>>> >>> >>> >
