chore: migrate java-logging into monorepo

[chingor13]

No description provided.

[snippet-bot]

Here is the summary of changes.

You are about to add 11 region tags.

• java-logging/samples/install-without-bom/pom.xml:27, tag logging_install_without_bom
• java-logging/samples/snippets/pom.xml:26, tag logging_install_with_bom
• java-logging/samples/snippets/src/main/java/com/example/logging/GetSinkMetadata.java:19, tag logging_get_sink
• java-logging/samples/snippets/src/main/java/com/example/logging/ListLogEntries.java:19, tag logging_list_log_entries
• java-logging/samples/snippets/src/main/java/com/example/logging/ListLogs.java:19, tag logging_list_logs
• java-logging/samples/snippets/src/main/java/com/example/logging/LogEntryWriteHttpRequest.java:19, tag logging_write_log_entry_advanced
• java-logging/samples/snippets/src/main/java/com/example/logging/QuickstartSample.java:19, tag logging_quickstart
• java-logging/samples/snippets/src/main/java/com/example/logging/TailLogEntries.java:19, tag logging_tail_log_entries
• java-logging/samples/snippets/src/main/java/com/example/logging/WriteLogEntry.java:19, tag logging_write_log_entry
• java-logging/samples/snippets/src/main/java/com/example/logging/jul/Quickstart.java:19, tag logging_jul_quickstart
• java-logging/samples/snippets/src/main/resources/logging.properties:18, tag logging_jul_config

---

This comment is generated by snippet-bot.
If you find problems with this result, please file an issue at:
https://github.com/googleapis/repo-automation-bots/issues.
To update this comment, add snippet-bot:force-run label or use the checkbox below:

• Refresh this comment

[jinseopkim0]

CIs appear to be failing, saying "Pull request exceeds maximum commit limit". Is there a good way to resolve this? Or is the plan to ignore this?

[chingor13]

CIs appear to be failing, saying "Pull request exceeds maximum commit limit". Is there a good way to resolve this? Or is the plan to ignore this?

For the CLA, we plan to manually override as these commits all came from a different repository where the CLA has been enforced. The maximum commit limit is unavoidable and a limitation of the check (managed by OSPO).

For the header-check, we plan to ignore, because we do want to preserve the original creation date of those files.

[blakeli0]

I see that integration tests and GraalVM tests are run as part of Kokoro - Test: Integration and Kokoro - Test: GraalVM Native Image. Can they be a separate CI that is only triggered by changes to the java-logging folder?

[chingor13]

I see that integration tests and GraalVM tests are run as part of Kokoro - Test: Integration and Kokoro - Test: GraalVM Native Image. Can they be a separate CI that is only triggered by changes to the java-logging folder?

Both integration and graalvm tests already are conditional based on which folders are touched and are intentionally running IT tests.

We could separate them if we really want to, but it is additional work across internal configs and in-repo. We could also do this separately after monitoring if these tests are adversely affecting other packages (perhaps the next codegen that touches logging + other modules in the same PR).

[blakeli0]

Both integration and graalvm tests already are conditional based on which folders are touched and are intentionally running IT tests.

I might be missing something, do you mind sharing where this is configured?

[chingor13]

Both integration and graalvm tests already are conditional based on which folders are touched and are intentionally running IT tests.

I might be missing something, do you mind sharing where this is configured?

generate_graalvm_modules_list (defined in common.sh) builds a list of modules based on which ones have been modified in the PR.

google-cloud-java/.kokoro/build.sh

Line 100 in 21bfc98

generate_graalvm_modules_list

google-cloud-java/.kokoro/common.sh

Lines 265 to 298 in 21bfc98

	function generate_graalvm_modules_list() {
	modules_assigned_list=()
	generate_modified_modules_list
	if [[ "${TEST_ALL_MODULES}" == "true" ]]; then
	# Assign the modules to modules_assigned_list (based on num jobs)
	num=0
	for module in "${modified_module_list[@]}"; do
	# Add 1 as JOB_NUMBER is 1-indexed instead of 0-indexed
	mod_num=$((num % NUM_JOBS + 1))
	# Spaces are intentionally added -- Query is regex and array elements are space separated
	# It tries to match the *exact* `module` text
	if [[ ! " ${excluded_modules[*]} " =~ " ${module} " ]] && [[ $mod_num -eq $JOB_NUMBER ]]; then
	modules_assigned_list+=("${module}")
	fi
	num=$((num + 1))
	done
	elif [[ ${#modified_module_list[@]} -gt 0 ]]; then
	# MAVEN_MODULES ENV_VAR is expecting comma delimited string (similar to mvn -pl)
	# This will get all the modules and put all the elements into an array
	maven_modules_list=($(echo "${MAVEN_MODULES}" | tr ',' ' '))
	for maven_module in "${maven_modules_list[@]}"; do
	# Check that the modified_module_list contains a module from MAVEN_MODULES
	# Spaces are intentionally added -- Query is regex and array elements are space separated
	# It tries to match the *exact* `maven_module` text
	if [[ " ${modified_module_list[*]} " =~ " ${maven_module} " ]]; then
	modules_assigned_list+=("${module}")
	fi
	done
	fi
	module_list=$(
	IFS=,
	echo "${modules_assigned_list[*]}"
	)
	}

[lqiu96]

seems like there may be some added changes in this file. Are some of these intended? Looks like some added \ and other characters.

[lqiu96]

qq, is this config correct? IIUC, this preserves files, but logging should have a lot of handwritten classes that needs to be preserved (I could be misunderstanding how these configs work). https://github.com/googleapis/java-logging/tree/main/google-cloud-logging/src/main/java/com/google/cloud/logging