Maven gets a lot of flack. Hani enjoy’s making fun of it. I even joked about it a little via:
All I wanted was a jar and I got a website
However, the more I get to play with it, the more I like it. And, it sure beats the alternatives :)
One side effect that I have noticed is that it allows me to have clearly defined extension points in my build. And, even more importantly, it allows me to NOT think about every extension point when designing my projects build.
When using Ant, I always found myself spending time really thinking about the dependencies.
Hmm, shall I have this general build target depend on a customer dion-build which I can later override and do cool stuff in sub-projects?
I found that I ended up with a bunch of:
<target …. if=”some.magic.property”>
In my Maven projects, I don’t seem to need any of this. Why don’t I?
I think it stems from:
- The Plugins: I try really hard to rely on plugins to do the work for me. First, I try to follow their defaults. Second, I tweak their properties to give me some flexibility if needed. Only as a TRUE last resort do I look to hack the maven.xml. I find that it is rare to get to the last resort.
- pre/postGoal: A lot of the good plugins have nice extension points. You can almost setup base goals which are NO-OPs, which you can later extend by implementing your own. However, even if this doesn’t exist, via pre/postGoal settings, you can extend anything!
Being able to extend anything with a pre/postGoal has proven to be very productive. What I really like about it, is that you don’t have any coupling between the original goal, and the extension mechanism.
For example, if you want to extend the java:compile goal to do something else, you can preGoal it to have the extension, say generating some other source code before the compile step. Note that we are not having to tweak the original goal at all. There is no coupling here. Maybe this is a personal preference, but that feels much cleaner than piecing together the puzzle via depends=”".
February 10th, 2005 at 1:09 pm
Well, interesting. Whatever, “the more I get to play with it, the more I like it” is the last sentence I wish to hear when working on a project. I mean, the less I play with make files, ant files, etc, the more I like it. Playing with make/ant/maven means other guys on the project are beginning to suffer. And this is very true with Maven, as it’s very harsh to find what’s going wrong if you f*ck up somewhere. I must admit that I’m not a Maven specialist, nor an ant one, but at least, I can afford fixing a ant file without googling crazy in expectation to find a little piece of -not – outdated documentation. I’ve spent 3 days trying to fix a Maven driven build process. No way. It tooks me 2 hours, and finally I had to parse the CVS files to discover taht -X is the Debug mode of Maven. And trust me, it did NOT help you a lot… What I just want is something that I can just launch, that builds the project, and that is understandable by any non-geek/guru/maven guy (make your choice), I’ve called the Average Programmer ! I’m not convinced by Maven as a tool that drives you in this peaceful path, where projects are’nt killed by the build process, but by other Massive Destructive Weapons (Rationnal For The Masses? ;-). Well, I’m not Hani, but from time to time, it helps to express this kind of frustration : http://www.almaer.com/blog/archives/000507.html ;)
February 10th, 2005 at 1:09 pm
Well, interesting. Whatever, “the more I get to play with it, the more I like it” is the last sentence I wish to hear when working on a project. I mean, the less I play with make files, ant files, etc, the more I like it. Playing with make/ant/maven means other guys on the project are beginning to suffer. And this is very true with Maven, as it’s very harsh to find what’s going wrong if you f*ck up somewhere. I must admit that I’m not a Maven specialist, nor an ant one, but at least, I can afford fixing a ant file without googling crazy in expectation to find a little piece of -not – outdated documentation. I’ve spent 3 days trying to fix a Maven driven build process. No way. It tooks me 2 hours, and finally I had to parse the CVS files to discover taht -X is the Debug mode of Maven. And trust me, it did NOT help you a lot… What I just want is something that I can just launch, that builds the project, and that is understandable by any non-geek/guru/maven guy (make your choice), I’ve called the Average Programmer ! I’m not convinced by Maven as a tool that drives you in this peaceful path, where projects are’nt killed by the build process, but by other Massive Destructive Weapons (Rationnal For The Masses? ;-). Well, I’m not Hani, but from time to time, it helps to express this kind of frustration : http://www.almaer.com/blog/archives/000507.html ;)
February 10th, 2005 at 2:15 pm
Maven is OK until something goes wrong, then the whole world comes crashing down upon you. Look at the experiences of several open source projects using Maven – tiny problems snowball into cases where nobody can do anything, and it’s very difficult to find out what went wrong.
The main problem is what Emmanuel says – you have to be a freakin’ guru to find Maven problems and fix them. I find ANT 1.6’s new module features are just fine for my work – I have a couple of build template files and per-project files are typically 20 lines long or so. And mere mortals can use it and figure out how to fix problems.
ANT may be underpowered, but its solid and underpowered. This is preferable to having an unstable nuclear powered rocketship which requires weird tools to open up and tinker with.
Seriously Dion – look on the Geronimo lists and Groovy IRC logs for examples of what happens when Maven Goes Wild.
February 10th, 2005 at 2:15 pm
Maven is OK until something goes wrong, then the whole world comes crashing down upon you. Look at the experiences of several open source projects using Maven – tiny problems snowball into cases where nobody can do anything, and it’s very difficult to find out what went wrong.
The main problem is what Emmanuel says – you have to be a freakin’ guru to find Maven problems and fix them. I find ANT 1.6’s new module features are just fine for my work – I have a couple of build template files and per-project files are typically 20 lines long or so. And mere mortals can use it and figure out how to fix problems.
ANT may be underpowered, but its solid and underpowered. This is preferable to having an unstable nuclear powered rocketship which requires weird tools to open up and tinker with.
Seriously Dion – look on the Geronimo lists and Groovy IRC logs for examples of what happens when Maven Goes Wild.
February 10th, 2005 at 2:22 pm
I understand that things can go wrong. However, my experience has been the opposite.
As long as I don’t try to do anything ‘too crazy’, and KISS, I find maven to be a huge time saver for me.
It also forces me to NOT go hacking away in a build file doing ‘different’ things, which have context, and mean that other people on the team don’t grok.
Each to their own and everything, but my experience on recent projects, has been great.
Dion
February 10th, 2005 at 2:22 pm
I understand that things can go wrong. However, my experience has been the opposite.
As long as I don’t try to do anything ‘too crazy’, and KISS, I find maven to be a huge time saver for me.
It also forces me to NOT go hacking away in a build file doing ‘different’ things, which have context, and mean that other people on the team don’t grok.
Each to their own and everything, but my experience on recent projects, has been great.
Dion
February 10th, 2005 at 2:55 pm
There are numerous examples where Maven projects are just getting in the way and developpers are too stubborn to simply throw it away. It does not bring anything but adding complexity where there should not.
I haven’t checked out a single Mavenized opensource project that just worked out of the box. There is always something wrong.
My experience with commercial projects is not better. I have had feedback from projects where some famous maven evangelist went to layout the build foundation with Maven but it simply went berserk later on (once there was code in) as no one was able to figure out what the hell was failing. ‘magic build’ you know.
The dependency feature is also a smoke screen, especially in multiproject configuration where it becomes so opaque you have no idea what you’re building against.
With Maven, maybe the developpers have the feeling they are producing something when it just generate all the reports of different plugins but more often than not it is just an excuse for poor documentation. If there is anything at all useful in the docs, it is outdated and/or incorrect, so what’s the point in producing 5MB of useless docs that will confuse the user ?
Incorrect doc is worse than no doc at all.
February 10th, 2005 at 2:55 pm
There are numerous examples where Maven projects are just getting in the way and developpers are too stubborn to simply throw it away. It does not bring anything but adding complexity where there should not.
I haven’t checked out a single Mavenized opensource project that just worked out of the box. There is always something wrong.
My experience with commercial projects is not better. I have had feedback from projects where some famous maven evangelist went to layout the build foundation with Maven but it simply went berserk later on (once there was code in) as no one was able to figure out what the hell was failing. ‘magic build’ you know.
The dependency feature is also a smoke screen, especially in multiproject configuration where it becomes so opaque you have no idea what you’re building against.
With Maven, maybe the developpers have the feeling they are producing something when it just generate all the reports of different plugins but more often than not it is just an excuse for poor documentation. If there is anything at all useful in the docs, it is outdated and/or incorrect, so what’s the point in producing 5MB of useless docs that will confuse the user ?
Incorrect doc is worse than no doc at all.
February 10th, 2005 at 3:08 pm
I hear a lot of people with these claims, so it must be happening. I have see bad projects where maven was abused. Maven also isn’t the perfect system and you should always conclude that it should be used as the build system.
However, I still contend that on various projects, Maven *IS* the best choice.
And, I have seen MANY more knightmare builds with spagetti ant build.xml files.
February 10th, 2005 at 3:08 pm
I hear a lot of people with these claims, so it must be happening. I have see bad projects where maven was abused. Maven also isn’t the perfect system and you should always conclude that it should be used as the build system.
However, I still contend that on various projects, Maven *IS* the best choice.
And, I have seen MANY more knightmare builds with spagetti ant build.xml files.
February 10th, 2005 at 3:44 pm
Dion, I think the difference here is that when a Maven build breaks, hours or days are lost. Literally. And the majority of time, only a single person on a team has any idea how to fix it. Again, literally.
With Ant you can certainly get spaghetti files, but when something breaks it’s generally fixed in a few minutes.
In this way using Maven is like playing Russian Roulette. If the gun isn’t blowing up on you it may not be good management, you just may have been lucky so far. But some day you will hit the full chamber, and you too will lose hours/days fixing _simple_ problems – and meanwhile no one can build.
I don’t want a build system that works most of the time but creates an instant critical crisis every once in a while. Who would?
February 10th, 2005 at 3:44 pm
Dion, I think the difference here is that when a Maven build breaks, hours or days are lost. Literally. And the majority of time, only a single person on a team has any idea how to fix it. Again, literally.
With Ant you can certainly get spaghetti files, but when something breaks it’s generally fixed in a few minutes.
In this way using Maven is like playing Russian Roulette. If the gun isn’t blowing up on you it may not be good management, you just may have been lucky so far. But some day you will hit the full chamber, and you too will lose hours/days fixing _simple_ problems – and meanwhile no one can build.
I don’t want a build system that works most of the time but creates an instant critical crisis every once in a while. Who would?
February 10th, 2005 at 5:22 pm
I hear what you are saying Mike. However, again, I haven’t seen the problems that you are talking about on any of my projects.
I haven’t had something go wrong in the build tha takes days to fix. I find that I can keep the build much more simple so I don’t run into these side effects.
I *do* see these problems with ant builds. This often happens because developer A tweaks a target and puts in a different exclude… copies a file from X to Y… then developer B comes in and names something which happens to match the exclusion and wonders what is going on. Does it take a day to fix? You hope not, but it may happen 10 times more :)
As always, each to their own, and the nice thing is that we can choose ;)
Dion
February 10th, 2005 at 7:09 pm
Oh, god, that was really good to express my frustration.
Let’s go a little bit further, right now. The real thing is “do not try to fix something that works”. So as soon as you have a Maven build that works (yes, it happens :-), and if you are the one who is the Maven Master of the universe, Kool. On Linux/Unix, chown those Maven an Project files. They will be 544lized, and may be 540 (chown -R 540 `find . -name “project.xml”` or something like this – sorry, I’m not bash, nor bush – ). Change your password to xZE_-m~@&Uo77. Be sure that nobody will never ever touch them but your assistant (under you control). SVN every change (cvs won’t be powerfull enough, it won’t track directory deletions). Add a documentation, and a root project.xml to launch your build (even if you have many subprojects). Test it against Eclipse/Idea/Emacs/Whatever your mates/team is using. It will be a -almost- full time job! And train your team. (the very same for ant). It’s like the Freddy mercury song : “It’s a kind of fascism …”. Maven is not Magic. It’s a tool. It works. It’s powerfull. But claiming that it’s magic leads to a misconception : maven != easy. It’s not. Do not pretend it is. It deserves respect and fear.
My last word (Mafia blues?) : “Don’t f*ck with mother nature, mother in law, and mother f*cker Maven !”
Emmanuel
February 11th, 2005 at 1:15 am
Ant and Maven
I was going to post a comment on Dion’s blog about his entry on Maven when I realized that Mike posted it for me… In short, ant’s <import> and <macrodef>…
February 11th, 2005 at 1:15 am
Ant and Maven
I was going to post a comment on Dion’s blog about his entry on Maven when I realized that Mike posted it for me… In short, ant’s <import> and <macrodef>…
February 11th, 2005 at 1:18 am
Dion, I posted a few comments on my blog.
February 11th, 2005 at 1:18 am
Dion, I posted a few comments on my blog.
February 11th, 2005 at 5:57 am
Leave the version numbers on your lib jars please
Dion is getting the community all fired up with his blog on Maven. While he has gotten many folks arguing about the build systems of the world no one pointed out what I feel is one of the great benefits…
February 11th, 2005 at 7:52 am
It’s kind of funny that people bash Maven in these comments.
While Ant is a fine build system, it lacks in reusability. Even the new features don’t come close to Maven in capturing and reusing build functionality.
The difference between the two systems is very much like the difference between procedural and object orienter programing.
Maven allow you to design a build system. It’s plugin architecture allow you to easily create a reusable build system. One that do not requires every developer in your organization to know the implementation details of your build system.
If you have a structure for some kind of application, you can easily create a maven pluging that will allow anyone in your organization to create the development structure for that kind of application.
Granted, you can hack something similar with Ant, but then you have to bother with dependencies. You have to explicitely describe which build functionality you want to reuse, you need to copy bunch of “modules” from place to place, you need tu manually manage version of these modules or dependencies.
Maven solve all of these problems, you have a multiple repositories that can maintains these dependencies and plug-in. You can easily evolve a plugin without affecting projects that use an old version of the same pluging, all these thing are taken care of by the framework.
True, when something goes bad, it may be more difficult to debug… But you know, we got the same arguments by procudural zealots about object oriented programing.
Maven is not perfect, dependencies can become a bit of a nightmare as you cannot easily manage dependency groups, but at least it offer you a way to design a build system… While Ant only allow you to hack one.
I like both Maven and Ant… But if I want a build system that will be there for a while, I choose Maven.
February 11th, 2005 at 7:52 am
It’s kind of funny that people bash Maven in these comments.
While Ant is a fine build system, it lacks in reusability. Even the new features don’t come close to Maven in capturing and reusing build functionality.
The difference between the two systems is very much like the difference between procedural and object orienter programing.
Maven allow you to design a build system. It’s plugin architecture allow you to easily create a reusable build system. One that do not requires every developer in your organization to know the implementation details of your build system.
If you have a structure for some kind of application, you can easily create a maven pluging that will allow anyone in your organization to create the development structure for that kind of application.
Granted, you can hack something similar with Ant, but then you have to bother with dependencies. You have to explicitely describe which build functionality you want to reuse, you need to copy bunch of “modules” from place to place, you need tu manually manage version of these modules or dependencies.
Maven solve all of these problems, you have a multiple repositories that can maintains these dependencies and plug-in. You can easily evolve a plugin without affecting projects that use an old version of the same pluging, all these thing are taken care of by the framework.
True, when something goes bad, it may be more difficult to debug… But you know, we got the same arguments by procudural zealots about object oriented programing.
Maven is not perfect, dependencies can become a bit of a nightmare as you cannot easily manage dependency groups, but at least it offer you a way to design a build system… While Ant only allow you to hack one.
I like both Maven and Ant… But if I want a build system that will be there for a while, I choose Maven.
February 11th, 2005 at 3:56 pm
Mr Pirsch,
It would be too long to actually discuss all the irrelevant bits of your post that actually show more experience of small short term projects than long one…but I would suggest you get some good books about configuration management.
And I would suggest you to put your maven binaries under source control with your projects because due to maven history about backward compatibility (or lack thereof), it is clear that no one will be able to build your projects.
February 11th, 2005 at 3:56 pm
Mr Pirsch,
It would be too long to actually discuss all the irrelevant bits of your post that actually show more experience of small short term projects than long one…but I would suggest you get some good books about configuration management.
And I would suggest you to put your maven binaries under source control with your projects because due to maven history about backward compatibility (or lack thereof), it is clear that no one will be able to build your projects.
February 11th, 2005 at 5:58 pm
Mr Pirsch, just a few words, no offense.
Reusability ! What a magic bullet… Let’s analyse the need for reusability, ok ? Are you creating, let’s say, 3 brand new projects every month? Man, I mean, real projects? Not toys projects, like 3 month/men students BigDecimal implementation using AOP? Ok, a 200K lines of code, 10 sub-projects, 40 sub-sub-projects, 20 people involved, 2 years of intensive work. Real life projects, ya know? Full of JUnit, UML, XML-all-over-the-world, plus bonus technos like a bunch of Commons-XXX.jars spreaded through the code.
Then, we are not talking about highly intellectual differences between Procedural/Object development. It’s a question of “will we be able to deliver on schedule?”
When you say that “Maven solve all of these problems, you have a multiple repositories that can maintains these dependencies and plug-in”, I really think that you’ve missed the point.
Dependencies are NOT the more difficult thing to manage (even very late on the development process, teams are not splitting new libraries full of new methods and classes very often : generally, they “just” kick the bugs out of their code).
It’s the building process of the full project that is important : “Are we able to deliver something coherent at ANY time?”. Nothing is worst than this unability to deliver. It could be unfit, incomplet, full of bugs, has limited functionnality, but at least you can DELIVER !
Maven does not solve all these problems. Maven helps you to solve some of this problem, but you -actually – have to pay the price for this : you need a really smart or experienced guy to do the job. That’s my point. It could be a terrific tool, but it lacks documentation, stability, debugging information, all the little tiny things that make a building process a success or a living hell.
I’m confident that it will really soon become much better, because of all the work that had been put in, but at least, stop spreading buzz words like “Maven is Magic”. It’s far from being close to any reality.
btw : look at this url (http://java-source.net/open-source/build-systems/ant)
I don’t know if it has been done in purpose, but in the “see also” section, in the middle of the page, you can see that “maven” is just followed by “rant”, another tool that is suppose to be helpfull to build systems ;-)
February 12th, 2005 at 7:28 am
I totally agree with Emmanuel L.’s reply.
I have used both, Maven (mainly before it became 1.0 final) and Ant (1.5,1.6.x) on serveral projects.
My overall experience is that for simple setups and minimal config requirements, maven is pretty easy to setup and use (ramp-up time is necessary obviosly) – probably even faster to be setup than with Ant.
On the other hand, Ant gives you a decent “tool” that you can use to tweak and tune your build process to the exact requirements that you (as the architect) or the project (with its specific context) requires by always giving the whole team a chance to understand what’s going on (studying the build.xml and build.properties should make everything 100% clear).
There is one other lesson learned and it goes hand in hand with what Dion pointed out earlier. Don’t try to use your build process to do anything and keep it as simple as possible. In the past I fucked up on this sometimes … wanted to put this and that and whatever feature which added more and more complexity to the ant build file and process and made it even harder to understand for other people. So KISS and focus on what the you and your team really needs. Ask yourself:
- Is this feature enhancement really necessary?
- How many times will it get used?
- What’s the time that the team saves by adding this?
- Does the feature enhancement make the whole ant build process even more complex? What are the alternatives?
- Etc.
I also have to agree that if you download a maven based project, it usually can not build succesfully the first time. Can’t speak for everyone, but I also have to say that I could fix most of the problems in less than 30 minutes (due to Maven background and genereal build expertise). Most of the times, some libs could not be downloaded (not available, wrong version number, etc.) or some config settings were “individual”, meaning they had to be adapted to my local settings (tomcat path, nothing special or not to be solved in minutes).
But I also faced a situation where I had to throw Maven away in one project where I could not get the build to work anymore due to some memory consumption issues … I check every forum etc., but was not able to solve the issue. I have never had something like this with Ant.
I think the main point with maven is probably not even the global dependency management feature, but a common approach to build management that should start with namings (folder names src, …) and should go on with best practice implementations. I would also like to add that Maven still has some way to go in terms of stability and documentation and that I do not know many people who really use the global dependency management and esepcially in the way it is intended :-)
All in all, my preference for medium-to-complex projects without special, global dependency management requirements: Apache Ant.
In case of pretty simple projects or with the need for global requirements management: Mix of Maven and Ant (just to make :-)))
Looking forward to getting your feebback,
CKNY
February 12th, 2005 at 7:29 am
I totally agree with Emmanuel L.’s reply.
I have used both, Maven (mainly before it became 1.0 final) and Ant (1.5,1.6.x) on serveral projects.
My overall experience is that for simple setups and minimal config requirements, maven is pretty easy to setup and use (ramp-up time is necessary obviosly) – probably even faster to be setup than with Ant.
On the other hand, Ant gives you a decent “tool” that you can use to tweak and tune your build process to the exact requirements that you (as the architect) or the project (with its specific context) requires by always giving the whole team a chance to understand what’s going on (studying the build.xml and build.properties should make everything 100% clear).
There is one other lesson learned and it goes hand in hand with what Dion pointed out earlier. Don’t try to use your build process to do anything and keep it as simple as possible. In the past I fucked up on this sometimes … wanted to put this and that and whatever feature which added more and more complexity to the ant build file and process and made it even harder to understand for other people. So KISS and focus on what the you and your team really needs. Ask yourself:
- Is this feature enhancement really necessary?
- How many times will it get used?
- What’s the time that the team saves by adding this?
- Does the feature enhancement make the whole ant build process even more complex? What are the alternatives?
- Etc.
I also have to agree that if you download a maven based project, it usually can not build succesfully the first time. Can’t speak for everyone, but I also have to say that I could fix most of the problems in less than 30 minutes (due to Maven background and genereal build expertise). Most of the times, some libs could not be downloaded (not available, wrong version number, etc.) or some config settings were “individual”, meaning they had to be adapted to my local settings (tomcat path, nothing special or not to be solved in minutes).
But I also faced a situation where I had to throw Maven away in one project where I could not get the build to work anymore due to some memory consumption issues … I check every forum etc., but was not able to solve the issue. I have never had something like this with Ant.
I think the main point with maven is probably not even the global dependency management feature, but a common approach to build management that should start with namings (folder names src, …) and should go on with best practice implementations. I would also like to add that Maven still has some way to go in terms of stability and documentation and that I do not know many people who really use the global dependency management and esepcially in the way it is intended :-)
All in all, my preference for medium-to-complex projects without special, global dependency management requirements: Apache Ant.
In case of pretty simple projects or with the need for global requirements management: Mix of Maven and Ant (just to make :-)))
Looking forward to getting your feebback,
CKNY
February 12th, 2005 at 7:29 am
I totally agree with Emmanuel L.’s reply.
I have used both, Maven (mainly before it became 1.0 final) and Ant (1.5,1.6.x) on serveral projects.
My overall experience is that for simple setups and minimal config requirements, maven is pretty easy to setup and use (ramp-up time is necessary obviosly) – probably even faster to be setup than with Ant.
On the other hand, Ant gives you a decent “tool” that you can use to tweak and tune your build process to the exact requirements that you (as the architect) or the project (with its specific context) requires by always giving the whole team a chance to understand what’s going on (studying the build.xml and build.properties should make everything 100% clear).
There is one other lesson learned and it goes hand in hand with what Dion pointed out earlier. Don’t try to use your build process to do anything and keep it as simple as possible. In the past I fucked up on this sometimes … wanted to put this and that and whatever feature which added more and more complexity to the ant build file and process and made it even harder to understand for other people. So KISS and focus on what the you and your team really needs. Ask yourself:
- Is this feature enhancement really necessary?
- How many times will it get used?
- What’s the time that the team saves by adding this?
- Does the feature enhancement make the whole ant build process even more complex? What are the alternatives?
- Etc.
I also have to agree that if you download a maven based project, it usually can not build succesfully the first time. Can’t speak for everyone, but I also have to say that I could fix most of the problems in less than 30 minutes (due to Maven background and genereal build expertise). Most of the times, some libs could not be downloaded (not available, wrong version number, etc.) or some config settings were “individual”, meaning they had to be adapted to my local settings (tomcat path, nothing special or not to be solved in minutes).
But I also faced a situation where I had to throw Maven away in one project where I could not get the build to work anymore due to some memory consumption issues … I check every forum etc., but was not able to solve the issue. I have never had something like this with Ant.
I think the main point with maven is probably not even the global dependency management feature, but a common approach to build management that should start with namings (folder names src, …) and should go on with best practice implementations. I would also like to add that Maven still has some way to go in terms of stability and documentation and that I do not know many people who really use the global dependency management and esepcially in the way it is intended :-)
All in all, my preference for medium-to-complex projects without special, global dependency management requirements: Apache Ant.
In case of pretty simple projects or with the need for global requirements management: Mix of Maven and Ant (just to make :-)))
Looking forward to getting your feebback,
CKNY
February 12th, 2005 at 3:00 pm
Maven versus Ant
Almost every new web project starts with writing the Ant code to build a WAR. This build process is duplicated with some variance on every web application project I’ve ever worked on that uses Ant.
We lift our noses when we find developers copying an
February 12th, 2005 at 3:00 pm
Maven versus Ant
Almost every new web project starts with writing the Ant code to build a WAR. This build process is duplicated with some variance on every web application project I’ve ever worked on that uses Ant.
We lift our noses when we find developers copying an
February 14th, 2005 at 10:23 am
First, to the dude who is just flaming without putting any content in is post, please have at least the decency of naming yourself. BTW, when working with a product/tool wich is in development, one must be aware that between pre-releases, incompatibilities may arise.
To my homonym… No offence taken… I always appreciate discussing with people with a different point of view.
On the case of managing dependencies… I have been working on many large projects. Projects that are split up in many small subprojects. One of the things that bothers me a bit is having to check out the complete project to work on part of it.
I like to have to possibility to just checkout the subproject I need and have it depends on prebuild binaries of the parts required by this subproject to work properly.
So what I do is setup an automated build system that will periodicaly build every subprojects and put their binaries somewhere so I can use these instead of having to build them. Only working (compile and unit tests are successful) binaries are published.
There is many way I can achieve this. SCM tools like Rational ClearCase are able to do that for you. One can also rely on cheaper (and easier to manage) tools like CVS or Subversion SCM tools that are good to manage source code but not so good at managing build processes. But the build process management can be added on top of these cheap tools so you can achieve the same functionality.
Now, I can do that with Ant, but I have to do it myself (I’m a bit lazy)… I cannot also very easily do it with Maven as it allow to manage my dependencies quite easily. The only thing I need to had, is a way to create a property file that will contain the latest known good version of each subproject so I can use this list whenever I want to make sure that the subpoject I’m working on work nice with the latests binaries. So in the morning, I can just update this little file, rebuild my subproject and deploy… No need to rebuild everything.
So yes, I beleive that Maven dependencies management is a really usefull feature.
One of the thing that Maven help is capturing what the “smart people” (BTW, I don’t really agree that you need someone really smart do create Maven build scripts/plugins) wanty the build system to do in a plugin. So next time someone needs the build system, it’s there… No need to fiddle with Ant scripts for a few days when you need to start a new project (while it may not happen every day, it happens enough to make it woth it).
It true that reusability is often a goal that is never achieved. The main reason is that to be able to reuse something, you need to document it and distribute it. This is the first step that never happen. Maven provide you with the framework and the structure do help you do it. We can already see the benefits with common libraries like jakarta commons… Need commons-collections… Just add the dependencies in project.xml, build and your done! No need to go to their website, find the d/l page, d/l it, put it somewere under source control, modify you Ant script to add it to the classpath and then compile.
I working for a company that do mostly consulting but also has a development center. When we are doing the inhouse development, we are always creating a bunch of useful libraries that can be reused on many projects (we do have enough projects that comes in to make it really worthwhile) and we keep the rights on these “framework” components. One of the benefits of this development center is that when we sell this service to the customer, we also sell a common architecture (that we customize or adapt to match the needs of the client) (we are not really selling the architecture but reuising it so our development teams are more efficient). So all of these projects are build more or less the same way, uses more or less the same frameworks, etc. So yes, Maven help us do that more easily than Ant.
As I said, I do like Ant… I’ve been working with it since it’s inception (I even had to argument with some of my team mates that it was better to use Ant than to use make). But I also like Maven for that additional layer that allow us to keep thing a bit more organized, structured and reusable.
It’s still a young tool and do need to get better… And it will.
BTW, I never used “Maven is Magic”, “Magic bullet” or even “magic” is my previous post ;-)
I’m not bashing Ant… I’m just saying that Maven is also a nice tool.
Emmanuel P.
February 14th, 2005 at 10:23 am
First, to the dude who is just flaming without putting any content in is post, please have at least the decency of naming yourself. BTW, when working with a product/tool wich is in development, one must be aware that between pre-releases, incompatibilities may arise.
To my homonym… No offence taken… I always appreciate discussing with people with a different point of view.
On the case of managing dependencies… I have been working on many large projects. Projects that are split up in many small subprojects. One of the things that bothers me a bit is having to check out the complete project to work on part of it.
I like to have to possibility to just checkout the subproject I need and have it depends on prebuild binaries of the parts required by this subproject to work properly.
So what I do is setup an automated build system that will periodicaly build every subprojects and put their binaries somewhere so I can use these instead of having to build them. Only working (compile and unit tests are successful) binaries are published.
There is many way I can achieve this. SCM tools like Rational ClearCase are able to do that for you. One can also rely on cheaper (and easier to manage) tools like CVS or Subversion SCM tools that are good to manage source code but not so good at managing build processes. But the build process management can be added on top of these cheap tools so you can achieve the same functionality.
Now, I can do that with Ant, but I have to do it myself (I’m a bit lazy)… I cannot also very easily do it with Maven as it allow to manage my dependencies quite easily. The only thing I need to had, is a way to create a property file that will contain the latest known good version of each subproject so I can use this list whenever I want to make sure that the subpoject I’m working on work nice with the latests binaries. So in the morning, I can just update this little file, rebuild my subproject and deploy… No need to rebuild everything.
So yes, I beleive that Maven dependencies management is a really usefull feature.
One of the thing that Maven help is capturing what the “smart people” (BTW, I don’t really agree that you need someone really smart do create Maven build scripts/plugins) wanty the build system to do in a plugin. So next time someone needs the build system, it’s there… No need to fiddle with Ant scripts for a few days when you need to start a new project (while it may not happen every day, it happens enough to make it woth it).
It true that reusability is often a goal that is never achieved. The main reason is that to be able to reuse something, you need to document it and distribute it. This is the first step that never happen. Maven provide you with the framework and the structure do help you do it. We can already see the benefits with common libraries like jakarta commons… Need commons-collections… Just add the dependencies in project.xml, build and your done! No need to go to their website, find the d/l page, d/l it, put it somewere under source control, modify you Ant script to add it to the classpath and then compile.
I working for a company that do mostly consulting but also has a development center. When we are doing the inhouse development, we are always creating a bunch of useful libraries that can be reused on many projects (we do have enough projects that comes in to make it really worthwhile) and we keep the rights on these “framework” components. One of the benefits of this development center is that when we sell this service to the customer, we also sell a common architecture (that we customize or adapt to match the needs of the client) (we are not really selling the architecture but reuising it so our development teams are more efficient). So all of these projects are build more or less the same way, uses more or less the same frameworks, etc. So yes, Maven help us do that more easily than Ant.
As I said, I do like Ant… I’ve been working with it since it’s inception (I even had to argument with some of my team mates that it was better to use Ant than to use make). But I also like Maven for that additional layer that allow us to keep thing a bit more organized, structured and reusable.
It’s still a young tool and do need to get better… And it will.
BTW, I never used “Maven is Magic”, “Magic bullet” or even “magic” is my previous post ;-)
I’m not bashing Ant… I’m just saying that Maven is also a nice tool.
Emmanuel P.
February 14th, 2005 at 12:21 pm
I’ve worked with Ant and Maven and I find that both have pros and cons. I’m not an expert on either. IMHO, I think Ant offers a lot more control and flexibility than Maven does.
I’m currently designing a single build script that will be used for building multiple projects. So what do I do first? Try and reorganize each project’s directory structure to conform to a standard. Because without a common directory structure I think I’d be writing and supporting build scripts all my life! Takes precious time away from programming. So the first important thing is to stick to a standard directory structure. Maven suggests doing this.
All our projects rely heavily on open source software such as commons-collection, struts (various versions), etc. Currently each developer copies these jars into their projects during setup time. Which leads to jar management nightmares! So I decided to maintain a single repository that would contain all these jars (and various versions of each jar) and then let the developer specify the jars he or she wants during build time (rather than setup time). Maven does this as well.
The only thing I am still going back and forth is I rather have all related, say, struts files (struts.jar, struts-bean.tld, etc.) in a directory numbered as struts1.1/, struts1.2.4/, etc. Maven stores struts jars (suffixed with the version numbers) into a directory struts/jars and the struts tlds (suffixed with the version numbers) into the struts/tld directory. The problem with this approach is that I have to update my taglib definitions in all of my existing web.xml files from, say, struts-bean.tld to struts-bean-1.2.4.tld. I don’t think the developers would fancy making these changes. Lazy bas*^#$*.
Using Ant, I can provide two files where the developer specifies the jars (or just the base directory say struts1.2.4/**) and use the “includesfile” attribute to handle dependencies. One file is for creating the classpath (jars just required for compilation but *not* inclusion in the war file – “classpathIncludesFile.txt”) and the second file (warIncludesFile.txt) that contains jar file names (or entire directories) for including in a war file. The contents (just the jars) of the “warIncludesFile.txt” will be included in the classpath before the contents of the “classpathIncludesFile.txt”. To ease such changes, I could provide a default “defaultClasspathIncludesFile.txt” and a default “defaultWarIncludesFile.txt”. This way previous two files become optional. The ANT script will loaded these files while building. This way I can manage dependency (by configuration) rather than having the developer hack the actual build.xml file. In Maven, I believe the developer would need to hack the actual project.xml (add/modify/remove “dependency” elements) file. I would rather have developers (or as I like to call them end-users to build scripts) modify configuration files than the actual build files. Has anyone thought of a better approach?
Also, Maven is slow.
In Maven’s defense, it’s touted as more than just a build tool. It creates a website and other stuff that Ant currently doesn’t offer out-of-the-box.
IMHO, if I were to compare Ant and Maven on *just* building projects I think Ant would win. But if I want more than just a build tool, then I would consider Maven.
What works for one company/project may not work for another. I think one would first need to figure out what they want from a build tool. Maven encapsulates a lot of work, but in the process *I think* takes away the flexibility.
I think Maven has good intentions, but still needs work.
February 14th, 2005 at 12:21 pm
I’ve worked with Ant and Maven and I find that both have pros and cons. I’m not an expert on either. IMHO, I think Ant offers a lot more control and flexibility than Maven does.
I’m currently designing a single build script that will be used for building multiple projects. So what do I do first? Try and reorganize each project’s directory structure to conform to a standard. Because without a common directory structure I think I’d be writing and supporting build scripts all my life! Takes precious time away from programming. So the first important thing is to stick to a standard directory structure. Maven suggests doing this.
All our projects rely heavily on open source software such as commons-collection, struts (various versions), etc. Currently each developer copies these jars into their projects during setup time. Which leads to jar management nightmares! So I decided to maintain a single repository that would contain all these jars (and various versions of each jar) and then let the developer specify the jars he or she wants during build time (rather than setup time). Maven does this as well.
The only thing I am still going back and forth is I rather have all related, say, struts files (struts.jar, struts-bean.tld, etc.) in a directory numbered as struts1.1/, struts1.2.4/, etc. Maven stores struts jars (suffixed with the version numbers) into a directory struts/jars and the struts tlds (suffixed with the version numbers) into the struts/tld directory. The problem with this approach is that I have to update my taglib definitions in all of my existing web.xml files from, say, struts-bean.tld to struts-bean-1.2.4.tld. I don’t think the developers would fancy making these changes. Lazy bas*^#$*.
Using Ant, I can provide two files where the developer specifies the jars (or just the base directory say struts1.2.4/**) and use the “includesfile” attribute to handle dependencies. One file is for creating the classpath (jars just required for compilation but *not* inclusion in the war file – “classpathIncludesFile.txt”) and the second file (warIncludesFile.txt) that contains jar file names (or entire directories) for including in a war file. The contents (just the jars) of the “warIncludesFile.txt” will be included in the classpath before the contents of the “classpathIncludesFile.txt”. To ease such changes, I could provide a default “defaultClasspathIncludesFile.txt” and a default “defaultWarIncludesFile.txt”. This way previous two files become optional. The ANT script will loaded these files while building. This way I can manage dependency (by configuration) rather than having the developer hack the actual build.xml file. In Maven, I believe the developer would need to hack the actual project.xml (add/modify/remove “dependency” elements) file. I would rather have developers (or as I like to call them end-users to build scripts) modify configuration files than the actual build files. Has anyone thought of a better approach?
Also, Maven is slow.
In Maven’s defense, it’s touted as more than just a build tool. It creates a website and other stuff that Ant currently doesn’t offer out-of-the-box.
IMHO, if I were to compare Ant and Maven on *just* building projects I think Ant would win. But if I want more than just a build tool, then I would consider Maven.
What works for one company/project may not work for another. I think one would first need to figure out what they want from a build tool. Maven encapsulates a lot of work, but in the process *I think* takes away the flexibility.
I think Maven has good intentions, but still needs work.
February 14th, 2005 at 12:52 pm
Continuing my previous post, I could possibly use Ant within Maven to achieve the functionality of developers making changes to config files (.properties or .txt) rather than hacking away at the actual project.xml file. Never tried it though. Can someone verify off the top off their head?
February 14th, 2005 at 2:09 pm
Allan,
With maven, you can actually use properties to specify the version of your dependencies. Properties files, however, will not allow you to add or remove dependencies from the project.xml.
With Maven, you must also see the project.xml file more like a property file (with a structure) more than a build script. The actual build scripts reside in plugins or in maven.xml (which most of the time only contains the definition for the default goal).
As you said, different organizations/projects have different needs. Even if they have the same needs, different tools may allow one to fill these needs.
It just makes me sad when I see someone saying that one tool is better for him and then other people tells him that he’s wrong because that same tool did not work for them. I get even sadder when these same people make false statement (like the lack of documentation… Just type “maven –help” and you’ll find the “-X” “–debug” option) about the tool in question.
February 14th, 2005 at 2:09 pm
Allan,
With maven, you can actually use properties to specify the version of your dependencies. Properties files, however, will not allow you to add or remove dependencies from the project.xml.
With Maven, you must also see the project.xml file more like a property file (with a structure) more than a build script. The actual build scripts reside in plugins or in maven.xml (which most of the time only contains the definition for the default goal).
As you said, different organizations/projects have different needs. Even if they have the same needs, different tools may allow one to fill these needs.
It just makes me sad when I see someone saying that one tool is better for him and then other people tells him that he’s wrong because that same tool did not work for them. I get even sadder when these same people make false statement (like the lack of documentation… Just type “maven –help” and you’ll find the “-X” “–debug” option) about the tool in question.
February 14th, 2005 at 2:28 pm
Well, this thread become more and more interesting. It’s not a “Maven is Cr*p/Ant is Cr*p” religious war.
It’s much more “using Maven/Ant I had these problems on these projects and solved them with Ant/Maven, which helped me much more than the other tool”
so, Emmanuel (Pirsch), I must admit that starting a project with Maven is easier than with Ant, is a lot of things are implicit. I also admit that it could help a lot when dealing with jars from your sub-projects (yes, it’s really a PITA to rebuild every little pieces just to be able to test your own part). Yes also, Maven offer much more than Ant : web-site, etc…
But I’m noc convinced by your other points (no problem, it’s not because we don’t agree that you’re/I’m right ;-)
- Being able to check out a piece : ant already allow you to do the same. so it’s a tie.
- Maven helps you to avoid a dl on jakarta web-site : 15-0 for Maven
- configuring a dependancy on Maven is not really intuitive (the way the url is constructed is quite weird…), and you need to know which is the available versions, and the location of those jars. So you still have to navigate through the site to grab all these informations. That’s a 15-15, I think !
- I do not want sub-projects to use commons-collection-3.0, 3.1 and 2.1. I want one version, and I do think that grabing the jar, storing it locally, and reference it statically is safer, even if it’s a little bit painful. Maven dependancies easiness is useless in this case. It even can be dangerous, or help to mess your project. 15-30
- many smart people have written many Maven plugins for many tools : 30-30
- some of those smart people forgot documentation for their smart plugins… : 30-40
- I realy appreciate to be able, from project root, to understand what will be the build process: which sub-project will be built first, which one will be second, and so on. I don’t like this multiproject concept of “don’t bother, I’ll do the job”. Who is in charge? Maven or Me? I really want to tell the tool : “do this first, then that, then go to hell”, which helps to understand how it works, and if it doesn’t, why it does not. If you have forgotten a rotten project.xml somewhere deep in your subdirectories, you will be on a dire straits whith the error you’ll get. Not a big deal, but something that you don’t want to happen. 0-1?
The match is not over. I’m going to watch the second game, could be interesting.
Allan has a good point, too : “Maven has good intentions, but still needs work”. Work, and documentation. As good as could be a product, it has still the value of its weakest part…
February 15th, 2005 at 7:25 am
While doing another match would certainly be interesting… I don’t think we have to put the two tools against each other to recognize their advantage and shortcomings.
I do want to correct a bit the match point of the previous match.
I do like the fact that Maven, using the reactor, is able to create the right build sequence based on each subproject dependencies. With this feature, you just have to adjust the subproject dependencies and the build sequence will be adjusted automatically.
However, one is not required to use the reactor to build subprojects. Just like with Ant, one can execute subprojects build in a specified sequence without using the reactor.
So the previous match could, and probably would, have go into a tie breaker.
I think it obvious, that even if one tool win a point here, the other tool is going to win a point there. We have these tools that can help us create nice build systems for our projects. Some people prefer one of them, some people prefer the other one… I think it create a nice and healthy competition of ideas for how to create a build system. There is even cross-polination between the two tools… Maven can use Ant tasks and Ant now has Savant http://www.inversoft.com/online/savant/savant.html) to manage dependencies.
Emmanuel P.
February 15th, 2005 at 7:25 am
While doing another match would certainly be interesting… I don’t think we have to put the two tools against each other to recognize their advantage and shortcomings.
I do want to correct a bit the match point of the previous match.
I do like the fact that Maven, using the reactor, is able to create the right build sequence based on each subproject dependencies. With this feature, you just have to adjust the subproject dependencies and the build sequence will be adjusted automatically.
However, one is not required to use the reactor to build subprojects. Just like with Ant, one can execute subprojects build in a specified sequence without using the reactor.
So the previous match could, and probably would, have go into a tie breaker.
I think it obvious, that even if one tool win a point here, the other tool is going to win a point there. We have these tools that can help us create nice build systems for our projects. Some people prefer one of them, some people prefer the other one… I think it create a nice and healthy competition of ideas for how to create a build system. There is even cross-polination between the two tools… Maven can use Ant tasks and Ant now has Savant http://www.inversoft.com/online/savant/savant.html) to manage dependencies.
Emmanuel P.
February 15th, 2005 at 10:13 am
<snip>
With maven, you can actually use properties to specify the version of your dependencies. Properties files, however, will not allow you to add or remove dependencies from the project.xml.
With Maven, you must also see the project.xml file more like a property file (with a structure) more than a build script. The actual build scripts reside in plugins or in maven.xml (which most of the time only contains the definition for the default goal).”
</snip>
One of the goals of writing a common build script for multiple projects is that I want the developers to only change properties and/or specify the jars they want included in their webapp.
I don’t expect the developers (end-users of build scripts) to know Ant or Maven. And therefore I don’t expect them to know how to change the structure of project.xml/maven.xml (Maven) or build.xml (Ant). I’d rather hide the details and just provide them property files (or config files). This way there is one build.xml file shared by all projects (and maybe each webapp will have a build.xml that will call the shared build.xml) and each project will have an application.properties files to configure properties, jars to include, etc.
The whole idea is to keep it simple. If I treat project.xml “like a” property file as you said then every project will have a different project.xml. I can understand that plugins encapsulate the logic and perform the actual work that one would write in a ANT target.
And maybe that is the way it is. It’s just difficult making the transition. So what’s the use of property files in Maven?
February 15th, 2005 at 1:26 pm
Allan,
I don’t really see a difference between learning to read and modify a property file and learning to read and modify a maven project.xml file.
With maven, plugins are playing your the role of your shared build.xml. And the project.xml file is playing the role of your application.properties file. They have a different syntax. That’s all.
IMHO, the developer who do not understand the build system, whatever is it, has probably no business in adding or removing dependencies for a project. Now, I agree that the person managing the dependency of the project need not to understand the implementation of the build system (ie: the actual build script) but he needs to understand the availlable goals (or targets) and the structure (dependencies, folder structure, …) required for the build system to work properly.
Adding or removing a element in a project.xml file is by not mean something that takes weeks to master.
The properties files in Maven allow you to customize or pass arguments to your plugins, you can use to allow a developer to customize how a project.xml file is read. For example, if you want to allow the develepor to allow for some dependency to be in the war or not (while always keeping it available at compilation time) you can do the following :
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.1</version>
<properties>
<war.bundle>${war.bundle.commons-collections}</war.bundle>
</properties>
</dependency>
Then in your project.properties file you have
war.bundle.commons-collections=true
And if your developer does not want to bundle it in the war he will put in the build.properties (if he just want to overide the property for himself) :
war.bundle.commons-collections=false
You can use properties files to configure application server location or other environment dependent properties.
One of the nice thing about Maven handling of property files is that they are automatically included in a predictable manner.
project.properties files are meant to to be shared, so they are in version control. But you can overide them by creating a build.properties files in your local copy (at the same location of the project.xml file), you can also create a build.properties file in your home folder that will be available for all of your projects (this is a good place to put the location of Tomcat or another app server).
February 15th, 2005 at 1:26 pm
Allan,
I don’t really see a difference between learning to read and modify a property file and learning to read and modify a maven project.xml file.
With maven, plugins are playing your the role of your shared build.xml. And the project.xml file is playing the role of your application.properties file. They have a different syntax. That’s all.
IMHO, the developer who do not understand the build system, whatever is it, has probably no business in adding or removing dependencies for a project. Now, I agree that the person managing the dependency of the project need not to understand the implementation of the build system (ie: the actual build script) but he needs to understand the availlable goals (or targets) and the structure (dependencies, folder structure, …) required for the build system to work properly.
Adding or removing a element in a project.xml file is by not mean something that takes weeks to master.
The properties files in Maven allow you to customize or pass arguments to your plugins, you can use to allow a developer to customize how a project.xml file is read. For example, if you want to allow the develepor to allow for some dependency to be in the war or not (while always keeping it available at compilation time) you can do the following :
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.1</version>
<properties>
<war.bundle>${war.bundle.commons-collections}</war.bundle>
</properties>
</dependency>
Then in your project.properties file you have
war.bundle.commons-collections=true
And if your developer does not want to bundle it in the war he will put in the build.properties (if he just want to overide the property for himself) :
war.bundle.commons-collections=false
You can use properties files to configure application server location or other environment dependent properties.
One of the nice thing about Maven handling of property files is that they are automatically included in a predictable manner.
project.properties files are meant to to be shared, so they are in version control. But you can overide them by creating a build.properties files in your local copy (at the same location of the project.xml file), you can also create a build.properties file in your home folder that will be available for all of your projects (this is a good place to put the location of Tomcat or another app server).
February 15th, 2005 at 2:45 pm
Cool beans! Thanks Emmanuel.
February 18th, 2005 at 12:33 pm
By the way, Maven (or should I say jexl/jelly) treats hyphens in property names as an expression. See http://www.jroller.com/comments/ras_shadow/Weblog/maven_properties_and_anomalies_replace
Is this documented somewhere. I’m going to start documenting all this as I keep working on Maven. Maybe even write some articles if time permits :)
February 18th, 2005 at 12:33 pm
By the way, Maven (or should I say jexl/jelly) treats hyphens in property names as an expression. See http://www.jroller.com/comments/ras_shadow/Weblog/maven_properties_and_anomalies_replace
Is this documented somewhere. I’m going to start documenting all this as I keep working on Maven. Maybe even write some articles if time permits :)
February 18th, 2005 at 1:22 pm
Thank’s Allan!
February 18th, 2005 at 5:35 pm
Mr Pirsch,
What amaze me, is that you say that it’s a cool thing that a ’smart guy’ can write a maven plugin if you have a special need…well in case you did not realize…you can do it with Ant too !
I find amazing that many people actually need to write their own maven plugin, while they did not feel the need to write their own with Ant… is that a limitation ?
btw, if you do some serious job, don’t rely on external repo. Use your own where you have sources, binaries and docs available for all your third party as well as your build tool, you probably wrote some maven plugin that no one will be able to build after v 1.0.4 ;)
February 21st, 2005 at 11:11 am
Maven is all about designing project structure. I’ve posted some comments at http://jroller.com/page/eu/20050221#one_maven_s_feature_that
February 21st, 2005 at 11:11 am
Maven is all about designing project structure. I’ve posted some comments at http://jroller.com/page/eu/20050221#one_maven_s_feature_that
July 18th, 2005 at 7:26 pm
I think those that spend so much time on build systems are loosers. A build system is something that you put in place once and shouldnt tinker around with. Moth of these things like ant/maven are fluff for use instead of a shell script or a python or perl script. Yes, may be they make things a bit easy, but falks, really look at what you need to do… compile some files, copy it to a distribtion directory, replace some text, etc… why this crap like maven and ant shit? Just get on with what is more important, which is your product.
March 7th, 2006 at 3:51 pm
Hi all,
I am new to Maven. I am trying to do build using maven in my RAD workspace. I have one lib project and 1 portlet project (jsr 168) . The lib project built the first time i ran maven buildAll and genereates a jar file. I deleted the jar file and tried to build the lib project again, but this time it says the following:
(PGMLib is my lib project)
Attempting to download PGMLib-2.0.jar.
WARNING: Failed to download PGMLib-2.0.jar.
Here is my Maven.xml:
${lib_projects}
“${lib_projects}”
${lib_projects}
In lib Projetcts
${portlet_projects}
In portlet Projetcts ${portlet_projects}
–>
deploy
deploy
Deploying portlet ${pom.id}
Starting portlet app
Stop Server
Copy libraries
Start Server
Copy documentation
The above sample I got it from Managing websphere applications and maven article. I modified the project names thats all.
I really appreciate any replies.
thanks
March 7th, 2006 at 3:51 pm
Hi all,
I am new to Maven. I am trying to do build using maven in my RAD workspace. I have one lib project and 1 portlet project (jsr 168) . The lib project built the first time i ran maven buildAll and genereates a jar file. I deleted the jar file and tried to build the lib project again, but this time it says the following:
(PGMLib is my lib project)
Attempting to download PGMLib-2.0.jar.
WARNING: Failed to download PGMLib-2.0.jar.
Here is my Maven.xml:
${lib_projects}
“${lib_projects}”
${lib_projects}
In lib Projetcts
${portlet_projects}
In portlet Projetcts ${portlet_projects}
–>
deploy
deploy
Deploying portlet ${pom.id}
Starting portlet app
Stop Server
Copy libraries
Start Server
Copy documentation
The above sample I got it from Managing websphere applications and maven article. I modified the project names thats all.
I really appreciate any replies.
thanks
March 7th, 2006 at 3:56 pm
Hi all,
I am new to Maven. I am trying to do build using maven in my RAD workspace. I have one lib project and 1 portlet project (jsr 168) . The lib project built the first time i ran maven buildAll and genereates a jar file. I deleted the jar file and tried to build the lib project again, but this time it says the following:
(PGMLib is my lib project)
Attempting to download PGMLib-2.0.jar.
WARNING: Failed to download PGMLib-2.0.jar.
Here is my Maven.xml:
${lib_projects}
“${lib_projects}”
${lib_projects}
In lib Projetcts
${portlet_projects}
In portlet Projetcts ${portlet_projects}
–>
deploy
deploy
Deploying portlet ${pom.id}
Starting portlet app
Stop Server
Copy libraries
Start Server
Copy documentation
The above sample I got it from Managing websphere applications and maven article. I modified the project names thats all.
the link to the artice taht has actual the maven.xml: http://www-128.ibm.com/developerworks/websphere/library/techarticles/0503_boog/0503_boog.html?ca=dnp-413#N1021F
I really appreciate any replies.
thanks
March 7th, 2006 at 6:40 pm
Hi
Could someone please tell me how to deploy jsr 168 portlets on websphere using maven
thanks