What should "sync libraries" do

#1

I'm running latest from git on linux.

I added my baby axoloti patches to github, should the "sync libraries" handle push/pull of my private patches?

I think I'm missing the community patches (nothing in file->library->community)

Pressing "sync libraries" gives me this:

sync Successful : factory (master,anon)
Sync (pull) FAILED : community (master,anon)
org.eclipse.jgit.api.errors.RefNotAdvertisedException: Remote origin did not advertise Ref for branch master. This Ref may not exist in the remote or may be hidden by permission settings.
org.eclipse.jgit.api.errors.RefNotAdvertisedException: Remote origin did not advertise Ref for branch master. This Ref may not exist in the remote or may be hidden by permission settings.
	at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:294)
	at axoloti.utils.AxoGitLibrary.pull(AxoGitLibrary.java:331)
	at axoloti.utils.AxoGitLibrary.sync(AxoGitLibrary.java:70)
	at axoloti.menus.FileMenu.jMenuSyncActionPerformed(FileMenu.java:264)
	at axoloti.menus.FileMenu.access$400(FileMenu.java:51)
	at axoloti.menus.FileMenu$5.actionPerformed(FileMenu.java:134)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
	at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
	at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
	at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
	at java.awt.Component.processMouseEvent(Component.java:6516)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3312)
	at java.awt.Component.processEvent(Component.java:6281)
	at java.awt.Container.processEvent(Container.java:2229)
	at java.awt.Component.dispatchEventImpl(Component.java:4872)
	at java.awt.Container.dispatchEventImpl(Container.java:2287)
	at java.awt.Component.dispatchEvent(Component.java:4698)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
	at java.awt.Container.dispatchEventImpl(Container.java:2273)
	at java.awt.Window.dispatchEventImpl(Window.java:2719)
	at java.awt.Component.dispatchEvent(Component.java:4698)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:747)
	at java.awt.EventQueue.access$300(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:706)
	at java.awt.EventQueue$3.run(EventQueue.java:704)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.awt.EventQueue$4.run(EventQueue.java:720)
	at java.awt.EventQueue$4.run(EventQueue.java:718)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:717)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

search path : /mnt/data/atte/medium/software/axoloti/axoloti-factory/objects
search path : /mnt/data/atte/medium/software/axoloti/objects
search path : /mnt/data/atte/medium/software/axoloti/axoloti-contrib/objects
finished loading objects
#2

I think this is because you are using an old test version (prior to 1.0.10), as was advised in this post you were required to upgrade. (test versions have limited life, as they are for testing only)

you should upgrade to 1.0.11 ,

before you upgrade backup your own patches/objects in a different directory

notes:
a) as you are using linux, please ensure you take note, of the issue with certificate.
b) you may also find that due to the master branch not being available the upgrade of libraries will fail, if so use preferences -> reset all , to reset your libraries)

sorry for the inconvenience, but I did make the EOL post a long time back before I deleted master, and also before that I have been advising users that for test releases, they must keep up to date with the latest test. (if you have moved to 1.0.10 this also would not have occurred)
... all of this is fairly common practice for these kind of test releases.

the library mechanism can cope with factory, community libraries and yes also private repos, see my videos about this. (there is a list of videos here)

hope this gets you back patching
Mark

#3

I wasn't being clear: I cloned from git and compiled from source. Assumed this would give me the latest. But you still recommend that I upgrade (installing from the 1.0.11 tarball)?

#4

ah, ok... then its a similar problem, but for a different reason...

if you compile from source, then its trying to use master, as this will be the 'development branch' of these libraries.
BUT the issue is, you will want to be using the version that other users are using!
SO... the solution is, go into both factory and contrib libraries , and set the revision to 1.0.11, and then do 'init' on each, this will move you to using 1.0.11 along with other users.

note: there is one issue with this approach, if you specify a revision, then I believe you will not get a warning when we move to the next version( e.g. 1.0.12) ...
(though, I need to confirm this, as its a while since I wrote that code :wink:)

question: @a773 can you not used the released linux package? unless you are planning on helping development, it is a much better idea... we do not support the development version, as it may have untested/incomplete code etc.

what I need to do (or someone else) is actually detail the compiling from source with a bit more detail, and in particular how it should be done, as ideally users (that are not developers) should be using the tagged release from github, not the master branch.

@johannes this highlights an issue, which I've mentioned before...

really there are 2 types of users compiling from source:
a) users with unsupported platforms... they just want a build
for these users, they should build the currently released version, against the tag e.g. 1.0.11
this should then default the revisions to that tag (as it does with the pre-built binaries)

b) developers/testers who what to use a development version
this must not be used against the production release repos, as the code may contain code that could break these repos.
as I suggested before, my thoughts are as soon as we make a release, we must then tag the development code line with a new version (* see below on thoughts on this), and then we can have a branch version of the factory/contrib that corresponds to this version. (and that the build will use by default for revision) ... we will then merge from production to dev 'regularly'

new version... as before, I suggest we use a linux type convention of 'even numbers' for development and odd for release.

so an example for now might might be
1.0.11 is released,
we create a branch now (axoloti,axolotl-factory,axoloti-contrib) for 1.0.12, this is the dev branch...
(during dev we keep merging 1.0.11 to 12 for the factory/contrib)
when releasing, we create a 1.0.13 branch, and then if we are doing a minor release (1.0.14 for dev)

this is for minor release..

when we are on to 'major' releases, I want to move to
1.1.0 for dev
1.2.0 for release
1.3.0 for dev
1.4.0 for release

it may seem complex, but the point is, that users of type (a) or (b) will then always be connected to the correct object/patch versions, and the development environment will operate the same as release environment, when committing changes etc... much better for testing.
also, this mechanism allows for the app to know about 'upgrading' and moving the repo versions, something we cannot do if its just called 'master'

#5

Thanks.

I'll give the 1.0.11 tarball a go. Can't use the .deb since I'm on 32 bit. NB: Had to remove lib32z1 and lib32ncurses5 from the build script, these libs are nowhere to be found in 32-bit debian and everything seems to work just fine...

#6

Ok, tried building 1.0.11, it fails with this:

-do-compile:
    [mkdir] Created dir: /mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/build/empty
    [mkdir] Created dir: /mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/build/generated-sources/ap-source-output
    [javac] Compiling 403 source files to /mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/build/classes
    [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6
    [javac] /mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/src/main/java/axoloti/Version.java:3: error: unclosed string literal
    [javac] public final static String AXOLOTI_VERSION = "fatal: Not a git repository (or any parent up to mount point /mnt/data)
    [javac]                                              ^
    [javac] /mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/src/main/java/axoloti/Version.java:4: error: ';' expected
    [javac] Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).";
    [javac]            ^
    [javac] /mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/src/main/java/axoloti/Version.java:4: error: ')' expected
    [javac] Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).";
    [javac]                                                                     ^
    [javac] /mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/src/main/java/axoloti/Version.java:4: error: illegal start of type
    [javac] Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).";
    [javac]                                                                         ^
    [javac] /mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/src/main/java/axoloti/Version.java:4: error: <identifier> expected
    [javac] Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).";
    [javac]                                                                          ^
    [javac] /mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/src/main/java/axoloti/Version.java:4: error: unclosed string literal
    [javac] Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).";
    [javac]                                                                           ^
    [javac] 6 errors
    [javac] 1 warning

BUILD FAILED
/mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/nbproject/build-impl.xml:911: The following error occurred while executing this line:
/mnt/data/atte/medium/software/axoloti/axoloti-1.0.11/nbproject/build-impl.xml:261: Compile failed; see the compiler error output for details.
Problem with 1.0.11, specifically commit a95546
#7

the tar wont help... its basically the same as compiling from the git clone.

if you want to know your using the 1.0.11 source, you should clone, then use

 git checkout 1.0.11

this will then use the 1.0.11 tag, which is the current release.

BUT you will still need to set the revision on each library, as it always defaults to master when used in 'developer mode'

(hmm, Im thinking I might change this to use the current tag, to stop all this :slight_smile: )

#8

@a773
ok, Ive made a code change, so that the development version uses the current library branch rather than master - so pull the current version of axoloti from github again, and compile.

(don't use 1.0.11 tag, at this time... as you need this code change! , and preferably delete your axoloti.prefs, as you will not want anything in the 'release' field of the library)

@johannes
I decided to do this way, as frankly, the current approach using master is as likely to cause issues e.g. things being checked into master, than don't make it into release branch etc, and also they would be tagged incorrectly in the object/patch version anyway!

once we decide on a version number scheme, we can create the branches require for a separate development version... so perhaps you can give this some thought?

my suggestion as above is:

for minor dev
1.0.11 to 1.0.12 (dev) to 1.0.13 (release) to 1.0.14(dev) to 1.0.15(release)
basically, this is a branch of the release. (i.e. 1.0.x in this case)

for normal dev
1.0.x(release) 1.1.x(dev) 1.2.x(release), 1.3.x(dev) 1.4.x(release)
note: if we have test releases we can use 1.2.1,1.2.2,1.2.3 etc.

this means the 1.x is not used for 'marketing' i.e. it doesn't constitute a major change, or have any expectations on it... its just a release, that is 'not a bug fix' release.

of course, you can then 2.0.0 as your 'marketing' that something really big an exciting has happened :wink:

#9

Thanks, everything now seems to work as expected, I can now see the community patches as well. Great!

Edit: and now I tested with core connected, and it works just fine!