Can some one please explain why do i need MAVEN here

[sandeeprajsingh tandon]

I am sorry to sound uneducated on Maven but i dont understand even after reading all the documentation of MAVEN why do i need it
Consider my example please
I am using Eclipse 3.2 with 2 Projects
Project 1 a java project has some jars downloaded from a central server and included in the build path.
Project 1 is then included as J2ee Module Dependenies in Project 2 which is a Web Project.
Any change in project 1 is automatically taken in by Project 2
So i have 4 questions
1) Is it necessary to include Project 1 as a j2ee module dependency in Project 2.
2) What would change if i put Project 1 in the JAVA BUILD PATH of Project 2
3) Do i need a MAVEN here. What would i gai using a MAVEN for my particular case.
4) In case i have to USE MAVEN, and i keep making changes in Project 1 would they be reflected in Project 2.

I Hope i didnt confuse anyone

Awaiting Help

[Tim Holloway]

It took me a long while to warm up to Maven. Unlike Ant, where you can see exactly what gets done when you build, Maven operates by magic. You have to pretty much put stuff exactly where it wants to find it, then you have to know what goals to build.

However, I've got projects that pull 20+ libraries from half a dozen sources. Maven is wonderful for this kind of thing. Instead of downloading and replicating the same JAR files in multiple projects, I can just refer to them in the POM and Maven will take care of the rest. Plus, adding new build options is less work.

To answer you questions. Nothing is "necessary", but if your 2 projects are both Maven projects, then you can get substantial benefits.

As far as automatic updating goes, in general, no. Maven is based on the concept that a project in production is not a continuously-mutating thing, it's a series of fixed releases. You normally would refer to one of those fixed releases (for example, release 1.0.2 of Project1 in the Project2 file). So to get Project2 to use a newer version of Project1, you'd need to do a deployment build of Project1 as a fixed release to your Maven repository. then update Project2's POM to use it.

That may seem a little inflexible, but it has the advantage that you know exactly what version of Project1 you're working with at all times. For large complex systems - especially those using components from all over the world (such as Apache, CodeHaus, JBoss and so forth) - keeping the outside changes to a minimum will ensure that your project will be more stable and make it easier to locate and repair bugs.

Maven isn't intended primarily to ensure that you work with the "latest and greatest" versions of everything, it's intended to help you work with predictable, stable stuff. I myself got burned badly enough in my Microsoft years to appreciate that - sometimes later and greater can break stuff. Nor is that just a Microsoft problem. One of the worst cases involved a large and expensive mainframe package where we had to roll back releases after only a week in production and wait for an even later and greater release while running the older version in the mean time. But Microsoft does that so well and so often I just couldn't resist picking on them.

[sandeeprajsingh tandon]

Thanks a lot Tim,

I got your point.

Actually the project 1 and Project 2 that i refer to are
1) Currently not using any 3rd party libraries even if there POM is referring to some hibernate libraries and other libraries(called as third party libraries hereafter). May be the entries are kept in POM for future use.
2) There are some framework libraries that are downloaded on to my hard disk as jars and both the projects have included them in their build path individually and as i said.. Project 2 has Project 1 in its build path. So my question is,
a) Do you think it would be better for me not to refer the framework jars on my hard disk but point to the server location in the POM
b) Incase i do not do as said in a , Project 1 already has these framework jars in its build path and project 1 is included as a J2EE module dependency in Project 2. But Project 2 still cries for those framework jars to be included as j2ee module dependencies even though project 1 is included. So should not project2 automatically refer to Project 1 jars.?

[Tim Holloway]

If your build environment is simple and your libraries aren't used in multiple projects, there's no major advantage in using Maven other than just for practice. But if you're using Hibernate, it's not a bad idea to have Maven manage the Hibernate dependencies.

I've got multiple projects and some of them use 20+ libraries, so Maven has become my friend (and I didn't make friends easily!). Maven is also good in a team environment because it makes it easy for another team member to pull in a project and start working on it.

Even if you're not using any of the public Maven repository third-party libraries, Maven can still help. You can add whatever libraries you want to your local Maven repository quite easily.

Besides making it easier to track libraries, Maven has another advantage for those of us who have a dozen or so projects on our computers at the same time. Maven builds by pulling the repo libraries straight from the Maven cache. So you don't have to keep copies of those libraries in physically in the projects that use them. That reduces the disk space requirements for the projects and of their master copies in the version control system. Every little bit helps!

BTW, I've got a monster project that I ship source code to a client periodically. The full build is over 40MB, but the actual source code ZIPfile is only 1.5MB! Since my Internet uploads aren't the world's faster, that's a major advantage for me right there.

Here's specific the answers to your questions. It doesn't matter about Eclipse. Eclipse can use Maven - or Ant, but Maven doesn't care about Eclipse and neither does Ant.

1. Nothing is necessary. It just might be useful.

2. How would you expect to do that? One thing you can do, however, is make a master project that contains BOTH Project 1 and Project 2 and have Maven build them as sub-projects. That's fairly common, especially with complex web projects where you might be building EJBs, multiple WARs and other artifacts, since Maven can only build one artifact per POM.

3. See above,

4. Going back to my original reply, Maven expects that projects are released as discrete revisions. Normally, you'd update the revision number and install the new revision (that is, of Project1) to the repository, although in a tight build like this, you could simply keep the same revision number and let the install process replace the older artifact in the repository.

If Project2 declares a dependency on Project1, that means that it expects to find a Project1 JAR in the Maven repository. Changing Project1 won't cause the changes to be automatically reflected in Project2 - you have to do an install build so that the repository copy of Project1 will be updated, since that's the copy that Project2 will pull when you build it. In the case where you have a parent project and Project1 and Project2 are sub-projects, you'd set it up so that when you built the parent project, it would build and install Project1, then build project2 using the newly-installed Project1 output.

[sandeeprajsingh tandon]

Thanks Tim:)

[sandeeprajsingh tandon]

Thanks a lot Tim for your time and explanations
Appreciate help