java-maven编译依赖快照版本有时间,导致依赖库找不到

问题描述

maven编译依赖快照版本有时间,导致依赖库找不到

MANIFEST.MF文件里面的信息:
Manifest-Version: 1.0
Built-By: Administrator
Build-Jdk: 1.6.0_10-rc2
Class-Path: lib/storage-1.0-20131202.054649-56.jar lib/compframe-1.0-2 0131202.072442-8.jar
实际下载到lib目录中的是storage-1.0--SNAPSHOT.jar这样。
pom文件:
?...

org.apache.maven.plugins
maven-compiler-plugin
3.0

lib
UTF-8

    <!-- 设置程序入口类,并设置依赖目录 -->
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>2.4</version>
        <configuration>
            <archive>
                <manifest>
                    <addClasspath>true</addClasspath>
                    <classpathPrefix>lib</classpathPrefix>
                    <mainClass>main.Main</mainClass>
                </manifest>
            </archive>
        </configuration>
    </plugin>

    <!-- 设置依赖库到打包生成目录下的lib目录 -->
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <executions>
            <execution>
                <id>copy</id>
                <phase>install</phase>
                <goals>
                    <goal>copy-dependencies</goal>
                </goals>
                <configuration>
                    <outputDirectory>
                        ${project.build.directory}/lib
                    </outputDirectory>
                </configuration>
            </execution>
        </executions>
    </plugin>

...

解决方案

换个Maven版本试试看。。

解决方案二:

maven-dependency-plugin 版本问题。换成2.5以上即可。

时间: 2024-10-03 19:54:08

java-maven编译依赖快照版本有时间,导致依赖库找不到的相关文章

maven快照版本和发布版本

   在使用maven过程中,我们在开发阶段经常性的会有很多公共库处于不稳定状态,随时需要修改并发布,可能一天就要发布一次,遇到bug时,甚至一天要发布N次.我们知道,maven的依赖管理是基于版本管理的,对于发布状态的artifact,如果版本号相同,即使我们内部的镜像服务器上的组件比本地新,maven也不会主动下载的.如果我们在开发阶段都是基于正式发布版本来做依赖管理,那么遇到这个问题,就需要升级组件的版本号,可这样就明显不符合要求和实际情况了.但是,如果是基于快照版本,那么问题就自热而然的

使用maven编译Java项目

综述 本文演示了用Maven编译Java项目 需要 时间:15分钟 文本编辑器或者IDE JDK 6 或者更高版本 创建项目 本例主要为了展示Maven,所以Java的项目力求简单. 创建项目结构 选择一个项目目录,在 *nix系统上使用下面语句 mkdir -p src/main/java/hello window下使用命令 mkdir src\main\java\hello 创建如下结构: └── src └── main └── java └── hello 在src/main/java/

执行 Maven 编译的 jar,找不到相关的 依赖的类--使用 maven-assembly-plugin 解决

问题:执行 jar 找不到依赖的类 用 Maven 编译完成后 ,生产了 ui-compressor-1.0.0.jar, 此时执行 java -cp target/ui-compressor-1.0.0.jar com.waylau.uicompressor.App 提示下面找不到依赖的包: Exception in thread "main" java.lang.NoClassDefFoundError: org/mozilla/javascrip t/ErrorReporter

rt jar-求java大神帮忙,java使用MAVEN编译时提示找不到类,但是类是属于rt.jar的

问题描述 求java大神帮忙,java使用MAVEN编译时提示找不到类,但是类是属于rt.jar的 java 版本: 1.6.0_10-rc2 maven 版本: 3.0.4 maven编译插件 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <s

新建maven环境,没有junit:jar:3.8.1 ,但是maven自己是依赖这个版本的

问题描述 新建maven环境,没有junit:jar:3.8.1 ,但是maven自己是依赖这个版本的 新建了maven环境 打包的时候报Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:2.6:resources (default-resources) on project wostore: Execution default-resources of goal org.apache.maven.plu

理解Maven中的SNAPSHOT版本和正式版本

Maven中建立的依赖管理方式基本已成为Java语言依赖管理的事实标准,Maven的替代者Gradle也基本沿用了Maven的依赖管理机制.在Maven依赖管理中,唯一标识一个依赖项是由该依赖项的三个属性构成的,分别是groupId.artifactId以及version.这三个属性可以唯一确定一个组件(Jar包或者War包). 其实在Nexus仓库中,一个仓库一般分为public(Release)仓和SNAPSHOT仓,前者存放正式版本,后者存放快照版本.如果在项目配置文件中(无论是build

Kotlin VS Java:编译速度大比拼,到底谁更快?

把一个Java应用程序转换为Kotlin,编译时间要多久? 这是关于Kotlin的一系列文章.分为三个部分. 第一部分讨论了从Java转换到Kotlin.第二部分是我对Kotlin的看法. 在前面的文章中, 我讨论了把Android 应用从Java 100%转换为Kotlin . Kotlin代码比Java的简洁,更易于维护,所以我认为转换是值得的. 但有些人不想试用Kotlin,因为他们担心它编译可能没有Java快. 这个关注点绝对是正确的,如果变得编译很慢,没有人愿意转换他们的代码. 所以,

JAVA 文件编译执行与虚拟机(JVM)简单介绍

java程序的内存分配 JAVA 文件编译执行与虚拟机(JVM)介绍 Java 虚拟机(JVM)是可运行Java代码的假想计算机.只要根据JVM规格描述将解释器移植到特定的计算机上,就能保证经过编译的任何Java代码能够在该系统上运行.本文首先简要介绍从Java文件的编译到最终执行的过程,随后对JVM规格描述作一说明.    一.Java源文件的编译.下载.解释和执行  Java应用程序的开发周期包括编译.下载.解释和执行几个部分.Java编译程序将Java源程序翻译为JVM可执行代码?字节码.

如何保护Java程序 防止Java反编译

Java是一种跨平台的.解释型语言.Java 源代码编译中间"字节码"存储于class文件中.Class文件是一种字节码形式的中间代码,该字节码中包括了很多源代码的信息,例如变量名.方法名等.因此,Java中间代码的反编译就变得非常容易.目前市场上有许多免费的.商用的反编译软件,都能够生成高质量的反编译后的源代码.所以,对开发人员来说,如何保护Java程序就变成了一个非常重要的挑战.本文首先讨论了保护Java程序的基本方法,然后对代码混淆问题进行深入研究,最后结合一个实际的应用程序,分