Magnolia 2.0: J2EE Content Management meets Usability

Discussions

News: Magnolia 2.0: J2EE Content Management meets Usability

  1. The Magnolia 2.0 CMS tries to combine an clean GUI, enhanced usability, web-based deplyoment and J2EE enterprise strength. It is the first open source CMS using JSR-170, the "Java Content Repository API".

    Magnolia 2.0 released: Usability and J2EE Enterprise Content Management in one hard-to-beat Open-Source package.
    Basel (Switzerland), Nov. 15th 2004

    With the release of Magnolia 2.0, a new generation of Open-Source Content Management is entering the highly competitive CMS market. Great usability paired with all advantages of web-based systems and built for the enterprise strength J2EE platform: a combination only Magnolia offers. As open-source software with the well-known advantages regarding TCO (total cost of ownership), security and expandability, Magnolia is also foremost in adopting new standards. Magnolia accesses content using JSR-170, the "Java Content Repository API". According to industry experts, JSR-170 will bring about major advances in interoperability and investment protection. Here, Magnolia delivers today what commercial vendors will tomorrow.

    Magnolia 2.0 from Obinary is the most progressive open-source J2EE Enterprise content management system today. Magnolia 2.0 offers some outstanding features, even compared to commercially licensed systems. The developers at Obinary succeeded in transferring well-known desktop software behavior to the web-based user interface. The result is a substantially improved user experience, which for once earns the often-strained description "intuitive". All actions can be performed directly in the web-browser using the right mouse button. Content elements can be moved and sorted using drag & drop. Thus the use of the system is simplified and faster, and required user training and resulting costs are minimized.

    Magnolia 2.0 is first open-source CMS and one of the first products at all based on the new JSR-170 standard, which defines the "Java Content Repository API". Communication between "Content Repositories" and applications is standardized and implemented vendor-independently. Content repositories specialize on intelligent content storage, while applications like Magnolia can focus on the management and presentation of content. Content from different applications supporting this standard can be shared easily, managed vendor-neutrally and stored future compatible. Magnolia 2.0 uses the open-source licensed JSR-170-implementation "Jackrabbit" as a content repository, based on version 0.14 of the JSR-170 standard definition.

    Magnolia 2.0 has a modular architecture, which offers efficiency and performance and allows easy and precise extensibility. As a J2EE solution, Magnolia 2.0 offers the excellent scalability, availability and performance this technology is known for. Companies like Siemens Enterprise and numerous customers from the pharmaceutical industries are already using Magnolia today.

    Magnolia 2.0 has been developed by Obinary, a software and consulting firm located in Basel/Switzerland that also offers commercial support, hosting, training and implementation services for Magnolia. Magnolia 2.0 is available from http://www.magnolia.info/ and can be tested online at http://www.magnolia.info/demo.

    References
    Obinary
    Magnolia Community Site
    Magnolia International
    Features
    Live Demo
    Live Demo
    Screenshots
    Download
    Reference-Section

    Threaded Messages (37)

  2. Correction[ Go to top ]

    Just a minor correction: "Great usability paired with all advantages of web-based systems and built for the enterprise strength J2EE platform: a combination only Magnolia offers." should be "Great usability paired with all advantages of web-based systems and built for the enterprise strength J2EE platform: a combination offered by Magnolia."

    For example, this combination (and a shitload more, of course) is also offered by our own CMS/portal product.

    To say that you are the "only" one to do any particular thing is always dangerous ;-)

    And as a sidenote, after having tried your live demo I would seriously object to the catch-phrase "great usability". In particular, the use of forms for input is just so last millenia. But as a developer of a competing product I'm obviously heavily biased.
  3. Correction[ Go to top ]

    To say that you are the "only" one to do any particular thing is always dangerous ;-)

    This is out of context - the context being Open Source.

    > the use of forms for input is just so last millenia
    Its not mandatory, we have a rich text editor as well and it would be trivial to have a XML editor instead. Its just a sample template, deliberately kept *very* simple to show developers *how* things are done (check out the code, please); not *what* can be done.

    Can you show me the open source web-based interface that matches ours? I am curious who else is as crazy about usability as we are.
  4. This is out of context - the context being Open Source.

    Once again, wrong eXo Platform is and is also based on JCR for its content portlet.

    "Can you show me the open source web-based interface that matches ours? I am curious who else is as crazy about usability as we are."

    For the web interface eXo Platform lets the portal manage it as set of portlets and the CMS is just a set of portlets.

    Have a look to the web interface an edit modes of the portal and you will see that the web interface there provides much more functionnalities starting from layouts and going to skins.


    I don't want to start a flame war stating that such product is better than the other...I just want to moderate both your Press Release and your tone in your threads.

    Please avoid words like "trivial", " who else is as crazy about usability as we are", it is simply very wrong to think you are the only one that care about usability!

    Sincerely

    Benjamin Mestrallet
    http://www.exoplatform.com
  5. Correction[ Go to top ]

    This is out of context - the context being Open Source.
    Point taken. In that particular field, yes, your UI might be considered top of the line (which, unfortunately, says something about the state of OpenSource CMS's).
  6. Correction[ Go to top ]

    As an information architect/usability expert who also suports open source software, I would love to help out with user interface architecture/design. But do you really think the commuity as a whole sees the value in that yet?
  7. Usability[ Go to top ]

    As an information architect/usability expert who also suports open source software, I would love to help out with user interface architecture/design. But do you really think the commuity as a whole sees the value in that yet?

    Well, we see a lot of value in that, and it is to be assumed that at least some of the people that have downloaded and installed Magnolia share our values. We care about the people who have to work with the product, and we built a system for them.

    You are welcome to join the team!
  8. Correction[ Go to top ]

    Hi Rickard,

    > For example, this combination (and a shitload more, of course) is also offered by our own CMS/portal product.

    How can I find more info about your product?

    BTW, I recall that you leverage AOP in your product,
    does this just ease your development or it will provide more
    flexibility and competitive features to your product end users?

    --alireza
  9. Correction[ Go to top ]

    How can I find more info about your product?
    Well, I'm not sure how useful it would be to you because a) it's not yet fully translated to English and b) we don't have staff to handle any higher sales rate right now (crazy, I know). Both points are being fixed, due to high demand, but that's the main status right now.
    BTW, I recall that you leverage AOP in your product,does this just ease your development or it will provide more flexibility and competitive features to your product end users?--alireza
    Well, it definitely eases our development, and yes we have done a lot of competitive features because of this. Whether anyone else can do this without AOP: of course, but probably not in such a short amount of time. So, we can do lots more to a lower cost (time/money-wise). In that sense it directly benefits our customers.

    Does that answer your question?

    /Rickard
  10. Correction[ Go to top ]

    Does that answer your question?
    Thanks for your answer, I hope you can success in your business, I'm sure about the quality of the product that you'll develop, you're a real genius.

    --alireza
  11. Very Nice[ Go to top ]

    I saw the video, I think this is great.

    We started by writing frameworks, to using frameworks (Struts, Spring) to now customizing applications (CMS, Forums, jRoller).

    I agree, UI could get to be a bit more JDNC features.
    http://jdnc.dev.java.net/documentation/roadmap.html

    .V
  12. What are your thoughts on developing a Java (Swing or SWT) based client interface? Basically a rich client?

      - Andy
  13. developing a Java (Swing or SWT)[ Go to top ]

    We did not want that (Java based GUI). Many internets disallow all software installation on client machines. I agree that HTML/JavaScript is not exactly latest & greatest for building GUI's but I think we have managed to build an excellent interface that has a zero deployment barrier.
    - Boris
  14. developing a Java (Swing or SWT)[ Go to top ]

    Main Form screen: JavaScript error - Unterminated string
    constant

    <form name="samplesForm" action="/features/mailform.html" method="post" onsubmit="return (checkMandatories(this.name,'"Please make sure you have filled out all fields marked with an asterisk"'));">

    check out your onsubmit stuff


    Dmitry
    http://www.servletsuite.com
  15. developing a Java (Swing or SWT)[ Go to top ]

    Main Form screen: JavaScript error - Unterminated stringconstant<form name="samplesForm" action="/features/mailform.html" method="post" onsubmit="return (checkMandatories(this.name,'"Please make sure you have filled out all fields marked with an asterisk"'));">check out your onsubmit stuffDmitry

    Thanks. Its only a sample template but still.
    added to the issue tracker:
    http://jira.magnolia.info/browse/MAGNOLIA-199
    - Boris
  16. Andy,
    I think this is the type of thing that is the future of new development as far as UI:

    http://www.canoo.com/ulc/demos/index.html

    .V
  17. Stating that "Magnolia 2.0 is first open-source CMS and one of the first products at all based on the new JSR-170 standard" is simply WRONG, eXo Platform has made its prototype available in August.

    I don't claim we were the first :) I just tell you are not.

    So I second Rickard here, becareful in your announcement if you don't want to loose all your credibility among the community.

    Indeed, in our last article published in august on TheServerSite.com we explained how we were leveraging the JCR (JSR 170 - level 1) to provide our CMS JSR 168 portlet prototypes...you should have a look...

    Benjamin Mestrallet
    http://www.exoplatform.com
  18. Stating that "Magnolia 2.0 is first open-source CMS and one of the first products at all based on the new JSR-170 standard" is simply WRONG, eXo Platform has made its prototype available in August.

    a) that was a prototype not a final product
    b) Magnolia is *based* on JSR-170; compatibility is not added as an afterthought
    c) Magnolia 1.0 was release 15th November 2003, and had the same base: JSR-170
    The press release can still be found in many places on the web.
    http://www.magnolia.info/en/international/press-releases/previous-obinary-releases/magnolia_release_1_0.html

    So I think we can safely say that we are the first because its a plain and simple fact, that is easily revealed by a Google search. Anyways, thats not the issue. Check out Magnolia, its beautiful and very easy to set up, use and template with.
  19. Magnolia 1.0 was release 15th November 2003, and had the same base: JSR-170The press release can still be found in many places on the web.

    Come on, give me a break, how can you say that you had a product in November 2003 while there were even no draft at that time (refer to JCP : http://www.jcp.org/en/jsr/detail?id=170). The final release is not even out. So you can promote your web interface but stop here for now please.

    Your press release in November 2003 was not serious about JCR (I do not argue against the web interface you made). You were building on the jcr proposal in the Apache slide project which were quite far from what the current JCR wpec is.

    I will go even further and say that without search (in your roadmap it is for version 2.1) the use you make of the current JCR API is not even reaching level 1 of the spec.

    I remind that the spec is split in 2 level with level 1 including read, write, search, categorization and meta-data -node type- management while level 2 includes security, versionning, locking, observation....

    Also if you look in our september 2003, also published on TSS, we were already presenting a CMS backend (not an implementation of the JCR API at the time) to work with the portal design, so please once again avoid those kind of sarcastic sentences "compatibility is not added as an afterthought".

    I looked at your demo and even code, before writing of course. And appart the web designed which is polished indeed , there is not much, but that maybe enought to manage some almost static web sites. In fact, a CMS without a portal web front or a portal without a CMS integrated is not a viable solution anymore.

    To me Magniola - as it is now - is just revisited version of OpenCMS.

    Benjamin Mestrallet
    http://www?exoplatform.com
  20. Portal <> CMS[ Go to top ]

    In fact, a CMS without a portal web front or a portal without a CMS integrated is not a viable solution anymore.To me Magniola - as it is now - is just revisited version of OpenCMS.Benjamin Mestrallethttp://www?exoplatform.com

    I stronly disagree here. For sure, you must argue this way, because Magnolia is not a porlet infrastructure and you have that feature. But i am doing real CMS projects the last years (not with Magnolia but commercial CMS systems) and i can assure you, most companies want a CMS product in first place and i dont see a need for them to go with a portal framework, thats just not what most of them need.

    And when i look at the market leaders here in germany when it comes to CMS, i see a lot of non-portal-CMS out there. So, it seems there is another one in this thread creating big sentences without too much substance. But at the end its all marketing right?
  21. Portal <> CMS[ Go to top ]

    Well if you are following the reports made by analyst groups such as Gartner or Yankee group, you will see that the market is going toward a web integrated application suite. In other words, Portal + CMS + BPM + app server.

    I don't say that all the project that were made so far with pure CMS were wrong. I just say that the integrated platform goes further web content management and site publishing and that it is the future. So don't feel offense by my words if you have made pure CMS projects so far :)

    I can bet that most CMS companies will either implement or buy portal sofwate (or the other way) within the next few years. That is what happen when Vignette bought Epicentric, and that is a very logical direction, letting the portal manage the layout and skins while having the CMS managing the content and publishing processes.

    If you think it is not much sentence....well that is your opinion, but not sure those analysts would agree with you.

    Finally, not sure that giving another point of view and correcting errors is marketing. I would not have written here if I felt the Press Release was fair...

    Now I also like to sign my posts. So that if people desagree with me they can tell me when they see me :)

    Benjamin Mestrallet
    http://www.exoplatform.com
  22. Well I don't understand what worries you?

    Yes, we went through pains to keep up with the ever changing spec, and no I don't state that we are JSR-170 compliant because the spec is not finalized, so we can't be, no matter what level.

    However, the site templates we wrote last year for Magnolia 1.0 will work without a change on 2.0 because we knew there would be changes.

    Magnolia has been productively running since July 2003, when we went life with http://www.obinary.com

    In 2003 we were where JCR was. I know the spec well enough, and yes there are different levels of compatibility. Once it is finalized and implementations are available, we will use them. So what? If you use Magnolia now, you get all that for free as soon as it is there.

    We have written an easy to use CMS, and I second Marc if he says that there is a "market" for that. We have done so because there was nothing out there that did what we wanted, and did it the way we wanted it.

    We decided to write a standards based open source CMS that does right what it does instead of trying to be everything to everyone. I am convinced we succeeded.

    Boris Kraft
    http://www.magnolia.info
  23. Magnolia Vs. OpenCMS[ Go to top ]

    How does Magnolia compare with OpenCMS?

    Our company choose OpenCMS due to it level of maturity and we need not to start 2 instance of tomcat.

    Best regards,
    CK Lim
    www.mediatrend2u.com
    Your Satisfaction Is Our Business
  24. JSR-170 + inefficient[ Go to top ]

    How is it useful that Magnolia is using a JSR-170 compliant repository? Sooo many files... So slow, so much memory needed!

    And why does it need to come bundled not with one Tomcat, but with two?
  25. JSR-170 + inefficient[ Go to top ]

    How is it useful that Magnolia is using a JSR-170 compliant repository? Sooo many files... So slow, so much memory needed!And why does it need to come bundled not with one Tomcat, but with two?

    JSR-170 is useful for many different reasons to different people. If you read the press release, you will find that I have given a number of reasons that I shall not repeat here.

    The "many files" is a pure implementation issue of the currenty JSR-170 implementation we use, and will change. The nice thing abut JSR-170 is that we can change that issue without anyone losing content. Check out jackrabbit to see where the implementation is heading.

    Regarding the tomcats: Magnolia is very scalable with built-in clustering. To show how that works, it comes as a two server download. We are thinking about changing that, but for everyone that complains, there is someone who thinks it is great and exactly what he has been looking for.

    You can easily deploy in a single tomcat.
    Regards
    Boris Kraft
  26. clustering built in[ Go to top ]

    Regarding the tomcats: Magnolia is very scalable with built-in clustering. To show how that works, it comes as a two server download. We are thinking about changing that, but for everyone that complains, there is someone who thinks it is great and exactly what he has been looking for.
    I have been following the mailing list, and have so far only read comments that objected to the 2 server setup, which AFAIK is currently built into the product. Clustering should be (and is) up to the appserver - the app only needs to cooperate
  27. clustering built in[ Go to top ]

    I have been following the mailing list, and have so far only read comments that objected to the 2 server setup, which AFAIK is currently built into the product. Clustering should be (and is) up to the appserver - the app only needs to cooperate
    The two server setup is not built into the product, its built in such a way that you can activate content between any number of Magnolia servers, and thus it is possible to separate authoring from public environments, or to publish to physically distributed servers etc.

    Regards
    Boris Kraft
  28. Magnolia Vs. OpenCMS[ Go to top ]

    How does Magnolia compare with OpenCMS?Our company choose OpenCMS due to it level of maturity and we need not to start 2 instance of tomcat.

    Magnolia does not need to run in 2 tomcats, but due to its architecture allows you to do pretty nice stuff, like activate content (= publish) to several public web sites at once for scalability, security and performance.

    Example: authoring server is inside the firewall, public server outside. Due to this architecture, you can scale on the end you need to. For instance, for a university you might want to have one authoring server per department, but still run the public website on one (maybe mirrored/clustered) machine. Magnolia gives you that flexibility.
  29. Pretty impressive[ Go to top ]

    This is a pretty impressive piece of work. One thing I didn't see is a workflow for change authorization. This is pretty standard in CMS systems. Is it there and I'm not seeing it?
  30. Pretty impressive[ Go to top ]

    This is a pretty impressive piece of work. One thing I didn't see is a workflow for change authorization. This is pretty standard in CMS systems. Is it there and I'm not seeing it?

    No there is no workflow as such at the moment; but we do work with any number of "chained" instances; per default that means you have an authoring server and a public server. You can make create rolese that disallow a user to activate (i.e. publish) content.

    Full blown workflow is scheduled for the next release; we started working on it this very week.
  31. Shmameless self promo:
    http://sourceforge.net/projects/infonoia

    Info: http://infonoia.com/en/content.jsp?d=inf.01.05

    Above is extended and used here among other places: http://wiki.apache.org/struts/PoweredBy

    Also, site will soon have 30! videos uploaded to sf.

    .V
  32. site will soon have 30! videos uploaded to sf..

    I imagine this is going to take a fair amount of time.
  33. I saw a brief demo of the product on your site, but I havent been able to access the site for the past two days. Hope you can get your issues worked out soon...I'm looking forward to giving it a trial!
  34. Good work guys.

    BTW, when is 2.1 out? I am always looking at good OS solutions but without versioning and workflow features you won’t meet too many CMS demands...

    Thanks
    AA
  35. Good work guys.BTW, when is 2.1 out? I am always looking at good OS solutions but without versioning and workflow features you won’t meet too many CMS demands...ThanksAA

    I would estimate the next release to be available no later than end of March.
    Regards
    Boris Kraft
  36. CMS without backend database?[ Go to top ]

    Correct me guys if I'm wrong, but I haven't found any traces of database in and around Magnolia.

    Does it mean it's CMS with _file-based_ persistence?
    What is the maximum number of content items it can handle?
  37. CMS without backend database?[ Go to top ]

    Correct me guys if I'm wrong, but I haven't found any traces of database in and around Magnolia.Does it mean it's CMS with _file-based_ persistence?What is the maximum number of content items it can handle?
    No, as the release has stated, it is the first Open Source CMS that is using JSR-170 API, which makes storage of content an implementation issue.

    We use Jackrabbit, but its up to you which JSR-170 repository you use. Our current implementation stores its data "directly" on the filesystem, but that will change.

    JSR-170 also defines SQL and XPATH to access content; and can easily be layered on a relational DB.

    IBM for one has made a public announcement that all its content related products will adhere to the JSR-170 API.

    Please out check the JSR-170.
    Regards
    Boris Kraft
  38. I'm questionning my self about a project that my team and I are developping on Magnolia 2.0.

    -Is Magnolia 2.0 compatible with any JCR interface developped
    upon a data base. I mean, if I have already data-bases, can I
    just code JCR interfaces and "Plugs in" Magnolia 2.0 on them?
    Will magnolia recognise the content and use it directly as its own data base?