search

owlcollab / owltools

OWLTools
BSD 3-Clause "New" or "Revised" License
107 stars 33 forks source link

Build of 2020-04-06 release source fail #307

Closed jelmd closed 3 years ago

jelmd commented 3 years ago

Trying to compile using the released source code https://github.com/owlcollab/owltools/archive/2020-04-06.tar.gz (see https://github.com/owlcollab/owltools/releases ). This fails with the following errors:

...
[ERROR] Failed to execute goal pl.project13.maven:git-commit-id-plugin:2.1.13:revision (git-commit-id) on project OWLTools-Runner: .git directory could not be found! Please specify a valid [dotGitDirectory] in your pom.xml -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :OWLTools-Runner
...
# same error again (removed)
...
[ERROR] Failed to execute goal on project OWLTools-Core: Could not resolve dependencies for project org.bbop:OWLTools-Core:jar:0.3.0-SNAPSHOT: Failed to collect dependencies at org.bbop:oboformat-tools:jar:0.7.3: Failed to read artifact descriptor for org.bbop:oboformat-tools:jar:0.7.3: Could not transfer artifact org.bbop:oboformat-tools:pom:0.7.3 from/to BerkeleyBOP (http://code.berkeleybop.org/maven/repository/): Connect to code.berkeleybop.org:80 [code.berkeleybop.org/52.216.138.218] failed: Connection refused (Connection refused) -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :OWLTools-Core

So it seems, that the build has a hard dependency on a git commit? Very bad idea - releases are usually exported repos, i.e. all git info removed for very good reasons.

The last error seems to be related to code.berkeleybop.org. I guess, mvn et. al. caches the IP of this site, and because this site changes its IP address like a mad man every 5s, the build has to fail, if it takes longer than 5s. Is there a less crazy, i.e. isn't there a reliable maven repo/mirror which can be used instead?

balhoff commented 3 years ago

So it seems, that the build has a hard dependency on a git commit? Very bad idea - releases are usually exported repos, i.e. all git info removed for very good reasons.

This allows the tool to report which git commit it was built from. It's often very handy. If you would prefer this to be configurable, PRs are welcome (although this is not really an active project).

Is there a less crazy, i.e. isn't there a reliable maven repo/mirror which can be used instead?

I haven't run into this problem before. It works fine for builds on travis. This repo is hosted on Amazon S3. It's mostly there for some jars that are holdovers from pre-Maven days and not maintained anymore. One workaround I guess would be to download those separately and put them in your local Maven repo. Just a workaround though.

If you're starting new development based on owltools, you might be interested in ROBOT instead, which has a lot of overlapping functionality and is more actively developed.

jelmd commented 3 years ago

Wrt. git: yes I know. But if one uses a local repo, makes changes .... So IMHO it is better to tag a release and use the tag file instead (or at least do not fail, if it is an exported repo). BTW: Wrt. version I think it would be also a good info to show the used/supported OWL API version.

Wrt. S3: found out, that the proxy settings were not used. So the firewall blocked it, because it doesn't allow egress access to any unknown site. S3 with its non-static IPs is a real pain and causes people to configure their FW [even on their servers] to allow access to any external site ... =8-(

Thanx for the ROBOT hint - I'll check it out :) .