views:

97

answers:

1

So I have a dependency, actually two dependencies to which I'd like to make changes either right now like fixing JBSEAM-3424 or potentially in the future. The coding is not an issue - I'm capable of making the change - and I'm not seeking to fork the community project, just to have a local version as recommended by Will Hartung to get some work done.

My concern is that issues of process will come up and bite me further down the line. So SO what can I do to ensure I manage this properly. What best practices are there?

Some more specific sub-questions:

  • Should I change the artifact names?
  • How choose group artifact and version names?
  • Should I import the whole source tree or be selective?
  • What if I can't get the build system working in full - should I scale it down or try to keep it close to the original?
+1  A: 

Should I change the artifact names? How choose group artifact and version names?

Keep the groupId and artifactId of the module(s) you change the same, but use a qualifier on the version to ensure that it is obvious it is a non-standard version, for example 1.0.0-simon. This is pretty common practice.

Should I import the whole source tree or be selective? Update based on your comment: Personally I'd only add the artifacts I've changed to my local source repository. If you change another artifact later then add it to your SCM then.

What if I can't get the build system working in full

Worry about that when it happens. If the project is built with Maven it should be straightforward for you to build only the artifacts you need. If it uses an uber-ant build which you can't get working with your changes, then consider paring the build down.

Rich Seller
I'd assumed I'd need to add the project source code to my own repository, so really that was about how much of the original source to add to my own project's repository.
Simon Gibbs