I'm trying to update only a single package and its dependencies. When I try a dry-run, it correctly seems to list all the packages that need updating:
> composer update drupal/core --with-dependencies --dry-run
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 17 updates, 0 removals
- Updating guzzlehttp/psr7 (1.3.1) to guzzlehttp/psr7 (1.4.2)
- Updating guzzlehttp/guzzle (6.2.2) to guzzlehttp/guzzle (6.2.3)
- Updating symfony/class-loader (v2.8.17) to symfony/class-loader (v2.8.18)
- Updating symfony/debug (v2.8.17) to symfony/debug (v2.8.18)
- Updating symfony/console (v2.8.17) to symfony/console (v2.8.18)
- Updating symfony/dependency-injection (v2.8.17) to symfony/dependency-injection (v2.8.18)
- Updating symfony/http-foundation (v2.8.17) to symfony/http-foundation (v2.8.18)
- Updating symfony/event-dispatcher (v2.8.17) to symfony/event-dispatcher (v2.8.18)
- Updating symfony/http-kernel (v2.8.17) to symfony/http-kernel (v2.8.18)
- Updating symfony/process (v2.8.17) to symfony/process (v2.8.18)
- Updating symfony/routing (v2.8.17) to symfony/routing (v2.8.18)
- Updating symfony/serializer (v2.8.17) to symfony/serializer (v2.8.18)
- Updating symfony/translation (v2.8.17) to symfony/translation (v2.8.18)
- Updating symfony/validator (v2.8.17) to symfony/validator (v2.8.18)
- Updating symfony/yaml (v2.8.17) to symfony/yaml (v2.8.18)
- Updating twig/twig (v1.31.0) to twig/twig (v1.33.0)
- Updating zendframework/zend-feed (2.7.0) to zendframework/zend-feed (2.8.0)
However, when I run the same command without --dry-run, no packages get updated:
> composer update drupal/core --with-dependencies
Gathering patches for root package.
Dependency "asm89/stack-cors" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "composer/semver" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "doctrine/annotations" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "doctrine/common" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "easyrdf/easyrdf" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "egulias/email-validator" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "guzzlehttp/guzzle" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "masterminds/html5" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "paragonie/random_compat" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "stack/builder" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony-cmf/routing" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/class-loader" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/console" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/dependency-injection" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/event-dispatcher" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/http-foundation" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/http-kernel" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/polyfill-iconv" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/process" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/psr-http-message-bridge" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/routing" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/serializer" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/translation" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/validator" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "symfony/yaml" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "twig/twig" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "zendframework/zend-diactoros" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Dependency "zendframework/zend-feed" is also a root requirement, but is not explicitly whitelisted. Ignoring.
Shouldn't the --with-dependencies-switch whitelist all dependencies of drupal/core, causing those to be updated as well?
The cause of this is that Drupal (drupal/drupal) specifically merges core/composer.json into the project (root) composer.json.
"extra": {
"merge-plugin": {
"include": [
"core/composer.json"
],
"recurse": false,
"replace": false,
"merge-extra": false
},
This causes the drupal/core dependencies to be treated as root dependencies, resulting in the "X is also a root requirement, but is not explicitly whitelisted. Ignoring." errors.
As a workaround, either update the full project via composer update or disable the merge section of your composer.json file.
Related
I have the following dependencies that unfortunately requires some classes which are not present on the default packages. First it is 'spring-cloud-starter-sleuth', when I add the local maven jar updated to version 3.1.5 it requires 'brave-context-slf4j' version 5.14.1 and I have added them without problems.
The problem is the standard dependencies which includes those jars e.g 'spring-cloud-dependencies' should exclude the other versions so this way I can use only spring-cloud-starter-sleuth:3.1.5 and brave-context-slf4j:5.14.1.
How could I add those exclusions to that dependencies?
Known: npm
I am used to npm and JavaScript and whenever the dependency tree changes, there is a changed package-lock.json generated. This file includes all dependencies and their transitive dependencies with resolved/fixed versions.
Unknown: mvn
Now i have to use Maven and Java.
The question is: What's the maven-equivalent of npms package-lock.json?
I would need this information as to efficiently track which exact versions of (transitive) dependencies are contained in my project/bundle.
In Maven you usually do not use version ranges - so you'll always have a defined version for a dependency. If you want to change the version of a transitive dependency you can do this using the dependencyManagement block (which is similar to the new npm overrides).
If you want a report of the exact dependencies used check out the Maven Dependency Plugin. You can run a mvn dependency:tree to see all dependencies (with relations) including versions.
For more information about Maven dependency mechanism see Introduction to the Dependency Mechanism
2.8 together with its cxf feature 3.3.5, with cxf-jaxrs which is installed as feature comes a dependency to Google Guava 20.0. I have my own project where I install a couple of jars via Karaf feature, among them a Google Guava 18.0. The bundle I want now to install has a Google Guava dependency for 18.0, however i get the following error:
Chain 1:
arcanite-core [arcanite-core [269](R 269.0)]
import: (&(osgi.wiring.package=com.google.common.collect)(version>=18.0.0)(!(version>=19.0.0)))
|
export: osgi.wiring.package: com.google.common.collect
com.google.guava [com.google.guava [253](R 253.0)]
Chain 2:
arcanite-core [arcanite-core [269](R 269.0)]
import: (&(osgi.wiring.package=com.querydsl.core)(version>=4.2.0)(!(version>=5.0.0)))
|
export: osgi.wiring.package=com.querydsl.core; uses:=com.google.common.collect
com.querydsl.core [com.querydsl.core [255](R 255.0)]
import: (&(osgi.wiring.package=com.google.common.collect)(version>=18.0.0))
|
export: osgi.wiring.package: com.google.common.collect
com.google.guava [com.google.guava [172](R 172.0)] Unresolved requirements: [[arcanite-core [269](R 269.0)] osgi.wiring.package; (&(osgi.wiring.package=com.querydsl.core)(version>=4.2.0)(!(version>=5.0.0)))]
In my imports for the project I have explicitly imported the 18.0 version:
<Import-Package>
...
com.google.common.collect;version="[18.0,19.0)",
*
<Import-Package>
How can I get rid of this conflict, is this really about having only one version of Guava in Karaf ( OSGI ), what am i doing wrong?
Ok that was a tricky one, as said the cxf-feature made up a dependecy to Guava 20.0.
Then installing my own feature with query-dsl and guvava 18.0 jar inside.
But the dependency querydsl to guava was not resolved according to maven, but according to the already existing guava in karaf so 20.0.
When i now install a bundle with query-dsl and guava 18.0 then there is the conflict.
In the end i removed 18.0 library from the feature and allowed a larger version range in my project:
...
com.google.common.collect;version="[18.0,23.0)",
*
And the conflict was gone, makes me wonder how would i specify such a dependency, here between querydsl and guava 18.0 in the feature.xml, if possible at all.
I have got the project for migration. Currently, version is CQ5.6. Maven build is deploying successfully. However, after build, bundles in osgi show in installed state. Two dependencies causing the issue.
org.apache.felix.shell,version=[1.0,2) -- Cannot be resolved
I was getting an error earlier as below during build.
ERROR
[INFO] --- maven-bundle-plugin:2.3.4:bundle (default-bundle) # myPRJ-taglib ---
[ERROR] Error building bundle com.mypack.deewealth:myPRJ-taglib:bundle:1.0.0-SNAPSHOT : Unresolved references to [org.apache.felix.shell] by class
(es) on the Bundle-Classpath[Jar:dot, Jar:OSGI-INF/lib/recaptcha4j-0.0.8-kohsuke-1.jar, Jar:OSGI-INF/lib/commons-io-2.1.jar, Jar:OSGI-INF/lib/commons-
lang-2.4.jar, Jar:OSGI-INF/lib/crx-packagemgr-1.0.22.jar, Jar:OSGI-INF/lib/squeakysand-osgi-0.4.0.jar, Jar:OSGI-INF/lib/jsoup-1.6.1.jar, Jar:OSGI-INF/
lib/stax-api-1.0-2.jar, Jar:OSGI-INF/lib/org.apache.sling.settings-1.1.0.jar, Jar:OSGI-INF/lib/cq-compat-runmode-0.2.0.jar, Jar:OSGI-INF/lib/commons-c
ollections-3.2.1.jar, Jar:OSGI-INF/lib/squeakysand-jsp-0.4.0.jar, Jar:OSGI-INF/lib/squeakysand-commons-0.4.0.jar]: [org/apache/sling/settings/impl/Run
ModeCommand.class]
To solve this I added below dependancy in pom.xml, as we added in
Dependency
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.shell</artifactId>
<version>1.4.2</version>
<scope>provided</scope>
</dependency>
Under import statement.
<Import-Package>
....
....
org.apache.felix.shell
</Import-Package>
After that, build was successful, but bundle was in resolved state because of
org.apache.felix.shell,version=[1.0,2) -- Cannot be resolved
Any suggestion, why this is causing the problem.
org.apache.felix.shell,version=[1.0,2) -- Cannot be resolved
mean that you are trying to use these felix packages from within AEM. However - there are no OSGi bundles in AEM that exports these packages.
You can download the bundle from maven repo and upload it into the AEM Felix console and use it.
OR you can create it as your parent pom dependency as one of module and wrap along with your project jar and use it.
To veify the availability of any package and dependencies use AEM Dependency finder.
I don't know CQ but I can explain why this happens in general. You had the error during build time because of missing dependency. You correctly solved it by adding the dependency which fixed your build. What happened behind the scenes is your bundle was updated with information that it needs (imports) org.apache.felix.shell,version=[1.0,2) package and that package will be provided by some other bundle at runtime.
Then at runtime the resolver got that information and tried to find a bundle that provides (exports) org.apache.felix.shell,version=[1.0,2) package. It couldn't find one and so the resolution failed and your bundle was left in installed (I believe that's what you meant to write instaed of resolved in your last sentence) state!
To solve that, you need to make sure org.apache.felix.shell,version=[1.0,2) package is available at runtime. I don't know CQ and how to install bundles in it but since you can install your own bundle I assume you can also install org.apache.felix.shell bundle the same way.
The shell jar you have installed is still unresolved as it depends on some jars that might not be present. You need to find the depth of all dependencies and resolve them.
I am using AEM 5.6.1. I am getting an exception with JAXB my bundle when a jax-b api 2.2.12 manually is installed in console. As JAX-b(2.1.0) is already provided internally in AEM by below bundle. This exception doesn't happen when the 2.2.12 is not present. Also, if jax-b 2.2.12 is installed after my bundle, no problems at all.
However this new version is being used by another bundle developed by a different vendor. Hence I can't remove this new bundle from felix console.
The system bundle which provides the original JAX-B 2.1.0
`<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.fragment.xml</artifactId>
<version>1.0.2</version>
</dependency>`
I was just wondering how could I force my bundle to ignore looking for jax-b 2.2.12 and take only the system default 2.1.0 version by some configuration using maven pom. Specifically in maven bundle plugin in the POM.
Activate method in my ABC class:
`#Activate
public void activate(ComponentContext ctx) throws JAXBException {
abcContext = JAXBContext.newInstance(ABC.class);
}`
Current Bundle plugin import package definition:
<Import-Package>
*;resolution:=optional
</Import-Package>
Exception:
16.03.2016 03:13:05.709 *ERROR* [Background Update foo.barsupport-bundle (606)] foo.barsupport-bundle [foo.bar.calendar.impl.CalendarEventParserImpl] The activate method has thrown an exception (javax.xml.bind.JAXBException
- with linked exception:
[java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory not found by cqse-httpservice [25]]) javax.xml.bind.JAXBException
- with linked exception:
[java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory not found by cqse-httpservice [25]]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:241)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:477)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:656)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:599)
at foo.bar.integration.calendar.impl.CalendarEventParserImpl.activate(CalendarEventParserImpl.java:33).
Any help would be really appreciated.
In general, your problem is that your bundle by default accept [2.0, 3.0) which is perfect for the Semantic Versioning (Major.Minor.BugFix). But, if your bundle use the newer version, and if it communicates with some of thoses classes to your framework which use an older version of that bundle, you can get those kind of ClassNotFoundException in Runtime.
The uses directive is created to make sure that if there is multiple compatible versions, and multiple importers, those importers will communicate between them with the same version. It generally occurs when a bundle exports packages where other packages imported by other. This is why a good practice is to have API bundle which doesn't export anything or Impl bundle that exports anything, it free you from the need of uses..
Try to use a version range when importing jaxb in your bundle:
<Import-Package>
javax.xml.bind;version="[2.1,2.2)"
*;resolution:=optional
</Import-Package>
This directive tell the osgi resolver to wire your bundle with the package javax.xml.bind with a version from 2.1 to 2.2, 2.2 excluded.