Comments (16)
The problem seems to be inside generateErrorMsg, when it tries to load a class that contains SLF4J loggers. I commented out that section temporarily, so I can at least build my project.
from gradle-plugin-scr.
+1
from gradle-plugin-scr.
@liljerk Can you please submit a PR for the change?
from gradle-plugin-scr.
I wrote a test case to try to reproduce the issue, and can't. See writeBuildFile where I make sure to have a project with both this and logback in the classpath.
Is it truly failing the build, or just giving a warning message?
from gradle-plugin-scr.
I think it would occur if you include your own slf4j libraries, even if compile time only dependencies.
from gradle-plugin-scr.
it is failing the build. workaround introduced by @liljerk fixes the problem.
from gradle-plugin-scr.
Unfortunately I can't evaluate @liljerk's patch unless I have a test that manifests the problem, and I'm having an extremely difficult time reproducing this.
I copied & pasted the build files in the StackOverflow post, filled in the "obvious" missing pieces (settings.gradle, a service class with SCR annotations, etc.) and created a fully self-contained project that I've attached: scr-slf4j.zip
$ unzip ../scr-slf4j.zip
Archive: ../scr-slf4j.zip
inflating: build.gradle
creating: gradle/
creating: gradle/wrapper/
inflating: gradle/wrapper/gradle-wrapper.jar
inflating: gradle/wrapper/gradle-wrapper.properties
inflating: gradlew
extracting: settings.gradle
creating: submod/
inflating: submod/build.gradle
creating: submod/src/
creating: submod/src/main/
creating: submod/src/main/java/
creating: submod/src/main/java/testpkg/
inflating: submod/src/main/java/testpkg/SimpleService.java
$ ./gradlew build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build
:submod:compileJava
:submod:processResources UP-TO-DATE
:submod:classes
:submod:processScrAnnotations
:submod:jar
:submod:assemble
:submod:compileTestJava UP-TO-DATE
:submod:processTestResources UP-TO-DATE
:submod:testClasses UP-TO-DATE
:submod:test UP-TO-DATE
:submod:check UP-TO-DATE
:submod:build
BUILD SUCCESSFUL
Total time: 1.259 secs
Everything runs just fine: no warnings or failures. What's different/missing?
from gradle-plugin-scr.
I am trying this out on an actual AEM project that has bundle and content folders, which is an usual structure for an AEM project. Can you also try it? Some information http://www.aemcasts.com/aem/episode-1.html
I am using this plugin in conjunction with the cq-bundle plugin as well.
from gradle-plugin-scr.
@leoxy520 That's also what we have on my "real" (for pay) project. It is a huge collection of bundles and content folders distributed across multiple AEM packages all built with a multi-module Gradle build. It works perfectly for us (for well over three years), so I know that that configuration in-and-of-itself is not a problem.
There has to be something else going on.
If you can give an example project (either modify the one I provided or make a new one, obviously without revealing any proprietary information) that manifests the issue, then I'll have something tangible to test against.
from gradle-plugin-scr.
FWIW, in the sample project it's also using the the cq-bundle plugin -- it's a copy & paste of what you pasted on StackOverflow.
from gradle-plugin-scr.
Clone the sample project I created below to see the exception that gets thrown during processScrAnnotations. The problem is the static logger inside the Handler class. If you remove the static keyword the build will succeed.
https://github.com/liljerk/gradle-broken-scr-plugin
from gradle-plugin-scr.
Thanks, that gives me something I can work with.
from gradle-plugin-scr.
I've been able to create a test case for it, allowing me to fix it without breaking existing functionality (i.e., the safety check for interfaces). I hope to have a new version released today.
from gradle-plugin-scr.
Fixed in v1.1.0
from gradle-plugin-scr.
Thanks @jdigger
What's the deal with the interface check anyway? I've got a legacy codebase with a dozen or so References to classes that implement osgi.service.event interfaces, but aren't interfaces themselves, and some other References to abstract classes (like granite's UserPropertiesService), and they all seem to bind just fine.
from gradle-plugin-scr.
It works because is Felix being very "forgiving" with the spec. See http://wiki.osgi.org/wiki/Declarative_Services and https://felix.apache.org/documentation/subprojects/apache-felix-service-component-runtime.html
In addition to the use of interfaces just being a better general design, they also enable the runtime to do a lot more work and be more efficient. The same is true, of course, for the SCR processor itself since it will automatically populate the @Service({..})
for you with all implemented interfaces. It's not as vital to DS, but if you were to upgrade to OSGi Blueprint it absolutely requires interfaces so it can use proxies to handle the more flexible lifecycle management.
I did add a flag to disable the check, but by default it's off because it's not "proper" OSGi.
from gradle-plugin-scr.
Related Issues (9)
- com.twcable.gradle:gradle-plugin-scr:1.2.0 fails in java 11
- Use Netflix Nebula for testing
- Remove plugin order dependence
- NPE when sources don't contain any components HOT 1
- Option to turn off interface checking
- Skip interface reference check / default value HOT 1
- Separate output directories HOT 1
- Bintray. This service has now been sunset
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gradle-plugin-scr.