Object List Overview

#21

I've never used travis - professionally we're jenkins-guys. But if travis can launch the jar and point it to the objects directories, it would be possible, that the java application then git-pushes it's render result to the gh-pages repository. Or it could render in a gh-pages repository-clone which then again could be pushed by travis. Since gh-pages are still a github repository, right? But i've no experience at all with travis.
What do you think?

#22

ok, I took another look :slight_smile:

yes, we could publish to gh-pages for each of axolotl-factory and axoloti-contrib repos.

the trick is to use an RSA key pair, the private one is then encrypted using travis tools.
theres a good run down of how to do it for doxygen here, it doesn't matter what process you run.
http://blog.gockelhut.com/2014/09/automatic-documentation-publishing-with.html

(I think all I need to setup, is an axoloti gh-pages repo to be created, which I have contributor access to, so I can push the public key to it)

#23

Hi,
I'm a bit hesitant to include this project into the axoloti source repositories itself, because it could complicate code maintenance. I appreciate the project, but in a way it is only re-presenting the information in objects from an independent codebase. I'd suggest to host it outside the output on another repo. I'm open to including a travis or jenkins job and key into the axoloti repos, that 'd be probably a script of a few dozen lines, to trigger the job on commits.
Don't get me wrong, I appreciate it, and 'd be happy to link to it, but need to focus my efforts.

#24

Hey, I completely understand your hesitation. Because I don't know anything about axo's CI and deployment infrastructure I think I can't really provide much benefit to this discussion. If somebody found a lightweight integration solution I woud be happy to make the necessary adoptations/extensions to my java application. Just tell me what you need and you got it :grin: Java applications, web services and system integration are my daily business so don't hesitate to ask!

#25

there are, of course, quite a few ways to do this....

if you want active triggers, then I think the scripts have to be in the travis.yml of the repo with the source thats changing (i.e. axoloti_factory/community), what these triggers do though of course is 'open'.
they could simply 'ping another web server' , which in response could do a pull.

otherwise you could poll the repos... not as nice, but can work.

in the last post, what I envisaged was just having a compiled jar from @cpwitz in the factory/community repos (in a tools directory), so its just replaced when/if there is a new version (e.g. if the xml format changes)

there is another side to this for the future...
I would interested to know how users are using this, such that the new object browser could do something similar within the app.
... but it maybe that users are enjoying this because they can see if without starting the app, in which case, the object browser can help this :))

#26

I use it to get a visual overview of the whole object or group of objects whilst being able to see the inputs and outputs whereas the object viewer in the ui feels cramped with no resize options, it shows a single object and you have to click each object to see what type the outlets are.

This is useful for comparing and making decisions on selecting objects from a group that share the same name, it also serves as a good reference for existing patches without cluttering the UI (I run 2 screens, well, 3 if you count the 2nd PC).

hth.

#27

Ah, now i see there are two separate sections named "logic", why?

#28

If you read the comments above, there is an answer I think ^^^^.

Especially TimVets and Cpwitz dialog.