Lol, I don't know if I'd call it "summarized" ;-) On Jul 12, 2011, at 2:06 PM, Johan Edstrom wrote:
> 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 >>>>> * >>>>> >>>>> >>>>> >>>>> >>>> >>>> >> >
