search

plazi / GoldenGATE-Imagine

A GUI Tool For Freeing Text and Data from PDF Documents
Other
5 stars 0 forks source link

Check in source code to master branch #2

Open tcatapano opened 9 years ago

tcatapano commented 9 years ago

Need the source code that was used to create the build posted in the release. Ideally with build instructions.

gsautter commented 9 years ago

I'll gladly upload it to any destination of your choice.

However, it's not a single GIT project ... more like 7 ones that build on top of one another. And the two at the very foundation are also the basis of RefBank, and virtually everything else we do. So simply migrating them and making them part of GG Imagine proper is not an option. It would, erroneously, suggest RefBank (as well as other things) now depend on GG Imagine ... not a good thing.

Or would (a clone of) the GG Imagine application project proper be sufficient, provided the dependencies are included as JARs?

tcatapano commented 9 years ago

@ramorrismorris should probably comment. I'm ok with having a clone of the GG Imgine code with dependencies provided as you suggest.

ramorrismorris commented 9 years ago

I agree. The critical things are (1) that version the jars of the dependencies have a well maintained version id with a well known location. (2)Any jars that we build are rebuildable from source in the github repo.

I am willing to say that we intend to build maven build facilities that will insure the right dependencies are at hand. Although not much before December, I am willing to take that on if it isn't already in hand. @gsautter: Do you have some sort of build script you use now given existing required jars?

The aforementioned principles should apply to each of the artefacts we build in git repos that build the jars that GgImagine builds

gsautter commented 9 years ago

@ramorrismorris I invest considerable effort in avoiding dependencies on specific versions of JARs, in particular on older versions. By and large, all the JARs are backward compatible. All I ever do is add functionality and new method signatures. Only in extremely rare cases there were API modifications other than additions that would have an effect outside an individual JAR. They are years in the past, and each time I adjusted the affected JARs right away.

Bottom line: It's safe to always use the most recent version. Only updates should start from the JARs at the very foundation of the system and then work upward, or down the dependency tree.

tcatapano commented 8 years ago

@gsautter: could you go ahead and upload what you consider to be the source code for the GG application proper plus the jars for the dependencies. Ideally, this would be what is necessary to build the release which we already created (i.e., the zip downloaded from Plazi Boston, apparently last revised on 2015-10-05) If your current stable code is subsequent to that, please upload it and we can create another build. Thanks.

gsautter commented 8 years ago

I would love to upload the source code ... but where exactly? Simply to the source branch? Not sure how to do that from a GIT project that is linked to another repository (and should stay that way) ... will temporarily changing the maters URL do?

An alternative would be to transfer https://github.com/gsautter/goldengate-imagine to the plazi account, so it "doesn't look like a personal project". Not sure about capitalization issues, though.

tcatapano commented 8 years ago

You could clone this repository locally and copy all the necessary files into the directory. Within the master branch, git add the files, then git commit, then git push origin master.

gsautter commented 8 years ago

Sure, that will work just fine. The GIT commands I've been using on and off for some three years. Just wanted to check if we can make do without creating yet another GIT project. But as it seems, what you propose is the best option, so I'll do it that way.

tcatapano commented 8 years ago

Thanks, I do think this if the most efficient and straightforward approach.

gsautter commented 8 years ago

I just copied and committed the application core, it should be up on GitHub now.

Next question: where to put the plug-ins (they are in a different GIT project)? I can merge them into the same src folder (the package names are compatible), I'd just have to merge the build scripts. The thing is that without plug-ins, GG Imagine can do just about nothing else than open PDFs and save them as IMFs ...

tcatapano commented 8 years ago

Adding them to the src directory sounds OK. Do you have any reservations about that? We'll just have to make clear that they are included as a convenience, but are maintained separately.

gsautter commented 8 years ago

Well, what I'll maintain is the GIT projects I'm working in right now ... This release project will never be anything but a clone. So I don't mind a merge-up at all ...

I might even write a script that pulls together all the code, including the dependencies, so we have one nice big repository with all of the code merged together. The reason I don't do this in my "working" projects is mainly dependency control, and also that especially the base libraries are the foundation of a lot more than just GG Imagine.

gsautter commented 8 years ago

Plug-ins are merged into src, and build scripts are merged as well.

gsautter commented 8 years ago

Anything else to include? Some of the functionality depends on "classic" GoldenGATE Editor plug-ins, which work on an XML wrapper around IMF, simply to be more universally usable, as IMF (naturally) depends on page images, while the XML data model underneath GG Editor can work on any given text string ...

tcatapano commented 8 years ago

Unless it is inordinately complicated to include the GG-Editor plugins, go ahead. We'd like GG-Imagine to be as full featured as possible.