How to resolve integrated files in Perforce JAVA API. I am trying to merge files from one branch to another. I am using following code to merge.
tmpClient.integrateFiles(file, toFile, "17.2", opts );
After executing this command, files need to be resolved. How can I do that?
Look at IClient.resolveFile() and IClient.resolveFilesAuto():
https://www.perforce.com/perforce/r15.1/manuals/p4java-javadoc/com/perforce/p4java/client/IClient.html
The specific method you use will depend on whether you expect that you will always be able to rely on auto-resolve (which is a bad expectation generally) and what sort of system you have in your app to handle conflicting merges.
Related
What is intended is to give everyone access to the source code but to restrict what they modify.
So what first came to mind is if there's any way to, when building the plugin/project, some sort of restriction is applied to the files that have been modified and if some unnauthorized modifications have been made the build fails.
An example would be that only some users may modify the java files, but all users can modify XML configurations and build the jar.
Or if this isn't possible what alternative do I have to restrict source code modifications?
Don't do this in maven, do this in your version control system.
Either use one where you can give different levels of access to different users or just use the fact that it's a version control system and if anyone makes changes they shouldn't roll the changes back out and tell them not to do it again.
I've written a bunch of android JNI code that I want to make into a library for a customer. Obviously, I don't want the customer to be able to see my JNI code. Is there a way I can include just the so file in a library project for them?
I've tried just using System.loadLibrary(<library>); but I get an Unsatisfied Link Error every time.
One thing that's worked, is I've just compiled my project and deleted all the c files. I'm still able to use the .so file, but if I do a make clean, it deletes my so file and there's no way to recover it without the source.
In short, what I want is to be able to compile an so file on my own, and give it to my customer with some java code that interfaces with it. I don't care if they see the java 'wrapper' source but I don't want them to be able to see the JNI code. I also want them to be able to treat this library as they would any other (ie make cleans don't wreck it).
Thanks!
Is there a way I can include just the so file in a library project for them?
Package an AAR containing the libraries, and host the AAR as an artifact for your customers. See my CWAC-AndDown library for an example. The AAR will contain your .so files for whatever architectures that you are supporting, plus a JAR of the compiled Java code that provides your Java API to the native code.
I also want them to be able to treat this library as they would any other (ie make cleans don't wreck it).
Well, by definition, make clean requires source. It also requires a makefile, which presumably you will not distributing, since that's useless without the source.
Background / example (but question is probably broader than this):
I'm trying to write a Java application that accesses a Google AppEngine server. To set up the project for this, I followed the steps outlined in the accepted answer here:
Developing a Java Application that uses an AppEngine database
I am now running into a problem where I'm trying to execute an HttpURLConnection-request in the Java client application (i.e. not in the AppEngine server code), but Google's AppEngine library seems to have replaced the Java version of this connection with its own urlFetch()-implementation. This leads to me getting the following error: "The API package 'urlfetch' or call 'Fetch()' was not found.".
Actual question:
What determines the order in which Java looks through libraries to find needed class-implementations? Is there a way to modify this order (specifically in Eclipse), so that the actual JRE-functions take precedence over a third-party-library that is also needed. Or is there maybe something special going on with the implementation of Url in the example given above, that cannot be resolved by specifying a library order?
Update:
Turns out the problem I was seeing had nothing to do with the order in which classes were loaded. The AppEngine server code explicitly calls setContentHandlerFactory(...) to register its own handler during execution rather than at library load time (see here for a fix to this specific issue). So, while my "actual question" might still stand, I haven't actually yet come across a scenario where it matters...
You might have to define a custom ClassLoader.
Also, take a look at this answer.
Inside Eclipse, you can adjust the classpath order. Right click your project, choose Properties, Java Build Path, then click the "Order and Export" tab. However, of course, this won't affect your program when running outside Eclipse.
I am very new to java and android development and to learn I am trying to start with an application to gather statistics and information like munin does. I am trying to be able to load "plugins" in my application. These plugins are already in the application but I don't want to have to invoke them all separately, but be able to iterate over them. I was trying to use serviceloader but could never get the META-INF/services into my apk. So I am wondering if it is possible to use serviceloader on android
Thanks
EDIT: I am asking about java.util.ServiceLoader, I think it should, but I can't figure out how to get my services folder into META-INF on the apk
There is an open bug report against this issue. See https://code.google.com/p/android/issues/detail?id=59658
The META-INF folder is deliberately excluded from the APK by ApkBuilder; the only comment in ApkBuilder.java is "we need to exclude some other folder (like /META-INF)" but there is no other explanation.
Even after adding META-INF with ant, you will still get in trouble if you want to use Proguard, which refuses to replace the content of META-INF/services/* files or rename them (that's another story, the author wants to keep Proguard agnostic).
However, people using maven may want to check https://github.com/pa314159/maven-android-plugin (the branch named "modified"), that tries to solve both issues. It is a fork from the original "android-maven-plugin" I modified one month ago for my own Android projects.
It also provides a patch for Proguard-4.7
Hope this helps, any feedback is welcome.
I've figured out a solution that may work for some situations. Instead of ServiceLoader, I'm using the org.openide.util.Lookup class / library that comes with NetBeans - it is a superset of ServiceLoader. It does not require NetBeans itself and seems to work ok with Eclipse. It is necessary to replace whatever ServiceLoader functionality you are using in your application with Lookup equivalents, and add the org-openide-util-lookup library. Then, you can just do something like this:
Lookup lookup = new ProxyLookup(Lookup.getDefault(),
Lookups.metaInfServices(myClass.getClassLoader(), "services/"));
And move your ServiceLoader files from META-INF/services/ to services/.
Note that, because of the ProxyLookup, this will continue to work on standard Java environments unchanged (i.e., in those cases it will continue to look in META-INF/services).
Here is a link to the documentation for the library: http://bits.netbeans.org/dev/javadoc/org-openide-util-lookup/org/openide/util/lookup/Lookups.html
UPDATE
After working with this for a couple of days, it seems to function well - I move between environments (standard Java and Android) and it works properly in each location. The primary downside is having to manually copy the files to the /services directory.
It is possible. You may want to check http://developer.android.com/reference/java/util/ServiceLoader.html
ServiceLoader is stuff from the Java language that is not really relevant on Android. I recommend not using it. If you just want to find a list of classes within your .apk to load, there are all kinds of ways to do this -- put in XMl file in res/xml that lists them, use reflection, annotations, etc.
I'm writing a Java application that needs a lot of static data that is stored in many enum types. Since I would like an user-friendly way to customize this data using for example xml or json files but I'm not allowed to do it directly with enums I was looking for a way to elegantly do it.
Maybe a good solution would be to have a separate java program that reads the xml files and produces the java sources that are then compiled with the remaining part of the sources. My doubs is how to automatize this process in a stand alone way (eg ant?) and how to integrate it seamlessly with eclipse so that it is autOmatically done when I'm working with the project.. Does anything similar to what I'm looking already exists? Any suggestion to solve my problem?
Thanks!
If the items and the overall structure are somehow fixed (and what varies most is the values of the attributes), you could consider defining the enum with one entry for each of your items and let the enum populate its own constants with data read from an external source (XML / JSON) -- at load time or on demand.
Create a project whose sole job is to generate java from your sources.
Make sure that the generation phase is done by Ant.
Now, wrap this project into eclipse and use a custom ant builder, that calls the target in your already existing build.xml.
This is a standard part of our dev infrastructure, so this definitely works.
You can write a maven plugin that generates the code. There are some plugins that do that. It won't work automatically, but you can connect it to the standard maven lifecycle so it gets executed just before compile.
I just did something like that recently.
You can have ant seamlessly integrate with eclipse to achive that:
In Eclipse open project properties, go to "Builders", click "New...", select "Ant Builder", select a build file, go to "Targets" tab and click "Set Targets..." for "Auto Build". Select the desired target and you are done. The target will run every time you save a source file (if "Build Automatically" is selected).
Have you considered including the XML files in your jar, and loading them on startup into maps that use the enum as a key?