maven-assembly-plugin mysterious error

2016-05-06 Thread Jim Klo
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

2016-05-06 Thread Ben Podgursky
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 Treloar  wrote:

> 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?
>