You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Sahoo <Sa...@Sun.COM> on 2008/10/18 07:08:23 UTC
maven 2.0.7 reorders dependencies during build causing compilation
failures
I just don't believe what I am seeing. Despite adding a particular
dependency directly in my pom.xml, maven reorders dependencies and hence
we get compilation failure. e.g., take a look at the pom.xml available
at [1]. It declares a direct dependency on
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.servlet</artifactId>
<version>${project.version}</version>
</dependency>
This is the first dependency in the dependencies section.
Yet, during compilation, the dependencies have been reordered and here
is the actual order used by maven:
[DEBUG] Classpath:
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-glue/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/common/glassfish-naming/3.0-SNAPSHOT/glassfish-naming-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/distributions/external/ldapbp/target/ldapbp-repackaged-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/com/sun/enterprise/hk2-core/0.3.34/hk2-core-0.3.34.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/connectors/javax.resource/target/javax.resource-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/com/sun/enterprise/tiger-types-osgi/0.3.34/tiger-types-osgi-0.3.34.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/common/container-common/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/deployment/javaee-core/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-naming/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/persistence/javax.persistence/target/javax.persistence-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/common/glassfish-api/10.0.422/glassfish-api-10.0.422.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/javax/servlet/jsp/jsp-api/2.1/jsp-api-2.1.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/distributions/external/grizzly-optionals/target/grizzly-optionals-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/deployment/dol/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/security/securitycommon/3.0-SNAPSHOT/securitycommon-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/com/sun/enterprise/config/0.3.34/config-0.3.34.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/external/ant/10.0-SNAPSHOT/ant-10.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/com/sun/enterprise/hk2/0.3.34/hk2-0.3.34.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/common/common-util/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/distributions/external/apache-commons/target/apache-commons-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/gui-plugin-common/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/common/amx-api/3.0-SNAPSHOT/amx-api-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/javaee-api/javax.servlet.jsp/target/javax.servlet.jsp-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/com/sun/enterprise/auto-depends/0.3.34/auto-depends-0.3.34.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/war-util/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/com/sun/pkg/pkg-client/1.0.7-15.1269/pkg-client-1.0.7-15.1269.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/admin/monitor/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/admin/config-api/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/admin/util/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/deployment/javax.enterprise.deploy/target/javax.enterprise.deploy-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/deployment/common/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/common/stats77/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/admin/admin-core/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/osgi/osgi_R4_core/1.0/osgi_R4_core-1.0.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/flashlight/flashlight-agent/3.0-SNAPSHOT/flashlight-agent-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/transaction/javax.transaction/target/javax.transaction-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/connectors/connectors-internal-api/3.0-SNAPSHOT/connectors-internal-api-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/web/jsp-impl/2.1-SNAPSHOT/jsp-impl-2.1-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/common/annotation-framework/3.0-SNAPSHOT/annotation-framework-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/web/el-impl/1.1/el-impl-1.1.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/admin/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/transaction/internal-api/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/common/internal-api/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/javax.servlet/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/security/realms/3.0-SNAPSHOT/realms-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/flashlight/framework/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/distributions/external/asm-all/target/asm-all-repackaged-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-core/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/admin/cli-framework/3.0-SNAPSHOT/cli-framework-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/javaee-api/javax.mail/target/javax.mail-3.0-SNAPSHOT.jar
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/distributions/external/grizzly-http/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/core/kernel/target/classes
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/javaee-api/javax.annotation/target/javax.annotation-3.0-SNAPSHOT.jar
[DEBUG] Source roots:
[DEBUG] http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-glue/src/main/java
[INFO] Compiling 130 source files to http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-glue/target/classes
Note: http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-glue/src/main/java/com/sun/enterprise/web/WebComponentInvocation.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-glue/src/main/java/com/sun/enterprise/web/pwc/connector/coyote/PwcCoyoteRequest.java :146: cannot find symbol
symbol : method getSessionCookieConfig()
location: interface javax.servlet.ServletContext
(servletContext.getSessionCookieConfig()!=null)) {
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Fatal error compiling
Is this not a bug?
Thanks,
Sahoo
[1]
http://fisheye4.atlassian.com/browse/glassfish-svn/trunk/v3/web/web-glue/pom.xml?r=23482
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 2.0.7 reorders dependencies during build causing compilation
failures
Posted by Sahoo <Sa...@Sun.COM>.
Yes, I have and I don't see any problem. It is impossible to enforce
every artifact in the transitive closure depends on same version of an
artifact. Different artifacts evolve at different pace, while some may
have a dependency on lower versions, some may require higher versions.
It's not just about different versions of same artifact, sometimes
different artifacts may have same classes in them and you may like to
use classes from a particular artifact because that contains the correct
version of classes you are looking for.
More over, we (in GlassFish project) use OSGi, so when someone takes our
artifact, they can always inspect all its dependencies and ensure they
are met in their environment. If they don't ensure, they will get a nice
message that will tell them that desired version of a package is not
available.
I hope you are not defending the unpredictable behavior of maven version
< 2.0.9.
Michael McCallum wrote:
> did you ever think that something is seriously wrong if the classpath ordering
> causes your build to fail?
>
> That could mean that sometime somewher someone will deploy your application
> and use a different order for the jars and it just won't run and the poor
> developer/ops person will have no idea...
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: maven 2.0.7 reorders dependencies during build causing
compilation failures
Posted by Martin Gainty <mg...@hotmail.com>.
Michael is expressing the bane of every developer
no jar in classpath
wrong version of jar in classpath
if you can forward any details as to the web-application-server (WebLogic/JBoss/Webspeher) you are implementing with so we can get this corner-case figured out..
thanks,
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> From: gholam@apache.org
> To: users@maven.apache.org
> Subject: Re: maven 2.0.7 reorders dependencies during build causing compilation failures
> Date: Sun, 19 Oct 2008 22:27:39 +1300
>
> did you ever think that something is seriously wrong if the classpath ordering
> causes your build to fail?
>
> That could mean that sometime somewher someone will deploy your application
> and use a different order for the jars and it just won't run and the poor
> developer/ops person will have no idea...
>
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
_________________________________________________________________
When your life is on the go—take your life with you.
http://clk.atdmt.com/MRT/go/115298558/direct/01/
Re: maven 2.0.7 reorders dependencies during build causing compilation failures
Posted by Michael McCallum <gh...@apache.org>.
did you ever think that something is seriously wrong if the classpath ordering
causes your build to fail?
That could mean that sometime somewher someone will deploy your application
and use a different order for the jars and it just won't run and the poor
developer/ops person will have no idea...
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 2.0.7 reorders dependencies during build causing compilation failures
Posted by Jörg Schaible <jo...@gmx.de>.
Sahoo wrote:
> Barrie Treloar wrote:
>> On Sat, Oct 18, 2008 at 3:38 PM, Sahoo <Sa...@sun.com> wrote:
>>
>>> I just don't believe what I am seeing. Despite adding a particular
>>> dependency directly in my pom.xml, maven reorders dependencies and hence
>>> we get compilation failure. e.g., take a look at the pom.xml available
>>> at [1]. It declares a direct dependency on
>>> <dependency>
>>> <groupId>org.glassfish</groupId>
>>> <artifactId>javax.servlet</artifactId>
>>> <version>${project.version}</version>
>>> </dependency>
>>>
>>
>> Yes.
>>
>> Use 2.0.9
>>
>> Dependencies were just HashMaps previously hence the order is random.
>> The dependency order is preserved in 2.0.9 but I cant remember what
>> ordering it used.
>>
> Sorry to ask again. Was the dependency order random in all versions
> previous to 2.0.9? I was under the impression that such was the case
> only in 2.0.8.
No, it has always been so before :-/
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 2.0.7 reorders dependencies during build causing compilation
failures
Posted by Sahoo <Sa...@Sun.COM>.
Barrie Treloar wrote:
> On Sat, Oct 18, 2008 at 3:38 PM, Sahoo <Sa...@sun.com> wrote:
>
>> I just don't believe what I am seeing. Despite adding a particular
>> dependency directly in my pom.xml, maven reorders dependencies and hence we
>> get compilation failure. e.g., take a look at the pom.xml available at [1].
>> It declares a direct dependency on
>> <dependency>
>> <groupId>org.glassfish</groupId>
>> <artifactId>javax.servlet</artifactId>
>> <version>${project.version}</version>
>> </dependency>
>>
>
> Yes.
>
> Use 2.0.9
>
> Dependencies were just HashMaps previously hence the order is random.
> The dependency order is preserved in 2.0.9 but I cant remember what
> ordering it used.
>
Sorry to ask again. Was the dependency order random in all versions
previous to 2.0.9? I was under the impression that such was the case
only in 2.0.8.
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 2.0.7 reorders dependencies during build causing compilation failures
Posted by Barrie Treloar <ba...@gmail.com>.
On Sat, Oct 18, 2008 at 3:38 PM, Sahoo <Sa...@sun.com> wrote:
> I just don't believe what I am seeing. Despite adding a particular
> dependency directly in my pom.xml, maven reorders dependencies and hence we
> get compilation failure. e.g., take a look at the pom.xml available at [1].
> It declares a direct dependency on
> <dependency>
> <groupId>org.glassfish</groupId>
> <artifactId>javax.servlet</artifactId>
> <version>${project.version}</version>
> </dependency>
Yes.
Use 2.0.9
Dependencies were just HashMaps previously hence the order is random.
The dependency order is preserved in 2.0.9 but I cant remember what
ordering it used.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org