gerrit/gerrit-patch-jgit/BUCK
David Ostrovsky 64d4bdf946 Buck: Emulate real JGit project structure in its own cell
I39f2d5d7 isolated jgit in its own cell, that is based on this JGit
Buck build implementation: [1]. Migration was done seamlessly, meant
that single BUCK file in lib/jgit represents JGit cell root location.
However, the real structure of JGit project is divided to number of
different sub-projects. To map between simplified JGit cell in gerrit
and real JGit project structure in JGit project, java_library() rules
were added to root BUCK file in JGit project that work like proxy to
real rules located in JGit sub-projects. For example //:jgit in JGit
tree was implemented as:

  java_library(
    name = 'jgit',
    exported_deps = ['//org.eclipse.jgit:jgit'],
    visibility = ['PUBLIC'],
  )

Such proxies are needed for every artifact that is referenced from
gerrit build and make Buck build implementation unnecessary verbose.
Moreover this introduced some subtle issues, like using JGit
dependencies in context of java_doc rules, where $(location :foo) macro
is unable to resolve the underlying files because java_library with
exported dependencies only do not have association with output file.
An attempt to replace java_library with only exported dependenies with
prebuilt_jar: [2] that depends on the real artifact introduced another
problem with assembly of gerrit.war, because now jgit.jar is twice in
the classpath (because prebuilt_jar has output file association). To
fix this we would need to filter potential duplicates in the assembly
process of gerrit.war.

Instead of using proxy approach and to try to provide yet another
workaround to subtle problems, emulate the JGit project structure and
reference directly the same artifacts paths within gerrit JGit cell
in gerrit build:

  deps = [
    '@jgit//org.eclipse.jgit:jgit',
  ],

This simplifies JGit Buck build implementation, as we wouldn't need to
proxy all artifacts referenced from gerrit build from the root build
file. And this would fix all remaining issues.

This approach make gerrit build slightly more verbose. JGit upgrade
process would need to touch 4 files instead of only one. But given that
the Gerrit/JGit development integration is important feature, we would
like to support (as this integration attempt shows: [3]) in our build
toolchain, this overhead is justified.

With this change, the root build file in JGit project can be stripped:
[4].

[1] https://git.eclipse.org/r/61938
[2] https://git.eclipse.org/r/66547
[3] https://gerrit-review.googlesource.com/61892
[4] https://git.eclipse.org/r/66562

Change-Id: I2d278f80d0fedc4c5e9943804873f57145877dfe
2016-02-14 11:46:49 +01:00

65 lines
1.3 KiB
Python

SRC = 'src/main/java/org/eclipse/jgit/'
gwt_module(
name = 'client',
srcs = [
SRC + 'diff/Edit_JsonSerializer.java',
SRC + 'diff/ReplaceEdit.java',
],
gwt_xml = SRC + 'JGit.gwt.xml',
deps = [
'//lib:gwtjsonrpc',
':Edit',
],
provided_deps = ['//lib/gwt:user'],
visibility = ['PUBLIC'],
)
gwt_module(
name = 'Edit',
srcs = [':jgit_edit_src'],
deps = [':edit_src'],
visibility = ['PUBLIC'],
)
prebuilt_jar(
name = 'edit_src',
binary_jar = ':jgit_edit_src',
)
genrule(
name = 'jgit_edit_src',
cmd = 'unzip -qd $TMP $(location @jgit//org.eclipse.jgit:jgit_src) ' +
'org/eclipse/jgit/diff/Edit.java;' +
'cd $TMP;' +
'zip -Dq $OUT org/eclipse/jgit/diff/Edit.java',
out = 'edit.src.zip',
)
java_library(
name = 'server',
srcs = [
SRC + 'diff/EditDeserializer.java',
SRC + 'diff/ReplaceEdit.java',
SRC + 'internal/storage/file/WindowCacheStatAccessor.java',
SRC + 'lib/ObjectIdSerialization.java',
],
deps = [
'//lib:gson',
'@jgit//org.eclipse.jgit:jgit',
],
visibility = ['PUBLIC'],
)
java_test(
name = 'jgit_patch_tests',
srcs = glob(['src/test/java/**/*.java']),
deps = [
':server',
'//lib:junit',
'@jgit//org.eclipse.jgit:jgit',
],
source_under_test = [':server'],
visibility = ['//tools/eclipse:classpath'],
)