Gert- Yes, usability, documentation and I'd throw public communication in there as well. I've worked on many Open Source projects in the past, and documentation is always an issue that rarely gets resolved to where it needs to be. I think a good way to mitigate that impact to users is to have better accessibility-- newbie friendly, as you put it. Those are things like more complete configuration files, and being mindful when communicating ideas-- are these engineering topics being discussed, or are they user related? For ServiceMix, these things seem to be further complicated by the fact that integration is one of the more technically demanding areas, and everyone uses these products differently.
I'll definitely start entering some JIRAs on these things and look forward to being able to dive into the code myself. Thanks! Matt Pavlovich On Jul 12, 2011, at 3:05 PM, Gert Vanthienen wrote: > Matt, > > > Thanks for this excellent feedback - perhaps I'm reading things the > wrong way, but I think the main point you make is about usability and > documentation. We all know we have a great set of technologies around > with Camel, CXF, ActiveMQ, ... but we do a very poor job at guiding > people towards picking the right stuff and showing them how to use it. > Most of the things you mentioned desperately need to get addressed, > but I think it's more about communicating and documenting things > properly. > > Most of the doubts people have about OSGi/Camel versus JBI are because > we have a huge problem with the website and documentation that needs > to get addressed asap. We should get people moving over to Camel > instead of JBI right now, in ServiceMix 4. Something like > http://servicemix.apache.org/docs/4.3.0-SNAPSHOT/quickstart/index.html > is a good start, we just need a lot more of those things to show off > what we can do with ServiceMix and how easily some things can actually > get done. > > In my mind, if people are already on the Camel/OSGi, there should be > no impact at all on their development environment or the way they > create bundles/routes/services when moving to ServiceMix 5. They > should just get more features from the container to support them and > to help them manage/troubleshoot/... whatever they created. > > For the configuration files: I'm not sure we can simply rename the > configuration files because they're currently tied to the PID of the > bundle, but filling them with sensible examples and adding a > configuration guide to the documentation which explains about the > different options without people having to go out and find that > information on dozens of other projects' sites would be a huge step in > the right direction as well, I guess? BTW, in our new ServiceMix 5 > web console there's nothing that prohibits us in showing the > configuration options in a more newbie-friendly way. > > The fact that you have to configure something like a timeout in a > dozen places is a very good point. Be sure to raise JIRA issues for > things like that, because those are the things that make ServiceMix > look less like a "hodgepodge of related technologies" as someone > rightfully pointed out on twitter today. > > As far as Scala is concerned: Whether we implement the internals for > the next version of the container in one JVM language or the other, is > not something the average user would be worried about. In ServiceMix > 5, they will be developing Camel/CXF/... things and are not directly > interacting with the internals of that container anyway. Regardless > of the implementation language we choose, what we should be aiming for > is providing the best possible integration container, with a nice web > ui, some tooling, good documentation and a website to get that point > across. > > @Matt: Fancy taking a stab at translating some of those excellent > ideas of yours into JIRA issues? > > Regards, > > Gert Vanthienen > ------------------------ > FuseSource > Web: http://fusesource.com > Blog: http://gertvanthienen.blogspot.com/ > > > > > > On Tue, Jul 12, 2011 at 9:00 PM, Matt Pavlovich <[email protected]> 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 >>>>> * >>>>> >>>>> >>>>> >>>>> >>>> >>>> >> >>
