Eclipse Aether not resolving `LATEST` correctly - java

Eclipse Aether doesn't seem to return the correct release when I try to resolve a LATEST version:
val artifact = DefaultArtifact("org.testng:testng:LATEST")
val versionResult = system.resolveVrsion(session, VersionRequest(artifact, repositories, null))
println(versionResult)
produces:
6.9.8 # maven (https://jcenter.bintray.com/, default, releases+snapshots)
However, 6.9.10 is the latest, and JCenter is reporting it correctly, both in the directory and also in the maven-metadata.xml:
<metadata>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.9.10</version>
<versioning>
<latest>6.9.10</latest>
<release>6.9.10</release>
Why am I getting 6.9.8 instead of 6.9.10?

There are two things which might the cause of your problem. First you assume that the magic word LATEST is supported by Aether and if i remember correctly (and looking into the code of Aether it is not supported). This means you should use a version range to get the latest.
Furthermore if you have a version range you need to call resolveVersionRange(...) instead of resolveVersion(..).
String versionRange = "[0,)";
Artifact artifact =
new DefaultArtifact( "org.testng:testng:jar:" + versionRange );
VersionRangeRequest rangeRequest = new VersionRangeRequest();
rangeRequest.setArtifact( artifact );
rangeRequest.setRepositories( remoteRepos );
VersionRangeResult rangeResult = repository.resolveVersionRange( repositorySystemSession, rangeRequest );
List<Version> versions = rangeResult.getVersions();
The above is a slightly modified version taken from a plugin i wrote. There is also a ctor of DefaultArtifact which contains only the appropriate parameters which might be a better alternative to use instead of concatenating the strings.

Related

Solve override compilation error in protobuf java generated files

I have the following setup:
I have the following dependency in my POM:
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>3.14.0</version>
</dependency>
I have a very simple proto file:
syntax = "proto3";
package com.ziath.genericdecoderserver;
option java_outer_classname = "DecodePackage";
message DecodeData {
string template = 1;
bytes image = 2;
int32 startColumn = 3;
int32 endColumn = 4;
}
I'm generating the proto file using the version 3.14.0, binary for win64:
PS C:\Users\neilb\Documents\GitHub\GenericDecoderServer\src\main\protobuf\bin> .\protoc.exe --version
libprotoc 3.14.0
This matches the maven dependency I'm pulling in. However the file generated has error with the override annotation:
#java.lang.Override
public com.ziath.genericdecoderserver.DecodePackage.DecodeData buildPartial() {
com.ziath.genericdecoderserver.DecodePackage.DecodeData result = new
com.ziath.genericdecoderserver.DecodePackage.DecodeData(this);
result.template_ = template_;
result.image_ = image_;
result.startColumn_ = startColumn_;
result.endColumn_ = endColumn_;
onBuilt();
return result;
}
The reported error is:
The method buildPartial() of type DecodePackage.DecodeData.Builder must override a superclass method
So this method is in the Builder class which is defined as:
public static final class Builder extends com.google.protobuf.GeneratedMessageV3.Builder<Builder> implements
// ##protoc_insertion_point(builder_implements:com.ziath.genericdecoderserver.DecodeData)
com.ziath.genericdecoderserver.DecodePackage.DecodeDataOrBuilder {
Eclipse is correct the method buildPartial is not in either of the interfaces protobuf is referencing so it looks like a version mismatch but the versions are the same. There are scores of errors in this generated code along the same lines. Does anybody know what the problem is or even seen this before because my searches show nothing from this?
Thanks.
Cheers,
Neil
Solved it! The project was created using Spring Initilaser and for some reason that made the java version to be 1.5 in eclipse. 1.5 does not allow override for interface methods.

Create a branch in an empty repository using the Java API for Bitbucket

I have created an empty repository using the java library for bitbucket. But when trying to create a branch, the error "my-repo" is empty - branches cannot be created in empty repositories. Tell me how to add data to the repository via the API. I have used com.cdancy library.
Code:
CreateRepository crepo = CreateRepository.create("my-repo", true);
Repository repo = client.api().repositoryApi().create("ESB", crepo);
CreateBranch master = CreateBranch.create("branchname", "hashcommit", null);
Branch mast = client.api().branchApi().create("Proj", "my-repo", branch);
Maven dependency:
<dependency>
<groupId>com.cdancy</groupId>
<artifactId>bitbucket-rest</artifactId>
<version>2.5.3</version>
</dependency>

switsh and helpSwitch methods missing from org.refcodes.console.ConsoleSugar when upgrading to 2.x

I was using org.refcode.refcodes-console version 1.1.9. When upgrading to 2.0.4, it seems various methods no longer exist.
My scala code:
val theHelp = helpSwitch("Shows this help")
I get this error when compiling: not found: value helpSwitch
Same error when using switsh and StringOptionImpl.
How should I replace them when migrating from 1.x to 2.x for this maven artifact?
All 'switch' (aka switsh) methods in ConsoleSugar have been renamed to 'flag' in major version 2. So 'switsh' has been renamed to 'flag' and 'helpSwitch' has been renamed to 'helpFlag'.
For StringOptionImpl, use 'SpringOption' instead.
So in the example provided, it should now be:
val theHelp = helpFlag("Shows this help")
Also, for the switsh method you would need to add a 'aAlias' parameter as the third parameter. For example:
val block = switsh("-w", "--wait", "Wait at the end of the Program")
would need to be something like become
val block = flag("-w", "--wait", "wait", "Wait at the end of the Program")

How to use different bootclasspaths in Bazel workspace?

I'm currently trying to build a Bazel 0.11.1 workspace with projects that use different Java language levels. The actual application uses Java 7, but for some code that won't ship, I want to settle with a more recent Java version to be able to use the new language features.
I can solve this to some extent by using --javacopt in .bazelrc, setting -source 1.7 -target 1.7 and override the defaults on a project level with the javacopts attribute, but this is not enough to ensure proper Java 7 compatibility when compiling with a more recent Java version. For this I really need to compile Java 7 projects against a Java 7 classpath as well.
The only way to use a custom bootclasspath seems to be via java_toolchain. It works. But I could not found a way to use different bootclasspaths for different projects, because the toolchain affects all projects and unlike with javacopts cannot be overridden at the project level.
Is this a usecase that is simply not (yet?) possible with Bazel? Or is there some trickery to make it work?
It turns out there is a way: write a custom rule that performs compilation.
The java_common module provides an interface to the compiler.
library.bzl
def _impl(ctx):
deps = []
for dep in ctx.attr.deps:
if java_common.provider in dep:
deps.append(dep[java_common.provider])
output_jar = ctx.new_file("lib{0}.jar".format(ctx.label.name))
runtime = java_common.JavaRuntimeInfo
compilation_provider = java_common.compile(
ctx,
source_jars = ctx.files.srcs_jars,
source_files = ctx.files.srcs,
output = output_jar,
javac_opts = ctx.attr.javac_opts,
deps = deps,
strict_deps = ctx.attr.strict_deps,
java_toolchain = ctx.attr.toolchain,
host_javabase = ctx.attr._host_javabase,
resources = ctx.files.resources,
neverlink = ctx.attr.neverlink,
)
return struct(
files = depset([output_jar]),
providers = [compilation_provider],
)
library = rule(
implementation = _impl,
attrs = {
"srcs_jars": attr.label_list(allow_files=True),
"srcs": attr.label_list(allow_files=True),
"javac_opts": attr.string_list(default=[]),
"deps": attr.label_list(),
"strict_deps": attr.string(default="ERROR"),
"toolchain": attr.label(default=Label("#bazel_tools//tools/jdk:toolchain")),
"sourcepath": attr.label_list(),
"resources": attr.label_list(),
"neverlink": attr.bool(default=False),
"_host_javabase": attr.label(default=Label("#local_jdk//:jdk")),
},
fragments = ["java"],
)
This rule I can now use to set a different toolchain for compilation.
BUILD
load('//build/jdk:library.bzl', 'library')
library(
name = "test",
srcs = glob(["src/main/java/**/*.java"]),
# data = glob(["src/main/resources/**"]),
toolchain = "//build/jdk:jdk8",
deps = ["..."],
)
Unfortunately I'm not 100% there yet. java_common.compile does not seem to have an equivalent for the data attribute of java_library, but for the most part the toolchain problem is solved.

buildr: package dependencies into a single jar

I have a java project that is built with buildr and that has some external dependencies:
repositories.remote << "http://www.ibiblio.org/maven2"
repositories.remote << "http://packages.example/"
define "myproject" do
compile.options.target = '1.5'
project.version = "1.0.0"
compile.with 'dependency:dependency-xy:jar:1.2.3'
compile.with 'dependency2:dependency2:jar:4.5.6'
package(:jar)
end
I want this to build a single standalone jar file that includes all these dependencies.
How do I do that?
(there's a logical followup question: How can I strip all the unused code from the included dependencies and only package the classes I actually use?)
This is what I'm doing right now. This uses autojar to pull only the necessary dependencies:
def add_dependencies(pkg)
tempfile = pkg.to_s.sub(/.jar$/, "-without-dependencies.jar")
mv pkg.to_s, tempfile
dependencies = compile.dependencies.map { |d| "-c #{d}"}.join(" ")
sh "java -jar tools/autojar.jar -baev -o #{pkg} #{dependencies} #{tempfile}"
end
and later:
package(:jar)
package(:jar).enhance { |pkg| pkg.enhance { |pkg| add_dependencies(pkg) }}
(caveat: I know little about buildr, this could be totally the wrong approach. It works for me, though)
I'm also learning Buildr and currently I'm packing Scala runtime with my application this way:
package(:jar).with(:manifest => _('src/MANIFEST.MF')).exclude('.scala-deps')
.merge('/var/local/scala/lib/scala-library.jar')
No idea if this is inferior to autojar (comments are welcome), but seems to work with a simple example. Takes 4.5 minutes to package that scala-library.jar thought.
I'm going to use Cascading for my example:
cascading_dev_jars = Dir[_("#{ENV["CASCADING_HOME"]}/build/cascading-{core,xml}-*.jar")]
#...
package(:jar).include cascading_dev_jars, :path => "lib"
Here is how I create an Uberjar with Buildr, this customization of what is put into the Jar and how the Manifest is created:
assembly_dir = 'target/assembly'
main_class = 'com.something.something.Blah'
artifacts = compile.dependencies
artifacts.each do |artifact|
Unzip.new( _(assembly_dir) => artifact ).extract
end
# remove dirs from assembly that should not be in uberjar
FileUtils.rm_rf( "#{_(assembly_dir)}/example/package" )
FileUtils.rm_rf( "#{_(assembly_dir)}/example/dir" )
# create manifest file
File.open( _("#{assembly_dir}/META-INF/MANIFEST.MF"), 'w') do |f|
f.write("Implementation-Title: Uberjar Example\n")
f.write("Implementation-Version: #{project_version}\n")
f.write("Main-Class: #{main_class}\n")
f.write("Created-By: Buildr\n")
end
present_dir = Dir.pwd
Dir.chdir _(assembly_dir)
puts "Creating #{_("target/#{project.name}-#{project.version}.jar")}"
`jar -cfm #{_("target/#{project.name}-#{project.version}.jar")} #{_(assembly_dir)}/META-INF/MANIFEST.MF .`
Dir.chdir present_dir
There is also a version that supports Spring, by concatenating all the spring.schemas

Categories

Resources