Gradle package lookup is not perfectly working

[WilliamFreau]

Description of the bug

I have migrate a project from Maven to Gradle for Business reason. And some of my Npm dependencies was missing.

Build-System	vaadin.allowed-packaged in application.properties	vaadin.allowed-packaged in package.properties	Dependency is found
Maven	No information	vaadin.allowed-packaged=de.f0rce	Everything is working
Gradle	No information	vaadin.allowed-packaged=de.f0rce	Everything is working
Maven	vaadin.allowed-packaged=com.example	vaadin.allowed-packaged=de.f0rce	Everything is working
Gradle	vaadin.allowed-packaged=com.example	vaadin.allowed-packaged=de.f0rce	de.f0rce Npm package is not present in package.json

So a conflict appear in Gradle plugin. If the attribute vaadin.allowed-packages is specify in the application.properties then the lookup did not take care of the package.properties in found JAR

Feel free to ask more informations if needed

Expected behavior

The Gradle plugin had to be working the same way as the Maven plugin.

Find all required Node dependencies

Minimal reproducible example

https://github.com/WilliamFreau/Vaadin-GradleLookup-Problem

Load with maven or gradle
Start the ExampleApp wich display the AceComponent and a Div in the default View

Think to delete package.json and generated stuff between

Versions

• Vaadin / Flow version: 24.9.12 but I expected the same behaviour for Vaadin 25+
• Java version: 25 but not important
• OS version: W10 / W11 but not tested more
• Build-Tool: Gradle

[mcollovati]

Just a first note, based on the example project: the goal of package.properties is to define which packages inside the JAR file should be scanned or ignored; they are not instructions meant to be applied globally.

From the docs:

To optimize package scanning within a JAR file, add a META-INF/VAADIN/package.properties file inside the JAR to define JAR specific scanning rules.

That said, there should be no differences between Gradle and Maven, since the settings are read and used at runtime, not by the plugin itself. I'll investigate further.

[mcollovati]

Also note that those properties are not considered at all in package.json processing.

EDIT: now I see. We are talking about dev mode, so filters are taken into account by VaadinServletContextInitializer.DevModeServletContextListener that uses Spring to filter out the classes that will be computed by DevModeInitializer (DevModeClassFinder + NodeTasks)

[mcollovati]

Tested with Maven:

Running from IDE (whole project open):

• ExampleLIB is not referenced as JAR in classpath; the IDE points to its target/classes folder, so the package.properties file is not read (only JAR files are supported)
• com.example.JavaAceComponent is scanned and @f0rce/lit-ace added to package.json
• component shown in the browser

Running from CLI from Example-Frontend module (mvn spring-boot:run)

• ExampleLIB as JAR in classpath, package.properties read
• com.example.JavaAceComponent not scanned because allowed-packages lists onlye de.f0rce
• @f0rce/lit-ace added to package.json
• component shown in the browser

By fixing the package.properties file to allow com.example instead of de.f0rce the component is correctly loaded also using the CLI approach.

The same happens also for Gradle.

I would say that there has been a misunderstanding in how package.properties works. It does not define global filtering rules but rather defines which packages in the SAME jar should be filtered or included in the scanning process.

We should probably improve the documentation to make this clearer.

[mcollovati]

@WilliamFreau if what above doesn't sound correct to you, please provide detailed instruction on how to reproduce (using IDE or command line instructions, etc).
It might be that what I tested is different from what you are testing.

[WilliamFreau]

Hello @mcollovati , I understand my explain is not fully understandable.
I also apologize for the folowing comment wich is not easy to understand

First of all some context: I am making different usefull librairies for my company base on Vaadin. Some is full custom and some is a re-package or improvement of other librairies.
For exemple: Ace-Component with execution engine or Pdf.js integration.
My librairies is used by others teams who just take it, read my documentation and use it.

Normally, when you want to add element to package.json, you add the corresponding @NpmPackage on your file and by classpath lookup, the vaadin plugin will add everything needed. And as you mentioned, if the @NpmPackage annotation is not on you packages, with vaadin.allowed-package you can tell Vaadin to look also other package.

When a library is shared, like for Vaadin-Directory or for business purpose, since vaadin 24.5 you can add package.properties in your library in order to add element to the lookup and avoid some configuration on each final user.

In my case I add the package.properties file it into my ExampleLib in order to tell the vaadin plugin that I need to lookup de.f0rce package. Therefore any people that will use ExampleLib will not have to add the lookup for de.f0rce on each project.

Since the final application could be big, I also use the vaadin.allowed-package in the application.properties in order to speedup things.
Without it I take more than a minute to perform the lookup.
But with the optmization:

• Maven: No problem
• Gradle, the lookup did not take care of the package.properties

---

In order to understand the minimal reproductible project,

Here is a simple diagram with dependencies

The reference is perform in:

• For Maven: Example-Parent/Example-Frontend/pom.xml > line 21 - 25
• For Gradle: Example-Parent/Example-Frontend/build.gradle -> line 5

---

Here is how I have understand the package-lookup and how I have experiment it with maven and gradle

Since de.f0rce is not in com.example package, then the @NpmPackage inside the librairie is not found

---

Here is the package lookup with the package.properites in the ExampleLib

Since the lib contains package.properites with vaadin.allowed-package=de.f0rce then the lookup find the @NpmPackage and everything is working

---

When I add the optimisation in application.properties in order to scope the classpath lookup, I have spot a different behaviour between Maven and Gradle

Here it how I think the lookup differ

With the maven build, the lookup goes into ExampleLib, read the package.properties and also look into de.f0rce
However with the gradle plugin, the lookup for de.f0rce is not perform

---

Final section is command / how to reproduce

Reproduce with gradle:
Ensure no package.json, package-lock.json, tsconfig.json, types.d.ts, vite.config.ts, vite.generated.ts

Execute .\gradlew.bat :Example-Frontend:bootRun

Reproduce with maven:
I have unfortunatly not managed to perform it with a command. But

• Open with IntelliJ (Community is enough)
• Load project as Maven-Project
• Ensure no package.json, package-lock.json, tsconfig.json, types.d.ts, vite.config.ts, vite.generated.ts exists
• Start the Run-Configuration named: ExampleApp
  • Or just run the Main as Spring-Application

The problem is not linked to the AceEditor, but is also applicable for ErrorWindows, ApexCharts or any other that have @NpmPackage

Feel free to ask me more information as needed, or to explain to me what I am doing wrong

[mcollovati]

Just to clarify: the rules in the package.properties are applied only to the classes in the same JAR.
If you allow de.xxx then Vaadin, will scan classes from the JAR only if they match. If your jar contains classes in different packages (like in the example project) they will not be scanned.

This means that in your JAR you cannot add rules for classes in other jars.

However, if you extend an annotated class, as in your example project, and you allow your class package, the annotation will be found.

[WilliamFreau]

Hello,

I have perform different test in My Example project and In my work project.

I have mis-understand the package.properties purpose. From my point of view I was thinking it could be used to tweak the Frontend dependencies lookup base on JAR in classpath. So If my JAR tell to scan other package it will perform it.

Somehow filling the package.properties have solved some of my unfound dependencies in Maven world.

But in the Gradle world, the file is read and disable the lookup in my JAR for my classes so the frontend dependecies is not found.

However, I still think a bug is still present around this because the same configuration will create different package.json file based on Maven or Gradle as I point in my example project with these information:

Extract from my minimal project Readme file

Reproduce

Test the configuration with this project which is the same project based on Maven and Gradle Mind to delete package.json and package-lock.json in order to force the lookup
Command line
Gradle

Ensure no package.json, package-lock.json, tsconfig.json, types.d.ts, vite.config.ts, vite.generated.ts Execute .\gradlew.bat :Example-Frontend:bootRun

The generated package.json file [package-gradle.json](https://github.com/WilliamFreau/Vaadin-GradleLookup-Problem/blob/master/Example-Parent/Example-Frontend/package-gradle.json). This file did not contain de.f0rce package
Maven

Ensure no package.json, package-lock.json, tsconfig.json, types.d.ts, vite.config.ts, vite.generated.ts

With IntelliJ, load as Maven project Execute the ExampleApp run configuration

I have not managed to compile with dependencies in command line...

The generated package.json file [package-maven.json](https://github.com/WilliamFreau/Vaadin-GradleLookup-Problem/blob/master/Example-Parent/Example-Frontend/package-maven.json)

But I have not managed to fully understand it or find the perfect way to reproduce it.

[mcollovati]

I can see exactly the same behavior in Maven and Gradle.
As said before, if you load the Maven project in IntelliJ IDEA and run the application from there, the ExampleLib module is not added to the classpath as a JAR file, but directly pointing at the target/classes folder of the module. This causes the package.properties file to be ignored, because they are read only from JAR files.

You can test this by doing a mvn install on the root folder of your example project and then run mvn spring-boot:run from the Example_Frontend module (after cleaning all frontend files).
Once the application is started, open http://localhost:8080 in the browser and you should not see the component. Nor the @f0rce/lit-ace in package.json