Comments (9)
This was something inherited from the old plugin. I think we started doing this because we had a user that had jars coming from subprojects with the same name as external dependencies (or maybe other subprojects). The identically named files would stomp on one another.
If we're adding both copies by default, that sounds like a bug.
from playframework.
Are you able to create a minimal reproducer that demonstrates the issue?
from playframework.
Hey @JLLeitschuh, I was able to pinpoint the issue to an incompatibility with the ospackage-application plugin: as soon as the plugin is added, the core.jar
and core-assets.jar
files are staged.
Our project uses that plugin to create an RPM used to start a dockerized application.
Created this small project to verify that running the ./gradlew dist
task will add the duplicated resources depending on the presence of the ospackage-application plugin
.
Just out of curiosity, why is the renaming necessary for subprojects? Any suggestion on how to work around this?
Thanks!
from playframework.
After some investigation, I'm going to answer my own question:
- the problem is with the fact that both plugins add to the default
main
distribution of the project - the
ospackage-application-plugin
selects all the libraries and dependencies defined by the project, and so does theplayframework
plugin - on top of that, though, the
playframework
plugin through theorg.gradle.playframework.plugins.PlayDistributionPlugin.PrefixArtifactFileNames
class, renames dependencies from modules and libraries, essentially duplicating all the jars added to the distribution's lib
@JLLeitschuh would it be possible to make the "renaming" functionality configurable by the plugin?
As of now my team is manually cleaning up the distribution libs before packaging the jar, but it's not ideal.
from playframework.
@JLLeitschuh would it be possible to make the "renaming" functionality configurable by the plugin?
At this point, I'm more than willing to merge any PR that has sufficient unit & integration tests.
@big-guy do you know why this renaming occurs?
from playframework.
It's not a bug of the playframework
plugin per se, but one that pops up if it is used with another plugin that modifies the project's standard distribution
configuration.
I tested it locally and making the renaming configurable (default to true to avoid backward compatibility) solves the problem for us.
I'll try to write some tests for the new configuration and create a PR when I have some time.
Thanks!
from playframework.
Sorry to take so long to get back to you. I see what's going on now.
nebula.ospackage-application
also applies the built-in application
plugin. This is ultimately what's causing problems and the duplicate jars are just one of the symptoms. I can reproduce the duplicate jar problem by just applying application
.
What's happening is that both of these plugins apply the distribution
plugin and have certain assumptions about how the distribution will be used. Both the play plugin and application plugin configure the "main" distribution and add similar content. They both create tasks to generate start scripts. This means there are deeper problems and duplicates. For example in bin/
, you'll find two different copies of the start scripts. In your example, the "sandbox" project actually has three different jars (assets, production code, runnable jar). All three are getting copied, but the production code one overwrites the runnable jar, so one set of the start scripts won't even work. I suspect the order that this overwrite happens depends on the order the plugins are applied.
Since the issue is more than just the renaming behavior, I think the proper fix is more involved. I think the fix is to change PlayDistributionPlugin
to apply application
and remove as much of the specialness as possible. The reason this wasn't done originally is that the original Play plugin copied a lot of the functionality from existing plugins (distribution, application, etc) instead of applying those plugins directly. I think it's still possible to do the PrefixArtifactFileNames trick and runnable jar as part of the "main" distribution by replacing/reconfiguring what the application plugin adds.
In the mean time, you may be able to workaround this by just applying nebula.ospackage
and configuring it to package up the Play application's distribution. This would avoid the application
plugin from being applied.
from playframework.
Hey @big-guy thanks for explaining this - I'll see if I have more time to dig into this, but as of now we're working around the mis-configured distribution to remove files based on regexes, and that help us cutting the size of our image in half.
Unfortunately we use both plugins (playframework
to start local versions of the service using gradle and nebula.ospackage-application
to package a docker image to push for production use), so I'm not sure we can simply avoid applying both plugins.
I'll try to understand you suggestion a bit better - I'm still pretty new to the whole gradle world - and see if we can achieve something by means of configuration only.
Thanks for the feedback!
from playframework.
I think I have a very similar issue, just wondered if you know why when running runPlay the app is working but when running from the installation script it fail ? what is the main different there ?
Thanks
from playframework.
Related Issues (20)
- [Question] Possible to have a "partial" hotreload/continuous build? HOT 1
- Official Gradle Community PlayFramework Slack Channel
- java.lang.NullPointerException when compiling play routes. Play 2.3 and Gradle 6.6 HOT 2
- [FeatureRequest] Support for Eclipse HOT 6
- Exception when compiling Twirl templates using JDK 11 HOT 2
- When applying the plugin Gradle build fails HOT 1
- Server stops immediately when runPlay is run from another tasks HOT 4
- Is there a folder layout convention for test sources files and test resources files? HOT 2
- Kotlin coroutines support HOT 9
- PlayIdeaPlugin not compatible with Gradle 7 HOT 1
- Migration from SBT to gradle
- Picking the netty server HOT 1
- Debug in Intellij runPlay HOT 2
- Logback.xml file
- ToolChain
- Plugin should not use the deprecated org.gradle.util.[VersionNumber|CollectionUtils]
- How do I specify ECMASCRIPT6 as a --language_in parameter in the JavaScriptMinifyWorkAction task?
- Configuration cache compatibility
- Support for Play 2.9 & 3.0 ? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from playframework.