Hitachi Vantara Pentaho Community Forums
Results 1 to 8 of 8

Thread: First Steps for Mavenization

  1. #1
    Join Date
    Aug 2007
    Posts
    16

    Default First Steps for Mavenization

    As some first steps for this project, we were discussing how to go about maintaining the build integrity. Here are some of the options we came up with:
    • Copy code from where the Ant build wants it to where Maven wants it
    • Use svn:externals on directories in a parallel Maven structure that refer to packages and classes in the Ant build directory
    • Move code to where Maven would like it and alter the Ant build script to point to these directories

    We've begun with the second option (that of using svn:externals to create the Maven project structure virtually). However, as many community users have noticed, there are circular dependencies that surface when you begin splitting up code into logical modules.

    We cannot continue until we have resolved these circular dependencies with at least one new module, and this will require switching to the third option of actually moving java files into the Maven project structure. We have a solution in mind and it wont break the Ant build.

    We would like to get a feel from the Pentaho developers about what sort of impact this will have when we eventually merge this maven branch into trunk. If moving code around is not a problem, this will provide the cleanest solution for Mavenization.
    ________
    Buy Vapolution
    Last edited by atoor; 03-11-2011 at 07:03 PM.

  2. #2
    Join Date
    Nov 2005
    Posts
    164

    Default

    Hello All,

    I believe, in order to mavenize pentaho, you will have to refactor. There is no other way. However, inside the maven branch, I don't believe that you must make the build.xml work. My advice is to move code to where maven wants it and create the maven POMS. Forget about the build.xml inside the maven branch. When the mavenization is complete, I believe there is a plugin that will create ANT scripts (for those who want them).

    I think what Doug meant by "don't break the build" is don't break the trunk build. In the end, what we want are the same deliverables that we have today and an easy way to add more later. So if we get a build that has those same deliverables, the build isn't broken. The deliverables include such things as classes, jars, wars, ears, zips, tars, and such.

    As far as keeping up-to-date between the trunk and the maven branch, you may want to create an ANT scirpt that updates the maven branch on a regular basis.

    - Brian Hagan
    Pentaho Build Engineer/Support Engineer
    ________
    Utg multi shot shotgun shell cartridges
    Last edited by atoor; 03-11-2011 at 07:03 PM.

  3. #3
    Join Date
    Oct 2006
    Posts
    817

    Default

    In my mind, it is imperative that Pentaho embrace Maven completely, without concern for keeping the old process. Maven is more than a build tool; it is a set of best practices as well. If Pentaho tries to shoehorn its existing directory structure into Maven, then I think it will live in limbo between old and new--between Ant and Maven. It goes against the recommendations of the Maven documentation--it results in a build process that (1) doesn't look like a "standard" Maven build and (2) doesn't take advantage of the defaults you get when enabling a plugin. Enable a plugin on a standard directory structure and it just works with minimal configuration.

    I think clarification is needed from management as far as the meaning of "maintaining the build integrity." Because there is a separate branch for this Maven work, there is no chance of breaking the build in the trunk. So I can only assume the aforementioned breakage would occur at merge time. This is a build refactoring that will yield enormous benefit and tying the manually synchronize the old process would be quite an effort.

    In my opinion, the a good compromise is to provide both Maven and Ant builds where the Ant build is automatically generated from the Maven build.

    http://maven.apache.org/plugins/maven-ant-plugin/
    ________
    Montana Medical Marijuana
    Last edited by atoor; 03-11-2011 at 07:03 PM.

  4. #4
    dmoran Guest

    Default

    I am mainly concerned with keeping the trunk build working so the nightly build process and junit testing etc. continues to work. You should be able to do whatever you want with the branch. Obviously, there will need to be some kind of upgrade path if we decide to switch to Maven in the end.

    Doug
    ________
    CHICAGO ASSEMBLY
    Last edited by atoor; 03-11-2011 at 07:04 PM.

  5. #5
    Join Date
    Sep 2007
    Posts
    1

    Default Mavenization

    Sorry for my potentially silly remark

    Maven allows to change default directory tree (overriding the /src/main/java with a different directory layout).

    Is there any objection to this strategy?
    ________
    Steaming food
    Last edited by atoor; 03-11-2011 at 07:04 PM.

  6. #6
    Join Date
    Oct 2006
    Posts
    817

    Default

    I personally don't like the idea of using anything but the standard directory layout. One of the benefits of Maven is its standard directory layout. New developers know exactly where to find source code, JUnit tests, resources, etc. when the standard directory layout is used. I feel fairly strongly about this. What are the benefits of using a non-standard directory layout?
    ________
    FORD C1 PLATFORM HISTORY
    Last edited by atoor; 03-11-2011 at 07:04 PM.

  7. #7

    Default

    my two coppers --

    standard layout - definately a strong recommendation to stay with the maven layout.

    circular dependencies - as atoor mentioned, circular dependency issues. Some suggestions related to exceptions, etc are posted here, but the *Util classes will need some serious thinking/re-designing: http://forums.pentaho.org/showthread.php?t=27484

    SVN reference - virtual maven layout, that is a pretty cool approach!

    Ant vs Maven builds - I've had minimal success using the generated Ant scripts, but those were the early days and I'm not too familiar with the process now adays. However, may want to re-examine the Ant scripts anyway during the mavenization process, just as a reason/time to re-evaluate the build system. One of my bigger recommendations is to simply start placing produced jars (regardless if maven or ant built) into a seperate repo similar to ibiblio and then create application-build scripts using the repos. So 1) build jars 2) store jars in local/remote repo 3) build applications (war/ear/pci/etc) from those jars in local/remote repo.
    ________
    Honda vtx1800s
    Last edited by atoor; 03-11-2011 at 07:04 PM.

  8. #8
    Join Date
    Aug 2007
    Posts
    16

    Default

    All,

    Please see the updated Wiki Page with the progress that has been made with this effort.

    Also, dhartford - thanks for pointing out the circular dependencies. The posts that you made concerning this problem have gone a long way towards helping to solve the issue. To resolve a lot of these dependencies we had to move classes around from one module to another, but in other cases we did have to refactor code.

    Thanks,

    -Andeep
    ________
    Suzuki boulevard s50 specifications
    Last edited by atoor; 03-11-2011 at 07:05 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.