You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by James Strachan <ja...@fusesource.com> on 2011/07/20 09:47:19 UTC
Re: [CONF] Apache Camel > Scalate
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?
On 19 July 2011 18:54, <co...@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.scaml").
> 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/Configuring+Camel>
> - Component<https://cwiki.apache.org/confluence/display/CAMEL/Component>
> - Endpoint <https://cwiki.apache.org/confluence/display/CAMEL/Endpoint>
> - Getting Started<https://cwiki.apache.org/confluence/display/CAMEL/Getting+Started>
>
>
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [CONF] Apache Camel > Scalate
Posted by Eric Johnson <em...@fusesource.com>.
Dan's unilateral decision to scrub the Scalate component from the
Camel site, while simply adding the others to a new table, does not
send the "we are happy about good external components" message.
It sends the message that Dan is the new Camel cop and we need to do
things his way or else.
I'm sure Dan's intentions were good, but his solution leaves a lot to
be desired.
Moving the Scalate entry to the new table and then sending a note to
the Scalate developers asking them to move the content in a reasonable
amount of time with an explanation the policy would have been the
better approach.
On Thu, Jul 21, 2011 at 3:25 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Hi Claus,
>
> I think we should also list external components. We only need to make sure
> it is visible that they are not part of the package and not supported by the
> camel community.
>
> So I think we could have an external components header at the end of the
> components page where we list external components. These should just link to
> an external documentation though. The details
> should not be on our camel wiki.
>
> So I think the message to external component developers should be that we
> are happy about any good external components but if they want it to be
> directly part of camel and supported by the community they will have to
> donate it to the camel project.
>
> Christian
>
>
> Am 21.07.2011 08:08, schrieb Claus Ibsen:
>>
>> Hi
>>
>> Yeah I seemed a bit rushed.
>>
>> On the components page, Dan added since in the bottom a table with
>> much related components, but as the components is not included in the
>> Camel source tree, he separated them from the top table.
>> http://camel.apache.org/components
>>
>> Maybe we could add the scalete component to this table in the bottom?
>>
>>
>> When someone creates a Camel components there is always a decision to
>> be made, whether the component should be hosted as part of the 3rd
>> party component, or donated and included at Apache Camel. Sometimes it
>> makes most sense to include it in the 3rd party in case its more tied
>> into that project, and that project changes more frequent, and for
>> example the Camel glue is just a thin layer. As well as the 3rd party
>> team is in control of that component etc. For example we had a
>> discussion with the Activiti team whether to host the Camel Activiti
>> integration at them or at Apache.
>>
>> In this case the scalete component is also build using scala code, and
>> scalete was being innovated rapidly. So I guess the decision back them
>> was to keep the scalete-camel component at Scalete for the time being.
>>
>> I am sure we can ask the scelete team to donate it to Apache if thats
>> what we want. But lets try to avoid this again. It does send a message
>> to 3rd party who take time to integrate their product with Camel a
>> wrong message.
>>
>> The scalete JARs is synced to central maven, so there is no problem
>> with that. And AFAIR they are osgi compliant as well.
>>
>>
>>
>>
>> On Wed, Jul 20, 2011 at 10:04 PM, Christian Müller
>> <ch...@gmail.com> wrote:
>>>
>>> Yes. I also think it was the right thing to do, but the wrong way...
>>> We should act with more respect for each other - independently whether or
>>> not we have different point of views.
>>>
>>> ... and as Claus always says: We love contributions... ;-)
>>>
>>> Best,
>>> Christian
>>>
>>> On Wed, Jul 20, 2011 at 5:58 PM, James
>>> Strachan<ja...@fusesource.com>wrote:
>>>
>>>> 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.
>>>>
>>>> Don't you think it'd be a little nicer to just bring this discussion
>>>> up first rather than just going ahead and deleting stuff? If that page
>>>> has to move somewhere so be it - but please talk to folks first.
>>>> Deleting stuff without comment or discussion is pretty rude behaviour.
>>>> BTW no need to SHOUT
>>>>
>>>> --
>>>> James
>>>> -------
>>>> FuseSource
>>>> Email: james@fusesource.com
>>>> Web: http://fusesource.com
>>>> Twitter: jstrachan, fusenews
>>>> Blog: http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration and Messaging
>>>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
Principle Technical Writer
FuseSource
Phone: (781) 280-4174
E-Mail: emjohnson@fusesource.com
Blog: http://documentingit.blogspot.com/
Twitter: finnmccumial
Re: [CONF] Apache Camel > Scalate
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Claus,
I think we should also list external components. We only need to make
sure it is visible that they are not part of the package and not
supported by the camel community.
So I think we could have an external components header at the end of the
components page where we list external components. These should just
link to an external documentation though. The details
should not be on our camel wiki.
So I think the message to external component developers should be that
we are happy about any good external components but if they want it to
be directly part of camel and supported by the community they will have
to donate it to the camel project.
Christian
Am 21.07.2011 08:08, schrieb Claus Ibsen:
> Hi
>
> Yeah I seemed a bit rushed.
>
> On the components page, Dan added since in the bottom a table with
> much related components, but as the components is not included in the
> Camel source tree, he separated them from the top table.
> http://camel.apache.org/components
>
> Maybe we could add the scalete component to this table in the bottom?
>
>
> When someone creates a Camel components there is always a decision to
> be made, whether the component should be hosted as part of the 3rd
> party component, or donated and included at Apache Camel. Sometimes it
> makes most sense to include it in the 3rd party in case its more tied
> into that project, and that project changes more frequent, and for
> example the Camel glue is just a thin layer. As well as the 3rd party
> team is in control of that component etc. For example we had a
> discussion with the Activiti team whether to host the Camel Activiti
> integration at them or at Apache.
>
> In this case the scalete component is also build using scala code, and
> scalete was being innovated rapidly. So I guess the decision back them
> was to keep the scalete-camel component at Scalete for the time being.
>
> I am sure we can ask the scelete team to donate it to Apache if thats
> what we want. But lets try to avoid this again. It does send a message
> to 3rd party who take time to integrate their product with Camel a
> wrong message.
>
> The scalete JARs is synced to central maven, so there is no problem
> with that. And AFAIR they are osgi compliant as well.
>
>
>
>
> On Wed, Jul 20, 2011 at 10:04 PM, Christian Müller
> <ch...@gmail.com> wrote:
>> Yes. I also think it was the right thing to do, but the wrong way...
>> We should act with more respect for each other - independently whether or
>> not we have different point of views.
>>
>> ... and as Claus always says: We love contributions... ;-)
>>
>> Best,
>> Christian
>>
>> On Wed, Jul 20, 2011 at 5:58 PM, James Strachan<ja...@fusesource.com>wrote:
>>
>>> 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.
>>> Don't you think it'd be a little nicer to just bring this discussion
>>> up first rather than just going ahead and deleting stuff? If that page
>>> has to move somewhere so be it - but please talk to folks first.
>>> Deleting stuff without comment or discussion is pretty rude behaviour.
>>> BTW no need to SHOUT
>>>
>>> --
>>> James
>>> -------
>>> FuseSource
>>> Email: james@fusesource.com
>>> Web: http://fusesource.com
>>> Twitter: jstrachan, fusenews
>>> Blog: http://macstrac.blogspot.com/
>>>
>>> Open Source Integration and Messaging
>>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [CONF] Apache Camel > Scalate
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah I seemed a bit rushed.
On the components page, Dan added since in the bottom a table with
much related components, but as the components is not included in the
Camel source tree, he separated them from the top table.
http://camel.apache.org/components
Maybe we could add the scalete component to this table in the bottom?
When someone creates a Camel components there is always a decision to
be made, whether the component should be hosted as part of the 3rd
party component, or donated and included at Apache Camel. Sometimes it
makes most sense to include it in the 3rd party in case its more tied
into that project, and that project changes more frequent, and for
example the Camel glue is just a thin layer. As well as the 3rd party
team is in control of that component etc. For example we had a
discussion with the Activiti team whether to host the Camel Activiti
integration at them or at Apache.
In this case the scalete component is also build using scala code, and
scalete was being innovated rapidly. So I guess the decision back them
was to keep the scalete-camel component at Scalete for the time being.
I am sure we can ask the scelete team to donate it to Apache if thats
what we want. But lets try to avoid this again. It does send a message
to 3rd party who take time to integrate their product with Camel a
wrong message.
The scalete JARs is synced to central maven, so there is no problem
with that. And AFAIR they are osgi compliant as well.
On Wed, Jul 20, 2011 at 10:04 PM, Christian Müller
<ch...@gmail.com> wrote:
> Yes. I also think it was the right thing to do, but the wrong way...
> We should act with more respect for each other - independently whether or
> not we have different point of views.
>
> ... and as Claus always says: We love contributions... ;-)
>
> Best,
> Christian
>
> On Wed, Jul 20, 2011 at 5:58 PM, James Strachan <ja...@fusesource.com>wrote:
>
>> 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.
>>
>> Don't you think it'd be a little nicer to just bring this discussion
>> up first rather than just going ahead and deleting stuff? If that page
>> has to move somewhere so be it - but please talk to folks first.
>> Deleting stuff without comment or discussion is pretty rude behaviour.
>> BTW no need to SHOUT
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: james@fusesource.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration and Messaging
>>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [CONF] Apache Camel > Scalate
Posted by Christian Müller <ch...@gmail.com>.
Yes. I also think it was the right thing to do, but the wrong way...
We should act with more respect for each other - independently whether or
not we have different point of views.
... and as Claus always says: We love contributions... ;-)
Best,
Christian
On Wed, Jul 20, 2011 at 5:58 PM, James Strachan <ja...@fusesource.com>wrote:
> 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.
>
> Don't you think it'd be a little nicer to just bring this discussion
> up first rather than just going ahead and deleting stuff? If that page
> has to move somewhere so be it - but please talk to folks first.
> Deleting stuff without comment or discussion is pretty rude behaviour.
> BTW no need to SHOUT
>
> --
> James
> -------
> FuseSource
> Email: james@fusesource.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration and Messaging
>
Re: [CONF] Apache Camel > Scalate
Posted by James Strachan <ja...@fusesource.com>.
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.
Don't you think it'd be a little nicer to just bring this discussion
up first rather than just going ahead and deleting stuff? If that page
has to move somewhere so be it - but please talk to folks first.
Deleting stuff without comment or discussion is pretty rude behaviour.
BTW no need to SHOUT
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [CONF] Apache Camel > Scalate
Posted by James Strachan <ja...@fusesource.com>.
On 20 July 2011 17:43, Eric Johnson <er...@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.
Thing is though, it was documented clearly as not being part of the
Apache Camel project.
Most camel components are using some Apache Camel code and lots of
other code not in the camel project. Camel is an integration library;
it can't own all the code - it has to work with other code.
So where is the line of what you can and can't talk about on the Camel website?
e.g. could we talk about using MQSeries and Camel; when there's no
actual MQSeries specific code in the Camel project - other than
generic camel code which is MQSeries agnostic, the rest of the code is
owned by IBM?
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [CONF] Apache Camel > Scalate
Posted by James Strachan <ja...@fusesource.com>.
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 <gn...@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 <er...@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, <co...@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
>>>> dkulp@apache.org
>>>> http://dankulp.com/blog
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> James
>>> -------
>>> FuseSource
>>> Email: james@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: ericjohnson@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: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [CONF] Apache Camel > Scalate
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <er...@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, <co...@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
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: james@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: ericjohnson@apache.org
> Blog: http://documentingit.blogspot.com/
> Twitter: finnmccumial
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [CONF] Apache Camel > Scalate
Posted by Eric Johnson <er...@apache.org>.
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, <co...@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
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: james@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: ericjohnson@apache.org
Blog: http://documentingit.blogspot.com/
Twitter: finnmccumial
Re: [CONF] Apache Camel > Scalate
Posted by James Strachan <ja...@fusesource.com>.
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, <co...@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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
Re: [CONF] Apache Camel > Scalate
Posted by Daniel Kulp <dk...@apache.org>.
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, <co...@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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com