Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Excluding a jar from being unzipped #111

Open
rtyler opened this issue Nov 14, 2014 · 11 comments
Open

Excluding a jar from being unzipped #111

rtyler opened this issue Nov 14, 2014 · 11 comments
Labels
enhancement
Milestone
1.2.4

Comments

@rtyler
Copy link

rtyler commented Nov 14, 2014

I've got a .jar file in my tree that I want to get included into the shadowjar, but not unzipped into the shadowjar. Right now it's unclear to me how I might have the file included but not unpacked.

Guidance is much appreciated :D
@rtyler rtyler mentioned this issue Nov 14, 2014
Closed
@johnrengelman
Copy link
Collaborator

There is not a mechanism for this at the moment.

@johnrengelman johnrengelman added this to the 2.0.0 milestone Jan 23, 2015
@BarelyAPrincess
Copy link

Could this at all be a near future planned feature? Because I'm having the same issue with a zip file that I wish to only include as a resource not unzipped into the root. This is working just fine with my normal jar.
Personally, I feel that not unzipping the file should be the norm, compared to being on by default.

@prasanthnath
Copy link

Is there any update on this issue?

@johnrengelman
Copy link
Collaborator

this will be addressed with #196
in the next release, Zip files will not be exploded...ever.

@johnrengelman johnrengelman modified the milestones: 1.4.0, 2.0.0 Jun 24, 2016
@johnrengelman johnrengelman modified the milestones: 1.2.4, 1.3.0 Nov 3, 2016
@dmikurube
Copy link

If I understand correctly, #196 is now fixed for .zip files, but .jar files are still unzipped. Do you have any plan to address .jar?

@dmikurube
Copy link

dmikurube commented May 26, 2017 •
edited
Loading

Or, if a PR is available to make this configurable, is it acceptable? For example,

shadowJar {
    jarsAsResources [ "jars/*.jar" ]  // They are not unzipped.
}

@johnrengelman johnrengelman mentioned this issue Jul 22, 2017
Closed
@johnrengelman johnrengelman reopened this Jul 22, 2017
@johnrengelman
Copy link
Collaborator

johnrengelman commented Jul 22, 2017 •
edited
Loading

@dmikuribe - you are correct. This was incorrectly closed. I would love a PR to support this. Something maybe like this though:

shadowJar {
  expander {
    exclude "foo.jar"
  }
}

@Lanchon
Copy link

Lanchon commented Jul 23, 2017

@dmikurube, here is what i use for a workaround:
https://github.com/DexPatcher/dexpatcher-tool/blob/v1.2.1/tool/build.gradle#L57-L79

dmikurube added a commit to embulk/embulk that referenced this issue Nov 27, 2017
@dmikurube
Move new plugin templates into Java resources not as a part of Ruby code
91806ec 
The files go into embulk-core, not embulk-cli, as a workaround against
Shadow Gradle Plugin's bug.
GradleUp/shadow#111

If gradle-wrapper.jar is processed directly by Shadow Plugin in embulk-cli,
gradle-wrapper.jar is unzipped unexpectedly. If the jar is once contained
in embulk-core's jar, gradle-wrapper.jar is not unzipped.
@dmikurube dmikurube mentioned this issue Nov 27, 2017
Merged
@trustin
Copy link

trustin commented Nov 20, 2018

This is unresolved yet, right? Got a little bit confused because milestone is set to 1.2.4.

@jponge
Copy link

jponge commented Mar 12, 2019

@johnrengelman Just observed that behaviour, a jar file put as a resource (e.g., lib/foo.jar) is being expanded in the final jar. This is very surprising and problematic as there is no workaround but to change the file extension, which causes other problems.

@Lanchon
Copy link

Lanchon commented Mar 12, 2019

yes there is a workaround. read the thread.

tsegismont added a commit to vert-x3/vertx-starter that referenced this issue Mar 12, 2019
@tsegismont
Workaround shadowJar bug
27eaa62 
GradleUp/shadow#111
@shinsuke-mat shinsuke-mat mentioned this issue Jul 27, 2020
Closed
Fiouz added a commit to Fiouz/shadow that referenced this issue Aug 30, 2021
@Fiouz
refactor: replace static final String fields public / remove getters
ba81f01 
Omitting the visibility modifier in Groovy [1] automatically creates a
private backing field and a public getter (+ setter if the field is not
final).
It is unlikely to be an intended design as it makes access to those
fields awkward from statically typed languages
`ShadowBasePlugin.getCONFIGURATION_NAME()`.

This is a backward incompatible change as this removes public getters.

Here is what the generated class looked liked before this
commit (7.0.0):

```
$ javap -p -c -constants ShadowBasePlugin.class
Compiled from "ShadowBasePlugin.groovy"
public class com.github.jengelman.gradle.plugins.shadow.ShadowBasePlugin implements org.gradle.api.Plugin<org.gradle.api.Project>, groovy.lang.GroovyObject {
  private static final java.lang.String EXTENSION_NAME = "shadow";

  private static final java.lang.String CONFIGURATION_NAME = "shadow";
[...]
  public static java.lang.String getEXTENSION_NAME();
    Code:
       0: getstatic     GradleUp#86                 // Field EXTENSION_NAME:Ljava/lang/String;
       3: areturn

  public static java.lang.String getCONFIGURATION_NAME();
    Code:
       0: getstatic     GradleUp#111                // Field CONFIGURATION_NAME:Ljava/lang/String;
       3: areturn
```

[1] https://groovy-lang.org/objectorientation.html#fields
Fiouz added a commit to Fiouz/shadow that referenced this issue Aug 30, 2021
@Fiouz
refactor: replace static final String fields public / remove getters
bb69308 
Omitting the visibility modifier creates a Groovy _property_ [1], which
is composed by:
* a _private_ backing field
* a public getter
* (+ setter if the property is not `final`)

It is unlikely to be an intended design as it makes access to those
fields awkward from statically typed languages
`ShadowBasePlugin.getCONFIGURATION_NAME()`.

This commit replaces such _properties_ with _public fields_ only.

This is a backward incompatible change as this removes public getters.

Here is what the generated class looked liked before this
commit (7.0.0):

```
$ javap -p -c -constants ShadowBasePlugin.class
Compiled from "ShadowBasePlugin.groovy"
public class com.github.jengelman.gradle.plugins.shadow.ShadowBasePlugin implements org.gradle.api.Plugin<org.gradle.api.Project>, groovy.lang.GroovyObject {
  private static final java.lang.String EXTENSION_NAME = "shadow";

  private static final java.lang.String CONFIGURATION_NAME = "shadow";
[...]
  public static java.lang.String getEXTENSION_NAME();
    Code:
       0: getstatic     GradleUp#86                 // Field EXTENSION_NAME:Ljava/lang/String;
       3: areturn

  public static java.lang.String getCONFIGURATION_NAME();
    Code:
       0: getstatic     GradleUp#111                // Field CONFIGURATION_NAME:Ljava/lang/String;
       3: areturn
```

[1] https://groovy-lang.org/objectorientation.html#properties
Fiouz added a commit to Fiouz/shadow that referenced this issue Aug 30, 2021
@Fiouz
refactor: directly expose static final String fields / remove getters
4048e07 
Omitting the visibility modifier creates a Groovy _property_ [1], which
is composed by:
* a _private_ backing field
* a public getter
* (+ setter if the property is not `final`)

It is unlikely to be an intended design as it makes access to those
fields awkward from statically typed languages
`ShadowBasePlugin.getCONFIGURATION_NAME()`.

This commit replaces such _properties_ with _public fields_ only.

This is a backward incompatible change as this removes public getters.

Here is what the generated class looked liked before this
commit (7.0.0):

```
$ javap -p -c -constants ShadowBasePlugin.class
Compiled from "ShadowBasePlugin.groovy"
public class com.github.jengelman.gradle.plugins.shadow.ShadowBasePlugin implements org.gradle.api.Plugin<org.gradle.api.Project>, groovy.lang.GroovyObject {
  private static final java.lang.String EXTENSION_NAME = "shadow";

  private static final java.lang.String CONFIGURATION_NAME = "shadow";
[...]
  public static java.lang.String getEXTENSION_NAME();
    Code:
       0: getstatic     GradleUp#86                 // Field EXTENSION_NAME:Ljava/lang/String;
       3: areturn

  public static java.lang.String getCONFIGURATION_NAME();
    Code:
       0: getstatic     GradleUp#111                // Field CONFIGURATION_NAME:Ljava/lang/String;
       3: areturn
```

[1] https://groovy-lang.org/objectorientation.html#properties
@johnrengelman johnrengelman reopened this Mar 21, 2023
Johni0702 added a commit to ReplayMod/ReplayMod that referenced this issue Jul 10, 2024
@Johni0702
Fix included mod jars being exploded into outer jar
5b766b4 
Caused by this stupid behavior of the shadow plugin:
GradleUp/shadow#111

Fixes #976
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
1.2.4
Development

No branches or pull requests
8 participants
@jponge @rtyler @trustin @dmikurube @johnrengelman @prasanthnath @BarelyAPrincess @Lanchon