Error executing command: Error resolving artifact
com.sample:features:xml:features:4.1.4-SNAPSHOT:
\[Could not find artifact com.sample:features:xml:features:4.1.4-SNAPSHOT in default
local (file:/C:{/Users}.m2/repository/),
Could not find artifact com.sample:features:xml:features:4.1.4-SNAPSHOT in apache
(https://repository.apache.org/content/groups/snapshots-group/),
Could not find artifact com.sample:features:xml:features:4.1.4-SNAPSHOT
in ops4j.sonatype.snapshots.deploy
(https://oss.sonatype.org/content/repositories/ops4j-snapshots/)\] :
com.sample:features:xml:features:4.1.4-SNAPSHOT.
I could not resolve this error after uncommenting local repository in org.ops4j.pax.url.mvn and add my local .m2 path
Thanks in advance for your suggestions.
You might have to reset your Apache karaf instance to fresh state.
Stop Karaf
Delete data folder from Karaf installation folder.
Start Karaf
Re-Install the features and bundles you need.
Alternatively you can try removing any features, feature-repositories and bundles that have been installed from there before removing the maven repository.
It's generally bad idea to remove/replace maven repositories from Apache Karaf from where user(s) might have already added new feature repositories, installed features and bundles.
Once tried to replace offline repository I had made with a new one which was missing some older artifacts. This lead to bunch of issues like inability to uninstall some of the older features.
Related
In karaf how do you search for missing packages in repos ?? seems like such a feature would be really really handy
For example, try to install activemq-broker following manual using latest karaf release (at the time of writing this question) and you need to add:
spring-legacy repo to install spring
some other stuff that's required by third party libraries and you have no idea about
Should be able to do a "search for package" and get a list of metadata about artifacts available in a repo that contain that package.
I'm facing an irritating behavior from my karaf server: Title says it all, installed bundles get restarted when I use a feature: install command.
* Project context *
Most of the bundles I deal with are camel routes, the other ones are common tools, shared by the routes.
As a result, I have a 2 level project: a common part that is installed first, and the camel routes that all depends on the common part (dependent on Maven point of view).
* Scenario *
start a fresh instance of karaf
install the common features
install a camel route feature: no troubles so far
install a second camel route feature: the bundles from the previously installed feature will restart.
* Breakthrough made *
All the bundles declared a common config file, with the option "update-strategy=reload". This means that karaf would notify each bundle of any modification of this file, and the bundle would restart to take it into account.
As a matter of fact, when I installed a new bundle with a dependency on this file, it would be read in order to initialize the bundle's properties, and karaf considered it to be a file modification. Therefore, installing a new bundle made all the others restart.
As you expect, I dealt with that problem by removing the update-strategy option, and most of my features are now clean.
* Leftovers *
BUT, some of them still holds the bug: Installing any of those troublesome features will have all the other installed features restart. This is a ONE-WAY problem, installing a clean bundle will not have the troublesome ones restart.
I checked anyway, but no other config file could be responsible for that.
Any help or advice would be appreciated, I can also provide anonymized examples of any file that would help you understand, like an osgi-context or a feature's pom.xml
One last thing: my features regroup around 50 bundles each, therefore I can barely understand the karaf logs, and I can't pinpoint which bundle is restarted first.
Thanks for your time and attention!
I think there are some misconceptions in what you describe.
update-strategy=reload does not cause a bundle to reload. It causes a blueprint context to reload.
You should also not share the some config between bundles it is known to mess up you deployments.
There are also other reasons why a bundle may restart. A karaf feature install tries to provide the optimal set of bundles that is needed overall in karaf to satisfy the set of currently installed features.
A typical case is that you first install feature with a bundle containing an optional package import. At this moment it can not provide the package. Then you install a second feature that provides an exporter of the package. Now the optional dependency of the bundle can be satisfied and the bundle will be restarted by karaf.
You can look into such cases by using feature:install -v . This will show you which bundles are restarted and also why. So maybe this can help you to debug why the restart happens.
a question about building flink-avro.
i downloaded the source, and i am able to build complete source.
but when i move to folder
flink/flink-staging/flink-avro
and run command mvn package as i want to compile and run the tests, it starts downloading latest flink SNAPSHOT jars.
whereas, i have built the same jars from source, everything is there in local repo.
why it downloads the same things which are built locally?
You need to use mvn install on the top level module first. This will copy the built jars into your local maven repository located at ~/.m2/respository/. mvn package only builds the jars and put them in folder target (no copying into local maven repo happens).
After that, you can step into flink-avro and build there (either with mvn package or mvn install -- as long as no other module depends on the built jars, mvn package is fine). If you change something in a module A and another module B depend on A, you need to do mvn install in module A. Otherwise, module B cannot access the newly built jars from A.
Maven always looks for dependent jars in your local m2-repository first. If it does not find the jars there, it starts downloading them from the Internet. If it finds "old" jars in your local repo, it might still use them (depending on your specified maven update interval). On the other hand, even if you built mvn install locally, and a newer version is available online, maven might download the newer version.
Last but not least, sometime maven does not resolve the timestamp dependencies correctly or does not update the local repo even if you do a mvn install. Clearing the local maven repository (just do a rm for the corresponding jars or the whole repo) can resolve this problem.
I'm using appengine-sdk 1.9.3.
In devserver, works in Eclipse and Ant normally.
When I deploy (update) to appengine (production environment), I get this error:
event.getResults(): [<pre>Error for /p7/formPanelServlet
java.lang.NoClassDefFoundError: Could not initialize class
com.google.appengine.tools.cloudstorage.oauth.OauthRawGcsServiceFactory
at com.google.appengine.tools.cloudstorage.GcsServiceFactory.createRawGcsService(GcsServiceFactory.java:42)
at com.google.appengine.tools.cloudstorage.GcsServiceFactory.createGcsService(GcsServiceFactory.java:34)
at com.bitvisio.p7.server.FormPanelServlet.<init>(FormPanelServlet.java:27)
At FormPanelServlet.java:27, the code is:
private final GcsService gcsService = GcsServiceFactory
.createGcsService(new RetryParams.Builder()
.initialRetryDelayMillis(10)
.retryMaxAttempts(10)
.totalRetryPeriodMillis(15000)
.build());
I put the lib appengine-gcs-client-0.3.9.jar in war/WEB-INF/lib. I think there is a problem with this lib.
Thanks for help.
Always use tools like Maven or Ivy to resolve dependencies for you. Copying JARs to war/WEB-INF/lib/ directory and editing .classpath file manually will be painful and may not help you always. If you use Eclipse & Google App Engine plugin, use Add Google APIs... as mentioned here - Google Plugin for Eclipse. In my case, adding Cloud Storage API via Google Plugin for Eclipse helped resolve this NoClassDefFoundError.
I had the same problem. I use Ivy to resolve dependencies and always get the latest.integration (with Maven use RELEASE) for revisions.
However I usually ignore transitive libraries. It looks like Google is expanding the API family - at least splitting out discrete functionality.
There are now quite a few transitive dependencies and it seems they released a new version of the GCS client around the same time as 1.9.3.
Getting all dependencies and packaging them in my deployment fixed my issue. I did not have the issue in development which made it more confusing.
You are facing this issue because you are not adding the some of the jar like
google-api-services-storage-v1-rev78-1.22.0.jar download link
joda-time-2.94.jar download link
guava-19.0.jar link to download
you can use the different version of jar according to your appengine-gcs-client jar file.
Note : Add all these jar and build path with the project and problem will get solve.
Currently we have a script that does maven build + tomcat deploy.
Deploying to tomcat involves stopping the server (force stop by setting CATALINA_PID), deleting war file and exploded folder from its webapps directory, copying new war file to webapps/ , deleting tomcat work directory and finally starting the server.
Can we achieve all/most of these using cargo-maven2 plugin (cleaning work/webapps ??)
[ I have a basic config that can be used to just stop,deploy and start ]
And is it good to use the plugin in production environment as well ? The documentation mentions that its useful for integration tests.
Can you guys share your thoughts on this?
Thanks,
Gayathri
As you already mentioned from the docs Cargo is for functional testing. For production you should use other things like puppet or chef. Furthermore Maven is not a deployment tool it's a build tool. From a technical point of view it's of course possible to use it in production but it's not intended.