قوانین جاوا

گزارش یک مشکل مشاهده منبع

قوانین

java_binary

مشاهده منبع قانون
java_binary(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, output_licenses, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)

یک بایگانی جاوا ("فایل jar")، به اضافه یک اسکریپت پوسته پوششی با همان نام قانون ایجاد می کند. اسکریپت wrapper shell از یک classpath استفاده می‌کند که شامل یک فایل jar برای هر کتابخانه است که باینری به آن بستگی دارد. هنگام اجرای اسکریپت wrapper shell، هر متغیر محیطی JAVABIN خالی بر نسخه مشخص شده از طریق پرچم --java_runtime_version Bazel اولویت دارد.

اسکریپت wrapper چندین پرچم منحصر به فرد را می پذیرد. برای فهرستی از پرچم‌های قابل تنظیم و متغیرهای محیطی پذیرفته‌شده توسط wrapper به //src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt مراجعه کنید.

اهداف خروجی ضمنی

  • name .jar : یک آرشیو جاوا، حاوی فایل‌های کلاس و سایر منابع مربوط به وابستگی‌های مستقیم باینری.
  • name -src.jar : آرشیو حاوی منابع ("مقدار منبع").
  • name _deploy.jar : یک بایگانی جاوا مناسب برای استقرار (فقط در صورت درخواست صریح ساخته شده است).

    ساختن هدف < name >_deploy.jar برای قانون شما، یک فایل jar خود حاوی یک مانیفست ایجاد می کند که به آن اجازه می دهد با دستور java -jar یا با گزینه --singlejar اسکریپت wrapper اجرا شود. استفاده از اسکریپت wrapper به java -jar ترجیح داده می شود زیرا پرچم های JVM و گزینه های بارگیری کتابخانه های بومی را نیز پاس می کند.

    Deploy jar شامل تمام کلاس هایی است که توسط یک کلاس لودر که مسیر کلاس را از اسکریپت wrapper باینری از ابتدا تا انتها جستجو می کند، پیدا می کند. همچنین شامل کتابخانه های بومی مورد نیاز برای وابستگی ها می باشد. اینها در زمان اجرا به طور خودکار در JVM بارگذاری می شوند.

    اگر هدف شما یک ویژگی راه‌انداز را مشخص می‌کند، به جای اینکه یک فایل JAR معمولی باشد، _deploy.jar یک باینری بومی خواهد بود. این شامل راه‌انداز به‌علاوه وابستگی‌های بومی (C++) قانون شما است که همگی به یک باینری ثابت پیوند شده‌اند. بایت های فایل jar واقعی به آن باینری بومی اضافه می شود و یک حباب باینری منفرد حاوی کد اجرایی و جاوا ایجاد می کند. شما می توانید فایل jar به دست آمده را مستقیماً مانند هر دودویی بومی اجرا کنید.

  • name _deploy-src.jar : آرشیو حاوی منابع جمع آوری شده از بسته شدن گذرای هدف. اینها با کلاس‌های موجود در deploy.jar مطابقت می‌کنند، به جز مواردی که jarها هیچ منبع jar منطبقی ندارند.

ویژگی deps در یک قانون java_binary بدون srcs مجاز نیست. چنین قاعده ای به یک main_class نیاز دارد که توسط runtime_deps ارائه شده است.

قطعه کد زیر یک اشتباه رایج را نشان می دهد:

java_binary(
    name = "DontDoThis",
    srcs = [
        ...,
        "GeneratedJavaFile.java",  # a generated .java file
    ],
    deps = [":generating_rule"],  # rule that generates that file
)

در عوض این کار را انجام دهید:

java_binary(
    name = "DoThisInstead",
    srcs = [
        ...,
        ":generating_rule",
    ],
)

استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.


استفاده از نام فایل منبع که نقطه ورود اصلی برنامه است (منهای پسوند) تمرین خوبی است. به عنوان مثال، اگر نقطه ورودی شما Main.java نام دارد، نام شما می تواند Main باشد.
deps

لیست برچسب ها ؛ پیش فرض []

لیست کتابخانه های دیگری که باید به هدف مرتبط شوند. نظرات کلی درباره deps را در ویژگی‌های معمولی که توسط اکثر قوانین ساخت تعریف شده‌اند، ببینید.
srcs

لیست برچسب ها ؛ پیش فرض []

فهرست فایل‌های منبعی که برای ایجاد هدف پردازش می‌شوند. این ویژگی تقریباً همیشه مورد نیاز است. استثناها را در زیر ببینید.

فایل های منبع از نوع .java کامپایل شده اند. در مورد فایل‌های .java تولید شده، معمولاً توصیه می‌شود که نام قانون تولیدکننده را به جای نام خود فایل در اینجا قرار دهید. این نه تنها خوانایی را بهبود می بخشد، بلکه قانون را در برابر تغییرات آتی انعطاف پذیرتر می کند: اگر قانون تولید فایل های مختلفی در آینده ایجاد کند، فقط باید یک مکان را اصلاح کنید: outs قانون تولید. شما نباید قانون تولید را در deps فهرست کنید زیرا یک no-op است.

فایل های منبع از نوع .srcjar باز و کامپایل می شوند. (اگر نیاز به ایجاد مجموعه ای از فایل های .java با ژانر دارید، این کار مفید است.)

قوانین: اگر قانون (معمولا genrule یا filegroup ) هر یک از فایل های ذکر شده در بالا را ایجاد کند، به همان روشی که برای فایل های منبع توضیح داده شد استفاده می شود.

این آرگومان تقریباً همیشه مورد نیاز است، مگر اینکه یک ویژگی main_class کلاسی را در مسیر کلاس اجرا مشخص کند یا آرگومان runtime_deps را مشخص کنید.

resources

لیست برچسب ها ؛ پیش فرض []

لیستی از فایل های داده ای که باید در یک جاوا گنجانده شوند.

اگر منابع مشخص شده باشند، به همراه فایل‌های .class معمولی که توسط کامپایل تولید می‌شوند، در jar قرار می‌گیرند. محل منابع داخل فایل jar توسط ساختار پروژه تعیین می شود. Bazel ابتدا به دنبال طرح‌بندی دایرکتوری استاندارد Maven می‌گردد. اگر این مورد پیدا نشد، Bazel سپس به دنبال بالاترین دایرکتوری با نام "java" یا "javatests" می گردد (بنابراین، برای مثال، اگر منبعی در <workspace root>/x/java/y/java/z باشد، مسیر منبع y/java/z خواهد بود.این اکتشافی را نمی توان نادیده گرفت، با این حال، ویژگی resource_strip_prefix می تواند برای تعیین یک فهرست جایگزین خاص برای فایل های منبع استفاده شود.

منابع ممکن است فایل های منبع یا فایل های تولید شده باشند.

classpath_resources

لیست برچسب ها ؛ پیش فرض []

از این گزینه استفاده نکنید مگر اینکه راه دیگری وجود نداشته باشد)

فهرستی از منابعی که باید در ریشه درخت جاوا قرار گیرند. تنها هدف این ویژگی پشتیبانی از کتابخانه های شخص ثالث است که نیاز دارند منابع آنها در مسیر کلاس دقیقاً "myconfig.xml" پیدا شوند. به دلیل خطر تداخل فضای نام، فقط روی باینری ها مجاز است و نه کتابخانه ها.

create_executable

بولی؛ غیر قابل تنظیم پیش فرض True است

منسوخ شده، به جای آن از java_single_jar استفاده کنید.
deploy_env

لیست برچسب ها ؛ پیش فرض []

فهرستی از دیگر اهداف java_binary که نشان دهنده محیط استقرار این باینری است. این ویژگی را هنگام ساخت افزونه ای که توسط java_binary دیگری بارگذاری می شود، تنظیم کنید.
تنظیم این ویژگی، تمام وابستگی‌ها را از مسیر کلاسی زمان اجرا (و deploy jar) این باینری که بین این باینری و اهداف مشخص شده در deploy_env به اشتراک گذاشته شده است، حذف می‌کند.
deploy_manifest_lines

لیست رشته ها؛ پیش فرض []

فهرستی از خطوط برای افزودن به فایل META-INF/manifest.mf که برای هدف *_deploy.jar ایجاد شده است. محتویات این ویژگی مشمول جایگزینی «مغیر ایجاد کنید» نیستند .
javacopts

لیست رشته ها؛ پیش فرض []

گزینه های کامپایلر اضافی برای این کتابخانه. مشروط به جایگزینی "Make variable" و نشانه گذاری پوسته Bourne .

این گزینه های کامپایلر پس از گزینه های کامپایلر جهانی به javac منتقل می شوند.

jvm_flags

لیست رشته ها؛ پیش فرض []

لیستی از پرچم‌ها برای جاسازی در اسکریپت wrapper ایجاد شده برای اجرای این باینری. مشروط به جایگزینی $(location) و "Make variable" و نشانه گذاری پوسته Bourne .

اسکریپت wrapper برای یک باینری جاوا شامل یک تعریف CLASSPATH (برای یافتن تمام jar های وابسته) است و مفسر جاوا مناسب را فراخوانی می کند. خط فرمان تولید شده توسط اسکریپت wrapper شامل نام کلاس اصلی و به دنبال آن یک "$@" است تا بتوانید آرگومان های دیگر را بعد از نام کلاس ارسال کنید. با این حال، آرگومان های در نظر گرفته شده برای تجزیه توسط JVM باید قبل از نام کلاس در خط فرمان مشخص شوند. محتویات jvm_flags قبل از لیست شدن نام کلاس به اسکریپت wrapper اضافه می شود.

توجه داشته باشید که این ویژگی روی خروجی های *_deploy.jar تاثیری ندارد.

launcher

برچسب ؛ پیش فرض None است

یک باینری را مشخص کنید که برای اجرای برنامه جاوا به جای برنامه bin/java معمولی همراه با JDK استفاده شود. هدف باید یک cc_binary باشد. هر cc_binary که Java Invocation API را پیاده سازی می کند، می تواند به عنوان مقداری برای این ویژگی مشخص شود.

به طور پیش فرض، Bazel از لانچر معمولی JDK (bin/java یا java.exe) استفاده می کند.

پرچم مربوط به --java_launcher Bazel فقط بر آن دسته از اهداف java_binary و java_test تأثیر می گذارد که مشخصه launcher مشخص نکرده اند.

توجه داشته باشید که وابستگی‌های بومی شما (C++، SWIG، JNI) بسته به اینکه از لانچر JDK یا راه‌انداز دیگری استفاده می‌کنید، متفاوت ساخته می‌شوند:

  • اگر از راه‌انداز معمولی JDK (پیش‌فرض) استفاده می‌کنید، وابستگی‌های بومی به‌عنوان یک کتابخانه مشترک با نام {name}_nativedeps.so ساخته می‌شوند، جایی که {name} ویژگی name این قانون java_binary است. کد استفاده نشده توسط پیوند دهنده در این پیکربندی حذف نمی شود.
  • اگر از هر راه‌انداز دیگری استفاده می‌کنید، وابستگی‌های بومی (C++) به صورت ایستا به یک باینری به نام {name}_nativedeps پیوند داده می‌شوند، جایی که {name} ویژگی name این قانون java_binary است. در این مورد، پیوند دهنده هر کدی را که فکر می‌کند استفاده نشده است را از باینری حاصل حذف می‌کند، به این معنی که هر کد C++ که فقط از طریق JNI به آن دسترسی پیدا می‌کند ممکن است به آن پیوند داده نشود مگر اینکه آن هدف cc_library alwayslink = 1 مشخص کند.

هنگام استفاده از هر راه‌اندازی غیر از راه‌انداز پیش‌فرض JDK، فرمت خروجی *_deploy.jar تغییر می‌کند. برای جزئیات بیشتر به اسناد اصلی java_binary مراجعه کنید.

main_class

رشته؛ پیش فرض "" است

نام کلاس با متد main() برای استفاده به عنوان نقطه ورودی. اگر یک قانون از این گزینه استفاده کند، نیازی به لیست srcs=[...] ندارد. بنابراین، با این ویژگی می توان یک فایل اجرایی از یک کتابخانه جاوا ایجاد کرد که از قبل حاوی یک یا چند متد main() است.

مقدار این ویژگی یک نام کلاس است، نه یک فایل منبع. کلاس باید در زمان اجرا در دسترس باشد: ممکن است توسط این قانون کامپایل شود (از srcs ) یا توسط وابستگی های مستقیم یا گذرا (از طریق runtime_deps یا deps ) ارائه شود. اگر کلاس در دسترس نباشد، باینری در زمان اجرا از کار می افتد. هیچ بررسی زمان ساخت وجود ندارد.

plugins

لیست برچسب ها ؛ پیش فرض []

پلاگین های کامپایلر جاوا برای اجرا در زمان کامپایل. هر java_plugin مشخص شده در این ویژگی هر زمان که این قانون ساخته شود اجرا می شود. یک کتابخانه همچنین ممکن است افزونه‌هایی را از وابستگی‌هایی که از exported_plugins استفاده می‌کنند به ارث ببرد. منابع تولید شده توسط افزونه در jar حاصل از این قانون گنجانده می شود.
resource_jars

لیست برچسب ها ؛ پیش فرض []

منسوخ شده: به جای آن از java_import و deps یا runtime_deps استفاده کنید.
resource_strip_prefix

رشته؛ پیش فرض "" است

پیشوند مسیر برای حذف از منابع جاوا.

اگر مشخص شده باشد، این پیشوند مسیر از هر فایلی در ویژگی resources حذف می شود. این یک خطا است که یک فایل منبع در این فهرست قرار ندارد. اگر مشخص نباشد (پیش‌فرض)، مسیر فایل منبع با همان منطق بسته جاوا فایل‌های منبع تعیین می‌شود. به عنوان مثال، یک فایل منبع در stuff/java/foo/bar/a.txt در foo/bar/a.txt قرار خواهد گرفت.

runtime_deps

لیست برچسب ها ؛ پیش فرض []

کتابخانه‌هایی که فقط در زمان اجرا برای باینری نهایی یا آزمایش در دسترس قرار می‌گیرند. مانند deps معمولی، اینها در مسیر کلاس اجرا ظاهر می‌شوند، اما بر خلاف آن‌ها، در مسیر کلاسی زمان کامپایل ظاهر نمی‌شوند. وابستگی های مورد نیاز فقط در زمان اجرا باید در اینجا فهرست شوند. ابزارهای تجزیه و تحلیل وابستگی باید اهدافی را که در runtime_deps و deps ظاهر می شوند نادیده بگیرند.
stamp

عدد صحیح؛ پیش فرض -1 است

اینکه اطلاعات ساخت را در باینری رمزگذاری کنیم یا نه. مقادیر ممکن:
  • stamp = 1 : همیشه اطلاعات ساخت را در باینری مهر کنید، حتی در ساخت های --nostamp . از این تنظیم باید اجتناب شود ، زیرا به طور بالقوه حافظه پنهان از راه دور را برای باینری و هر اقدام پایین دستی که به آن وابسته است از بین می برد.
  • stamp = 0 : همیشه اطلاعات ساخت را با مقادیر ثابت جایگزین کنید. این باعث می شود که نتایج ساخت خوبی در حافظه پنهان ذخیره شود.
  • stamp = -1 : جاسازی اطلاعات ساخت توسط پرچم --[no]stamp کنترل می شود.

باینری های مهر شده بازسازی نمی شوند مگر اینکه وابستگی آنها تغییر کند.

use_launcher

بولی؛ پیش فرض True است

اینکه آیا باینری باید از یک راه‌انداز سفارشی استفاده کند یا خیر.

اگر این ویژگی روی false تنظیم شود، ویژگی راه‌انداز و پرچم مربوط به --java_launcher برای این هدف نادیده گرفته می‌شود.

use_testrunner

بولی؛ پیش فرض False است

از کلاس تست runner (به طور پیش فرض com.google.testing.junit.runner.BazelTestRunner ) به عنوان نقطه ورودی اصلی برای یک برنامه جاوا استفاده کنید و کلاس تست را به عنوان مقدار ویژگی سیستم bazel.test_suite در اختیار اجراکننده آزمایش قرار دهید. می‌توانید از این برای لغو رفتار پیش‌فرض استفاده کنید، یعنی استفاده از test runner برای قوانین java_test ، و نه استفاده از آن برای قوانین java_binary . بعید است که بخواهید این کار را انجام دهید. یکی از موارد استفاده برای قوانین AllTest است که توسط قانون دیگری احضار می شوند (مثلاً برای راه اندازی پایگاه داده قبل از اجرای آزمایش). قانون AllTest باید به‌عنوان یک java_binary اعلان شود، اما همچنان باید از اجرای آزمایشی به عنوان نقطه ورودی اصلی خود استفاده کند. نام یک کلاس اجراکننده آزمایشی را می توان با ویژگی main_class رد کرد.

java_import

مشاهده منبع قانون
java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)

این قانون اجازه می دهد تا از فایل های jar .jar از پیش کامپایل شده به عنوان کتابخانه برای قوانین java_library و java_binary استفاده کنید.

مثال ها


    java_import(
        name = "maven_model",
        jars = [
            "maven_model/maven-aether-provider-3.2.3.jar",
            "maven_model/maven-model-3.2.3.jar",
            "maven_model/maven-model-builder-3.2.3.jar",
        ],
    )

استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

deps

لیست برچسب ها ؛ پیش فرض []

لیست کتابخانه های دیگری که باید به هدف مرتبط شوند. به java_library.deps مراجعه کنید.
data

لیست برچسب ها ؛ پیش فرض []

لیست فایل های مورد نیاز این قانون در زمان اجرا.
add_exports

لیست رشته ها؛ پیش فرض []

به این کتابخانه اجازه دسترسی به module یا package داده شده را بدهید.

این با پرچم های javac و JVM --add-exports= مطابقت دارد.

add_opens

لیست رشته ها؛ پیش فرض []

به این کتابخانه اجازه دهید تا به صورت بازتابی به module یا package داده شده دسترسی داشته باشد.

این با پرچم های javac و JVM --add-opens= مطابقت دارد.

constraints

لیست رشته ها؛ پیش فرض []

محدودیت های اضافی بر روی این قانون به عنوان یک کتابخانه جاوا اعمال می شود.
exports

لیست برچسب ها ؛ پیش فرض []

اهدافی که این قانون را در اختیار کاربران قرار می دهد. به java_library.exports مراجعه کنید.
jars

لیست برچسب ها ؛ ضروری

لیست فایل های JAR ارائه شده به اهداف جاوا که به این هدف بستگی دارد.

بولی؛ پیش فرض False است

از این کتابخانه فقط برای کامپایل استفاده کنید و نه در زمان اجرا. اگر کتابخانه در حین اجرا توسط محیط زمان اجرا ارائه شود مفید است. نمونه‌هایی از کتابخانه‌هایی مانند این، APIهای IDE برای پلاگین‌های IDE یا tools.jar برای هر چیزی که روی یک JDK استاندارد اجرا می‌شود، هستند.
proguard_specs

لیست برچسب ها ؛ پیش فرض []

فایل هایی که به عنوان مشخصات Proguard استفاده می شوند. اینها مجموعه مشخصات مورد استفاده توسط Proguard را توصیف می کنند. در صورت مشخص شدن، بسته به این کتابخانه به هر هدف android_binary اضافه می شوند. فایل‌های موجود در اینجا فقط باید دارای قوانین بی‌توان، یعنی -dontnote، -dontwarn، assumenosideeffects و قوانینی باشند که با -keep شروع می‌شوند. گزینه‌های دیگر فقط می‌توانند در proguard_specs android_binary ظاهر شوند تا از ادغام‌های غیر توتولوژیک اطمینان حاصل شود.
runtime_deps

لیست برچسب ها ؛ پیش فرض []

کتابخانه‌هایی که فقط در زمان اجرا برای باینری نهایی یا آزمایش در دسترس قرار می‌گیرند. به java_library.runtime_deps مراجعه کنید.
srcjar

برچسب ؛ پیش فرض None است

یک فایل JAR که حاوی کد منبع فایل های JAR کامپایل شده است.

java_library

مشاهده منبع قانون
java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)

این قانون منابع را به یک فایل .jar کامپایل و پیوند می دهد.

خروجی های ضمنی

  • lib name .jar : یک بایگانی جاوا حاوی فایل های کلاس.
  • lib name -src.jar : آرشیو حاوی منابع ("مقدار منبع").

استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

deps

لیست برچسب ها ؛ پیش فرض []

لیست کتابخانه هایی که باید به این کتابخانه پیوند داده شوند. نظرات کلی درباره deps را در ویژگی‌های معمولی که توسط اکثر قوانین ساخت تعریف شده‌اند، ببینید.

شیشه های ساخته شده توسط قوانین java_library که در deps فهرست شده اند در مسیر کلاسی زمان کامپایل این قانون قرار خواهند گرفت. علاوه بر این، بسته شدن موقتی deps ، runtime_deps و exports آنها در مسیر کلاس اجرا خواهد بود.

در مقابل، اهداف در ویژگی data در فایل‌های اجرا گنجانده می‌شوند اما نه در مسیر کلاس زمان کامپایل و نه در زمان اجرا قرار دارند.

srcs

لیست برچسب ها ؛ پیش فرض []

فهرست فایل‌های منبعی که برای ایجاد هدف پردازش می‌شوند. این ویژگی تقریباً همیشه مورد نیاز است. استثناها را در زیر ببینید.

فایل های منبع از نوع .java کامپایل شده اند. در مورد فایل‌های .java تولید شده، معمولاً توصیه می‌شود که نام قانون تولیدکننده را به جای نام خود فایل در اینجا قرار دهید. این نه تنها خوانایی را بهبود می بخشد، بلکه قانون را در برابر تغییرات آتی انعطاف پذیرتر می کند: اگر قانون تولید فایل های مختلفی در آینده ایجاد کند، فقط باید یک مکان را اصلاح کنید: outs قانون تولید. شما نباید قانون تولید را در deps فهرست کنید زیرا یک no-op است.

فایل های منبع از نوع .srcjar باز و کامپایل می شوند. (اگر نیاز به ایجاد مجموعه ای از فایل های .java با ژانر دارید، این کار مفید است.)

قوانین: اگر قانون (معمولا genrule یا filegroup ) هر یک از فایل های ذکر شده در بالا را ایجاد کند، به همان روشی که برای فایل های منبع توضیح داده شد استفاده می شود.

فایل های منبع از نوع .properties به عنوان منابع در نظر گرفته می شوند.

همه فایل‌های دیگر نادیده گرفته می‌شوند، تا زمانی که حداقل یک فایل از نوع فایلی که در بالا توضیح داده شد وجود داشته باشد. در غیر این صورت یک خطا مطرح می شود.

این آرگومان تقریبا همیشه مورد نیاز است، مگر اینکه آرگومان runtime_deps را مشخص کنید.

data

لیست برچسب ها ؛ پیش فرض []

لیست فایل های مورد نیاز این کتابخانه در زمان اجرا. نظرات کلی در مورد data در ویژگی های معمولی که توسط اکثر قوانین ساخت تعریف شده اند، مشاهده کنید.

هنگام ساختن java_library ، بازل این فایل ها را در جایی قرار نمی دهد. اگر فایل های data فایل های تولید شده باشند، Bazel آنها را تولید می کند. هنگام ساختن تستی که به این java_library وابسته است، Bazel فایل های data را به ناحیه runfiles کپی یا پیوند می دهد.

resources

لیست برچسب ها ؛ پیش فرض []

لیستی از فایل های داده ای که باید در یک جاوا گنجانده شوند.

منابع ممکن است فایل های منبع یا فایل های تولید شده باشند.

اگر منابع مشخص شده باشند، به همراه فایل‌های .class معمولی که توسط کامپایل تولید می‌شوند، در jar قرار می‌گیرند. محل منابع داخل فایل jar توسط ساختار پروژه تعیین می شود. Bazel ابتدا به دنبال طرح‌بندی دایرکتوری استاندارد Maven می‌گردد. اگر این مورد پیدا نشد، Bazel سپس به دنبال بالاترین دایرکتوری با نام "java" یا "javatests" می گردد (بنابراین، برای مثال، اگر منبعی در <workspace root>/x/java/y/java/z باشد، مسیر منبع y/java/z خواهد بود.این اکتشافی را نمی توان نادیده گرفت، با این حال، ویژگی resource_strip_prefix می تواند برای تعیین یک فهرست جایگزین خاص برای فایل های منبع استفاده شود.

add_exports

لیست رشته ها؛ پیش فرض []

به این کتابخانه اجازه دسترسی به module یا package داده شده را بدهید.

این با پرچم های javac و JVM --add-exports= مطابقت دارد.

add_opens

لیست رشته ها؛ پیش فرض []

به این کتابخانه اجازه دهید تا به صورت بازتابی به module یا package داده شده دسترسی داشته باشد.

این با پرچم های javac و JVM --add-opens= مطابقت دارد.

bootclasspath

برچسب ؛ پیش فرض None است

API محدود شده، استفاده نکنید!
exported_plugins

لیست برچسب ها ؛ پیش فرض []

لیست java_plugin ها (مثلاً پردازنده های حاشیه نویسی) برای صادرات به کتابخانه هایی که مستقیماً به این کتابخانه وابسته هستند.

لیست مشخص شده java_plugin ها برای هر کتابخانه ای که مستقیماً به این کتابخانه وابسته است اعمال می شود، درست مثل اینکه آن کتابخانه به صراحت این برچسب ها را در plugins اعلام کرده باشد.

exports

لیست برچسب ها ؛ پیش فرض []

کتابخانه های صادر شده

فهرست کردن قوانین در اینجا آنها را در اختیار قوانین والدین قرار می دهد، گویی که والدین صراحتاً به این قوانین وابسته هستند. این برای deps معمولی (غیر صادراتی) صادق نیست.

خلاصه: یک قانون X می تواند به کد Y دسترسی داشته باشد اگر یک مسیر وابستگی بین آنها وجود داشته باشد که با یک لبه deps شروع می شود که با صفر یا بیشتر یال های exports شروع می شود. بیایید چند مثال برای نشان دادن این موضوع ببینیم.

فرض کنید A به B بستگی دارد و B به C بستگی دارد. در این مورد C یک وابستگی گذرا از A است، بنابراین تغییر منابع C و بازسازی A همه چیز را به درستی بازسازی می کند. با این حال A نمی تواند از کلاس ها در C استفاده کند. برای اجازه دادن به آن، یا A باید C را در deps خود اعلام کند، یا B می تواند با اعلام C در (B) کار را برای A (و هر چیزی که ممکن است به A وابسته باشد) آسان کند. ) ویژگی exports .

بسته شدن کتابخانه های صادر شده برای همه قوانین والدین مستقیم در دسترس است. یک مثال کمی متفاوت در نظر بگیرید: A به B بستگی دارد، B به C و D، و همچنین C را صادر می کند اما D را صادر نمی کند. اکنون A به C دسترسی دارد اما به D دسترسی ندارد. حال، اگر C و D برخی از کتابخانه ها را صادر کنند، C' و D' به ترتیب، A فقط می تواند به C' دسترسی داشته باشد اما به D' دسترسی ندارد.

مهم: یک قانون صادر شده یک وابستگی منظم نیست. با چسبیدن به مثال قبلی، اگر B C را صادر می کند و می خواهد از C نیز استفاده کند، باید آن را نیز در deps خود فهرست کند.

javabuilder_jvm_flags

لیست رشته ها؛ پیش فرض []

API محدود شده، استفاده نکنید!
javacopts

لیست رشته ها؛ پیش فرض []

گزینه های کامپایلر اضافی برای این کتابخانه. مشروط به جایگزینی "Make variable" و نشانه گذاری پوسته Bourne .

این گزینه های کامپایلر پس از گزینه های کامپایلر جهانی به javac منتقل می شوند.

بولی؛ پیش فرض False است

اینکه آیا این کتابخانه باید فقط برای کامپایل استفاده شود و نه در زمان اجرا. اگر کتابخانه در حین اجرا توسط محیط زمان اجرا ارائه شود مفید است. نمونه‌هایی از این کتابخانه‌ها عبارتند از IDE API برای پلاگین‌های IDE یا tools.jar برای هر چیزی که روی یک JDK استاندارد اجرا می‌شود.

توجه داشته باشید که neverlink = 1 مانع از این نمی شود که کامپایلر مطالب را از این کتابخانه به اهداف کامپایل که به آن وابسته هستند، مطابق با مشخصات زبان جاوا (به عنوان مثال، ثابت های static final String یا انواع اولیه) داخل کند. بنابراین مورد استفاده ترجیحی زمانی است که کتابخانه زمان اجرا با کتابخانه کامپایل یکسان باشد.

اگر کتابخانه زمان اجرا با کتابخانه کامپایل متفاوت است، باید اطمینان حاصل کنید که فقط در جاهایی که JLS کامپایلرها را به صورت درون خطی ممنوع کرده است (و این باید برای تمام نسخه های آینده JLS برقرار باشد) متفاوت است.

plugins

لیست برچسب ها ؛ پیش فرض []

پلاگین های کامپایلر جاوا برای اجرا در زمان کامپایل. هر java_plugin مشخص شده در این ویژگی هر زمان که این قانون ساخته شود اجرا می شود. یک کتابخانه همچنین ممکن است افزونه‌هایی را از وابستگی‌هایی که از exported_plugins استفاده می‌کنند به ارث ببرد. منابع تولید شده توسط افزونه در jar حاصل از این قانون گنجانده می شود.
proguard_specs

لیست برچسب ها ؛ پیش فرض []

فایل هایی که به عنوان مشخصات Proguard استفاده می شوند. اینها مجموعه مشخصات مورد استفاده توسط Proguard را توصیف می کنند. در صورت مشخص شدن، بسته به این کتابخانه به هر هدف android_binary اضافه می شوند. فایل‌های موجود در اینجا فقط باید دارای قوانین بی‌توان، یعنی -dontnote، -dontwarn، assumenosideeffects و قوانینی باشند که با -keep شروع می‌شوند. گزینه‌های دیگر فقط می‌توانند در proguard_specs android_binary ظاهر شوند تا از ادغام‌های غیر توتولوژیک اطمینان حاصل شود.
resource_strip_prefix

رشته؛ پیش فرض "" است

پیشوند مسیر برای حذف از منابع جاوا.

اگر مشخص شده باشد، این پیشوند مسیر از هر فایلی در ویژگی resources حذف می شود. این یک خطا است که یک فایل منبع در این فهرست قرار ندارد. اگر مشخص نباشد (پیش‌فرض)، مسیر فایل منبع با همان منطق بسته جاوا فایل‌های منبع تعیین می‌شود. به عنوان مثال، یک فایل منبع در stuff/java/foo/bar/a.txt در foo/bar/a.txt قرار خواهد گرفت.

runtime_deps

لیست برچسب ها ؛ پیش فرض []

کتابخانه‌هایی که فقط در زمان اجرا برای باینری نهایی یا آزمایش در دسترس قرار می‌گیرند. مانند deps معمولی، اینها در مسیر کلاس اجرا ظاهر می‌شوند، اما بر خلاف آن‌ها، در مسیر کلاسی زمان کامپایل ظاهر نمی‌شوند. وابستگی های مورد نیاز فقط در زمان اجرا باید در اینجا فهرست شوند. ابزارهای تجزیه و تحلیل وابستگی باید اهدافی را که در runtime_deps و deps ظاهر می شوند نادیده بگیرند.

java_lite_proto_library

مشاهده منبع قانون
java_lite_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

java_lite_proto_library کد جاوا را از فایل های .proto تولید می کند.

deps باید به قوانین proto_library اشاره کند.

مثال:


java_library(
    name = "lib",
    runtime_deps = [":foo"],
)

java_lite_proto_library(
    name = "foo",
    deps = [":bar"],
)

proto_library(
    name = "bar",
)

استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

deps

لیست برچسب ها ؛ پیش فرض []

لیستی از قوانین proto_library برای تولید کد جاوا.

java_proto_library

مشاهده منبع قانون
java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

java_proto_library کد جاوا را از فایل های .proto تولید می کند.

deps باید به قوانین proto_library اشاره کند.

مثال:


java_library(
    name = "lib",
    runtime_deps = [":foo_java_proto"],
)

java_proto_library(
    name = "foo_java_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

deps

لیست برچسب ها ؛ پیش فرض []

لیستی از قوانین proto_library برای تولید کد جاوا.

java_test

مشاهده منبع قانون
java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)

یک قانون java_test() یک تست جاوا را کامپایل می کند. تست یک بسته بندی باینری در اطراف کد تست شما است. به جای اینکه کلاس اصلی کامپایل شود، متد اصلی اجرای آزمایشی فراخوانی می شود.

اهداف خروجی ضمنی

  • name .jar : یک بایگانی جاوا.
  • name _deploy.jar : یک آرشیو جاوا مناسب برای استقرار. (فقط در صورت درخواست صریح ساخته شده است.) برای جزئیات بیشتر به شرح خروجی name _deploy.jar از java_binary مراجعه کنید.

بخش آرگومان های java_binary() را ببینید. این قانون همچنین از تمام ویژگی های مشترک در همه قوانین تست (*_test) پشتیبانی می کند.

مثال ها



java_library(
    name = "tests",
    srcs = glob(["*.java"]),
    deps = [
        "//java/com/foo/base:testResources",
        "//java/com/foo/testing/util",
    ],
)

java_test(
    name = "AllTests",
    size = "small",
    runtime_deps = [
        ":tests",
        "//util/mysql",
    ],
)

استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

deps

لیست برچسب ها ؛ پیش فرض []

لیست کتابخانه های دیگری که باید به هدف مرتبط شوند. نظرات کلی درباره deps را در ویژگی‌های معمولی که توسط اکثر قوانین ساخت تعریف شده‌اند، ببینید.
srcs

لیست برچسب ها ؛ پیش فرض []

فهرست فایل‌های منبعی که برای ایجاد هدف پردازش می‌شوند. این ویژگی تقریباً همیشه مورد نیاز است. استثناها را در زیر ببینید.

فایل های منبع از نوع .java کامپایل شده اند. در مورد فایل‌های .java تولید شده، معمولاً توصیه می‌شود که نام قانون تولیدکننده را به جای نام خود فایل در اینجا قرار دهید. این نه تنها خوانایی را بهبود می بخشد، بلکه قانون را در برابر تغییرات آتی انعطاف پذیرتر می کند: اگر قانون تولید فایل های مختلفی در آینده ایجاد کند، فقط باید یک مکان را اصلاح کنید: outs قانون تولید. شما نباید قانون تولید را در deps فهرست کنید زیرا یک no-op است.

فایل های منبع از نوع .srcjar باز و کامپایل می شوند. (اگر نیاز به ایجاد مجموعه ای از فایل های .java با ژانر دارید، این کار مفید است.)

قوانین: اگر قانون (معمولا genrule یا filegroup ) هر یک از فایل های ذکر شده در بالا را ایجاد کند، به همان روشی که برای فایل های منبع توضیح داده شد استفاده می شود.

این آرگومان تقریباً همیشه مورد نیاز است، مگر اینکه یک ویژگی main_class کلاسی را در مسیر کلاس اجرا مشخص کند یا آرگومان runtime_deps را مشخص کنید.

data

لیست برچسب ها ؛ پیش فرض []

لیست فایل های مورد نیاز این کتابخانه در زمان اجرا. نظرات کلی در مورد data در ویژگی های معمولی که توسط اکثر قوانین ساخت تعریف شده اند، مشاهده کنید.
resources

لیست برچسب ها ؛ پیش فرض []

لیستی از فایل های داده ای که باید در یک جاوا گنجانده شوند.

منابع ممکن است فایل های منبع یا فایل های تولید شده باشند.

اگر منابع مشخص شده باشند، به همراه فایل‌های .class معمولی که توسط کامپایل تولید می‌شوند، در jar قرار می‌گیرند. محل منابع داخل فایل jar توسط ساختار پروژه تعیین می شود. Bazel ابتدا به دنبال طرح‌بندی دایرکتوری استاندارد Maven می‌گردد. اگر این مورد پیدا نشد، Bazel سپس به دنبال بالاترین دایرکتوری با نام "java" یا "javatests" می گردد (بنابراین، برای مثال، اگر منبعی در <workspace root>/x/java/y/java/z باشد، مسیر منبع y/java/z خواهد بود.این اکتشافی را نمی توان نادیده گرفت، با این حال، ویژگی resource_strip_prefix می تواند برای تعیین یک فهرست جایگزین خاص برای فایل های منبع استفاده شود.

add_exports

لیست رشته ها؛ پیش فرض []

به این کتابخانه اجازه دسترسی به module یا package داده شده را بدهید.

این با پرچم های javac و JVM --add-exports= مطابقت دارد.

add_opens

لیست رشته ها؛ پیش فرض []

به این کتابخانه اجازه دهید تا به صورت بازتابی به module یا package داده شده دسترسی داشته باشد.

این با پرچم های javac و JVM --add-opens= مطابقت دارد.

bootclasspath

برچسب ؛ پیش فرض None است

API محدود شده، استفاده نکنید!
classpath_resources

لیست برچسب ها ؛ پیش فرض []

از این گزینه استفاده نکنید مگر اینکه راه دیگری وجود نداشته باشد)

فهرستی از منابعی که باید در ریشه درخت جاوا قرار گیرند. تنها هدف این ویژگی پشتیبانی از کتابخانه های شخص ثالث است که نیاز دارند منابع آنها در مسیر کلاس دقیقاً "myconfig.xml" پیدا شوند. به دلیل خطر تداخل فضای نام، فقط روی باینری ها مجاز است و نه کتابخانه ها.

create_executable

بولی؛ پیش فرض True است

منسوخ شده، به جای آن از java_single_jar استفاده کنید.
deploy_manifest_lines

لیست رشته ها؛ پیش فرض []

فهرستی از خطوط برای افزودن به فایل META-INF/manifest.mf که برای هدف *_deploy.jar ایجاد شده است. محتویات این ویژگی مشمول جایگزینی «مغیر ایجاد کنید» نیستند .
javacopts

لیست رشته ها؛ پیش فرض []

گزینه های کامپایلر اضافی برای این باینری. مشروط به جایگزینی "Make variable" و نشانه گذاری پوسته Bourne .

این گزینه های کامپایلر پس از گزینه های کامپایلر جهانی به javac منتقل می شوند.

jvm_flags

لیست رشته ها؛ پیش فرض []

لیستی از پرچم‌ها برای جاسازی در اسکریپت wrapper ایجاد شده برای اجرای این باینری. مشروط به جایگزینی $(location) و "Make variable" و نشانه گذاری پوسته Bourne .

اسکریپت wrapper برای یک باینری جاوا شامل یک تعریف CLASSPATH (برای یافتن تمام jar های وابسته) است و مفسر جاوا مناسب را فراخوانی می کند. خط فرمان تولید شده توسط اسکریپت wrapper شامل نام کلاس اصلی و به دنبال آن یک "$@" است تا بتوانید آرگومان های دیگر را بعد از نام کلاس ارسال کنید. با این حال، آرگومان های در نظر گرفته شده برای تجزیه توسط JVM باید قبل از نام کلاس در خط فرمان مشخص شوند. محتویات jvm_flags قبل از لیست شدن نام کلاس به اسکریپت wrapper اضافه می شود.

توجه داشته باشید که این ویژگی روی خروجی های *_deploy.jar تاثیری ندارد.

launcher

برچسب ؛ پیش فرض None است

یک باینری را مشخص کنید که برای اجرای برنامه جاوا به جای برنامه bin/java معمولی همراه با JDK استفاده شود. هدف باید یک cc_binary باشد. هر cc_binary که Java Invocation API را پیاده سازی می کند، می تواند به عنوان مقداری برای این ویژگی مشخص شود.

به طور پیش فرض، Bazel از لانچر معمولی JDK (bin/java یا java.exe) استفاده می کند.

پرچم مربوط به --java_launcher Bazel فقط بر آن دسته از اهداف java_binary و java_test تأثیر می گذارد که مشخصه launcher مشخص نکرده اند.

توجه داشته باشید که وابستگی‌های بومی شما (C++، SWIG، JNI) بسته به اینکه از لانچر JDK یا راه‌انداز دیگری استفاده می‌کنید، متفاوت ساخته می‌شوند:

  • اگر از راه‌انداز معمولی JDK (پیش‌فرض) استفاده می‌کنید، وابستگی‌های بومی به‌عنوان یک کتابخانه مشترک با نام {name}_nativedeps.so ساخته می‌شوند، جایی که {name} ویژگی name این قانون java_binary است. کد استفاده نشده توسط پیوند دهنده در این پیکربندی حذف نمی شود.
  • اگر از هر راه‌انداز دیگری استفاده می‌کنید، وابستگی‌های بومی (C++) به صورت ایستا به یک باینری به نام {name}_nativedeps پیوند داده می‌شوند، جایی که {name} ویژگی name این قانون java_binary است. در این مورد، پیوند دهنده هر کدی را که فکر می‌کند استفاده نشده است را از باینری حاصل حذف می‌کند، به این معنی که هر کد C++ که فقط از طریق JNI به آن دسترسی پیدا می‌کند ممکن است به آن پیوند داده نشود مگر اینکه آن هدف cc_library alwayslink = 1 مشخص کند.

هنگام استفاده از هر راه‌اندازی غیر از راه‌انداز پیش‌فرض JDK، فرمت خروجی *_deploy.jar تغییر می‌کند. برای جزئیات بیشتر به اسناد اصلی java_binary مراجعه کنید.

main_class

رشته؛ پیش فرض "" است

نام کلاس با متد main() برای استفاده به عنوان نقطه ورودی. اگر یک قانون از این گزینه استفاده کند، نیازی به لیست srcs=[...] ندارد. بنابراین، با این ویژگی می توان یک فایل اجرایی از یک کتابخانه جاوا ایجاد کرد که از قبل حاوی یک یا چند متد main() است.

مقدار این ویژگی یک نام کلاس است، نه یک فایل منبع. کلاس باید در زمان اجرا در دسترس باشد: ممکن است توسط این قانون کامپایل شود (از srcs ) یا توسط وابستگی های مستقیم یا گذرا (از طریق runtime_deps یا deps ) ارائه شود. اگر کلاس در دسترس نباشد، باینری در زمان اجرا از کار می افتد. هیچ بررسی زمان ساخت وجود ندارد.

بولی؛ پیش فرض False است

plugins

لیست برچسب ها ؛ پیش فرض []

پلاگین های کامپایلر جاوا برای اجرا در زمان کامپایل. هر java_plugin مشخص شده در این ویژگی هر زمان که این قانون ساخته شود اجرا می شود. یک کتابخانه همچنین ممکن است افزونه‌هایی را از وابستگی‌هایی که از exported_plugins استفاده می‌کنند به ارث ببرد. منابع تولید شده توسط افزونه در jar حاصل از این قانون گنجانده می شود.
resource_strip_prefix

رشته؛ پیش فرض "" است

پیشوند مسیر برای حذف از منابع جاوا.

اگر مشخص شده باشد، این پیشوند مسیر از هر فایلی در ویژگی resources حذف می شود. این یک خطا است که یک فایل منبع در این فهرست قرار ندارد. اگر مشخص نباشد (پیش‌فرض)، مسیر فایل منبع با همان منطق بسته جاوا فایل‌های منبع تعیین می‌شود. به عنوان مثال، یک فایل منبع در stuff/java/foo/bar/a.txt در foo/bar/a.txt قرار خواهد گرفت.

runtime_deps

لیست برچسب ها ؛ پیش فرض []

کتابخانه‌هایی که فقط در زمان اجرا برای باینری نهایی یا آزمایش در دسترس قرار می‌گیرند. مانند deps معمولی، اینها در مسیر کلاس اجرا ظاهر می‌شوند، اما بر خلاف آن‌ها، در مسیر کلاسی زمان کامپایل ظاهر نمی‌شوند. وابستگی های مورد نیاز فقط در زمان اجرا باید در اینجا فهرست شوند. ابزارهای تجزیه و تحلیل وابستگی باید اهدافی را که در runtime_deps و deps ظاهر می شوند نادیده بگیرند.
stamp

عدد صحیح؛ پیش فرض 0 است

اینکه اطلاعات ساخت را در باینری رمزگذاری کنیم یا نه. مقادیر ممکن:
  • stamp = 1 : همیشه اطلاعات ساخت را در باینری مهر کنید، حتی در ساخت های --nostamp . از این تنظیم باید اجتناب شود ، زیرا به طور بالقوه حافظه پنهان از راه دور را برای باینری و هر اقدام پایین دستی که به آن وابسته است از بین می برد.
  • stamp = 0 : همیشه اطلاعات ساخت را با مقادیر ثابت جایگزین کنید. این باعث می شود که نتایج ساخت خوبی در حافظه پنهان ذخیره شود.
  • stamp = -1 : جاسازی اطلاعات ساخت توسط پرچم --[no]stamp کنترل می شود.

باینری های مهر شده بازسازی نمی شوند مگر اینکه وابستگی آنها تغییر کند.

test_class

رشته؛ پیش فرض "" است

کلاس جاوا که باید توسط اجراکننده آزمایش بارگذاری شود.

به طور پیش فرض، اگر این آرگومان تعریف نشده باشد، از حالت میراث استفاده می شود و به جای آن از آرگومان های تست استفاده می شود. پرچم --nolegacy_bazel_java_test را روی آرگومان اول تنظیم کنید.

این ویژگی نام یک کلاس جاوا را که باید توسط این تست اجرا شود را مشخص می کند. به ندرت نیاز به تنظیم این وجود دارد. اگر این آرگومان حذف شود، با استفاده از name هدف و مسیر منبع-ریشه-نسبی آن استنباط می شود. اگر تست خارج از ریشه منبع شناخته شده قرار داشته باشد، Bazel یک خطا را گزارش می دهد اگر test_class تنظیم نشده باشد.

برای JUnit3، کلاس تست یا باید یک زیر کلاس از junit.framework.TestCase باشد یا باید متد suite() static عمومی داشته باشد که یک junit.framework.Test (یا زیر کلاس Test ) را برمی گرداند. برای JUnit4، کلاس باید با org.junit.runner.RunWith حاشیه نویسی شود.

این ویژگی به چندین قانون java_test اجازه می دهد تا یک Test به اشتراک بگذارند ( TestCase ، TestSuite ، ...). معمولاً اطلاعات اضافی به آن ارسال می‌شود (مثلاً از طریق jvm_flags=['-Dkey=value'] ) به طوری که رفتار آن در هر مورد متفاوت است، مانند اجرای زیرمجموعه‌ای متفاوت از آزمایش‌ها. این ویژگی همچنین استفاده از تست های جاوا را در خارج از درخت javatests امکان پذیر می کند.

use_launcher

بولی؛ پیش فرض True است

اینکه آیا باینری باید از یک راه‌انداز سفارشی استفاده کند یا خیر.

اگر این ویژگی روی false تنظیم شود، ویژگی راه‌انداز و پرچم مربوط به --java_launcher برای این هدف نادیده گرفته می‌شود.

use_testrunner

بولی؛ پیش فرض True است

از کلاس تست runner (به طور پیش فرض com.google.testing.junit.runner.BazelTestRunner ) به عنوان نقطه ورودی اصلی برای یک برنامه جاوا استفاده کنید و کلاس تست را به عنوان مقدار ویژگی سیستم bazel.test_suite در اختیار اجراکننده آزمایش قرار دهید.
می‌توانید از این برای لغو رفتار پیش‌فرض استفاده کنید، یعنی استفاده از test runner برای قوانین java_test ، و نه استفاده از آن برای قوانین java_binary . بعید است که بخواهید این کار را انجام دهید. یکی از موارد استفاده برای قوانین AllTest است که توسط قانون دیگری احضار می شوند (مثلاً برای راه اندازی پایگاه داده قبل از اجرای آزمایش). قانون AllTest باید به‌عنوان یک java_binary اعلان شود، اما همچنان باید از اجرای آزمایشی به عنوان نقطه ورودی اصلی خود استفاده کند. نام یک کلاس اجراکننده آزمایشی را می توان با ویژگی main_class رد کرد.

java_package_configuration

مشاهده منبع قانون
java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

پیکربندی برای اعمال به مجموعه ای از بسته ها. تنظیمات را می توان به java_toolchain.javacopts s اضافه کرد.

مثال:



java_package_configuration(
    name = "my_configuration",
    packages = [":my_packages"],
    javacopts = ["-Werror"],
)

package_group(
    name = "my_packages",
    packages = [
        "//com/my/project/...",
        "-//com/my/project/testing/...",
    ],
)

java_toolchain(
    ...,
    package_configuration = [
        ":my_configuration",
    ]
)


استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

data

لیست برچسب ها ؛ پیش فرض []

لیست فایل های مورد نیاز این پیکربندی در زمان اجرا.
javacopts

لیست رشته ها؛ پیش فرض []

پرچم های کامپایلر جاوا
output_licenses

لیست رشته ها؛ پیش فرض []

packages

لیست برچسب ها ؛ پیش فرض []

مجموعه ای از package_group که پیکربندی باید روی آن اعمال شود.

java_plugin

مشاهده منبع قانون
java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

java_plugin پلاگین هایی را برای کامپایلر جاوا که توسط Bazel اجرا می شود تعریف می کند. در حال حاضر، تنها نوع پلاگین پشتیبانی شده، پردازنده های حاشیه نویسی هستند. یک قانون java_library یا java_binary می تواند افزونه ها را بسته به آنها از طریق ویژگی plugins اجرا کند. یک java_library همچنین می‌تواند به طور خودکار افزونه‌هایی را به کتابخانه‌هایی که مستقیماً به آن وابسته هستند با استفاده از exported_plugins صادر کند.

اهداف خروجی ضمنی

  • libname .jar : یک بایگانی جاوا.

آرگومان ها با java_library یکسان هستند، به جز اضافه شدن آرگومان processor_class .

استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

deps

لیست برچسب ها ؛ پیش فرض []

لیست کتابخانه هایی که باید به این کتابخانه پیوند داده شوند. نظرات کلی درباره deps را در ویژگی‌های معمولی که توسط اکثر قوانین ساخت تعریف شده‌اند، ببینید.

شیشه های ساخته شده توسط قوانین java_library که در deps فهرست شده اند در مسیر کلاسی زمان کامپایل این قانون قرار خواهند گرفت. علاوه بر این، بسته شدن موقتی deps ، runtime_deps و exports آنها در مسیر کلاس اجرا خواهد بود.

در مقابل، اهداف در ویژگی data در فایل‌های اجرا گنجانده می‌شوند اما نه در مسیر کلاس زمان کامپایل و نه در زمان اجرا قرار دارند.

srcs

لیست برچسب ها ؛ پیش فرض []

فهرست فایل‌های منبعی که برای ایجاد هدف پردازش می‌شوند. این ویژگی تقریباً همیشه مورد نیاز است. استثناها را در زیر ببینید.

فایل های منبع از نوع .java کامپایل شده اند. در مورد فایل‌های .java تولید شده، معمولاً توصیه می‌شود که نام قانون تولیدکننده را به جای نام خود فایل در اینجا قرار دهید. این نه تنها خوانایی را بهبود می بخشد، بلکه قانون را در برابر تغییرات آتی انعطاف پذیرتر می کند: اگر قانون تولید فایل های مختلفی در آینده ایجاد کند، فقط باید یک مکان را اصلاح کنید: outs قانون تولید. شما نباید قانون تولید را در deps فهرست کنید زیرا یک no-op است.

فایل های منبع از نوع .srcjar باز و کامپایل می شوند. (اگر نیاز به ایجاد مجموعه ای از فایل های .java با ژانر دارید، این کار مفید است.)

قوانین: اگر قانون (معمولا genrule یا filegroup ) هر یک از فایل های ذکر شده در بالا را ایجاد کند، به همان روشی که برای فایل های منبع توضیح داده شد استفاده می شود.

فایل های منبع از نوع .properties به عنوان منابع در نظر گرفته می شوند.

همه فایل‌های دیگر نادیده گرفته می‌شوند، تا زمانی که حداقل یک فایل از نوع فایلی که در بالا توضیح داده شد وجود داشته باشد. در غیر این صورت یک خطا مطرح می شود.

این آرگومان تقریبا همیشه مورد نیاز است، مگر اینکه آرگومان runtime_deps را مشخص کنید.

data

لیست برچسب ها ؛ پیش فرض []

لیست فایل های مورد نیاز این کتابخانه در زمان اجرا. نظرات کلی در مورد data در ویژگی های معمولی که توسط اکثر قوانین ساخت تعریف شده اند، مشاهده کنید.

هنگام ساختن java_library ، بازل این فایل ها را در جایی قرار نمی دهد. اگر فایل های data فایل های تولید شده باشند، Bazel آنها را تولید می کند. هنگام ساختن تستی که به این java_library وابسته است، Bazel فایل های data را به ناحیه runfiles کپی یا پیوند می دهد.

resources

لیست برچسب ها ؛ پیش فرض []

لیستی از فایل های داده ای که باید در یک جاوا گنجانده شوند.

منابع ممکن است فایل های منبع یا فایل های تولید شده باشند.

اگر منابع مشخص شده باشند، به همراه فایل‌های .class معمولی که توسط کامپایل تولید می‌شوند، در jar قرار می‌گیرند. محل منابع داخل فایل jar توسط ساختار پروژه تعیین می شود. Bazel ابتدا به دنبال طرح‌بندی دایرکتوری استاندارد Maven می‌گردد. اگر این مورد پیدا نشد، Bazel سپس به دنبال بالاترین دایرکتوری با نام "java" یا "javatests" می گردد (بنابراین، برای مثال، اگر منبعی در <workspace root>/x/java/y/java/z باشد، مسیر منبع y/java/z خواهد بود.این اکتشافی را نمی توان نادیده گرفت، با این حال، ویژگی resource_strip_prefix می تواند برای تعیین یک فهرست جایگزین خاص برای فایل های منبع استفاده شود.

add_exports

لیست رشته ها؛ پیش فرض []

به این کتابخانه اجازه دسترسی به module یا package داده شده را بدهید.

این با پرچم های javac و JVM --add-exports= مطابقت دارد.

add_opens

لیست رشته ها؛ پیش فرض []

به این کتابخانه اجازه دهید تا به صورت بازتابی به module یا package داده شده دسترسی داشته باشد.

این با پرچم های javac و JVM --add-opens= مطابقت دارد.

bootclasspath

برچسب ؛ پیش فرض None است

API محدود شده، استفاده نکنید!
generates_api

بولی؛ پیش فرض False است

این ویژگی، پردازشگرهای حاشیه نویسی را که کد API را تولید می کنند، علامت گذاری می کند.

اگر یک قانون از یک پردازشگر حاشیه نویسی تولید کننده API استفاده کند، قوانین دیگر بسته به آن تنها در صورتی می توانند به کد تولید شده اشاره کنند که اقدامات کامپایل آنها پس از قانون تولید برنامه ریزی شده باشد. این ویژگی به Bazel دستور می دهد تا زمانی که --java_header_compilation فعال است، محدودیت های زمان بندی را معرفی کند.

هشدار: این ویژگی بر عملکرد ساخت تأثیر می گذارد، فقط در صورت لزوم از آن استفاده کنید.

javabuilder_jvm_flags

لیست رشته ها؛ پیش فرض []

API محدود شده، استفاده نکنید!
javacopts

لیست رشته ها؛ پیش فرض []

گزینه های کامپایلر اضافی برای این کتابخانه. مشروط به جایگزینی "Make variable" و نشانه گذاری پوسته Bourne .

این گزینه های کامپایلر پس از گزینه های کامپایلر جهانی به javac منتقل می شوند.

بولی؛ پیش فرض False است

اینکه آیا این کتابخانه باید فقط برای کامپایل استفاده شود و نه در زمان اجرا. اگر کتابخانه در حین اجرا توسط محیط زمان اجرا ارائه شود مفید است. نمونه‌هایی از این کتابخانه‌ها عبارتند از IDE API برای پلاگین‌های IDE یا tools.jar برای هر چیزی که روی یک JDK استاندارد اجرا می‌شود.

توجه داشته باشید که neverlink = 1 مانع از این نمی شود که کامپایلر مطالب را از این کتابخانه به اهداف کامپایل که به آن وابسته هستند، مطابق با مشخصات زبان جاوا (به عنوان مثال، ثابت های static final String یا انواع اولیه) داخل کند. بنابراین مورد استفاده ترجیحی زمانی است که کتابخانه زمان اجرا با کتابخانه کامپایل یکسان باشد.

اگر کتابخانه زمان اجرا با کتابخانه کامپایل متفاوت است، باید اطمینان حاصل کنید که فقط در جاهایی که JLS کامپایلرها را به صورت درون خطی ممنوع کرده است (و این باید برای تمام نسخه های آینده JLS برقرار باشد) متفاوت است.

output_licenses

لیست رشته ها؛ پیش فرض []

plugins

لیست برچسب ها ؛ پیش فرض []

پلاگین های کامپایلر جاوا برای اجرا در زمان کامپایل. هر java_plugin مشخص شده در این ویژگی هر زمان که این قانون ساخته شود اجرا می شود. یک کتابخانه همچنین ممکن است افزونه‌هایی را از وابستگی‌هایی که از exported_plugins استفاده می‌کنند به ارث ببرد. منابع تولید شده توسط افزونه در jar حاصل از این قانون گنجانده می شود.
processor_class

رشته؛ پیش فرض "" است

کلاس پردازنده، نوع کاملاً واجد شرایط کلاس است که کامپایلر جاوا باید به عنوان نقطه ورود به پردازشگر حاشیه نویسی استفاده کند. اگر مشخص نشود، این قانون یک پردازشگر حاشیه نویسی را به پردازش حاشیه نویسی کامپایلر جاوا کمک نمی کند، اما مسیر کلاس زمان اجرا آن همچنان در مسیر پردازشگر حاشیه نویسی کامپایلر گنجانده می شود. (این در درجه اول برای استفاده توسط پلاگین های Error Prone در نظر گرفته شده است که از مسیر پردازشگر حاشیه نویسی با استفاده از java.util.ServiceLoader بارگیری می شوند.)
proguard_specs

لیست برچسب ها ؛ پیش فرض []

فایل هایی که به عنوان مشخصات Proguard استفاده می شوند. اینها مجموعه مشخصات مورد استفاده توسط Proguard را توصیف می کنند. در صورت مشخص شدن، بسته به این کتابخانه به هر هدف android_binary اضافه می شوند. فایل‌های موجود در اینجا فقط باید دارای قوانین بی‌توان، یعنی -dontnote، -dontwarn، assumenosideeffects و قوانینی باشند که با -keep شروع می‌شوند. گزینه‌های دیگر فقط می‌توانند در proguard_specs android_binary ظاهر شوند تا از ادغام‌های غیر توتولوژیک اطمینان حاصل شود.
resource_strip_prefix

رشته؛ پیش فرض "" است

پیشوند مسیر برای حذف از منابع جاوا.

اگر مشخص شده باشد، این پیشوند مسیر از هر فایلی در ویژگی resources حذف می شود. این یک خطا است که یک فایل منبع در این فهرست قرار ندارد. اگر مشخص نباشد (پیش‌فرض)، مسیر فایل منبع با همان منطق بسته جاوا فایل‌های منبع تعیین می‌شود. به عنوان مثال، یک فایل منبع در stuff/java/foo/bar/a.txt در foo/bar/a.txt قرار خواهد گرفت.

java_runtime

مشاهده منبع قانون
java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)

پیکربندی را برای زمان اجرا جاوا مشخص می کند.

مثال:



java_runtime(
    name = "jdk-9-ea+153",
    srcs = glob(["jdk9-ea+153/**"]),
    java_home = "jdk9-ea+153",
)


استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

srcs

لیست برچسب ها ؛ پیش فرض []

تمام فایل ها در زمان اجرا
default_cds

برچسب ؛ پیش فرض None است

آرشیو پیش فرض CDS برای هرمتیک java_runtime . هنگامی که هرمتیک برای یک هدف java_binary فعال است و اگر هدف با مشخص کردن ویژگی classlist آرشیو CDS خود را ارائه ندهد، CDS پیش‌فرض java_runtime در هرمتیک Deploy JAR بسته‌بندی می‌شود.
hermetic_srcs

لیست برچسب ها ؛ پیش فرض []

فایل ها در زمان اجرا مورد نیاز برای استقرار هرمتیک.
hermetic_static_libs

لیست برچسب ها ؛ پیش فرض []

کتابخانه هایی که به صورت ایستا با پرتاب کننده برای استقرار هرمتیک مرتبط هستند
java

برچسب ؛ پیش فرض None است

مسیر فایل اجرایی جاوا.
java_home

رشته؛ پیش فرض "" است

مسیر به ریشه زمان اجرا. مشروط به جایگزینی متغیر "Make" . اگر این مسیر مطلق باشد، این قانون یک زمان اجرا غیر هرمتیک جاوا با یک مسیر شناخته شده را نشان می دهد. در آن صورت، صفات srcs و java باید خالی باشند.
lib_ct_sym

برچسب ؛ پیش فرض None است

فایل lib/ct.sym برای کامپایل با --release مورد نیاز است. اگر مشخص نشده باشد و دقیقاً یک فایل در srcs وجود داشته باشد که مسیر آن به /lib/ct.sym ختم می شود، از آن فایل استفاده می شود.
lib_modules

برچسب ؛ پیش فرض None است

فایل lib/modules مورد نیاز برای استقرار هرمتیک.
output_licenses

لیست رشته ها؛ پیش فرض []

version

عدد صحیح؛ پیش فرض 0 است

نسخه ویژه زمان اجرا جاوا. به عنوان مثال، عدد صحیح توسط Runtime.version().feature() برگردانده شده است.

java_toolchain

مشاهده منبع قانون
java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)

پیکربندی کامپایلر جاوا را مشخص می کند. از طریق آرگومان --java_toolchain می توان از کدام زنجیره ابزار استفاده کرد. معمولاً نباید آن نوع قوانین را بنویسید مگر اینکه بخواهید کامپایلر جاوا خود را تنظیم کنید.

مثال ها

یک مثال ساده می تواند این باشد:



java_toolchain(
    name = "toolchain",
    source_version = "7",
    target_version = "7",
    bootclasspath = ["//tools/jdk:bootclasspath"],
    xlint = [ "classfile", "divzero", "empty", "options", "path" ],
    javacopts = [ "-g" ],
    javabuilder = ":JavaBuilder_deploy.jar",
)

استدلال ها

ویژگی های
name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

android_lint_data

لیست برچسب ها ؛ پیش فرض []

برچسب‌های ابزارهای موجود برای گسترش برچسب در android_lint_jvm_opts.
android_lint_jvm_opts

لیست رشته ها؛ پیش فرض []

لیست آرگومان های JVM هنگام فراخوانی Android Lint.
android_lint_opts

لیست رشته ها؛ پیش فرض []

لیست آرگومان های Android Lint.
android_lint_package_configuration

لیست برچسب ها ؛ پیش فرض []

پیکربندی Android Lint که باید برای گروه های بسته مشخص شده اعمال شود.
android_lint_runner

برچسب ؛ پیش فرض None است

برچسب برنامه Android Lint runner، در صورت وجود.
bootclasspath

لیست برچسب ها ؛ پیش فرض []

ورودی های bootclasspath هدف جاوا. با پرچم -bootclasspath javac مطابقت دارد.
compatible_javacopts

خالی؛ پیش فرض {} است

API داخلی، استفاده نکنید!
deps_checker

برچسب ؛ پیش فرض None است

برچسب ImportDepsChecker Deploy jar.
forcibly_disable_header_compilation

بولی؛ پیش فرض False است

--java_header_compilation را لغو می کند تا کامپایل هدر را در پلتفرم هایی که از آن پشتیبانی نمی کنند، مانند JDK 7 Bazel غیرفعال کند.
genclass

برچسب ؛ پیش فرض None است

برچسب GenClass Deploy jar.
header_compiler

برچسب ؛ پیش فرض None است

برچسب کامپایلر هدر. اگر --java_header_compilation فعال باشد، لازم است.
header_compiler_builtin_processors

لیست رشته ها؛ پیش فرض []

API داخلی، استفاده نکنید!
header_compiler_direct

برچسب ؛ پیش فرض None است

برچسب اختیاری کامپایلر سرصفحه برای استفاده برای اقدامات مسیر کلاسی مستقیم که شامل هیچ پردازشگر حاشیه نویسی تولیدکننده API نیست.

این ابزار از پردازش حاشیه نویسی پشتیبانی نمی کند.

ijar

برچسب ؛ پیش فرض None است

برچسب فایل اجرایی ijar.
jacocorunner

برچسب ؛ پیش فرض None است

برچسب JacocoCoverageRunner Deploy jar.
java_runtime

برچسب ؛ پیش فرض None است

java_runtime برای استفاده با این زنجیره ابزار. در پیکربندی اجرا به طور پیش فرض java_runtime است.
javabuilder

برچسب ؛ پیش فرض None است

برچسب جاوا بیلدر استقرار jar.
javabuilder_data

لیست برچسب ها ؛ پیش فرض []

برچسب های داده های موجود برای گسترش برچسب در javabuilder_jvm_opts.
javabuilder_jvm_opts

لیست رشته ها؛ پیش فرض []

لیست آرگومان های JVM هنگام فراخوانی JavaBuilder.
javac_supports_multiplex_workers

بولی؛ پیش فرض True است

درست است اگر جاوا بیلدر از اجرای به عنوان یک کارگر دائمی چندگانه پشتیبانی می کند، اگر این کار را نمی کند نادرست است.
javac_supports_worker_cancellation

بولی؛ پیش فرض True است

اگر جاوا بیلدر از لغو کارگران دائمی پشتیبانی کند درست است، اگر اینطور نباشد نادرست است.
javac_supports_worker_multiplex_sandboxing

بولی؛ پیش فرض False است

درست است اگر JavaBuilder از اجرای به عنوان یک کارگر دائمی چندگانه با sandboxing پشتیبانی کند، اگر اینطور نباشد نادرست است.
javac_supports_workers

بولی؛ پیش فرض True است

درست است اگر جاوا بیلدر از اجرای به‌عنوان کارگر دائمی پشتیبانی کند، اگر پشتیبانی نمی‌کند نادرست است.
javacopts

لیست رشته ها؛ پیش فرض []

لیست آرگومان های اضافی برای کامپایلر جاوا. لطفاً برای لیست گسترده پرچم‌های کامپایلر جاوا به مستندات کامپایلر جاوا مراجعه کنید.
jspecify_implicit_deps

برچسب ؛ پیش فرض None است

آزمایشی، استفاده نکنید!
jspecify_javacopts

لیست رشته ها؛ پیش فرض []

آزمایشی، استفاده نکنید!
jspecify_packages

لیست برچسب ها ؛ پیش فرض []

آزمایشی، استفاده نکنید!
jspecify_processor

برچسب ؛ پیش فرض None است

آزمایشی، استفاده نکنید!
jspecify_processor_class

رشته؛ پیش فرض "" است

آزمایشی، استفاده نکنید!
jspecify_stubs

لیست برچسب ها ؛ پیش فرض []

آزمایشی، استفاده نکنید!
jvm_opts

لیست رشته ها؛ پیش فرض []

لیست آرگومان های JVM هنگام فراخوانی کامپایلر جاوا. لطفاً برای لیست گسترده پرچم‌های احتمالی این گزینه به مستندات ماشین مجازی جاوا مراجعه کنید.
misc

لیست رشته ها؛ پیش فرض []

منسوخ شده: به جای آن از جاواکوپت استفاده کنید
oneversion

برچسب ؛ پیش فرض None است

برچسب باینری اجرای یک نسخه.
oneversion_allowlist_for_tests

برچسب ؛ پیش فرض None است

برچسب لیست مجاز یک نسخه برای تست ها.
oneversion_whitelist

برچسب ؛ پیش فرض None است

برچسب لیست مجاز یک نسخه.
package_configuration

لیست برچسب ها ؛ پیش فرض []

پیکربندی که باید برای گروه های بسته مشخص شده اعمال شود.
proguard_allowlister

برچسب ؛ پیش فرض "@bazel_tools//tools/jdk:proguard_whitelister" است

برچسب مجوز Proguard.
reduced_classpath_incompatible_processors

لیست رشته ها؛ پیش فرض []

API داخلی، استفاده نکنید!
singlejar

برچسب ؛ پیش فرض None است

برچسب SingleJar Deploy jar.
source_version

رشته؛ پیش فرض "" است

نسخه منبع جاوا (به عنوان مثال، '6' یا '7'). مشخص می کند که کدام مجموعه از ساختارهای کد در کد منبع جاوا مجاز است.
target_version

رشته؛ پیش فرض "" است

نسخه هدف جاوا (به عنوان مثال، '6' یا '7'). مشخص می کند که کلاس برای کدام زمان اجرا جاوا باید ساخته شود.
timezone_data

برچسب ؛ پیش فرض None است

برچسب ظرف منبع حاوی داده‌های منطقه زمانی. اگر تنظیم شود، داده‌های منطقه زمانی به‌عنوان یک وابستگی ضمنی زمان اجرا به همه قوانین java_binary اضافه می‌شوند.
tools

لیست برچسب ها ؛ پیش فرض []

برچسب‌های ابزارهای موجود برای گسترش برچسب در jvm_opts.
turbine_data

لیست برچسب ها ؛ پیش فرض []

برچسب های داده های موجود برای گسترش برچسب در turbine_jvm_opts.
turbine_jvm_opts

لیست رشته ها؛ پیش فرض []

لیست آرگومان های JVM هنگام فراخوانی توربین.
xlint

لیست رشته ها؛ پیش فرض []

لیست هشدارهایی که باید از لیست پیش فرض اضافه یا حذف شوند. قبل از آن با یک خط تیره آن را حذف می کند. لطفاً برای اطلاعات بیشتر به مستندات Javac در گزینه های -Xlint مراجعه کنید.