Since
the mvn assembly tar isn't re-buildable, I think the release artifact has to
be a tarred svn export, and then we have a second release artifact which is
binary+site+docs like you say above. People can choose whether to download
the source release or the binary.
OK. I'd say do the svn export for now. For next time, we'll have mvnbe a tarred svn export, and then we have a second release artifact which is
binary+site+docs like you say above. People can choose whether to download
the source release or the binary.
generate a -src bundle to sit beside the -bin bundle it currently
creates.
if you want a fully rebuildable assembly, then you may want to revisit using a secondary assembly descriptor:
http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#project
I had this as an extra binary artifact as part of the build early on, but it was weighty, and slowed down the build process, so I suggested removing it. Perhaps you could consider configuring a Maven profile so that only when a -D argument is defined on the maven command line that this additional assembly is created (basically prevents this assembly from being built until you need it).
It should be pretty simple, I can help with this, but take a look at the commit SHA:
2ea3dbac74778279f8479ebb012198cb9bc7c9d8
from HBASE-2334, just the top-level pom.xml change, this is the reversal I did:
@@ -308,10 +308,6 @@
<descriptors>
<descriptor>src/assembly/bin.xml</descriptor>
</descriptors>
- <descriptorRefs>
- <descriptorRef>src</descriptorRef>
- <descriptorRef>project</descriptorRef>
- </descriptorRefs>
</configuration>
</plugin>
</plugins>
Paul
