TL;DR -> How to integrate a local Opendaylight Karaf App in the Opendaylight integration/distribution project, for local use? I am not looking to publish my code to upstream to official opendaylight repositories.
I am trying to understand how to make changes to source code of certain features in Opendaylight to fulfill my custom use-cases.
For this, I downloaded the Netconf Source code from "https://git.opendaylight.org/gerrit/netconf" and the distribution source code from "https://git.opendaylight.org/gerrit/integration/distribution".
I made certain modifications in the Netconf Code and built it using mvn clean install -Pq -Dcheckstyle.skip.
Now, how do I go about integrating these updates in the integration/distribution project?
FYI:
I am working on ODL "release/oxygen-sr2". However, I realise that newer versions are available and I am open to shifting to them.
Using Java 8 and Maven 3.6.0
I had been suggested that I could just maven build the Netconf Project code and run Apache Karaf from there. Any other feature could then be installed via the Karaf CLI. But, my use case would require modifications on multiple existing features and even creating a new feature. Therefore, this solution also doesn't work for me as I would still need to integrate everything in one central project.
Actually, it's pretty simple, but maybe not obvious. Build all the projects you
want locally, then build the integration/distribution project. Any artifacts it
finds in the local m2 repo will be used for the final int/dist karaf that will
get created.
in other words, for every project you want to customize, pull that repo, make
your changes, build it. Then as a last step, build the int/dist project.
I have a library and a program, both under my control and built using Gradle. What's the best way to develop these two at the same time?
I have set up a private maven repository to distribute the library and that's working, but I don't want to release to that repository every little experiment I make during development. It's slow and disruptive to users of the library.
I tried installing the jar to the local maven repository as explained here: Gradle alternate to mvn install but the project that's using the library is not picking up that newly installed version.
I think, you can try to use multi-project builds for that if it's possible. But you will likely need to restructure both your current projects to become modules of the same new project.
What's the best way to develop these two at the same time?
It depends by how the team is organized and what are your policies.
Of course if the team can use a git repo and access to the source code you can just use git without pushing a new version on the maven server for each commit or push.
Otherwise if other users can only use the final library, you have to push the version on the maven server.
I have set up a private repository to distribute the library and that's working, but I don't want to release to that repository every little experiment I make during development. It's slow and disruptive to users of the library.
Every maven repo has 2 different repositories:
release
snapshot
Usually release repo is used only for stable releases and the snapshot repo is used to publish little change, beta release and so on.
In any case it is not required that every changes in the code is pushed in the maven repo (it is a your choice)
It's slow
The time to upload artifacts usually is not so big, in any case you can evaluate to push the release in the maven repo with a CI server.
The best method seems to be to make one project include the other one when present by adding:
if (file("../libraryproject").exists()) {
includeBuild "../libraryproject"
}
to the settings.gradle file of the project that uses the library. That can be committed to the source code repo because when that directory doesn't exist, the dependency will be included in the traditional way.
This is called Composite Build in the Gradle world, IntelliJ seems to handle properly and theres'a recorded webcast showing the whole setup: https://www.youtube.com/watch?v=grPJanXfRPg
I've been working on a Java project using Gradle in Eclipse that builds on my local machine and works just fine. I want the project to be available to a team of developers via Git, but after creating the repository and trying to build on a different machine using both IntelliJ and Eclipse, I'm realizing that there are some challenges. For instance, it seems like there need to be minor changes in build.gradle. Or in IntelliJ, JDK 1.8.0 must be specified for java.util.stream.
My goal is to create a project that allows a team of developers to simply clone the repository, use any IDE they want, build the project and begin contributing right away. Has anyone attempted to do this before with Gradle? What are some tips or insights? Is Gradle a poor choice for this? How can I standardize the build, libraries, etc.?
I am making a Java application that uses Git. I found that there is something called
JavaGit, EGit and JGit.
I know that JavaGit and EGit/JGit are different. What I don't understand is the difference between EGit and JGit. Both are hosted on Eclipse projects but one seems to be Eclipse related and the other not.
I don't use Eclipse and I don't plan to, so I really don't care much about "Eclipse integration".
Is JGit somehow connected to Eclipse? (It is hosted on www.eclipse.org, and the documentation of JGit also has a lot of "eclipse" keywords inside)
Out of the three, what will I need to connect my Java program (not written in Eclipse) to work with Git repositories?
I would prefer a standalone Git library (i.e., without depending on a local Git installation)
EDIT: One more question:
Does JGit support Git bundle command?
EDIT: I found the answer -- it does (haven't tried it yet). It is in transport package in a class called BundleWriter
You can use JGit as standalone library, but, as mentioned in the JGit Homepage:
JGit can be found within:
* EGit, Eclipse team provider for Git
In that sense, JGit is connected to Eclipse in that EGit uses JGit features to develop the Eclipse Git plugin.
Considering all Eclipse projects are now versioned in Git repos (instead of previously CVS repos), I would consider JGit for your Java project, as it seems that:
JavaGit isn't updated for quite some time (2008)
Eclipse is committed to offer a good support for Git through EGit, which should ensure by extension the development of JGit (used by EGit).
Thorbjørn Ravn Andersen comments:
Even though you say that Egit uses JGit, it is not quite clear in the above that EGit is an Eclipse plugin for git giving git support in the same way that CVS is already supported in Eclipse
The migration of Eclipse projects from CVS to Git is in progress, and has been reported here (by Chris Aniszczyk).
I’ve monitored conversations concerning the migration of project code from CVS to Git in the dev-lists of several projects.
Most developers, it seems, understand the value proposition of migrating, despite their concerns that with migration comes a whole lot of new learnin’ as they figure out how to say productive in the new environment.
Inevitably, discussion about the team provider for Git being developed by the EGit project becomes an prominent part of the conversation. “Is EGit ready for primetime?” is often the question that bounced around
The official bug illustrated Eclipse commitment to provide "adequate tooling support" for all Eclipse projects now on Git repo is the bug 293192.
In order to deprecate old VCS in favour of git (bug 270854), adequate tooling
should be available. This bug is created to track that.
[...] I opened/linked relevant EGit bugs in order to have a better visibility/tracking
of what's missing.
So Egit is the only project referenced in that bug to provide said adequate tooling support for the new (D)VCS chosen for all Eclipse projects.
(bug 270854 is about Deprecate old VCS tools, which includes essentially CVS.)
Just in (March 17th, 2001): The State of Git at Eclipse – Early 2011 (Chris Aniszczyk):
I’m happy that things have come quite a long way since last year based on Eclipse Marketplace stats and the community contributions the projects have received.
So what’s next? In terms of tooling, we’re getting closer to our 1.0 release (which is planned for the Indigo release).
The git tooling at Eclipse is much better these days, if you need help or have questions, please start with the most excellent EGit User Guide.
If you’re an eclipse.org project, please consider starting the process to move your project repository to Git. There are a lot of eclipse.org projects already on Git.
It would be nice to see the all of the eclipse.org projects have plans to move to Git by the Indigo release.
As one of the authors of JGit and EGit, sorry for the confusion.
JGit is an EDL (new-style BSD) licensed, lightweight, pure Java library implementing the Git version control system. It can be used in a standalone fashion and is embedded in applications such as Gerrit, Eclipse, Netbeans and IntelliJ. EGit embeds JGit to use it to work with Git repositories and expose Git constructs from within Eclipse. At the moment, JGit doesn't support the git-bundle command but you're welcome to contribute support, it shouldn't be that hard, please see our contributor guide.
Just to chime in, as I just stumbled on this this question just now.
There is a difference between the Eclipse Foundation and the Eclipse IDE. The Foundation is the umbrella organization, while the IDE is one of the projects developed through the foundation. So, the important thing to know is that just as Apache started with the web server and branched out to become a Foundation hosting a number of projects, so has the Eclipse Foundation now expanded beyond its "roots" in the IDE.
So in this context the JGit code provides a Java API for git commands, while EGit uses JGit to provide git support for the Eclipse IDE.
Personally, I also find this a little confusing at times, and sometimes it almost seems that having so much going on has in some ways degraded the focus of these organizations; however I can also see the utility in having one umbrella organization instead of 20 similar but different organizations.
JGit is git implemented from scratch as a Java library whereas JavaGit is (was ?) a Java API wrapping the native git implementation (i.e. it's calling the native git command line).
EGit is the Git Eclipse Team Provider integrating JGit into the Eclipse IDE and is providing the UI to work with Git from inside Eclipse.
In the meantime a large part of the Eclipse community and also a large number of corporate developers is using EGit/JGit (that's the reason why the companies backing these projects put money into that). See the project pages ([1], [2]) and ohloh if you want to get some insight who is contributing.
JGit is a library to manipulate git repository. You do not use JGit alone, unless you write a program to manipulate git repository in the way you like.
If you use Eclipse as the IDE, you install EGit as a version control plugin (defaulted in Indigo). EGit calls JGit so you also have JGit installed if you install EGit.
Note, for Netbeans, you install NBGit as a version control plugin. NBGit also calls JGit.
JavaGit: not actively maintained?
JGit is the Java implementation of Git. It is a library, that also can be used in your own applications. It also provides some sort of CLI operations.
EGit on the other side is the Eclipse team provider plugin for Git, which uses JGit as Git implementation. Simplified you could say EGit is the UI part, and JGit the background part.
JGit doesn't depend on EGit, but EGit does depend on JGit.
From: https://www.eclipse.org/forums/index.php/t/273443/
I am building a plugin for Eclipse - but as we use Maven as a standard build platform I would like to be able to build the plugin using Maven.
I have found a previous question about using Maven with Eclipse Plugins - but as it is a year old I thought it was worthwhile collecting some new answers:
Is it currently possible to build Eclipse Plugins by Maven AND have nice IDE Integration?
It seems that Tycho has not been driven forward much in the last year - but has anything else been created that fulfils this need or is there an easier way?
Does anyone recommend still the Maven PDE plugin? Is this a cumbersome solution as it is just a wrapper for ANT scripts?
I'm on the Tycho mailing list and I see plenty of feedback that suggests that people are successfully building plug-ins using Maven. My current project isn't doing OSGi development, so I can't vouch from personal experience with the latest version of Tycho. It's also worth pointing out that Tycho currently supports (to the best of my knowledge) a manifest-first approach to building plug-ins (as apposed to POM-first) - this might be a factor in deciding if Maven/Tycho fits your project.
It seems that Tycho has not been driven forward much in the last year - but has anything else been created that fulfils this need or is there an easier way?
The project is definitely active (have a look at the git repository), regardless of the updates of its website and AFAIK Sonatype is using it (successfully) for m2eclipse.