Re: Maven Optimism

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Wed Jul 09 2008 - 19:59:45 EDT

  • Next message: Lachlan Deck: "Re: Maven Optimism"

    On 10/07/2008, at 3:06 AM, Chuck Hill wrote:

    > On Jul 9, 2008, at 2:50 AM, Pierce T. Wetter III wrote:
    >>>>
    >>>> I may have miscounted by overcounting the symlinks to build.xml
    >>>> though as I didn't notice those but I think you're undercounting
    >>>> by only looking at Build/build/*.xml.
    >>
    >> I'm using this as a measure:
    >>
    >> wc -l `find . -name "build.xml" -print` Build/build/build-*.xml
    >> Build/build/generic.xml `find . -name "build.properties" -print`
    >> `find . -name "*.patternset" -print` `find . -name ".classpath" -
    >> print`
    >
    >> Because the problem as I've found with Ant is that the build
    >> information is in all of those files, not just build.xml.
    >
    > Lets place the blame where the blame belongs and make a more honest
    > comparison. This is most NOT an Ant issue.

    Agreed.

    > It is a WOProject / build philosophy issue. The duplication
    > between .classpath and some of the files in woproject/ are a
    > deficiency in the woproject Ant tasks in that they currently can't
    > use what is in .classpath. Mike is working on fixing this.

    He still won't drop the ...

    > Now, what does maven do for this? Unless it is reading
    > the .classpath file, it also has to somehow, somewhere duplicate the
    > information that Eclipse uses.

    No. It's the opposite actually. The classpath is dynamic via the maven
    plugin / builder. i.e., the classpath in eclipse is derived from your
    pom. So there's no duplication there.

    > And will Eclipse update the Maven information in the pom.xml when a
    > new framework is added?

    Yes.

    > When a new jar is added to the project?

    Yes.

    > Or is that all manual pom fiddling?

    You can do that also if you wish and there's nothing to do in Eclipse
    (except maybe refresh if you edited it externally from Eclipse). i.e.,
    all of these three examples result in pom file updates.

    > Finally, build.properties:
    >
    > principalClass=
    > project.name=
    > customInfoPListContent=
    > eoAdaptorClassName=
    > webXML=
    > webXML_CustomContent=
    > classes.dir=
    >
    > If Maven does not use these and does not have a parallel system,
    > then it has less flexibility.

    Maven has both a properties section and other similar means.

    > How would Maven handle it if the package name for the Application
    > were changed in Eclispe?

    Huh?

    with regards,

    --
    

    Lachlan Deck



    This archive was generated by hypermail 2.0.0 : Wed Jul 09 2008 - 20:01:12 EDT