Problems with new build and maven assemble:single?
Closed this issue · 22 comments
I have had a working exhibitor 1.5.2 built in the ZeroToDocker NetflixOSS project. Updating for 1.5.3 fails, I think due to problems with the new build.
Checkout out here for the work in progress trying to get 1.5.3 to work:
https://github.com/aspyker/zerotodocker/tree/versionedExhibitor/exhibitor-zookeeper
You can build these on Docker via the commands here:
https://github.com/aspyker/zerotodocker/blob/versionedExhibitor/buildimages.sh#L46
Each builds using maven assemble:single as:
https://github.com/aspyker/zerotodocker/blob/versionedExhibitor/exhibitor-zookeeper/1.5.2/Dockerfile#L31
https://github.com/aspyker/zerotodocker/blob/versionedExhibitor/exhibitor-zookeeper/1.5.2/pom.xml
The build of both succeed, but there seems to be quite a bit missing from the 1.5.3 file, I think due to the standalone pom files.
If you look at:
and
You'll see big differences. As an example, the 1.5.2 references the Amazon SDK, whereas the 1.5.3 does not.
@rspieldenner I know we should be moving away from Maven, but I settled on this as the lightest way to solve this in building the Docker image. Do you know if there is a way to fix the standalone pom's to be as functional as before? Also, can you confirm this is a result of the new build changes?
I removed a lot of unnecessary dependencies. If they weren't needed to compile or by the tests they were deleted.
@rspieldenner I am getting a ton of issues in the maven build of the standalone jar. Can I stop by and show you this? I'm not a maven expert by any means.
Sure we can take a look tomorrow
@rspieldenner and i worked on this on Friday. Rob, can you checkin your changes and then I'll check in the changes to standalone to support distZip (or I can submit a PR with both if you prefer). After that we can do a release and we can add the file via the go github-release tool (I tested this on my own repository). @rspieldenner, I'll email you separately the details of what github-release does so we can update nebula plugins.
Not sure if the single archive pom is still in flux, but may I suggest setting the exhibitor version instead of 1.0 in the projects version.
This would result in the jar having the right version. In the dependency part you can use ${project.version} so only one place needs editing.
#230 somewhat related
How the heck do you build a proper FAT/Uber JAR in Gradle?
Don't worry about Gradle, Maven ain't even working for 1.5.3! ;-)
By default I believe the application plugin which can create a zip or tar
with shell scripts to configure the proper class path is the correct way to
go.
The https://github.com/johnrengelman/shadow is a good choice for uber
jarring.
On Thu, Feb 12, 2015 at 10:16 AM, Mathias Bogaert notifications@github.com
wrote:
Don't worry about Gradle, Maven ain't even working for 1.5.3! ;-)
—
Reply to this email directly or view it on GitHub
#224 (comment).
I can confirm that the maven one is missing AWS and logging jar.
You can add the following to build a working 1.5.3 in the meantime.
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk</artifactId>
<version>1.9.17</version>
</dependency>
<!-- Log4J -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.1</version>
</dependency>
No, this doesn't work either.
java.io.IOException: Could not find (.*log4j.*)|(.*slf4j.*) jar
at com.netflix.exhibitor.core.processes.Details.findJar(Details.java:145)
at com.netflix.exhibitor.core.processes.Details.<init>(Details.java:57)
at com.netflix.exhibitor.core.processes.StandardProcessOperations.startInstance(StandardProcessOperations.java:105)
at com.netflix.exhibitor.core.state.KillRunningInstance.completed(KillRunningInstance.java:41)
at com.netflix.exhibitor.core.activity.ActivityQueue$1.run(ActivityQueue.java:127
mvn clean package is the command to run with latest pom.
Sorry for slow response. After my #228 pull request, you can do:
./gradlew :exhibitor-standalone:distZip
This creates a zip with all the project jars and dependencies and sh and bat files.
@quidryan Is there any way you can redo the 1.5.4 build:
https://netflixoss.ci.cloudbees.com/job/NetflixOSS/job/exhibitor/job/exhibitor-release/
with distZip specified?
I'd like to download that and upload it to the attachments for that release on github unless @rspieldenner has automated that already in nebula :)
@quidryan @rspieldenner @Randgalt we keep releasing without fixing the packaging. Can someone do a cloud bees build with distZip specified which was fixed to actually produce a fat zip that can be used in ZeroToDocker (and anyone else wanting to have a easy way to do what used to be possible with maven assemble)?
AFAIK the uber jar works now. What's the problem?
@Randgalt distZip would work as well. As a gradle guy, I like distZip over uberjar.
With either it would be good to get the Cloudbees build the runnable artifact so we can upload it to the release on github so a Docker build job can download it and build a running image without having to install all the development build tools.
If a uber jar works, I'm happy rephrasing my above to
@quidryan @rspieldenner @Randgalt we keep releasing without fixing the packaging. Can someone do a cloud bees build with uber jar being built that can be used in ZeroToDocker (and anyone else wanting to have a easy way to do what used to be possible with maven assemble)?
I don't have access to the Cloudbees stuff.
@Randgalt understood. @rspieldenner @quidryan please?
It's on the list just way down the list.
On Mon, Mar 9, 2015 at 4:14 PM, Andrew Spyker notifications@github.com
wrote:
@Randgalt https://github.com/Randgalt understood. @rspieldenner
https://github.com/rspieldenner @quidryan https://github.com/quidryan
please?—
Reply to this email directly or view it on GitHub
#224 (comment).
@rspieldenner if you can get the cloudbees building and archiving the distZip, I can do the work to manually update the next release attachments. I agree that this is suboptimal and should be completely automated, but this would unstick ZeroToDocker and exhibitor as a temp solution.
This issue is extremely old and new versions have came out since then.
Closing this for now. You can re-open if this is still a problem on latest version.