[Soc-coordination] [GSoC] Status Reoprt: Java Project Dependency Builder

[Daniel Pocock]

On 09/06/14 11:16, Andrew Schurman wrote:
> On Sat, Jun 7, 2014 at 1:08 AM, Daniel Pocock <daniel at pocock.com.au> wrote:
>>
>>
>> On 07/06/14 09:33, Andrew Schurman wrote:

>>
>> For some projects you will need to patch their pom file or build.xml or
>> whatever and it would be ideal if you forked their Git repository and
>> created your changes on a branch.
>>
>> If the project is in an SVN repo, you will probably need my sync2git script:
>> https://github.com/dpocock/sync2git
>>
>> Please have a look at the issues in github too, #2 is quite easy:
>> https://github.com/dpocock/sync2git/issues
> 
> Instead of cloning the entire history, what if we just take a snapshot
> of the files at that particular version? It will save us from
> translating between VCSs. We could do something different for git, but
> I think doing the same thing for everything would make things easier.
> 

I've been using this approach for some very big projects like
reSIProcate and sipXtapi for a while now - the sync2git script runs
automatically from cron.  For over 90% of SVN projects that use the
standard layout (trunk/branches/tags) this approach is likely to just
work.  The only manual work is tweaking authors.txt (e.g. inserting the
names), some people don't bother with that but I personally feel it is
good to properly attribute Git commits to their authors so they will
show up in Github reports, etc.

Doing VCS conversion does add some latency to the whole build process.
However, it means you can benefit from using VCS like tools to inspect
the changes.  For projects that are not in the 90%, e.g. those where
some manual effort is needed to get them to build, the VCS will provide
a consistent way for people to make the manual changes before the
automated build resumes again, e.g:

- build fails because foo.jar is missing

- foo SVN is found from foo.pom or some other clue

- foo-svn-mirror is created in Github using sync2git and a call to the
Github API

- using the Github API, a fork is created in Github, from foo-svn-mirror
-> foo-dfsg

- automated changes are made on a dfsg branch in foo-dfsg (e.g. removing
copies of junit.jar or other binary or non-free artifacts in the repository)

- now for the manual step - the developer can manually tweak the
build.xml or commit a build.properties or whatever is needed.  These
changes are also committed on the dfsg branch in the foo-dfsg fork

- finally, the developer sends some signal to kick off the automated
build again (e.g. with a command line or web-based UI)

Regards,

Daniel