I’m in a pickle. There’s a project at $WORK that I should have been paying closer attention to (but haven’t). We’ve taken some 3rd party software (guanxi as it happens), and made some modifications in order to form our own custom distribution. But:
- We started modifying what was then the trunk.
- The trunk has moved forwards.
- Our modifications are not isolated chunks of work (though they should be).
In other words, it’s a classic merge scenario. Except that both our changes and the trunk are contained within a CVS repository. This means that the original ancestor (the point at which divergence started) can be somewhat difficult to ascertain.
Thankfully, I’ve had moderate success using git cvsimport to pull everything into a git repository. Well, actually five git repositories, thanks to git cvsimport not quite understanding CVS’ modules file format. So, git merge should assist me. But of course, I’m unfamiliar enough with the guanxi code to know how to successfully resolve conflicts. Best of all, it looks like new development which is similar to ours is happening on a branch destined to go into the trunk.
Where does this leave me? For now, a long session of merging with the developer who did the changes. But longer term, we also need to:
- Split out our code changes into their own packages (or for preference, project).
- Regularly merge in changes from trunk.
- Talk to the original developer about whether or not he can make life easier for us.
- Switch to using git proper rather than developing in the original CVS tree.
It doesn’t help that the project in question is a Java webapp — we want to reuse the classes in that webapp as a jar file in our own webapp. This is yet another complicating factor…
My head hurts.
Jabbering Giraffe 
4 replies on “Managing 3rd Party Code”
I’m flattered you’re using the code! Hope it’s of some use. Drop me a note and we can make sure what I do is reusable for you. I suspect the webapp as jar is already covered by a build option.
Thanks — we’ll definitely be in touch. Right now, we’re looking over the changes we’ve already made to see which ones need to go back into the mainline and which ones need to be pulled out into their own project.
Unfortunately, the webapp-as-jar thing is the packaging element in the pom, which I don’t think is easy to override. For other projects, we’ve generally split out the source code into a separate jar-based project and made it a dependency of the webapp. This has worked quite well for reuse.
If you look in Core/pom.xml you’ll see the deploy config – this packages the webapps (IdP, Guard and Engine) as jar files. So the main build for each webapp produces a war but deploying them produces jars. I had the same requirement for webapp as jar so added that bit.
Awesome! Thank you!