Is there a project heaven? I hope so, because I went to use some Sitemesh documentation and saw that the parent project has been declared dead (as in, "has seen its final days.") Sitemesh has a new page for the next version, but that's in alpha ("lots missing"). It looks like it may be working, but irregardless the alpha status worries me.

The biggest thing to me though was the finality of OpenSymphony. It's a project that has a collection of libraries under it's umbrella: sitemesh, oscache, osworkflow, quartz, and ognl are the most popular although most have alternatives:

* Tiles can replace sitemesh if you're willing to accept a huge pile of suck instead of a Corvette; many frameworks can composite pages like sitemesh can now, too.
* EhCache and OSCache are a lot alike
* MVEL is probably a better version of OGNL
* Drools and OSWorkflow are a lot alike
* Quartz has no real contenders but there are some options

So what bothers me is that OpenSymphony has projects that are really useful yet it's "dead." Information lives forever on the internet but dead projects don't get any issues addressed, and as time passes they become less and less suitable. Considering how useful they were (and still are) that's hard to watch because you know they could keep up if the will was there.

But it's not, or else the project wouldn't have gone away.

The page on OpenSymphony.org suggests that the projects could get forked and live somewhere else; anyone interested in picking this up and running with it? Is a company willing to sponsor the continuation and improvement of these projects, maybe?

Quartz is now part of Software AG and OGNL is an Apache Incubator project, so neither one is dead.  They're just not part of OpenSymphony anymore.

Or Source Forge, or any of the other free, OSS hosting facilities. Fork it (them).

What tends to happen is the project doesn't die, it's the interest of the maintainers that fades.

The source code is usually pretty simple to get and fork.

The loss is the loss of the mailing list archives, open and closed issues/tickets, and other collateral created around the projects, and further all of the links across the web that say "oh I found a solution to that problem, go here" with a link to a dead page. These are the things that can really hurt project usability.

Also, while you can fork the code, be careful about the use of the name. The code may be open source, but the project name may well not. Best to contact the owners to see if they're willing to hand that name over to you as well.

But, minimally, if it's important to you, fork it on to a OSS hosting site.

"many frameworks can composite pages like sitemesh can now, too"

Any example? Thanks!

Struts Tiles is the obvious alternative.

Frameworks like JSF (templates) and others internally have this faclility.

"many frameworks can composite pages like sitemesh can now, too"

 

Any example? Thanks!

Such is the nature of the industry. Projects can die, get forked or get commercialized. This is why standards are so important - they act as a buffer between vendors and end-users.

EJB 3.1 defines simple declarative schedulers that meet the 80% use case: http://www.javascool.com/2010/04/15/ejb-timer-service/. I've personally always been a fan of Flux: http://fluxcorp.com.

Such is the nature of the industry. Projects can die, get forked or get commercialized. This is why standards are so important - they act as a buffer between vendors and end-users.

EJB 3.1 defines simple declarative schedulers that meet the 80% use case: http://www.javascool.com/2010/04/15/ejb-timer-service/. I've personally always been a fan of Flux: http://fluxcorp.com.

 

What do standards have to do with this?  You are implying one should stick to standards which in the Java world is near impossible since the standards either do not exist or in most cases, are so far behind the non-standards.  Look at the scheduler example, Quartz and Flux are far more robust than EJB 3.1 ones, plus you can use them in non EJB 3.1 containers and outside of a JEE container. Why wait to upgrade your servers when you can use a real scheduler today?  Simply add the jar.

Hmm, I thought what I said was pretty self-evident, but I'll restate it:

* If you fall within the 80% server-side use case that EJB 3.1 provides via the standard, it becomes rather irrelevant what happens to any given product/vendor.

* If Flux, Quartz, etc standardized 80% of the features, it would be much easier to switch between them.

* If you frivolously choose a non-standard product, expect risks of vendor lock-in.

"The Java EE is hard to upgrade" point has been discussed ad nausea and I don't see a point of repeating that discusion here. For example, take a look here: http://www.theserverside.com/news/thread.tss?thread_id=62515#346785.

Reza, good to see you active in person and online as always. :)

* If Flux, Quartz, etc standardized 80% of the features, it would be much easier to switch between them.

I'm sure James House, Terracotta, and now Software AG would agree — we're focused on what our users want and aren't paying too much attention to what the other guys are doing.

Our users aren't asking us to conform to a standard. They would rather have things like fine-grained security permissions in the operations console interface so the operations team can see only what they need to (and are allowed) to see.

Cheers,

David

http://fluxcorp.com

Good to see you as well!

I hate to say this, but perhaps this is a good time to consider open-sourcing the core scheduler for Flux? I always thought it was a great product that got less attention than it deserved (used it in a few project throughout the years), perhaps due to lack of being more "open"/standard?

I do know that you are doing quite well though :-).

I hate to say this, but perhaps this is a good time to consider open-sourcing the core scheduler for Flux? I always thought it was a great product that got less attention than it deserved (used it in a few project throughout the years), perhaps due to lack of being more "open"/standard?

With respect, Reza, I don't see the value to our customers to open source Flux's core. Giving away (parts of) Flux leads to lower revenues, which leads to fewer developers/engineers working on, testing, improving, and supporting Flux. Flux could not be a high flying open source company like JBoss was. That's just not our business model. We are who we are — a solid, growing automation/workflow/managed file transfer company, but we'll never be listed on the NASDAQ. :)

Cheers,

David

http://fluxcorp.com

David,

I do understand. I for one, have never been an open source zealot (although I am an open source developer now), which is why I used Flux when it best made sense :-).

Cheers,

Reza

Hi, I'm the project lead of SiteMesh.

SiteMesh got hit by a double whammy. Firstly, Java.net deleted the project, including the downloads. Then OpenSymphony shut down. And I have had very little time to contribute to it recently. It's a mess.

But, I can assure you, SiteMesh is not dead - just picking itself up. A group of volunteers have recently got involved to help restore it and get the momentum going. If you want to make a difference, we sure could use help.

The code has been moved to GitHub , the discussions to Google Groups and a new website, complete with revamped tutorials is in the works.

We'll be back!

Could you put the last release version[s] of SiteMesh up on SiteMesh.org?  That would give people a nice way to get both the current revs and also find info on the new stuff.

Cheers,

-Will

"MVEL is probably a better version of OGNL"

I'd say that is an understatement :)
 
Here are some additional things to say
-Dynamic and fully static typed execution, with full type inference.
-Drastically faster and provides both Map contexed as well as Object[] indexed contexts for ultra fast variable resolving.
-Pluggable data converter registries, for automatic coercion.
-Pluggable property handlers to allow mapping of bean style accessors to any instance.
-More extensive language with projections and folds
-Fast powerful templating
-Apache Software Licensed

With MVEL under the ASL I do wonder why Apache are wasting resources on this.

http://mvel.codehaus.org/

Mark

Sometimes I think whether we are delivering the best for our customers, short-term and long-term, for instance COBOL based technologies seem more supported than many Java based.

Sometimes I feel we are losing the ground pursuing the pure free stuff, dual licensing should be the future of professional open source otherwise we are building nice software today using adobe bricks.

If you're looking for information on the following projects, you can find more information at it's new home:

ProjectNew HomeWebWork and XWork http://struts.apache.org/

Quartz Scheduler http://www.quartz-scheduler.org/

SiteMesh http://www.sitemesh.org/

Compass http://www.compass-project.org/

OGNL http://incubator.apache.org/ognl/