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
