L.S., Instead of using a tag, perhaps we should just be a bit more mindful to move discussions about things that concern our user base over to the users@ mailing list instead of keeping those on dev@. Not only would that be a more natural way of communicating the right information to the right target audience, but we might just get some feedback from users that aren't actively monitoring the dev list as a bonus.
Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Thu, Jul 14, 2011 at 8:51 PM, Johan Edstrom <[email protected]> wrote: > I think that is a good point, a separation of discussions be it with some tag > or such just indicating > that the discussion is regarding internals and engineering as opposed to how > to use the API and > provided infrastructure. > > > On Jul 14, 2011, at 12:44 PM, Matt Pavlovich wrote: > >> 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 >>>>>>> * >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >> > >
