Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Here's a simple and quick answer to Mavenizing an Ant project:</p> <p><em><strong>DON'T DO IT!</em></strong></p> <p>This is not some anti-Maven screed. I use Maven, and I like Maven. It forces developers not to do stupid things. Developers are terrible at writing build scripts. They want to do things this way and not the way everyone else does. Maven makes developers setup their projects in a way that everyone can understand.</p> <p>The problem is that Ant allows developers to do wild and crazy things that you have to completely redo in Maven. It's more than just the directory structure. Ant allows for multiple build artifacts. Maven only allows for one per <code>pom.xml</code><sup>1</sup>. What if your Ant project produces a half dozen different jar files -- and those jar files contain many of the same classes? You'll nave to create a half dozen Maven projects just for the jars, and then another half dozen for the files that are in common between the jars.</p> <p>I know because I did exactly this. The head of System Architecture decided that Maven is new and good while Ant must be bad and Evil. It didn't matter that the builds worked and were well structured. No, Ant must go, and Maven is the way.</p> <p>The developers didn't want to do this, so it fell to me, the CM. I spent six months rewriting everything into Maven. We had WSLD, we had Hibernate, we had various frameworks, and somehow, I had to restructure everything to get it to work in Maven. I had to spawn new projects. I had to move directories around. I had to figure out new ways of doing things, all without stopping the developers from doing massive amounts of development.</p> <p>This was the inner most circle of Hell. </p> <p>One of the reasons why your Ant projects are so complex probably has to do with dependency management. If you are like our current shop, some developer decided to <strike>hack together</strike> <em>develop</em> their own system of dependency management. After seeing this dependency management system, I now know two things developers should never write: Their own build files, and dependency management systems.</p> <p>Fortunately, there is an already existing dependency management system for Ant called <a href="http://ant.apache.org/ivy">Ivy</a>. The nice thing about Ivy is that it works with the current Maven architecture. You can use your site's centralized Maven repository, and Ivy can deploy jars to that repository as Maven artifacts.</p> <p>I created an Ivy project that automatically setup everything for the developers. It contained the necessary setup and configuration, and a few macros that could replace a few standard Ant tasks. I used <code>svn:externals</code> to attach this Ivy project to the main project.</p> <p>Adding the project into the current build system wasn't too difficult:</p> <ul> <li>I had to add in a few lines in the <code>build.xml</code> to integrate our <code>ivy.dir</code> project into the current project.</li> <li>I had to define an <code>ivy.xml</code> file for that project.</li> <li>I changed any instance of <code>&lt;jar</code> and <code>&lt;/jar&gt;</code> to <code>&lt;jar.macro</code> and <code>&lt;/jar.macro&gt;</code>. This macro did everything the standard <code>&lt;jar/&gt;</code> task did, but it also embedded the <code>pom.xml</code> in the jar just like Maven builds do. (Ivy has a task for converting the <code>ivy.xml</code> file into a <code>pom.xml</code>).</li> <li>I Ripped out all the old dependency management crap that the other developer added. This could reduce a <code>build.xml</code> file by a hundred lines. I also ripped out all the stuff that did checkouts and commits, or ftp'd or scp'd stuff over. All of this stuff was for their Jenkins build system, but Jenkins can handle this without any help from the build files, thank you. </li> <li>Add a few lines to integrate Ivy. The easiest way was to delete the jars in the <code>lib</code> directory, and then just download them via <code>ivy.xml</code>. All together, it might take a dozen lines of code to be added or changed in the <code>build.xml</code> to do this.</li> </ul> <p>I got to the point where I could integrate Ivy into a project in a few hours -- if the build process itself wasn't too messed up. If I had to rewrite the build.xml from scratch, it might take me a two or three days.</p> <p>Using Ivy cleaned up our Ant build process and allowed us many of the advantages we would have in Maven without having to take a complete restructuring.</p> <p>By the way, the most helpful tool for this process is <a href="http://www.scootersoftware.com">Beyond Compare</a>. This allowed me to quickly verify that the new build process was compatible with the old.</p> <hr> <h2>Moving onto Maven Anyway...</h2> <p>The funny thing is that once you have integrated your Ant projects with Ivy, turning them into Maven projects isn't that difficult:</p> <ul> <li>Clean up the logic in your <code>build.xml</code>. You might have to rewrite it from scratch, but without most of the dependency management garbage, it's not all that difficult.</li> <li>Once the <code>build.xml</code> is cleaned up, start moving directories around until they match Maven's structure.</li> <li>Change source to match the new directory structure. You may have a WAR that contains *css files in a non-standard location, and the code is hardwired to expect these files in that directory. You may have to change your Java code to match the new directory structure.</li> <li>Break up Ant projects that build multiple projects into separate Ant projects that each builds a single artifact.</li> <li>Add a <code>pom.xml</code> and delete the <code>build.xml</code>.</li> </ul> <hr> <p><sup>1</sup> Yes, I know this isn't entirely true. There are Maven projects with sub-projects and <em>super poms</em>. But, you will never have a Maven project that builds four different unrelated jars while this is quite common in Ant.</p>
    singulars
    1. This table or related slice is empty.
    1. POMigrating complex project from Ant to Maven - How to handle unusual folder structures?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USDavid W.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POMigrating complex project from Ant to Maven - How to handle unusual folder structures?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload