Saturday, October 12, 2002

Maven thoughts Maven thoughts...  [rebelutionary] For quite some time I've been meaning to answer Mikes concerns over Maven most of which are totally valid and I agree with, so here goes. Maven has moved along a little since Mike wrote this so some of the issues have been addressed. Mike's Bad points You have to throw away all of your existing Ant build file which can be very painful (I was under the impression Maven called out to Ant, not subsumed it!) It does take longer to run a simple build with Maven. The startup time can be irritating. It is a pain mapping libs from the repo directory to an IDE like (IDEA) I cannot run Maven from within IDEA yet It is very complicated to setup and migrate from Ant for a complex project - I assumed from reading the website it was fairly easy Following on from the above, there is no 'How do I migrade my Ant project to Maven?' I can't setup a mirrored repository (at least - I don't know how to). I want a repository inside our LAN, that if the file doesn't exist, goes to ibiblio.org - to save traffic, be faster, as risk insurance and to have our internal JARs on it "You can use all Ant tags - just no - signs in variables" The docs are very confusing and not enough (I know - it's open source, and thanks to #maven for helping out). Docs are always needed! It is ugly to separate project properties from local machine properties (in Ant we do this with a build.properties file for local props, and an init task for project ones) It forces you to think like a Jakarta project! This is not necessarily a 'best practice'! For example, my app doesn't produce a single JAR, it produces many different things. I'm sure this is just a default setup / more docs needed thing though. My answers Agreed. Though going forward there should be no reason why chunks of an existing Ant build can't just be integrated into Maven. For example Maven could support backwards compatible Ant scripts inside the maven.xml Agreed. Hopefully Maven will be optimizied soon. Also there's a new interactive Maven console; so you can start maven up once then have a very responsive Maven shell which makes it faster than Ant. There's an IDEA plugin (along with plugins for eclipse & jbuilder) to generate the necessary project stuff for IDEs from a Maven project Agreed. Hopefully all the popular IDEs will get a Maven plugin soon Agreed. I hope Ant migration tools become available to make this less painful Agreed. Its easy. Just create a file or HTTP based repository with the same layout and set your maven.remote.repo property in your build.properties in your home directory, the project directory or in your project.properties. This is a minor concession so that Maven can now support native Jexl expressions throughout the build files. Agreed, though they have been getting a bit better lately It works the same way in Maven. Agreed; you can extend your build to do whatever you want though.   3:57:30 PM    comment []

EJB futures. EJB futures. Rickards comments on the J2EE container shootout. Rickard's comments on the shootout and the war. Rickard ÷berg has posted some great comments on the J2EE Container Shootout. Before you get to the J2EE Container Shootout comments, keep an open mind as you read Rickard's comments on Bush's "war on terror" - like it or not, this is how we Americans look to some of our best allies. [Blogging Roller] Great comments from Rickard ÷berg and I agree with all of them. Servlets and Web Services are the future, I already view EJB as legacy. [James Strachan's Radio Weblog] It is kind of weird, sitting on the sidelines during the growth of ejb. I have some how always wound up on some project that was being done using traditional servlets and jdbc, "because we don't have time for that airy-fairy j2ee stuff on this project". The next project, however, was always going to be the all singing, all dancing, BEA based J2EE killer development project. I need to learn EJB, because I can't get java work in sydney without it anymore (unless I want to work at technologically retarded large corporates for the rest of my programming career). So, I am going to play dumb here again (probably because I'm good at it), and ask: Why is ejb now legacy? I'll be the first to admit the AOP is cool, in that you can make small peices of code have far reaching (nay, magical) effects. I'll readily admit that XDoclet, and other code generation tools, save hours of coding. I'll happily accept that Web Services are an essential ingredient in our coming interconnected world. But doesn't EJB still serve as a useful business object implementation strategy? Combine a object heirarchy encapsulating business rules, with a half decent cmp system, and you have the back end data repository for your web services right? Or have I completely missed the card trick? [Brett Morgan's Insanity Weblog Zilla] It took me a while to get the time to answer this one but here goes. Maybe my "EJB is legacy" statement was a bit over the top; EJB has still got a couple of years left before its commonly referred to as legacy in the same way that CORBA is today. EJB is a nicer pure java version of CORBA than straight CORBA and its still got a place in the computing landscape. So for folks wanting to do LAN based CORBA style distributed objects stuff, EJB still has a place. Though folks seem to be going web services more and more these days. Using tools like Axis and Glue its very easy to put together distributed web systems with pluggable transports under the covers from HTTP, email & JMS (for starters, I'm sure other things like beep, Jabber & JXTA will follow), without some of the inherent problems and complexities of EJB and traditional distributed objects. For me though the big reason why web services will win and EJB will increasingly become more legacy is connectivity. Web services work over the internet, across WANs and across language barriers and in particular span both the Java and .NET worlds. EJB doesn't do any of these things well. Just gazing into a crystal ball for a moment. If enterprise systems of the future were built without any EJBs at all and were built just with Servlets + Axis or Glue then what EJB features would be sorely missed? I can't think of many really. JDO seems roughly equivalent to EntityBeans plus there's a gazillion other ways of doing persistence. Web services frameworks like Axis and Glue typically take care of marshalling, stubs, skeletons etc. So having some lightweight container services like activiation, seems to be the only thing that we'd miss. Maybe Axis + Phoenix could be the new replacement for EJB?   3:42:12 PM    comment []

Do we need type safety for entity data? Do we need type safety for entity data?. James writes about DynaBean and DynaSql and its usefulness and indeed they are very interesting specially for producingdyanmicsqland dynamic query results and such. I've done something similiar but different which I think is worth to note here... [Memory Dump] Ara demonstrates an interesting approach to adding typesafe queries using doclet tags. I would like a little macro on top to make it a bit easier to use. e.g. Finder.search( Party.class, "country = $0 and searchCode = $1", new Object[] { "uk", "abc" } ); Incidentally another hybrid approach could be to derive from a DynaBean so that your entities are runtime extensible, but then add some typesafe methods to enhance type safety while still allowing for a more dynamic entity model. 3:08:37 PM    comment []

Fail fast Fail fast. Dare Obasanjo: Checked vs. Unchecked Exceptions Again.  I agree partially with both positions, but I don't believe that they go far enough.  If you believe in design by contract, then pick a language like Eiffel in which you can declare all of your pre and post conditions.  On the other hand, the logic that a system should not fail at compile time but should only fail when presented with unexpected conditions at runtime can also be applied to strong typing.  Languages like SmallTalk support this latter paradigm. While by training, I am in the former camp, I'm increasingly finding myself resonating with the arguments made by latter camp.  What makes this work is a switch from "it compiles, check it in" to "it passes all tests, check it in".  All too often, I see people making exceptions to this "just this one time", and my experience has been that it rarely works out.  JUnit, NUnit, and PyUnit are your friends. While Java and C# battle over who is the rightful successor to C++, it is quite possible that a language like Python (or, dare I say it, Ruby) will ultimately be the one that wins out. [Sam Ruby] Agreed. I think languages like Java can easily be extended using metadata, like doclet tags, to enhance design by contract features found in languages like Eiffel or to adorn source code with additional unit testing metadata like JUnitDoclet to better enable automatic testing and assertions.  1:36:21 PM    comment []

Google-recursion? Google-recursion?. Now Anthony has a cool idea here - customising his pages for each incoming search keyword - which Google will then index. Google-Recursion? Search keyword referrer personalisation. Its running on my pictures, media and weblog sections, the page detects if the visitor is coming from Google, extracts the keywords they entered into Google, and then performs a query across all the content records in my site, returning up to 30 relevance ranked related pages on my site. [rebelutionary] Thats a pretty cool idea. I guess its just looking for google referrer logs and extracting the query from it right? For such a simple thing, referrer logs are amazingly useful and powerful. 11:56:38 AM    comment []

Do we need type safety for entity data? What? He's crapping on about that liberal programming stuff again?. Carlos is wondering if OFBiz is turning OO on its Head or Programming in the Large? JIRA provides good validation for the Entity Engine (don't know what else it uses in the OFBiz project). Ack! I think we are a validation that the EE works for us - as usual, YMMV. We only use the Entity Engine mind you. OFBiz as a whole is a much larger project, to develop and entire commerce platform really. I hear that there are quite a number of sites running on the entire OFBiz framework now which is great! Have they gone mad? What's going on here? After all these years of moving away from Relational models to OO models, these guys have gone full circle. Could the be on to something? Let's think for a moment here, when we build webapps, using a framework like Struts or Webwork, we see things called Actions, in fact its not just for webapps, you find them in Swing too? What are Actions? Actions are functions in the form of an object. Could we just not have just had plain functions as first class objects? Are Actions the same thing as functions, so like what the OFBiz guys say, there are only Services and Entities. Just like what a C guy would say, there are only functions and data structures. I still don't really understand what Carlos means here by 'programming in the large'. OFBiz works wonderfully because it is not another OR framework (yes, there are no data related objects per se - there is one generic 'data holder' style object). It is what we have internally called a liberal framework. It enables you to very rapidly build new entities, migrate your data model, add attributes etc - all in a few XML files, without any code generation step. Main draw back? You lose type safety at compile time - so woe betide you if you don't have a good testing framework. (But you have a full unit test suite already anyway right? ) This is a minor draw back IMHO (again - I must stress this is for our application's needs - YMMV) and it does open up some nifty new things you can do... especially when combined with other equally liberal frameworks like... WebWork! For example you can write a single JSP fragment which understands (using ww tags and the ww expression language) how to display and link an entity. You can then pass any entity to that fragment (whether it represents an issue, a project or a comment is irrelevant) because all entities are GenericValues. This is very, very cool. [rebelutionary] Agreed with all of that. I think alot of projects don't actually need a typesafe entity model. Many projects spend most of their time just displaying data in some UI. Most UI technologies whether rich like Swing or lightweight like HTML don't really care much for typesafety anyway; there's often a loose binding between the UI and the data, so keeping the data in a loose generic format can often make things much simpler. For many UI centric applications I think this is a great approach. A couple of thoughts came to mind. There's a little library called DynaBeans which is part of the commons-beanutils package which provide a bean like abstraction but which is generic and can be created dynamically at runtime without the need for code generation. So you can use a DynaBean to wrap up a row of data from any database query etc. There's a simple class (WrapDynaBean) for wrapping a real bean as a DynaBean, so the DynaBean interface can provide a nice simple API for accessing beans generically, whether they are statically coded beans or dynamic from some source (SQL, XML, whatever). The other nice thing is that DynaBeans work nicely inside template engines like Velocity and Jelly (I'm sure it could work in WebWork too) acting just like normal beans. So expressions like ${customer.name} would work equally well on a DynaBean or real bean. After reading the above thread on OFBiz, it sounds very similar to the DynaSql part of the commons-sql library. DynaSql allows DynaBeans to be used as an API to relational data, turning queries into DynaBeans and inserting/updating/deleting data simply via "dynabeans". This approach also reminds me a little of the value object approach EJB folks use to try get decent performance; have objects that just represent state, that can easily be passed around your system and easily bound to a UI. Then keeping your business logic (session beans) seperate from your persistent state (value objects). Whether you want a typesafe interface to your entity model or a generic interface like DynaBean or OFBiz is really up to the client; if the client is a UI then a generic interface is typically preferable, as it can adapt dynamically at runtime to the server. If the client is some business logic then a typesafe interface is usually preferable. One final and slightly wacky thought is to conect this to web services. Maybe if the mechanism for fetching or changing persistent state was via a web service mechanism, then both typesafe OO models and generic interfaces could both be supported. Plus you also get cross-language and cross-platform access to your persistent data. Then developers could choose the API to the data they wish. I've started putting a story together on web services and databases to try and explain this last point in more detail.   11:45:58 AM    comment []

Article about Maven Article about Maven. Maven ties together tools for better code management is an article by Jeff Linwood talking about some of the highlights of maven.... [bob mcwhirter] Nice introductory article. 10:07:17 AM    comment []

Open Source product management Open Source product management. Santiago and Craig exchange their wisdom on the thin line between open source and making money of it. Very interesting interchange. [Outer Log Thought Web] Good exchange. I think increasingly more and more of commercial software will be based up a larger and larger core of open source software. 10:06:08 AM    comment []