Maven 1

Oops, I see I just entered a duplicate of this in http://jira.codehaus.org/browse/MAVEN-1418.

I REALLY want this fixed also. Any chance it can get in 1.0.1?

If you submit a patch there are more chances.
If you also submit test cases I'm almost sure it will be fixed.

See the test case in http://jira.codehaus.org/browse/MAVEN-1418.

The attached patch fixes this bug. I've included a test in ProjectInheritanceTest that checks that two dependencies, one with type=jar and another type=war generate two entries in the dependency tree. This test should fail if run against the released maven, it succeeds if applied with the rest of the patch.

Will this patch make it to the release?

I really appreciate Maven, by the way: Many thanks to the developers.

Dan Greening

Quoting Trygve:
The type is not going to be a part of the dependency id in maven 2 so it should not become a part in maven 1 either.

Regarding your comment Carlos :
I have always felt there was something odd about artifacts and dependencies in the POM (maven1) : an artifact is something 'physical', in the sense that it is a concrete file in the FS. An artifact has a 'type' which is indeed rather its file extension. However, the 'type' is sometimes misunderstood as the 'role' of the artifact : is it a plain library, a tag-library, a maven plugin, etc...

The jar 'type' (rather file extension) is the best example of this : a jar file can be used for many purposes. In the repository, the
<group>/<type>s/<file>-<version>.<type> naming convension should in my opinion be
<group>/<role>s/<file>-<version>.<type>

So my question is, regarding maven2, will this notion be introduced (i guess from your comment that you may be rather conservative on the POM in maven2 and if not, how do you address the practical issue this jira-issue relates to (the fact that you have to workaround this by using a different name for, let's say, a plain library and a tag-library).

Today's plugins make distinctions on basis of type. Some simple examples: dll vs. jar, ejb and war, etc. Having the same name, such as "user.dll" and "user.jar" (sometimes produced by the same project) can be helpful in determining the things that go together.

Or, in the case of ejb and library jar files, both named "user.jar" (OK I didn't invent this, Sun did) knowing what artifact type you are referring to can determine where it is to be deployed. And sometimes you depend on both.

Can one of the powers that be talk about how these distinctions would be handled in Maven 2? I'd like some guidance on how to handle this.

Independently on what how M2 is going to handle it, I think we should fix this situation on Maven 1.x, preferably at the 1.0 branch.

So, did anybody test this patch? What's the status, are we willing to apply it? If not, why, because it doesn't provide test cases?

The patch I provided does include a couple of test cases, but if more are needed I can add them.

Dan,

I'm not sure if your patch is ok because I applied it and now cactus is not working in my project. Instead of running the cactifywar tasks, it only display the task on the console, as shown below:

war:war:
[echo] Building WAR configmanager
[jar] Updating jar: S:\components\components\configmanager\target\configmana
ger-1.1.4.war
<cactifywar destfile="s:\components\components\configmanager/target/configmanage
r-cactus.war" version="2.3"><classes dir="s:\components\components\configmanager
/target/test-cactus-classes"></classes><filterredirector mapping="/test/filterRe
director.jsp"></filterredirector><classes dir="C:\Documents and Settings\t_fl01\
.maven\cache\cactus-maven-1.7dev\plugin-resources/jboss3x"><include if="cact
us.home.jboss3x" name="*.properties"></include></classes><webinf dir="C:\Documen
ts and Settings\t_fl01\.maven\cache\cactus-maven-1.7dev\plugin-resources/jbo
ss3x"><include if="cactus.home.jboss3x" name="jboss-web.xml"></include></webinf>
<lib file=""></lib></cactifywar>
cactus:test-war:
<cactus fork="yes" failureproperty="cactustests.failure" warfile="s:\components\
components\configmanager/target/configmanager-cactus.war" printsummary="withOutA
ndErr" errorproperty="cactustests.error"><classpath><pathelement path="s:\compon
ents\components\configmanager/target/classes"></pathelement><pathelement locatio
n="s:\components\components\configmanager/target/test-cactus-classes"></pathelem
ent></classpath><containerset><jboss3x config="default" output="s:\components\co
mponents\configmanager/target/test-cactus-reports/jboss3x.out" tmpdir="d:\jboss-
3.0.8_tomcat-4.0.6/server/cactus" if="cactus.home.jboss3x" todir="s:\components\
components\configmanager/target/test-cactus-reports/jboss3x" port="8080" dir="d:
\jboss-3.0.8_tomcat-4.0.6"></jboss3x><orion1x output="s:\components\components\c
onfigmanager/target/test-cactus-reports/orion1x.out" if="cactus.home.orion1x" to
dir="s:\components\components\configmanager/target/test-cactus-reports/orion1x"
port="8080" dir=""></orion1x><orion2x output="s:\components\components\configman
ager/target/test-cactus-reports/orion2x.out" if="cactus.home.orion2x" todir="s:\
components\components\configmanager/target/test-cactus-reports/orion2x" port="80
80" dir=""></orion2x><resin2x output="s:\components\components\configmanager/tar
get/test-cactus-reports/resin2x.out" if="cactus.home.resin2x" todir="s:\componen
ts\components\configmanager/target/test-cactus-reports/resin2x" port="8080" dir=
""></resin2x><resin3x output="s:\components\components\configmanager/target/test
-cactus-reports/resin3x.out" if="cactus.home.resin3x" todir="s:\components\compo
nents\configmanager/target/test-cactus-reports/resin3x" port="8080" dir=""></res
in3x><tomcat4x output="s:\components\components\configmanager/target/test-cactus
-reports/tomcat4x.out" if="cactus.home.tomcat4x" todir="s:\components\components
\configmanager/target/test-cactus-reports/tomcat4x" port="8080" dir=""></tomcat4
x><tomcat5x output="s:\components\components\configmanager/target/test-cactus-re
ports/tomcat5x.out" if="cactus.home.tomcat5x" todir="s:\components\components\co
nfigmanager/target/test-cactus-reports/tomcat5x" port="8080" dir=""></tomcat5x><
weblogic7x output="s:\components\components\configmanager/target/test-cactus-rep
orts/weblogic7x.out" if="cactus.home.weblogic7x" todir="s:\components\components
\configmanager/target/test-cactus-reports/weblogic7x" port="8080" dir=""></weblo
gic7x></containerset><formatter usefile="false" type="plain"></formatter><format
ter type="xml"></formatter> [test] [ERROR] Could not find org.apache.testlet.
engine.TextTestEngine. Make sure you have it in your classpath
</cactus>

It might be an issue in my cactus version (which I generated from CVS), but it works fine if I use the old maven.jar.

– Felipe

Felipe

I observed a side effect of the patch, I'm not sure it's the one that causes the bug on cactus but this one will probably requires a look and/or some changes in the plugins :

in a script we are getting a dependency of type zip, and we were accessing it with a :

<j:set var="fooVar" value="${pom.getDependency('fooGroup:barName')}"/>

(dependency of group "fooGroup" and of name "barName")

with the patch, this leads to an empty dependency, so the code is now :

<j:set var="fooVar" value="${pom.getDependency('fooGroup:barName:zip')}"/>

hope this may help

I appreciate the hints, but given Carlos' claim that this will never make it into the main source code I'm not going to invest more time into this patch (or fixes to other components exposed by this patch). If I get any indication of a change of heart, I'll work on it.

done in new model, verified

In which model, for Maven 1.1 or M2?

both

need to think this through a bit more.
previously 'touchstone:test' resolved to 'touchstone:test:war' if it was the other type. Now it is either indeterminate if there are multiple, or it must assume a default of jar. Need to implement this differently - but for now if type is not specified, jar is assumed in getDependencyPath. This may be an acceptable breakage, but must be documented.

This is a very well know bug/limitation of Maven 1.0