[jira] (MNG-4999) Maven should fail the build or give a warning when there are cyclic dependencies
[ https://jira.codehaus.org/browse/MNG-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322338#comment-322338 ] Rich Seddon commented on MNG-4999: -- I think it may be possible to close this now, this seems to do the job: http://mojo.codehaus.org/extra-enforcer-rules/banCircularDependencies.html > Maven should fail the build or give a warning when there are cyclic > dependencies > > > Key: MNG-4999 > URL: https://jira.codehaus.org/browse/MNG-4999 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Affects Versions: 2.2.1, 3.0.2 > Environment: any >Reporter: Phillip Hellewell > > Maven gives no warning or error when there are cyclic dependencies. It > should give at least a warning, and have the ability to fail the build > through an option. > How to reproduce: > 1. Make B that doesn't depend on anything. Deploy a snapshot of B. > 2. Make A that depends on the snapshot of B . Deploy a snapshot of A. > 3. Change B to depend on the snapshot of A. Now deploy a new snapshot of B > (same version as in step 1). > I would venture to say that the perc. of people who actually want to allow > cycles is smaller than the percentage who want to catch it as an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-408) Can't generate quickstart archetype from internal catalog using archetype plugin 2.2 and Maven 2.2.1
Rich Seddon created ARCHETYPE-408:
-
Summary: Can't generate quickstart archetype from internal catalog
using archetype plugin 2.2 and Maven 2.2.1
Key: ARCHETYPE-408
URL: https://jira.codehaus.org/browse/ARCHETYPE-408
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.2
Reporter: Rich Seddon
Using Maven 2.2.1, I attempted to generate a quickstart project from the
archetype as follows:
mvn org.apache.maven.plugins:maven-archetype-plugin:2.2:generate
-DarchetypeCatalog=internal
This fails (see below). The same command works with Maven 3.0.4. If I change
the maven-archetype-plugin version to 2.1 it also works using Maven 2.2.1.
{noformat}
[INFO] Preparing archetype:generate
[INFO] No goals needed for project - skipping
[INFO] [archetype:generate {execution: default-cli}]
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart
(org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: internal -> org.appfuse.archetypes:appfuse-basic-jsf (AppFuse archetype for
creating a web application with Hibernate, Spring and JSF)
2: internal -> org.appfuse.archetypes:appfuse-basic-spring (AppFuse archetype
for creating a web application with Hibernate, Spring and Spring MVC)
3: internal -> org.appfuse.archetypes:appfuse-basic-struts (AppFuse archetype
for creating a web application with Hibernate, Spring and Struts 2)
4: internal -> org.appfuse.archetypes:appfuse-basic-tapestry (AppFuse archetype
for creating a web application with Hibernate, Spring and Tapestry 4)
5: internal -> org.appfuse.archetypes:appfuse-core (AppFuse archetype for
creating a jar application with Hibernate and Spring and XFire)
6: internal -> org.appfuse.archetypes:appfuse-modular-jsf (AppFuse archetype
for creating a modular application with Hibernate, Spring and JSF)
7: internal -> org.appfuse.archetypes:appfuse-modular-spring (AppFuse archetype
for creating a modular application with Hibernate, Spring and Spring MVC)
8: internal -> org.appfuse.archetypes:appfuse-modular-struts (AppFuse archetype
for creating a modular application with Hibernate, Spring and Struts 2)
9: internal -> org.appfuse.archetypes:appfuse-modular-tapestry (AppFuse
archetype for creating a modular application with Hibernate, Spring and
Tapestry 4)
10: internal -> org.makumba:makumba-archetype (Archetype for a simple Makumba
application)
11: internal -> org.apache.maven.archetypes:maven-archetype-j2ee-simple (A
simple J2EE Java application)
12: internal -> org.apache.maven.archetypes:maven-archetype-marmalade-mojo (A
Maven plugin development project using marmalade)
13: internal -> org.apache.maven.archetypes:maven-archetype-mojo (A Maven Java
plugin development project)
14: internal -> org.apache.maven.archetypes:maven-archetype-portlet (A simple
portlet application)
15: internal -> org.apache.maven.archetypes:maven-archetype-profiles ()
16: internal -> org.apache.maven.archetypes:maven-archetype-quickstart ()
17: internal -> org.apache.maven.archetypes:maven-archetype-site-simple (A
simple site generation project)
18: internal -> org.apache.maven.archetypes:maven-archetype-site (A more
complex site project)
19: internal -> org.apache.maven.archetypes:maven-archetype-webapp (A simple
Java web application)
20: internal -> net.databinder:data-app (A new Databinder application with
sources and resources.)
21: internal -> org.apache.camel.archetypes:camel-archetype-component (Creates
a new Camel component)
22: internal -> org.apache.camel.archetypes:camel-archetype-activemq (Creates a
new Camel project that configures and interacts with ActiveMQ)
23: internal -> org.apache.camel.archetypes:camel-archetype-java (Creates a new
Camel project using Java DSL)
24: internal -> org.apache.camel.archetypes:camel-archetype-scala (Creates a
new Camel project using Scala DSL)
25: internal -> org.apache.camel.archetypes:camel-archetype-spring (Creates a
new Camel project with added Spring DSL support)
26: internal -> org.apache.camel.archetypes:camel-archetype-war (Creates a new
Camel project that deploys the Camel Web Console, REST API, and your routes as
a WAR)
27: internal -> org.jini.maven-jini-plugin:jini-service-archetype (Archetype
for Jini service project creation)
28: internal -> de.akquinet.jbosscc:jbosscc-seam-archetype (Maven Archetype to
generate a Seam Application- Documentation)
29: internal -> org.apache.maven.archetypes:softeu-archetype-seam
(JSF+Facelets+Seam Archetype)
30: internal -> org.apache.maven.archetypes:softeu-archetype-seam-simple
(JSF+Facelets+Seam (no persistence) Archetype)
31: internal -> org.apache.maven.archetypes:softeu-archetype-jsf (JSF+Facelets
Archetype)
32: internal -> com.rfc.maven.archetypes:jpa-maven-archetype (JPA application)
33: internal -> org.springframework.osgi:spr
[jira] (MJAR-153) Missing continuation characters in Export-Package field
Rich Seddon created MJAR-153:
Summary: Missing continuation characters in Export-Package field
Key: MJAR-153
URL: https://jira.codehaus.org/browse/MJAR-153
Project: Maven 2.x JAR Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Linux, Maven 3.0.4
Reporter: Rich Seddon
Attachments: pom.xml
The following plugin configuration results in an "Export-Package" field which
has two problems. First, every other line has "CR" instead of just "CRLF'.
Second, every other line is missing the continuation character. This latter
problem results in an invalid header exception when the jar is opened by Java.
{code:XML}
maven-jar-plugin
2.4
a.test.of.maven-jar-plugin
2
org.jboss.weld.osgi-bundle
org.jboss.weld.literal,
org.jboss.weld.logging,
org.jboss.weld.logging.messages,
org.jboss.metadata.validation,
org.jboss.weld.bean.interceptor,
org.jboss.weld.metadata,
org.jboss.weld.metadata.cache,
org.jboss.weld.resources,
org.jboss.weld.test,
org.jboss.weld.tests,
org.jboss.weld.tests.extensions,
org.jboss.weld.tests.extensions.injectionTarget,
org.jboss.weld.exceptions,
a.test.of.maven-jar-plugin
{code}
Here's the manifest contents:
{noformat}
Manifest-Version: 1.0^M
Export-Package: org.jboss.weld.literal,
org.jboss.weld.logging,
org.jb^M
oss.weld.logging.messages,
org.jboss.metadata.validation,
org.jboss.w^M
eld.bean.interceptor,
org.jboss.weld.metadata,
org.jboss.weld.metadat^M
a.cache,
org.jboss.weld.resources,
org.jboss.weld.test,
org.jboss.wel^M
d.tests,
org.jboss.weld.tests.extensions,
org.jboss.weld.tests.extens^M
ions.injectionTarget,
org.jboss.weld.exceptions,^M
Fragment-Host: org.jboss.weld.osgi-bundle^M
Built-By: rseddon^M
Build-Jdk: 1.6.0_29^M
Bundle-ManifestVersion: 2^M
Created-By: Apache Maven^M
Bundle-Description: a.test.of.maven-jar-plugin^M
Bundle-SymbolicName: a.test.of.maven-jar-plugin^M
Archiver-Version: Plexus Archiver^M
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-720) release:stage doesn't run site lifecycle, which means you (typically) need to override goals to make it work
Rich Seddon created MRELEASE-720: Summary: release:stage doesn't run site lifecycle, which means you (typically) need to override goals to make it work Key: MRELEASE-720 URL: https://jira.codehaus.org/browse/MRELEASE-720 Project: Maven 2.x Release Plugin Issue Type: Bug Components: stage Affects Versions: 2.2.1 Reporter: Rich Seddon Priority: Minor release:perform runs "deploy site-deploy", so the whole site lifecycle is run. release:stage runs "deploy site:stage-deploy". This means this doesn't work out of the box, since "site:site" isn't run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-220) Unable to access remote catalogs on HTTPS protocol, even with redirection
[ https://jira.codehaus.org/browse/ARCHETYPE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276814#comment-276814 ] Rich Seddon commented on ARCHETYPE-220: --- Agreed that the need to properly handle authentication is necessary for https sometimes, but there are a lot of times when it isn't needed. Many public repositories nowadays which serve unauthenticated content over https, some examples: https://repository.jboss.org/nexus/content/groups/developer/archetype-catalog.xml https://maven.atlassian.com/content/groups/public/archetype-catalog.xml https://repository.sonatype.org/content/groups/forge/archetype-catalog.xml This is also an extremely common setup for repository managers in corporate environments. > Unable to access remote catalogs on HTTPS protocol, even with redirection > - > > Key: ARCHETYPE-220 > URL: https://jira.codehaus.org/browse/ARCHETYPE-220 > Project: Maven Archetype > Issue Type: Bug > Components: Generator >Affects Versions: 2.0-alpha-4 > Environment: Any (Windows, Linux) >Reporter: Josep F. Barranco >Priority: Minor > Attachments: https.patch, > org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch > > > I use that test: > 1 - Create an "archetype-catalog.xml" and set it on your apache "htdocs" > directory >Executing "mvn archetype:generate -DarchetypeCatalog=http://localhost"; > works fine. > 2 - Configure your apache to use certificates and allow SSL (port 443) to > access to same archetype catalog file >Executing "mvn archetype:generate -DarchetypeCatalog=https://localhost"; > does not work. (it shows default catalog) >It seems that stating with "https://"; does not match with allowed > parameter values (local, internal, file:, http:) > 3 - Anyway, try to redirect your working HTTP access to HTTPS (configure > rewrite engine on Apache) as workaround to access you SSL catalog. >Executing "mvn archetype:generate -DarchetypeCatalog=http://localhost"; > (same as step 1) IS NOT WORKING!!! (it shows empty catalog) > There's no way to access an archetype-catalog.xml located on a SSL url ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPH-70) Maven Help Plugin prints an Exception Stack Trace: NoSuchMethodError on execution
[
http://jira.codehaus.org/browse/MPH-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=212831#action_212831
]
Rich Seddon commented on MPH-70:
FWIW, I just hit this on one of my machines.
I haven't had a chance to investigate (will try to do that later), but I will
can confirm that using a clean local repository fixes the issue.
> Maven Help Plugin prints an Exception Stack Trace: NoSuchMethodError on
> execution
> -
>
> Key: MPH-70
> URL: http://jira.codehaus.org/browse/MPH-70
> Project: Maven 2.x Help Plugin
> Issue Type: Bug
>Reporter: Tim O'Brien
>Assignee: Benjamin Bentmann
>
> I just tried to run the Help plugin
> Here is my Maven version info:
> Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
> Java version: 1.6.0_15
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.1" arch: "x86_64" Family: "mac"
> Here is the error output:
> ~/book$ mvn help:describe -Dplugin=scm -e
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Maven: The Definitive Guide Example Code
> [INFO] Maven: The Definitive Guide (Parent Project)
> [INFO] Maven: The Definitive Guide (XML, HTML, PDF, and Site)
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [INFO] Building Maven: The Definitive Guide (Parent Project)
> [INFO]task-segment: [help:describe] (aggregator-style)
> [INFO]
>
> [INFO] [help:describe {execution: default-cli}]
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] NoSuchMethodException:
> org.apache.maven.plugins.help.HelpMojo.toLines(java.lang.String, int, int,
> int)
> [INFO]
>
> [INFO] Trace
> org.apache.maven.BuildFailureException: NoSuchMethodException:
> org.apache.maven.plugins.help.HelpMojo.toLines(java.lang.String, int, int,
> int)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoFailureException:
> NoSuchMethodException:
> org.apache.maven.plugins.help.HelpMojo.toLines(java.lang.String, int, int,
> int)
> at
> org.apache.maven.plugins.help.DescribeMojo.toLines(DescribeMojo.java:930)
> at
> org.apache.maven.plugins.help.DescribeMojo.append(DescribeMojo.java:969)
> at
> org.apache.maven.plugins.help.DescribeMojo.describePlugin(DescribeMojo.java:515)
> at
> org.apache.maven.plugins.help.DescribeMojo.execute(DescribeMojo.java:268)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly conta
[jira] Created: (MNG-4435) Maven uses artifact download credentials during deployment in some circumstances
Maven uses artifact download credentials during deployment in some circumstances Key: MNG-4435 URL: http://jira.codehaus.org/browse/MNG-4435 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.2.1 Reporter: Rich Seddon If Maven downloads an artifact using authorization, this authorization seems to be cached, which can cause a subsequent deployment to succeed where it should have failed. Steps to reproduce: # Set up a build which will require downloading an artifact from a Nexus server which requires authentication, and configure your settings.xml appropriately. # Create a project with a distribution management section which points to a repository in the above server. Make sure the repository id doesn't exist in your settings.xml # Run "mvn deploy" What happens: If the credentials used to download artifacts from Nexus have deployment privileges in the Nexus repository the deployment will succeed. Now run "mvn deploy" again. This time the deployment will fail with a 401 code. This bug exists in both Maven 2.2.1 and the latest Maven 3.0 snapshots. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4309) Checksum validation doesn't fail the build for repository metadata files
Checksum validation doesn't fail the build for repository metadata files
Key: MNG-4309
URL: http://jira.codehaus.org/browse/MNG-4309
Project: Maven 2
Issue Type: Bug
Components: Deployment
Affects Versions: 2.2.1
Reporter: Rich Seddon
I have a repository which has invalid checksums for some of it's
maven-metadata.xml files.
When building with "-C" I get a warning, but the build still succeeds
{code}
mvn -C deploy
+ Enabling strict checksum verification on all artifact downloads.
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - test:project_a:jar:2.0.2-SNAPSHOT
[INFO]task-segment: [deploy]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/Users/rseddon/test/foo/project_a/src/main/resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/Users/rseddon/test/foo/project_a/src/test/resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] No tests to run.
[INFO] [jar:jar {execution: default-jar}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/Users/rseddon/test/foo/project_a/target/project_a-2.0.2-SNAPSHOT.jar to
/Users/rseddon/.m2/repository/test/project_a/2.0.2-SNAPSHOT/project_a-2.0.2-SNAPSHOT.jar
[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from foo
Uploading:
http://localhost:8081/nexus/content/repositories/snapshots//test/project_a/2.0.2-SNAPSHOT/project_a-2.0.2-20090817.175509-6.jar
1K uploaded (project_a-2.0.2-20090817.175509-6.jar)
[INFO] Retrieving previous metadata from foo
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'1fee9c8f59bbb8457c230db81681cf98d90683d1'; remote =
'07f4f4f5cc59ff10b1f71328abe8f61f6e56bdc0' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'1fee9c8f59bbb8457c230db81681cf98d90683d1'; remote =
'07f4f4f5cc59ff10b1f71328abe8f61f6e56bdc0' - IGNORING
[INFO] Uploading repository metadata for: 'artifact test:project_a'
[INFO] Retrieving previous metadata from foo
[INFO] Uploading repository metadata for: 'snapshot
test:project_a:2.0.2-SNAPSHOT'
[INFO] Uploading project information for project_a 2.0.2-20090817.175509-6
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Mon Aug 17 10:55:09 PDT 2009
[INFO] Final Memory: 9M/19M
[INFO]
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4303) Maven doesn't seem to be detecting checksum failures for snapshot artifacts.
[ http://jira.codehaus.org/browse/MNG-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Seddon closed MNG-4303. Resolution: Fixed closing, forgot to clear local repo > Maven doesn't seem to be detecting checksum failures for snapshot artifacts. > > > Key: MNG-4303 > URL: http://jira.codehaus.org/browse/MNG-4303 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Rich Seddon > > I'm seeing what looks to be a bug in maven. > I have a snapshot repo with one snapshot jar artifact. > I run "mvn install" for a project which has this as a dependency. > Now the local repo has this snapshot cached. > Next I deploy a 2nd snapshot, but this time I corrupt the jar on the server > so checksums don't match. > If I run "mvn -C -U install", the build succeeds, no warnings are issued. > Furthermore, at this point both snapshots are in my local repo, but it turns > out that the size of the 2nd snapshot is identical to the eize of the first > one, even though the jar sizes are different on the server. > If I clear my local repo and run "mvn -U -C install" the build fails with a > checksum error, as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4303) Maven doesn't seem to be detecting checksum failures for snapshot artifacts.
Maven doesn't seem to be detecting checksum failures for snapshot artifacts. Key: MNG-4303 URL: http://jira.codehaus.org/browse/MNG-4303 Project: Maven 2 Issue Type: Bug Affects Versions: 2.2.1 Reporter: Rich Seddon I'm seeing what looks to be a bug in maven. I have a snapshot repo with one snapshot jar artifact. I run "mvn install" for a project which has this as a dependency. Now the local repo has this snapshot cached. Next I deploy a 2nd snapshot, but this time I corrupt the jar on the server so checksums don't match. If I run "mvn -C -U install", the build succeeds, no warnings are issued. Furthermore, at this point both snapshots are in my local repo, but it turns out that the size of the 2nd snapshot is identical to the eize of the first one, even though the jar sizes are different on the server. If I clear my local repo and run "mvn -U -C install" the build fails with a checksum error, as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
