maven-assembly-plugin mysterious error
Hi, I’m doing some refactoring of some existing projects - mostly we are moving from SVN to GIT and making a larger project more modular. One piece I’m working on packages our native code into an assembly to be posted into our Artifactory so other projects can depend upon those native bits without having to build them. So at this point… all I’ve done is taken the existing code and shuffled directories around, making them shallower, and then fixed up various scripts and paths to reference the new paths. This all seems to work, however - when I go to build these assemblies, I receive a NullPointerError referencing the TarArchiver.cleanup() line 494, and no other aid as to indicate what might be wrong. Can anyone provide any insight as to what might be going wrong, how I might better debug, etc? The full execution log + error is below my sig. Thanks, - JK Jim Klo Senior Software Engineer Center for Software Engineering SRI International t. @nsomnac pom.xml === http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns="http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;> 4.0.0 com.sri xsb 0.0.8349-SNAPSHOT pom ${project.basedir}/../../build maven-assembly-plugin 2.5.3 cocoa-x64.xml true make-assembly package single Descriptor for cocoa-x64.xml == http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd;> cocoa-x64 tar.bz2 false ${project.properties.artifact.basedir}/trunk.osx/flserver-build/ext/XSB ${file.separator}XSB Log === xsb jklo$ mvn -e -X package Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: /usr/local/Cellar/maven/3.3.9/libexec Java version: 1.8.0_45, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac" [DEBUG] Created new class realm maven.api [DEBUG] Importing foreign packages into class realm maven.api [DEBUG] Imported: javax.enterprise.inject.* < plexus.core [DEBUG] Imported: javax.enterprise.util.* < plexus.core [DEBUG] Imported: javax.inject.* < plexus.core [DEBUG] Imported: org.apache.maven.* < plexus.core [DEBUG] Imported: org.apache.maven.artifact < plexus.core [DEBUG] Imported: org.apache.maven.classrealm < plexus.core [DEBUG] Imported: org.apache.maven.cli < plexus.core [DEBUG] Imported: org.apache.maven.configuration < plexus.core [DEBUG] Imported: org.apache.maven.exception < plexus.core [DEBUG] Imported: org.apache.maven.execution < plexus.core [DEBUG] Imported: org.apache.maven.execution.scope < plexus.core [DEBUG] Imported: org.apache.maven.lifecycle < plexus.core [DEBUG] Imported: org.apache.maven.model < plexus.core [DEBUG] Imported: org.apache.maven.monitor < plexus.core [DEBUG] Imported: org.apache.maven.plugin < plexus.core [DEBUG] Imported: org.apache.maven.profiles < plexus.core [DEBUG] Imported: org.apache.maven.project < plexus.core [DEBUG] Imported: org.apache.maven.reporting < plexus.core [DEBUG] Imported: org.apache.maven.repository < plexus.core [DEBUG] Imported: org.apache.maven.rtinfo < plexus.core [DEBUG] Imported: org.apache.maven.settings < plexus.core [DEBUG] Imported: org.apache.maven.toolchain < plexus.core [DEBUG] Imported: org.apache.maven.usability < plexus.core [DEBUG] Imported: org.apache.maven.wagon.* < plexus.core [DEBUG] Imported: org.apache.maven.wagon.authentication < plexus.core [DEBUG] Imported: org.apache.maven.wagon.authorization < plexus.core [DEBUG] Imported: org.apache.maven.wagon.events < plexus.core [DEBUG] Imported: org.apache.maven.wagon.observers < plexus.core [DEBUG] Imported: org.apache.maven.wagon.proxy < plexus.core [DEBUG] Imported: org.apache.maven.wagon.repository < plexus.core [DEBUG] Imported: org.apache.maven.wagon.resource < plexus.core [DEBUG] Imported: org.codehaus.classworlds < plexus.core [DEBUG] Imported: org.codehaus.plexus.* < plexus.core [DEBUG] Imported: org.codehaus.plexus.classworlds < plexus.core [DEBUG] Imported: org.codehaus.plexus.component < plexus.core [DEBUG] Imported: org.codehaus.plexus.configuration < plexus.core [DEBUG] Imported:
Re: An idea I had for one way of doing Continuous Delivery with Maven
Of course, we tag the MANIFEST of all jars with the git commit. We actually go a bit farther and print out all dependency git SHA1s during the build process, so you only have to refer to the jenkins build log to do a bisect and not dig through jars. I describe how we did that here: http://liveramp.com/engineering/identifying-maven-snapshot-artifacts-by-git-revision/ On Thu, May 5, 2016 at 6:32 PM, Barrie Treloarwrote: > On 6 May 2016 at 09:48, Ben Podgursky wrote: > > > I see these discussions often, and I wanted to jump in and mention how we > > handle continuous deploys, because I feel that it avoids many of the > > downsides mentioned here, albeit with some (IMO) minor costs: > > > > - all of our internal dependencies are SNAPSHOT. we do not do releases, > > ever, or ever depend on a fixed version > > > > - we attach to the package phase of our builds an assembly which packages > > the artifact and all of the dependencies it tested against into a tar.gz > > > > - we deploy the tar.gz to our artifact server with a snapshot version > (ex, > > MY_PROJECT-1.0-deploy.tar.gz) > > > > - when deploying we simply take the last snapshot deploy artifact and > unzip > > it in production (+ some config files etc). > > > > so while you use SNAPSHOT versions, you are guaranteed that you are > > deploying against tested dependencies. and you never have to commit > > updated dependency versions, do releases, etc. the only real cost is a > bit > > of artifact server disk space… but disk space is incredibly cheap. > > > You left out tagging the source code in the built jars. > > How are you supposed to pull up the code in production? > Or git bisect, or diff between versions to track down when a defect was > introduced? >