Martin Höller wrote:
>
> Am Mittwoch, 7. Juli 2010 01:19:16 schrieb asookazian:
> [...]
>> This is one area where Ant is much more flexible than Maven (or at least
>> it's easier to customize invocations of targets in Ant than it is with
>> goals in Maven's lifecycle phases)...
>
> Why don't you stick with Ant then?
>
> From your previous mails it seems to me like you are trying to use Maven
> like
> you did with Ant. Maven is not Ant! If you want to use Maven, use it the
> Maven way or you won't benefit from it at all. Start with reading a good
> Maven book like "Maven - The Definitve Guide" [0] from Sonatype (which
> seems
> is now split into two books).
>
> hth,
> - martin
>
> [0] http://www.sonatype.com/products/maven/documentation/book-defguide
>
>
>
1) I *must* use Maven for work project. And currently we're stuck with
2.0.8 (we have no in-house Maven experts to help us upgrade to 2.2.x or
3.0).
2) I have read a couple books on Maven including the O'Reilly book (which is
pretty decent btw). Maven is so complex that it takes months of hands-on
experience to master in terms of adding modules/POMs, adding profiles,
creating plugins/MOJOs, creating a custom lifecycle, setting up CI (e.g.
Continuum) and Nexus repo, understanding (transitive) dependency management,
learning/using m2e in Eclipse WTP envmt, etc.
3) There is an example of hooking into Maven lifecycle/builds from Ant
build.xml script in the JBoss Weld (CDI RI) distro:
<target name="package">
<maven target="install" basedir="${basedir}">
<arg line="-f ${pom.file}" />
</maven>
</target>
<macrodef name="maven">
<attribute name="target" />
<attribute name="basedir" />
<element name="args" implicit="true" optional="true" />
<sequential>
<java classname="org.codehaus.classworlds.Launcher" fork="true"
dir="@{basedir}" failonerror="true">
<classpath>
<fileset dir="${maven.dir}/boot">
<include name="*.jar" />
</fileset>
<fileset dir="${maven.dir}/bin">
<include name="*.*" />
</fileset>
</classpath>
<sysproperty key="classworlds.conf"
value="${maven.dir}/bin/m2.conf" />
<sysproperty key="maven.home" value="${maven.dir}" />
<args />
<arg line="@{target}" />
</java>
</sequential>
</macrodef>
This is what I based my build.xml off of.
4) Maven should be able to accommodate an exploded WAR and EAR without
having to package the WAR and then unexplode it. And I should not have to
use a plugin like jboss-maven-plugin unpack goal to achieve this (which
explodes the EAR but not the WAR). I understand that the install lifecycle
phase will ultimately install the EAR into a local Maven repo, but what if I
don't necessarily need that to happen for my local dev builds on my dev box?
In the
http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.0/maven-core/src/main/resources/META-INF/plexus/components.xml
file I see the following:
<!-- START SNIPPET: war-lifecycle -->
<phases>
<process-resources>org.apache.maven.plugins:maven-resources-plugin:resources</process-resources>
<compile>org.apache.maven.plugins:maven-compiler-plugin:compile</compile>
<process-test-resources>
org.apache.maven.plugins:maven-resources-plugin:testResources
</process-test-resources>
<test-compile>org.apache.maven.plugins:maven-compiler-plugin:testCompile</test-compile>
<test>org.apache.maven.plugins:maven-surefire-plugin:test</test>
<package>org.apache.maven.plugins:maven-war-plugin:war</package>
<install>org.apache.maven.plugins:maven-install-plugin:install</install>
<deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy>
</phases>
<!-- END SNIPPET: war-lifecycle -->
What exactly is 'war' or 'install' above? Is that referring to a Maven
plugin (e.g. maven-war-plugin and maven-install-plugin)? or a specific goal
(e.g. war:war)? Maybe I can write a custom lifecycle which uses
war:exploded instead...
--
View this message in context:
http://maven.40175.n5.nabble.com/Maven-3-explode-goal-tp946368p1044748.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
