We Keep Coding

Gradle Plugin dependency

What is the exact dependency I need to develop a Gradle Plugin in Java? Ideally I would like to get it from a well-known repository such as Maven Central or similar.
I have a Maven project with a core functionality and I just added two extra plugins, one for Ant, one for Maven. They are already tested and working; easy! Now, I wanted to add a third module for a Gradle plugin to make this functionality also available from any Gradle project.
However, I can't find the exact dependencies I need to develop a Gradle plugin.
The Gradle docs (such as https://docs.gradle.org/current/userguide/java_gradle_plugin.html) are not very well written to say the least. They mention:
the gradleAPI() dependency
or the java-gradle-plugin dependency
But they are quite unclear... no group, no version (really?).
If anyone can enlighten me to where I can get these dependencies from, I would be very thankful.

Gradle's public and internal APIs, aka gradleApi(), are bundled with the Gradle distribution and not independently published and therefore not easily consumable by Maven builds. There's the pending epic #1156 (Ensure plugin cross-version compatibility by allowing a user to depend on gradlePublicApi()) that might help here.
Since Gradle plugins are best to be built with Gradle, a pragmatic solution is to invoke the Gradle build from Maven and attach the produced artifact to the Maven build. Andres Almiray (aalmiray) once described this in the blog post Running Gradle Inside Maven (Web Archive Link). He describes the following high level steps:
Create a new Maven module (e.g. gradle-plugin) and add attach it to the parent POM
In the POM of gradle-plugin add a dependency to your core module. Use the maven-dependency-plugin to store dependencies to the Maven build folder, e.g. target/dependencies.
Create the build.gradle, add a Maven repository that points to target/dependencies (step 2) and let it depend on the core module as well as gradleApi(). Implement the Gradle plugin.
Use the exec-maven-plugin to invoke the Gradle build.
Use the maven-resources-plugin to copy the Gradle built plugin jars to the standard Maven build folder.
Use the build-helper-maven-plugin to attach the copied jars to the Maven build.
Sample project to be found here (gradle-in-maven).

https://docs.gradle.org/current/userguide/custom_plugins.html#sec:custom_plugins_standalone_project
In here it is mentioned that it is gradleApi() and I know that this works (from experience). The localGroovy() on that page is only needed if your plugin code uses groovy (does not apply if you only use groovy in the build.gradle of your plugin).
java-gradle-plugin is a library that makes it a bit simpler to make plugins, it is not required though. I personally prefer using gradleApi only.
EDIT:
It appears I've misunderstood the question. Here are the steps to get gradleApi jar:
Create a Gradle project with your desired Gradle version.
Add implementation gradleApi() dependency.
Import/run the project once.
Go to your .gradle folder (located in home folder in Linux-based operating systems).
Open caches folder
Open the version folder you want, e.g. 6.0.1
Open generated-gradle-jars folder.
Copy the jar to wherever you want and use it.
For me the 6.0.1 jar is at ~/.gradle/caches/6.0.1/generated-gradle-jars/gradle-api-6.0.1.jar
Please note that I have not tested this, I know the jar is there but I haven't tried using it.

Install AspectJ Eclipse

I'm trying to get started with aspect oriented programming.
I'm using latest eclipse (currently 12-2019)
public aspect Observer {
}
This Results in an error
Syntax error on token "aspect", interface expected
According to https://www.eclipse.org/ajdt/downloads
I added
http://download.eclipse.org/tools/ajdt/43/update
as an update site to eclipse
However eclipse tells me that some parts could not be installed
It looks Like some parts are missing
Cannot complete the install because one or more required items could
not be found. Software being installed: AspectJ Development Tools
2.2.3.e43x-RELEASE-20130627-0800 (org.eclipse.ajdt.feature.group 2.2.3.e43x-RELEASE-20130627-0800) Missing requirement: AspectJ 1.7.3.20130613144500-a (org.aspectj.ajde 1.7.3.20130613144500-a) requires 'osgi.bundle; org.eclipse.core.runtime.compatibility 0.0.0'
but it could not be found Cannot satisfy dependency:
From: AspectJ Compiler 1.7.3.20130613144500-a (org.aspectj.feature.group 1.7.3.20130613144500-a)
To: org.eclipse.equinox.p2.iu; org.aspectj.ajde [1.7.3.20130613144500-a,1.7.3.20130613144500-a] Cannot satisfy
dependency:
From: AspectJ Development Tools 2.2.3.e43x-RELEASE-20130627-0800 (org.eclipse.ajdt.feature.group 2.2.3.e43x-RELEASE-20130627-0800)
To: org.eclipse.equinox.p2.iu; org.aspectj.feature.group [1.7.3.20130613144500-a,1.7.3.20130613144500-a]
How could I Get Aspects to run in Eclipse?
Could you help me out?

Your problem caused by the removal of org.eclipse.core.runtime.compatibility plugin from Eclipse 4.6 .
Read more about this problem here.
The correct solution is to:
Install AspectJ from the correct download link.
The most updated to Eclipse 4.10 is: http://download.eclipse.org/tools/ajdt/410/dev/update
Another solution is to:
Uninstall Eclipse.
Install Eclipse 4.3 (matching your AspectJ version) .
Retry AspectJ install.
The more complex solution is:
Locate and build/extract org.eclipse.core.runtime.compatibility jar file from Maven repository.
Put org.eclipse.core.runtime.compatibility jar file into Eclipse plugins directory.
Run eclipse in --clean mode to rebuild and register the added plugin.
Retry AspectJ install.
You might encounter more missing dependencies for org.eclipse.core.runtime.compatibility, eventually will have to load all the related plugins (long effort).

Eclipse plugin code can't find "javax.inject.Inject" class, plugin jars now not in plugins directory

I'm trying to debug an Eclipse plugin that developed a bug around the 2019-09 timeframe. Something must have changed in the platform that causes it not to work anymore.
I can run the rcp 2018-12 distro and test it, and I verify that it works. I was able to step through the handler code.
If I run the 2019-12 distro, I can't fully compile the project, as it says "The type javax.inject.Inject cannot be resolved.". When I try to open type javax.inject.Inject in the 2018-12 distro, it finds it in "eclipse/plugins/javax.inject_1.0.0.v20091030.jar" in the distro. When I inspect that "plugins" directory, I find lots of separate plugin jars.
In the 2019-12 distro, it can't find javax.inject.Inject, and when I look in that plugins directory, I only find a single jar, the "org.eclipse.equinox.launcher" jar.
I remember this subject of the single launcher jar, but I don't know if this is a direct cause of this compile error, or what I have to do to move forward.
Update:
In response to the much appreciated answer, here's what I found:
I do find a ~/.p2 directory, and I found the javax.inject plugin in there. When I inspect the "Target Platform" settings, I see very similar information in both the 2018-12 and 2019-12 instance (plugin count varies by a very small number).
I inspected all of the MANIFEST.MF files, and none of them have a single "Import-Package" statement. I understand the advice is to add one, but I'd like to understand why I'm NOT seeing an error in 2018-12.
When I look at the "Plug-in Dependencies" list in the Project Explorer, I see "javax.inject" in the list in 2018-12, but I don't see it in 2019-12.
When I select the MANIFEST.MF file and view it in the form mode and select "Dependency Analysis" and then "Show the plug-in dependency hierarchy", I can then see that "org.eclipse.core.runtime", which is version 3.15... in 2018-12 and version 3.17... in 2019-12 has different dependencies. In particular, in 3.15, one of the dependencies is "javax.inject". In 3.17, that is not one of its dependencies.
So, I can see that a possible solution is definitely to add an "Import-Package" for "javax.inject", but can you explain why it might be that NONE of the MANIFEST.MF files have a single "Import-Package" statement as of yet?

If you are using an Eclipse installed with the Oomph installer the plugins can be in a different location (the .p2 direcory in your home directory I think). The javax.inject plugin should still be present along with all the other Eclipse plugins.
Plugins normally reference javax.inject using Import-Package in the MANIFEST.MF rather than specifying the required plugin use Require-Package so:
Import-Package: javax.inject
There haven't been any significant changes in this area between 2018-12 and 2019-12. The version of javax.inject is still exactly the same.
Check what you have configured as your Target Platform (Preferences > Plug-in Development > Target Platform) - that determines what plug-ins are available.
Update:
The reason you now need to add the Import-Package is the change made by Eclipse bug 487676 which removed the 're-export' of the javax.inject dependency from org.eclipse.core.runtime so that you now have to explicitly add it. This is also documented in the Whats New for Eclipse 2019-09 (4.13)

How to identify and build a JBoss java application from 2007?

I have a java application written in 2007-2010 that I need to build and run.
I am unable to open it in netbeans or eclipse.
Some identifying features of the source code:
It has a maven.xml and project.xml file (not pom.xml) in root
It has a jndi.properties, launch.properties and project.properties file in root
it has a .project and .jupiter file in the root directory
It is currently running in prod in a Jboss container
Are these indicators of some application framework from the late 2000s that someone can identify?
I am hoping to be able to open it in an IDE and build it.

It's a Maven 1 architecture.
[project.xml] Project Object Model (POM) definition
[maven.xml] Custom build scripts
[project.properties] general build settings
[build.properties] local build settings
Here you can see some more information and how to migrate it to Maven 2: Maven 1 to Maven 2
And here is some information on Maven's website about Maven 1: Quick start to Maven 1
Notice that it isn't supported anymore.
.project possibly indicates it's been built with Eclipse
.jupiter probably indicates that they used the code reviewer plugin Jupiter
All that said, I believe you could import it as an Eclipse project. Just pay attention on which Java version to use and which Eclipse and Maven as well.
I'd strongly recommend you to migrate to a newer version of Maven, but I also know how legacy software can be impacted by such migration, so it's up to you which way to go through.

Gradle unable to find downloaded dependency packaged as OSGi bundle (non-OSGi app)

(Edited for clarification)
My (non-OSGi) application build is in Gradle, and I am trying to upgrade from very old version of Jersey (1.1.4.1) to something much newer (1.12?). I do not pretend to know anything about using OSGi. But when I point my Gradle dependencies (with $JERSEY_VERSION set to "1.12") to:
[group: 'com.sun.jersey', name: 'jersey-server', version: "$JERSEY_VERSION"]
it downloads the jersey-server-1.12.jar into my Gradle dependencies cache under a "bundles" directory instead of the normal "jars" directory, and then Gradle seems to not include this jar in its classpath like it would if it were under a "jars" subdirectory instead.
I discovered it went under "bundles" because the POM has it labeled as an OSGi enabled jar. I do not think we are going to want to OSGi-ify our project. Am I stuck with older versions of Jersey, or is there anything else I can do to get Gradle to see the Jersey jar? I would prefer to not manually copy the file to a local repo if possible, but rather somehow depend on the dependency management capabilities of Gradle if it is up to the task.

OSGi bundles are normal jars with extra manifest entries. You should be able to use them in a non OSGi project as you would any other dependency. Is it a problem that they end up in the cache's bundles directory?

'Twas a silly oversight: moving from 1.1.4.1 to 1.12, the POM dependencies changed, so that jersey-core.jar was no longer being brought in implicitly. I had to add jersey-core.jar explicitly. I had assumed the problem was the fact that jersey-server.jar was being imported as a bundle, but I was really just getting a ClassNotFoundException for a class that was in jersey-core.jar.