It's a console app. You call it and it builds "stuff", much like Ant does. I don't really know much more than that right now, though, so no complicated questions please.:)
(Oh, and that "screenshot" is messed up, I had to add a "." to make sure it stayed indented properly, Slashdot messed it up otherwise.)
Erm... so you didn't really read the page huh? Maven is a project automation tool, not a build automation tool. You configure it to do (continuous) builds, but also to do documention, collaboration etc.
I guess I shouldn't be too surprised, I wasn't on the bandwagon either until I actually used it for a project.
Maven is a command-line tool. The screenshots are not that impressive...:)
If you know Ant (Java much improved version of make), Maven is like Ant on steroid. Maven handles intra/inter-project dependencies, project site documentation generation, unit testing, code coverage, packaging, deployment, and there's even a plugin to test whether your code conform to the coding standard.
One of the major strength of Maven is that it manages the various jar (library) dependencies in a seemless way. Multiple subprojects do not need to duplicate the jars that they depend on. You can even throw multiple subprojects into a "reactor" and it'll build them in the correct order based on their dependency graph.
It's sad that it's for Java only. I wish there's something like Maven for C/C++, or even C#, but so far I don't think I find anything yet.
Great. This is just what the world needs. Ant has something like 100 different tags with like 10 attributes to each of those. Creating large projects with Ant becomes a huge task of managing xml errors while trying to get the damn thing to build something. Now lets add some complication! People will love this. Eat it right up!
Someone really needs to build a better make. Make a better make. Whatever. If your one of those wacky open source coders who dont have a proj
I use qmake [trolltech.com] and don't ever plan to go back:
TEMPLATE=app TARGET=foobar HEADERS=foobar.h SOU RCES=foobar.cpp
That's all it takes. Run qmake on this and then make. And it is platform-independent too, meaning that it will use whatever *make you have (gmake, nmake etc.) on any supported OS (the list is long enough.)
I had a look at Maven's project description file, and I definitely won't use it any time soon even if I get a Java project to work on. It will cost me and other developers way too much time to learn
It will cost me and other developers way too much time to learn it.
From my experience, it does take a couple days to get up and running with Maven. Say ~10 man hours. This time is insignificant compared with the benefits that it bestows.
Remember, a good programer knows when not to program, and plan, improve processes instead. Also, Maven really only needs to be touches by one person, the project lead. The rest only need to know a couple commands and spend a couple hours to learn how to document stu
Plan 9 provides mk [bell-labs.com], as a replacement for make. There are unix ports [swtch.com] available. Since this isn't really a `better make' story, I'll not post more, but the papers [bell-labs.com] and manual pages [bell-labs.com] (yes, actually used in Plan 9) are often interesting reading regardless.
by Anonymous Coward writes:
on Friday July 16, 2004 @05:06PM (#9721556)
Sadly, the headline also left out the rather key information that this tool is for Java projects only.
I was quite looking forward to a revolutionary project management tool... alas, this one is yet another myopic product of the "Java is the whole universe" generation.
Java is great... but there is a larger world out there you know.
Is it really Java only? It's written in Java yes, it supports many common Java paradigms - would it not be fairly simple to use doxygen rather than javadoc, gcc rather than javac, nunit rather than junit etc etc.
Ant allows this, and I understand Maven to be an evolution of build tools, so I don't see why it should not be project-development-technology-agnostic.
It's technically possible but part of the point of the thing is that you don't have to spend forever writing build scripts to get going. So once there's a set of users writing plugins with better support for (e.g.) C# and C++, sure it'll be agnostic.
Right now it's effectively a Java tool since most of the plugins are for Java (jar, javac, javadoc, junit, etc).
Not true. It uses ant, ant can do anything (think of it as a replacement for make). People here build C, C++ and a bunch of other stuff using ant. With the correct modules you wrap all that up (with your Java components) into one nicely managed project.
Sure it's written _in_ Java, but it's not just _for_ Java (but naturally, the user community is heavily biased in that direction).
What, exactly, do maven or ant buy which make does not provide? They are written in a slow, ugly, unpleasant language, yes. They use XML instead of decent flat text, yes. They lack the great library of tools which have grown up around make, yes. Why would I want this, again? I will grant that make's use of <tab> is an abomination, but other than that it's a damned good tool which does a damned good job.
Idiot Java/XML heads constantly re-inventing the wheel.
Idiot luddites refusing to see progress when it smacks them in the face.
What, then, is the progress? As I asked in my post, 'what, exactly, do maven or ant buy which make does not provide?' As I noted, they are written in an ugly language; they use an ugly syntax (XML has all the bad points of S-expressions and few of the good); they do not work with auto*. I did note that make has a bad point.
I also looked at a few sites trying to get an answer. As far as I can see, switching to maven or ant buys m
Another downside to make: People often start with the false assumption that Makefiles are automatically cross-platform, and then find out that they aren't.
Also, make/automake/autoconf/autoheader/... can be quite complicated and confusing. Whereas ant (and presumably maven) are pretty simple by comparison.
I was hoping it was a project management system, not a programming project management tool, not a java thing. Nothing to see here for me; I'll move along now.
Sadly, the headline also left out the rather key information that this tool is for Java projects only.
Actually, no, it's not. We use it to build C code, install and configure Oracle and DB2 databases, automate some OpenSSL stuff, put together PHP sites, and rsync stuff all over the place. We also use it for managing our main Java app as well.
So I am not the only person who had bad experiences with Plone? Good to know it was not my own dumbness alone that led me to the conclusion Zope would be a good idea if the Zope people stopped having revolutionary ideas and sat down to document and clean up what they already have...:)
We just lost half a year trying to build a scalable Intranet site with Plone and Zope, for an organisation which really needs that scalability. Never again.
We even had some of Europe's best Plone/Zope experts on the project, and they came to the conclusion that it's not really possible (outside some very narrow fields where you can just use Squid or other similar caching to create scalability from where there is none) to create scalable web applications using those tools.
I would imagine there are a lot of people (like me) who had *no idea* what this is or what it is for. Here is the one paragraph definition of it FTA:
"Maven defines itself as a project-management and project-comprehension tool. Its project object model (POM) controls the development and management of a project. The POM controls builds, document creation, site publication and distribution publication and can be stored in an XML file. Maven also provides a set of tools to enable developers to automatically generate a number of critical items, such as source metrics; mailing, developer and dependency lists; software development process documentation; change logs based directly on source repository; and source cross-references."
In other words, it looks like a cross between the head cheese coding despot on any development project mailinglist and an automated webmaster thingee.... a management worker bot whatever.. it's a....
Hmm... I seem to have been modded funny for that, but actually I kind of mean it.
Having tried to use a couple of projects that depended upon it, I found that maven really was quite painful to use, and the projects seemed less "clean" than ones built by Ant with greater constraints on the library versions they can use.
Worse yet, trying to build a project that's been mavenized when you're subsisting on 28.8K thinband is a nightmare. Maven's repository may seem like a great idea, but it's a terrible one for anyone behind a restrictive proxy, or otherwise unable to take advantage of this "feature".
If you are choosing between a project based on maven and one based on Ant then I'd recommend the Ant one. Maven has no features that I consider compelling over and above Ant, but it is much more complicated, and it does introduce problems for some users' circumstances.
Imagine a superset of `ant build` that not only compiles your binaries, but also generates your documentation and install and test everything you need to run your application out-of-the-box in a single step.
> Imagine a superset of `ant build` that not only compiles your binaries, but > also generates your documentation and install and test everything you need > to run your application out-of-the-box in a single step.
You mean like 'make' with a default rules, plus a couple of shell scripts and Doxygen?
Ant + emerge/apt-get type thing + set of premade scripts that will do everything you ever needed provided you agree to organize your project directories exactly as Maven demands.
I think someone else said it best: huge pain in the ass.
I have this little rule: If I can't figure out how to get some supposed "productivity enhancer" up and running in 30 seconds, I don't bother. That means it needs to be easy to configure, have reasonable defaults, and allow doing unimportant things "later".
If you download the maven source, with a minimal set of configuration, you have something going because Maven is used to build Maven.
If you are building a new project, it takes a couple of hours on a sizeable project, if it is quite complex, it will take some time to incorporate everything. You can't build a complicated compile/tool chain without spending some time.
It is more visual compared to ant, more interactive. Ant is just a workhorse, this has some estethics. On the other hand, if you are happy with ant, maven doesn't add anything new.
If you are going to start a new project, give Maven a try. If you already have something mature based on complicated Ant scripts, moving to Maven won't add any value to your development system.
I've been using it for about a month and I still don't know what it is. All's I know is that I go to the project directory I just downloaded from CVS, I type
maven eclipse
and all the extra files and shit I need for the project to compile and work are automatically there.
Aside from that, I know that Maven reads from an xml based config file that's in the project directory.
We have started using Maven for in-house development and it really simplifies things. Being able to declare dependencies on libraries, etc, and have Maven go and grab the correct versions during build is cool enough, but all of the reporting and site building tools are really incredible. The PHBs were very impressed with the code analysis reports that it generates, and the CVS annotation of code is very nice for our internal sites. It takes a little getting used to, but if you've used Ant, you're halfway there.
I use CVS over ssh and I have the CVS url in the project config file set up that way. When I run the document/report generation it prompts me for my SSH password. I think that it handles other types of CVS authentication, but I'm not positive.
I've been using Maven for the last week or so to see what it's like. You can think of it as Ant's big brother - you use it for automating build systems and all the stuff associated with that like javadoc, reporting, changelogs and so on.
I have mixed opinions on Maven.
On the good side, the console mode is useful. Maven is pretty slow to start up as it's written in Java and the JVM takes a while to get moving - console mode works round that. The site generation plugins are also pretty cool, as you pointe
Well, it's a view of Maven users. I don't know what maven is, and I still don't after reading that. It was kind of funny for the first paragraph though.
Did that weblog actually contain any substance? It doesn't say a thing about WHY this person doesn't like Maven, it just criticizes the people that code and maintain it. It doesn't even really criticize them, as much as call them names.
Give me a concrete reason why Maven isn't worth using... This weblog doesn't do that.
For the record, I am well aware of Maven's shortcomings - the draconian 'one size fits all' approach to some aspects of the build system. While I don't agree that 'one size fits all', I
Obviously, you haven't read the bile blog before. Hani's point is to spew pedantic humor about the "asshats" of the java community. If you're looking for a serious argument on the subject, see:
http://jroller.com/page/tdak/20040715#maven_over vi ew
I agree with some other posters here that the BileBlog posts on Maven don't really offer clear reasons why Maven is bad. If you read enough of his posts on Maven you can pull out some of his general issues:
The auto-generated website has a lot of pointless information that most people don't care about.
The language it's implemented in is crap.
The project favors features over stability.
Maven highly constrains project layouts
New releases break stuff that worked in old releases
For the record, I don't think the idea of Maven is bad. The sexiest feature in my mind is declaring library dependencies by name and version number and having Maven pull down the required library from a central repository. No more cryptically named jars checked into version control. Upgrading the library is as simple as changing the version number. Inter-project dependencies are simplified since Maven publishes build artifacts to the repository for you. Other projects can just treat your project like another library dependency. Think of it like APT for Java builds.
I find myself writing the same constructs over and over in Ant. There really aren't that many ways of build a J2EE application. Maven takes care of a lot of the tedious details by letting you specify at a high-level what you want to build; it takes care of building classpaths and assembling pieces into an EAR file. You can just get on with the code.
I also don't have a significant problem with some of the constraints Maven puts on projects. It's a pain when you have something specific in mind or are trying to retrofit a project, but it is kinda nice to be able to look at any Java project and instantly grasp where to find things. Enforcing a directory layout may constrain the developer but increases transparency. The GNU projects generally follow a standard project layout with Autoconf support. I personally would not want to give up./configure;make;make install. Standardizing project layouts helps make ease of use like that possible. Whether Maven picked a good standard or not is another matter.
Where I agree with Hani's blog is:
The implementation language sucks. Using XML as the syntax of a scripting language has to be the worst idea ever. I had to go in and tweak a few Maven plugins when it was in beta and I still have nightmares.
Compatibility was broken between releases. I know that for a while Maven was in beta, but the beta cycles were so long that people assumed it was 'good enough', like JDOM. At a few points, I thought the project was dead. So it was majorly irritating when simple things broke when upgrading releases. The BileBlogger rightfully points out that betas should be about stabilizing releases, not doing a lot of feature fiddling
I've been thinking about bringing it in for an effort I am currently working on. A lot of its features would match my needs. The issues that Hani identified however, especially the implementation language, are holding me back.
There is also the fact that Ant is very well known. Many people are capable of fixing issues with Ant scripts. Extending Ant for custom tasks is also fairly trivial. I wouldn't really want to write a Maven plugin. And debugging the damn thing is tough since most of the logic is hidden.
I started using Maven about a month ago, just to see what all the fuss was about. There is a lot to it, and it can be overwhelming. But there is a good middle ground between roll-your-own-ant and Maven, and it's called Javagen Ant Modules (JAM) and it's here [javagen.com].
What I got from JAM that is useful to me:
dependency management automatically downloads library JARs for me during build.
common build.xml file and framework, so all my Maven projects have same basic structure.
Reduced learning curve so I could get going without learning everything about Maven all at once.
access to lots of cool Maven "plugins" like maven-eclipse that integrate the whole thing into my Eclipse3.0 [eclipse.org] setup.
But there is a good middle ground between roll-your-own-ant and Maven, and it's called Javagen Ant Modules (JAM)...
That's very bad news, because the open-source build tool "jam" [perforce.com] already exists and has been around for a very long time. And it's really good too.
People really ought to google a bit before picking names for their project tools. Sure, names can often be reused without conflict, but here both jam's are program build tools, and that's just plain short-sighted.
Unfortunately most people seem to hate it. Maybe thats just my bias because I tried it and found it a complete pain in the ass to work with. I dont like supposed development aides thats want to tell me how I should organise everything to suit its quirks rather than my preferences. Its really irritating when this demands vast amounts of configuration to achieve and requires a scripting language who creator has apologised for creating an abomination.
Think I (and many others) will stick with ant for the time being
Well, what do you expect? That is its purpose, managing your development. I personally abstracted ant scripts where you can define where the files in properties. Then it is a matter of policy and taste where to put the files.
Unfortunately most people seem to hate it. Maven mailing list(s) is one of the most active ones, with +50 messages a day. Most articles and comments at ServerSide, IBM DeveloperWorks and elsewhere are quite favorable toward it. Many major projects (e.g. Geronimo) are using it.
I dont like supposed development aides thats want to tell me how I should organise everything to suit its quirks rather than my preferences. Maven follows well established practices (e.g. directory structure) from the Apache Jakarta projects. Accustomed to Ant's freedom, I also was unhappy with some defaults/behaviors initially, but gradually all of them made sense.
Its really irritating when this demands vast amounts of configuration to achieve I interpret this to mean that attempting to implement your quirks in Maven took vast amount of configuration to achieve, and have no objection to that. Another massive configuration effort is required when an existing complex and rather quirky Ant build of a large application is migrated to Maven (as it was in my case, I should mention that I wrote also the Ant build;-)). But starting with Maven on a common medium-sized app is relatively easy when using the GenApp plugin [apache.org].
requires a scripting language who creator has apologised for creating an abomination I agree here. I also do not like the idea of executable XML, of using XML as a programming language. Please note, however, that Jelly is an interface for tags in Maven used to implement plugins. In principle, any mechanism for embedding tags will do (and there is significant work in this direction for v2 AFAIK).
So, apart from personal taste, Maven is quite a solid production-ready project build and comprehension tool.
Bloated project management software helped kill Netscape - they spent all their time farting around with a bugtracker when they should have been fending off Microsoft.
Apache doing non-web server things makes me worried.
Jakarta has been running for years and is without a doubt the most important open source project in the Java world (and one of the more important anywhere). And it's part of Apache.
Apache is not just a webserver and it hasn't been for a looooong time.
The ASF has been doing projects that aren't directly related to web servers for a long time. Also, poor software engineering killed Netscape. They were pouring resources into the horrible 4.x codebase and weren't getting anywhere. That's why Mozilla started from scratch.
Really, go to Jakarta [slashdot.org] and take a look around. Tomcat, Struts, Log4j... the list goes on of fantastic Java software. They are one of the major players in Java, next to IBM and Sun, and a great gadfly in the Community Process.
I've only used Maven in the way that it has been part of projects that I've downloaded. Something that gives me reservations is the way that it manages library dependencies by downloading them into the project tree. On a Unix system this feels inconsistent because I prefer to manage installed software (libraries) on a system-wide basis.
It would be nice if there were a consensus on Java library dependency resolution/installation. I used to use the exellent jpackage.org on Mandrake, but now I appreciate the source compilation aspect of Gentoo (although many of Gentoo's Java packages are old). A combination of the two would be ideal.
And whilst I'm forming a wishlist, I'd also like Java applications to have greater integration with the system, not on the desktop, but in the way that multiple invocations might have less of a memory penalty (like a Java subsystem).
Maven doesn't bring library dependencies into your project tree.
Maven's 'repository', under Linux (and with the default properties), is under ~/.maven/repository/
Admittedly each user gets a copy of all the dependencies (rather than, say, having things under/usr/local/maven/), but it's certainly not put into each project.
Managing different versions of dependencies without duplicating them into each project is, for me, the entire *point* of Maven.
You can override this state of affairs to create a system-
Maven's 'repository', under Linux (and with the default properties), is under ~/.maven/repository/
You're right - my memory had become slight hazy about this. It was the per-user package repositories that I was remembering as a potential problem.
What it needs now is source compilation... [I know that the Java bytecode won't vary much with recompilation, but it is using the "preferred source format" that I like]
And whilst I'm forming a wishlist, I'd also like Java applications to have greater integration with the system, not on the desktop, but in the way that multiple invocations might have less of a memory penalty (like a Java subsystem).
Then you might want Mac OS X [apple.com]. Library memory is shared across VMs. I think this is coming in Java 5 (1.5) for everyone, but I forget. Maybe its 1.6 (6?).
I've found Maven to be very handy. It can be really hard to write a portable build script in Ant (especially if you use several external JARs). Maven will automatically download dependencies and build your classpath. Back when I used Ant I had to write a new build script for every project. Maven is able to handle most of that kind of thing for you.
Maven is probably best thought of as a java equivalent to portage, i.e. it concerns itself with fetching, building, packaging (including metadata like authors and such), and version tracking. It just lacks a browseable set of package skeletons the way ports and portage does.
I used maven about a year ago, and I found it to be incredibly slow, bloated, underdocumented, amateurish, slipshod, and oh yes, buggy. It seems designed around some sort of "kitchen sink" approach of "xml is kewl, plugins are kewl, let's glom it all together and make something... kewl".
Honestly, whenever I see the word "plugin", I think someone hasn't really designed things well. Instead of providing a coherent app, they make a library of functions and let random piecemeal bits added after the thought take over the actual functioning. I'm not knocking component design, just the typical thought process that goes into typical "plugin" architectures. Stick with ant, you'll be much more sane for it.
by Anonymous Coward writes:
on Friday July 16, 2004 @07:55PM (#9722922)
It is a Build Tool, not a "project management tool".
What it builds are software programs.
What it was designed for and is good at is building the software called "Apache". The more a software development project looks like the Apache one, the more likly it is a useful tool for that project.
You want a management tool. This is NOT it.
You want a nonsoftware project tool. This is NOT it.
You want a build tool for a research software project, say in AI or written in LISP. This is NOT IT.
You want a build tool for far flung contributors writting code in Java (or java like language) with all the structural details about the project already known. Bingo!!! This is the tool for you.
I posted earlier anonymously. I'm bulding a superset of what Maven provides for Linux distros and projects. Been building engineering intranet sites since 95 that provide some of the features maven has along with some features maven does not have. QBAL will be GPL'd. I'm coming up to speed on Mozilla/XUL now and will have something ready this fall. Take a look at http://qbal.mozdev.org to get an idea of the scope.
Maven is not a general purpose Java build system, so i doubt it will ever overtake Ant's popularity.
The main problem is that it can only build projects with certain very rigid structures, it also has a number of features that should never be part of a build system at all, such as documentation generation and repository management. None of these extra functions it does particularly well.
For example if you want a shared jar repository - it would be quite simple to come up with something more sophisticated t
MS Project is NOT bug free; not even close. I would venture to guess that MS Project has more bugs than IE. It's non-intuitive also.
I, for one, am glad to see this project get moving. I'd love to see open-source and closed source projects get real project managers using real project management software.
You're right. I wasn't proposing that this is a replacement for MS Project. All I'm saying is that I'm glad there's some focus on project management and I'm hoping for more!
I must not have the right "Java" as it is telling me it can't lib/tools.jar so I'm going to go grab the latest jdk and see what happens.
For anyone getting the JAVA_HOME environment variable not set, a reminder is that you can set env. vars by right clicking on my computer and going to advanced and then there's an environment vars button.
There's a godawful lot of things you have to point the JDK to in order for it get everything it needs. I used to hack on a code metrics analysis tool. The build instruction for Windows was a complete mess.
Mac OS X just did things right. It did it even better than Solaris.
However, this being a development tool rightfully has some fairly high minimum knowledge requirements. If you're trying to get it to find lib/tools.jar by upgrading to the latest JDK, you're not in the intended audience for this sort of t
No offense taken. I think you're absolutely right.
I do know a bit of java but I've always been intimidated by the nasty java installers so I always fallback to php and web based applications vs java applications.
What installer? Just download the tarball version of the JDK if you don't want to bother with the rpm package, export JAVA_HOME, then add $JAVA_HOME/bin to your path and Bob's your uncle.
Same thing also works with the Windows version. Most packaged applications behave well with JAVA_HOME env. defined properly. You are ready to roll. Maven and Ant are no different.
tools.jar is in $JAVA_HOME/lib/tools.jar, if you have the JDK. On the other hand, in many cases you only jave to define JAVA_HOME correctly. If you have JRE, you don't have tools.jar.
Seems like a major assumption to have to have PRODUCT_X_PATH as the very first item in the path list. What is to be done when PRODUCT_Y and PRODUCT_Z have the same requirement?
Surely it's trivial to be able to accept the path no matter where it appears?
It's a system for building software, similar to "make". It's a way of scripting all of the steps required to deliver software in it's final state. A typical project-build for me often includes stuff like getting the latest library files that work with my code, compiling source to byte-code, byte-code enhancement (e.g for JDO object persistence), packaging into JAR files, inserting macros into config files and source code for server-names, test login and passwords, etc., then copying a myriad of files into var
"What people have been reduced to are mere 3-D representations of their own
data."
-- Arthur Miller
Link to project (Score:5, Informative)
http://maven.apache.org/ [apache.org]
Re:Link to project (Score:2)
Aha. (Score:1, Troll)
Re:Link to project (Score:2, Interesting)
So I have to install it on one of my servers just so I can see what the interface looks like? Give me a break...
Re:Link to project (Score:4, Informative)
Screenshot (Score:5, Funny)
.__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0
BUILD SUCCESSFUL
Total time: 1 seconds
Finished at: Fri Jul 16 17:34:27 EDT 2004
---
It's a console app. You call it and it builds "stuff", much like Ant does. I don't really know much more than that right now, though, so no complicated questions please.
(Oh, and that "screenshot" is messed up, I had to add a "." to make sure it stayed indented properly, Slashdot messed it up otherwise.)
Re:Screenshot (Score:3, Informative)
I guess I shouldn't be too surprised, I wasn't on the bandwagon either until I actually used it for a project.
Re:Link to project (Score:5, Informative)
Maven is a command-line tool. The screenshots are not that impressive...:)
If you know Ant (Java much improved version of make), Maven is like Ant on steroid. Maven handles intra/inter-project dependencies, project site documentation generation, unit testing, code coverage, packaging, deployment, and there's even a plugin to test whether your code conform to the coding standard.
One of the major strength of Maven is that it manages the various jar (library) dependencies in a seemless way. Multiple subprojects do not need to duplicate the jars that they depend on. You can even throw multiple subprojects into a "reactor" and it'll build them in the correct order based on their dependency graph.
It's sad that it's for Java only. I wish there's something like Maven for C/C++, or even C#, but so far I don't think I find anything yet.
Re:Link to project (Score:3, Interesting)
Maven is like Ant on steroid.
Great. This is just what the world needs. Ant has something like 100 different tags with like 10 attributes to each of those. Creating large projects with Ant becomes a huge task of managing xml errors while trying to get the damn thing to build something. Now lets add some complication! People will love this. Eat it right up!
Someone really needs to build a better make. Make a better make. Whatever. If your one of those wacky open source coders who dont have a proj
Re:Link to project (Score:2)
That's all it takes. Run qmake on this and then make. And it is platform-independent too, meaning that it will use whatever *make you have (gmake, nmake etc.) on any supported OS (the list is long enough.)
I had a look at Maven's project description file, and I definitely won't use it any time soon even if I get a Java project to work on. It will cost me and other developers way too much time to learn
Re:Link to project (Score:2)
From my experience, it does take a couple days to get up and running with Maven. Say ~10 man hours. This time is insignificant compared with the benefits that it bestows.
Remember, a good programer knows when not to program, and plan, improve processes instead. Also, Maven really only needs to be touches by one person, the project lead. The rest only need to know a couple commands and spend a couple hours to learn how to document stu
Re:Link to project (Score:2)
Not the only thing left out: it's for Java only (Score:5, Informative)
I was quite looking forward to a revolutionary project management tool
Java is great
Re:Not the only thing left out: it's for Java only (Score:5, Insightful)
Is it really Java only? It's written in Java yes, it supports many common Java paradigms - would it not be fairly simple to use doxygen rather than javadoc, gcc rather than javac, nunit rather than junit etc etc.
Ant allows this, and I understand Maven to be an evolution of build tools, so I don't see why it should not be project-development-technology-agnostic.
Re:Not the only thing left out: it's for Java only (Score:5, Informative)
Right now it's effectively a Java tool since most of the plugins are for Java (jar, javac, javadoc, junit, etc).
Re:Not the only thing left out: it's for Java only (Score:5, Informative)
Sure it's written _in_ Java, but it's not just _for_ Java (but naturally, the user community is heavily biased in that direction).
Re:Not the only thing left out: it's for Java only (Score:2)
Idiot Java/XML heads constantly re-inventing the wheel.
Re:Not the only thing left out: it's for Java only (Score:2)
Idiot luddites refusing to see progress when it smacks them in the face.
Re:Not the only thing left out: it's for Java only (Score:2)
What, then, is the progress? As I asked in my post, 'what, exactly, do maven or ant buy which make does not provide?' As I noted, they are written in an ugly language; they use an ugly syntax (XML has all the bad points of S-expressions and few of the good); they do not work with auto*. I did note that make has a bad point.
I also looked at a few sites trying to get an answer. As far as I can see, switching to maven or ant buys m
Re:Not the only thing left out: it's for Java only (Score:3, Insightful)
Also, make/automake/autoconf/autoheader/... can be quite complicated and confusing. Whereas ant (and presumably maven) are pretty simple by comparison.
Oh, you for mean for programming projects only (Score:3, Insightful)
Re:Oh, you for mean for programming projects only (Score:5, Funny)
You want this then... (Score:4, Interesting)
It's similar enough to Microsoft Project. Gantt Charts [wikipedia.org] have been a project management standard for almost 100 years.
Linux, Mac OS X, Windows. It's Java, so take yer pick. GPL'd too.
Uhh, not quite. (Score:2)
And if you think that all you need to effectively manage a project is some Gantt charts, then I have an EULA I'd like you to sign.
I think what the parent poster was hoping for (as was I) was a Project Management system. Gantt charts alone don't cut it.
Re:Not the only thing left out: it's for Java only (Score:5, Informative)
Actually, no, it's not. We use it to build C code, install and configure Oracle and DB2 databases, automate some OpenSSL stuff, put together PHP sites, and rsync stuff all over the place. We also use it for managing our main Java app as well.
Just the tool is Java-based.
Re:Link to project (Score:5, Informative)
It's a Java programming project management tool.
There is a huge difference between the two things.
Re:Link to project (Score:2)
Plone-esque proportions (Score:2, Informative)
Re:Plone-esque proportions (Score:1, Informative)
We even had some of Europe's best Plone/Zope experts on the project, and they came to the conclusion that it's not really possible (outside some very narrow fields where you can just use Squid or other similar caching to create scalability from where there is none) to create scalable web applications using those tools.
One of the largest problems was th
definition (Score:5, Interesting)
"Maven defines itself as a project-management and project-comprehension tool. Its project object model (POM) controls the development and management of a project. The POM controls builds, document creation, site publication and distribution publication and can be stored in an XML file. Maven also provides a set of tools to enable developers to automatically generate a number of critical items, such as source metrics; mailing, developer and dependency lists; software development process documentation; change logs based directly on source repository; and source cross-references."
In other words, it looks like a cross between the head cheese coding despot on any development project mailinglist and an automated webmaster thingee.... a management worker bot whatever.. it's a....
I still don't know what it is
Re:definition (Score:5, Funny)
It's a great big pain in the butt.
Re:definition (Score:5, Informative)
Having tried to use a couple of projects that depended upon it, I found that maven really was quite painful to use, and the projects seemed less "clean" than ones built by Ant with greater constraints on the library versions they can use.
Worse yet, trying to build a project that's been mavenized when you're subsisting on 28.8K thinband is a nightmare. Maven's repository may seem like a great idea, but it's a terrible one for anyone behind a restrictive proxy, or otherwise unable to take advantage of this "feature".
If you are choosing between a project based on maven and one based on Ant then I'd recommend the Ant one. Maven has no features that I consider compelling over and above Ant, but it is much more complicated, and it does introduce problems for some users' circumstances.
Re:definition (Score:5, Informative)
Imagine a superset of `ant build` that not only compiles your binaries, but also generates your documentation and install and test everything you need to run your application out-of-the-box in a single step.
Re:definition (Score:3, Insightful)
> also generates your documentation and install and test everything you need
> to run your application out-of-the-box in a single step.
You mean like 'make' with a default rules, plus a couple of shell scripts and Doxygen?
*yawn*
I've been doing that for a while, now.
Re:definition (Score:3, Interesting)
Everytime I encounter one of these huge java 'management' thingys it takes more time to configure the bloody thing than is ever saved.
Also, what does it do that Ant doesn't? I mean, one can have ant generate javadoc, or run unit tests too...
Re:definition (Score:2)
I think someone else said it best: huge pain in the ass.
Re:definition (Score:1, Interesting)
I have this little rule: If I can't figure out how to get some supposed "productivity enhancer" up and running in 30 seconds, I don't bother. That means it needs to be easy to configure, have reasonable defaults, and allow doing unimportant things "later".
Maven definitely did not pass.
Re:definition (Score:5, Informative)
If you are building a new project, it takes a couple of hours on a sizeable project, if it is quite complex, it will take some time to incorporate everything. You can't build a complicated compile/tool chain without spending some time.
It is more visual compared to ant, more interactive. Ant is just a workhorse, this has some estethics. On the other hand, if you are happy with ant, maven doesn't add anything new.
If you are going to start a new project, give Maven a try. If you already have something mature based on complicated Ant scripts, moving to Maven won't add any value to your development system.
Hell, (Score:2, Interesting)
Aside from that, I know that Maven reads from an xml based config file that's in the project directory.
Right .... (Score:1, Funny)
maven eclipse
and all the extra files and shit I need for the project to compile and work are automatically there.
So far then, we've established that it's entirely opaque. OK, I feel we're getting there.
Red Dwarf Does Maven (Score:3, Funny)
Cryten: "a project-management and project-comprehension software tool that uses a Project Object Model with XML storage"
(blank, smiling stare)
Cat: "What is it?"
Cryten: "a project management tool that increases developer productivity when working on Java projects."
(blank, smiling stare)
Cat:"What is it?"
Holly: "a computer thingy"
Cat: "Aaaaaah. Now why didn't you say that in the first place?"
(everything I needed to know, I learned watching Red Dwarf!)
Re:Red Dwarf Does Maven (Score:1)
Incredibly useful build tool (Score:5, Informative)
Derek
Re:Incredibly useful build tool (Score:2)
Re:Incredibly useful build tool (Score:2)
Derek
Re:Incredibly useful build tool (Score:2)
And does it work with repositories other than CVS (I'm running Subversion myself but keep finding it isn't supported things, e.g. jEdit)
Re:Incredibly useful build tool (Score:3, Informative)
Derek
Re:Incredibly useful build tool (Score:2, Informative)
Re:Incredibly useful build tool (Score:2, Informative)
I have mixed opinions on Maven.
On the good side, the console mode is useful. Maven is pretty slow to start up as it's written in Java and the JVM takes a while to get moving - console mode works round that. The site generation plugins are also pretty cool, as you pointe
Re:Incredibly useful build tool (Score:1)
Re: The PHBs were very impressed (Score:5, Funny)
I didn't follow whether this was intended as praise or criticism.
Maven Bile (Score:5, Informative)
Re:Maven Bile (Score:5, Interesting)
-Malloc
Re:Maven Bile (Score:2)
Re:Maven Bile (Score:3, Interesting)
Give me a concrete reason why Maven isn't worth using... This weblog doesn't do that.
For the record, I am well aware of Maven's shortcomings - the draconian 'one size fits all' approach to some aspects of the build system. While I don't agree that 'one size fits all', I
Re:Maven Bile (Score:1, Informative)
http://jroller.com/page/tdak/20040715#maven_ove
Re:Maven Bile (Score:5, Informative)
For the record, I don't think the idea of Maven is bad. The sexiest feature in my mind is declaring library dependencies by name and version number and having Maven pull down the required library from a central repository. No more cryptically named jars checked into version control. Upgrading the library is as simple as changing the version number. Inter-project dependencies are simplified since Maven publishes build artifacts to the repository for you. Other projects can just treat your project like another library dependency. Think of it like APT for Java builds.
I find myself writing the same constructs over and over in Ant. There really aren't that many ways of build a J2EE application. Maven takes care of a lot of the tedious details by letting you specify at a high-level what you want to build; it takes care of building classpaths and assembling pieces into an EAR file. You can just get on with the code.
I also don't have a significant problem with some of the constraints Maven puts on projects. It's a pain when you have something specific in mind or are trying to retrofit a project, but it is kinda nice to be able to look at any Java project and instantly grasp where to find things. Enforcing a directory layout may constrain the developer but increases transparency. The GNU projects generally follow a standard project layout with Autoconf support. I personally would not want to give up
Where I agree with Hani's blog is:
I've been thinking about bringing it in for an effort I am currently working on. A lot of its features would match my needs. The issues that Hani identified however, especially the implementation language, are holding me back.
There is also the fact that Ant is very well known. Many people are capable of fixing issues with Ant scripts. Extending Ant for custom tasks is also fairly trivial. I wouldn't really want to write a Maven plugin. And debugging the damn thing is tough since most of the logic is hidden.
try the ACTUAL bile (Score:3, Informative)
The bile you linked is just a reminder so no one forgets that it indeed still sucks.
Java (Score:3, Informative)
Indian stomach - wtf? (Score:1)
In danish 'maven' is the word for stomach.
Well, can't win them all
Also a perfectly good english word... (Score:2)
Re:Also a perfectly good english word... (Score:2)
Zyl...Zuul...Coincidence (Score:2, Funny)
Check out JAM for Maven (Score:5, Informative)
What I got from JAM that is useful to me:
Ouch, not "JAM" ! Non Java-centric "jam" exists (Score:3, Informative)
That's very bad news, because the open-source build tool "jam" [perforce.com] already exists and has been around for a very long time. And it's really good too.
People really ought to google a bit before picking names for their project tools. Sure, names can often be reused without conflict, but here both jam's are program build tools, and that's just plain short-sighted.
Its a love it or hate it project (Score:3, Insightful)
Think I (and many others) will stick with ant for the time being
Re:Its a love it or hate it project (Score:2)
Re:Its a love it or hate it project (Score:5, Informative)
Maven mailing list(s) is one of the most active ones, with +50 messages a day. Most articles and comments at ServerSide, IBM DeveloperWorks and elsewhere are quite favorable toward it. Many major projects (e.g. Geronimo) are using it.
I dont like supposed development aides thats want to tell me how I should organise everything to suit its quirks rather than my preferences.
Maven follows well established practices (e.g. directory structure) from the Apache Jakarta projects. Accustomed to Ant's freedom, I also was unhappy with some defaults/behaviors initially, but gradually all of them made sense.
Its really irritating when this demands vast amounts of configuration to achieve
I interpret this to mean that attempting to implement your quirks in Maven took vast amount of configuration to achieve, and have no objection to that.
Another massive configuration effort is required when an existing complex and rather quirky Ant build of a large application is migrated to Maven (as it was in my case, I should mention that I wrote also the Ant build
But starting with Maven on a common medium-sized app is relatively easy when using the GenApp plugin [apache.org].
requires a scripting language who creator has apologised for creating an abomination
I agree here. I also do not like the idea of executable XML, of using XML as a programming language. Please note, however, that Jelly is an interface for tags in Maven used to implement plugins. In principle, any mechanism for embedding tags will do (and there is significant work in this direction for v2 AFAIK).
So, apart from personal taste, Maven is quite a solid production-ready project build and comprehension tool.
--
Svetlin
Bloated project mgt software killed Netscape (Score:1)
Apache doing non-web server things makes me worried.
Re:Bloated project mgt software killed Netscape (Score:4, Interesting)
Jakarta has been running for years and is without a doubt the most important open source project in the Java world (and one of the more important anywhere). And it's part of Apache.
Apache is not just a webserver and it hasn't been for a looooong time.
Re:Bloated project mgt software killed Netscape (Score:2, Insightful)
Re:Bloated project mgt software killed Netscape (Score:2)
Maven Great??? (Score:2)
Re:Maven Great??? (Score:3, Insightful)
A different opinion (Score:5, Interesting)
I havent used Maven myself, but since this was mostly a very positive announcement, I guess it cant hurt to point to another point of view.
Java as a system facility (Score:4, Interesting)
Something that gives me reservations is the way that it manages library dependencies by downloading them into the project tree. On a Unix system this feels inconsistent because I prefer to manage installed software (libraries) on a system-wide basis.
It would be nice if there were a consensus on Java library dependency resolution/installation. I used to use the exellent jpackage.org on Mandrake, but now I appreciate the source compilation aspect of Gentoo (although many of Gentoo's Java packages are old). A combination of the two would be ideal.
And whilst I'm forming a wishlist, I'd also like Java applications to have greater integration with the system, not on the desktop, but in the way that multiple invocations might have less of a memory penalty (like a Java subsystem).
- Brian.
Re:Java as a system facility (Score:1)
Maven's 'repository', under Linux (and with the default properties), is under ~/.maven/repository/
Admittedly each user gets a copy of all the dependencies (rather than, say, having things under
Managing different versions of dependencies without duplicating them into each project is, for me, the entire *point* of Maven.
You can override this state of affairs to create a system-
Re:Java as a system facility (Score:2)
You're right - my memory had become slight hazy about this. It was the per-user package repositories that I was remembering as a potential problem.
What it needs now is source compilation
[I know that the Java bytecode won't vary much with recompilation, but it is using the "preferred source format" that I like]
- Brian
Re:Java as a system facility (Score:2)
And whilst I'm forming a wishlist, I'd also like Java applications to have greater integration with the system, not on the desktop, but in the way that multiple invocations might have less of a memory penalty (like a Java subsystem).
Then you might want Mac OS X [apple.com]. Library memory is shared across VMs. I think this is coming in Java 5 (1.5) for everyone, but I forget. Maybe its 1.6 (6?).
It a time saver (Score:1, Informative)
Back when I used Ant I had to write a new build script for every project. Maven is able to handle most of that kind of thing for you.
My impressions of maven (Score:4, Informative)
I used maven about a year ago, and I found it to be incredibly slow, bloated, underdocumented, amateurish, slipshod, and oh yes, buggy. It seems designed around some sort of "kitchen sink" approach of "xml is kewl, plugins are kewl, let's glom it all together and make something
Honestly, whenever I see the word "plugin", I think someone hasn't really designed things well. Instead of providing a coherent app, they make a library of functions and let random piecemeal bits added after the thought take over the actual functioning. I'm not knocking component design, just the typical thought process that goes into typical "plugin" architectures. Stick with ant, you'll be much more sane for it.
It is a build tool . (Score:5, Insightful)
What it builds are software programs.
What it was designed for and is good at is building the software called "Apache". The more a software development project looks like the Apache one, the more likly it is a useful tool for that project.
You want a management tool. This is NOT it.
You want a nonsoftware project tool. This is NOT it.
You want a build tool for a research software project, say in AI or written in LISP. This is NOT IT.
You want a build tool for far flung contributors writting code in Java (or java like language) with all the structural details about the project already known. Bingo!!! This is the tool for you.
Uhm.... what? (Score:1)
Maven is a very robust project-management and project comprehension tool
Uhm... what?
... a long history of pushing out beta after beta (Score:2, Funny)
see qbal.mozdev.org (Score:2, Informative)
Bigusputicus
Maven is badly designed (Score:1, Interesting)
The main problem is that it can only build projects with certain very rigid structures, it also has a number of features that should never be part of a build system at all, such as documentation generation and repository management. None of these extra functions it does particularly well.
For example if you want a shared jar repository - it would be quite simple to come up with something more sophisticated t
Re:Sheesh (Score:2, Informative)
I, for one, am glad to see this project get moving. I'd love to see open-source and closed source projects get real project managers using real project management software.
Everyone will be more organized that way!
Re:Sheesh (Score:1, Troll)
Your sense of humour is inexistant.
Now there might be several reasons:
1. You never had one. This situation is not desperate, but will require some work.
2. You lost it. Go get it!
Cheers
Re:Sheesh (Score:1)
Visualize them! (Score:4, Informative)
I must not have the right "Java" as it is telling me it can't lib/tools.jar so I'm going to go grab the latest jdk and see what happens.
For anyone getting the JAVA_HOME environment variable not set, a reminder is that you can set env. vars by right clicking on my computer and going to advanced and then there's an environment vars button.
Re:Visualize them! (Score:3, Informative)
Mac OS X just did things right. It did it even better than Solaris.
However, this being a development tool rightfully has some fairly high minimum knowledge requirements. If you're trying to get it to find lib/tools.jar by upgrading to the latest JDK, you're not in the intended audience for this sort of t
Re:Visualize them! (Score:2)
I do know a bit of java but I've always been intimidated by the nasty java installers so I always fallback to php and web based applications vs java applications.
So to educate me... Where is tools.jar?
Re:Visualize them! (Score:2)
Same thing also works with the Windows version. Most packaged applications behave well with JAVA_HOME env. defined properly. You are ready to roll. Maven and Ant are no different.
Re:Visualize them! (Score:2)
Re:Visualize them! (Score:2, Informative)
Click on PATH and edit it so the JAVA_HOME is at the FRONT
of the path as so:
%JAVA_HOME%\bin;<... rest of path
and you have JAVA_HOME set as:
JAVA_HOME=<path to jsdk or jre home>
This will save you boatloads of problems.
------------
It's a good thing Swing sucks and is too hard to use or else
I wouldn't be able to do my dev on a mac and deploy my apps
to windows. Silly me.
Re:Visualize them! (Score:1)
Re:Visualize them! (Score:1)
about maven).
By putting the JAVA_HOME/bin at the front of your path you
are ensuring that the version of java being used is the one you want.
Oracle, Sybase and others tend to drop all sorts of JVM versions into your path. Effing everything up.
There are other various ways of making sure your app uses the right jvm, but this is the easiest that I know about.
For the situation you describe you can include a JRE with your installer (install anywhe
Re:OT: FOSS competitor to Microsoft Project? (Score:3, Informative)
http://www.dotproject.net
Not yet the equal of M$ Project, but given time...
Wow. (Score:2)
Re:I don't know (Score:1)
It's a way of scripting all of the steps required to deliver software in it's final state.
A typical project-build for me often includes stuff like getting the latest library files that work with my code, compiling source to byte-code, byte-code enhancement (e.g for JDO object persistence), packaging into JAR files, inserting macros into config files and source code for server-names, test login and passwords, etc., then copying a myriad of files into var