[JBoss JIRA] (SHRINKWRAP-521) Can't compile without compile without JAVA_HOME set, due to NPE in JavacCompiler
by Jan-Willem Gmelig Meyling (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-521?page=com.atlassian.jira.pl... ]
Jan-Willem Gmelig Meyling commented on SHRINKWRAP-521:
------------------------------------------------------
https://github.com/codehaus-plexus/plexus-compiler/pull/52 is merged and released with Plexus Compiler 2.8.5, so updating that dependency should resolve the issue. Nevertheless, it may still be useful to wire up a logger so that output by the Plexus Compiler can be propagated.
> Can't compile without compile without JAVA_HOME set, due to NPE in JavacCompiler
> --------------------------------------------------------------------------------
>
> Key: SHRINKWRAP-521
> URL: https://issues.jboss.org/browse/SHRINKWRAP-521
> Project: ShrinkWrap
> Issue Type: Bug
> Reporter: Jan-Willem Gmelig Meyling
> Priority: Trivial
>
> If JAVA_HOME is not set, the Plexus JavacCompiler will fallback to "which javac". However, this statement is logged without a proper check that checks whether logging is enabled (see my pull request https://github.com/codehaus-plexus/plexus-compiler/pull/52 ). Because Shrinkwrap does not attach a logger to the JavacCompiler, and this issue in Plexus Compiler, the JavacCompiler will throw a null pointer exception during compilation causing the test run to fail.
> I've already proposed a PR to Plexus Compiler, but perhaps it is a good idea to attach a logger anyway so that compilation output can be printed to the logging output, which will also resolve this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
- 1
- 0
[JBoss JIRA] (SHRINKWRAP-523) Support creation of AWS Lambda .zip archives
by Ian Brandt (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-523?page=com.atlassian.jira.pl... ]
Ian Brandt updated SHRINKWRAP-523:
----------------------------------
Description:
AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
{code:java}
final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
lambdaZip.addClasses(handlerClass);
final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
Maven.resolver()
.loadPomFromFile("pom.xml")
.importCompileAndRuntimeDependencies()
.resolve()
.withTransitivity()
.asList(JavaArchive.class)
.forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
{code}
It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
I can think of a few ways to accomplish this (and there are likely others):
# Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
#* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
#* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
#* There's also the issue of the default archive name having a '.jar' extension instead of '.zip' (per the service descriptor properties file for {{JavaArchive}}).
# Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
#* Easy again with the underlying implementation being {{ContainerBase}}.
#* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API. Perhaps that makes defaulting the library path to 'lib/' more assuming, though.
#* I was surprised to find the default extension for {{GenericArchive}} is '.jar', which implies the JAR spec. I would have guessed '.zip'. I'd propose changing it as part of this approach, but that would be a breaking change for anyone who's come to depend on it being '.jar'.
#* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
# Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
#* It would be the equivalent of approach #1, but with a default extension of '.zip'.
#* AWS Lambda seems here to stay.
#* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
# Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
I'm happy to create a pull request given guidance on the preferred approach. For myself, I'd lean towards #2 if changing the default extension is deemed acceptable.
was:
AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
{code:java}
final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
lambdaZip.addClasses(handlerClass);
final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
Maven.resolver()
.loadPomFromFile("pom.xml")
.importCompileAndRuntimeDependencies()
.resolve()
.withTransitivity()
.asList(JavaArchive.class)
.forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
{code}
It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
I can think of a few ways to accomplish this (and there are likely others):
# Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
#* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
#* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
#* There's also the issue that the default archive name will have a '.jar' extension instead of '.zip', per the service descriptor properties file for {{JavaArchive}}.
# Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
#* Easy again with the underlying implementation being {{ContainerBase}}.
#* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API, though that also makes defaulting the library path to 'lib/' a bit more assuming.
#* I was a bit surprised to find the default extension for {{GenericArchive}} is '.jar' as well, as that implies the JAR spec. I would have guessed '.zip'. I'd propose changing that as part of this approach, but that would be a breaking change for anyone that's come to depend on it being '.jar'.
#* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
# Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
#* It would be the equivalent of approach #1, but with a default extension of '.zip'.
#* On one hand, AWS Lambda seems here to stay.
#* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
# Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
I'm happy to create a pull request given guidance on the preferred approach. For myself I'd lean towards #2 if changing the default extension is deemed acceptable.
> Support creation of AWS Lambda .zip archives
> --------------------------------------------
>
> Key: SHRINKWRAP-523
> URL: https://issues.jboss.org/browse/SHRINKWRAP-523
> Project: ShrinkWrap
> Issue Type: Feature Request
> Components: api, impl-base
> Affects Versions: 1.2.6
> Reporter: Ian Brandt
> Priority: Optional
>
> AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
> As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
> Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
> {code:java}
> final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
> lambdaZip.addClasses(handlerClass);
> final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
> Maven.resolver()
> .loadPomFromFile("pom.xml")
> .importCompileAndRuntimeDependencies()
> .resolve()
> .withTransitivity()
> .asList(JavaArchive.class)
> .forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
> lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
> {code}
> It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
> I can think of a few ways to accomplish this (and there are likely others):
> # Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
> #* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
> #* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
> #* There's also the issue of the default archive name having a '.jar' extension instead of '.zip' (per the service descriptor properties file for {{JavaArchive}}).
> # Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
> #* Easy again with the underlying implementation being {{ContainerBase}}.
> #* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API. Perhaps that makes defaulting the library path to 'lib/' more assuming, though.
> #* I was surprised to find the default extension for {{GenericArchive}} is '.jar', which implies the JAR spec. I would have guessed '.zip'. I'd propose changing it as part of this approach, but that would be a breaking change for anyone who's come to depend on it being '.jar'.
> #* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
> # Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
> #* It would be the equivalent of approach #1, but with a default extension of '.zip'.
> #* AWS Lambda seems here to stay.
> #* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
> # Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
> I'm happy to create a pull request given guidance on the preferred approach. For myself, I'd lean towards #2 if changing the default extension is deemed acceptable.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
- 1
- 0
[JBoss JIRA] (SHRINKWRAP-523) Support creation of AWS Lambda .zip archives
by Ian Brandt (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-523?page=com.atlassian.jira.pl... ]
Ian Brandt updated SHRINKWRAP-523:
----------------------------------
Description:
AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
{code:java}
final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
lambdaZip.addClasses(handlerClass);
final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
Maven.resolver()
.loadPomFromFile("pom.xml")
.importCompileAndRuntimeDependencies()
.resolve()
.withTransitivity()
.asList(JavaArchive.class)
.forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
{code}
It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
I can think of a few ways to accomplish this (and there are likely others):
# Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
#* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
#* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
#* There's also the issue that the default archive name will have a '.jar' extension instead of '.zip', per the service descriptor properties file for {{JavaArchive}}.
# Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
#* Easy again with the underlying implementation being {{ContainerBase}}.
#* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API, though that also makes defaulting the library path to 'lib/' a bit more assuming.
#* I was a bit surprised to find the default extension for {{GenericArchive}} is '.jar' as well, as that implies the JAR spec. I would have guessed '.zip'. I'd propose changing that as part of this approach, but that would be a breaking change for anyone that's come to depend on it being '.jar'.
#* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
# Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
#* It would be the equivalent of approach #1, but with a default extension of '.zip'.
#* On one hand, AWS Lambda seems here to stay.
#* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
# Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
I'm happy to create a pull request given guidance on the preferred approach. For myself I'd lean towards #2 if changing the default extension is deemed acceptable.
was:
AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
{code:java}
final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
lambdaZip.addClasses(handlerClass);
final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
Maven.resolver()
.loadPomFromFile("pom.xml")
.importCompileAndRuntimeDependencies()
.resolve()
.withTransitivity()
.asList(JavaArchive.class)
.forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
{code}
It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
I can think of a few ways to accomplish this (and there are likely others):
# Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
#* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
#* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
#* There's also the issue that the default archive name will have a '.jar' extension instead of '.zip', per the service descriptor properties file for {{JavaArchive}}.
# Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
#* Easy again with the underlying implementation being {{ContainerBase}}.
#* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API, though that also makes defaulting the library path to 'lib/' a bit more assuming.
#* I was a bit surprised to find the default extension for {{GenericArchive}} is '.jar' as well, as that implies the JAR spec. I would have guessed '.zip'. I'd propose changing that as part of this approach, but that would be a breaking change for anyone that has come to depend on it being '.jar'.
#* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
# Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
#* It would be the equivalent of approach #1, but with a default extension of '.zip'.
#* On one hand, AWS Lambda seems here to stay.
#* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
# Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
I'm happy to create a pull request given guidance on the preferred approach. For myself I'd lean towards #2 if changing the default extension is deemed acceptable.
> Support creation of AWS Lambda .zip archives
> --------------------------------------------
>
> Key: SHRINKWRAP-523
> URL: https://issues.jboss.org/browse/SHRINKWRAP-523
> Project: ShrinkWrap
> Issue Type: Feature Request
> Components: api, impl-base
> Affects Versions: 1.2.6
> Reporter: Ian Brandt
> Priority: Optional
>
> AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
> As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
> Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
> {code:java}
> final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
> lambdaZip.addClasses(handlerClass);
> final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
> Maven.resolver()
> .loadPomFromFile("pom.xml")
> .importCompileAndRuntimeDependencies()
> .resolve()
> .withTransitivity()
> .asList(JavaArchive.class)
> .forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
> lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
> {code}
> It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
> I can think of a few ways to accomplish this (and there are likely others):
> # Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
> #* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
> #* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
> #* There's also the issue that the default archive name will have a '.jar' extension instead of '.zip', per the service descriptor properties file for {{JavaArchive}}.
> # Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
> #* Easy again with the underlying implementation being {{ContainerBase}}.
> #* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API, though that also makes defaulting the library path to 'lib/' a bit more assuming.
> #* I was a bit surprised to find the default extension for {{GenericArchive}} is '.jar' as well, as that implies the JAR spec. I would have guessed '.zip'. I'd propose changing that as part of this approach, but that would be a breaking change for anyone that's come to depend on it being '.jar'.
> #* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
> # Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
> #* It would be the equivalent of approach #1, but with a default extension of '.zip'.
> #* On one hand, AWS Lambda seems here to stay.
> #* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
> # Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
> I'm happy to create a pull request given guidance on the preferred approach. For myself I'd lean towards #2 if changing the default extension is deemed acceptable.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
- 1
- 0
[JBoss JIRA] (SHRINKWRAP-523) Support creation of AWS Lambda .zip archives
by Ian Brandt (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-523?page=com.atlassian.jira.pl... ]
Ian Brandt updated SHRINKWRAP-523:
----------------------------------
Description:
AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
{code:java}
final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
lambdaZip.addClasses(handlerClass);
final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
Maven.resolver()
.loadPomFromFile("pom.xml")
.importCompileAndRuntimeDependencies()
.resolve()
.withTransitivity()
.asList(JavaArchive.class)
.forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
{code}
It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
I can think of a few ways to accomplish this (and there are likely others):
# Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
#* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
#* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
#* There's also the issue that the default archive name will have a '.jar' extension instead of '.zip', per the service descriptor properties file for {{JavaArchive}}.
# Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
#* Easy again with the underlying implementation being {{ContainerBase}}.
#* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API, though that also makes defaulting the library path to 'lib/' a bit more assuming.
#* I was a bit surprised to find the default extension for {{GenericArchive}} is '.jar' as well, as that implies the JAR spec. I would have guessed '.zip'. I'd propose changing that as part of this approach, but that would be a breaking change for anyone that has come to depend on it being '.jar'.
#* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
# Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
#* It would be the equivalent of approach #1, but with a default extension of '.zip'.
#* On one hand, AWS Lambda seems here to stay.
#* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
# Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
I'm happy to create a pull request given guidance on the preferred approach. For myself I'd lean towards #2 if changing the default extension is deemed acceptable.
was:
AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
{code:java}
final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
lambdaZip.addClasses(handlerClass);
final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
Maven.resolver()
.loadPomFromFile("pom.xml")
.importCompileAndRuntimeDependencies()
.resolve()
.withTransitivity()
.asList(JavaArchive.class)
.forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
{code}
It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
I can think of a few ways to accomplish this (and there are likely others):
# Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
#* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
#* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
#* There's also the issue that the default archive name will have a '.jar' instead of '.zip' extension per the service descriptor properties file for {{JavaArchive}}.
# Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
#* Easy again with the underlying implementation being {{ContainerBase}}.
#* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API, though that also makes defaulting the library path to 'lib/' a bit more assuming.
#* I was a bit surprised to find the default extension for {{GenericArchive}} is '.jar' as well, as that implies the JAR spec. I would have guessed '.zip'. I'd propose changing that as part of this approach, but that would be a breaking change for anyone that has come to depend on it being '.jar'.
#* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
# Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
#* It would be the equivalent of approach #1, but with a default extension of '.zip'.
#* On one hand, AWS Lambda seems here to stay.
#* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
# Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
I'm happy to create a pull request given guidance on the preferred approach. For myself I'd lean towards #2 if changing the default extension is deemed acceptable.
> Support creation of AWS Lambda .zip archives
> --------------------------------------------
>
> Key: SHRINKWRAP-523
> URL: https://issues.jboss.org/browse/SHRINKWRAP-523
> Project: ShrinkWrap
> Issue Type: Feature Request
> Components: api, impl-base
> Affects Versions: 1.2.6
> Reporter: Ian Brandt
> Priority: Optional
>
> AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
> As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
> Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
> {code:java}
> final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
> lambdaZip.addClasses(handlerClass);
> final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
> Maven.resolver()
> .loadPomFromFile("pom.xml")
> .importCompileAndRuntimeDependencies()
> .resolve()
> .withTransitivity()
> .asList(JavaArchive.class)
> .forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
> lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
> {code}
> It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
> I can think of a few ways to accomplish this (and there are likely others):
> # Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
> #* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
> #* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
> #* There's also the issue that the default archive name will have a '.jar' extension instead of '.zip', per the service descriptor properties file for {{JavaArchive}}.
> # Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
> #* Easy again with the underlying implementation being {{ContainerBase}}.
> #* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API, though that also makes defaulting the library path to 'lib/' a bit more assuming.
> #* I was a bit surprised to find the default extension for {{GenericArchive}} is '.jar' as well, as that implies the JAR spec. I would have guessed '.zip'. I'd propose changing that as part of this approach, but that would be a breaking change for anyone that has come to depend on it being '.jar'.
> #* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
> # Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
> #* It would be the equivalent of approach #1, but with a default extension of '.zip'.
> #* On one hand, AWS Lambda seems here to stay.
> #* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
> # Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
> I'm happy to create a pull request given guidance on the preferred approach. For myself I'd lean towards #2 if changing the default extension is deemed acceptable.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
- 1
- 0
[JBoss JIRA] (SHRINKWRAP-523) Support creation of AWS Lambda .zip archives
by Ian Brandt (JIRA)
Ian Brandt created SHRINKWRAP-523:
-------------------------------------
Summary: Support creation of AWS Lambda .zip archives
Key: SHRINKWRAP-523
URL: https://issues.jboss.org/browse/SHRINKWRAP-523
Project: ShrinkWrap
Issue Type: Feature Request
Components: api, impl-base
Affects Versions: 1.2.6
Reporter: Ian Brandt
Priority: Optional
AWS Lambda supports deployments of Java functions in [a simple ZIP format|https://docs.aws.amazon.com/lambda/latest/dg/create-deployment-pkg...].
As with standard JARs, the class files, resources, manifest resources, and service provider configurations are all included from the root of the archive. Unlike standard JARs, dependent JARs are included under a 'lib/' folder.
Currently, to create ad-hoc Lambda deployments for testing I'm starting with a {{JavaArchive}}. I add the standard JAR assets, and then use the [{{Archive.add(Archive, ArchivePath, StreamExporter)}}|https://repository.jboss.org/nexus/content/repositories...] API (as used by [{{ContainerBase.addAsLibraries(Archive...)}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6-javadoc.jar-unzip/index.html] to add the dependencies. Finally, I export it to a temp file with a '.zip' extension for upload:
{code:java}
final JavaArchive lambdaZip = ShrinkWrap.create(JavaArchive.class);
lambdaZip.addClasses(handlerClass);
final ArchivePath archiveLibraryPath = ArchivePaths.create("/lib");
Maven.resolver()
.loadPomFromFile("pom.xml")
.importCompileAndRuntimeDependencies()
.resolve()
.withTransitivity()
.asList(JavaArchive.class)
.forEach(javaArchive -> lambdaZip.add(javaArchive, archiveLibraryPath, ZipExporter.class));
lambdaZip.as(ZipExporter.class).exportTo(tempZipFile, overwrite);
{code}
It would be nice to be able to use the [{{LibraryContainer}}|https://repository.jboss.org/nexus/content/repositories/unzip/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6-javadoc.jar-unzip/index.html] API directly instead.
I can think of a few ways to accomplish this (and there are likely others):
# Make {{JavaArchive}} a {{LibraryContainer}}. The library path would be defaulted to 'lib/'.
#* Easy to do since {{JavaArchiveImpl}} extends {{ContainerBase}}, which already has the all the necessary implementation.
#* The API would now extend the [JAR File Specification|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/...], so there's the question of utility vs. conformance.
#* There's also the issue that the default archive name will have a '.jar' instead of '.zip' extension per the service descriptor properties file for {{JavaArchive}}.
# Add {{LibraryContainer}} and {{ServiceProviderContainer}} to the list of interfaces extended by {{GenericArchive}}.
#* Easy again with the underlying implementation being {{ContainerBase}}.
#* There's no presumption of a spec with {{GenericArchive}}, so presumably there's no harm in the additional API, though that also makes defaulting the library path to 'lib/' a bit more assuming.
#* I was a bit surprised to find the default extension for {{GenericArchive}} is '.jar' as well, as that implies the JAR spec. I would have guessed '.zip'. I'd propose changing that as part of this approach, but that would be a breaking change for anyone that has come to depend on it being '.jar'.
#* Another issue here is if you further say the {{WebContainer}}, {{EnterpriseContainer}}, and {{ResourceAdapterContainer}} API might as well be added too. Their respective implementation classes extend {{ContainerBase}}, creating a multiple inheritance situation on the implementation side. There's also conflict between the standard paths, e.g. 'lib/' vs. 'WEB-INF/lib/'.
# Add a new {{LambdaArchive}} interface and implementation to ShrinkWrap proper.
#* It would be the equivalent of approach #1, but with a default extension of '.zip'.
#* On one hand, AWS Lambda seems here to stay.
#* I would think it better to take this as an opportunity to make the base API more generic, rather than to specialize with a new subtype.
# Create the same {{LambdaArchive}}, but in a ShrinkWrap extension project.
I'm happy to create a pull request given guidance on the preferred approach. For myself I'd lean towards #2 if changing the default extension is deemed acceptable.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
- 1
- 0
- ← Newer
- 1
- Older →