Luis, It's these relative paths that are going to be your biggest problem changing your build. As was mentioned in an earlier part of the thread, it helps to think of ant as being procedural and maven object oriented. Ant is very procedural and it suffers from many of the same problems as procedural languages.
Think of one build file including another via a relative path being like one C header including another with a relative path. Over time these relative includes cause the system to become hopelessly interdependent and brittle, and a labyrinth to navigate and understand. Your build is completely dependent on the build file system layout and to reusing or restructuring any portion of it becomes a nightmare. Maven's approach is more OO; modularizing sections of the build into artifacts and sharing these with other sections of build independently of location in the build tree. It is this location independence that is key. Reaching out of one project to use something in another is like breaking a classes' encapsulation by calling a private member variable, it shouldn't be done. A Relative path is an implicit dependency, having one ultimately ties you to the path target. Maven has excellent dependency management; you want it to be handling dependencies for you. Your goal is to modularize these build sections into maven artifacts and let maven worry about who's using them and where they can be found. This way you rid yourself of the tyranny of these relative paths, and where a project lives in the build tree is no longer important. So how then do you get started migrating? Tackling any large Ant project It's a sure guarantee that if you start at the root of your build tree (or root build.xml) and work down you will tie yourself in knots and never get anywhere. The easiest thing will be for you to start with the leaves on your build tree and work backwards. But what constitutes a leaf and where are they found? You will most probably have sections of your build that only rely on third party jars. Typically these are utils and other library packages that are widely used at higher levels. These are the easiest to start with so break them out into your first maven project(s). Once you have these base library artifacts you now have useable dependencies that are independent of their location in the build tree, congratulations ;) You can start on mavenizing other parts of the build tree that depend on your newly mavenized projects. Don't worry too much about project inheritance and the like this early, this is something that will reveal itself as you progress, and your main concern initially is just to tame the build. Once everything is mavenized you will have a much better idea of what the ugly parts of the build are and how the hierarchy can be refactored into something more maintainable. Along the way, you will no doubt have to move some classes out of packages where the do not belong, but this is all part of bringing you build under control. Buy in from development might be required to make this happen but often it is glaringly obvious that classes are placed where they shouldn't be. Bad modularization and architecture in the source will bleed into the build and cause the same problems there as it does in the code. Don't be afraid to bring this to people's attention. Where its not so obvious, or where you have confusing cycles, you can create a project with the sole purpose of breaking the dependency until such a time as the whole build is under control and you can discuss the proper way for them to be addressed and refactored away. Also keep in mind the OO analogy, that moving from maven to ant is similar to porting a procedural app to an object oriented language. There were things that made sense in the procedural world that don't belong in an OO app. Change what you see needs to change. Believe me, once you have everything mavenized, your life maintaining the build will be much easier. Anyhow I hope this helps you get started, shout if you have any questions. Rgds, ste -----Original Message----- From: Luis Roberto P. Paula [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 3:48 AM To: Maven Users List Subject: Re: Ant basedir >> What would you want to use this basedir property for? Maven has a different mindset for referencing resources within a project than ant. I'm sure if you describe your use case here someone will show you the maven way to do things. I'm using maven to call a ant-build file that is in another directory. The problem is that there is a lot of relative paths in this ant file. On Dec 11, 2007 9:43 PM, Gargan, Stephen <[EMAIL PROTECTED]> wrote: > What would you want to use this basedir property for? Maven has a > different mindset for referencing resources within a project than ant. > I'm sure if you describe your use case here someone will show you the > maven way to do things. > > Rgds, > > ste > > -----Original Message----- > From: Luis Roberto P. Paula [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 11, 2007 11:27 AM > To: Maven Users List > Subject: Ant basedir > > Hi, > > How do I set ant basedir from maven? > > I was trying something like that: > > *<ant basedir="/tmp/test" antfile="build.xml">* > > but there is no basedir attribute. > > Thanks, > Luis > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
