You may be surprised at what’s not in Alfresco 5

4325797829_280db25ffe_zIt won’t be long before we’ll be celebrating Alfresco’s tenth birthday. Sniff, sniff, they grow up so fast!

As part of that growth, it’s only natural that certain areas of the product will reach their end-of-life. Since its first release we’ve seen very little pruning of old or obsolete features, but that changes with the Alfresco Community Edition 5.0.b release.

Some of the things that have been dropped won’t surprise anyone. Some I consider regressions and may actually come back quickly, at least I hope they do. The surprises have been handled a little sloppily–Richard Esplin, the current head of community apologized for that earlier this week, essentially saying it was due to the rush to get 5.0.b out in time for Alfresco Summit.

You can read Richard’s post and the release notes for the full list of feature removals. In this post I’ll call out the major items you will no longer find in Alfresco Community Edition as of 5.0.b.

Alfresco Explorer

If you’ve paid any attention to my blog or just about anyone else who speaks or writes about Alfresco you already knew to avoid the original JSF-based web client called “Alfresco Explorer”. It’s the original web client accessible at /alfresco.

Alfresco has been saying Explorer was going away for a long time and they’ve finally done it. If you fire up Alfresco 5.0.b Community Edition and go to /alfresco you’ll find our old friend is no more. Good night, sweet prince!

All of my clients have been focused on Alfresco Share for years so if the impact of the change was simply that you couldn’t log in to that old client any longer it wouldn’t be a big deal, but there has been some collateral damage, which brings us to the next section…

Workflow Console, Tenant Console, or Basically Any Console

Unfortunately, some vital consoles leveraged the same JSF code base as Alfresco Explorer. When that went, these consoles went as well. The old saying about babies and bathwater comes to mind.

The removal of the workflow console is particularly irksome. It’s critical to anyone doing anything with either Activiti or jBPM in Community Edition. In my opinion, this is the most important console of the bunch.

The data dictionary console is also gone, which is used to enable or disable hot-deployed content models. If you only use content models deployed as part of the WAR this won’t affect you.

The tenant console is also gone. This obviously won’t affect you unless you are using the multi-tenancy feature.

The AVM console is also gone, but then again, so is the AVM as I’ll touch on briefly next.

The frustrating thing about these missing consoles is that they aren’t planned to make a return until 5.1, according to Richard. That makes 5.0 Community Edition harder to use than it needs to be. It’s possible that Alfresco will make the console framework available so that the community can help get these back in place quickly.

The AVM

The AVM is the ill-fated Web Content Management offering that Alfresco told you was reaching its End-of-Life back in February of 2012 so, again, you should not be surprised about this one. All but a handful of people have found other WCM solutions.

Lucene

This one sparked a WTF moment on Twitter earlier in the month when I was shocked to realize that 5.0.b Community Edition required Solr to be fully functional. Without it, you can’t do a people search, for example. Actually, you can’t do a full-text search either. So in my book, this makes Solr required to run.

Prior to this change you could choose either Solr or Lucene. I often used Lucene locally because it was one less WAR to deal with and it was the default when doing a manual WAR install. Some people preferred Lucene’s in-transaction indexing over Solr’s asynchronous indexing and eventual consistency.

I understand that Solr is the way forward for Alfresco. It just felt like this one was a bit rushed. I don’t remember any public communication saying that Lucene would no longer be an option in 5.0. The Alfresco Product Support Status page doesn’t list it either. Richard’s post says, “When we added Solr to Alfresco 4, we deprecated Lucene.” That may be true, I’m just not sure Alfresco told anyone, although it is possible I missed it.

SDK, API, & Publishing Features

The release notes for 5.0.b includes a “Feature Removals” section. Noteworthy entries include:

  • The old Java SDK has now been replaced with the Maven-based SDK in Github. This has been a long time coming.
  • The CMIS API endpoints from 3.x and 4.0 have been removed (use the 4.2 URLs). People are constantly using the wrong CMIS service URL for their version. Maybe this will help that.
  • “CML” Web Services SOAP API. Another one that is past-due.
  • JCR / JCR-RMI. I rarely see this used.
  • URL Addressability API. Who needs it when you’ve got web scripts?
  • Social Publishing Features.
  • Blog Publishing Features

These are all positive changes and I suspect will help Alfresco a lot on the engineering and support side.

Future Removals

The release notes also include a note that NFS and jBPM are now officially deprecated. I’ve been expecting the jBPM removal for a while now. If you haven’t started moving everything to Activiti process definitions you should definitely do so now.

Getting the old stuff out of the distribution is great–I’m glad to see it. I hope that going forward Alfresco can do a better job communicating openly in a timely manner about major changes like dropping Lucene. It sounds like Richard is going to take that on as part of his new role in Product Management, which is a very good thing.

 

23 comments

  1. Peter Monks says:

    Just one point of clarification: Alfresco’s use of Lucene has never offered “in-transaction indexing” in a way that can be relied upon, because:
    1. full text indexing has always been out-of-transaction (and therefore eventually consistent)
    2. in a cluster, indexing is always asynchronous (and therefore eventually consistent) on all but the cluster node that handled the write
    3. it’s possible for customers to turn of in-transaction indexing for Lucene (and doing so is recommended in some write-heavy environments)

    In short, while “in transaction indexing” is widely believed to be an advantage of Lucene, it’s not actually true that Lucene (or any search engine that’s ever been used by Alfresco) provides this capability. It’s rather unfortunate that this rumour continues to circulate, as it regularly catches extension developers by surprise (I’ve personally worked with around a dozen implementers to help them remove this exact assumption from their code).

  3. Jeff Potts says:

    Peter,

    What I meant was that you can create an object and expect that object to be immediately queryable via Lucene as opposed to Solr which has some amount of lag.

    Jeff

  4. pmonks says:

    Jeff I understood what you meant. I’m pointing out that while that’s a commonly held belief, it is in fact a misconception – one cannot, in general, write (create, update or delete) to a node in Alfresco and expect the write to be immediately queryable via Lucene.

  5. Julian says:

    @PeterMonks, my opinion is that Jeff is right, with Lucene you can expect in-transaction behaviour in most used scenaries (query by metadata and not by content, and with a sticky-session load balancer in a cluster environment). That’s impossible with Solr becouse of eventual consistency model.

    I know, as Alfresco partner since 2006, that Lucene is Alfresco’s Achilles heel but the problems introduced by eventual consistency are hard, and implies a lot of refactoring on custom code and external clients. I think Alfresco it’s not been very fair and responsible with its decisions lately, just saying Solr is great it’s not all the true…

  6. Pingback: Novedades en Alfresco 5 - Queres Tecnologias - Consultoría e Integración de Sistemas

Comments are closed.