MapTool GitHub Repository is open for business

New build announcements plus site news and changes.

Moderators: dorpond, trevor, Azhrei, Craig

Post Reply
Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

MapTool GitHub Repository is open for business

Post by Craig »

I have created a Repository for MapTool on GitHub which can be found at https://github.com/RPTools/maptool
The build script has been created from scratch making the whole thing -- at least I think -- easier to build.

I will be accepting contributions against the version in GitHub. If you want to make contributions and you don't think it will
just be a one off the easiest way to do so is create a Github account (its free) and them fork the above repository which will
create a copy in your account. Once you have made what ever changes you wan't to you can issue a pull request which will
let us know that you have code you would like merged (and provide any details as well) that is easier to merge than keeping track
of in some ones email box. The other advantage of forking the project is it allows anyone to see changes that people are making
(as long as they are committed to the repository) hopefully leading to easier co-operation all around.

The build now used gradle instead of ant this helps manage dependancies easier and keeps the produced binaries out of source
control. The build-resources/README.md contains instructions on how to build the thing. The other projects that MapTool depends
on such as parser, rplib, dicelib etc are not yet on GitHub, I will be migrating those as needed (so let me know if you need them
in there before I get around to it). The build uses gradle wrapper so there is no need to install gradle to build MapTool, because
of this the first time you build the source it will take quite a while as it needs to download gradle components, then it will download
MapTool external dependencies. This will be cached so subsequent builds will be significantly faster.

All major IDEs support git, and most support GitHub specifically if you want to use an editor that for some reason doesn't support
it git (or you don't like its support) for some reason there GitHub supplies its own GUI tool for Wndows and Mac OS X or you can use
the usual git command line tools. There are no editor projects/configurations checked into source control as they shouldn't be
needed as most IDEs should be able to pick up all dependancies from the gradle build file, if you are using an editor that can't
let me know (I am sure eclipse will have problems but mostly because it always has problems with everything).


Only small steps so far but at least there are some steps happeing :\, speaking of small steps the rest of this week is kinda busy
for me so don't get discouraged if I don't get a chance to look at your contributions until late in the week or early next week. I
will monitor this thread and answer any questions though, and if need be try provide more detailed instruction based on feedback.

But in the mean time here are some links to hopefully help you on your way
Fork a Repository
Flow used by GitHub
GitHub Guides
Pro Git (open source book)
GitHub YouTube Channel with training videos
GitHub Learning Resources

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool GitHub Repository is open for business

Post by Craig »

RESERVED

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool GitHub Repository is open for business

Post by Craig »

RESERVED

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: MapTool GitHub Repository is open for business

Post by JamzTheMan »

Thanks Craig! So are we back to keeping 1.3 alive for the time being? And a couple of questions...

1. Can you/GitHub handle partial merges? e.g. My "fork" has several enhancements, some not deemed acceptable by some (like html get/send requests). Would I have to keep 2 forks, then? I can't just say, "here's my fork, take xyz" I assume (or are we dealing with forks of forks?) New to GitHub but willing to learn. :)

2. Have you dealt with JavaFX yet and can your build scripts handle it? Are you still creating libraries in sub directory or a single JAR? I'm finding it convenient to package my fork as a single JAR now but it requires some work. I'm also trying to incorporate Launch4J (for the Windows users at least). It worked great for my TokenTool fork.

3. Will you be the new "gatekeeper"? Do you plan to be active (able to answer questions) or mostly just helping with getting builds together? (either is fine btw, just curious on what your goals will be.)
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool GitHub Repository is open for business

Post by Craig »

JamzTheMan wrote:Thanks Craig! So are we back to keeping 1.3 alive for the time being? And a couple of questions...
I have no plans for any more 1.3 builds and in the perfect world there shouldn't be any. Obviously if there is a nasty bug in there or issues with start up for some people then fixes for those will happen.

All new additions will be applied the GitHub repository which will be used to create 1.4. I am sure 1.3 will be around for a long time still as people may not want to move to 1.4 until its stable
(there were people running 1.2 long after 1.3 b70 game out after all).
JamzTheMan wrote:1. Can you/GitHub handle partial merges? e.g. My "fork" has several enhancements, some not deemed acceptable by some (like html get/send requests). Would I have to keep 2 forks, then? I can't just say, "here's my fork, take xyz" I assume (or are we dealing with forks of forks?) New to GitHub but willing to learn. :)
Git can be asked to take only certain commits from a pull request, although its not ideal as it slows things down (manually having to specify the commits and makes reviewing the change a lot more laborious). Its probably far better to keep things separate. You can either achieve this by creating a second fork based on your first one or creating a long running branch for changes that you don't plan to get added to the original repository, essentially doing a modified version of Flow used by GitHub where the main branch contains what is in the main repo. Both GitHub forks(essentially a new git repository) and gir branches are pretty light weight so you might want to try both approaches and see which suits you best/gets in your way the least.
JamzTheMan wrote: 2. Have you dealt with JavaFX yet and can your build scripts handle it? Are you still creating libraries in sub directory or a single JAR? I'm finding it convenient to package my fork as a single JAR now but it requires some work. I'm also trying to incorporate Launch4J (for the Windows users at least). It worked great for my TokenTool fork.
I have replicated the current zip file as I know some people like to just plonk in a replacement jar. Although I don't think this is necessary any more I just went for the way it was currently being done -- this was actually a little more work than the all in one jar approach. I have looked at a few native app builders but they all suffer from the fact that the app would need to be built on each of the platforms (Windows, Mac, Linux) separately. Its something I may revisit later when we move to Java 8 and use its package (Launch4J has issues with non ancient versions of Mac OS X last I looked at it so thats kinda ruled out).

At the moment the source and binary level for the project is set to 1.7, once we move to 8 I will update it for JavaFX (there are painful things in the build process with 7 because JavaFX is not included in JRE/JDK so dependancies are harder to deal with). So I guess you next question is when do we move to Java 8? Azhrei is concerned with moving to Java 8 because there may be video driver issues due to new rendering path. So everyone go out and test the latest builds with Java 8 and provide feedback so we can move quicker. To be honest though I can't see it taking too long to move as Java 8 has been out for a while and even Oracle is making noises about how to start transitioning people from 7 to 8 as default. It appears -- at least to me -- that the changes to rendering path are likely to be more friendly towards video drivers than less too
JamzTheMan wrote: 3. Will you be the new "gatekeeper"? Do you plan to be active (able to answer questions) or mostly just helping with getting builds together? (either is fine btw, just curious on what your goals will be.)
I plan to be active and can answer questions. One of the benefits of using the pull request mechanism of GitHub is you dont have to send the email with a patch to me or Azhrei it just appears on GitHub for either of us to handle.

User avatar
JML
Dragon
Posts: 515
Joined: Mon May 31, 2010 7:03 am
Location: Blagnac, France

Re: MapTool GitHub Repository is open for business

Post by JML »

Another question : what about the work username seems to have made till now. Is it already in or do you plan to integrate it later ?

By the way : glad to see you back guys :D

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool GitHub Repository is open for business

Post by Craig »

JML wrote:Another question : what about the work username seems to have made till now. Is it already in or do you plan to integrate it later ?

By the way : glad to see you back guys :D
I havent seen all his stuff -- so I appologise upfront for stuff I dont know about or has changed drastically since I last saw it -- but from what I have, some of it like the asset mamager can and should be intergrated, and some of it like some of his mock ui is just a mock up and doesn't do much but display stuff on the screen without any thing happening behind the sceenes or connection to how things are working. Obviously if he has code that does something we need or improves on something that is already there we want it:)

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: MapTool GitHub Repository is open for business

Post by JamzTheMan »

Thanks for all the replies, I see where you are going now.

Re: MT 1.3 vs 1.4. Would it not make sense then to create a second Git repository (or is it easy enough to manage by version?). So if there is a bug, we can put 1.3 and send a patch, but truly start hacking up 1.4.

I think if we plan on doing 1.4 (as a community) we need a Lead Designer to set out some goals (small and large) and developers can start claiming chunks of it. I would expect the 1.4 build to be broken more than not as we start changing things wholesale. I'd be willing to contribute but my time comes and goes like everyone so I'd rather check in partial code with bugs (with comments and all) than not check it in for months at a time. Someone else may be able to pick on the mantle and fix small sections that way.

Re: Java 1.8. I agree, and in fact may just go ahead and switch over to 1.8 for my fork and see how it goes. JavaFX has been a PITA with 1.7. For 1.4, I say definately go 1.8. There's no reason to stay on 1.7 for it. It'll take so long for a first release anyway. And IMHO, we have 1.3_x for backwards compatible versions if people need it. I think it's great that we've been able to keep MT multi-platform and very generic, but in the end, sometimes you will just have to cut the fat. Besides, by the time MT 1.4 will be GA, we'll probably be having discussions regarding Java 1.9...
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool GitHub Repository is open for business

Post by Craig »

JamzTheMan wrote:Thanks for all the replies, I see where you are going now.

Re: MT 1.3 vs 1.4. Would it not make sense then to create a second Git repository (or is it easy enough to manage by version?). So if there is a bug, we can put 1.3 and send a patch, but truly start hacking up 1.4.
To be honest I am really hoping no more builds of 1.3 are needed. That might be optimistic of me though :) even if we need one or two new ones the bug fixes should be small enough that I don't feel at this time it's worth moving away from current repo for 1.3. 1.3 is not perfect by any means but the line needs to be drawn somewhere (and adhered to this time :))
JamzTheMan wrote:I think if we plan on doing 1.4 (as a community) we need a Lead Designer to set out some goals (small and large) and developers can start claiming chunks of it.
I think we need to get some feedback of what people want, hmm we need some sort of survey to see how important different features are to people. There will of course be some things that are not "sexy" feature additions that need to be done as well.
JamzTheMan wrote: I would expect the 1.4 build to be broken more than not as we start changing things wholesale.
This is true, but it would be good to have frequent builds that are stable enough to be tested in adventurous groups. Everyone having their own fork with their own ability to create branches should be helpful in managing this.
JamzTheMan wrote:I'd be willing to contribute but my time comes and goes like everyone so I'd rather check in partial code with bugs (with comments and all) than not check it in for months at a time. Someone else may be able to pick on the mantle and fix small sections that way.

If you have a public repo on github this means any one can see the code you have checked in and lend a hand completing it if need be. As long as you don't mind people seeing your half completed code this is a good thing :)
JamzTheMan wrote:Re: Java 1.8. I agree, and in fact may just go ahead and switch over to 1.8 for my fork and see how it goes. JavaFX has been a PITA with 1.7. For 1.4, I say definately go 1.8.
I am not the one who needs convincing :)
JamzTheMan wrote: Theres no reason to stay on 1.7 for it. It'll take so long for a first release anyway. And IMHO, we have 1.3_x for backwards compatible versions if people need it. I think it's great that we've been able to keep MT multi-platform and very generic, but in the end, sometimes you will just have to cut the fat. Besides, by the time MT 1.4 will be GA, we'll probably be having discussions regarding Java 1.9...
I can't think of any platforms people would be using that have Java 1.7 but not java 1.8.

username
Dragon
Posts: 277
Joined: Sun Sep 04, 2011 7:01 am

Re: MapTool GitHub Repository is open for business

Post by username »

Craig wrote: I havent seen all his stuff -- so I appologise upfront for stuff I dont know about or has changed drastically since I last saw it -- but from what I have, some of it like the asset mamager can and should be intergrated, and some of it like some of his mock ui is just a mock up and doesn't do much but display stuff on the screen without any thing happening behind the sceenes or connection to how things are working. Obviously if he has code that does something we need or improves on something that is already there we want it:)
I'd still consider pre-alpha, it is mostly a design prototype for the architecture: components, layers, data-model. That, I think, has been validated (still being rough on the edges...) So currently I am trying to bring the basics up (somewhat according to priorities suggested in the other thread) but that may still take a few weeks. Then it can be released to some early birds.

But since with JFX all of the GUI stuff would need to be rewritten (unless simply using the JFX Swing container) we wanted to take the opportunity to disentangle other pieces of the code. If that's still the goal.

Currently you have
- relatively completed grid component (but simple movement layer)
- select and move tokens (images) around
- manipulate images on the background and draw (including patterns)
- disabled vision layer :-)
- manipulate layer order and visibility
- load/save (probably clumsy) and ignores drawing (fixing that currently)
- and, of course, the asset component (zips, directories, javaresource, cache, webpage, campaign) with reordering
- I haven't checked in the tell-mocks-by-disabled-buttons yet. Maybe later this week.
- (Sun's) checkstyle, findbugs, some testfx automated integration tests

Post Reply

Return to “Announcements”