Is there a way to call another artifactory plugin from an artifactory plugin?
We use artifactory user plugins a lot in our company and it works fine but sometime we could see the need to call directly another plugin instead of copying the code around...
If your goal is reusing logic between plugins, you can encapsulate this logic in Java classes and import them in your plugins. You can package the reusable code in a java archive (jar) and place it as a library under the ${ARTIFACTORY_HOME}/etc/plugins/lib directory.
Related
I just recently used Github, and when I was trying to upload my java project I realized that I was using some external libraries like apahce poi in this project, and these files have to be stored in libs for my application to function, do I need to upload these files because I realize that might violate some issues(maybe ?).
If yes, then what is the correct way to upload or maybe just post a link to those dependency
Use a tool that provides a dependency management system such as Maven or Gradle (these are both common choices in the Java ecosystem). Your project will then include a configuration file that Maven or Gradle will use to download dependencies so you don't need to distribute them with your project.
I'm developing Jenkins' plugin which is dependent on another plugin (specifically MultiJob plugin, but it can be any other one of course).
Obviously, the dependency is found in POM, so I can actually use the classes of it.
The problem: if I'm trying to install my plugin in Jenkins that the dependency is not found in it Jenkins doesn't installs it automatically and upon first usage my plugin throws an exception NoClassDefFoundError, of course.
Question: can I make Jenkins to install my dependencies as prerequisites and if yes, how?
Note: I do see that other plugins somehow cause the dependencies to be installed (Git plugin for instance makes GitClient installed during its installation).
Thanks in advance.
It's been a while since i've raised the question, but if anybody will look for something similar, here is what i've finally came up with:
Since the dependency classes are only needed in case they are really there, i've decided to use Java's lazy linkage behavior and actually refer the relevant classes only on demand.
So practically, made a factory that has a list of class names of interest and every time i need to process some object i'm checking it's class against this list. If matched - the class is loaded and therefore it's okay to init the linking/initiation logic.
Last one, if you plan to use such a pattern do not forget to sign those dependency plugins as optional in your pom.xml.
everyone.
I am new to Go language and currently I am trying to understand the basics of building Go applications. I met the following problem.
For example, I am using other libraries in my project. I have them locally, on my computer, so my project works fine.
I am loading my code on github and another programmer download it. As I understand, my code won't work, because this programmer doesn't have the libraries I used.
So the question is: What is the best way to share my project with all libraries it has? Should I upload these libraries in the separate repositories? Then to use my project, people need to look inside the code to detect which libraries I am using to download them one by one?
For example, in Java there is such thing like Maven or Ant, which downloads all required dependencies. Is there any tools like this for Go?
Let's call the main file of my project main.go
And I am using my own library: mathutil.go
what is the best way to make this project run on other computers?
Go's dependencies work very much like using Maven or IVY transitive dependencies. When someone does "go get" of your package, anything you depend on will automatically download.
For example, in your source:
import "github.com/foo/bar"
go will automatically download that to your $GOPATH/src/github.com/foo/bar along with your code.
Assuming the third party libs you use are hosted in a public repo (ie: github) then people don't need to do anything.
If the libraries you used are not available on a public repo, you will need to post them somewhere assuming their licensing allows.
Take a look at golang.org/doc/code.html for more details
I'm developing my own hudson plugin and can not find a really comprehensive documentation.
How can I connect to the artifactory plugin to get a list of artifacts? The artifactory plugin is installed in hudson but I don't know how to instance it/connect to it from my own plugin.
My plugin deploys a specific version to our webstart server. This includes downloading the artifact from artifactory over HTTP, creating version.xml and *.jnlp file and uploading these three files to the webserver using SCP. For the configuration of this plugin, I need a list of all versions of a specific project from artifactory.
Thanks in advance.
If you'd like to use model and utility classes of another plugin, then it's simply a process of depending on that plugin (compile-wise) and making sure that the dependent plugin is installed so you can reference these classes at runtime.
If you'd like to use entities like builders, actions or wrappers, you'll probably need to use Hudson's facilities; I'm not so sure as to which facilities it has, but Jenkins' hudson.model.AbstractBuild and hudson.model.AbstractProject (and other) objects have methods like:
hudson.model.Actionable#getActions
AbstractProject#getPublishersList
That'll return those entities (assuming they're configured on the project in question).
Apart from that approach, there are a number of ways to solve your issue using Artifactory's REST API:
If the artifacts are contained in Artifactory within one location that's known to you, you can execute a file list query to reveal the contents of that directory.
If you'd like to fetch the produced artifacts of a specific Hudson build, and assuming that you use the Hudson plugin to deploy Build Info, you can request the Build Info object using the Build Info resource; utilizing the checksums of the produced artifacts listed in this object, you can perform artifact checksum queries to find out if and where these artifacts exist in Artifactory.
If you don't know the specific build name and number or the location, you can use any of the search facilities to locate artifacts based on different details; The GAVC or XPath searchers are most likely to help in your situation.
Greetings,
I have a java project which I export as a jar. This java project also uses JNI.
So far, the only method I could find to use this jar in an Eclipse plugin is to wrap it in an other eclipse plugin project, and add this jar wrapper plugin to dependencies of my actual plugin.
I've wrestled with Eclipse's paths and dependency settings for days, and this method is the only one that works for me at the moment.
However, it is not very practical, since when I change my JNI based java code, I can simply create a new jar, but to connect that jar to my actual plugin, I have to re-create the jar wrapper plugin every time.
That is, I delete the jar wrapper plugin project, with everything on the disk, and re create it with the same name, pointing to the updated jar. I also have to drop the reference to this project from the actual plugin project and add again (maybe this has gotten smarter recently, but I did not test it)
This is time consuming, and I can't add this wrapper plugin project to svn either, since it is being created from scratch every time.
If I could simply update a jar wrapping eclipse plugin project by pointing at the new version of jar, that would solve my problem, and I could commit the project to svn after each update.
Is there any method you can think of which may help me run this process smoothly?
Best Regards
Seref
An Equinox-only (i.e. non-standard OSGi) method of using external libraries in an OSGi bundle without physically wrapping them is bundling by reference: you still need a wrapper plugin, but it does not contain the wrapped library itself but a reference in the bundle manifest's Bundle-Classpath header with a syntax like this:
Bundle-Classpath: external:/path/to/your/lib.jar
During development time, this is quite convenient and saves the effort of having to recreate the wrapper plugin whenever the wrapped library is updated. During deployment time, you'll either have to install the library along with the product or use a traditional wrapper plugin (one containing the actual library). You can also use the same wrapper plugin for bith use cases, but change the Bundle-Classpath from external:/stuff/lib.jar to libs/lib.jar dependent on whether you want to use the wrapped or the external library.
(Most of this comes from the book OSGi and Equinox - Creating Highly Modular Java Systems, which I don't really like, but which nevertheless contains useful stuff about Equinox (Eclipse's OSGi implementation) and the PDE build system.)