`
xinklabi
  • 浏览: 1588073 次
  • 性别: Icon_minigender_1
  • 来自: 吉林
文章分类
社区版块
存档分类
最新评论

Sonatype Nexus以war包形式部署时始终报错,最后由此文章发现线索得以解决(还得靠google啊)

 
阅读更多

这两天以在tomcat上部署war包的形式跑nexus,总是报错,在自己机器上安装JDK7都不行,但在别人的机器上就可以运行(我后来安装和他们一模一样的JDK,但也不行),他们有的是JDK1.6的跑nexus-2.4.war都没问题。我开始怀疑是不是我安装了两套JDK影响的,因为在两个仅安装一个JDK的(并且从未卸载过)同事机器上跑是没问题,而我和另一个同事安装过两个JDK的都报同样的错误,但是在还有一个同事机器上安装两套JDK却没问题。折腾蒙了,最后在google上搜索异常,找到了这篇英文文章,从他发现是nexus工作目录sonatype-work问题找到灵感。于是搜了一下如何修改war包中nexus的sonatype-work,在解压的war包中修改nexus-2.4\WEB-INF目录下的plexus.properties文件,将里面nexus-work对应的值改掉,放在tomcat中,启动,成功!

 

修改sonatype-work目录的方法如下:

最近搭建Maven本地私服,下载了内置Jetty的Nexus,发现按照网上介绍的方法尝试迁移Nexus的工作目录,发现有时有效,有时又无效,经过一下午的研究后,最终确定下面的解决方案。。

 

一、如果下载的是WAR包版,请修改:

%Nexus_HOME%/conf/nexus.properties

nexus-work=${bundleBasedir}/../../sonatype-work/nexus

 

二、如果下载的是内置Jetty版,请修改:

1、start-nexus方式启动

%Nexus_HOME%/conf/nexus.properties

nexus-work=${bundleBasedir}/../../sonatype-work/nexus

 

2、console-nexus方式启动

直接添加环境变量PLEXUS_NEXUS_WORK

 

建议:如果不建议有一个dos窗口的话,添加环境变量后,每次使用console-nexus的方式启动,好处是每次升级Nexus后不用修改配置文件。

 

 

 

Update, 26-02: Brian Demers from Sonatype pointed out in the comments that Maven 2.0.10 and later are forwards-compatible with changes in the metadata format. If your Maven 2 version is one of the recommended versions on the download page, you will not have this problem.

Two days, in fact. Yesterday evening, after my colleagues went home, I brought down our Nexus 1.8.0.1 instance to upgrade it to 1.9 without interrupting their work. The download page for Nexus 1.9 contains the following instruction:

Sonatype has changed how the lucene indexes are stored on disk, it is required that users reindex all repositories in their nexus server to start benefitting from the changes (and for search to work properly).

Inconspicuous enough. Furthermore, clicking through from the change overview to the full change log reveals:

[NEXUS-3849] – Add full support for the new maven 3 snapshot metadata

What it doesn’t reveal is that the rebuild metadata command in the repository administration screen, which would appear to be proper housekeeping at a time when you’re reindexing the repositories, now generates Maven 3 style metadata and inadvertently breaks compatibility with Maven 2 (update: older versions). This is where the fun begins.

 

The fun

Having upgraded Nexus to 1.9 and having rebuilt metadata en reindexed repositories, my Jenkins builds started failing:

1
2
3
4
5
6
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error retrieving previous build number for artifact 'myGroup:myArtifact:pom': Cannot read metadata from \
    '/home/maven/maven-repository/myGroup/myArtifact/1.8.0-SNAPSHOT/maven-metadata-nexus-snapshots.xml': \
    expected START_TAG or END_TAG not TEXT (position: TEXT seen ...<extension>pom</... @14:25)

Wouldn’t you know it, Maven 2 builds cannot handle the new metadata format.

(I feel it’s worth mentioning that when Jenkins releases a new version, everything Just Works ™. They have their act together in a fantastic way.)

Attempted fix: downgrade Nexus

My previous Nexus version is still on the file system. To downgrade, all I had to do is stop Nexus, revert symlink, start Nexus.

1
2
jvm 1    | 2011-02-24 18:30:28 ERROR [er_start_runner] - o.s.n.DefaultNexus            - Could not start Nexus, user configuration exception!
jvm 1    | org.sonatype.configuration.upgrade.UnsupportedConfigurationVersionException: Unsupported configuration file in /home/maven/nexus-oss-webapp-1.8.0.1/./../sonatype-work/nexus/conf/nexus.xml with version: 1.4.4. Cannot upgrade.

Oh crap. Well at least the error message is perfectly clear. Even better, there turns out to be a nexus.xml.bak in the conf directory. For the first time that evening, I mutter something vaguely grateful about Sonatype. Now, let me just copy the entire conf directory to a safe location, restore that backup config file and try again.

1
2
jvm 1    | 2011-02-24 18:39:21 INFO  [er_start_runner] - o.s.n.c.a.DefaultNe~          - Loading Nexus Configuration...
jvm 1    | 2011-02-24 18:39:21 INFO  [er_start_runner] - o.s.n.c.s.StaticCon~          - Configuration loaded succesfully.

…so far so good…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
jvm 1    | 2011-02-24 18:39:22 ERROR [er_start_runner] - o.s.g.b.r.NamedClass          - Error injecting: org.sonatype.nexus.DefaultNexus
jvm 1    | com.google.inject.ProvisionException: Guice provision errors:
jvm 1    |
jvm 1    | 1) Error starting: class org.sonatype.nexus.DefaultNexus
jvm 1    |   while locating org.sonatype.nexus.DefaultNexus
 
(truncated)
 
jvm 1    | Caused by: java.lang.NullPointerException
jvm 1    |      at org.sonatype.security.configuration.DefaultSecurityConfigurationManager.getRealms(DefaultSecurityConfigurationManager.java:104)
jvm 1    |      at org.sonatype.security.DefaultSecuritySystem.getRealmsFromConfigSource(DefaultSecuritySystem.java:202)
jvm 1    |      at org.sonatype.security.DefaultSecuritySystem.start(DefaultSecuritySystem.java:846)
jvm 1    |      at org.sonatype.nexus.DefaultNexus.startService(DefaultNexus.java:682)
jvm 1    |      at org.sonatype.nexus.DefaultNexus.start(DefaultNexus.java:647)

… oh bugger.

Restore the configuration for Nexus 1.9 and start that. I’m now in a stable, but useless situation where Nexus 1.9 is running and my Maven 2 builds are failing. It’s 19:20, I’ll return tomorrow.

Attempted fix: -Dmaven.metadata.legacy=true

Researching this issue, I came across NEXUS-3806, which mentions a maven.metadata.legacy system property. This looks hopeful, assuming that Nexus and Maven 2/3 share parts of their code base. I brought down Nexus, added -Dmaven.metadata.legacy=true to wrapper.conf. Restart nexus, rebuild metadata for my snapshots repository. Fingers crossed…

…but no luck, the metadata is still in Maven 3 format. It is now noon the next day and my Maven builds are still broken.

As I’m writing this, I realize that I didn’t try deleting the existing metadata files before running the Rebuild Metadata command. After going through all this, I didn’t feel like finding out, so if you’re in a position to verify this, please do so and leave a note in the comments.

Attempted fix: making Maven 2 understand the Maven 3 metadata format

I think MNG-4452 prompted the change in metadata XML format, applied to maven-artifact version 3.0. I know enough about Maven’s internals from earlier troubleshooting to I quickly abandon any hope of backporting this to Maven 2.

Back to getting Nexus 1.8.0.1 to work

I decided to pick up where I left off last night. I stopped Nexus,(线索在这里) renamed my sonatype-work directory and restarted Nexus, emulating a clean install. This gave me a fresh, newly-generated sonatype-work directory to compare to my existing one. I eventually traced the failed startup to the security-configuration.xml file. Here’s the original one:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?xml version="1.0"?>
<security-configuration>
    <version>2.0.3</version>
    <enabled>true</enabled>
    <anonymousAccessEnabled>true</anonymousAccessEnabled>
    <anonymousUsername><!-- hidden --></anonymousUsername>
    <anonymousPassword><!-- hidden --></anonymousPassword>
    <realms>
        <realm>NexusLdapAuthenticationRealm</realm>
        <realm>XmlAuthenticatingRealm</realm>
        <realm>XmlAuthorizingRealm</realm>
    </realms>
    <securityManager>web</securityManager>
</security-configuration>

The <securityManager> element and the NexusLdapAuthenticationRealm were absent in the fresh config. I restored my original sonatype-work directory and removed these two lines. Nexus 1.8.0.1 now starts up successfully! It is now three in the afternoon, I needed some good news by now.

I went into the web interface and re-enabled LDAP on the Administration/Server page. This restored the NexusLdapAuthenticationRealm in my XML file, meaning that the <securityManager> element is what prevented my downgraded Nexus from starting. The very first Nexus version I installed on our build server was 1.7.1. The securityManager element must be a relic of that version, although this doesn’t explain why this didn’t previously prevent Nexus from starting up.

Did that fix my Maven builds?

Not at first sight. The Rebuild Metadata task in Nexus 1.8.0.1 skips any existing metadata files. Once I figured that out I nuked these on the filesytem with a quick find /home/maven/sonatype-work/nexus/storage/snapshots -name "maven-metadata.xm*" -delete. After another Rebuild Metadata, I finally have my repository metadata in Maven 2 format.

Did that fix my Maven builds? Nope, because the Maven 3-style metadata files were still in my local repository. This is the home stretch; removing them from the local repository with another quick find command got my Maven 2 builds working again.

Getting some satisfaction

1
rm -rf nexus-oss-webapp-1.9

Suck on that, you empty-headed animal food trough wiper! I fart in your general direction*!

Lessons learned

With Maven 3 around, installing stuff from Sonatype when you’re still on (update: an outdated) Maven 2 version is a dangerous proposition. Nexus 1.9 has proven to be incompatible with Maven 2, unintentionally I’m sure. Not upgrading Nexus is easier than downgrading it. I refuse to run a DTAP chain for my development support tooling, so I’ll just refrain from updating Nexus altogether from here on.

I’ll use Jenkins to satisfy my keeping-stuff-up-to-date compulsions. ;)

<!--end post-->

<!-- Comments -->

Comments (13)

  1. <!--comment body-->

    [...] This post was mentioned on Twitter by Xebia Nederland, Jan Plas. Jan Plas said: RT @Xebia: New blog post: : How Sonatype Nexus 1.9 ruined my day http://blog.xebia.com/2011/02/25/how-nexus-1-9-ruined-my-day/ [...]

  2. <!--comment body-->
    Brian Demers - Reply

    February 25, 2011 at 8:03 pm

    You must be using Maven 2.0.9 or less ?
    You should upgrade to 2.0.11 (or 2.2.1)
    See: https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html

    You may run into problem with other repositories as well using maven 2.0.9.

    Take a look at: http://maven.apache.org/download.html to see which version of maven version would work best for you.

  3. <!--comment body-->
    Edoardo - Reply

    February 25, 2011 at 8:46 pm

    Hi Barend,

    I kind of understand your pain… Maven is a very good idea – in principle, but it takes a very hefty amount of effort to tame it’s numerous bugs and a certain recklessness in its dev community ;)

    Oh well: backups, backups… backups. Much cheaper than hoisting a DTAP chain and if you happen to run it on a VM, they’re really just a shapshot away ;)

    Glad you fixed it though…

  4. <!--comment body-->
    Fred Simon - Reply

    February 26, 2011 at 12:35 am

    I think it’s time you use Artifactory!
    Our Jenkins plugins will remove Maven from the deployment equation and Artifactory will calculate and provide the correct maven-metadata.xml to any of your build tool: Maven 2/3, Gradle, Ivy.
    Keep your freedom drop Nexus…

  5. <!--comment body-->
    Alexis Kinsella - Reply

    February 26, 2011 at 2:00 am

    Hi Barend,

    I migrated some nexus repository from version 1.8.0.1 to 1.9 some days ago. I didn’t noticed a such issue. Nexus repository still works with Nexus in version 1.9 and Maven 2.

    You got the repository broken because of the rebuild of metadata, or it was simply broken after restart ?

    Do I risk some similar crash in case I run a such command (Rebuild of metadata) on nexus repository?

    Thank you for that blog post, I guess it will help many people to save lot of time ;)

    Alexis

  6. <!--comment body-->
    Arnaud Héritier - Reply

    February 26, 2011 at 5:20 am

    As Brian said, it has probably more to have with the version of Maven 2 used than with the repo manager.
    Fred you could test it with artifactory but I think you won’t serve different metadata depending of the maven version used ?
    The problem was that in maven <= 2.0.9, Maven failed if metadata were wrong (or had unknown elements if I remember well). Nowadays it ignores unknow elements (to allow us to add new things in new versions) and does like if metadata are here if they are unreadable.
    About upgrade process for such soft, I agree that having a validation environment is annoying to manage because you need to have all the stack (repo, ci …) and to reconfigure everything all together. I agree with Edoardo, before each upgrade I create a backup of all data. And if possible I do that when teams are off.
    I'm using 1.9-M1 for months with Maven 3.x and 2.2.1 jobs without having encountered this issue. This WE I'm trying to upgrade to 1.9.0.1.

    Cheers

    Arnaud

  7. <!--comment body-->
    Tony - Reply

    February 26, 2011 at 9:45 pm

    Maven 2.0.9 was released 3 years ago. Wow. Long past time to upgrade.

  8. <!--comment body-->
    Leon - Reply

    February 27, 2011 at 10:40 am

    Hi Barend,

    It does seem to be in the very best traditions of Maven and maven plugin updates. Innocent-looking minor version upgrades breaking the build are not really unheard of :(

    Next time, I hope you take the path of wisdom and backup the entire intra- and internet before you touch sonatype stuff. Or have a time machine handy (aren’t black holes rumored to provide that capability?)

    I am getting curious about the amount of work required to upgrade maven to 2.2x. I have the funny feeling that that would require manually porting all the pom files and recompile and test everything again. Do you think such a step would be worthwile? Or would switching to artifactory be a better option, potentially blacklisting maven plugin updates?

  9. <!--comment body-->
    Yoav Landman - Reply

    February 28, 2011 at 3:49 pm

    Artifactory will return variable metadata depending on the maven client version from the next release (https://issues.jfrog.org/jira/browse/RTFACT-3794). Until then, we keep generating on the Artifactory side metadata that is fully compliant with the older format so we don’t ruin your day.
    For Jenkins, you are also welcome to use the Jenkins integration, to make sure you don’t end up with partially deployed modules if your build breaks in the middle and to have traceable artifacts and dependencies in your repo http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin

  10. <!--comment body-->
    Leon - Reply

    April 16, 2011 at 2:59 pm

    I was just googling for maven repo (“liquid LAF swing maven repo” to be exact) and this is my first hit. Well done :)

  11. <!--comment body-->
    witek - Reply

    October 8, 2012 at 1:44 pm

    just saved about 2 hours on googling / trying / fixing / failing – thanks man!

分享到:
评论

相关推荐

    sonatype nexus2.7最新版

    Sonatype Nexus是一款强大的软件仓库管理器,主要用于管理和分发Maven、npm、Gradle等构建工具的依赖。在本文中,我们将深入探讨Sonatype Nexus 2.7版本及其作为Maven私服的功能。 首先,让我们理解什么是Maven私服...

    2018年sonatype nexus-2.14.8-01.war pro专业版

    安装Sonatype Nexus Pro时,首先需要将`nexus-2.14.8-01.war`文件部署到Tomcat服务器上。这个WAR文件是一个预打包的Web应用程序,包含了Nexus的所有运行时组件。将其复制到Tomcat的`webapps`目录下,Tomcat会自动...

    Sonatype Nexus Repository Manager 使用 nexus-cli 执行指令

    Sonatype Nexus Repository Manager 使用 nexus-cli 执行指令

    sonatype nexus

    转载的别人提供的sonatype nexus,亲测可用

    docker-nexus, Sonatype Nexus的Docker 图像.zip

    docker-nexus, Sonatype Nexus的Docker 图像 sonatype/docker-nexus用于 Sonatype Nexus 存储库管理器 2的Docker 映像,。 对于 Nexus 存储库管理器 3,请参考 https://github.com/sonatype/docker-n

    Sonatype-nexus

    标题中的“Sonatype Nexus”指的是Sonatype公司的Nexus Repository Manager,这是一个开源的软件仓库管理工具,主要用于管理和分发Maven、npm、Gradle等不同构建工具的依赖库。它也被广泛用于搭建私有的Maven仓库,...

    Sonatype Nexus Maven 仓库管理工具

    【Android Gradle 插件】将自定义 Gradle 插件上传到自建 Maven 仓库 ⑤ ( 使用 Sonatype Nexus 搭建 Maven 仓库 ) https://hanshuliang.blog.csdn.net/article/details/127385094 博客资源

    Nexus源码包

    Nexus是一款强大的Maven仓库管理器,它被广泛用于企业级的...通过深入学习和分析Nexus源码,开发者不仅可以掌握Nexus的工作流程,还可以学习到很多高级Java技术和最佳实践,对于提升个人技能和解决实际问题非常有益。

    sonatype-nexus-3.64.0-04-unix

    sonatype-nexus-3.64.0-04-unix 是一个强大的Maven仓库管理器,它极大地简化了自己内部仓库的维护和外部仓库的访问。

    Nexus Repository Manager的使用

    ### Nexus Repository Manager 使用详解 #### 一、简介 Nexus Repository Manager (NRM) 是一款由Sonatype开发的仓库管理工具,它可以帮助开发者管理和分发软件包及其依赖项。NRM支持多种格式,如Maven、npm、...

    nexus-2.6.2.war

    标题 "nexus-2.6.2.war" 提供的信息是关于一个特定版本的Nexus软件,这是Sonatype公司开发的一款开源的仓库管理器,主要用于Maven、Gradle和其他基于Java的构建工具的依赖管理和分发。"war"文件是Web应用程序档案...

    nexus-oss-on-aws:具有良好架构的AWS上部署Sonatype Nexus Repository OSS

    通过EKS上的Helm部署Sonatype Nexus Repository OSS。 通过EFS CSI驱动程序,PV和PVC使用EFS作为Nexus3数据存储 创建一个专用的S3存储桶作为Nexus3 Blobstore 使用外部DNS在Route53中为入口域名创建记录 使用ACM...

    Maven私有库和本地库的安装与配置(Sonatype Nexus + Maven)

    Maven私有库和本地库的安装与配置(Sonatype Nexus + Maven) Maven私有库和本地库的安装与配置是 Maven 项目中的一个重要步骤。通过使用 Sonatype Nexus,可以轻松地安装和配置私有库和本地库,从而实现 Maven ...

    sonatype nexus ubuntu下安装指南.docx

    在Ubuntu系统上安装Sonatype Nexus时,可能会遇到一些权限问题。Nexus是一款强大的仓库管理工具,用于管理Maven、Gradle等构建工具的依赖。以下是解决这些权限问题的详细步骤: 1. **权限问题:无法写入pid文件** ...

    nexus-webapp的war.zip

    总结来说,"nexus-webapp的war.zip" 提供的是Sonatype Nexus的一个版本,它是一个基于Maven的仓库管理系统,以WAR格式打包,可以直接部署在Tomcat上。通过这个Web应用,开发者可以方便地管理他们的Maven依赖,提高...

    sonatype-nexus-docker:Sonatype Nexus OSS 的 Docker 镜像

    sonatype-nexus-docker Sonatype Nexus 的 Docker 版本用法 docker run -p 8081:8081 --name nexus griff/sonatype-nexus然后将浏览器指向 或者使用明确指定的音量目标: mkdir -p /devdata/nexusdocker run -v /...

    Sonatype Nexus IQ Evaluation-crx插件

    Sonatype Nexus IQ评估-扫描开源资源库以查找已知漏洞。 此Chrome扩展程序可与Sonatype Nexus Lifecycle一起使用,以在下载OSS软件包之前对其进行检查。 该插件需要一个有效的Sonatype Nexus Lifecycle实例。 在安装...

    docker-nexus:Sonatype Nexus 的 Docker 镜像

    sonatype/docker-nexus 带有 OpenJDK 的 Sonatype Nexus Repository Manager 2 的 Docker 镜像,从 2.14.14 开始,用作基础镜像,而早期版本使用 CentOS。 对于 Nexus Repository Manager 3,请参考构建: # docker ...

    nexus-2.14.5.war.zip

    当将“nexus-2.14.5.war”解压并部署到Tomcat时,Tomcat会自动解析WAR文件,并将其内容展开到一个工作目录下,然后根据Web应用的配置启动服务。 【部署Nexus到Tomcat】 1. 下载并解压“nexus-2.14.5.war.zip”,...

Global site tag (gtag.js) - Google Analytics