Mark McLaren wrote:
Thanks Ate,

I am delighted to hear that the portal bridge project is still very
much alive and that further innovations for transparent portlet
development are in the pipeline.  The SpringMVC bridge project sounds
particularly promising.

I really appreciate all the hard work you have put in over the years.
I completely understand your "call to arms" and I would love to help
if I can.

Hardly a showcase but my own modest Struts bridge based portlet
contributions are a bookmarks and a newsfeeds portlet, available from:

<http://bmarks-portlet.sourceforge.net/>
That definitely *looks* cool (I haven't had time to try it or look at the code).
I don't see the license mentioned on the project summary page though.
Would this be ASF compatible?


Also, a long time ago (Nov' 2005), I wrote some introductory Struts
Bridge documentation on the JA-SIG uPortal wiki (it might be a little
dated now).  This documentation, such as it is, still ranks quite
highly on Google for "Struts bridge".

<http://www.ja-sig.org/wiki/display/PLT/Struts+Bridge>
Thanks, nice (and short) description of the required steps!


As far as, further contributions goes:

I'd be happy to contribute a struts-blank-bridges-portlet.war - I have
something basic working already.

As for extensions, for my portlets I created a portlet aware version
of the JSTL XML tag library (derived from a similar uPortal
contribution).  The XSL would include <portlet:renderUrl> tags to
designate internal application links to be generated by the XSL.
(useful if you are not using Struts' html:link all the time).  If you
are interested I can put together a simple example application.

My experience with uPortal community is that their Wiki provides a
great means to accelerate community documentation and signpost
community developments.  I notice there is a Apache Portals wiki but I
could not find much there for the Portals Bridges project - would this
be the best place to post future community documentation/tutorial
material etc
?.

Yeah, I know the Portals Wiki isn't exactly "inviting" nor very interesting at 
the moment.
The technical part (and very much part of the cause imo) is something under discussion (moving to Confluence, upgrading to a much newer version of MoinMoin but we're lacking the resources and experience for that to honest).
For the time being though, I'd suggest to use the current Wiki as that's the 
quickest route right now.
And if/when we move/upgrade to something better, existing content will be moved 
over too of course.

Thanks,

Ate


Best wishes,

Mark

On Sun, Jun 8, 2008 at 12:28 AM, Ate Douma <[EMAIL PROTECTED]> wrote:
Hi Mark,

Thanks a lot for the heads up :)

I fully agree with you and think the Struts Bridge isn't getting enough
attention.
As the primary creator of it, I'm probably to blame most for that, certainly
with regards to the (lack of) documentation and providing proper
"visibility".

I did write quite a few high end business (portlet) applications myself
using it and supported several development teams using it too in the past
but haven't had much time nor opportunity anymore the last few years.

Other projects, frameworks (Wicket, SpringMVC etc.) and a new job (at Hippo)
have taken my focus and responsibilities mostly elsewhere.
I (and a few others) still do support the Struts Bridge though and I think
it has a lot of benefits over solutions like Struts 2 or Spring Portlet MVC
which require you to write explicitly against the Portlet API and won't work
within a "plain" web container.

That is also one of the primary reasons I wrote the Wicket Portlet support
in a "transparent" way too: like with the Struts Bridge, you can write
Wicket Portlet applications which work just as well "standalone" in a web
container.

FYI: I know a similar solution is currently under development by a fellow
Portals committer for SpringMVC (in contrast to Spring Portlet MVC), based
upon/following the Struts Bridge solution, which *might* be contributed back
here at Portal Bridges in the future too...

Anyway, concerning your worries about the future: it really depends on the
community (so: including yourself).

Apache projects are not and will not live and survive on single individual
efforts only: it really is the community which must keep a project alive. I
myself will continue to help out as much as I can, but that by itself is
never going to be enough.

If you (the community) need better documentation, new/improved features,
examples, a struts-blank-bridges-portlet.war, better "marketing" etc.,
you'll need to help out *yourself*:
- contribute documentation
- contribute fixes/improvements
- contribute *useful* showcase examples
- write/publish articles how *you* are using the Struts Bridge
- blog
- etc.

If the community is willing to spread the word, others will take notice,
join the community, and start doing the same.
That's what it is all about: no less, no more.

If you look back through this mailing list archive, you'll see very little
community involvement...
Really, really too bad, as I honestly think (and have knowledge) that a lot
of people actually *are* using the bridge.
But, if nobody is willing to provide feedback, help out and *acknowledge* it
(for whatever reason: company policy, shyness, ignorance, or worse:
indifference), nothing much is going to happen.

(As a side note: very "funny" to see that my Struts Bridge examples, the
JPetstorePortlet and even the very outdated MailReader demo together blow
away the download numbers of all the other "examples" provided at JBoss
Portlet Swap,
see: http://www.jboss.org/portletswap/downloads/portlets/framework
Also note: I never ever once got a single feedback from either a Struts
committer or the JBoss Portal team about the
Struts Bridge or these examples...)

Well, sorry if I come across a little bit disappointed, but I really would
like to see the Struts Bridge community (and for that matter: the whole of
the Portal Bridges community) to be more interactive.

So, if you want to make the Struts Bridge more future "proof", start helping
out today!

As you say, you're a big fan (great!) and have been using the Struts Bridge
yourself successfully.
Surely, you've extended it with some features which might be of interest to
others too, written some documentation or instructions for your fellow
developers, maybe even written some kind of manual (or maybe someone else
lurking on this list has?).

Please contribute and help out, send in feature request, create JIRA issues
for them:
 http://issues.apache.org/jira/browse/PB
Provide fixes, code, examples, patches, whatever.

I'll be glad to help out to integrate them, improve the website, provide
pointers to external articles, blogs, anything.
But you'll need to help me out, I simply cannot and will not do that on my
own.

I hope this long "rant" doesn't scare you or others away, I just want to be
honest: the Struts Bridge has a lot potential, even with Struts 2.x around,
because so many developers and companies still are and very much continue to
use Struts 1.x. I can easily think of at least 20 new features and
improvements for the Struts Bridge to make it even much better, but I don't
have the time nor interest to design and develop them all by myself anymore.

With kind regards and hoping for a lot more community interaction,

Ate

Mark McLaren wrote:
Hi all,

How about creating a struts-blank-bridges-portlet Maven archetype?  I
think we need to be able to demonstrate how easy and quick portlets
can be to write!

I'm a big fan of the Struts Bridge and was very pleased to see the
recent release in December 07.  What concerns me is that the noisier
portlet developers who write Spring Portlet MVC or Struts 2 portlets
(etc.) seem to be getting most of the attention when it comes to the
beginners question "How do I write a portlet?".

Personally (as a Struts 1.x developer), I see Struts Bridge as the
most natural way to create a portlet as it can be developed and run
standalone.  I am at a loss as to why more people are not using Struts
Bridge (could it be the documentation or lack of examples?).  I am
concerned for the long term future of the Struts Bridge product as the
alternatives seem to be grabbing the majority of the market share.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to