BaseApp

Tuesday, May 8, 2007

Learning JSF

I have started with learning JSF recently and plan to be done with my first pass of reading the Complete Reference book for JSF (1.1 and 1.2) by Ed Burns and Chris Schalk, by end of June 2007. I have just completed the introduction part and building of a simple JSF application now and i feel that i have made the right choice to select JSF for the web application framework for BaseApp. In the past i did some experiments and learning of Struts framework (version 1.2.8) - again referring to the complete reference book on Struts by James Holmes and i remember that i was not very happy about the tedious process of incorporating the Struts framework in my web application. So since then i have developed 2 web applications and in both i could not kindle the desire to use Struts. With JSF, i must say, i am impressed with the features and the ease of use.

For baseapp, we will be using JSF 1.2 on Glassfish v2 (or v3 if thats ready when i am ready :).

Saturday, December 16, 2006

BaseApp project gets its logo


The final one... (simple image layering done using Inkscape).
But in the process of creating a logo for the project i did some experiments before i finalized on the one above. Here are some of the logos which i created in the process:


Script-FU -> Logos ->Soto Chrome

Script-FU -> Logos ->Glossy

Script-FU -> Logos ->Cool Metal


Google-like Logo (Developed using Inkscape)


Simple 3D floating Logo in Gimp 2.2.10 (based on basics tutorial)

I used Gimp 2.2.10 on windows to generate some of the above logos.

Let me know what you think of the final logo :) by leaving a comment.

Wednesday, December 13, 2006

Change in plan

I started BaseApp with the plan of using the J2EE 1.4 APIs (and frameworks built around it) but now that i have started reading the book Enterprise JavaBeans 3.0 (5th Edition) by Bill Burke and Richard Monson-Haefel, i feel its better i adopt the Java EE 5.0 APIs. Reason being that,
  1. EJB 3 spec uses standard Java EE annotations (for attribute oriented programming) and hence i wont be relying on xdoclet (and hence from now xdoclet does not have much of a role to play in green field projects of Java EE 5.0) and
  2. the Java Persistence API spec gives a standard programming model (POJO based) for ORM and hibernate 3.2 has become an implementation of this API. So though i can still use hibernate with JBoss 4.0.5 GA (which supports EJB 3.0 spec partially) as a JPA implementation i can have the option to change to TopLink too.
  3. an existing application using EJB 2.x beans upgrades the application server with support for EJB 3.0, then the developers could as well have the new beans written in EJB 3.0 which can co-exist with EJB 2.x beans. This backwards compatibility is required from the server vendors by the spec. Upon such an upgrade a project team may even decide to refactor the existing EJB 2.x bean classes incrementally to become EJB 3.0 POJOs. Such an upgrade especially will make more sense to organizations which use open source no cost app servers like JBoss AS. JBoss 5.0 Beta 1 is released recently (which implements EJB 3.0 spec completely) and i think companies which have used this AS for their product will have started their migration efforts already or will do so soon. Once the production ready version is available, i foresee that upgrade to JBoss 5.0 and other open source Java EE 5.0 app servers will be first to happen due to the obvious benefits of EJB 3.0 (easier to develop and deploy than earlier versions of EJB) and that such app server upgrade will not require the organizations to change their existing code. The organizations can first test their existing application thoroughly by simply deploying them on the new app server and later can add new beans which are EJB 3.0 and still later can plan for refactoring their existing code.
  4. EJB 3.0 container is really a micro container which can be embedded in say Tomcat (a servlet container) too. JBoss has hence changed it architecture from using JMX-based micro kernel to embeddable EJB 3.0 micro container with their support for EJB 3.0 in recent releases. This is something which Spring framework also did.
  5. Spring used to fill the gaps well for EJB 2.x era applications but with EJB 3.0 this gap is narrowed significantly, if not closed completely, in most areas of significance. So, i for one, who has no experience in Spring framework and had not learnt it so far on my own, feel that it will be better investment of time and effort to learn and master EJB 3.0 which is standard API set and not third-party (even though not as powerful and reliable yet as Spring).
In short, mastery of EJB 3.0 seems to be a better investment of time now and hence the decision to develop BaseApp as an EJB 3.0 application.

So this is the final list of tools and frameworks against which BaseApp will be developed for its first release:
  • Stateless/Stateful Session Beans
  • Message Driven Beans

Monday, December 11, 2006

Development Setup for BaseApp

What you need for development?

A Workstation :). Mine is a AMD Athlon XP 2400+ CPU (2 GHz), 1.5 GB RAM. The OS is WinXP Home Edition SP2.

Setting up a Development Environment

Before i start any development (primarily in Java) i make sure that the following open source tools are ready for use:
  • CVSNT is installed. Its simple click and install thing. Then you will need to setup the CVSNT Service and identify the CVSROOT. Then install a WinCVS client and access your project sources in the client and import the new project module to the CVSNT server. Once the import is done you can checkout the project sources and work on it. I will generally use the VCS support from the IDE itself (Netbeans 5.0 beta 2 has excellent support for the CVS). Yes, there are alternatives to using CVS; one is Subversion. But for me CVS works fine as i am more used to it. Also you might want to have the ViewCVS (A windows port link) installed to browse your CVS repository online. You would need Python and Apache installed on your system for ViewCVS to work. For BaseApp, i will use the Subversion SCM provided at Google Code site.
  • Install a issue tracking system. Bugzilla or Scarab. For BaseApp, i will use the issue tracking service provided at Google Code site.
  • A Free SMTP Server (as you generally require to send out emails from either your own application or for the tools above like scarab). This will be required only to test/develop BaseApp components.
  • A Wiki is useful to record your information and to share it with other developers in your project. Its more a best practice to have a Wiki in your setup and use it for recording the module features which you have learnt over time. This makes a easy reference for yourself in future and also for your colleagues who might need to maintain the work done by you. An alternative to Wiki nowadays is to setup a blog.
  • Mailing list: You need to (especially so for open source projects) have the discussion forums setup for the users and developers (contributors) to be able to discuss about the project/modules. Majordomo is the most famous, free, such option, which comes to mind. For open source project like BaseApp, we will use the free hosted discussion groups by google.
  • An IDE. For Web development work, i have developed a taste for the Netbeans IDE. Other good alternatives (and some say better :) are, Eclipse (Open Source) and IntelliJ IDEA (Commercial).
  • MySQL Database or Oracle 10g XE.
  • Continuous Integration : CruiseControl (open source) or AnthillPro (commercial).
The above tools mentioned are just some of the most commonly required tools which are required in a project's life cycle.

Saturday, December 9, 2006

Starting BaseApp

BaseApp is my first (owned, administered by me :)) open source project which is hosted at Google codes. Go to the project page to learn more about the objectives, status, etc.


(c) 2006-2007, Watsh Rajneesh. All Rights Reserved.