We are evaluating xcode-maven-plugin from http://sap-production.github.io/xcode-maven-plugin/site/ for handling iOS library dependencies using maven. It looks really promising but we are using some prebuilt third party libs we don't have the source code from that we would like to also install in maven and resolve as maven dependencies but we don't know how to achieve that with the plugin.
We have already used the maven-android-plugin for Android to upload third party binaries and we manage to do that playing with the headerFilesDirectives and nativeLibrariesOutputDirectory parameters but we haven't found anything similar for the xcode plugin.
Does anyone know if it is possible to install prebuilt iOS libraries with the latest(1.14.0) xcode-maven-plugin version?.
We are new to Maven so maybe we are missing something obvious here.
Why do not you use a CocoaPods instead? It's a dependency manager for Objective-C projects. It's like iOS equivalent of Maven.
Related
I'm new to the Atlassian development and I've went over the guides/tutorials for plugin development and everything worked fine (I'm using Ubuntu with IntelliJ as IDE). Also read the "Jira 7 Development Cookbook - Third Edition". When I tried to switch to JSD development the dependencies and plugins didn't work. I get errors like this:
Dependency : 'com.atlassian.jira.plugins:project-templates-api:2.18' not found
or
Plugin : 'com.atlassian.plugin:atlassian-spring-scanner-maven-plugin:2.0.1' not found
I'm following guides from the official site under that part of the development guides. I've looked over documentation of API plugins and classes and tried changing the version and/or name of the plugins, but I always get that same error. Have I overlooked something important or is this something that happens often and has a solution?
EDIT:
Don't use
atlas-mvn idea:idea
as drelliot said.
You have to add dependencies and plugins manually on pom.xml and do
atlas-mvn install
I still have bugs, but most were solved by this.
Don't use
atlas-mvn idea:idea
as drelliot said. You have to add dependencies and plugins manually on pom.xml and do
atlas-mvn install
After that just import the project into IDE of your choice. I still have bugs with packages and version since the official tutorials are outdated and don't help a lot, but most were solved by this.
I tried to compile chaincode sample and write my own one (https://github.com/hyperledger/fabric/tree/master/examples/chaincode/java/SimpleSample)
However, I can't get a shim-client-1.0. Do you have plans to make java sdk public?
I hope that “shim-client-1.0.jar” will be added to maven repository soon, nevertheless you can try to compile it using source code in “github.com/hyperledger/fabric/core/chaincode/shim/java”.
gradle build
and "shim-client-1.0.jar" will be available in github.com/hyperledger/fabric/core/chaincode/shim/java/build/lib folder.
I have a problem with the NuGet package manager. I published my library (a type provider, but I don't think this matters) and then testet it, but it fails to find a dependency. The complete error message is (full namespace/name ommitted for brevity):
The type provider 'TypeProviderImplementation....' reported an error:
Could not load file or assembly 'dotNetRDF', Version=1.0.3.0, Culture=neutral, PublicKeyToken=...' or one of its dependencies.
The thing is that when installing the library, it looks like the dependencies are installed correctly. The correct libraries are downloaded and there is no error showing up.
In an attempt to solve the problem, I specified the exact version in the .nuspec file, but this didn't change anything.
...
Installing dotNetRDF via NuGet and then manually referencing my precompiled DLL (without going through NuGet) seems to work fine.
So I'm basically out of ideas on how to solve or even debug the problem. I'm thankful for any pointers.
Addign more information about .NET version numbers as my comment below is quite hard to read:
I checked framework versions as suggested. I did this via looking at the FrameworkDisplayName in the object browser. Basically, my library was using 4.5 and dotNetRDF was using 4.0.
I switched to .NET 4.0, but nothing changed.
My library = ".NET Framework 4"
dotNetRDF = ".NET Framework 4"
HtmlAgilityPack = ".NET Framework 4.5"
Newtonsoft.Json = ".NET Framework 4.5"
VDS.Common = ".NET Framework 4 Client Profile"
My dependency is dotNetRDF, the remaining ones are dependencies of dotNetRDF.
Latest NuSpec file can be found here. I create the package via the command nuget pack LITEQ.fsproj -Prop Configuration=Release.
The package id is LITEQ.RDF.
Some additional information:
The library is a F# project. I just tested what happens if I create a console project and install the library via NuGet and then send the references to the F# Interactive Console. It actually works in this case.
So it feels like there is some problem with the project configuration after installing the library via NuGet.
To reproduce, the error, download the library, open up the UniKo.West.Liteq namespace and for example use the NpqlTypeProvider:
open Uniko.West.Liteq
type A = NpqlRdfProvider< #"">
Certainly for me I can't see any obvious problems, when I install your package into an empty console project I don't have any issues and I can write a trivial example that uses the dotNetRDF APIs just fine. If you can produce a minimal example project into which installing the packages creates an issue then that would be very helpful.
Your Issue
However the dependencies you state for your project look wrong, you have .Net 4.0 for your project and some dependencies but .Net 4.5 for others which will not work. Note that when you downgrade a projects target framework NuGet does not cope nicely with that, it is best to completely uninstall and reinstall NuGet packages any time you change the target framework version. It is perfectly fine for a newer version of the framework to rely on dependencies that target older versions, so your .Net 4.5 project can happily depend on the .Net 4.0 version of dotNetRDF. However the reverse is not true which may be the cause of your problems.
You can sometimes tell if this is the case because VS may highlight bad dependencies under References in the solution explorer with little warning icons (sadly it doesn't always do this). Even if this is not the case you should see output like the following in the Output Window when you try and build if you have incompatible dependencies and this may also yield compile errors about missing namespaces:
C:\Program Files
(x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5):
warning MSB3274: The primary reference "HtmlAgilityPack" could not be
resolved because it was built against the ".NETFramework,Version=v4.5"
framework. This is a higher version than the currently targeted
framework ".NETFramework,Version=v4.0".
So I would strongly suggest that you uninstall all packages via NuGet and reinstall them whenever you change the target .Net framework of your project.
Other Issues
In terms of other possible issues you are using dotNetRDF 1.0.3 which is not the latest version, versions prior to 1.0.5 have a known issue related to interactions with the versioning and framework profiles of Json.Net. If a project you are installing into also has dependencies on Json.Net you may run into version conflict issues. See CORE-405: Resolve Issues with Json.Net dependency for some discussion on this.
I would suggest that you also upgrade your dependency to the latest dotNetRDF release which is 1.0.6.3421 at the time of writing this answer and see if that resolves your problem.
Edit - NuGet Package Versions
NuGet packages versions do not have to correspond to the assembly version, as it happens 1.0.6.3421 does have an assembly version of 1.0.3.0. That was actually not our intention but a flaw in our build process but that isn't really relevant here.
What it looks like is that your library is compiled against a different version of dotNetRDF than the one NuGet is installing for you. However without seeing the source of your package it is impossible to debug further.
What if neither solution works?
If neither of these things resolves your problem then you are going to need to provide a minimal project that reproduces the problem.
A temporary solution (or more of a hack) is to not rely on dependencies, but to directly put the DLLs into the NuGet package. When I do this, the library works fine. The NuSpec file in this case looks like this (excerpt):
<package>
<metadata>
...
</metadata>
<files>
<file src="bin\Release\dotNetRDF.dll" target="lib/net40" />
<file src="bin\Release\HtmlAgilityPack.dll" target="lib/net40" />
<file src="bin\Release\HtmlAgilityPack.pdb" target="lib/net40" />
<file src="bin\Release\HtmlAgilityPack.xml" target="lib/net40" />
...
</files>
</package>
But obviously, this isn't a good solution.
Let's say I'm building an application with a dependency on a third party library, but one I've built myself - say, Boost. I've packaged the dependency into a framework which is the OSX way of doing things.
How should I now distribute the framework to the developers of the dependent application? If this were Windows I'd probably use Nuget, or apt etc on Ubuntu. Python has pip for this kind of thing - is there a standard MacOS way of dealing with combined source & binary dependencies?
Cheers.
I can imagine 3 different ways to do this:
CocoaPods: This it the nearest thing to something like a "package manager" as you get.
Make a Github/Bitbucket Repository and use git for distribution
make a framework bundle and distribute it via download (e.g. zipped or packed in a .dmg) or email
How to manually install the maven plugin since I have enabled offline mode in settings.xml?
For example I downloaded maven-clean-plugin-2.4.1.jar. But I dont know where to place it and how to install it.
Tried http://maven.apache.org/plugins/maven-install-plugin/usage.html but I am not able to install. Please help me.
Here is the similar question.
Hope this may help you out for installing plugins for maven offlnely.
Maven: How to install a plugin in offline mode
I would recommend to go online once and run
mvn dependency:go-offline
The go-offline goal of the dependency plugin will "resolve all project dependencies, including plugins and reports and their dependencies."