I want to modify a jenkins plugin called Files Found Trigger. But after I downloaded the source code from github, I found there are lots of lines started with import hudson.XXX. And I have no clue where to get the hudson library.
I thought maybe I could find some information at Jenkins Plugin Tutorial. But it seems that the tutorial doesn't mention about where to get the library.
Anyone can help?
From here (Upgrading from Hudson to Jenkins):
Jenkins is basically a drop-in replacement to Hudson.
It's the continuation of the same code base, in same package structure. There has been no major surgery since the rename, and the rename really only affected what's shown in the UI. As such, it understands the same set of environment variables, same system properties, and the same information in the home directory. So if you rename jenkins.war as hudson.war, and simply overwrite your hudson.war, the upgrade is complete.
So my conclusion is: just rename hudson to jenkins.
There is no need to do anything, the Jenkins core has loads of references to java packages pointing to hudson.XXX. This is for legacy reasons, Jenkins used to be called Hudson. When the splitting of the project and renaming to Jenkins was done, the java package structure and names was kept in order to maintain backwards comparability for plugins (otherwise all plugins would have to be updated).
In case you've got compilation errors due to this, then something is wrong with your setup, ensure that the maven dependencies are correct as mishadoff says.
Every jenkins plugin should refer to parent object in pom.xml
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>2.21</version>
<relativePath />
</parent>
You can find more examples at official git plugin https://github.com/jenkinsci/git-plugin/blob/master/pom.xml#L3
UPDATE: The plugin Files Found Trigger you're trying to modify, uses parent dependency in pom.xml https://github.com/jenkinsci/files-found-trigger-plugin/blob/master/pom.xml#L4
All import hudson.* statements, come exactly from that lib:
Related
There are a lot of questions about this, but the answers seem to contradict each other. So I wanted to ask it for my version of Maven (3.0.4).
I have a JAR file that's not part of any maven repository. It's a local dependency. I understand there are two ways to add it to my Maven project.
Add it as a dependency and specify the file path in the <systemPath> property. (No other work needed.)
Create a local repository <my-project>/repo and install the JAR in this repository. Then, add the new repository in my pom.xml file and add the new dependency.
I'm curious which way is better practice? I've heard some negative things about the <systemPath> property, although that way looks faster.
The answer is, it depends...
If you add it as a system dependency it is likely to become path dependent which makes it more difficult to share among other developers. Sure you can also distribute the 3rd party jar relative to your POM via your SCM but the intention of systemPath is more for dependencies that are provided by the JDK or the VM. From the docs about systemPath:
They are usually used to tell Maven about dependencies which are provided by the JDK or the VM. Thus, system dependencies are especially useful for resolving dependencies on artifacts which are now provided by the JDK, but where available as separate downloads earlier.
To install the jar in the local repo is also not friendly for sharing. It requires all developers to "upload" the jar to their local repo before building. You can of course add a script that handles this for you but it is always easy to forget to upload and IMO a better solution is point 3 below. The local install process is described here.
If you are working in an organization where the developers share the POM you should upload the 3rd party jar to a local repository manager. That way you can easily work with the 3rd party jar as if using any other maven enabled jar. Check this link for a comprehensive list on repository managers.
To summarize, if you are sharing the POM with others I would suggest that you upload it to a local repository manager. Otherwise the second option can work for you. As a last option, I would fall back to option number 1.
Also note that this has nothing to do with which version of Maven you are running.
You can add jar to your local maven repository. Usually it located at:
$home_directory/.m2/repository
For example you have expample.jar and you want to add it to your pom as:
<dependency>
<groupId>com.example</groupId>
<artifactId>example</artifactId>
<version>1.0</version>
</dependency>
Then you must add example.jar to:
$home_directory/.m2/repository/com/example/1.0/example.jar
In my case NetBeans do it for me.
The best way I see so far is to use install:install-file goal with maven. You can use the mvn command line to execute it directly with appropriate parameters, or if you are using eclipse EE, you can do so by leveraging the embedded maven and creating a Run Configuration as follows:
Then, you include the jar as follows:
<dependency>
<groupId>mylocal.weka</groupId>
<artifactId>weka</artifactId>
<version>1.0</version>
</dependency>
Of course adjust the parameters as per your needs.
Best,
Haytham
First, I've attempted to use the kie-maven-plugin in the project parent:
<groupId>org.kie</groupId>
<artifactId>kie-maven-plugin</artifactId>
<version>6.1.0.Final</version>
<extensions>true</extensions>
but after further reading it doesn't sound like it actually precompiles the rules before placing them in the jar (and I don't see any sign of it doing so).
I also see that there is a drools verifier, however it seems that this only works to verify drl files within Java.
Is there a good way to compile / verify a drl file in a Maven build so that I don't deploy and run the webservice only to find that there is a typo in the drl file?
I'm currently using Eclipse Kepler w/ the Drools plugins, Maven 3.x and Drools 6.0.1.
I would guess that you forgot to specify the packaging as "kjar". If that is the case, the plugin won't be executed during the Maven build. Simply add <packaging>kjar</packaging> into you pom.xml.
Please see the example usage of the kie-maven-plugin: https://github.com/droolsjbpm/drools/blob/master/kie-maven-plugin-example/pom.xml
To best of my knowledge the kie-maven-plugin only verifies that the resources can be compiled. Running Drools verifier is not part of the execution.
If you are already using the "kjar" packaging, please post the entire pom.xml, otherwise it is hard to guess what is actually causing the described behavior.
I work with a partner in java programming, I use intellij and he uses Eclipse.
Is there a way that we can somehow mutually share our code with each other so we could work on the same code each in our own time?
Thanks
There is that possibility using GIT or another Code repository. Look at https://github.com/
or https://bitbucket.org/. There is also very helpfull article.
To be also independant you can simply integrate your code with Maven, both incellij and eclipse can import project based only on pom.xml file created in maven setup.
In this your should use repository when there are more than one programmer on a single project whether you are using even same IDE. SVN will be one of the choices for repository
Given that you guys need to implement version control, one important aspect of co-operating together is to keep your codebase IDE-agnostic.
Thankfully, with java and maven there is an easy way to do this.
Firstly, commit to building your project with a build tool such as maven. Therefore, using this example, the pom.xml is the master configuration file for your project.
In contrast, your "project" files (either your .idea folder for intellij or your .project, .classpath and related files for eclipse) should not be checked into version control at all.
You can then add "ignores" to your VCS so that IDE-specific configuration files are not checked in - this way you won't interfere with each other with IDE-specific things.
Then, it is relatively easy for both of you to share a maven (pom.xml) based project with each other, and to configure your IDE independently from each other (i.e.: locally).
I have a Maven project that needs to be versioned. I have chosen to use the versions-maven-plugin as my versioning plugin but am unsure if that's the best option.
I have read the documentation that such plugin actually modifies the POM and I don't really like that approach. I have worked on projects where they had separate build.properties file that got modified manually.
What I want to achieve is to have my CI generating the artifact for me ready to be deployed and update the version number automatically.
So, any suggestions? How have you done before?
Thank you
I'd get the version number from the one source that matters: that's the source code management system (Subverson, Mercurial, or Git), not Maven.
I'd say that Maven might be out of synch unless your Maven plug-in is getting it from SCM.
Use the Release Plugin. You want to perform automatic deployment and batch release. The Versions Plugin is designed for something else.
We have found MAVEN-RELEASE-PLUGIN super useful and can not imagine releasing and managing version with it.
On the development shop I work for, we have an internal MAVEN repository, to keep our libraries (proprietary & open-souce). A common problem that we face is that, sometimes, the open-source libraries in our local MAVEN repository gets obsolete. Is there an automatic way to keep all the open-source libraries I use in my MAVEN repository always updated? What do you suggest to resolve this issue?
Archiva has been mentioned, but nexus seems more popular. Both have been designed to solve problems like the one you're having
Assuming you:
Don't want to download everything
Don't want to run another server
process
Only want to track a limited number
of projects
You might want to create a separate pom.xml file with dependencies like this:
<dependency>
<groupId>org.openfoo</groupId>
<artifactId>jfoo</artifactId>
<version>[1.0.0,2.0.0)</version>
</dependency>
This will tell maven to use jfoo 1.0.0 up to jfoo 2.0.0 so when jfoo releases version 1.2.17, you'll be fetching that in the next build assuming your settings are set to check versions each time.
This pom doesn't have to actually build anything. Just list those things you want to track.
Running:
cd the-path-to-the-project; mvn -q -B -U package
Via cron once a day will update all the dependencies in that pom and only report when there is a problem
BTW, this is a hack. If the number of developers is > 3 and you have the resources to run nexus, don't bother with the hack.
Take a look at Apache Archiva, a repository manager for Maven.