I'm part way through resolving the issue with the '301 Moved Permanently' that has been plaguing us since around June 20th and I thought it worth updating the community and perhaps get other thoughts on the solution.
I'm still not sure what has happened since around June 20th or slightly before, but I suspect there was some type of change in behavior at sourceforce-snapshots that has surfaced this issue. The basic issue appears to be that the ant maven task (see mvn task at http://maven.apache.org/ant-tasks/index.html) operates differently than running maven at the command-line. If I run maven from the command line, all artifacts are downloaded from maven central and it works. When ant kicks off the maven build using its ant maven task, it operates differently. If a fetched artifact's pom file contains a <repositories> element, then the ant maven task will exclusively use that repository and won't try to use maven central. One case that affects us is with a dependency upon ehcache-web in the resource manager. ehcache-web's pom.xml has a <repositories> element specifying sourceforce-snapshots ( http://search.maven.org/remotecontent?filepath=net/sf/ehcache/ehcache-web/2.0.4/ehcache-web-2.0.4.pom). When the ant maven task attempts to get ehcache-web-parent, it ONLY looks in sourceforce-snapshots (which fails) and does not look in maven central. I have written this issue up as http://jira.codehaus.org/browse/MANTTASKS-246. Workaround 1. previously mentined work-around was not entirely correct. All you have to do is remove the affected pom.xml files and run mvn from the command-line in the uportal-war directory. You don't need to specify a wagon provider. Though you can also manually download the affected pom files from maven central and replace the corrupted ones in your local .m2/repository repo, this is not a good approach. You'll have several bad poms in your repo because a number of poms are downloaded and fail, but don't fail the build for some reason. Solution I'm looking at resolving the issue in the short term by one of several approaches: 1. Alter the build.xml to use ant's exec task to shell off and run maven just like we do from the command line. I verified this works and is the solution I am going to implement. Unfortunately we have to take into account OS differences. other approaches that might work: 2. Specifying repositories in the maven ant task. I don't think this would be transparent for institutions that specify a mirror. I see indications that mirrors (and other items in your settings.xml) are ignored in this dependency resolution process, though practically it is for these transitive dependencies so it may not make much of a difference in practice. 3. Replacing the affected pom.xml files in maven central with versions without a <respositories> element. Though not likely to be difficult, it would be more time consuming. 4. altering the behavior of the maven ant task (we can build it and replace the one at bootstrap/lib). Most difficult. I've seen multiple maven issues for similar behavior so I suspect this is not a straight forward process. Better long-term solution 5. Replace the ant/maven build process with Gradle. I'd love to do this, but it will take more time than we have right now. I'd like to couple this with changes to allow us to build a single artifact that can be promoted through environments (e.g. pick up all environment-specific properties at run-time from external location and not rely on the build process to substitute values at build time). If anyone has any thoughts to contribute to the solution, let me know. Thanks, -- James Wennmacher - Unicon 480.558.2420 -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
