[EMAIL PROTECTED] writes:
> <LongMessageWarning/>
>
> I've been doing some thinking on this over the last couple of days in
> 'down time', so I'm posting them here for comment/laughter.
>
> - I don't want project.xml to become an ant build file, i.e. it should
> hold details about the project, not how it's built - that info is better
> off in the build files and properties files.
> - I'd like to define what is needed, e.g. jar, taglib-jar, war, portlet
> par file, ear file etc in a flexible way and have some good defaults to
> make it as little work as possible
> - I'd like maven to be able to produce multiple 'outputs' from a build.
> All from the same source and test tree.
>
I agree completely.
The Maven generated docs and consistency of build target names are
important.
I like the project.xml for defining high level concepts including (but
not limited to) name, url, cvsWebUrl, issueTrackingUrl,
distributionDirectory, distributions, mailingLists, developers
I like adding the 'output' or 'deliverable' element to the high level
concept and delegating to an ant build file (build-QQQQ.xml).
The build-QQQQ.xml file could provide targets like: compile, test,
iutest, dist for customization. By default these targets could call
standard Maven targets.
This will allow variable pre-processing steps: rmic, javacc, html
converter, in addition to (re)defining the filesets.
Alternative testing frameworks can be called, hopefully they will put
suitably formatted test results in ${basedir}/test-reports.
I believe specifying the type of output file in the project.xml is
unnecessary, and should be left to build-QQQQ.xml. The build-QQQQ.xml
file could set properties and call standard maven sub-targets
(maven:jar).
The user still sees a consistent Maven build:
ant maven:test --> runs 'test' cases for all 'output/deliverables'
ant maven:iutest --> runs 'iutest' cases for all 'output/deliverables'
ant maven:dist --> create a single file for each deliverable
ant -Ddeliverable=MyFirstDeliverable maven:test
--> runs 'test' for a specific deliverable
ant -Ddeliverable=MySecondDeliverable maven:dist
--> creates the single deliverable file (jar/war...)
Perhaps an auto-generated build file could be created to collect the
deliverable (compile/test/iutest/dist) targets.
If the build-MyFirstDeliverable.xml exists, use the targets defined
there, otherwise call standard maven targets.
Sample target for the auto-generated build file:
<target name="maven:compile">
<!-- user supplied build file -->
<ant antfile="build-MyFirstDeliverable.xml" target="compile"/>
<!-- default to maven target -->
<ant antfile="${maven.home}/build-maven.xml" target="compile"/>
</target>
Alvin.
> If I define an output in the build as a jar, maven should run maven:jar.
> If I define it as a war, it should run maven:war, ear runs maven:ear - how
> do we make this flexible to be extended by the user, and still workable.
>
> To make maven support multiple jars being built on a per project basis,
> something needs to hold the fileset on a per jar basis, e.g. in maven's
> case the fileset is:
>
> <jar jarfile="${build.dir}/${final.name}.jar">
> <!-- include classes -->
> <fileset dir="${build.dest}" excludes="**/package.html" />
> <!-- include jar resources -->
> <fileset dir="${jarResources.baseDir}">
> <patternset refid="jar.resources.set"/>
> </fileset>
> <manifest>
> <attribute name="Built-By" value="${user.name}"/>
> <!-- name should be '/' separated, not '.' -->
> <section name="${package}">
> <attribute name="Specification-Title" value="${id}"/>
> <attribute name="Specification-Version"
> value="${currentVersion}"/>
> <attribute name="Specification-Vendor"
> value="${organization}"/>
> <attribute name="Implementation-Title" value="${package}"/>
> <attribute name="Implementation-Version"
> value="${currentVersion}"/>
> <attribute name="Implementation-Vendor"
> value="${organization}"/>
> </section>
> </manifest>
> </jar>
>
> It would be nice to be able to specify the filesets, and let the user
> override them, e.g. we can specify something like this:
> <jar jarfile="${build.dir}/${jar.name}.jar">
> <!-- include classes -->
> <fileset refid="jar.${jar.name}.classes" />
> <!-- include jar resources -->
> <fileset refid="jar.${jar.name}.resources" />
> ....
>
> for a war that would be something like:
> <war warfile="${build.dir}/${webapp.name}.war"
> webxml="src/webapps/${webapp.name}/web/WEB-INF/web.xml">
> <fileset refid="war.${webapp.name}.web"/>
> <lib refid="war.${webapp.name}.lib" />
> <classes refid="war.${webapp.name}.classes"/>
> <webinf refid="war.${webapp.name}.webinf"/>
> <metainf refid="war.${webapp.name}.metainf"/>
> </war>
>
> The idea being here that in project.xml, you would list your build
> 'deliverables' or outputs, and maven would call a target defined in
> build-maven.xml to generate the output, passing in the appropriate jar
> name, war name etc. And the user can override the filesets in their build
> file as needs be. I'm not terribly sure if ant allows
> overriding/referencing of filesets, but I'll be finding out soon.
>
> So, in project.xml I'd define in the build section:
> <outputs>
> <output>
> <result>jar</result>
> <name>maven</name>
> </output>
> <output>
> <result>jar</result>
> <name>maven-cli</name>
> </output>
> <output>
> <result>war</result>
> <name>maven-web-gui</name>
> </output>
> <output>
> <result>taglib</result>
> <name>maven-jsp</name>
> </output>
> </outputs>
>
> build-maven.xml would delegate to the appropriate build-QQQQ.xml file as
> necessary, e.g. build-j2ee.xml or build-jetspeed.xml for the war, taglib,
> jar etc types
>
> Bring on the flames.../alternate designs :)
> --
> dIon Gillard, Multitask Consulting
> Work: http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
