jalview

build.gradle

Clone Tools

Stats

Commits this week: 0
Total Committers: 7
Last Commit: 25 Nov
Commits this week: 0

Lines of code count not available

Commit Activity

Commits By Day In Week
52 week commits volume
Commits By Day In Week
Commits by day
Commits By Day In Week
Commits by hour
Commits By Hour In Day
Commit calendar
 

Most active committers (90 days)

loading
loading
  • last updated a few seconds ago
All Commits Reviews
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Wednesday 15 Sep
7:52 am

Jim Procter

Wednesday 10 Feb
12:12 am

Ben Soares

JAL-3521 Changed wording of INSTALLATION in source tarball build_properties

Options
    • -1
    • +1
    /build.gradle
Monday 08 Feb
7:00 pm

Ben Soares

JAL-3521 Adding a build_properties into sourceDist tarball, with INSTALLATION=SourceDist git-commit...

Options
    • -0
    • +10
    /build.gradle
Saturday 06 Feb
1:51 am

Ben Soares

JAL-3521 Moved the debian build.gradle to utils/debian/build.gradle.debian

Options
    • -11
    • +1361
    /build.gradle
  2. … 1 more file in changeset.
Friday 04 Dec 2020
5:35 pm

Ben Soares

Agreed. I seem to remember (this was a while ago now) that I found isAMacAndNotJS() and thought it might be an important distinction. Sounds like it's just redundant? Can tidy this another time then.

Agreed. I seem to remember (this was a while ago now) that I found isAMacAndNotJS() and thought it might be an important distinction. Sounds like it's just redundant? Can tidy this another time then.

5:31 pm

Ben Soares

Agree this is just touching on a much bigger task. However... The reason I /needed/ to do this rather than just /wanted/ to do this is that several of the classes I've been working on (e.g. jalview...

Agree this is just touching on a much bigger task.
However...
The reason I /needed/ to do this rather than just /wanted/ to do this is that several of the classes I've been working on (e.g. jalview.bin.Launcher, jalview.bin.HiDPISetting, jalview.bin.MemorySetting) run very early on (especially jalview.bin.Launcher!). This means Cache.log has perhaps not yet been initialised, so a Cache.log.debug doesn't log (unless you count reams of NullPointerExceptions as logging!).

In the case of HiDPISetting and MemorySetting that also get used in Getdown, where there is no jalview.bin.Cache, they currently have to use System.out and System.err [or maybe I could stub jalview.bin.Cache too]. I'd prefer them to use Cache.log when they can so this is an attempt at starting to decouple jalview.bin.Cache from other jalview things so it can be used standalone within Getdown. The main reason for wanting to do that is to have shared code to read the preferences between Jalview and Getdown.

Wednesday 02 Dec 2020
5:56 pm

Jim Procter

I think there are lots of things that could be tidied up (particularly the overloading and additional logging functions via Cache which don't really reduce code at point of use, but are certainly u...

I think there are lots of things that could be tidied up (particularly the overloading and additional logging functions via Cache which don't really reduce code at point of use, but are certainly useful in spirit), but now is most definitely not the time to optimise and beautify code.

5:53 pm

Jim Procter

Ben Soares as far as I can see the only thing missing after this branch is merged to develop is this logic. I just did a quick test and it appears 'Platform.isAMac()' returns false under JalviewJS,...

Ben Soares as far as I can see the only thing missing after this branch is merged to develop is this logic. I just did a quick test and it appears 'Platform.isAMac()' returns false under JalviewJS, so probably not a dealbreaker. Do you agree ?

5:20 pm

Jim Procter

JAL-3608 cherry pick of 92cb745e7
JAL-3608 cherry pick of 92cb745e7
Thursday 19 Nov 2020
5:58 pm

Ben Soares

JAL-3521 removed unnecessary parts of the ext project in build.gradle

Options
    • -327
    • +6
    /build.gradle
4:17 pm

Ben Soares

JAL-3521 Minimal plugins and tasks needed to run tests and build jalview.jar

Options
    • -1034
    • +5
    /build.gradle
Thursday 24 Sep 2020
6:16 pm

Ben Soares

JAL-3577 Quick fix adding quotation marks for findProperty("JALVIEW_VERSION")==null...

Options
    • -1
    • +1
    /build.gradle
Tuesday 15 Sep 2020
12:58 pm

Jim Procter

Thursday 03 Sep 2020
12:20 pm

Jim Procter

Merge branch 'improvement/JAL-3280_Migrate_the_VersionChecker_service_to_build_properties' into releases/Release_2_11_1_Branch

Options
    • -1
    • +5
    /build.gradle
Tuesday 01 Sep 2020
5:45 pm

Ben Soares

JAL-3280 fixes after CR-JAL-241. Now only checking release build_properties.

Options
    • -2
    • +4
    /build.gradle
  2. … 1 more file in changeset.
4:37 pm

Ben Soares

Decision made in the issue to just check release build_properties.

Decision made in the issue to just check release build_properties.

12:53 pm

Ben Soares

I'll add a Test. Perhaps this stems from me misunderstanding a comment in the issue: "We should provide a way to find out what the latest version available from a channel is. I suggest we have a b...

I'll add a Test.

Perhaps this stems from me misunderstanding a comment in the issue: "We should provide a way to find out what the latest version available from a channel is. I suggest we have a build details URL for each channel".
For non-Release/Test channel versions the "remote" build_properties will be a local file://.../getdown/website/11/alt/build_properties (which works if you're on the machine you built it on).
For Release/Test channel versions, the remote build_properties will be the most recent one available in https://www.jalview.org/getdown/release/11/release/build_properties (or test/1.8/alt etc). It is true that if this is the case then getdown SHOULD have already updated the jalview.jar. This is fine, and you would expect nothing to be reported anyway.
If you're using the shadowJar or an otherwise non-updatable version of Jalview or for whatever reason getdown has not auto-updated then you will get the message saying what the most recent version (in your channel) is. [This is perhaps the main part of the target audience for this message now???]
If we just want to check the current release version, this simplifies things quite a lot and I don't mind making that change at all (it means we don't have to pass any properties in to jalview to suggest a different appbase etc).

12:41 pm

Ben Soares

I can only think a bad copy and paste but why I did that I don't know (possibly I leant on "p" by accident after a "yy"? I need to be careful about my copy and pastes.) I'll remove.

I can only think a bad copy and paste but why I did that I don't know (possibly I leant on "p" by accident after a "yy"? I need to be careful about my copy and pastes.) I'll remove.

12:39 pm

Ben Soares

Yes this should be removed. Cache.log.debug doesn't work (NullPointer) because (I think) log hasn't been initialised yet. I thought this System.out had been there before, but it wasn't so I'll remo...

Yes this should be removed. Cache.log.debug doesn't work (NullPointer) because (I think) log hasn't been initialised yet. I thought this System.out had been there before, but it wasn't so I'll remove it!

11:42 am

Jim Procter

Best to have tests covering these methods. The original idea of the versionChecker is to compare the latest version in the Jalview release channel to what the user is running. Maybe I'm missing s...

Best to have tests covering these methods.

The original idea of the versionChecker is to compare the latest version in the Jalview release channel to what the user is running.

Maybe I'm missing something, but If the versionChecker defaults to the getdown channel that it was launched from, it isn't going to be doing what it was originally intended ?

11:39 am

Jim Procter

Why reading twice ?

Why reading twice ?

11:39 am

Jim Procter

this should be a debug statement ? Seeing 'LATEST_VERSION=' on stdout seems a bit strange, also.

this should be a debug statement ? Seeing 'LATEST_VERSION=' on stdout seems a bit strange, also.

11:35 am

Jim Procter

JAL-3280 Pass appbase and appdir from getdown to jalvew. Check appbase (defaults to release appbase)...
JAL-3280 Pass appbase and appdir from getdown to jalvew. Check appbase (defaults to release appbase)...
Monday 31 Aug 2020
6:38 pm

Ben Soares

JAL-3280 Pass appbase and appdir from getdown to jalvew. Check appbase (defaults to release appbase) for build_properties VERSION insteadl of jnlp file.

Options
    • -1
    • +3
    /build.gradle
  2. … 1 more file in changeset.
Wednesday 19 Aug 2020
12:38 am

Ben Soares

JAL-3718 Added digestonly key to getdown.txt to copy file to alt or release when building, and to be included in the getdown digest. This key is completely ignored by the getdown-launcher. Looks in j8/j11digestonly.

Options
    • -0
    • +12
    /build.gradle
  2. … 19 more files in changeset.
Thursday 13 Aug 2020
5:51 pm

Jim Procter

JAL-3675 brought forward patch to build.gradle for changed main class variable in build.properties

Options
    • -1
    • +1
    /build.gradle
Thursday 09 Jul 2020
1:31 pm

Ben Soares

Wednesday 08 Jul 2020
1:07 am

Ben Soares

Resolutions to this review are in task/JAL-3608_property_set_laf_and_tests_from_Release_2_11_1_Branch and will be migrated to task/JAL-3608_property_set_laf_and_tests soon...

Resolutions to this review are in

task/JAL-3608_property_set_laf_and_tests_from_Release_2_11_1_Branch

and will be migrated to task/JAL-3608_property_set_laf_and_tests soon...

1:01 am

Ben Soares

Yes that's much nicer

Yes that's much nicer

1:01 am

Ben Soares

Terrible copy and paste! fixed

Terrible copy and paste! fixed