I'm still working on this jira. this module is already in production and working correctly for 5.2.6, 5.3.7, 5.4.AlphaXX. the build process and testing integration with Pluto works well with Maven. The gradle build is ok but I have not managed to use Tomee Pluto and Arquilian in a gradle build. Any technical feedback is welcome

In addition, Tapestry does support portlets, but by using a thirdy-party module.

What if the Tapestry documentation itself had a "Recommended third-party" modules section? For example, tapestry-security, the integration with Apache Shiro, isn't part of the Tapestry project itself but it's written by a committer of both Tapestry and Shiro and it's widely trusted.

Latest released Tapestry version is 5.3.6 and tapestry5-portlet says it supports them.

Inclusion on tapestry.apache.org is like a seal of approval. It provides trust. Provision from somewhere else lacks the seal. It must earn the trust all by itself.

On the other hand, portlet support from tapestry.apache.org reflects good on tapestry itself. If I were running tapestry, I'd want portlet support in there. All other serious UI frameworks support portlets

But, we're talking hypotheses here. The attached jars would need to be brought up to par with the latest tap5 before being able to be considered for inclusion.

Hello, Pieter!

If tapestry5-portlet is working and if it had its JARs in the Maven Central Respository, would you be satisfied? As I said in the message above, we cannot have too much stuff under the Tapestry project itself because otherwise we wouldn't have the time to support all that.

Cheers!

Separate jar is what I'd expect; you don't want to force portlet.jar upon everybody.
Out of the box, as in documented and provided on tapestry.apache.org just like all tap5 jars.
(I'm still maintaining a tap4-based portlet app and I would love to migrate to tap5.)

Hello, Pieter!

What do you mean by out-of-the-box portlet support? As in tapestry-core itself? I'm sorry, that's not going to happen. Not everybody which uses Tapestry uses portlets, so it doesn't make much sense to put support for it in core. The Tapestry philosophy is to have the basic functionality in tapestry-core and more specific stuff in other JARs, such as tapestry-upload and tapestry-hibernate.

If it's about a separate JAR under the Apache Tapestry project, tapestry5-portlet is mostly written by Tapestry committers themselves. In addition, we avoid having too much stuff under the Tapestry project itself because we're all volutaries and we'd need to support that code.

I agree with you that tapestry5-porlet should have its JAR in Maven Central Repository.

Cheers!

I'd expect this issue to be closed once tap5 has out-of-the-box portlet support.
(PS: I didn't check out the fine work on code or github.)

Hi, guys!

Shouldn't this issue be closed due to the tapestry5-portlet linked above? I haven't used portlets myself, so I'm not the best one to check it.

If nobody says no in a couple weeks, I'll close this issue.

Like Felix Scheffer
(http://code.google.com/p/tapestry5-portlet-support/ for more
details),
we have updated the dependencies of this library to use Tapestry 5.2.6.

This library also support:

• portlet event processing (JSR 286)
• serving ajax request as portlet resource (event name that start with
  serve or components declared in the PortletResourceResponseIdentifier
  service)
• support MARKUP_HEAD_ELEMENT
• rework on IdAllocator to avoid conflict for generated id when there
  is more than on tapestry portlet in a page.
• use of Apache Pluto to ease the test

Code is available at https://github.com/got5/tapestry5-portlet.
If you want to see it in action, you just need to:

• Download the sources
• Go to the repository directory
• Run "mvn jetty:run"
• Open your browser to http://localhost:8080/tapestry5-portlet/portal/Index

This bridge is available also in snapshot version for Tapestry 5.3.3.
To come : documentations and gradle tasks to prepare a clean move to main Tapestry project (Targeted version 5.4)

Due to the raising adoption of portal servers like liferay in for example Germany, I see a definitive need for portlet support in the major frameworks. I have encountered quite a few projects that had to be ported from servlet to portlet and when the framework has no support, you have to rewrite almost the whole app. I don't think that this helps tapestry if the devs simply ignore that.
I for myself won't use tapestry for a coming project, because I know that it needs to run in a portal server later...

Just my 2c

we have an ongoing study on this subject based on Makus work.

Beste afzender,

Dit e-mailadres van Cumquat is niet langer meer in gebruik. U kunt
contact opnemen met Cumquat via een van de onderstaande
e-mailadressen:

• project.office@cumquat.nl voor projectgerelateerde onderwerpen
• sales@cumquat.nl voor commerciële onderwerpen
• info@cumquat.nl voor algemene onderwerpen

Dank u wel.

Dear sender,

This e-mail account of Cumquat is no longer is use. Please contact
Cumquat by using one of the e-mail accounts below:

• project.office@cumquat.nl for project related issues
• sales@cumquat.nl for sales questions
• info@cumquat.nl for general questions

Thank you.

Cumquat Information Technology B.V.
De Dreef 19
3706 BR ZEIST
t +31 (0)30 6940 490
f +31 (0)30 6940 499
i www.cumquat.nl

Does this still current and with interested?

Hey, I have extended the code of Tran Le Xuan and Kristina B. Taylor. XHR Requests and Resource Serving has been implemented.
Check details on my google code project: http://code.google.com/p/tapestry5portlet/

Due the new portal features in JSR-286 (events, resource serving (ajax), filters, policy, public render parameters), don't you think that Portlet2 deserves a separate version of Tapestry? There is a gap in this area.

This is my contribution for supporting tapestry runs in portlet mode. I develop from the source of Kristina B. Taylor (https://issues.apache.org/jira/browse/TAP5-78). Thanks for Kristina. The source now supports tapestry versions from 5.0.15 to 5.0.18, and 5.1.0.5.
For version 5.0.15, I fixed the bug about the action event and the passivate context from Kristina source.
For version 5.0.18, it can run with tapestry version 5.0.16, 5.0.17, and 5.0.18.

I just don't think you understand how open source works Jan.

If it was really that important then you should:

a) Make a go of portlet support yourself.
b) Have your company pay Howard to do it.

The source is right there, so anyone can in theory jump right in and do it. That's how it works.

OMG Jesse - you are doing the Tapestry community a bad favor reacting the way you do.

Just to make myself perfectly clear. I don't want to go to Wicket and/or JSF, because I love working in Tapestry. I'm personally responsible for the adoption of Tapestry at my company (from version 3.0). I just want to point out that Tapestry 5 will even be more appealing to use, when we can use it to create our portlets.

Why don't you just go use wicket then Jan? I don't think anyone here really cares what you use.

FYI: final spec approved - http://jcp.org/en/jsr/detail?id=286

JSR-301 will specify how JSF can be bridged for JSR-286.
Work is well underway for Wicket 1.4 to allow JSR-286 portlet development.