On Jul 9, 2008, at 8:41 PM, Henrique Prange wrote:
> Hi Chuck,
>
> Chuck Hill wrote:
>> Hi Pierce,
>> On Jul 9, 2008, at 2:50 AM, Pierce T. Wetter III wrote:
>>>>>
>>>
>>> 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. 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.
>
> Will Ant tasks rely on Eclipse .classpath file to build WO projects?
> Can anyone explain a bit more about this subject?
I think Mike has covered that already.
>> 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. Duplication is duplication.
>> And will Eclipse update the Maven information in the pom.xml when
>> a new framework is added? When a new jar is added to the project?
>> Or is that all manual pom fiddling?
>
> Maven takes care of the project management. So, you only have to
> change the POMs (as explained by Lachlan). This way, you can
> generate configuration files for Eclipse, IDEA, Netbeans and any
> other IDE you want (maybe you have to write a plug-in).
>
> You can make the changes inside Eclipse with q4e or m2eclipse. These
> plug-ins synchronize the Eclipse configuration after a change in the
> POM.
That is an interesting way of doing it.
>> The rest of the patternsets are also not an Ant issue, but a design
>> philosophy in woproject (to not force a project layout).
>
> Maven don't force a directory layout also.
My point was that using either Maven or woproject, if you want a
flexible layout you need to do more work. If you can accept a set
layout, your life is easier. It is not an Ant vs Maven issue as
Pierce was suggesting.
>> If you do use a project layout, as Wonder does, these can easily be
>> rendered unnecessary.
>> 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. How would Maven handle it if the
>> package name for the Application were changed in Eclispe?
>
> maven-wolifecycle-plugin use this file to generate the WOA package.
> In fact, this plug-in also use the WOProject Ant Tasks for this
> goal. :)
>
> If you don't want to use the build.properties (or the maven-
> wolifecycle-plugin), you can add that information on your POM using
> properties and filtering the required resources on each build.
That is what I suspected. So Pierce is wrong to count those files
"against" Ant as both build system use them.
Chuck
>> Chuck
>>> This makes it easier to use a single generic Ant build file, but
>>> to some extent that's the whole point of maven in my mind. With
>>> Ant, everything is so bloody explicit that you end up creating a
>>> sort of virtual maven via Wonder's generic.xml.
>>>
>>> To quote from "generic.xml":
>>>
>>> 2) to build your own projects that have the same layout as a
>>> wonder project
>>>
>>> So mvn/Wonder have the same approach. Standardize on a layout, so
>>> that you can use the same build methodology everywhere. You use
>>> the same recipe you get the same bread.
>>>
>>> But I have to say, the ant build files are very complicated to
>>> understand compared to the pom.xml files. In the past, I've found
>>> that I end up having to grok all 1300 lines of Build/build/
>>> build.xml and Build/build/generic.xml in order to debug the build
>>> of one of my projects.
>>>
>>>>
>>>> Second, the individual build files build way more projects:
>>>>
>>>> macbook:Wonder ak$ find . -name build.xml|wc
>>>> 67 67 2775
>>>> macbook:Wonder ak$ find . -name pom.xml|wc
>>>> 56 56 2121
>>>
>>> You're looking at what you have, but I've rewritten all of those
>>> and added new ones. I have files to build nearly everything in
>>> Wonder on my system:
>>>
>>> sierramadre:Wonder pierce$ find . -name pom.xml | wc
>>> 68 68 2440
>>>
>>>>
>>>> Thirdly from what I've seen, someone needs to change all these
>>>> files whenever we bump a version. All of Ulrichs commits so far
>>>> where these xml fixes. All *I* need to do is set one property.
>>>
>>> I'm using a property in my pom.xml versions as well. So changing
>>> all those files isn't really necessary, I can change the version
>>> by changing the master pom.xml, same as you can. Eventually, I'll
>>> move all the jar references up to the master pom, which will save
>>> me a line per reference, and standardize the versions used.
>>>
>>>>
>>>>
>>>> Fourth, adding a project typically requires five lines in Build/
>>>> build/build.xml to add it to the correct group and some props. I
>>>> might consider moving these props from the build file to a
>>>> build.properties and making Build/build/build.xml only specify
>>>> the inter-related deps.
>>>
>>> Except you have to add the build dependencies somewhere as well,
>>> which if you want to compare apples/oranges, you really have to
>>> count right? You also have to count the information in
>>> build.properties. The information in the pom.xml file for a new
>>> project without dependencies is more then 5 lines, its like 10
>>> lines, but 5 of those name the project so you can reference it
>>> elsewhere and the other 5 reference the super-pom.
>>>
>>>>
>>>>
>>>> I'll grant you one point for the commons-logging versions, but I
>>>> use neither ERJGroups or EROpenID. If I were and I'd be bothered,
>>>> I'd figure out a way to keep them using only one.
>>>>
>>>>
>>>
>>> It's not just that jar. WO uses commons-logging as well. The real
>>> point here is that managing jar dependencies sucks. I know you
>>> feel criticized but you shouldn't take it personal because I'm
>>> talking about Wonder as my real point is that Wonder, which is
>>> widely used, and considered pretty stable, has some jar dependency
>>> issues. The solution to the jar problem that Wonder uses is the
>>> ERJars framework for common jars, and Libraries directories for
>>> unique jars, but that doesn't really solve the problem unless
>>> someone with Obsessive-Compulsive-Disorder dedicates their life to
>>> keeping ERJars in sync. Even then, what if you want some
>>> frameworks and not others from Wonder, or you need the same (but
>>> newer version) jar in one of your applications.
>>>
>>> The maven solution is to document the dependencies, and setup a
>>> whole bunch of infrastructure in order to be able to compute all
>>> that stuff on the fly.
>>>
>>> Again, you use the same recipe you get the same bread;
>>> conceptually, ERJars functions as a maven repository, just one
>>> manually maintained.
>>>
>>> Having had to fight with a whole bunch of jar dependency issues in
>>> production recently, I'm leaning more towards the maven way; as
>>> opposed to trusting that every engineer will dutifully scour all
>>> the other Libraries directories in all the other projects to see
>>> what's needed where. Or even that I'll remember to push the
>>> missing jar into production.
>>>
>>>>
>>>>
>>>> So far we've seen that maven is neither more terse nor more
>>>> powerful (at least in a way that would mean something to me).
>>>
>>>
>>> I think maven makes a reasonable attempt to solve a really,
>>> really annoying problem.
>>>
>>> As far as terseness goes, perhaps that's not the right measure,
>>> but generic.xml gives me the freaking willies, while pom.xml seems
>>> stunningly obvious. I mean I really, really detest Ant build
>>> files. I'd actually prefer regular make files.
>>>
>>>
>>>>
>>>> The other issues I have with it is that I actually *need* the
>>>> flexibility in deployment structure. In some projects I *don't*
>>>> want all-embedded builds as that stuff goes out of hand with 7
>>>> apps*all the frameworks. The resulting release tops 250M. So I
>>>> want some of them embed only some jars. Show me how this works
>>>> with maven *without* writing any "goals" or "mojos".
>>>
>>> Well, now you're bottoming out my maven knowledge, as I'm not
>>> quite sure what you're complaining about.
>>>
>>>>
>>>>
>>>> So in summary, maven may or may not be nice. But I've been
>>>> building Wonder with the build files for 7 years now and they
>>>> haven't really changed a lot in this time. They do the roughly
>>>> the same as some 20MB tool chain where you *still* have to write
>>>> java plugins for.
>>>
>>> And I have to maintain a build that's based on some stale snapshot
>>> of the Wonder build files, and given a choice between grokking
>>> generic.xml and or throwing it out and learning maven, I'm leaning
>>> towards Maven, because its sucked so far. Of course, the latest
>>> Wonder generic.xml looks a lot cleaner then what I have now, so
>>> that's not necessarily a fair criticism. But maybe it is, because
>>> I would never have dived into Wonder to tweak the Ant builds, but
>>> tweaking the Maven builds was pretty simple.
>>>
>>> But as I keep saying, you use the same recipe you get the same
>>> bread. The Wonder Ant build and the Maven build at the end of the
>>> day have to do the same steps and need the same information. Ant,
>>> being more explicit, ends up pushing you towards a generic.xml
>>> type solution, where every step in the build is spelled out
>>> explicitly, but a certain folder layout is assumed, and certain
>>> things are stored in external files. That way, you can use the
>>> same Ant build script over and over.
>>>
>>> Maven, being more implicit, ends up pulling the equivalent of
>>> generic.xml into these plugin definitions based on the assumption
>>> that all WO framework projects have to be built the same way for
>>> all developers. That leaves the project specific information to be
>>> specified somewhere like the project name and dependencies. Which
>>> goes in one place, the pom.xml.
>>>
>>> So at the end of the day, to use Wonder's generic.xml, you have to
>>> setup your folder structure in a certain way and put certain
>>> information in .classpath, .patternset, and .properties files. To
>>> use maven, you have to setup your folder structure in a certain
>>> way and put that same information in pom.xml. At the system level
>>> you have to think of Ant as Ant plus the generic.xml you're using,
>>> and at that point, Ant+Wonder Build Scripts == Maven. Maven just
>>> goes on to leverage the information in the pom in other ways.
>>>
>>> This title of this post is "Maven Optimism", following up from
>>> "Maven Skepticism". I'm still a long way from being a maven
>>> expert, but I've sort of refused to become an Ant expert. But so
>>> far, I'm a lot more optimistic about being able to use Maven
>>> effectively. I think it brings a lot to the table, and solves some
>>> tough development issues.
>>>
>>> Pierce
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-de..ists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>>>
>>> This email sent to chil..lobal-village.net
>>>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-de..ists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>
> This email sent to chil..lobal-village.net
>
--Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
This archive was generated by hypermail 2.0.0 : Thu Jul 10 2008 - 13:54:47 EDT