Not really: 1. I need to have the gav 2. Please never set Class-Path of the manifest. It leads to broken runtime in most environments :(.
Le 8 févr. 2018 05:19, "Lukasz Cwik" <lc...@google.com> a écrit : > Looking at the Gradle shadow plugin, it seems like it is doing what you > ask. Does this fit your usecase? > > From: http://imperceptiblethoughts.com/shadow/#configuring_the_ > runtime_classpath > > Additionally, Shadow automatically configures the manifest of the > shadowJar task to contain a Class-Path entry in the JAR manifest. The > value of the Class-Path entry is the name of all dependencies resolved in > the shadow configuration for the project. > > dependencies { > shadow 'junit:junit:3.8.2' > } > > Inspecting the META-INF/MANIFEST.MF entry in the JAR file will reveal the > following attribute: > > Class-Path: junit-3.8.2.jar > > > > On Wed, Feb 7, 2018 at 9:27 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> >> >> 2018-02-07 18:21 GMT+01:00 Lukasz Cwik <lc...@google.com>: >> >>> What kinds of features would this enable within the Apache Beam SDK or >>> allow for users to write (looking for some reason as to why this is not >>> just a one off change to support a use case)? >>> >> >> It allows to build a classpath and to rely on beam without requiring >> maven to resolve the poms and it is way faster than resolving pom model. I >> full ack it is a bit limit like case but it doesn't cost much to beam too >> so thought I could ask before >> doing something 100% custom. >> >> >>> Would it list all the transitive dependencies? >>> >> >> all runtime ones (= not test and provided ones - even if i can live with >> it listing them all, I just don't see why it would) >> >> >>> >>> How would you test that it works? >>> >> >> It is a maven plugin so not sure it requires a test in beam itself but on >> my side I have some test for this kind of thing already running a server >> from this kind of file typically. >> >> >>> >>> On Wed, Feb 7, 2018 at 7:23 AM, Romain Manni-Bucau < >>> rmannibu...@gmail.com> wrote: >>> >>>> Hi guys, >>>> >>>> I have a use case where I would resolve beam classpath >>>> programmatically. I wonder if it would be possible to add in META-INF (or >>>> BEAM-INF, in the jar is the main request ;)) a dependencies.txt (or other >>>> file) listing all the mandatory dependencies. I'm mainly interested by the >>>> java sdk core module but can be beneficial to others as well. >>>> >>>> With maven it is just a matter of defining: >>>> >>>> <plugin> >>>> <groupId>org.apache.maven.plugins</groupId> >>>> <artifactId>maven-dependency-plugin</artifactId> >>>> <version>${dependency-plugin.version}</version> >>>> <executions> >>>> <execution> >>>> <id>create-META-INF/dependencies.txt</id> >>>> <phase>prepare-package</phase> >>>> <goals> >>>> <goal>list</goal> >>>> </goals> >>>> <configuration> >>>> >>>> <outputFile>${project.build.outputDirectory}/META-INF/dependencies.txt</outputFile> >>>> </configuration> >>>> </execution> >>>> </executions> >>>> </plugin> >>>> >>>> with gradle it is a loop around a resolvedconfiguration which dumps the >>>> artifacts in a maven format (group:name:type:version) >>>> >>>> My interest of it being in beam is to be able to upgrade beam without >>>> having to re-release these metadata. >>>> >>>> Is it something the project could be interested in? >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>> <http://rmannibucau.wordpress.com> | Github >>>> <https://github.com/rmannibucau> | LinkedIn >>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>> >>> >>> >> >
