Menu
▾
▴
aplaws-devel
|
From: Aplaws D. L. <apl...@li...> - 2009-05-24 10:42:00
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7407157 By: terry_permeance I did a search for "cms" in sourceforge and APLAWS isn't returned as a match. Makes me wonder if anyone is interested in raising the profile of APLAWS? Obviously not having a release on sourceforge since 2005 doesn't help nor the fact that sourceforge isn't linked to svn on fedora. Any thoughts on the future of APLAWS compared to others such as Alfresco etc. Terry ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-05-24 11:30:02
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7407192 By: shawnlane I think the problem for APLAWS is it has been abandoned by Redhat. The original architecture suited Redhat, designed to make money from services support. It was never designed from the ground up as an open source solution, first it only had Oracle support for example and Resin as the application server, plus a proprietary build system and RPM deployments . By removing the need for Resin, Oracle, Perl and building like a normal JEE application then this is a good move. However I think it is too late. The outside world things are moving on, specifications for content repositories that APLAWS does not have for example. I know a number of local authorities are looking at WCM from another perspective, they need a product that can deliver their services and is supported more easily that APLAWS but has a minimum 5 year product life cycle. I think APLAWS does work and is good for content management, but it does not meet what end users are expecting in 2009. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-05-24 14:08:09
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7407341 By: pboy Hi, | It was never designed from the ground up as an open source solution, I think it had been a Open Source project right from the begining when developed on MIT and Arsdigita Community System. But you are right, the APLAWS specific runtime system may have been a perfect solution in the short run, but obstructive in the long run. | The outside world things are moving on, specifications for | content repositories that APLAWS does not have for example. Compared to other Open Source CMS APLAWS has a lot of advantages and of features, others dont have. | specifications for content repositories that APLAWS | does not have for example There are only very few programs which follow that route (Alfresco for example). Most use a specific database backend or file system. End for the end user ir doesn't matter if the backend follows a repository framework. It's more a developer's concern. But again, you are right. We had better earlier taken up some of the ideas of the discussion on the last user meeting at Camden. But I think APLAWS / CCM has a lot of good and productive features and we are on the way to eliminate the bad side of the beast. :-) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-05-24 19:38:23
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7407611 By: pboy Terry, for shure, on the "marketing" side of APLAWS there is a lot of room for improvement -:) Since some time I have administrative privileges on sourceforge and I will update as much information as possible during the next weeks. Until now I was busy with the URL resource: beast. As soon as we have the next release ready, running in a standard JEE container, we should do some "marketing" work, not only sourceforge, but freshmeat, cmsmatrix and others. APLAWS / Byline had been present there for years, but sind the release of 1.0.4 and the need to change a funded project to "user led" had made some problems and delays. But looking over the commit log for the past months I think the project is going well now. Because of the "marketing needs" I'm very glad about your project of an "embedded" database and the "examples" project (which make it easier to provide a demo version). We should really try to discuss it and make plan for implementation. | Any thoughts on the future of APLAWS compared to others | such as Alfresco etc. APLAWS / CCM has a lot of outstanding features (semantic approach, categorizing system, among others, more technical ones) which set it apart from the crowd of Open Source projects like Typo3 or Mambo/Joomla, etc. Regarding Alfresco one idea was, to reimplement APLAWS's key conepts on top of Alfresco to make use of their implementation of the Java Content Repository framework. But Alfresco is not "really" an Open Source program but commercially driven. And currently it is far away from a full fledged CMS. So, if we decide to replace APLAWS persistence by JCR, we should use a really free implementation like Apache's jackrabbit. As a summary: In my perspective, the many outstanding features of APLAWS are currently hidden and hampered by a bloated code base, performance and a lot of minor usability issues, which sum up to a severe problem (steep learning curve) for new users. For (to) a long time developers (Red Hat?) refused or plumg forgot to clean up the code. Implementation of new features was the main and single goal. Discussions about that issue are 5 years old! "Never touch a running system" was the motto. That strategie led to a situation, where new Java functions were not used and some features of APLAWS are 2 or 3 times implemented in a different way, because nobody understood the (bloated) code or it was to time consuming to study it. So, for the foreseeable future / the next months we should: - extensivly clean up the code which will result in performance gain and easier maintenance and implementation of new functionality. - should polish up the user interface to make using APLAWS more pleasant. Having done that we have a good chance to regain a terrain we may have lost over the past year. By the way, did you receive my mail (yesterday) via user.sourceforge? Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-05-25 09:43:17
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7408371 By: shawnlane I think with the work you are doing, people looking for a JEE solution for content management will be able to just download and run, something that was very difficult with APLAWS without skilled developers. (NB many local authorities do not have any developers). To be constructive, I think areas that would make a difference is easy to set up and deploy sub site, with easily modifiable templates, it sounds like Mandalay solves the latter problem. >So, if we decide to replace APLAWS persistence by JCR, we should use a really free implementation like Apache's jackrabbit. Agree, it's not clear what Alfresco are doing, except to try and undercut products like Documentum and make money via support, training rather than straight licence fee. As a WCM product Alfresco is a long way from being complete. Performance is an issue which we fixed by buying a big expensive DB server and by implementing a severe squid apache layer. So another area is to sort out caching/performance, We have a lvs -> squid -> apache -> tomcat configuration and it's difficult for publishers to know if their published page is actually live! On our Intranet we went back to simpler apache with modcache -> mod proxy -> tomcat, which is fast and easier to deploy and a lot less painful than LVS route. PS I applaud you for the work you are doing on APLAWS! ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-05-26 07:11:03
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7409834 By: pboy Hi Shawn, thanks for the kind words. | Performance is an issue which we fixed by buying a big expensive | DB server and by implementing a severe squid apache layer. So another | area is to sort out caching/performance, | We have a lvs -> squid -> apache -> tomcat configuration and it's difficult | for publishers to know if their published page is actually live! On our Intranet | we went back to simpler apache with modcache -> mod proxy -> tomcat, | which is fast and easier to deploy and a lot less painful than LVS route. It would be perfect if you could shortly describe on wiki how you did setup the Squid solution rsp. the modcache solution and what was the performance gain about and what follow up problems araised (and how to manage them). As part of the maintenance manuel I wrote some paragraphs about it, but way too short. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-05-25 10:17:25
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7408424 By: terry_permeance A few random(ish) observations: 1. Aplaws was too hard to build before. It's now pretty simple with ecdc. Next steps would be to migrate to maven and to embed derby. 2. I think we should replace the output applications with Liferay (or equivalent) which does a much better job at layout, portlets, etc. By "output" I mean the content, navigation and portal applications. 3. The content center needs to be rewritten in a more productive UI framework. GWT might be a good option given Bebop is already Swing-like. In short, Aplaws is pretty solid from a technical perspective, even if it doesn't use Spring, Hibernate and the latest and greatest frameworks. I think the RedHat/Arsdigita/Aplaws community have done a great job. >From a non-technical perspective, Aplaws needs something to differentiate itself from the open-source crowd [http://java-source.net/open-source/content-managment-systems] and attract new users and developers. It could be government compliance but it could be something else. Alfresco + Liferay integration is pretty basic. Aplaws could position itself as a portlet-based CMS. Regards, Terry ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-05-25 14:23:04
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7408739 By: shawnlane 1. Aplaws was too hard to build before. It's now pretty simple with ecdc. Next steps would be to migrate to maven and to embed derby. 2. I think we should replace the output applications with Liferay (or equivalent) which does a much better job at layout, portlets, etc. By "output" I mean the content, navigation and portal applications. Totally agree with point 1 and 2. Once it becomes easy to build and deploy you will get more take up. Plus adding standards based portals would enable better expansion of the system and more plug in opportunities. I think this would also get SME's looking at it as an option. Rebuilding the interface for editing would be a major task, but using GWT might get more interest from developers. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-05-26 07:23:24
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7409847 By: pboy Terry, I'm not familiar with Liferay, but I think, APLAWS should exist as an autonomous, self-employed application and should not rely on / become dependent from a third party product. Indeed, portlet centric is a good perspective (and their is already a lot of implementation in Aplaws). APLAWS needs it's own portal server (therefore I'm interested in exploring ccm-ldn-portal and bylines ccm-protalserver), should be able to integrate other portlets and should be able to integrate itself into other portal solutions. That's a long term perspective. Regarding the presentation layer: The current "light weight" approach using xsl is a promising perspective with a lot of benefits compared to plain JSF or similiar frameworks. Our Mandalay development will make themeing much easier. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X