joantune / maidsyncher Goto Github PK
View Code? Open in Web Editor NEWDSI's syncher between ActiveCollab and GitHub's Issue system
License: GNU Lesser General Public License v3.0
DSI's syncher between ActiveCollab and GitHub's Issue system
License: GNU Lesser General Public License v3.0
PropertyUtils.isWriteable returns false - this is because it returns itself (flow style) instead of returning void. Either one corrects this, or copies the code by hand (hella lot boilerplate)
This happens sometimes while running syncher-web
with mvn jetty:start
and then running mvn exec:java -Dexec.mainClass="pt.ist.Main"
in the syncher-main
;
Talking with @jcarvalho, I got to know that this error only happens when an instance of a fenix-framework app that is sharing a database with another (which is the case) cannot load an instance because a class has disappeared/is unknown to that apps DML.
Thus, we think the culprit is the fact that the scheduler classes exist only in the syncher-web
through the dependence that is explicitly declared in the syncher-web-restserver
but not on the syncher-main
GHRepository:
GHMilestone:
GHIssue:
GHComment:
GHLabel:
ACProject:
ACMilestone:
ACTask:
ACSubTask:
ACComment:
ACLoggedTime:
Save the permalink and use that instead of the modified (for use with the API url).
in case we have the domain instances available. It makes it simpler
When creating the first sync, everything goes well. On the second time, this gets triggered:
18:55:08.743 [pt.ist.Main.main()] INFO pt.ist.maidSyncher.domain.MaidRoot - Running SyncActionWrapper for event: Sync event, DSIElement: 240518172181 (DSIIssue) Type: UPDATE targetUniverse: GITHUB originObject: ACTask Changed descriptors: updatedById body createdById categoryId
and it shouldn't
GHLabel(s) DSIObject might not exist (depending on the label name), there fore, because of the dependedOn and similar method of the SyncActionWrapper, it might be useful to add a field to the SyncEvent telling which class(es) of DSIObject a SyncEvent might create
if a sync of a DSIObject fails for some reason. Let's delete that 'empty' DSIObject, so that the next time the synching process runs, it detects the CREATE event again
GHOrganization:
GHRepository:
GHMilestone:
GHIssue:
GHComment:
GHLabel:
GHUser:
C
U
D
ACollab (inc.)
In the earlier tests (GHIssueSyncTests), there were incorrect uses of the mockito code. It shouldn't take long to correct those and use mockito as it was meant to be used.
When adding SyncEvent's to the changesBuzz, make sure that if the origin universe is equal, the apiObject of all of those events that may already exist for that given DSIObject, are the same, if they aren't, it means that that object meanwhile changed (between SyncEvent) generations, and the Sync needs to be redone. This way, we can avoid having less exceptions sent when applying the ChangesBuzz.
Alternatively, check this only when processing the ChangesBuzz (before any change is made)
Probably a good place is a popover of the 'Failure' word in the modal
If a sync action throws an error, keep it's SyncEvent on the queue to process, thus making sure that the sync occurs
So, basicly, make sure that all of the 'touched' objects are returned in the .sync() of the SyncAction, and that those are used to complete the SyncActionLog with more info, that in turn will be displayed in the web interface, so one has a feeling of which objects were changed by which action
i.e. show that it's ongoing (have a state ongoing [that is closed at the start of another sync in the case that ongoing sync was abruptly stopped]). When a sync is in that state, don't allow them to show the details view (it is the simplest support possible)
This is kinda of tricky because you would need an AC test instance to actually test the API (?) or do an elaborate Mock of it, that kinda would defeat the purpose (?). Anyway, I'm not sure what is the response, in case of edits, like:
Related with #28
List of objects that usually are deleted:
GHMilestone
GHLabel
GHComment
Everything (?) on the AC Side
Output example:
Issue 1 name: test issue milestone: - labels: 21:45:19.076 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
duplicate invalid
got 4 comments. Showing them:
Comment 13442231 and a test comment
21:45:19.290 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
Comment 13442242 and things, more things @time 20m
21:45:19.298 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
Comment 13965715 aaand, another comment
21:45:19.306 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
Comment 14141904 added a comment, just to see it synching
21:45:19.313 [pt.ist.Main.main()] DEBUG p.i.m.domain.SynchableObject - Synching 12884902091 class: pt.ist.maidSyncher.domain.github.GHIssue changed properties: labels
List of members:
nullnulljoantune
Instead of the switch case, one could register smaller "SyncAction" instances that would take care of a given descriptor, and consume it.
In the end, if consumers where still present, a warning or error would be thrown (meaning we didn't take into consideration all of the changes). This would prevent the use of that nasty boilerplate switch case, which is half idiotic, but that hopefully does the trick of forcing you to take into consideration all of the changes.
Also, this would allow logs to be made, as one of the methods of the smaller SyncAction would be a description of what it did, e.g. the milestone descriptor changes on an ACTask, you would have a SyncAction that consumed that event and whose description of its actions would be something like, created/reused the corresponding milestone number/url on the GH side.
Anyway, this for now is a question for future processing, because the SyncAction might have more requirements that haven't been fully envisioned now (depending on the problems that will arise in the future). And also because there are some other issues to solve with this approach, like how to take care of the state that should be shared between SyncAction's e.g. a Issue that is to be edited/created on the GH side should be shared. It isn't clear yet on how this and other issues are going to be solved with this approach (and now the priority is to put this to work).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.