I'm using play 2.2 framework, I'm developing the module and defined it as snapshot.
I have published the snapshot to nexus but when I try to deploy the same without changing version or appname redeploy fails with below error:
[info] Done packaging.
java.io.IOException: Access to URL http://mycompany.com/nexus/content/repositories/snapshots/com/mymodule/1.0.1-SNAPSHOT/mymodule-1.0.1-SNAPSHOT.pom was refused by the server: Forbidden at org.apache.ivy.util.url.AbstractURLHandler.validatePutStatusCode(AbstractURLHandler.java:79
at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:231)
at org.apache.ivy.util.FileUtil.copy(FileUtil.java:150)
at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84)
at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
at org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:234)
at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:216)
I know the reason for this failure, Nexus is denying the deploy due to the fact that the previous snapshot is also exactly same w/o timestamp.
Question is how to attach timestamp in Build.scala or any configuration in play framework that enable to redeploy of snapshots multiple times to Nexus. This is obviously is not a problem in maven project, but somehow evident in play framework projects.
Thanks in advance.
Thanks
Aravind
Use the aether deploy instead of the sbt/ivy publish. This should create the metadata on the server correctly.
https://github.com/arktekk/sbt-aether-deploy
Related
I am trying to follow, https://github.com/qubole/s3-sqs-connector and trying to load the connector but seems like the connector is not available on maven and while generating the buiold manually the sqs classes are not loaded.
Can some1 guide me on this.
Thanks,
Dipesh
Update:
S3-SQS connector is now released on maven central.
https://mvnrepository.com/artifact/com.qubole/spark-sql-streaming-sqs
You should be able to use it now. Get back to us if you face any problems.
Unfortunately, registration of the s3-sqs-connector in spark-packages is still pending. We'll try to release the package in maven central directly as soon as possible but it should take a few days at the very least.
In the meantime, you can clone the repository and build the jar yourself if required.
I tried to launch our Scala application on the Swisscom Cloud Foundry (CF) infrastructure. To do so, the matching Heroku buildpack was used:
https://github.com/heroku/heroku-buildpack-scala
As this did not work, I tried to deploy the 'hello-scala' example using this buildpack.
My fork to be able to build the slightly outdated example:
https://github.com/AlwinEgger/hello-scala
I have to underline that I am fetching the port I have to use as env variable 'PORT'.
Unfortunately, there is not much on the log. "failed to accept connections within health check timeout" message indicates that there is no one listening...
My questions: Did anyone succeed in deploying Scala apps on CF infrastructures (# Swisscom)?
A workaround I found:
I'm not using the scala- but the java-buildback. This with the major advantage and inconvenience that the project is not any more build on the instance.
Advantage: It speeds up the whole process considerably
Inconvenience: A build server is needed
So what do we have to do?
An example may be found here (this is the actual application):
https://github.com/OpenOlitor/openolitor-server
Add the sbt-native-packager to your project
Execute the action 'universal:packageBin' building by hand or configure your build server to do so
Change the buildpack in the manifest.yml and add some parameters, if necessary. Configure the path of the artifact to deploy.
Run cf push or let the build server do so.
My application is developed in Grails 2.4.4. It uses MongoDB-3.0.2 plugin. I use Hudson as my CI system.
Sometimes when the job in hudson tries to build the application war, I get the below error.
Error | Resolve error obtaining dependencies: Failed to read artifact
descriptor for
org.grails:grails-datastore-gorm-plugin-support:jar:3.1.3.BUILD-SNAPSHOT
(Use --stacktrace to see the full trace)
It doesn't happen all the time. Many times the war was built successfully. Recently I am facing this problem more frequently.
In one of the question similar to this this, someone has suggested to change the Snapshot version to Release version. I tried it but didn't help me.
I also faced this problem in dev environment few times.
Can anyone let me know what could be the issuse? Could it be connectivity problem between the repository and my system?
Our SSL certificate expired this morning. We are working to get it addressed. An option to use as a workaround would be to use http instead of https. See comments at https://github.com/grails/grails-core/issues/9200.
The process is almost complete to get the new cert in place. Sorry for the trouble.
I have an Azure .net backend working just fine locally. But when I deploy to Azure, I get this msg when I use the azure test page to test the deployed service.
Found conflicts between different versions of the same dependent assembly 'AutoMapper': 3.2.1.0. Please change your project to use version '3.2.0.0' which is the one currently supported by the hosting environment.'
So, my first thought was to downgrade to AutoMapper 3.2.0, but then I get into difficulty with my existing mappings that worked just fine with AutoMapper 3.2.1.
My question is why does Azure Region 'East Asia'(where my azure mobile service is deployed) have this issue ?
Do other regions suffer from this ?
What should I do ?
The problem was that I had local copies of AutoMapper binaries in my bin folder which got deployed to Azure. So, removed them and conflict was resolved.
Im in the process of evaluating the new interface of Apache Archiva. The user interface is really good and I was able to configure most of the settings.
However, when I try to deploy the artifact through eclipse Im getting the below error.
Error code 405, HTTP method PUT is not supported by this URL
I donot get this when I use the Apache Archiva 1.3.6.
Any idea?
This can happen if your repository URL is incorrect. See GitHub issue 4.
I have setup the new Archiva version 2.0.0. Apparently this issue has been fixed with the latest version.