build.xml

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Revert "JAL-3210 Moving j2s components around"

This reverts commit ea88f37133ba49aca6cd7bf0cc4242c0594cebf1.

  1. … 59 more files in changeset.
JAL-3210 Moving j2s components around

  1. … 59 more files in changeset.
JAL-3210 Moving j2s components around

  1. … 59 more files in changeset.
JAL-3210 Barebones gradle/buildship/eclipse. See README

  1. … 1990 more files in changeset.
JAL-3235 -Dtestng-verbosity=10 to trace execution of TestNG tests

JAL-3418 debug testng execution - verbosity=10

JAL-3210 ben testing

  1. … 7 more files in changeset.
Test file relocated to test/jalview/io.

Test file relocated to test/jalview/io.

JAL-3274: Embed build details in JalviewJS builds
JAL-3274: Embed build details in JalviewJS builds
JAL-3274 run buildProperties task when buildIndices and prepare-site are executed

JAL-3033 build.xml:build-site runs build-site.xml to populate site/ with prebuilt/deps

Merge branch 'develop' into Jalview-JS/develop

Conflicts:

.classpath

  1. … 2 more files in changeset.
JAL-3111 Disable the pubapplet target in build.xml so cruisecontrol build can complete

  1. … 1 more file in changeset.
May be worth adding temp.deleteOnExit() in case anything goes wrong with renaming later

May be worth adding temp.deleteOnExit() in case anything goes wrong with renaming later

Needs Javadoc; in particular to highlight the side-effect (that a file is written)

Needs Javadoc; in particular to highlight the side-effect (that a file is written)

Use '.' (test/jalview/io) rather than examples (which should be kept for real user data files). Or better if possible, use File.createTempFile to save files to a system-managed temporary folder.

Use '.' (test/jalview/io) rather than examples (which should be kept for real user data files).
Or better if possible, use File.createTempFile to save files to a system-managed temporary folder.

Merge branch 'develop' into trialMerge

Conflicts:

.classpath

resources/lang/Messages.properties

resources/lang/Messages_es.properties

src/jalview/api/AlignViewportI.java

src/jalview/fts/core/GFTSPanel.java

src/jalview/gui/AlignFrame.java

src/jalview/gui/AnnotationPanel.java

src/jalview/gui/Desktop.java

src/jalview/gui/FeatureSettings.java

src/jalview/gui/Finder.java

src/jalview/gui/IdPanel.java

src/jalview/gui/Jalview2XML.java

src/jalview/gui/PCAPanel.java

src/jalview/gui/PopupMenu.java

src/jalview/gui/Preferences.java

src/jalview/gui/ScalePanel.java

src/jalview/gui/SeqPanel.java

src/jalview/io/JalviewFileChooser.java

src/jalview/jbgui/GDesktop.java

src/jalview/jbgui/GFinder.java

src/jalview/jbgui/GPCAPanel.java

src/jalview/util/DBRefUtils.java

src/jalview/viewmodel/AlignmentViewport.java

src/jalview/viewmodel/seqfeatures/FeatureRendererModel.java

test/jalview/io/CrossRef2xmlTests.java

test/jalview/io/Jalview2xmlTests.java

test/jalview/ws/dbsources/UniprotTest.java

  1. … 70 more files in changeset.
JAL-3192 call buildcore.xml:make-all-cores as part of JalviewJS site build

  1. … 1 more file in changeset.
exampleLabel (and label.suffix_example_filenames) removed (had been taken out to save vertical space in the Preferences pane).

exampleLabel (and label.suffix_example_filenames) removed (had been taken out to save vertical space in the Preferences pane).

JAL-3063 removed all core castor dependent code from Jalview

  1. … 166 more files in changeset.
Is exampleLabel needed? Doesn't seem to do anything.

Is exampleLabel needed? Doesn't seem to do anything.

In BackupFiles it started off as (and remains) simply a boolean flag. Being able to convey that in the user preferences would be too terse so I agree that I wanted to expand that to look like a bin...

In BackupFiles it started off as (and remains) simply a boolean flag. Being able to convey that in the user preferences would be too terse so I agree that I wanted to expand that to look like a binary choice. I still wanted it to behave like a boolean flag though to keep the code readable in GPrefences. Also I knew I wanted to do this more than once, and I suspect that if I'm adding anything similar to Preferences in the future I'll want to use it again, it just seemed tidier to bundle it off, with checks and balances, into another class. If I ever have to change those checks and balances I'll be glad it's in a separate class and not spread around GPreferences in multiple places!

Ah I see, yes that is different behaviour. Though your class is still just wrapping a simple test like if (trueButton.isSelected()) I still think this is not so much a boolean as a binary choice ...

Ah I see, yes that is different behaviour.
Though your class is still just wrapping a simple test like

if (trueButton.isSelected()) 

I still think this is not so much a boolean as a binary choice (both options 'mean' something).
And that doing the exact same thing with two radio buttons directly would be simpler.

I'm not sure this is the same. jalviewBooleanRadioButtons.isSelected() should return true only if buttonTrue is selected and buttonFalse isn't selected. It will return false if both are selected (w...

I'm not sure this is the same. jalviewBooleanRadioButtons.isSelected() should return true only if buttonTrue is selected and buttonFalse isn't selected. It will return false if both are selected (which is not possible[!] but would be ambiguous), or neither are selected (possible but also ambiguous), or crucially if buttonFalse is selected (unambiguously return false). The two expected scenarios are one xor other are selected, with isSelected() returning either true or false. I assume buttonGroup.getSelection() != null will return true if buttonFalse is selected (sorry not had time to check this in reality)? This is how I was wanting the two button radio group to behave like a checkbox but be more visually explicit in the user preferences.

I don't really like creating work for myself, but my experience (in a different arena, so might not apply here) is that scope-creep is common and future features get asked for a couple of years dow...

I don't really like creating work for myself, but my experience (in a different arena, so might not apply here) is that scope-creep is common and future features get asked for a couple of years down the line, even when they've been specifically ruled out at the design stage! My over-spec compensatory coding stems from that experience, but I'm happy to believe that occurs less here. I guess I also think a method named "lsBackupFiles" should definitely have the ability to return a list! Now that's changed I guess I don't have to!

Merge branch 'feature/JAL-3063JAXB' into feature/JAL-3063jaxbNoCastor

  1. … 1 more file in changeset.
JAL-3063 - ant task for regenerating JAXB schema - could be optimised further

  1. … 1 more file in changeset.
Golden rule (for me, but not just for me) is not to write code you don't need (and refactor if needed in the future). Why not just have a getBackupFiles that returns TreeMap, then Groovy is free to...

Golden rule (for me, but not just for me) is not to write code you don't need (and refactor if needed in the future).
Why not just have a getBackupFiles that returns TreeMap, then Groovy is free to use as it wishes e.g. files.values().iterator().
More flexible than guessing what view of the files might be wanted in future.

addTrueActionListener can be removed without changing behaviour. addFalseActionListener isn't used. Don't need either.

addTrueActionListener can be removed without changing behaviour.
addFalseActionListener isn't used.
Don't need either.