jakartaee / inject Goto Github PK

Add info about which signing keys will be used for published artifacts.

For security purposes, it would be great if you were able to publish the gpg public keys that are "valid" for use when verifying signing artifacts uploaded to maven central.

This allows for "out of band" verification of the expected signing key.

Some examples of other libs publishing their signing keys:

https://square.github.io/okhttp/security/security/#verifying-artifacts

https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/KEYS.txt
https://downloads.apache.org/commons/KEYS
https://downloads.apache.org/logging/KEYS

I cloned the repo and did a "mvn clean install" then I got this:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jakarta.inject-api: Fatal error compiling: invalid flag: --release -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jakarta.inject-api: Fatal error compiling
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.MojoExecutionException: Fatal error compiling
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1145)
    at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:187)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.codehaus.plexus.compiler.CompilerException: invalid flag: --release
    at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess (JavaxToolsCompiler.java:173)
    at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile (JavacCompiler.java:174)
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1134)
    at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:187)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: java.lang.IllegalArgumentException: invalid flag: --release
    at com.sun.tools.javac.api.JavacTool.processOptions (JavacTool.java:206)
    at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:156)
    at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:107)
    at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:64)
    at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess (JavaxToolsCompiler.java:125)
    at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile (JavacCompiler.java:174)
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1134)
    at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:187)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)

I'm using

$mvn -version
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: D:\Dev\ApacheMaven\current-maven
Java version: 1.8.0_252, vendor: Azul Systems, Inc., runtime: D:\Dev\Java\jdk8x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Hi,

I’m a member of the Eclipse Foundation Security Team. I’ve analyzed this repository with Scorecard and StepSecurity to check if it was applying some supply chain security best practices.

The following issue(s) has(ve) been detected:

• Properly use a dependency update tool, like Dependabot

As a result, you will see some PRs coming both from me and/or the StepSecurity bot to provide fixes for those issues. This issue will serve as the parent for those PRs.

Thanks!

Francisco Perez

Describe the bug
The classes in the jakarta.inject api JAR have Java 5 byte code instead of Java 8 byte code.

To Reproduce
javap -v -classpath jakarta.inject-api-2.0.0.jar jakarta.inject.Inject | grep "major version"
major version: 49
javap -v -classpath jakarta.inject-api-2.0.0.jar jakarta.inject.Named | grep "major version"
major version: 49
javap -v -classpath jakarta.inject-api-2.0.0.jar jakarta.inject.Provider | grep "major version"
major version: 49
javap -v -classpath jakarta.inject-api-2.0.0.jar jakarta.inject.Qualifier | grep "major version"
major version: 49
javap -v -classpath jakarta.inject-api-2.0.0.jar jakarta.inject.Scope | grep "major version"
major version: 49
javap -v -classpath jakarta.inject-api-2.0.0.jar jakarta.inject.Singleton | grep "major version"
major version: 49

Expected behavior
Jakarta EE 9's minimum Java level is Java 8. As such all API jars should have Java 8 byte code. All other API JARs for the Jakarta EE 9 features have classes with Java 8 byte code. As you see above the major version is 49. It should be 52 for Java 8 byte code.

Additional context
From looking at other projects, the following needs to configured in the pom.xml

        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>

If the community is to succeed in migrating to java modules then the basic dependencies such as javax.inject or jakarta.inject should at least reserve their automatic module name.

See http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-October/013233.html for a discussion on what that name could be. Suggested: 'java.inject'

A new release on maven central of jakarta.inject 1.0 should become available.

(also logged in javax-inject/javax-inject#33 some time ago)

Is your feature request related to a problem? Please describe.
Now that #20 is merged, we have a proper module-info.class starting with version 2.0.1. Great job! 💪

However, this only targets the 2.x branch with its jakarta namespace. Many libraries still use the javax.inject.* package and don't want any breaking changes.

Describe the solution you'd like
I'd therefore propose to backport the module-info to 1.x using the module name java.inject and export package javax.inject.

Describe alternatives you've considered
Convince library vendors to switch to jakarta namespace. Even if successful, this would delay adoption until the next major version to avoid breaking changes.

Additional context
We have discussed potential compatibility issues with older Java versions in #20 and decided to use the MR-Jar approach to avoid such problems.

The main package of this API is "jakarta.inject".

We already have another project in Jakarta called Jakarta Contexts and Dependency Injection, which makes it sometimes confusing this one is officially called "Dependency Injection" too. As the name for this project was also often "@Inject", "Jakarta Inject" might be a better and simpler name.

Is your feature request related to a problem? Please describe.
At current moment jakarta-inject library have Automatic-Module-Name attribute, if we using boot classloader it's ok.

But when multi-classloader env, resolving automatic modules have problem. Problem in this jdk code https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/module/Resolver.java#L160

For example:

• App-Container start with self modules (which resolved by default due, java start with -p/-m arguments)
• App-Container want initialize app1 in own classloader, and create ModuleLayer for it.
• App-Container load all jars from app1 and want resolve it by Resolver. But due some limitation - not all jars must be initialized as modules (java.lang.module.Configuration#resolve parameter roots, what modules must be resolved).
• And then we try to resolve jakarta-inject inside app1 which for now automatic-module. And jdk will resolve ALL automatic modules (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/module/Resolver.java#L160) and it will resolve all not targeted modules

Describe the solution you'd like
Add module-info class file to jar file. It can be placed in jar root, or in META-INF/versions/9/, old jvms skip this file anyway.

There many ways how generate it. Check gson library or log4j2.

Also up release to 9 target.

I use own maven-plugin which generate module-info, and place it to target directory (https://github.com/consulo/java9-maven-plugin)

Describe alternatives you've considered
Leave as is Automatic-Module-Name

Thanks

Is your feature request related to a problem? Please describe.
The CDI specification recommends that @Named is not used as a qualifier at injection points. However, the Javadoc for @Named merely says that it's a string based qualifier and gives an example of it's use in this context.

CDI uses @Named to assign a bean name for lookup from technologies like JSF. Bean names mostly have to be unique among the application.

Describe the solution you'd like
Can we add a note to the @Named annotation indicating that CDI recommends against its use as a qualifier for injection points?

Describe alternatives you've considered
We could just remove the example showing @Named used in the way that CDI recommends against.

We could do nothing and acknowledge that the choice to have shared injection annotations means that the Javadoc can't be as helpful to users as we'd like.

Additional context
I realise that there are other consumers of @Named other than CDI (I'm aware of Spring and Guice). Any guidance for use in CDI would have to be written in a way that doesn't mislead users of these technologies.

In the steering committee we voted to moved all specification projects from eclipse-ee4j to jakartaee. As such this repo should move to in due time.

Moving is fairly automatic, and redirects will be automatically put in place from the current location here to the new location.

Extra from: https://www.eclipse.org/lists/jakarta.ee-spec/msg02073.html

"We voted on it in 2019 and then in 2020 we added it explicitly to our 2021 plan and voted on that plan. I think we just need to start executing. I sent about 30 emails like the following in an attempt to add some shape to it and kick off the move in the spec projects.

• https://www.eclipse.org/lists/jakartaee-platform-dev/msg02940.html
• https://www.eclipse.org/lists/messaging-dev/msg00028.html
• https://www.eclipse.org/lists/jakartaee-tck-dev/msg01417.html
• https://www.eclipse.org/lists/ejb-dev/msg00264.html
  "

Also note that many projects have indeed moved: https://github.com/jakartaee/

The release 1.0.1 is not OSGi compatible. The release candidates for version 2 are OSGi compatible.

Because the package declaration was changed in version 2, bundles of that version are incompatible with any library which rely on the javax.inject package served directly from older JDKs.

The following feature branch already exists in this repository, which seems to add the maven-bundle-plugin to generate OSGi-relevant metadata. Please provide a new version e.g., 1.0.2, with those changes applied to enable OSGi compatibility even for the version 1 library.

https://github.com/eclipse-ee4j/injection-api/tree/ee8

Thx!

Instructions

• Update text files
• Generate "boilerplate" specification project
• Make a staging release
• Generate Stand-alone TCK test results
• Create a PR to jakartaee/specifications repository
• Update the Jakarta EE API jar by submitting a PR to the jakartaee-api project
  jakartaee/jakartaee-api#21

Details are here:

Describe the bug
A project I work on has an automatic dependency update mechanism, based on patch versions. According to semantic versioning, backward compatibility is maintained.

But to my surprise, using jakarta.inject-api 1.0.2 over 1.0.1 broke the compilation. It has to do with all the package renaming from javax.inject to jakarta.inject for the annotations. Of course the build is breaking.

I noticed in mvnrepository that 2 versions were released around the same time, a 2.0.0 and a 1.0.2.
Was the 1.0.2 wrongly released by containing 2.0.0 code?

To Reproduce
Steps to reproduce the behavior:

1. Have a project depending on jakarta.inject-api 1.0.1 and classes using the annotations like @Qualifier, @Singleton or @Named
2. Update the dependency to 1.0.2
3. Compile and see compilation errors because symbol not found.

Expected behavior
The project compiles after jakarta.inject-api patch version update

Screenshots
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project my-project: Compilation failure: Compilation failure:
[ERROR] D:\my-project\src\main\java\package\MyClass.java:[8,19] error: package javax.inject does not exist
[ERROR] D:\my-project\src\main\java\package\MyClass.java:[19,1] error: cannot find symbol

A requirement for the EE10 release is for API jars to include a proper module-info.class. This is here to track the final release.

jakartaee/platform#421

• get api jar from maven, ie https://repo1.maven.org/maven2/jakarta/inject/jakarta.inject-api/1.0/jakarta.inject-api-1.0.jar
• check that some license and notice file is included in the jar, preferably under META-INF folder

=> no license nor notice file found. These files are required to be present in the main distribution jar as well as source jar, see https://www.eclipse.org/projects/handbook/#legaldoc-distribution for details

@starksm64 I noticed, Jakarta Dependency Injection was already in Jakarta EE 8, but the package namespace remains javax.inject.

Was this a fork? I assume the Apache License allows that as long as you keep the names or the original authors there, just curious, but I trust it was where necessary also approved by Oracle and the JCP (EC).

The jakartaee/cdi#584 issue needs updates to the DI javadoc.

The following is invalid:

@Inject
record Heater(Logger logger) {
    void heat() {
        logger.log("~ ~ ~ heating ~ ~ ~");
    }
}

To make it work, we have to convert the record to a class and annotate the constructor instead:

final class Heater {
    private final Logger logger;
    @Inject 
    Heater(Logger logger) {
        this.logger = logger;
    }
    void heat() {
        logger.log("~ ~ ~ heating ~ ~ ~");
    }
}

This is tedious. We should be able to inject into records, it would be equivalent to constructor injection.

Currently the @Inject annotation has @Target({ METHOD, CONSTRUCTOR, FIELD }). I think if we add TYPE to that list, then the annotation would be allowed on records too and injection frameworks like dagger and spring can start supporting that. TYPE has been around since 1.5, so a Java version update would not be necessary.