Imported Packages : com.day.cq.wcm.api,version=[1.29,2) and org.apache.sling.api.resource,version=[2.12,3) -- Cannot be resolved - osgi

I am facing a weird issue after creating the AEM project using the archetype 24 from https://experienceleague.adobe.com/docs/experience-manager-core-components/using/developing/archetype/overview.html?lang=en#available-properties
The project build successfully and deployed perfectly and somehow the osgi bundle is not "Active" because of below issue in bold: com.day.cq.wcm.api,version=[1.29,2) -- Cannot be resolved and org.apache.sling.api.resource,version=[2.12,3) -- Cannot be resolved
Imported Packages:
**com.day.cq.wcm.api,version=[1.29,2) -- Cannot be resolved**
**org.apache.sling.api.resource,version=[2.12,3) -- Cannot be resolved**
I have tried to add these dependencies in the parent pom finding in http://localhost:4502/system/console/depfinder
Somehow my efforts failed to resolve this issue, could anyone help me to resolve the issue.
thanks in advance

What you did to "solve" the issue is telling your bundle to accept any version of the packages. This very likely will cause problems later as you might get an incompatible implementation.
Instead what you should do is use the system console bundle view in AEM/sling to find out which versions of the packages are offered by the bundles. Probably the versions are lower than 1.29 and 2.12.
So the correct solution would be to use an older version of the archetype that matches the versions offered by your AEM/sling system.

Please change the language of the website to English and read the article here: https://flagtick.com/post/getting-started-with-aem-sites-setup-project-eduzone-system-part-7
It might help you a little bit.
</executions>
<dependencies>
<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.caconfig.bnd-plugin</artifactId>
<version>1.0.2</version>
</dependency>
</dependencies>
</plugin>

I had same problem with archetype 26.
resolved by adding this dependencies inside core/pom.xml
<!-- https://mvnrepository.com/artifact/com.day.cq.wcm/cq-wcm-api -->
<dependency>
<groupId>com.day.cq.wcm</groupId>
<artifactId>cq-wcm-api</artifactId>
<version>5.9.4</version>
<scope>provided</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.api -->
<dependency>
<artifactId>org.apache.sling.api</artifactId>
<version>2.18.4</version>
<groupId>org.apache.sling</groupId>
<scope>provided</scope>
</dependency>

Related

Flex Maven project compilation error: Global artifact is not available. Make sure to add 'playerglobal' or 'airglobal' to this project

I am converting an existing flex project to a maven project using the IntelliJ IDEA. As per the R&D on google, I have added the pom.xml file and I have resolved multiple issues by adding the required dependencies. However, I am stuck at one point now where despite adding the required dependency in pom file, the 'compile' goal keeps throwing error.
Error:
Failed to execute goal
net.flexmojos.oss:flexmojos-maven-plugin:7.1.0:compile-swf
(default-compile-swf) on project TA_UI_Test1:
java.lang.reflect.InvocationTargetException: Global artifact is not
available. Make sure to add 'playerglobal' or 'airglobal' to this
project. -> [Help 1]
pom.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>TA_UI_Test1</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>swf</packaging>
<name>TA_UI_Test1 Flex</name>
<build>
<sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
<groupId>net.flexmojos.oss</groupId>
<artifactId>flexmojos-maven-plugin</artifactId>
<version>7.1.0</version>
<extensions>true</extensions>
<configuration>
<sourceFile>Main.mxml</sourceFile>
<debug>true</debug>
<!--<swfVersion>11</swfVersion>-->
<!--<targetPlayer>10.2</targetPlayer>-->
</configuration>
<dependencies>
<dependency>
<groupId>com.adobe.flex</groupId>
<artifactId>compiler</artifactId>
<version>4.6.b.23201</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.adobe.flex.compiler</groupId>
<artifactId>flex-compiler-oem</artifactId>
<version>4.1.0.16076</version>
</dependency>
<dependency>
<groupId>com.adobe.flex.compiler</groupId>
<artifactId>mxmlc</artifactId>
<version>4.1.0.16076</version>
</dependency>
<!--<dependency>-->
<!--<groupId>com.adobe.flex.framework</groupId>-->
<!--<artifactId>playerglobal</artifactId>-->
<!--<version>10-3.3.0.4852</version>-->
<!--<type>swc</type>-->
<!--</dependency>-->
<!--<dependency>-->
<!--<groupId>com.adobe.flex.framework</groupId>-->
<!--<artifactId>playerglobal</artifactId>-->
<!--<version>4.5.1.21328</version>-->
<!--<classifier>10</classifier>-->
<!--<type>2.swc</type>-->
<!--</dependency>-->
<dependency>
<groupId>com.adobe.flex.framework</groupId>
<artifactId>playerglobal</artifactId>
<version>3.2.0.3958</version>
<classifier>9</classifier>
<type>swc</type>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.adobe.flex.framework</groupId>
<artifactId>flex-framework</artifactId>
<version>4.6.b.23201</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.adobe.flex.compiler</groupId>
<artifactId>asdoc</artifactId>
<version>4.6.b.23201</version>
</dependency>
<dependency>
<groupId>com.adobe.flex</groupId>
<artifactId>compiler</artifactId>
<version>4.6.b.23201</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.adobe.flex.compiler</groupId>
<artifactId>flex-compiler-oem</artifactId>
<version>3.6.0.16995</version>
</dependency>
<dependency>
<groupId>com.adobe.flexunit</groupId>
<artifactId>flexunit</artifactId>
<version>0.85</version>
<type>swc</type>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.adobe.flex.compiler</groupId>
<artifactId>mxmlc</artifactId>
<version>4.1.0.16076</version>
</dependency>
<!--<dependency>-->
<!--<groupId>com.adobe.flex.framework</groupId>-->
<!--<artifactId>playerglobal</artifactId>-->
<!--<version>10-3.3.0.4852</version>-->
<!--<classifier>10.2</classifier>-->
<!--<type>swc</type>-->
<!--</dependency>-->
<!--<dependency>-->
<!--<groupId>com.adobe.flex.framework</groupId>-->
<!--<artifactId>playerglobal</artifactId>-->
<!--<version>4.5.1.21328</version>-->
<!--<classifier>10</classifier>-->
<!--<type>2.swc</type>-->
<!--</dependency>-->
<dependency>
<groupId>com.adobe.flex.framework</groupId>
<artifactId>playerglobal</artifactId>
<version>3.2.0.3958</version>
<classifier>9</classifier>
<type>swc</type>
</dependency>
</dependencies>
</project>
Things I have tried:
1. I have added the required dependency of artifact playerglobal as seen in above pom.xml file, and I have tried with 3 different versions of it (seen above in pom). However, none of them helps.
2. I have tried adding playerglobal dependency inside the 'plugin' node, and also inside the common 'dependencies' node separately in pom. However, any of them are not helping. [Reason to try both these things is that for other couple of dependencies of flex-compiler-oem and mxmlc, it was not recognizing required classes when the dependencies were added just in the common 'dependencies' node. When I added them inside the 'plugin dependencies', then it moved on from those errors.]
3. As per this article, I have also tried keeping the 'com.adobe.flex > compiler' right after 'configuration' node. However, that also doesn't help.
4. I am using Maven 3.2.5 right now, but I have tried with various other maven versions like 3.3.9, 3.0.5, 3.1.1 too. They are also not helping. (3.3.9 is not supported for flexmojos-maven-plugin 7.1.0 as per this article. It also says that maven 3.2.5 is working fine though. Using maven 3.0.5 says that minimum required maven version is 3.1.1. And using maven 3.1.1 gives same error as I am getting right now with maven 3.2.5.)
My SDK/IDE versions:
Maven: 3.2.5
Flex: 3.2.0
JDK: 1.8
IntelliJ IDEA: Ultimate 2017.1
Any help would be greatly appreciated. Thanks in advance.
I don't know to what extent you’re familiar with using Flex in the Maven world, but there were many discussions on what to do with Flex in a post-Flash world (I haven’t had to deal with setting up and maintaining Flex Maven-based projects in about 5-6 years now). Basically, Adobe didn’t want to publish their artifacts to Maven Central, they used to have their own repositories. Then Adobe disowned their Flex project and contributed it to Apache (if I recall correctly, not all of it, but most of it). The guys at Apache re-worked things to a large extent and have been the ones developing it now.
To be honest, I haven’t followed up on Flex over the years, as I think there is no point in using it anymore, as with HTML5, Flex seems as an obsolete technology. The world is no longer using Flash and this has brought a lot benefits to everyone. However, this is just my opinion and I’m not a UI expert.
The guys at Apache decided not to reset the versions and continue where Adobe left – just the artifact coordinates were changed. The groupId-s are now org.apache.flex* (you can check the Apache Flex dependencies published here), instead of com.apache.*. These artifacts are now available via Maven Central. You should switch to a newer version of Maven and use at least 3.3.9.
For more on the history of the project (which is actually quite important, if you’d like to get a better understanding of the dependency mess and what’s now a point of truth and what’s not, please check here and here). The Flex documentation is now on the Apache site. This page is perhaps the most recent and detailed one that I could find, although I’m not 100% sure it’s up-to-date.
You will have to do some further reading up and investigation, but based on your example above, it looks like you're using very, very old versions of the Flex libraries. I would recommend using Maven Central's search engine and searching for each of the artifactId-s and replacing them with the most recent ones and seeing how that goes...
Good luck! :)
I have addressed above issue now. I came across some links which talked about mavenizing the Flex SDK, such as this and this. The second link is the one suggested by carlspring in his above answer; however, I could not follow its steps fully since the git URL mentioned in it is blocked in my company network. So I downloaded the code from the former link and created the mavenizer, and executed it as per the steps given in the link to generate the mavenized SDK. (I faced an issue in the mavenizer where the connection to external maven repository is done to check for updates, so I commented that code and created mavenized SDK successfully after that.)
After generating the Mavenized SDK, you just have to copy it in your local maven repository, and then the playerglobal/airglobal dependencies will successfully get resolved.
Note: In addition to the first link mentioned above, refer to this link as well, which has more detailed steps of mavenizing the Flex SDK. It helped me a lot in creating the folder structure properly.

unable to resolve dependency for akamai edgegrid API

I am trying to use akamai edgegrid API for invalidating akamai chache. I have added below dependency in my pom.xml, but my bundle keeps in installed state. Below are more details-
pom.xml dependency-
<dependency>
<groupId>com.akamai.edgegrid</groupId>
<artifactId>edgegrid-signer-apache-http-client</artifactId>
<version>2.1.0</version>
<scope>provided</scope>
</dependency>
Bundle is in installed state, on felix console it says-
Imported Packages com.akamai.edgegrid.signer -- Cannot be resolved
error.log says -
Unable to resolve 497.82: missing requirement [497.82] osgi.wiring.package; (osgi.wiring.package=com.akamai.edgegrid.signer)
You have used <scope>provided</scope> , it means this jar will be used during compile time and during run time it will use the jar available on the run time environment. Unfortunately edgegrid-signer-apache-http-client-2.1.0.jar is not available on the AEM instance.
To resolve the issue, Do not use <scope>provided</scope> .
Updated POM -
<dependency>
<groupId>com.akamai.edgegrid</groupId>
<artifactId>edgegrid-signer-apache-http-client</artifactId>
<version>2.1.0</version>
</dependency>
Before deploying the bundle on AEM, extract the jar and check edgegrid-signer-apache-http-client.jar , edgegrid-signer-core.jar, httpclient.jar, httpcore.jar should be part of the bundle.
Hopefully it will solve your issue. All the best.
Please let me know if you still face any issue.
-Mrutyunjaya

Vaadin std prod project includes vaadin-client-compiler and jetty?

I get vaadin-client-compiler artifact (which brings Jetty with it) included with my production project. Am I supposed to ?
To reproduce I'm starting from scratch and letting Maven generate a Vaadin multimodule project for me:
mvn
-DarchetypeGroupId=com.vaadin
-DarchetypeArtifactId=vaadin-archetype-application-multimodule
-DarchetypeVersion=7.6.2
-DarchetypeRepository=http://repo.maven.apache.org/maven2/
-DgroupId=com.acme
-DartifactId=VaadinTest1
-Dversion=1.0.0-SNAPSHOT
-Dpackage=com.acme.vaadintest1
-Dbasedir=D:\\dev\\java
-DthemeName=mytheme
-DwidgetsetName=MyAppWidgetset
-DuiName=MyUI
-Darchetype.interactive=false
--batch-mode archetype:generate
Then in the parent project I execute:
mvn -Pproduction clean install
After this is done I look into the WAR file generated in the "xxx-production" project and notice it contains vaadin-client-compiler, Jetty, and what not.
I've found this ticket and by looking at the last comment it seems I shouldn't have anything like that in my production WAR. I hesitate to change my POMs as they are generated by the archetype and I guess at some level supposed to represent kind of a Vaadin best-practice approach. I wouldn't want to second guess that. Or ?
The problem with these artifacts being part of the classpath is that
it balloons the size of the WAR
it creates some problems wrt Atmosphere which supposedly gets confused because it finds Jetty on the classpath. (Atmosphere is used under the hood by Vaadin)
The result is that you'll get SEVERE error like this in the log when deploying on Tomcat 8:
14-Feb-2016 16:42:30.368 SEVERE [localhost-startStop-1] org.atmosphere.cpr.DefaultAsyncSupportResolver.newCometSupport Failed to create comet support class: class org.
atmosphere.container.JettyServlet30AsyncSupportWithWebSocket, error: null
To sum up:
Is it correct that I'm not supposed to have these artifacts in a
Vaadin 7.6.2 production project ?
How to solve ?
I believe I've found the answer. It seems Vaadin team was/is fully aware of this but it is kind of a left-over from the old days when there was some kind of annoying bug.
In your xxx-widgetset project you'll see something like this in the POM for that project:
<dependencies>
<!-- Versions for these are configured in the parent POM -->
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client</artifactId>
<!-- TODO this should have scope provided once http://dev.vaadin.com/ticket/14788 is resolved -->
<!-- <scope>provided</scope> -->
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client-compiler</artifactId>
<!-- TODO this should have scope provided once http://dev.vaadin.com/ticket/14788 is resolved -->
<!-- <scope>provided</scope> -->
</dependency>
... you'll see more deps here if you've added
... Vaadin add-ons to your project.
</dependencies>
See the TODO comments ??
Well, it just so happens that the bug mentioned in ticket 14788 doesn't happen anymore, at least not on 7.6.2. So you can now safely do what the TODO comment says.
This has reduced my WAR size by 50-70 pct.
It seems to me there's no longer any good reason why this archetype generation doesn't actually do what TODO comment says. Currently you'll have to manually correct it every time you generate a new project skeleton.
If you work with a different webserver (in your case Tomcat 8) you don't need the provided jetty-plugin.
As the archetype has some jetty-dependencies you can exclude them with the
exclusions tag in the Maven POM file.
Example
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client-compiler</artifactId>
<version>${vaadin.version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlets</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-annotations</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-util</artifactId>
</exclusion>
</exclusions>
Moreover delete/comment out all unnecessary "jetty" dependencies found in the module POM files.

Unable to download saxon-he 9.5 with maven

Maven will not retrieve saxon 9.5, because it has two conflicting dependencies on jdom.
It turns out the second dependency :
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom</artifactId>
<version>2.0.4</version>
<optional>true</optional>
</dependency>
should probably have "jdom2" as artifactId.
Does anyone have suggestions on how to override this?
Yes indeed you are right. I have raised this as a bug issue on the Saxon community site:
https://saxonica.plan.io/issues/2056
We will address the problem as soon as possible.
To override dependencies in maven I suggest look at the following:
Override dependencies of third party jar in maven

Choosing dependency version in maven and maven plugin

I have a maven plugin which is using hsqldb 1.8.0.10. In my pom.xml from the plugin, it is declared like this:
<dependency>
<groupId>hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.10</version>
</dependency>
But if I run that plugin from another maven project, and that project has a newer version of hsqldb (for instance 1.9.0), how can I configure my plugin that he will use the newest version of hsqldb, without changing it's pom.xml?
And is it possible to do this the other way around as well? If my other maven project uses hsqldb 1.7.0 (for instance), that he will use the 1.8.0.10 version which is specified in the maven plugin itself?
I hope someone can answer my question.
Kind regards,
Walle
Your main question is possible, but it might not work properly if the plugin doesn't work with the newer code for any reason.
A plugin can have it's own personal dependencies section, and will use standard Maven dependency resolution, choosing the highest version requested. So, you can do
<plugin>
<groupId>some.group.id</groupId>
<artifactId>some.artifact.id</artifactId>
<version>someversion</version>
<dependencies>
<dependency>
<groupId>hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.9.0</version>
</dependency>
</dependencies>
</plugin>
I don't think going the other way around is possible, though.
use properties place holder for the version, say ${hsqldb.version} then declare in different project pom the version you want to put in it

Resources