In my Android project, I've used gradle build file to pull api keys from a local file outside of the source root and to automatically generate BuildConfig class and it's fields using a buildConfigField.
But I'm unable to do the same thing in my RoboVM project. I guess, the BuildConfig fields mentioned above are Android specific.
How can I remove API secrets from my RoboVM source code?
Related
Under same ORG, i have 2 projects. One is a class library project. Another one is a web site project. Both have their own build and release definition. I want to include dlls from the class library project when i do a release of the web site project. Web site project uses IIS deployment tasks in it's release. This IIS deployment task deploy the zip file created from the build of the web site project only (this project will have reference of the dll from class library already added). What i need is when the release of web site happen , it should pick the latest dll from class library project added in to it's bin folder. How do i do that in devops release definition.
Azure DevOps - Linking Class Library project into the release of another project
The easiest way is add the class library project in the solution of web site project and set it as project reference instead of reference the dll file.
Then we build the solution of the web site project, the latest dll from class library project will be added in to bin folder of web site project each time when we build the solution.
If you do not want to use project refernce, you can also use the Download Pipeline Artifacts task in the build pipeline of web site project to download the latest dll from class library project, then use the Copy Files task to copy the dll from the default folder to the bin folder.
Hope this helps.
I created a custom plugin to be uploaded on Google Cloud Data Fusion platform, which is based on CDAP platform.
I followed the instructions for developing and deploying plugins but the upload fails when I try to associate the corresponding Json configuration file (generated by IntelliJ itself through the CDAP Maven artifacts) with following error:
Artifact artifact:default.record-gen-source.1.0 extends artifacts 'system:cdap-data-streams[4.0.0,5.0.0)/system:cdap-data-pipeline[4.0.0,5.0.0)' that do not exist
If I remove the reference to parent artifacts the custom plugin is loaded but it doesn't appear neither as a batch plugin or as a stream plugin (I can understand this, I'm removing the parents references).
What could be the error?
The issue is the plugin you are trying to upload inherits from incorrect parent artifact versions(which in this case cdap-data-streams & cdap-data-pipeline). The version of these artifacts are based on the version that is available in your current Data Fusion instance (which I believe is 6.1). If the version of cdap-data-pipeline/cdap-data-streams artifact doesn't fall under the range specified then you will be seeing this error. If you edit the version range to be [4.0.0,7.0.0) it should work I believe.
Can you try updating the pom.xml if you are using cdap-maven-plugin plugin with updated version range Like here and rebuild & deploy?
I have 2 separate projects in STS Eclipse, both using gradle to build. One is a web application. The other is a data access library that the web application uses. I have the buildship plugin for this.
Normally, I would simply change the project properties to include the data project in the web application's build path/project references/etc to make this work, but we're switching over to using Gradle for this.
I have a working build.gradle file in each project, but I don't know how to make the web app's build script build and include the data project.
I've looked for various tutorials and examples, and they talk about a root project that contains both projects inside. I have no idea how to create this.
How do I go about setting this up?
Furthermore, I'm concerned about SVN in a setup like this. I want to be able to commit each project separately since other applications will use the data access library, which is why it's a separate project. My understanding is that a nested project structure suggested by gradle would cause the entire root project to be committed as 1 entry, with both subprojects.
This would then mean that I would have to copy the data access project into all the other projects that need to use it, which would make maintaining the code a pain. At that point, I might as well not have a separate data access project and instead just include all that code in a package in the web app.
The solution to this issue was the "includeflat" command in the settings.gradle
I have a java based appengine endpoint project in eclipse.
When I generate client library using command line tool.
https://developers.google.com/appengine/docs/java/endpoints/endpoints_tool
I'm getting only source based jar file ('project_name_version'.java-1.18.0-rc-sources.jar). It does not work fine in Android Studio when I add as a Library.
How can I get class based jar client library (google-api-services-'project_name_verison'-1.18.0-rc.jar)?
I tried searching online but no luck yet.
You could always zip up the sources file and use them in Android Studio. However , note that in the build.gradle file, you will have to reference the other dependent JAR files + versions that will be needed by the sources that you have generated in Eclipse via the Generate Cloud Endpoint Library option.
Build your app engine back end with JRE 7. You can change this from windows->preferences->java->installed JREs. You'll find an Add button at the right side of the pane. For more detail refer this Tutorial
This will solve most of your problems.
What is the recommended Eclipse (4.2) configuration for building a Google Cloud Endpoints Android Client Project?
Running Google -> Generate Cloud Endpoint Client Library yields a /libs within my Server project that contains:
commons-logging-1.1.1.jar
google-api-client-1.12.0-beta.jar
google-api-client-android-1.12.0-beta.jar
google-api-client-appengine-1.12.0-beta.jar
google-api-client-java6-1.12.0-beta.jar
google-http-client-1.12.0-beta.jar
google-http-client-android-1.12.0-beta.jar
google-http-client-appengine-1.12.0-beta.jar
google-http-client-gson-1.12.0-beta.jar
google-http-client-jackson-1.12.0-beta.jar
google-http-client-jackson2-1.12.0-beta.jar
google-oauth-client-1.12.0-beta.jar
google-oauth-client-appengine-1.12.0-beta.jar
google-oauth-client-java6-1.12.0-beta.jar
google-oauth-client-jetty-1.12.0-beta.jar
google-oauth-client-servlet-1.12.0-beta.jar
gson-2.1.jar
guava-jdk5-13.0.jar
httpclient-4.0.3.jar
httpcore-4.0.1.jar
jackson-core-2.0.5.jar
jackson-core-asl-1.9.9.jar
jdo2-api-2.3-eb.jar
jetty-6.1.26.jar
jetty-util-6.1.26.jar
jsr305-1.3.9.jar
transaction-api-1.1.jar
xpp3-1.1.4c.jar
Does my Client need to include all these .jar files? If I copy them all into the /libs folder of my Android Client Project and do Build Path -> Add, I get the errors:
Dx trouble processing "javax/xml/namespace/QName.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
and
Dx trouble processing "javax/transaction/HeuristicCommitException.class"
So I need to manually remove xpp3-1.1.4c.jar and transaction-api-1.1.jar from my Client /libs for a clean build.
Is this the "standard" way of building a Client project? How can I determine what are the required .jar libraries for building on Android? Can I configure Eclipse to dynamically import only this subset into my Client?
If I update my Endpoint classes within my Server project in the future and re-run Generate Cloud Endpoint Client Library, do I only need to copy the generated source code under /com/google/api/services to my Client project?
You only need these jars in your Android project:
google-api-client-1.12.0-beta.jar
google-api-client-android-1.12.0-beta.jar
google-http-client-1.12.0-beta.jar
google-http-client-android-1.12.0-beta.jar
google-http-client-gson-1.12.0-beta.jar
google-oauth-client-1.12.0-beta.jar
gson-2.1.jar
guava-jdk5-13.0.jar
jsr305-1.3.9.jar
The other dependencies are included for running the library within other environments.
In general, the dependencies are fixed between runs of generating the client library. However, the generator will use the newest version of the client library, so if that's upgraded in the background, the dependencies might need to be upgraded as well.