BTW the very first paragraph of the scalate camel page clearly showed the groupId of the component - which highlights that its never been part of the camel distro nor was it pretending to be. The components page has always been about all components for camel - irrespective of which distro they come from (its the reason that most pages start describing the groupId / artifactId to find the component). Though it does make sense to split the table up into 'camel distro' components first and then external ones.
The main reason we put the scalate camel component in the scalate project was simply that scalate (and scala) is revving much quicker than the Camel API is changing. In other words, there have been no significant API changes in Camel that have any effect on the scalate camel component, yet there's been around 8 scala/scalate releases during that time. So it makes sense to stay there really as scala/scalate revs quickly and the scalate-camel component can work with pretty much any camel 2.x distro; though I'm in the process of moving the wiki page to the Scalate site so we can link to it from an 'external component' section of the components page... On 20 July 2011 18:25, Guillaume Nodet <gno...@gmail.com> wrote: > Well, another option would be to ask for the camel scalate component > code to move to Camel. Scalate is ASL so that's possible. > > On Wed, Jul 20, 2011 at 18:43, Eric Johnson <ericjohn...@apache.org> wrote: >> My understanding of what Dan is saying is that since the Scalate >> component is not developed as part of the Apache Camel project it >> cannot be documented in a way that makes it look like it is a part of >> the Apache Camel project. It, and any similarly developed 3rd party >> components, should be clearly marked as such and documented elsewhere. >> >> It would be nice to: >> a) provide a link to the policy that Dan is invoking/enforcing >> b) have a public discussion, or at least a warning, about this move >> before taking unilateral action >> >> Dan's action may be the right thing to do, but it has been done in the >> wrong way. >> >> >> On Wed, Jul 20, 2011 at 11:51 AM, James Strachan <ja...@fusesource.com> >> wrote: >>> I still don't get it - maybe I'm just dumb. >>> >>> So we need to delete all web pages hosted at apache that even talk >>> about using, say, JAXB - since its not some source code in an Apache >>> repo? A web page at Apache can only talk about source code hosted by >>> Apache and absolutely nothing else? Can we mention JVM flags? How >>> about bash shell scripting and working with command lines? Can we even >>> use the word "Hudson" or "Jenkins"? How about linking to CI servers >>> which contain source code not hosted by Apache? >>> >>> Is there some policy somewhere that describes what we're actually >>> allowed to talk about on a page? >>> >>> >>> On 20 July 2011 16:43, Daniel Kulp <dk...@apache.org> wrote: >>>> On Wednesday, July 20, 2011 8:47:19 AM James Strachan wrote: >>>>> Dan could you please explain why you're deleting pages from the wiki which >>>>> describe open source camel components without first at least having a >>>>> discussion about it? >>>> >>>> Because in this case, there is nothing really to discuss. That page >>>> CANNOT >>>> be hosted here. Period. It's not supported by the Apache Camel project. >>>> It's not part of Apache Camel. Etc.... If the Scalate team would like >>>> to >>>> create a page on their own site with information, we can create a new "3rd >>>> party Camel Components" page or table or similar that provides a (nofollow) >>>> link to their page, but Apache cannot provide hosting and such for >>>> documentation of external components. Alternatively, if they would like to >>>> donate the Scalate component to camel, we could put it back for 2.9. I >>>> can >>>> help out with the software grant needed. >>>> >>>> I'm going to be going through the components page and pulling out the >>>> camel- >>>> extra components and moving them to a separate table as well. (with CLEAR >>>> notice about them having non-Apache compatible licenses, less supported, >>>> etc...) Most likely, the docs for those will need to move to camel-extra >>>> with >>>> links off as well. I may need help from a camel-extra committer to create >>>> the pages there. >>>> >>>> >>>> We need to be very clear about which components are part of Camel and >>>> supported by this community, which components are somewhat related (camel- >>>> extra) but have clearly incompatible licenses, and which are fully third >>>> party >>>> and not associated with Camel at all. >>>> >>>> The best similar example is the maven plugins list: >>>> >>>> http://maven.apache.org/plugins/ >>>> >>>> which provide 3 very distinct tables. "core" maven plugins, >>>> codehaus/mojo >>>> plugins, and "others". >>>> >>>> >>>> >>>> >>>> Dan >>>> >>>> >>>> >>>>> On 19 July 2011 18:54, <conflue...@apache.org> wrote: >>>>> > Scalate Page *removed* by Daniel >>>>> > Kulp<https://cwiki.apache.org/confluence/display/~dkulp> >>>>> > >>>>> > Scalate >>>>> > >>>>> > *Available as of Camel 2.3* >>>>> > >>>>> > The *scalate:* component allows you to process a message using >>>>> > Scalate<http://scalate.fusesource.org/>template, which supports either >>>>> > SSP or Scaml format templates. This can be ideal when using >>>>> > Templating<https://cwiki.apache.org/confluence/display/CAMEL/Templating >>>>> > >to generate responses for requests. >>>>> > >>>>> > Maven users will need to add the following dependency to their pom.xml >>>>> > for this component, and use the correct version of Scalate: >>>>> > >>>>> > <dependency> >>>>> > >>>>> > <groupId>org.fusesource.scalate</groupId> >>>>> > <artifactId>scalate-camel</artifactId> >>>>> > <version>1.3.2</version></dependency> >>>>> > >>>>> > URI format >>>>> > >>>>> > scalate:templateName[?options] >>>>> > >>>>> > Where *templateName* is the classpath-local URI of the template to >>>>> > >>>>> > invoke; or the complete URL of the remote template (eg: >>>>> > file://folder/myfile.ssp). >>>>> > >>>>> > You can append query options to the URI in the following format, >>>>> > ?option=value&option=value&... >>>>> > Message Headers >>>>> > >>>>> > The scalate component sets a couple headers on the message (you can't >>>>> > set >>>>> > these yourself and from Camel 2.1 scalate component will not set these >>>>> > >>>>> > headers which will cause some side effect on the dynamic template >>>> support): >>>>> > Header Description CamelScalateResource The resource as an >>>>> > >>>>> > org.springframework.core.io.Resource object. CamelScalateResourceUri >>>>> > The *templateName* as a String object. >>>>> > >>>>> > Headers set during the Scalate evaluation are returned to the message >>>>> > and >>>>> > added as headers. Then its kinda possible to return values from Scalate >>>>> > to the Message. >>>>> > >>>>> > For example, to set the header value of fruit in the Scalate template >>>>> > .tm: >>>>> > >>>>> > <% in.setHeader('fruit', 'Apple') %> >>>>> > >>>>> > The fruit header is now accessible from the message.out.headers. >>>>> > >>>>> > Scalate Context >>>>> > >>>>> > Camel will provide exchange information in the Scalate context (just a >>>>> > Map). >>>>> > >>>>> > The Exchange is transfered as: >>>>> > key value exchange The Exchange itself. headers The headers >>>>> > of >>>>> > >>>>> > the In message. camelContext The Camel Context intance. request >>>>> > The >>>>> > In message. in The In message. body The In message body. out >>>>> > The >>>>> > Out message (only for InOut message exchange pattern). response The >>>>> > Out message (only for InOut message exchange pattern). >>>>> > >>>>> > Hot reloading >>>>> > >>>>> > The Scalate template resource is, by default, hot reloadable for both >>>>> > file and classpath resources (expanded jar). >>>>> > Dynamic templates >>>>> > >>>>> > Camel provides two headers by which you can define a different resource >>>>> > location for a template or the template content itself. If any of these >>>>> > headers is set then Camel uses this over the endpoint configured >>>>> > resource. This allows you to provide a dynamic template at runtime. >>>>> > >>>>> > Header Type Description CamelScalateResourceUri String An URI >>>>> > for >>>>> > >>>>> > the template resource to use instead of the endpoint configured. >>>>> > CamelScalateTemplate String The template to use instead of the endpoint >>>>> > configured. >>>>> > >>>>> > Samples >>>>> > >>>>> > For example you could use something like >>>>> > >>>>> > from("activemq:My.Queue"). >>>>> > >>>>> > to("scalate:com/acme/MyResponse.ssp"); >>>>> > >>>>> > To use a Scalate template to formulate a response to a message for >>>>> > InOut >>>>> > >>>>> > message exchanges (where there is a JMSReplyTo header). >>>>> > >>>>> > If you want to use InOnly and consume the message and send it to another >>>>> > destination, you could use the following route: >>>>> > >>>>> > from("activemq:My.Queue"). >>>>> > >>>>> > to("scalate:com/acme/MyResponse.scaml"). >>>>> > to("activemq:Another.Queue"); >>>>> > >>>>> > It's possible to specify what template the component should use >>>>> > >>>>> > dynamically via a header, so for example: >>>>> > >>>>> > from("direct:in"). >>>>> > >>>>> > setHeader("CamelScalateResourceUri").constant("path/to/my/template.s >>>>> > caml"). to("scalate:dummy"); >>>>> > >>>>> > It's possible to specify a template directly as a header the component >>>>> > >>>>> > should use dynamically via a header, so for example: >>>>> > >>>>> > from("direct:in"). >>>>> > >>>>> > setHeader("CamelScalateTemplate").constant("<%@ attribute body: >>>>> > Object %>\nHi this is a scalate template that can do templating >>>>> > ${body}"). to("scalate:dummy"); >>>>> > >>>>> > The Email Sample >>>>> > >>>>> > In this sample we want to use Scalate templating for an order >>>>> > confirmation email. The email template is laid out in Scalate as: >>>>> > >>>>> > <%@ attribute in: org.apache.camel.scala.RichMessage %> >>>>> > Dear ${in("lastName"}, ${in("firstName")} >>>>> > >>>>> > Thanks for the order of ${in("item")}. >>>>> > >>>>> > Regards Camel Riders Bookstore >>>>> > ${in.body} >>>>> > >>>>> > See Also >>>>> > >>>>> > - Configuring >>>>> > Camel<https://cwiki.apache.org/confluence/display/CAMEL/Configuri >>>>> > ng+Camel> - >>>>> > Component<https://cwiki.apache.org/confluence/display/CAMEL/Compo >>>>> > nent> - Endpoint >>>>> > <https://cwiki.apache.org/confluence/display/CAMEL/Endpoint> - >>>>> > Getting >>>>> > Started<https://cwiki.apache.org/confluence/display/CAMEL/Getting >>>>> > +Started> >>>> -- >>>> Daniel Kulp >>>> dk...@apache.org >>>> http://dankulp.com/blog >>>> Talend - http://www.talend.com >>>> >>> >>> >>> >>> -- >>> James >>> ------- >>> FuseSource >>> Email: ja...@fusesource.com >>> Web: http://fusesource.com >>> Twitter: jstrachan, fusenews >>> Blog: http://macstrac.blogspot.com/ >>> >>> Open Source Integration and Messaging >>> >> >> >> >> -- >> Principle Technical Writer >> FuseSource >> Phone: (781) 280-4174 >> E-Mail: ericjohn...@apache.org >> Blog: http://documentingit.blogspot.com/ >> Twitter: finnmccumial >> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan, fusenews Blog: http://macstrac.blogspot.com/ Open Source Integration and Messaging
