This one uses a list of properties as it's project model.
It will be interesting to see how it's possible to pass parameters onto javac to do the compile.
That the exception was allowed to bubble out so far is a testament to the complete evilness of throws Exception. I
]]>Since his blog requires a Blogger account to post, I'm commenting here.
Simplicity:
Even though Maven is not a simple beast (lets not pretend that Hivemind is either), it does make quite a few things simple to the user of the build. Knowing that a project will always be able to have a standard set of functionality on it, removes the usual Ant build file reading and understanding most people go through when trying to start with a project.
However, he's fallen into the same trap with his proposed Ant build file, he's now got Ant XML documents pretending to be programs with the <import> tags.
Consistency:
This is probably one area maven shines above howards example build file. He now has his own common 'jar' and 'download' code, not a shared consistent one.
Efficiency
I'll agree Maven's not as slim as Ant, but then Ant's not as slim as make.exe either. As for needing to fork the unit tests, maybe if there was a bug report or a user list posting someone could fix this. Without it, there's no chance.
Feedback
I agree Maven sucks at this, but I still haven't seen a failure error message from an imported ant build file to compare it with.
On to the example maven and comparative build files.
In summary, yes Maven will be more verbose than hand crafting personal Ant build files, and yes the error message reporting in Maven is woeful.
I'm still waiting to see the build file that Howard comes up with to produce his "Integrated pretty documentation (with navigation)".
Go for it!
I'm happy that with Maven we have all this stuff centralised and standardised, and that 100s of developers aren't rewriting tasks, making up macros and other stuff to add into their Ant build files.
Maven's not everybody's cup of tea, but it does do quite a good job of cutting down on build file psychomania.
Howard, get a trackback link!
]]>Firefox has this cool feature that allows you to parameterise a bookmark.
Take this bookmark:
to http://jakarta.apache.org/commons/jelly/tags.html#core:%s
Note the %s there.
I gave that bookmark a 'keyword' of jelly in the bookmark and I can now type
jelly forEach
or
jelly if
in the address bar and be taken straight to the docs for the tags.
I also use one for Ant.
Thanks to Mark Pilgrim for the details and Giulio Piancastelli for the Ant core tasks one.
]]>"Forgive my possibly perverse Maven-hating Ant-loving sense of humour, but I think if the Maven guys think that's all they need to learn from Ant, they've got another think coming!"
We have lots of 'thinks' coming Scot. I'm glad you agree with us that there is a lot Maven can learn from Ant.
I was by no means saying that's all Maven could learn from Ant. That's too long a list to go into. I was simply pointing to Conor's great article for future reference.
]]>Plugins live in $MAVEN_HOME/plugins.
- There is no documented location for non-maven plugins to persist between installs.
- No documented location for 'single user' plugins for a multi-user install.
Which plugins?
- There's no way to define a list of required plugins for a user or installation. This creates issues across larger installations.
Plugin defaults
- There's no way to provide a standard set of defaults for plugins across a set of developers. The ${user.home}/build.properties file becomes a maintenance issue. It would be better to externalise or parameterise defaults.properties.
Installation
- plugin:download is great, but an 'artifact:download' is needed as well.
- plugin:update is also needed to pick up new releases of existing plugins with a confirmation before install.
- installation should be to either a user-only or system directory.
- Version clashes (e.g. multiple versions of a plugin) should be displayed during the build so that they can be corrected.
- As the ${maven.home}/plugins dir is a single directory, clashes with plugin jar names seem inevitable, and it would seem better to structure the plugins dir like a repo with ${groupId}/plugins directories. e.g. all maven plugins go into ${maven.home}/plugins/maven/plugins, and plugins from sourceforge go into ${maven.home}/plugins/sourceforge/plugins
- Plugin dependencies are not usually provided with plugins. The download/install process should fetch them all rather than waiting until later.
Unzipping
- Plugins are automatically unzipped creating large numbers of directories and files in typically ${user.home}/.maven which are often left over on a new install causing issues
Caching
- Plugins contents are cached into files in ${user.home}/.maven/plugins. Until rc3 this cache would often become corrupt over time with unpredictable results. Once rc3 is out we'll see how this goes.
Plugin classpaths
- Plugins written in Jelly often have clashes with the libraries in use by Maven. The classloaders need to be isolated.
- Classes provided by Maven (ant junit etc) often require classes to be found in their classloader.
- Plugins often have issues with jdk 1.3 and the xml classes.
JDK Differentiation
- There's no easy way to specify dependencies for a project by jdk version (e.g. xml classes needed only for jdk13 etc)
Dependency specification
- There's no way to specify for example a released junit > 3.8, a specific version is always required. Some way to specify 3.x or > 3 would make keeping up to date a lot easier, and specific versions are still required for repeatable build situations.
Plugin information
- Once a plugin is installed, it would be nice to be able to dump info about the plugin (name, url, distribution site, authors, mailing lists etc....)
Goal naming
- Plugins usually define goals with a standard prefix, e.g. myplugin:theGoal. Exceptions to this rule should be reported, and prefixes being reused by other plugins reported as well.
Axis is gone???
IBM pulled out sometime late in 2002, and the project has been healthy and developed ever since.
You know what they say about publicity....
]]>Experience with Struts, Tiles, WebSphere, DB2 are a plus....
]]>Bad move. The desktop would no longer come up on WinXP SP1a.
Uninstalled Subversion and my desktop was back, whew.
I couldn't believe it was Subversion, so I did it again, just to make sure.
Yep, no desktop again. Off to the tigris site....
]]>A multiproject build of 24 projects into a single EAR file (including non-container tests) used to allocate 154MB of memory.
It now uses 67MB to do the same thing.
Not optimal, but a swag load better.
Update: Oh, and it also cut 10 minutes of the build time too
Good work Brett!
]]>Interesting read...
]]>In the last month, as part of automating our build process, I've raised 4 bug reports on the ejbdeploy tool of WebSphere Application Server, Advanced Edition (For the interested, PMRs 49750, 55301, 55386, 55930).
49750 - opened 2004-02-19 and closed on 2004-03-05 ('corrupt' metadata files)
55301 - opened 2004-03-05 and closed on 2004-03-24 ('cmp ejb cant have a cmp field called 'value')
55386 - opened 2004-03-08 and closed on 2004-03-10 ('corrupt' metadata files)
55930 - opened 2004-03-23 (ejbdeploy doesn't include RMIC code if an ejbModule directory exists)
All of these are problems with the tool where it either fails to run to completion successfully, or runs successfully but doesn't create a correct jar.
The code can be successfully exported out of IBM WebSphere Studio AD in each case, so there's an inconsistency between the development and deployment environments.
The response from IBM on 55301 when I enquired if these would be fixed in an upcoming release was
Potential fixes for problems in WSAS 4.0.x would be evaluated and several factors will help us to make decision whether or not fixes for it would be
developed such as its prevalence, workaround availability, and if the newer releases already have fixes for them. For this particular problem we would not work on a fix for WSAS 4.0.
The end result? I've wasted days on these issues with a decision from IBM that these issues will be not be fixed in a later release.
The decision to not fix these issues mean that any other poor sucker on WAS 4.0.x is going to have to go through the same pain as I did.
It also doesn't give me a good feeling about other bugs we may pick up on the way, if they're already known about (by IBM) and I then spend days trying to work around them.
It would be much better if the list of issues and workarounds were documented so that we could easily find them, and in the case of calling a CMP field 'value' steer clear of them altogether.
Surely this would make the support team's job easier too.
]]>As someone who's been paid for speaking there, I found it very rewarding. Not only did I get paid for talking about technical topics, but I also got to attend a conference where I learnt a lot from people who know what they're talking about.
And I fly from Australia to go there.
]]>This year the focus is on building and deploying Web services using Java and Open Source technologies, so Apache's various projects including Jakarta should be well represented.
If you're a technical person, I'd recommend submitting a paper.
I've presented there a few times, and the conference is a "by geeks, for geeks" event, with a lot of interaction. I've gotten a lot out of the sessions I attended there, and made some good friends along the way.
]]>The was40 plugin has been useful, and I've added a generate-ejb-code goal to it, which generates the code needed for the ejb jar to run in WAS.
The EJBDeploy tool in WAS is a very fragile beasty. I've had lots of NPEs due to invalid chunks of metadata in the various files WAS/WSAD uses. With some help from IBM support I've been able to identify the bad chunks and clean them up.
I'll hopefully have the generate-ejb-code goal all cleaned up and ready for general usage in the next couple of days.
]]>It's an offshoot of the ide development work. Go Milos
]]>The 0.1 release works and was tested with Netbeans 3.5.1.
The 0.2 snapshot release works with the Netbeans 3.6 beta.
Cool.....
]]>
create your own visited states map
or write about it on the open travel guide
I hope that a 1.0 release happens sometime, but will happily remain using RC1 and the 1.0 Branch.
Good luck guys.
]]>kSpam works well, but needs TLC from an admin POV. The UI should also be enhanced. it's open source though so that may be coming soon.
SpamSentinel has a nice UI, works well, but crashes our server after a short time, and I couldn't get the reporting options installed. It does allow users to monitor their incoming spam.
MIMEShield has a slightly less pretty UI than SpamSentinel, but has excellent reporting facilities, and all allows users to control spam.
MailEssentials needed the MS SMTP server to run, which was no great drama, but the Bayesian analysis wouldn't import HAM.
So we're still running kSpam.....
]]>I've had a fleeting look @ shocks, and posted some suggestions to the mailing lists. The lead developer is very open to suggestions, and keen on improving on Struts and WebWork.
]]>It found some interesting registry entries, set up hosts file entries to block known trackers and was very usable.
]]>Finally catching up with eclipse and even eclipsing it in some areas!
Due end of March 2004
]]>See this link for details of the 4.0 release.
]]>Looks interesting.
]]>The Sourceforge site looks very interesting.
]]>"The new windowing system is going to be merged into the CVS trunk on
November 12th."
See The XP L&F version for what it will soon look like.
Cool!
The Classic windows L&F and Metal L&F versions are there too.
]]>Today I found JSF Central, which looks like a good resource.
I saw Stephen Stelting's presentation on JSF at CSS 2003, and there were some good samples he showed there
I'm still not in the convinced camp yet though. It seems there's no compatibility between JSF and Portlets, which doesn't make any sense. Also requiring a servlet to be configured seems a little ugly.
I wonder when it will go public final?
]]>I caught Dave Lander's session on portlets at CSS 2003 recently.
That prompted me to go checkout the Reference Implementation being done @ Apache, and the corresponding Eclipse Plugins.
There were also a couple of implementations closely following the spec to be released too.
Also, the rewrite of command handling for Struts, Chain looks like it is supporting portlets as well.
Standards do mean something after all!
Can't wait till it hits Oz.
]]>EtherApe was a gold mine of information, along with nessus and dsniff.
Very cool stuff.
He was a smart, funny guy who, other than being Canadian, really knew his stuff.
Neil, if you're listening, I still haven't done that schema validation for Maven yet :-)
It's amazing how many people still handcraft Ant build files for all the simple stuff that happens on every project.
Saw dbdoclet which will produce docbook from javadoc comments, as well as class diagrams. It would be nice to integrate generating class diagrams into Maven.
]]>a lightweight framework for unit testing applications in the J2EE environment. It supports Struts actions and forms, servlets, filters and tag classes.
I don't know if we can use it for our environment, as it seems like a fair bit of extra set up work, but interesting to know about anyway.
]]>While I was there I met, eat with and saw in action Gary Ashley Jr.'s session on the struts controller servlet.
He was a good speaker, and it was an interesting session.
There were lots of people at the conference using Struts, and we all shared similar pain.
Hopefully the conference proceedings will be made available online at some point.
]]>I'm hoping Wayne puts the material online after the conference for us all.
I also asked Simon if he could help us with distributing Sun's jars from ibiblio as part of Maven. Fingers crossed he can help out.
]]>The highlights so far have been updates on what's in JDK 1.5, the new metadata facility for Java (coming in 1.5), and XSLT 2.0 stuff.
]]>To use it, you can check it out of Maven Plugins CVS
]]>"unable to remap C:\cygwin\bin\cygssl-0.9.7.dll"on every request. I then found out that to fix this, I should do a
rebaseallfrom a fresh cygwin window with no other cygwin processes running. After this all went well
This one adds an uninstaller, links to common documents, checks for JAVA_HOME before installing and shows the ASL on startup.
]]>Getting that running was reasonably easy thanks to some good docs.
]]>Man, there are some real shockers out there. Finding a binary download for bind for windows is a joke.
I ended up using posadis
Good docs, easy to get going. A breeze!
]]>Yet to use it, but it certainly looks the job.
]]>We all love to bitch and moan don't we?
]]>I was really happy with how usuable it was, how it could save directly to PDF and it's overall stability.
]]>For a pretty well functioning j2ee ide, it's a bargain if you're an eclipse fan.
It has most things covered pretty well and works easily with jboss and other appservers.
It's also nice to have something supported as well.
]]>We're now only 61 issues from getting a release.
Go for it guys!
]]>It's been tedious and time consuming as there's no easy way to 'batch edit' a whole swag of issues and mark them for a given release.
This single feature would make Jira a load easier to use...
]]>I'm firmly in the RC camp, as the core of maven has had very little change for quite some time now, and barring the memory usage of the reactor, not much is majorly wrong with it for a release....
]]>Thanks to all the people who contributed to this release, there have been quite a few vocal users sending in patches and keeping us developers on our collective toes!
]]>The report that's there for Maven doesn't currently reflect what we have planned :-)
]]>Once they're finished, we're ready to roll.
]]>There really needs to be an easier way to get documentation done than the free for all word processing style.
I'd be so happy if Maven's xdoc or html2xdoc could do it easily for me. Maybe I should seriously look into the 'plain' html side of things.
What do you do for project doco?
]]>This means it's easier to generate documentation sites for many projects and aggregate them all into one.
]]>it's finally reached the release point.
Much as I use struts, I'm still not really happy with the architecture it uses and the amount of effort required to get up to speed.
]]>If there's something you want in that release, please raise it in Jira and link it to the release place holder
]]>
]]>Bob, wheres the YAWF????
]]>Does anyone else out there use it?
]]>Look under Technical Achievement.
]]>Email + blog = identity.
email: dion@codehaus.org
blog: http://blogs.codehaus.org/people/dion/
Still waiting for that new Dell laptop to arrive
]]>