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
