PCGen Wiki - User contributions [en]

Joining the Code Team

2015-06-03T13:10:52Z

James: Github update

{| align="right"
| __TOC__
|}

=Introduction=

A list of what to do to join the code team

=General steps=

# Get a [http://groups.yahoo.com Yahoo Groups] id.
# Be sure to subscribe to the [http://groups.yahoo.com/group/pcgen_developers/ Developer's mailing list]
# Introduce yourself on the list
# Find the [http://games.groups.yahoo.com/group/pcgen/ pcgen] project on Yahoo! Groups and join.
# Get as many IM IDs as possible (most people use Pidgin, Meebo or Gaim) and get online with them.
# Also join the IRC channel #pcgen on ~DALnet & ~Freenode, we have our meetings and group discussions there in real time.
# Get the latest official version of PCGen from SF and run it.
# Get an id at [https://github.com/ GitHub].
# Find the [https://github.com/PCGen/pcgen/ pcgen] repository and [https://help.github.com/articles/fork-a-repo/ fork] it.

=Your first change=
# Get your [[Basic Developer Setup|development environment set up]]
# Select an issue that interests you, either from our issues flagged as bitsize in the [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=component+%3D+Bitesize+AND+project+%3D+CODE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Code] and [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=component+%3D+Bitesize+AND+project+%3D+NEWTAG+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC New Tag] projects, or one you have encountered.
# Build a fix that fixes the bug or implements the new feature
# Test the fix, preferably by writing a unit test
# Submit the fix as a [https://help.github.com/articles/using-pull-requests/ pull request] to the pcgen repository.
# Your pull request will be reviewed and friendly feedback provided by one of the team.

=Joining the team=

# Once your pull request (PR) is accepted and merged, you're part of the code team.
# Your second PR should be adding your name to the team listing!
# Put your details in this wiki under the [[Code]] team!

Any questions, don't hesitate to ask!

Release Instructions

2015-05-25T21:40:30Z

James:

{| align="right"
| __TOC__
|}

==Introduction==

Here are the steps to follow when making a release of PCGen. If it is your first time, please check the prereqs section at the bottom of this page.

==Prerequisites==
The first time you run a release you will have to make sure you have the following tools available:
===Release Notes===
* Text editor
* Web browser
* Perl interpreter
* Perl modules: readonly (installed on Windows via ActivePerl's Perl Package Manager)

===Release===
* Java SDK 1.6 (the one that includes the javac compiler)
* Gradle 1.x
* SVN
* Perl interpreter
* [http://nsis.sourceforge.net/Download NSIS]

===Outstanding Issues===
You need to check JIRA for any outstanding issues to ensure the release meets our QA std.

* Alpha releases require no Blockers, allow Critical only with Code lead exception
* Beta releases require no Blockers or Criticals
* RCs/final releases require no Blockers, Criticals, or Majors

==Create Release Notes==

# Update your local copy of pcgen from github
# Copy the previous set of release notes to pcgen-release-notes-nnn.html where nnn is the version number.
# Do a global replace of the old version number to the new version number, both as n.nn.n and nnnn
# Open Jira and for each project open the release notes for the version.
# Copy the html to the changelog section, changing h2 tags to h3.
# Update the What's New section with any high profile changes.
# Update the Thanks section with the list of people who committed during the cycle. The search filter "is:pr is:closed is:merged updated:>2015-02-09" is useful for triming the list of pull request to those included in the release.
# Commit the new release notes and notify pcgen_bod so they can review it.
# Notify pcgen dev and experimental lists of upcoming release, asking for autobuilds to be tested. Best to give 24 hours notice.

==The Build==
# Using a clean directory with no changes to the pcgen files
# '''svn update''' the PCGen repository (5 mins)
# Release manager edits src/java/pcgen/gui/prop/PCGenProp.properties to set the release date, version number, contributors, etc. and commit the result (5 mins)
# If switching to or from RC mode, edit gradle.properties and adjust the version number to be in the correct format. e.g. 6.4.0RC1 or 6.4.0
# Execute '''gradle clean prepareRelease slowtest''' in the pcgen directory and verify there are no failing Junit test. Also check if there are any "Unknown publisher" messages. If so you need to add new entries for the listed publishers to the gendatalist.pl script. (20 mins)
# Check Jira for any closed requests missing from the release notes. Steps 4 and 6 of 'Create Release Notes' section above can be used to assist here. (10 mins)
# Update the readme.md file with the what's new section of the release notes.
# Execute '''gradle fullZip''' or '''gradle buildNsis''' to generate a testing zip or exe. (3 mins)
# Smoke test the newly built pcgen full zip or exe. (30 mins)
# Create a folder for the release under the [https://sourceforge.net/projects/pcgen/files/ File Manager]
# Upload the release notes using the File Manager to the release folder
# Run '''gradle pcgenRelease''' (which updates the gradlefiles and tags the SVN repository). (2 mins)
# Upload the release files to SourceForge. The quickest way is uploading via the web, the same way you uploaded the release notes etc. (10 mins)
# Update Readme.MD with the SHA256 checksums from target/SHA256-digests.txt. Upload the revised file and check-in. (5 mins)
# Notify PCGen_bod of the new release. (5 mins)
# PR Monkeys create a news item for the new release
# PR Monkeys send announcement to all pcgen mailing list for the new release

==Update JIRA==

For each of the projects, mark the version you are working on as released and create the next version if it doesn't already exist. When marking a version as released, please make sure the released date is set to today.

* [http://jira.pcgen.org/plugins/servlet/project-config/CODE/versions Code Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/DATA/versions Data Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/DOCS/versions Documentation Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/NEWSOURCE/versions New Source Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/NEWTAG/versions New Tag Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/OS/versions Output Sheets Versions]

==Mac Installer==

See [http://pcgen.svn.sourceforge.net/viewvc/pcgen/Trunk/pcgen/installers/mac-installer/instructions.html Instructions]

==Signing Files with PGP==
'''Historical only''' We used to use the [[http://www.gnupg.org/ GnuPG for Windows]] to generate the signatures. You will need the private key, either your own, or the PCGen one (contact the PCGen BOD). Once GnuPG is installed and knows about the key you wish to use, it is just a matter fo right clicking on the files to be signed (multi-select is fine) and selecting GPGee > Sign and then making sure the PCGen key is selected, hitting OK and entering the passphrase for the key. This creates an .asc signature file for each selected file.

==Troubleshooting==
Yes, even the best installs of all the program amount to nothing if there is a hitch. These are basic notes from the current issues cropping up and resolutions. These notes are not prettified yet. The idea being we will get a full set of troubleshooting tips and tricks here in the near future.

Check your versions.
JDK1.5 is required with JAVA_HOME variable (see below)
SVN must be a true .exe install, TortoiseSVN will not meet this requirement
SVN exe can be found here [[http://subversion.tigris.org/files/documents/15/46531/Setup-Subversion-1.6.5.msi SVN]]

My Computer > System > Advanced Settings:
For JAVA_HOME make sure it's a set System Variable and make sure it's using the correct path to your current installation base folder

Meeting 2015 01 30

2015-01-31T01:39:20Z

James:

=Board Meeting=

==Attendance==
* Chair - Andrew Maitland
* Data 2nd - Doug Limmer
* OS 2nd - Stefan Radermacher
* Arch - Tom Parker
* Observer - David Bender
* Observer - Jeff (Swiftbrook)

==Summary==
* License will review newer sources finished this weekend
* Stefan will finish data reviews this weekend
* Doug is still working on Advanced Class Guide
* James will release 6.5.1 next weekend (Feb 7/8)
* Code Bug introduced for deities tab
* Deep Dive discussion by Tom:
** Proposed integrating the non-solver portion of the formula parser - this would allow the BOOLEAN functions that we're using for Archetypes and Racial Traits
** Brought up Performance issue for Trailing PRExxx
** Brought up thoughts about handling the PRE/REQ concepts and PRETHIS
** Discussed a solution for the REQ/PRE but would lose user feedback - re-thinking how to utilize that better
** Eluded to new tools for the data team

==RAW LOG==

* [15:01] <@Andrew[Chair]> I have 3pm PST/6pm EST
* [15:01] <@Andrew[Chair]> it's time according to my schedule
* [15:01] <@Andrew[Chair]> We want to wait another 5 minutes for James?
* [15:02] <Distant_Scholar> I just got an e-mail saying James won't make it (I imagine y'all did, too).
* [15:02] <@Andrew[Chair]> I didn't...
* [15:03] <Distant_Scholar> I got it on the BOD mailing list.
* [15:03] <Distant_Scholar> I'll (try to) copy it in below.
* [15:03] <Distant_Scholar> JD: Hi, I'm not able to make today's meeting sorry
* [15:03] <Distant_Scholar> JD: Code report:
* [15:03] <Distant_Scholar> JD: * Welcome to Mark Cline who joined the code monkeys last week.
* [15:04] <Distant_Scholar> JD: * Some small non arch changes to the code
* [15:04] <Distant_Scholar> JD: * Aiming to put out 6.5.1 soon. Could be next weekend if everyone is ok with that.
* [15:04] <Distant_Scholar> JD: Cheers, James.
* [15:04] <@Andrew[Chair]> Okay, cool
* [15:04] <@Andrew[Chair]> Guess we should start then
* [15:04] <@Andrew[Chair]> *Bangs gavel*
* [15:05] <@Andrew[Chair]> Hi all, welcome to the PCGen Board of Directors meeting for January 30th, 1500 hours PST
* [15:05] <@Andrew[Chair]> Agenda:
* [15:05] <@Andrew[Chair]> Quick reports for immediate items
* [15:05] <@Andrew[Chair]> Nixed - Release Schedule (James isn't present)
* [15:05] <@Andrew[Chair]> Tom's Deep Dive Discussion
* [15:06] <Tom[Arch_SB]> Not sure if deep dive is useful without James
* [15:06] <Tom[Arch_SB]> that's really one of the sounding boards
* [15:06] <@Andrew[Chair]> Hm, well... We can pitch ideas at him.
* [15:07] <@Andrew[Chair]> He does read the reports too... :)
* [15:08] <@Andrew[Chair]> Okay, since the deep dive won't be happening as deeply, I'll just report my absent report blurb as well.
* [15:08] <@Andrew[Chair]> Content Report:
* [15:08] <@Andrew[Chair]> Data: Cleared two new sources into the release "Adventurer's Armory" and "AP #67"; waiting on Stefan to clear a few more sources now - Blood of the Moon, Taldor, Technology Guide.
* [15:08] <@Andrew[Chair]> I just finished coding up Inner Sea Combat - that's now off to License and Data for review. Doug is still working on Advanced Class Guide.
* [15:08] <@Andrew[Chair]> I had to redo the system that controlled Ranger Bonus Feats, and the Archetype control for the Ranger Combat Style.
* [15:08] <@Andrew[Chair]> We are in discussion about EQMOD naming standards, looks like we'll be doing real names to follow object naming like we do for equipment.
* [15:08] <@Andrew[Chair]> Documentation: Found a few bugs, but otherwise nothing is happening here.
* [15:09] <@Andrew[Chair]> Outputsheets: Working with Tom to update items to use the new FACT/FACTSET system. Stefan is working on a few issues.
* [15:09] <@Andrew[Chair]> That's it for Content
* [15:09] <@Andrew[Chair]> Questions before I post Paul's License report?
* [15:09] <Tom[Arch_SB]> not from me
* [15:09] <Distant_Scholar> There is someone else working on ACS; I forget who, though. Andrew Wilson, maybe?
* [15:10] <@Andrew[Chair]> There's been a few.
* [15:10] <@Andrew[Chair]> I added a one-off contributor as well
* [15:11] <@Andrew[Chair]> Okay, Paul reports: I intend to have all the files for licensing cleared this weekend.
* [15:11] <@Andrew[Chair]> I haven't heard from Admin.
* [15:12] <@Andrew[Chair]> Tom, you're up. *passes talking stick*
* [15:12] <Tom[Arch_SB]> So as you mentioned, FACT/FACTSET went in with the new output models
* [15:12] <Tom[Arch_SB]> so working to add to those as necessary, will take a bunch of effort to get through those
* [15:13] <Tom[Arch_SB]> Looking further at the formula system and how that can be integrated, perhaps a short discussion on that at the end
* [15:13] <Tom[Arch_SB]> Main focus though is driving as much as we can to the new output system to try to decouple from the old output tokens/code
* [15:13] <Tom[Arch_SB]> that gives learning of what can be/has to be done in the OS and what macros and other things will be useful
* [15:14] <Tom[Arch_SB]> as what as what will still require some code support (hopefully very little)
* [15:15] <Tom[Arch_SB]> I also merged a change today that will hopefully quiet Jenkins
* [15:15] <@Andrew[Chair]> :-) Thank You
* [15:15] <Tom[Arch_SB]> lots of "administrative code cleanup" if you will
* [15:15] <Tom[Arch_SB]> any questions?
* [15:16] <@Andrew[Chair]> Not really a question, more of a "When you free to work on it?"
* [15:16] <Tom[Arch_SB]> We can cover that offline, not sure how to predict that well
* [15:17] <@Zaister> good evening
* [15:17] <@Andrew[Chair]> Fair enough. Otherwise, no direct question. Just eager to hear what you want to share about the system changes.
* [15:17] <Tom[Arch_SB]> Hi Stefan
* [15:18] <@Andrew[Chair]> Hi Stefan
* [15:19] <@Zaister> Did we get the domain tabs stack trace fixed? That was caused by the FACT merge
* [15:19] <@Andrew[Chair]> Stefan, since you're here, you have anything to add to the reports or discussion? :)
* [15:19] <@Andrew[Chair]> (before we drag out more details from Tom)
* [15:19] <Tom[Arch_SB]> Didn't see that bug report, is there a JIRA for it?
* [15:19] <@Zaister> I hope I finally get the reviews done over the weekend, I have nothing more at the moment
* [15:19] <@Andrew[Chair]> I didn't see any report either.
* [15:20] <@Zaister> tom: I don't think so, but I get a stack trace everytime I run the program, and the deity list is empty. I think there was a list posting
* [15:20] <Tom[Arch_SB]> looks like James opened one
* [15:20] <Tom[Arch_SB]> CODE-2818
* [15:20] <Tom[Arch_SB]> I'll look at that
* [15:20] <Tom[Arch_SB]> thanks for the pointer
* [15:21] <@Zaister> cool
* [15:22] <@Andrew[Chair]> Okay Tom... you teased us about Formula parser stuff, fact/factset and some nifty super secret project... so discuss. :)
* [15:24] <Tom[Arch_SB]> Well, tonight is going to be on the formula parser
* [15:25] <Tom[Arch_SB]> There have been ongoing concerns about integration, and still trying to work through a decent way to do that
* [15:25] <Tom[Arch_SB]> Was thinking it might be good to integrate but in the initial pass, without any ability to do equations
* [15:25] <Tom[Arch_SB]> This sounds a bit strange, but it's actually still a lot of capability
* [15:25] *** PapaDRB has quit IRC: Quit: ~ Trillian Astra - www.trillian.im ~
* [15:25] <Tom[Arch_SB]> much of the FLAG stuff could work, so the data could be removing the current "it's a var but we're using it as a flag"
* [15:26] <Tom[Arch_SB]> which offloads BONUS and thus would help out
* [15:26] <Tom[Arch_SB]> also is better semantics
* [15:26] <Tom[Arch_SB]> I can also use the solving system internally to get rid of some code
* [15:26] <Tom[Arch_SB]> and make things more consistent and debuggable
* [15:27] <Tom[Arch_SB]> (anything passing through a solver would appear in the solver debugging system which was in the EqVar demo)
* [15:28] <Tom[Arch_SB]> It actually brings in the solver so we get some experience with it, starts to move data without trying the more risky rip up of formulas (but certainly reduces use of BONUS so there is less to worry about later)
* [15:28] <Tom[Arch_SB]> I think it's a good first step and wanted to get thoughts on that
* [15:28] <@Andrew[Chair]> Sounds really good to me. Ranger already proved we need that.
* [15:29] <@Andrew[Chair]> This means we'd get PREBOOL for the initial pass?
* [15:29] <Tom[Arch_SB]> Yes, that would be part of it
* [15:30] <@Andrew[Chair]> Archetypes would be a great test bed, see how that helps performance :)
* [15:30] <Tom[Arch_SB]> well...
* [15:30] <Tom[Arch_SB]> to set expectations....
* [15:30] <Tom[Arch_SB]> there are a few things in the performance issue category
* [15:30] <Tom[Arch_SB]> one is BONUS
* [15:30] *** Swiftbrook has quit IRC: Ping timeout: 246 seconds
* [15:30] <Tom[Arch_SB]> but one is having a trailing PRExxx at all
* [15:30] <Tom[Arch_SB]> so eventually we need to think in mental models that try to minimize trailing PRExxx
* [15:31] <Tom[Arch_SB]> (The default object trick, while useful to get around some issues PCGen has had and a few that it may still have is a long term issue)
* [15:31] <@Andrew[Chair]> If you have a better model to handle Archetypes, I'm very open to discussions.
* [15:32] <Tom[Arch_SB]> That's one thing I've been looking at to try to figure out a good model
* [15:32] <Tom[Arch_SB]> It's kind of an interesting problem
* [15:32] <Tom[Arch_SB]> was looking at Stefan's PRETHIS FREQ as well and want to find something better than that when it's "can't do another of <blah>"
* [15:33] <@Zaister> ah that one
* [15:33] <@Andrew[Chair]> Yeah, the basic PRExxx turn red issue, and that doesn't even touch the MULT:YES items
* [15:34] <Tom[Arch_SB]> it really highlights a few different things all at once.
* [15:34] <Tom[Arch_SB]> Well, that's what I think anyway, based on my research so far
* [15:34] <@Andrew[Chair]> Yes, many issues. All stem from no better solution has been presented to solve it.
* [15:34] <Tom[Arch_SB]> One is the "there is a <foo> modification performed by an archetype and once you have one that does that you can't take another"
* [15:35] <Tom[Arch_SB]> (that performs that mod)
* [15:35] <Tom[Arch_SB]> One is the red display issue, so it's really back to PRE/REQ
* [15:35] <Tom[Arch_SB]> and separating those concepts
* [15:35] <@Andrew[Chair]> Yes, separating concepts is a good idea.
* [15:36] <Tom[Arch_SB]> One of the big challenges is in communication back to the user
* [15:37] <Tom[Arch_SB]> I have at least one model that would work logically, but the info window wouldn't necessarily be able to say why it wasn't available
* [15:37] <Tom[Arch_SB]> I'm unsure what the reaction to that would be
* [15:37] <@Andrew[Chair]> Which situation is this?
* [15:38] <@Andrew[Chair]> Feedback is important for debugging issues
* [15:38] <Tom[Arch_SB]> Any Ability
* [15:38] <Tom[Arch_SB]> sorry, not the use case I'm talking about
* [15:38] <Tom[Arch_SB]> When you go in to select a Feat, for example
* [15:38] <Tom[Arch_SB]> Super Weapon Foo is red because you need to be specialized in something first
* [15:39] <Tom[Arch_SB]> right now, presumably, there is a PREFEAT:Weapon Specialization or whatever
* [15:39] <@Andrew[Chair]> yes
* [15:39] <Tom[Arch_SB]> (or maybe it's implicitly the choose? I should actually check that)
* [15:39] <@Andrew[Chair]> PREABILITY:1,CATEGORY=Feat,Weapon Focus
* [15:39] <Tom[Arch_SB]> anyway, presume it's a PREFEAT for discussion
* [15:39] <Tom[Arch_SB]> ok
* [15:40] <Tom[Arch_SB]> so that PREABILITY produces text in the info window of "must have 1 of Ability (Feat ) Weapon Focus"
* [15:40] <Tom[Arch_SB]> or some such
* [15:40] <Tom[Arch_SB]> and that text will be red
* [15:40] <@Andrew[Chair]> yes
* [15:40] <Tom[Arch_SB]> since it's not met
* [15:40] <Tom[Arch_SB]> that's the text I'm talking about
* [15:40] <@Andrew[Chair]> okay
* [15:40] <Tom[Arch_SB]> I have a system that might dramatically simplify the data, but those would be lost
* [15:41] <Tom[Arch_SB]> but I suspect the "why can't I take this" might be important to some folks
* [15:41] <@Andrew[Chair]> Yes, we'd have an increase in help desk "calls"
* [15:41] <Tom[Arch_SB]> so not sure about that model and whether I can adapt it
* [15:42] <@Andrew[Chair]> So, silly question, why can't we just use a PRETEXT:Must have Weapon Focus to take this feat. ?
* [15:43] <Tom[Arch_SB]> two reasons
* [15:43] <@Andrew[Chair]> not sure if we need the color coding to indicate, but having a message on what is required regardless would be the minimal thing to me.
* [15:43] <Tom[Arch_SB]> one would be data sprawl
* [15:43] <Tom[Arch_SB]> the other is... hard to explain
* [15:44] <Tom[Arch_SB]> This isn't what I'm thinking, so dont' take it AT ALL literally, but imagine the ability to do a PREOTHER to apply a PRE to another object
* [15:44] <Tom[Arch_SB]> you'd need the PRETEXTOTHER as well
* [15:44] <Tom[Arch_SB]> hmm
* [15:44] <Tom[Arch_SB]> that's interesting though
* [15:44] <Tom[Arch_SB]> let me think on that
* [15:44] <Tom[Arch_SB]> there are ways something like that could work
* [15:45] <Tom[Arch_SB]> maybe
* [15:45] <Tom[Arch_SB]> need more brainpower than I have after a long week :/
* [15:45] <@Andrew[Chair]> PREOTHER is an interesting concept...
* [15:45] <Tom[Arch_SB]> don't even go there
* [15:45] <@Andrew[Chair]> :P
* [15:45] <Tom[Arch_SB]> the goal is less PRExxx not more
* [15:45] <@Andrew[Chair]> You brought it up.
* [15:45] <Tom[Arch_SB]> as an analogy
* [15:46] <@Andrew[Chair]> Okay, so model with deficiencies to be thought about later.
* [15:47] <@Andrew[Chair]> Did that tie into less trailing PRExxx?
* [15:48] <Tom[Arch_SB]> yes
* [15:49] <@Andrew[Chair]> All right, so for now, PREBOOL will allow a smooth switch over, performance might not improve due to the prexxx trailing issue.
* [15:50] <@Andrew[Chair]> but it will be less to migrate when we integrate more of the formula system.
* [15:50] <Tom[Arch_SB]> It will improve some
* [15:50] <Tom[Arch_SB]> since the system will only solve once not every loop
* [15:50] <Tom[Arch_SB]> just not as dramatic as one might hope for
* [15:50] <Tom[Arch_SB]> need a more dramatic data architecture change to get that
* [15:51] <Tom[Arch_SB]> and you guys need new tools before that is a reasonable request
* [15:51] <@Andrew[Chair]> hm, sounds good, but you do understand how archetypes work right?
* [15:51] <@Andrew[Chair]> when you say "solve once" I don't want to have an issue with things not updating when an archetype is taken
* [15:52] <Tom[Arch_SB]> solve once means solve once
* [15:52] <Tom[Arch_SB]> it "knows" dependencies
* [15:53] <@Andrew[Chair]> Okay, as long as it works. I'm happy. Just jumping on potential issues before we get to converting.
* [15:53] <@Andrew[Chair]> When would you plan on implementing this phase of the Formula System Parser then?
* [15:54] <Tom[Arch_SB]> Need to get the git infrastructure set up first
* [15:54] <Tom[Arch_SB]> James helped me the first part of that a bit ago, but we need to finish that up so I understand the setup
* [15:54] <@Andrew[Chair]> ok
* [15:54] *** Swiftbrook has joined #pcgen
* [15:54] <Tom[Arch_SB]> then it's in a git sandbox anyway and we can figure out what the criteria are for swapping it in
* [15:55] <Tom[Arch_SB]> kind of like we did with FACT/FACTSET
* [15:55] <Tom[Arch_SB]> there is some research required to make sure there aren't nasty issues
* [15:55] <Tom[Arch_SB]> so it may be a slower integration
* [15:55] <@Andrew[Chair]> Sounds like about a month out if not more then
* [15:55] <Tom[Arch_SB]> I don't have a good sense to put a calendar up for it though
* [15:56] <Tom[Arch_SB]> I'd like to have it running in git within a few weeks, then figure it out from there
* [15:56] <Tom[Arch_SB]> I'm not sure I have deep time to invest until mid Feb anyway
* [15:57] <Tom[Arch_SB]> any other ?, I need to duck out at 7
* [15:57] <@Andrew[Chair]> Okay, and I presume the new data tools comment was for finishing up the DSL discussion.
* [15:57] <Tom[Arch_SB]> no
* [15:57] <Tom[Arch_SB]> those are unrelated
* [15:58] <@Andrew[Chair]> New toys then, goodie :) Okay, I've got nothing else to ask. Anyone else in the last minute or so?
* [15:58] <Distant_Scholar> Not me.
* [16:00] <@Andrew[Chair]> Thanks for coming everyone. Meeting adjourned *Bangs gavel*

Building PCGen

2014-12-20T10:32:41Z

James: Update info to reflect move to gradle wrapper

{| align="right"
| __TOC__
|}
=Building PCGen from the command line=

This process uses the [[Gradle]] tool, you need the following software packages:

* Java Development Kit (aka Java SDK or JDK). You should use the latest version (update) of the JDK 6.0 available for download from [http://www.oracle.com/technetwork/java/javase/downloads/index.html here]. At the time of writing this was Java SE 6 Update 45. Java 7 will also work, but no 1.7 specific features should be used in the code just yet. Other JDKs might work, but no one has tried.
* You will also need the latest version of the PCGen source code available from SVN. See [[Subversion Setup]] for details.

Open a command window and change to the root directory/folder where you installed the PCGen source code. There should be a file called build.gradle there.

Type gradlew at the command prompt. This will make sure you have a clean start and then build the pcgen.jar file. You can start pcgen.jar, pcgen.exe or pcgendev.sh to run it or manually run the jar file using a command line like
<pre>java -Xmx1024M -jar pcgen.jar</pre>

To generate the JavaDocs use gradlew javadoc. To run all the tests use gradlew slowtest (which can take a while).

Typing the command <pre>gradlew</pre> will clean the project, build the code and run a small selection of tests.

Typing the command <pre>gradlew slowtest</pre> will build the code and run the full test suite and produce a report.

=Using Eclipse to build PCGen=

You can build PCGen from within Eclipse. It is configured by default to use the gradle dependencies however you will need the "Gradle Integration for Eclipse" plugin which can be installed free from the Eclipse Marketplace.

Once installed, Eclipse will share the jars as specified in build.gradle. You can also accesa gradle tasks from within Eclipse using the "Window > Show View > Other" menu and then selecting "Gradle Tasks".

==Running and debugging==

# Open the PCGen project.
# Open the Run dialog by right-clicking on the PCGen project and selecting Run As > Run Configurations
# Select the Java Application node.
# Press the New button for a new configuration. Edit by field, thus:
Name -> PCGen

Main class -> pcgen.system.Main

VM arguments (Arguments tab) -> -Xmx1024M
# Press Apply to save the configuration.
# Press Run to start PCGen.

You can also run a single test by right clicking on the test and selecting Debug > JUnit Test. This is a great way to track through a bug too.

=Using IDEA to build PCGen=

You can build PCGen from within IntelliJ IDEA. Intellij will recognize the Gradle build for the project and provide access to the tasks.

==Running and debugging==

NB - IDEA will build the software sufficient for running and debugging within the IDE automatically just by following these step. This is not the same as the build from the Building section, above, which builds the software suitable for command-line use.

# Open the PCGen.ipr project file.
# Get the Run/Debug Configurations dialog with Run > Edit Configurations from the menu bar.
# Select the Application tab.
# Press the [+] button for a new configuration. Edit by field, thus:
Name -> PCGen

Main class -> pcgen.system.Main
# Uncheck Display settings before running/debugging.
# Press Ok.

You can now run PCGen with the green right-pointing triangle on the toolbar and debug with the green right-facing beetle on a blue diamond. Or just use the Run menu.

Building PCGen

2014-09-07T07:36:54Z

James: Indicate gradle 2 does not work

{| align="right"
| __TOC__
|}
=Building PCGen from the command line=

This process uses the [[Gradle]] tool, you need the following software packages:

* Java Development Kit (aka Java SDK or JDK). You should use the latest version (update) of the JDK 6.0 available for download from [http://www.oracle.com/technetwork/java/javase/downloads/index.html here]. At the time of writing this was Java SE 6 Update 45. Java 7 will also work, but no 1.7 specific features should be used in the code just yet. Other JDKs might work, but no one has tried.
* Gradle 1.12 (not later - we know Gradle v2 does not work for us) from [http://www.gradle.org/ here]. Gradle is fully cross-platform Java based build tool. See [[Gradle]] section for further details
* You will also need the latest version of the PCGen source code available from SVN. See [[Subversion Setup]] for details.

Open a command window and change to the root directory/folder where you installed the PCGen source code. There should be a file called build.gradle there.

Type gradle at the command prompt. This will make sure you have a clean start and then build the pcgen.jar file. You can start pcgen.jar, pcgen.exe or pcgendev.sh to run it or manually run the jar file using a command line like
<pre>java -Xmx1024M -jar pcgen.jar</pre>

To generate the JavaDocs use gradle javadoc. To run all the tests use gradle slowtest (which can take a while).

Typing the command <pre>gradle</pre> will clean the project, build the code and run a small selection of tests.

Typing the command <pre>gradle slowtest</pre> will build the code and run the full test suite and produce a report.

=Using Eclipse to build PCGen=

You can build PCGen from within Eclipse. It is configured by default to use the gradle dependencies however you will need the "Gradle Integration for Eclipse" plugin which can be installed free from the Eclipse Marketplace.

Once installed, Eclipse will share the jars as specified in build.gradle. You can also acces gradle tasks from within Eclipse using the "Window > Show View > Other" menu and then selecting "Gradle Tasks".

==Running and debugging==

# Open the PCGen project.
# Open the Run dialog by right-clicking on the PCGen project and selecting Run As > Run Configurations
# Select the Java Application node.
# Press the New button for a new configuration. Edit by field, thus:
Name -> PCGen

Main class -> pcgen.system.Main

VM arguments (Arguments tab) -> -Xmx1024M
# Press Apply to save the configuration.
# Press Run to start PCGen.

You can also run a single test by right clicking on the test and selecting Debug > JUnit Test. This is a great way to track through a bug too.

=Using IDEA to build PCGen=

You can build PCGen from within IDEA. You will need to do a little bit of setup first though:
# Go to the Window > Tool Windows > Ant Build. Press the [+] button to add a build file.
# Navigate to and select the build.xml Ant script in the root of the PCGen project tree. Press Ok.

You can now select any Ant target you wish. Particularly helpful are the build and fetch-data targets.

==Running and debugging==

NB - IDEA will build the software sufficient for running and debugging within the IDE automatically just by following these step. This is not the same as the build from the Building section, above, which builds the software suitable for command-line use.

# Open the PCGen.ipr project file.
# Get the Run/Debug Configurations dialog with Run > Edit Configurations from the menu bar.
# Select the Application tab.
# Press the [+] button for a new configuration. Edit by field, thus:
Name -> PCGen

Main class -> pcgen.system.Main
# Uncheck Display settings before running/debugging.
# Press Ok.

You can now run PCGen with the green right-pointing triangle on the toolbar and debug with the green right-facing beetle on a blue diamond. Or just use the Run menu.

Release Instructions

2014-09-05T11:52:07Z

James:

{| align="right"
| __TOC__
|}

==Introduction==

Here are the steps to follow when making a release of PCGen. If it is your first time, please check the prereqs section at the bottom of this page.

==Prerequisites==
The first time you run a release you will have to make sure you have the following tools available:
===Release Notes===
* Text editor
* Web browser
* Perl interpreter
* Perl modules: readonly (installed on Windows via ActivePerl's Perl Package Manager)

===Release===
* Java SDK 1.6 (the one that includes the javac compiler)
* Gradle 1.x
* SVN
* Perl interpreter
* [http://nsis.sourceforge.net/Download NSIS]

===Outstanding Issues===
You need to check JIRA for any outstanding issues to ensure the release meets our QA std.

* Alpha releases require no Blockers, allow Critical only with Code lead exception
* Beta releases require no Blockers or Criticals
* RCs/final releases require no Blockers, Criticals, or Majors

==Create Release Notes==

# Update your local copy of pcgen from SVN
# Copy the previous set of release notes to pcgen-release-notes-nnn.html where nnn is the version number.
# Do a global replace of the old version number to the new version number, both as n.nn.n and nnnn
# Open Jira and for each project open the release notes for the version.
# Copy the html to the changelog section, changing h2 tags to h3.
# Update the What's New section with any high profile changes.
# Update the Thanks section with the list of people who committed during the cycle.
# Commit the new release notes and notify pcgen_bod so they can review it.
# Notify pcgen dev and experimental lists of upcoming release, asking for autobuilds to be tested. Best to give 24 hours notice.

==The Build==
# Using a clean directory with no changes to the pcgen files
# '''svn update''' the PCGen repository (5 mins)
# Release manager edits src/java/pcgen/gui/prop/PCGenProp.properties to set the release date, version number, contributors, etc. and commit the result (5 mins)
# If switching to or from RC mode, edit gradle.properties and adjust the version number to be in the correct format. e.g. 6.4.0RC1 or 6.4.0
# Execute '''gradle clean prepareRelease slowtest''' in the pcgen directory and verify there are no failing Junit test. Also check if there are any "Unknown publisher" messages. If so you need to add new entries for the listed publishers to the gendatalist.pl script. (20 mins)
# Check Jira for any closed requests missing from the release notes. Steps 4 and 6 of 'Create Release Notes' section above can be used to assist here. (10 mins)
# Update the readme.md file with the what's new section of the release notes.
# Execute '''gradle fullZip''' or '''gradle buildNsis''' to generate a testing zip or exe. (3 mins)
# Smoke test the newly built pcgen full zip or exe. (30 mins)
# Create a folder for the release under the [https://sourceforge.net/projects/pcgen/files/ File Manager]
# Upload the release notes using the File Manager to the release folder
# Run '''gradle pcgenRelease''' (which updates the gradlefiles and tags the SVN repository). (2 mins)
# Upload the release files to SourceForge. The quickest way is uploading via the web, the same way you uploaded the release notes etc. (10 mins)
# Update Readme.MD with the SHA256 checksums from target/SHA256-digests.txt. Upload the revised file and check-in. (5 mins)
# Notify PCGen_bod of the new release. (5 mins)
# PR Monkeys create a news item for the new release
# PR Monkeys send announcement to all pcgen mailing list for the new release

==Update JIRA==

For each of the projects, mark the version you are working on as released and create the next version if it doesn't already exist. When marking a version as released, please make sure the released date is set to today.

* [http://jira.pcgen.org/plugins/servlet/project-config/CODE/versions Code Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/DATA/versions Data Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/DOCS/versions Documentation Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/NEWSOURCE/versions New Source Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/NEWTAG/versions New Tag Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/OS/versions Output Sheets Versions]

==Mac Installer==

See [http://pcgen.svn.sourceforge.net/viewvc/pcgen/Trunk/pcgen/installers/mac-installer/instructions.html Instructions]

==Signing Files with PGP==
'''Historical only''' We used to use the [[http://www.gnupg.org/ GnuPG for Windows]] to generate the signatures. You will need the private key, either your own, or the PCGen one (contact the PCGen BOD). Once GnuPG is installed and knows about the key you wish to use, it is just a matter fo right clicking on the files to be signed (multi-select is fine) and selecting GPGee > Sign and then making sure the PCGen key is selected, hitting OK and entering the passphrase for the key. This creates an .asc signature file for each selected file.

==Troubleshooting==
Yes, even the best installs of all the program amount to nothing if there is a hitch. These are basic notes from the current issues cropping up and resolutions. These notes are not prettified yet. The idea being we will get a full set of troubleshooting tips and tricks here in the near future.

Check your versions.
JDK1.5 is required with JAVA_HOME variable (see below)
SVN must be a true .exe install, TortoiseSVN will not meet this requirement
SVN exe can be found here [[http://subversion.tigris.org/files/documents/15/46531/Setup-Subversion-1.6.5.msi SVN]]

My Computer > System > Advanced Settings:
For JAVA_HOME make sure it's a set System Variable and make sure it's using the correct path to your current installation base folder

Code

2014-07-19T21:54:02Z

James: /* Developer Environment */

{| align="right"
| __TOC__
|}

=Introduction=
Welcome to the Wiki section for the Code Monkey team!

=Mission Statement=
'''TBA'''

=Resources=
* [[Developers Meeting]]
* [[Dev Meeting Log 20090429]]
* [[Dev Meeting Log 20090815]]
* [[Dev Meeting Log 20090911]]
* [[Dev Meeting Log 20091017]]
* [[Dev Meeting Log 20091114]]
* [[Dev Meeting Log 20120309]]
* [[Dev Meeting Log 20120429]]
* [[Dev Meeting Log 20121103]]
* [[Dev Meeting Log 20140627]]

==For New Starters==
* [[Joining the Code Team]] General steps to take to prepare yourself
* [[Code Monkey Introduction]]

==Developer Environment==
* [[Basic Developer Setup]]
* [[Subversion Setup]]
* [[Merging]] with SVN
* [[Building PCGen]], also see [[Gradle]]
* [[Continuous Integration]]

==Coding==
* [[Coding Standards]]
* [[Deprecating a Token]]
* [[Explanation of the Code Base]]
* [[PCGen Code Exploration Almanac]]
* [[Graph Theory]]
* [[Logging in the Code Base]]
* [[Unit Testing]]
* [[Removing Libraries]]
* [[Unnecessary Code Detector]]

=Completed Sub Projects=
* [[Ability Object TODO List]]
* [[LST_Editor_Verification]]

=Open Sub Projects=
* [[Internationalization]]
* [[CDOM]]
* [[UI Overhaul]]
* [[LST_Editor]]
* [[Major Code Projects]]
* [[Template Engine]]

=Active Team Members=

===[[Explanation of Teams#Silverback|Silverback]]===
* [[James Dempsey]]

===[[Explanation of Teams#Second|2nd]]===
* TBA

===[[Explanation of Teams#Chimp|Chimp]]===
* [[Tom Parker]]

===[[Explanation of Teams#Gibbon|Gibbon]]===
* Jayme Cox
* [[Stefan Radermacher]]

===[[Explanation of Teams#Tamarin|Tamarin]]===
* [[Andrew Wilson]]
* [[Martijn Verburg]]
* [[Connor Petty]]

===[[Explanation of Teams#Lemur|Lemur]]===
* [[Eddy Anthony]]
* Per Christian Henden
* Thomas Cooper
* [[Tod Milam]] - Mac Developer
* [[Kim Winz]]

===[[X-Terminator Mark II]]===
* [[Greg Bingleman]] - [http://www.codemonkeypublishing.com Code Monkey Publishing]

===Other===
* Brad Stiles, SVN advice
* Jason Buchanan, Advice on old code
* [[Jonas Karlson]], Advice on old code

=Passive Team Members=

* B. K. Oxley (Provides IntelliJ licenses)

=Inactive Team Members=

===[[Explanation_of_Teams#2nd|2nd]]===
* Devon Jones

===[[Explanation_of_Teams#Chimp|Chimp]]===
* Aaron Divinsky

===[[Explanation_of_Teams#Tamarin|Tamarin]]===
* Andriy Sen
* [[Kevin Fernandes]]
* [[Koen Van Daele]]
* [[Joe Frazier, Jr.]]
* Per Christian Henden

===[[Explanation_of_Teams#Lemur|Lemur]]===
* Bill Neumann
* Dan Parks
* [[Eduard Martinescu]]
* Eric Jarman
* Jasper Spaans
* Julio Esslinger Viegas
* Peter Barker
* [[Rick Ryker]]
* Thomas Clegg
* Tony Lavalle
* Hades Lucifer [7/20/10]
* Josh Johnston [7/20/10]
* MotorViper [7/20/10]
* [[Steven West]] [7/20/10]
* [[Alec Ross]] [7/20/10]
* [[Tir Gwaith]] [7/20/10]

===Other===
* [[Andargor]], Suggestions
* [[Bryan McRoberts]], Advice on old code
* Kurt Wimmer, Suggestions
* Walter Duncan, Held the old pcgen_autobuild user

Gradle

2014-07-05T07:32:11Z

James:

{| align="right"
| __TOC__
|}

[[File:Gradle_logo.gif]]

=Introduction=

PCGen is now built using the Gradle build tool.

=Installing Gradle=

See [[http://www.gradle.org/docs/current/userguide/installation.html Gradle Install Guide]] for a tutorial on installing Gradle. It is pretty simple though.

=Main Tasks=

These are the tasks which you are more likely to use everyday. All tasks are run using gradle taskname . If you run gradle without any tasks it will run clean and build by default. Tasks names are not case sensitive.

===clean===

Clean erases all output from previous builds and sets all tasks to be rerun (not up to date).

===build===

Compile PCGen, rebuild the plugin jars, run the fast unit tests and make the pcgen.jar file. Note this also stamps the build with the SVN revision, which can be seen in the PCGen About window.

===slowtest===

Runs the full suite of tests including the character integration tests and the data tests.

===datatest===

Run just the data related tests.

===inttest===

Runs just the character integration tests.

=Useful Tasks=

Here are some of the other tasks which you may wish to use.

===javadoc===

Produce the javadoc.

===allReports===

Produce the code quality reports for the main code only (not the test folders).

===pfinttest===

Runs just the Pathfinder character integration tests.

===fullZip===

Produce the full PCGen zip file as used in the autobuild and the release.

===prepareRelease===

Prepare PCGen for release. This will update and commit the version, do a clean build including the unit tests and generate the data list for the installer.

===pcgenRelease===

Release a new version of PCGen. This will build PCGen, produce the release artifacts, tag the release and then update and commit the version ready for new dev work. The upload to SourceForge is manual though!

File:Gradle logo.gif

2014-07-05T07:29:56Z

James: Gradle logo

Gradle logo

Gradle

2014-07-05T07:29:11Z

James: Created page with "{| align="right" | __TOC__ |} =Introduction= PCGen is now built using the Gradle build tool. =Installing Gradle= See [[http://www.gradle.org/docs/current/userguide/ins..."

{| align="right"
| __TOC__
|}

=Introduction=

PCGen is now built using the Gradle build tool.

=Installing Gradle=

See [[http://www.gradle.org/docs/current/userguide/installation.html Gradle Install Guide]] for a tutorial on installing Gradle. It is pretty simple though.

=Main Tasks=

These are the tasks which you are more likely to use everyday. All tasks are run using gradle taskname . If you run gradle without any tasks it will run clean and build by default. Tasks names are not case sensitive.

===clean===

Clean erases all output from previous builds and sets all tasks to be rerun (not up to date).

===build===

Compile PCGen, rebuild the plugin jars, run the fast unit tests and make the pcgen.jar file. Note this also stamps the build with the SVN revision, which can be seen in the PCGen About window.

===slowtest===

Runs the full suite of tests including the character integration tests and the data tests.

===datatest===

Run just the data related tests.

===inttest===

Runs just the character integration tests.

=Useful Tasks=

Here are some of the other tasks which you may wish to use.

===javadoc===

Produce the javadoc.

===allReports===

Produce the code quality reports for the main code only (not the test folders).

===pfinttest===

Runs just the Pathfinder character integration tests.

===fullZip===

Produce the full PCGen zip file as used in the autobuild and the release.

===prepareRelease===

Prepare PCGen for release. This will update and commit the version, do a clean build including the unit tests and generate the data list for the installer.

===pcgenRelease===

Release a new version of PCGen. This will build PCGen, produce the release artifacts, tag the release and then update and commit the version ready for new dev work. The upload to SourceForge is manual though!

Building PCGen

2014-07-05T06:42:12Z

James: Migrate to the Gradle build

{| align="right"
| __TOC__
|}
=Building PCGen from the command line=

This process uses the [[Gradle]] tool, you need the following software packages:

* Java Development Kit (aka Java SDK or JDK). You should use the latest version (update) of the JDK 6.0 available for download from [http://www.oracle.com/technetwork/java/javase/downloads/index.html here]. At the time of writing this was Java SE 6 Update 45. Java 7 will also work, but no 1.7 specific features should be used in the code just yet. Other JDKs might work, but no one has tried.
* Gradle 1.12 (or later) from [http://www.gradle.org/ here]. Gradle is fully cross-platform Java based build tool. See [[Gradle]] section for further details
* You will also need the latest version of the PCGen source code available from SVN. See [[Subversion Setup]] for details.

Open a command window and change to the root directory/folder where you installed the PCGen source code. There should be a file called build.gradle there.

Type gradle at the command prompt. This will make sure you have a clean start and then build the pcgen.jar file. You can start pcgen.jar, pcgen.exe or pcgendev.sh to run it or manually run the jar file using a command line like
<pre>java -Xmx1024M -jar pcgen.jar</pre>

To generate the JavaDocs use gradle javadoc. To run all the tests use gradle slowtest (which can take a while).

Typing the command <pre>gradle</pre> will clean the project, build the code and run a small selection of tests.

Typing the command <pre>gradle slowtest</pre> will build the code and run the full test suite and produce a report.

=Using Eclipse to build PCGen=

You can build PCGen from within Eclipse. It is configured by default to use the gradle dependencies however you will need the "Gradle Integration for Eclipse" plugin which can be installed free from the Eclipse Marketplace.

Once installed, Eclipse will share the jars as specified in build.gradle. You can also acces gradle tasks from within Eclipse using the "Window > Show View > Other" menu and then selecting "Gradle Tasks".

==Running and debugging==

# Open the PCGen project.
# Open the Run dialog by right-clicking on the PCGen project and selecting Run As > Run Configurations
# Select the Java Application node.
# Press the New button for a new configuration. Edit by field, thus:
Name -> PCGen

Main class -> pcgen.system.Main

VM arguments (Arguments tab) -> -Xmx1024M
# Press Apply to save the configuration.
# Press Run to start PCGen.

You can also run a single test by right clicking on the test and selecting Debug > JUnit Test. This is a great way to track through a bug too.

=Using IDEA to build PCGen=

You can build PCGen from within IDEA. You will need to do a little bit of setup first though:
# Go to the Window > Tool Windows > Ant Build. Press the [+] button to add a build file.
# Navigate to and select the build.xml Ant script in the root of the PCGen project tree. Press Ok.

You can now select any Ant target you wish. Particularly helpful are the build and fetch-data targets.

==Running and debugging==

NB - IDEA will build the software sufficient for running and debugging within the IDE automatically just by following these step. This is not the same as the build from the Building section, above, which builds the software suitable for command-line use.

# Open the PCGen.ipr project file.
# Get the Run/Debug Configurations dialog with Run > Edit Configurations from the menu bar.
# Select the Application tab.
# Press the [+] button for a new configuration. Edit by field, thus:
Name -> PCGen

Main class -> pcgen.system.Main
# Uncheck Display settings before running/debugging.
# Press Ok.

You can now run PCGen with the green right-pointing triangle on the toolbar and debug with the green right-facing beetle on a blue diamond. Or just use the Run menu.

Removing Libraries

2014-07-05T06:20:44Z

James: Update for the new gradle process

{| align="right"
| __TOC__
|}

=Introduction=

From time to time we remove legacy 3rd party libraries. This page lists what you need to do in order to cleanly remove one.

=Steps/Things to Check=

# Edit the build.gradle file to remove the library
# Run through a full build/test cycle
# Commit the updated build.gradle file

Release

2014-07-05T06:17:32Z

James: /* Resources */

{| align="right"
| __TOC__
|}
=Introduction=
Welcome to the Wiki section for the Release team!

=Mission Statement=
'''To put out timely quality releases for the PCGen Project'''

=Resources=
* [[Roadmap]]
* [[Release Instructions]]
* [[Post Release Test]]
* [[Merging]]
* [[Press_Release_Templates]]
* [[Continuous Integration]]
* Old [[Autobuild Config]]
* [[Production Cycle Standards]]

=Active Team Members=

===[[Explanation of Teams#Silverback|Silverback]]===
* [[LegacyKing|Andrew Maitland]]

===[[Explanation of Teams#Second|2nd]]===
* [[James Dempsey]]

===[[Explanation of Teams#Chimp|Chimp]]===
* [[Eddy Anthony]] - Mac Installer

===[[Explanation of Teams#Gibbon|Gibbon]]===
* [[Eric C Smith]] - Mac Installer, OOC Dataset Releases

===[[Explanation of Teams#Tamarin|Tamarin]]===
* [[Tir Gwaith]] - prettylst

===[[Explanation of Teams#Lemur|Lemur]]===
* [[Tod Milam]] - Mac Installer
* Brad Stiles - CDs
* Robert Ward - CDs

===Unix/Linux Installer===

=Inactive Team Members=

===[[Explanation of Teams#Lemur|Lemur]]===
* Edwin C Holley - Windows Installer

===Gencon===
* Theryon Stormrune

Maven Release Process

2014-07-05T06:16:33Z

James: Note that maven use has been retired.

{| align="right"
| __TOC__
|}

=Retirement=

'''The Maven release has now been retired and replaced by Gradle. See [[Release_Instructions]] for how to use the Gradle build to produce a release.'''

=Introduction=

We are proposing to largely automate the release process. This is because it currently takes something like 3 hours to pull together when everything goes right.

=Automated Process=

Once automation with Maven is complete the process will be something like the following.

# Update the pcgen.properties to reflect the new version. Commit this updated version.
# Run @@maven scm:prepare-release@@ to tag the source and update the version info in the maven files.
# Get the next autobuild and regression test it
# If errors are found, branch from the tag made above and fix the issues.
# Once satisfied all is ok, upload the generated release notes document
# Update the notes info for maven
# Run @@maven pcgen:release@@ on a windows machine - this will generate the zip files and the windows installer, and upload them to a new package in SourceForge It will take a little over an hour to process, depending on connection speed.
# Test that the files can be downloaded and run correctly.
# Build and upload the MAC installer
# Make the announcements

=Changes Required to Support Maven=

To get the process automated is going to require a bit of work however. Here are my suggestions on what needs to be done.

* Standardise our SVN layout - '''Done'''
* Rename Trunk to trunk - '''Not required'''
* Rename Tags to tags - '''Done'''
* Rename Branches to branches - '''Done'''
* Simplify the top layer so that we can tag and branch just the pcgen folder - '''N/A'''
* Move the Installer directory up into the pcgen directory - '''Done'''
* Move the Standards folder into the pcgen/code folder - '''Done'''
* Convert the current NSIS script into an XSL script to generate the NSIS script. This is the approach used by maven and should allow us to automate the inclusion of new alpha sources. - '''Done'''
* Code the pcgen:release target to run the necessary steps for a release. - '''Done apart from signing files and creating SF release'''
* Get all monkeys into the habit of recording noteworthy changes in the changes.xml used to generate the release notes. - '''Ongoing'''

MAVEN

2014-07-05T06:14:04Z

James: Maven build retired in favor of gradle.

{| align="right"
| __TOC__
|}

=Introduction=

The maven build has now been replaced by Gradle.

Release Instructions

2014-07-05T06:11:59Z

James: Complete Gradle release process

{| align="right"
| __TOC__
|}

==Introduction==

Here are the steps to follow when making a release of PCGen. If it is your first time, please check the prereqs section at the bottom of this page.

==Prerequisites==
The first time you run a release you will have to make sure you have the following tools available:
===Release Notes===
* Text editor
* Web browser
* Perl interpreter
* Perl modules: readonly (installed on Windows via ActivePerl's Perl Package Manager)

===Release===
* Java SDK 1.6 (the one that includes the javac compiler)
* Gradle 1.x
* SVN
* Perl interpreter
* [http://nsis.sourceforge.net/Download NSIS]

===Outstanding Issues===
You need to check JIRA for any outstanding issues to ensure the release meets our QA std.

* Alpha releases require no Blockers, allow Critical only with Code lead exception
* Beta releases require no Blockers or Criticals
* RCs/final releases require no Blockers, Criticals, or Majors

==Create Release Notes==

# Update your local copy of pcgen from SVN
# Copy the previous set of release notes to pcgen-release-notes-nnn.html where nnn is the version number.
# Do a global replace of the old version number to the new version number, both as n.nn.n and nnnn
# Open Jira and for each project open the release notes for the version.
# Copy the html to the changelog section, changing h2 tags to h3.
# Update the What's New section with any high profile changes.
# Update the Thanks section with the list of people who committed during the cycle.
# Commit the new release notes and notify pcgen_bod so they can review it.
# Notify pcgen dev and experimental lists of upcoming release, asking for autobuilds to be tested. Best to give 24 hours notice.

==The Build==
# Using a clean directory with no changes to the pcgen files
# '''svn update''' the PCGen repository (5 mins)
# Release manager edits src/java/pcgen/gui/prop/PCGenProp.properties to set the release date, version number, contributors, etc. and commit the result (5 mins)
# If switching to or from RC mode, edit gradle.properties and adjust the version number to be in the correct format but with the last number 1 less than the target. e.g. 6.4.0RC0 or 6.4.-1
# Execute '''gradle prepareRelease slowtest''' in the pcgen directory and verify there are no failing Junit test. Also check if there are any "Unknown publisher" messages. If so you need to add new entries for the listed publishers to the gendatalist.pl script. (20 mins)
# Check Jira for any closed requests missing from the release notes. Steps 4 and 6 of 'Create Release Notes' section above can be used to assist here. (10 mins)
# Update the readme.md file with the what's new section of the release notes.
# Execute '''gradle fullZip''' or '''gradle buildNsis''' to generate a testing zip or exe. (3 mins)
# Smoke test the newly built pcgen full zip or exe. (30 mins)
# Create a folder for the release under the [https://sourceforge.net/projects/pcgen/files/ File Manager]
# Upload the release notes using the File Manager to the release folder
# Run '''gradle pcgenRelease''' (which updates the gradlefiles and tags the SVN repository). (2 mins)
# Upload the release files to SourceForge. The quickest way is uploading via the web, the same way you uploaded the release notes etc. (10 mins)
# Update Readme.MD with the SHA256 checksums from target/SHA256-digests.txt. Upload the revised file and check-in. (5 mins)
# Notify PCGen_bod of the new release. (5 mins)
# PR Monkeys create a news item for the new release
# PR Monkeys send announcement to all pcgen mailing list for the new release

==Update JIRA==

For each of the projects, mark the version you are working on as released and create the next version if it doesn't already exist. When marking a version as released, please make sure the released date is set to today.

* [http://jira.pcgen.org/plugins/servlet/project-config/CODE/versions Code Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/DATA/versions Data Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/DOCS/versions Documentation Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/NEWSOURCE/versions New Source Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/NEWTAG/versions New Tag Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/OS/versions Output Sheets Versions]

==Mac Installer==

See [http://pcgen.svn.sourceforge.net/viewvc/pcgen/Trunk/pcgen/installers/mac-installer/instructions.html Instructions]

==Signing Files with PGP==
'''Historical only''' We used to use the [[http://www.gnupg.org/ GnuPG for Windows]] to generate the signatures. You will need the private key, either your own, or the PCGen one (contact the PCGen BOD). Once GnuPG is installed and knows about the key you wish to use, it is just a matter fo right clicking on the files to be signed (multi-select is fine) and selecting GPGee > Sign and then making sure the PCGen key is selected, hitting OK and entering the passphrase for the key. This creates an .asc signature file for each selected file.

==Troubleshooting==
Yes, even the best installs of all the program amount to nothing if there is a hitch. These are basic notes from the current issues cropping up and resolutions. These notes are not prettified yet. The idea being we will get a full set of troubleshooting tips and tricks here in the near future.

Check your versions.
JDK1.5 is required with JAVA_HOME variable (see below)
SVN must be a true .exe install, TortoiseSVN will not meet this requirement
SVN exe can be found here [[http://subversion.tigris.org/files/documents/15/46531/Setup-Subversion-1.6.5.msi SVN]]

My Computer > System > Advanced Settings:
For JAVA_HOME make sure it's a set System Variable and make sure it's using the correct path to your current installation base folder

Dev Meeting Log 20140627

2014-06-28T01:45:33Z

James:

'''Developers Present:'''
* Tom Parker (Arch SB)
* James Dempsey (Code SB)
* Connor Petty (Code UI specialist)
* Andrew Maitland (Content Observer)

'''Discussion Summary:'''
* Tom explained the Current Arch Demo's and ideas he had and how he wanted to implement the changes slowly (FACT/FACTSET/EQVar Demo/Freemarker Patch Demo)
* James and Tom discussed Eclipse pushing Java 7 code into the programming, and will officially change to Java 7 6.5+
* Connor explained the UI Facade and other layers to Tom

'''RAW LOG'''
* [17:00] <Tom[Arch]> I think we'll wait a moment as James should be joining
* [17:01] <Tom[Arch]> Connor have you looked at either the FACT proposal or looked at the EqVarDemo branch?
* [17:01] <cpmeister> I have not looked at the fact proposal yet, but I did look at the EqVarDemo branch.
* [17:03] <@AndrewAAM> http://wiki.pcgen.org/FACT_Token
* [17:03] <@AndrewAAM> http://wiki.pcgen.org/FACTSET_Token
* [17:03] <cpmeister> I can't say I know enough about what the EqVarDemo was trying to accomplish to give much of an opinion about it though.
* [17:04] <@AndrewAAM> EQVar takes the formula system and allows you to use it in containers that don't interact with outside containers
* [17:04] <Tom[Arch]> variables with namespaces, in effect
* [17:04] <@AndrewAAM> That's the dirty summary, Tom can explain it better.
* [17:04] <Tom[Arch]> where each piece of equipment ends up being a separate container/namespace
* [17:05] <Tom[Arch]> I think we'll start and we can catch James up
* [17:05] <cpmeister> fine with me
* [17:06] <Tom[Arch]> So as context, we currently have the facades, which you (Connor) just moved to pcgen.facade, which interact with the UI and the core. There is some additional separation needed from the core, but that's the theory anyway
* [17:06] <Tom[Arch]> Right now, we also have facades that have fixed methods, things like getLegs or whatever
* [17:07] <Tom[Arch]> those are on the RaceFacade, et al
* [17:07] *** James[Code_SB] has joined #pcgen
* [17:07] <cpmeister> Hi James
* [17:07] <Tom[Arch]> The challenge going forward is that the core is getting more and more generic
* [17:07] <Tom[Arch]> Hi James
* [17:07] <@AndrewAAM> (Hi James - Sent you the previous)
* [17:08] <James[Code_SB]> Morning
* [17:08] <Tom[Arch]> So - for example - the Deity's symbol will be something the core knows nothing about
* [17:08] <Tom[Arch]> Right now it has a StringKey.HOLY_ITEM, but even that will go away
* [17:08] <James[Code_SB]> Thanks for that
* [17:08] <Tom[Arch]> as will the individual load token
* [17:08] <Tom[Arch]> FACT will entirely hold the content
* [17:09] <Tom[Arch]> So all the Core will know is that a Deity has a characterisitc called "Symbol" that is "Star" or whatever
* [17:09] <Tom[Arch]> So eventually the facades need to be able to translate to the UI the appropriate items
* [17:09] <Tom[Arch]> and I'd suggest that be in a way that keeps the facades reusable across game modes (so they think generically as well)
* [17:09] <Tom[Arch]> Then only at the final UI (in whatever layer it is - we'll get to that later) knows it needs the "Symbol" Fact
* [17:10] <Tom[Arch]> too high level or good enough?
* [17:10] <Tom[Arch]> We can do a walkthrough if you would like
* [17:10] <cpmeister> I'm understanding it so far.
* [17:11] <James[Code_SB]> That makes sense to me
* [17:11] <Tom[Arch]> So that handles things that are about an object. Symbol, Title, whatever. Things that don't change about an object
* [17:11] <Tom[Arch]> Doesn't cover PC characteristics like Hands
* [17:11] <Tom[Arch]> and obviously doesn't cover lists.... though there is a close cousin for that , FACTLIST
* [17:11] <Tom[Arch]> ERrr FACTSET
* [17:11] <Tom[Arch]> sorry
* [17:12] <Tom[Arch]> Similar theory, but you get a Set of items back rather than one
* [17:12] <Tom[Arch]> So things like components on a spell
* [17:13] <Tom[Arch]> or descriptors on a spell
* [17:13] <Tom[Arch]> would be FACTSET
* [17:13] <Tom[Arch]> (note they can be objects not just strings in both FACT and FACTSET)
* [17:13] <Tom[Arch]> There will be a "database" of sorts where you can go "ask" "What is a Symbol" and it will tell you String.class
* [17:14] <Tom[Arch]> likely relevant for you (Connor) in terms of formatting
* [17:14] <cpmeister> indeed
* [17:15] <Tom[Arch]> I'm working on building a demo for FACT so folks can look at the code. I'm about half done
* [17:15] <Tom[Arch]> That will facilitate seeing how it works in practice
* [17:15] <Tom[Arch]> By the way, I'm expecting those to be 6.5
* [17:15] <Tom[Arch]> So after we branch, I'd like to get them in relatively quick
* [17:16] <Tom[Arch]> That being said, the transition gets tricky, and is part of why we are here
* [17:16] <Tom[Arch]> let's use Deity's Symbol for a moment
* [17:16] <Tom[Arch]> Right now, it's triggered by the SYMBOL token, and the UI eventually pulls (through the facade) StringKey.HOLY_ITEM
* [17:16] <Tom[Arch]> (as to why the token and StringKey are mismatched - not sure)
* [17:17] <Tom[Arch]> If we swap to FACT, we end up being in the position of needing to swap the UI
* [17:17] <Tom[Arch]> but that leaves us in the risk mode of having to swap all the data at once OR having some mechanism for saying "old or new"
* [17:18] <Tom[Arch]> given that swap all at once is effectively ripping out the token for all users, I think we need to at least consider having a control mechanism for pulling from both places
* [17:18] <Tom[Arch]> that make sense to everyone?
* [17:19] <cpmeister> So far yes, do the facts in any way interact with variables?
* [17:20] <Tom[Arch]> immediately, no. Longer term, yes, but probably transparent to you
* [17:20] <Tom[Arch]> Here would be one example:
* [17:21] <Tom[Arch]> MODIFY:SomeVar|SOLVE|value()+if("Star"==fact(deity(),"Symbol"),1,0)
* [17:21] <Tom[Arch]> Please note that is COMPLETELY contrived
* [17:21] <Tom[Arch]> and I'm not sure we'd really do much that way
* [17:21] <Tom[Arch]> but the point is that there will likely be some ability in a formula to test a fact
* [17:23] <Tom[Arch]> good?
* [17:23] <cpmeister> good
* [17:23] <Tom[Arch]> ok
* [17:23] <Tom[Arch]> So roughly the same challenge exists for Variables (either EqVars or global vars in the new variable system)
* [17:24] <Tom[Arch]> Today we do CRITRANGE as a token, but that too can go away in favor of an EqMod
* [17:24] <Tom[Arch]> so we end up with a variable CritRange that needs to be swapped into the UI (though this is likely an item just for Preview, thus you are insulated from it)
* [17:24] <Tom[Arch]> But on a "global" basis, the issue would happen with LEGS for example
* [17:25] <Tom[Arch]> going from fetching from the LegsFacet to having a variable "Legs"
* [17:25] <Tom[Arch]> so we should also be trying to insulate from the facets as their structure/existence will change
* [17:26] <Tom[Arch]> The next trick is a Var isn't only a Number.class
* [17:26] <James[Code_SB]> critrange is definitely in the info for equipment and may be a column too so it is a good example
* [17:26] <Tom[Arch]> ok
* [17:26] <Tom[Arch]> we'll have to do the conversion very slowly to ensure both that
* [17:27] <Tom[Arch]> a) We get a flag somewhere in the UI controls (per game mode)
* [17:27] <Tom[Arch]> b) We can ensure we get the appropriate info to the data team as to what the calculation was in the code
* [17:27] <Tom[Arch]> I've already stressed with Andrew this is going to have to be slow and steady, one at a time
* [17:27] * @AndrewAAM waves
* [17:27] <Tom[Arch]> If we try to rush this will be an epic train wreck
* [17:28] <Tom[Arch]> ok, back to not only a number
* [17:28] <Tom[Arch]> same rules as Fact, there is a database that can tell you what it is, so Legs would return Number.class
* [17:29] <Tom[Arch]> Note we are using Number.class not Double or Float or Integer, as we do "arbitrary precision" arithmetic
* [17:29] <Tom[Arch]> where "arbitrary" here means "Integer if we can"
* [17:29] <Tom[Arch]> we dont' drop into BigDecimal or anything like that
* [17:29] <Tom[Arch]> that way 2-1 is always 1 not .999999999
* [17:30] <Tom[Arch]> So we can also do things like "Point" as a type. In the case of the EqVarDemo it's actually a custom class GridPoint
* [17:30] <Tom[Arch]> it is used to store what is today FACE
* [17:30] <Tom[Arch]> and that is actually "hard coded" in the token as a demo of both global variables in the new system as well as being able to modify a non-Number in the variable system
* [17:31] <Tom[Arch]> There isn't any reason why a variable couldn't be a String as well if there is a character-wide item that we need as a single fact (*cough* Region *cough*)
* [17:31] <Tom[Arch]> I shouldn't say fact
* [17:31] <Tom[Arch]> too confusing
* [17:31] <Tom[Arch]> Character wide characteristic
* [17:32] <Tom[Arch]> any questions?
* [17:33] <Tom[Arch]> seem fairly straightforward to deal with?
* [17:33] <James[Code_SB]> I wouldn't go quite that far :)
* [17:33] <Tom[Arch]> LOL
* [17:34] <James[Code_SB]> I think you've noted some interesting challenges for the UI - this is really driving the move away from a d20 focussed UI, much as the output system is going the same way
* [17:34] *** cpmeister has quit IRC: Changing host
* [17:34] *** cpmeister has joined #pcgen
* [17:34] <Tom[Arch]> it is
* [17:35] <Tom[Arch]> but at the end of the day the UI still has a tie to the game mode
* [17:35] <Tom[Arch]> so we may end up with panes being named and defined in the game mode or some such
* [17:35] <James[Code_SB]> and it changes the 'perspective' of PCGen quite a lot - a good thing but a change in mind set
* [17:35] <James[Code_SB]> indeed
* [17:35] <Tom[Arch]> My big point here is hoping we make the facades generic and only have to work with the UI
* [17:35] <James[Code_SB]> They are to a minor extent now, but I know the data team would like to have a lot more control
* [17:35] <James[Code_SB]> right
* [17:35] <Tom[Arch]> and at that, I think it will only be a portion of the UI
* [17:36] <Tom[Arch]> but that's for Connor to explain more. (Hopefully we get to the UI layers today as well as I'd like to understand that)
* [17:36] <James[Code_SB]> whereas now, the facades are where a lot of messy game knowledge lives
* [17:36] <Tom[Arch]> yea, some of that we can clean up with this, some is harder
* [17:37] <cpmeister> I think if we want to keep the facades intact in any reasonable way there might need to be different facade implementations for each game mode
* [17:37] <Tom[Arch]> that's part of why I asked for a selection deep dive on user experience
* [17:37] <Tom[Arch]> What would bind them to a game mode?
* [17:38] <cpmeister> I imagine the end goal is for facts to become completely arbitrary but only consistent within game modes
* [17:38] <Tom[Arch]> correct
* [17:39] <cpmeister> So the facades implementations that depend on facts cannot be relied upon to work for all game modes
* [17:39] <Tom[Arch]> It depends on the design
* [17:39] <Tom[Arch]> Let's use Symbol as the example
* [17:40] <Tom[Arch]> If you make DeityFacade have a getSymbol() then yes, you're stuck to the game mode
* [17:40] <Tom[Arch]> I'm not sure that's how I would do it
* [17:40] <Tom[Arch]> if you have public T getFact(String s, Class<T> cl)
* [17:40] <Tom[Arch]> there is no tie to the game mode
* [17:40] <Tom[Arch]> and the only tie is the place where the info is presented/what knows it is displaying a String (or whatever)
* [17:41] <Tom[Arch]> it localizes the game mode knowledge
* [17:41] <cpmeister> But there IS a tie to a fact name. :)
* [17:41] <Tom[Arch]> eventually there HAS to be
* [17:41] <Tom[Arch]> of course
* [17:41] <Tom[Arch]> but I would put that in the code that constructs the UI
* [17:41] <Tom[Arch]> since by its nature it has to be game mode specific already
* [17:42] <Tom[Arch]> because you have to have a field to show it and set the field location et al
* [17:42] <Tom[Arch]> might as well set the fact name there too
* [17:43] <Tom[Arch]> Maybe this is a good point for you to explain the layers of the UI
* [17:43] <Tom[Arch]> that way we all have that context
* [17:43] <cpmeister> What purpose would the facade layer serve if the facades cannot be tied to the facts?
* [17:44] <cpmeister> (I'll get to the UI layers in a moment)
* [17:44] <Tom[Arch]> in the case of facts, very little
* [17:44] <Tom[Arch]> in the case of vars, lists and other things, insulating you from facades
* [17:44] <Tom[Arch]> Have you looked at the output demo I posted to JIRA?
* [17:45] <cpmeister> Unfortunately no, I've been preoccupied with real life the past few weeks
* [17:46] <Tom[Arch]> no problem. That may be an interesting thing to look at
* [17:46] <cpmeister> Could you send me a link?
* [17:46] <Tom[Arch]> http://jira.pcgen.org/browse/CODE-2619
* [17:46] <Tom[Arch]> it's a very generic facade (bordering on a shim) between the core and FreeMarker
* [17:47] <Tom[Arch]> I would view the UI facade acting in a similar way
* [17:47] <Tom[Arch]> and the patch is no longer Java7 specific (thanks for pointing that out James, I completely missed that I used a J7 feature)
* [17:48] <James[Code_SB]> Eclipse just quietly does it for you I've noticed recently
* [17:48] <James[Code_SB]> and it is rather nice
* [17:48] <Tom[Arch]> very convenient, we just eventually need to decide to drop J6 officially rather than do it accidentally
* [17:49] <Tom[Arch]> but that's quite a tangent
* [17:49] <Tom[Arch]> Perhaps time for UI layers? ... and you can look at the Output system later Connor. This was as much to be informative vs trying to settle everything in one shot
* [17:49] <James[Code_SB]> Yeah I'd like 6.4 to be the last Java 6 compatible release - it is getting too hard to maintain compatibility now
* [17:50] <cpmeister> sure thing Tom
* [17:50] <cpmeister> Basically the UI is separated into a views and models
* [17:51] <cpmeister> The views are the swing UI components that render to the screen and the models are the data that populates the components
* [17:52] <cpmeister> I've maintained a strict separation between these two layers such that only the models handle CharacterFacade instances
* [17:53] <cpmeister> Everytime a character is created and shown to the screen the UI models are created and listeners attached to the character
* [17:54] <cpmeister> Each character has its own set of models and each model is explicitly installed and uninstalled from the views
* [17:56] <cpmeister> (sorry, just a sec)
* [17:59] <cpmeister> One advantage of explicitly installing and uninstalling models is that switching between character can be made very fast.
* [18:00] <cpmeister> The UI currently switches models in tabs an arbitrary order to make tab switching appear faster
* [18:01] <Tom[Arch]> below character model, how do things work for single objects like Deity or Race
* [18:01] <Tom[Arch]> and how does it work for info on those things?
* [18:02] <cpmeister> Could you clarify?
* [18:02] <Tom[Arch]> Let's stay at Deity for a moment
* [18:03] <Tom[Arch]> So CharacterFacade can give you...an ItemFacade or some such
* [18:03] <Tom[Arch]> that is the model?
* [18:03] <Tom[Arch]> ItemFacade<DeityFacade> specifically I think?
* [18:03] <Tom[Arch]> (assuming I have the first class right)
* [18:03] <James[Code_SB]> Two targets to consider here - the deity the character has selected and the list of all deities
* [18:03] <Tom[Arch]> yes, I'm on the PC info at the moment
* [18:04] <Tom[Arch]> the latter being game mode info, but yes, good point that there are two deity related items
* [18:05] <James[Code_SB]> public ReferenceFacade<DeityFacade> getDeityRef()
* [18:05] <Tom[Arch]> so ReferenceFacade not ItemFacade
* [18:05] <James[Code_SB]> yep
* [18:05] <Tom[Arch]> k ty
* [18:05] <Tom[Arch]> but that is effectively a model?
* [18:05] <James[Code_SB]> which allows the UI to be notified when it changes and not have to poll
* [18:05] <Tom[Arch]> which is loaded into some view (field) somewhere presumably
* [18:06] <Tom[Arch]> right, so the CharacterFacade owns it as writeable, and shares a readable version to the view
* [18:06] <James[Code_SB]> yes
* [18:06] <cpmeister> The models mearly serve as the adapter classes for the facades.
* [18:07] <James[Code_SB]> Not sure I follow Connor
* [18:07] <cpmeister> Most all of the model logic is delegated to the facade layer
* [18:07] <Tom[Arch]> not sure I'm following
* [18:07] <Tom[Arch]> is the ReferenceFacade a model in this case?
* [18:07] <cpmeister> :/
* [18:07] <cpmeister> referencefacade is part of the facade layer
* [18:08] <cpmeister> The models attach listeners to the reference facades and propagate events to the views
* [18:08] <Tom[Arch]> so in showing the actively selected deity by a PC what is the model
* [18:09] <Tom[Arch]> looking at CharacterComboBoxModel
* [18:09] <Tom[Arch]> (found one)
* [18:09] <cpmeister> the model would listen to the ReferenceFacade<DeityFacade> and change the contents of the UI's diety field when an event occurs
* [18:10] *** ckwalsh has quit IRC: Read error: Connection reset by peer
* [18:11] <cpmeister> Since the views are event based, the only task the models have is to implement a swing model propogate events through the swing layer
* [18:11] <cpmeister> *and propogate
* [18:11] <Tom[Arch]> So because the view in this case is a picklist, we need to have a model that combines both the game mode info (all Deities) with the PC info (the ReferenceFacade we were talking about), so that is why the *facades shouldn't be models themselves
* [18:11] <cpmeister> correct
* [18:12] <Tom[Arch]> the referencefacade is the underlying container for the PC, which the model listens to et al to be event based and the view draws stuff
* [18:12] <cpmeister> bingo
* [18:12] <Tom[Arch]> model or facade owns sorting when you have a list?
* [18:13] <cpmeister> the views own the sorting
* [18:13] <cpmeister> sometimes we use a sorted list facade instead
* [18:13] <cpmeister> it depends on the situation
* [18:14] <cpmeister> when displaying a strict list of items, the sorting would occur in a delgating list facade.
* [18:14] <Tom[Arch]> when you say view owns the sorting, does the view actually tell the model what to do and the model actually has the data?
* [18:15] <Tom[Arch]> or does the model then tell the facade to sort as well?
* [18:15] <Tom[Arch]> or does the view have a separate list from the model?
* [18:15] <cpmeister> For tables, swing models are internally wrapped in another swing model so that sorting can be handled transparently to the original model
* [18:16] <Tom[Arch]> so the facades and the model are both basically unaware of display
* [18:16] <cpmeister> for tables yes
* [18:16] <Tom[Arch]> meaning sorting of the display in this case
* [18:16] <Tom[Arch]> for non-dynamic stuff like a picklist you would use the sorted facade?
* [18:16] <cpmeister> yes
* [18:16] <Tom[Arch]> ok
* [18:17] <cpmeister> unless we display the picklist with a table, in which case no
* [18:17] <cpmeister> though we could sort the data before handing it to the table but that becomes useless redundancy
* [18:17] <Tom[Arch]> right, you'll display race different ways in two places since you have the picklist on the general screen which is controlled by a sorted list, but once in the table on the Race tab, the Race tab needs to dominate
* [18:17] <Tom[Arch]> that's actually good because it keeps the picklist from having to fight with the Race Tab
* [18:18] <cpmeister> making sense?
* [18:18] <Tom[Arch]> yes
* [18:19] <Tom[Arch]> so on the sorting discussion we had it's really tables where we can't (shouldn't) help
* [18:19] <cpmeister> yes
* [18:19] <Tom[Arch]> but the static lists are potentially reusable (give or take whether it makes sense to really share)
* [18:20] <cpmeister> for the most part yes, but if the static list needs to be displayed outside of a table it will likely be wrapped in a sorting list facade by the model
* [18:20] <Tom[Arch]> for now that's sensible - defensive programming and all that
* [18:21] <Tom[Arch]> need a lot more polishing in many places to break that assumption
* [18:21] <cpmeister> any other questions? I need to take off soon.
* [18:22] <Tom[Arch]> I need to run as well, already 6 min past when I should have left :/
* [18:22] <Tom[Arch]> I think I'm good for now
* [18:22] <Tom[Arch]> thanks for the discussion
* [18:22] <cpmeister> no problem :)
* [18:23] <James[Code_SB]> Thanks have a good evening guys
* [18:23] <Tom[Arch]> thanks all
* [18:23] <cpmeister> have a nice day everyone!

'''END OF LOG'''

FACT Token

2014-06-21T22:17:45Z

James:

{| align="right"
| __TOC__
|}

=Purpose=

This proposal covers a means for the data to declare named constants for rules objects (e.g deity) that have values provided by the data and that are fixed at data load time. The proposal covers a number of tokens and is the first in a set of proposals to disconnect the code from the specific underlying game mode.

The core of the proposal is a "FACT" token that allows the data team to specify specific items (with normal LST file support like .CLEAR making it usable in .COPY and .MOD lines)

=Status=

This is a draft proposal for architecture/code review. Syntax is not final and is subject to revision and limitations due to existing syntax which may not be apparent in this proposal.

=Scope=

This proposal is intended to cover factual information about a single object applied to a PC.

"About the _object_" is key.

This means it is not intended to cover the number of LEGS a PC has (that is a fact ABOUT the _PC_ that the objects can alter, we are ONLY covering facts about the _object itself_). It is intended to cover things like the Symbol of a Deity (a "fact" about that Deity that doesn't alter the PC)

In order to maintain the semantic definition of "fact", items here will be unmodifiable at runtime. If the intent is to modify an object, that is semantically a variable, and is outside the scope of this proposal.

Note for clarity: This modification statement is "unmodifiable at runtime", which means the lock occurs when LST load completes. They CAN be overwritten in a .MOD.

The distinction between "fact" and "variable" is significant. This is *intended* to cover a *limited* set of information, and support features *based upon* those limitations. Data is exchanging limitations for power, as seen below.

There will be future capabilities that are more flexible (and can be changed at runtime) but which will support a different (more limited) subset of features. That is out of scope of this proposal, however.

=Background=

Currently when new items are added to objects, it ends up requiring code intervention.

This has a number of unfortunate side effects:
* This gets stuck in a priority queue along with a lot of other work for the code team
* It binds the code tightly to the game mode (who says a PC has legs?)
* It often creates yet another PRExxx token to handle that item (PREDEITYALIGN, etc)
* It sometimes comes back as a request for a Primitive for use in CHOOSE

In order to get away from this tight binding, we need a more generic way of dealing with information in the data.

In addition to the work already done in the token/loader system and in the core, the final puzzle piece that enables this capability was the insertion of Freemarker as the output/template system.

Specifically, as we get to 6.5, we will be enabling a different system for output based on Freemarker rather than on the existing output tokens. (see https://groups.yahoo.com/neo/groups/pcgen_developers/conversations/messages/4165 )

This will enable more data control over what is output without relying on core knowledge.

=Proposal=

==Base Token (FACT)==

FACT:x|y
x is an identifier
y is the factual value

An identifier (x above) must have been defined in a FACTDEF line in a DATACONTROL LST file.

FACT by default overwrites.

It will be slowly, but consciously applied until it is eventually a global capability.

It is NOT like ASPECT, it does NOT support PRExxx (if the item is changing, then semantically it is NOT a fact - see "Background" above)

e.g. a Deity might have:

FACT:SYMBOL|Star

.CLEAR will be supported as a "y" value, and it will clear just the fact for the single identifier.

==PCC (Campaign) LST token (DATACONTROL)==

In order to make useful work of a FACT, we require a few things. One of these is a set of controls for how the FACT is used. This requires a Campaign LST file token in order to store those controls:

DATACONTROL:x

x is a file (as per other files in the Campaign LST file)

==Data Control LST Contents==

===First Token (FACTDEF)===

The Data Control LST file controls how facts (and in the future other things) are handled by the code. Specifically, we can have a line define legal facts:

FACTDEF:x|y|z <> ...tokens...
x is a file type (e.g. DEITY for Deity LST files)
y is the identifier type (STRING, etc.)
z is the identifier (then usable as x in the FACT LST token)

This token MUST appear as the first token on the line in the file.

A Second FACTDEF with matching X, z but different y will produce an error, since you have two conflicting items with the same identifier.

Duplicate FACTDEF with matching x, y, z are legal (thus allowing it to be present in multiple sources), but other tokens on the line are CUMULATIVE (dupe entries even in different files ACT LIKE A MOD)

Note: The "y" Items will be hardcoded. In addition to "STRING", the same items that are valid as the [http://pcgen.org/autobuilds/pcgen-docs/listfilepages/globalfilestagpages/globalfilesother.html#QUALIFY "x" value of QUALIFY] (the existing Global token) would also be legal here.

===VISIBLE===

For any given FACTDEF, we can control how that FACT is used. This allows us to make it visible to the end user, or display in output.

VISIBLE:x

x is:
YES
NO (default is NO)
DISPLAY
EXPORT

For example:
FACTDEF:DEITY|STRING|Symbol <> VISIBLE:EXPORT

EXPORT or YES would enable the output in Freemarker:

${deity.symbol}

(which would produce an error if VISIBLE:NO or VISIBLE:DISPLAY)

EXPORT or YES or will trigger display in the UI, specifically in the items about the object, in Gui2InfoDisplay (code will know the meaning of this)

In case of .MOD (see FACTDEF for multiple definitions acting as a .MOD) this overwrites

===SELECTABLE===

For any given FACTDEF, we can control how that FACT is used. This allows us to make it usable in CHOOSE or other locations where a Primitive is legal:

SELECTABLE:

x is:
YES
NO (default is NO)

For example:
FACTDEF:DEITY|ALIGNMENT|Align <> VISIBLE:YES <> SELECTABLE:YES

SELECTABLE:YES enables use in a CHOOSE:

CHOOSE:DEITY|ALIGN=LG

Given the above FACTDEF, this would allow a choice of any Deity with the 'ALIGN' FACT set to 'LG' (this emulates the ALIGN= item we have in CHOOSE:DEITY today)

(It would produce an error if the FACTDEF for ALIGN was SELECTABLE:NO)

In case of .MOD (see FACTDEF for multiple definitions acting as a .MOD) this overwrites

===REQUIRED===

For any given FACTDEF, we can make that FACT requried for a certain type of object.

REQUIRED:x

x is:
YES
NO (default is NO)

For example:
FACTDEF:DEITY|ALIGNMENT|Align <> VISIBLE:YES <> REQUIRED:YES

This would then trigger an LST load error if a Deity did not have the "ALIGN" Fact assigned.

In case of .MOD (see FACTDEF for multiple definitions acting as a .MOD) this overwrites

As caution to the data team: Use of this forces it across ALL loaded data, NOT JUST DATA FROM THE LOCAL PCC FILE. That likely means this is used sparingly, and only in base sets, otherwise the additional sets would have to .MOD a lot of stuff...

===DISPLAYNAME===

For any given FACTDEF, we can control the name displayed for that type of item in the UI

DISPLAYNAME:x

x is a String (used to describe this fact in the UI)

Intent is that this is used to describe the object and is the string that will be displayed in the UI

In case of .MOD (see FACTDEF for multiple definitions acting as a .MOD) this overwrites

===EXPLANATION===

For any given FACTDEF, we can explain the purpose it serves in the data

EXPLANATION:x

x is a String

Intent is this is used to describe what the object is for purposes of the LST editor or readers of the data

In case of .MOD (see FACTDEF for multiple definitions acting as a .MOD) this overwrites

==Global PREFACT==

Of course, being able to define a FACT also demands something like:

PREFACT:w,x,y=z
w is a number
x is the type (e.g. DEITY) - matches the types defined for FACTDEF
y is the identifier (e.g. SYMBOL)
z is the required value

For example:
PREFACT:1,DEITY,SYMBOL=Star

=Code Team Awareness=

==Generic behavior==

This is designed to provide generic behavior to get us "out of the business" of dealing with minor token requests. There are actually dozens of "facts" about Equipment that have been requested for MSRD and this proposal would replace MANY of the existing NEWTAG proposals, and do it with less code (and without risk of copy/paste error)

==Caching==

One of the weaknesses we have in our existing Primitive system is multiple construction and caching. Let's take something like this in the data:

CHOOSE:DEITY|ALIGN=LG

If this appears twice, then the unfortunate part is that we create two Deity ALIGN Primitives. This is wasteful, albeit minor.

The challenge is that we also want to ensure that we don't have to redo work. So if we had that CHOOSE twice, we would want to cache that information. With multiple primitives that is not possible. With a centralized PrimitiveFactory (or whatever) it becomes practical to build the Primitive once, and then that Primitive can itself cache results.

However, a cache is only practical if the underlying information cannot change. (If it can change, it's both not a fact, and not cacheable)

This provides a generic method of dealing with facts that ensures those facts *do not change*, thus any infrastructure we build can be cacheable (and we can automatically build that infrastructure)

=Challenges=

==Capitalization==

Frankly this is a bear. Currently we import LST files in case-insensitive form (technically all caps), but Freemarker output is case sensitive. So the conversion of Symbol (or however it appears in the FACTDEF) to .symbol in the output is a convention we have to agree upon:
* Freemarker is always in lower case for a FACT:
* We enforce an identifier to appear in all caps (not strictly required, so perhaps this is a data standard)

==Localization==

Currently Gui2InfoFactory uses internationalized strings to identify each item (e.g. Symbol). In order to "unhardcode" Gui2InfoFactory, we need to put that into the FACTDEF line as well, but that raises the "localization in data" debate.

Release Instructions

2014-06-17T12:20:59Z

James: Initial gradle scirpt

{| align="right"
| __TOC__
|}

==Introduction==

Here are the steps to follow when making a release of PCGen. If it is your first time, please check the prereqs section at the bottom of this page.

==Prerequisites==
The first time you run a release you will have to make sure you have the following tools available:
===Release Notes===
* Text editor
* Web browser
* Perl interpreter
* Perl modules: readonly (installed on Windows via ActivePerl's Perl Package Manager)

===Release===
* Java SDK 1.6 (the one that includes the javac compiler)
* Gradle 1.x
* Perl interpreter
* SVN
* [http://nsis.sourceforge.net/Download NSIS]

===Outstanding Issues===
You need to check JIRA for any outstanding issues to ensure the release meets our QA std.

* Alpha releases require no Blockers, allow Critical only with Code lead exception
* Beta releases require no Blockers or Criticals
* RCs/final releases require no Blockers, Criticals, or Majors

==Create Release Notes==

# Update your local copy of pcgen from SVN
# Copy the previous set of release notes to pcgen-release-notes-nnn.html where nnn is the version number.
# Do a global replace of the old version number to the new version number, both as n.nn.n and nnnn
# Open Jira and for each project open the release notes for the version.
# Copy the html to the changelog section, changing h2 tags to h3.
# Update the What's New section with any high profile changes.
# Commit the new release notes and notify pcgen_bod so they can review it.
# Notify pcgen dev and experimental lists of upcoming release, asking for autobuilds to be tested. Best to give 24 hours notice.

==The Build==
# Using a clean directory with no changes to the pcgen files
# '''svn update''' the PCGen repository (5 mins)
# Release manager edits src/java/pcgen/gui/prop/PCGenProp.properties to set the release date, version number, contributors, etc. and commit the result (5 mins)
# Execute '''gradle clean build slowtest''' in the pcgen directory and verify there are no failing Junit test (20 mins)
# Check Jira for any closed requests missing from the release notes. Steps 4 and 6 of 'Create Release Notes' section above can be used to assist here. (10 mins)
# Update the readme.md file with the what's new section of the release notes.
# Execute '''gradle genDataList''' and check if there are any "Unknown publisher" messages. If so you need to add new entries for the listed publishers to the gendatalist.pl script.(1 min1)
# Execute '''gradle fullZip''' or '''gradle buildNsis''' to generate a testing zip or exe. (3 mins)
# Smoke test the newly built pcgen full zip or exe. (30 mins)
# Create a folder for the release under the [https://sourceforge.net/projects/pcgen/files/ File Manager]
# Upload the release notes using the File Manager to the release folder
# '''needs updating>>''' Run '''gradle release''' (which updates the gradlefiles and tags the SVN repository). Tag format is '''release-5.17.x''' while the version format is '''5.17.x''' (2 mins)
# Run '''gradle checksum''' to generate the release files. (5 mins)
# Upload the release files to SourceForge. The quickest way is uploading via the web, the same way you uploaded the release notes etc. (10 mins)
# Update Readme.MD with the SHA256 checksums from target/SHA256-digests.txt. Upload the revised file and check-in. (5 mins)
# Notify PCGen_bod of the new release. (5 mins)
# PR Monkeys create a news item for the new release
# PR Monkeys send announcement to all pcgen mailing list for the new release

==Update JIRA==

For each of the projects, mark the version you are working on as released and create the next version if it doesn't already exist. When marking a version as released, please make sure the released date is set to today.

* [http://jira.pcgen.org/plugins/servlet/project-config/CODE/versions Code Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/DATA/versions Data Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/DOCS/versions Documentation Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/NEWSOURCE/versions New Source Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/NEWTAG/versions New Tag Versions]
* [http://jira.pcgen.org/plugins/servlet/project-config/OS/versions Output Sheets Versions]

==Mac Installer==

See [http://pcgen.svn.sourceforge.net/viewvc/pcgen/Trunk/pcgen/installers/mac-installer/instructions.html Instructions]

==Signing Files with PGP==
'''Historical only''' We used to use the [[http://www.gnupg.org/ GnuPG for Windows]] to generate the signatures. You will need the private key, either your own, or the PCGen one (contact the PCGen BOD). Once GnuPG is installed and knows about the key you wish to use, it is just a matter fo right clicking on the files to be signed (multi-select is fine) and selecting GPGee > Sign and then making sure the PCGen key is selected, hitting OK and entering the passphrase for the key. This creates an .asc signature file for each selected file.

==Troubleshooting==
Yes, even the best installs of all the program amount to nothing if there is a hitch. These are basic notes from the current issues cropping up and resolutions. These notes are not prettified yet. The idea being we will get a full set of troubleshooting tips and tricks here in the near future.

Check your versions.
JDK1.5 is required with JAVA_HOME variable (see below)
SVN must be a true .exe install, TortoiseSVN will not meet this requirement
SVN exe can be found here [[http://subversion.tigris.org/files/documents/15/46531/Setup-Subversion-1.6.5.msi SVN]]

My Computer > System > Advanced Settings:
For JAVA_HOME make sure it's a set System Variable and make sure it's using the correct path to your current installation base folder

Template Engine

2014-02-22T04:26:50Z

James: Add doco for equipsetloop directive

{| align="right"
| __TOC__
|}
== Template Engine Sub Project ==

The aim of the project is to examine the Freemarker library with a view to using it to replace our export engine. In particular it would cover functionality logic functions like looping and if tests. This would leave our code to deal with the important things like TO HIT values etc.

We would do this in three phases:
# Add support for Freemarker templates for output
# Once sufficient sheets have been converted/rewritten, deprecate support for old sheet types
# Finally after a few releases, remove support for the old sheet types.

There are a few reasons for exploring this change
* Add a richer set of logic commands to enable more customisable output
* Simpler more consistent logic commands and more widely understood syntax
* Remove one of the more complex and difficult to maintain sections of the PCGen code base.

== Status ==

Currently working on phase 1.

FreeMarker support has been added to PCGen and is available in the [http://pcgen.org/autobuilds/ trunk autobuilds]. It will first be available in the 6.03.00 alpha release scheduled for February 2014.

Progress is being tracked in [http://jira.pcgen.org/browse/CODE-2418 CODE-2418 FreeMarker Output Generation - Phase 1]

== FreeMarker Template How-To ==

=== Introduction to FreeMarker ===

[http://freemarker.org/ FreeMarker] is a template engine that has now been incorporated into PCGen's export system as an alternative to our venerable export syntax. The FreeMarker engine brings some important benefits:
* Industry standard syntax
* Support for macros to output parameterised blocks
* Improved flow-control and logic instructions
* Support for including other files, e.g. macro libraries or common blocks
* Calculations and state within the output template
* Built-in syntax support in [http://freemarker.org/editors.html many text editors]

Here's a simple example FreeMarker PCGen template
<nowiki>

<h1>Freemarker Sheet for <@pcstring tag="NAME"/> - ${.now?date}</h1>

 Character Name: <@pcstring tag="NAME"/> 
 Player Name: <@pcstring tag="PLAYERNAME"/> 

 Fighter: ${pcvar("CL=Fighter")} 
 Rogue: ${pcvar("CL=Rogue")} 

<@loop from=0 to=pcvar('countdistinct("CLASSES")')-1 ; class , class_has_next >
<@pcstring tag="CLASSABB.${class}"/> <#t>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if><#t>
</@loop></nowiki>

which produces the output
<nowiki>

<h1>Freemarker Sheet for Ronald 'Surefingers' Millbridge - 29/10/2013</h1>

 Character Name: Ronald 'Surefingers' Millbridge 
 Player Name: James 

 Fighter: 0 
 Rogue: 11 

Rog 11,Wiz 2</nowiki>

=== FreeMarker Documentation ===

FreeMarker has quite thorough documentation. The main references output sheet authors will use are:
# [http://freemarker.org/docs/dgui.html Template Author's Guide]
# [http://freemarker.org/docs/ref.html Reference Guide]
# [http://freemarker.org/ Main FreeMarker page]

In addition, see testsuite/base-xml.ftl for a fully worked example of xml output.

=== Creating a Sheet ===

FreeMarker sheets are detected by PCGen by their file name suffix. A template ending in .ftl will be processed by FreeMarker rather than by PCGen's legacy output engine. The extension of the file to be produced should be immediately before that and preceded by a . or -. So a template to produce html output might be named csheet-first.html.ftl or chseet-compact-html.ftl and PCGen would pick up that it was a template to be processed by FreeMarker template that would produce output of a html file.

=== PCGen's Custom Functions ===

To provide output of PCGen characters we need to be able to access the character data and the output tags. The following tags are provided for that purpose.

==== pcstring ====

This tag evaluates a PCGen export token for the current character and returns the value as a string. It may be called as a directive (with a single parameter named 'tag') or as a function (with a single unnamed parameter).

''Examples''
<nowiki>
<@pcstring tag="PLAYERNAME"/>
<@pcstring tag="CLASSABB.${class}"/>
${pcstring('CLASSABB.${class}')}
<#if (pcstring('SPELLLISTCLASS.${class}')?length > 0)>present</#if></nowiki>

==== pcvar ====

This tag allows character variable values to be exported to a FreeMarker template. It evaluates a variable for the current character and returns the value as a number.

''Examples''
<nowiki>
<#assign numClasses=pcvar('countdistinct("CLASSES")')/>
${pcvar('count("ABILITIES","CATEGORY=FEAT","TYPE=Metamagic","VISIBILITY=DEFAULT[or]VISIBILITY=OUTPUT_ONLY")')}
${pcvar("CL=Fighter")}
</nowiki>

==== pcboolean ====

pcboolean allows character boolean values to be exported to a FreeMarker template. It evaluates an export token for the current character and returns the value as a boolean.

''Examples''
<nowiki>
<#if pcboolean('WEAPON.${weap}.ISTYPE.Double')>
<#if (pcboolean('HASVAR:Manifester.OR.HASVAR:PsychicWarriorManifester')) ></nowiki>

==== loop ====

The loop tag provides a way to repeat content a certain number of times. Unlike the inbuilt list directive it can loop zero times.

'''Parameters'''

* from (optional) - The starting value, defaults to 0.
* to - The ending value (inclusive). If this is less than from then the contents will not be output.
* step (optional) - The amount to increment b each loop, defaults to 1.

In addition up to two loopvars may be specified. The first will be populated with the current index value of the loop and the second will be a boolean indicating if there are more iterations of the loop to go. We recommend that the second variable, if present, is named after the first variable with _has_next added. e.g. class, class_has_next . This is in order to match the list directive, which provides a similarly named variable automatically.

''Example''
<nowiki>
<@loop from=0 to=pcvar('countdistinct("CLASSES")')-1 ; class , class_has_next >
<@pcstring tag="CLASSABB.${class}"/>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if>
</@loop></nowiki>
might produce
<nowiki>
Rog 11, Wiz 5</nowiki>

==== equipsetloop ====

The equipsetloop tag provides a way to repeat content for each of a character's equipment sets.

'''Parameters'''

None

''Example''
<nowiki>
<@equipsetloop>
Equipment Set : ${pcstring("EQSET.NAME")}. Equipment:
<@loop from=0 to=pcvar('COUNT[EQUIPMENT.MERGELOC]')-1 ; equip , equip_has_next >
${pcstring("EQ.MERGELOC.${equip}.NAME")}<#if equip_has_next>, </#if>
</@loop><#lt><#-- Equipment -->
</equipmentset> 
</@equipsetloop></nowiki>
might produce
<nowiki>
Equipment Set : Travelling Gear. Equipment: Backpack, Longsword, Traveller's Outfit 
Equipment Set : Council. Equipment: Coin purse, Noble's Outfit, Rapier </nowiki>

== Phase 1 ==

The aim of phase 1 is to utilise the already built output system and add the ability to
# Detect Freemarker templates and use the Freemarker engine to process them
# Add custom directives that can be called from a template (output sheet) to allow the existing output tags to be used.

This gives us a simple change-over and use of our existing well tested output tags.

We need to ensure that freemarker templates can be used in html, and PDF output styles.

See [http://freemarker.org/docs/dgui_misc_userdefdir.html User Defined Directives] and [http://freemarker.org/docs/pgui_config_sharedvariables.html Shared Variables] for information on creating custom directives/tags.

=== 1b Assisted Looping ===

Freemarker's inbuilt looping mechanism is object oriented. It expects to receive a list and process through it. In contrast, PCGen currently only outputs strings and numbers. The technique described at [http://stackoverflow.com/questions/15461721/freemarker-template-for-loop-statement For loop] can be used, which results in a structure like the following to loop through a list:
<nowiki>
<#assign max=pcvar('countdistinct("CLASSES")')-1>
<#if (max>=0)>
<#list 0..max as class>
<@pcstring tag="CLASSABB.${class}"/>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if>
</#list>
</#if></nowiki>

Note The if test is to allow the loop to be skipped if the list is empty.

Now this is a bit verbose so I have instead created a custom 'loop' directive to allow looping a number of times. This also deals with the empty loop scenario. See [[#loop|loop]]

=== 1c Object Output ===

To more closely align with FreeMarker's object oriented approach, we should examine the potential for exporting objects for output. So for example, exporting a list of spell objects that can then be looped over and each object queried as needed. A base for this output interface could be the Facade work done for the user interface.

<nowiki>
<#list pc.knownspells as spell>
<li>${spell.name} School: ${spell.school} <#if spell.subschool??> [${spell.school}] </#if></li>
</#list></nowiki>

Explanation of the Code Base

2013-12-30T22:46:54Z

James: Update for the new UI

{| align="right"
| __TOC__
|}

=High level overview of PCGen Code Base=

''src/java/pcgen'' is where the code tree begins. The directories match the package names — so ''pcgen.core'' would be ''src/java/pcgen/core'' (or ''src\java\pcgen\core'' if you are on Windows).

=Packages=

==pcgen.base.*==

These classes are 'base' library elements. None of these should be objects that are dependent upon pcgen.cdom or pcgen.core classes. The intent is that pcgen.base elements are usable in any project, not specifically PCGen. No item which is deeply tied to the concept of a Role-Playing Game or building a Player Character should be present in this package.

==pcgen.cdom.*==

The pcgen.cdom package contains the core contents of the CDOM structure. There are a number of key subpackages of pcgen.cdom:

# pcgen.cdom.base: This is the "base" package, which has many key components that the entire PCGen code base is dependent upon. It should be expected that the members of this package have few dependencies outside of pcgen.base* and pcgen.cdom.base*, as this is "low" in the package hierarchy.
# pcgen.cdom.choiceset: This package contains [[CDOM Primitive Choice Set Concept Document|Primitive Choice Sets]]
# pcgen.cdom.content: This package contains the non-CDOM Object content objects that would make up a Player Character. Long term, these objects would be "granted" by CDOM Objects, and thus would appear directly in the CDOM Graph that defines the Player Character (in 5.16, there is very little that distinguishes content from a helper)
# pcgen.cdom.enumeration: This package contains type safe enumerations (such as enums)
# pcgen.cdom.formula: This package contains items related to formula calculations performed by PCGen.
# pcgen.cdom.helper: This package is for "helper" objects of the CDOM Objects found within pcgen.cdom.inst. Generally a "helper" would be contained within the CDOM Object.
# pcgen.cdom.inst: This package is for instances of CDOM Objects. Long term, this will contain many of the objects currently in pcgen.core
# pcgen.cdom.list: This package contains list objects, such as Class Spell List objects. These list objects serve as identifiers for collections of CDOM Objects that are used at runtime.
# pcgen.cdom.reference: This package contains [[CDOM References Concept Document|CDOM References]]
# pcgen.cdom.modifier: This package contains modifiers, a specialized form of content that is designed to alter the behavior of content that is part of a Player Character (The override from a Hit Die Lock is a good example of a modifier)
# pcgen.cdom.util: These are utility packages for classes contained within the pcgen.cdom* packages.

==pcgen.rules.*==

This package contains the classes related to the "Rules Data Store". The classes here are responsible for loading (and writing) the rules files (PCC, LST), and when combined with the token plugins, this package converts the persistent objects into the instances, lists, content, helpers, references, and other objects of the pcgen.cdom* package.

==pcgen.core==

This is where the business logic goes. This is the main engine that makes things work. The most important class in here is PObject, many classes are subclassed from this (like PCClass, Race, Feat, Spell, etc.). Another important class is PlayerCharacter which is where the player characters are constructed and manipulated. Globals contains the lists of objects loaded when a user loads their desired sources. Constants holds most of the code constants so you do not need to remember their values.

==pcgen.gui==

This was the old GUI logic. It has now been removed and the UI is in the pcgen.gui2 classes.

==pcgen.gui2==

This is the NewGUI logic, starting from PCGen 6.0. The main window is pcgen.gui2.PCGenFrame, the tabs are in pcgen.gui2.tabs. All interaction between the tabs and the PCGen core is done via facades. This provides a nice separation of controller and view logic from the model code. The facade implementation can be found in the pcgen.gui2.facade package. Other major packages are pcgen.gui2.converter for the LST Converter and pcgen.gui2.sources for the source selection dialog.

==pcgen.io==

This is where the disk writing stuff occurs, like creating/parsing pcg files, and exporting character sheets.

==pcgen.persistence==

This is where the lst files are read in. The class that controls the loading of data is SourceFileLoader.

==pcgen.system==

This is where the new startup system introduced as part of the new user interface lives. The main class is pcgen.system.main.

==pcgen.util==

This is where generally useful classes that are don't fit any of the other categories go.

==plugin==

This is where the pluggable features go. This includes tools such as Character Sheet, Dicebag, Random Name Generator, Encounter Generator, Network Management, Experience Tracker, Initiative Tracker, GM Notes, Overland Travel and the Character Tracker. It also includes processors for the variety of Lst Tokens and Output Tokens. There is also an [[Arch. Discuss of Plugin System|Architectural Discussion of the PCGen Persistence Plugin System]] to help provide additional explanation of how the Lst Tokens work.

See the Javadocs for further details of the PCGen code base.

Template Engine

2013-12-24T04:27:44Z

James: tidy-up

{| align="right"
| __TOC__
|}
== Template Engine Sub Project ==

The aim of the project is to examine the Freemarker library with a view to using it to replace our export engine. In particular it would cover functionality logic functions like looping and if tests. This would leave our code to deal with the important things like TO HIT values etc.

We would do this in three phases:
# Add support for Freemarker templates for output
# Once sufficient sheets have been converted/rewritten, deprecate support for old sheet types
# Finally after a few releases, remove support for the old sheet types.

There are a few reasons for exploring this change
* Add a richer set of logic commands to enable more customisable output
* Simpler more consistent logic commands and more widely understood syntax
* Remove one of the more complex and difficult to maintain sections of the PCGen code base.

== Status ==

Currently working on phase 1.

FreeMarker support has been added to PCGen and is available in the [http://pcgen.org/autobuilds/ trunk autobuilds]. It will first be available in the 6.03.00 alpha release scheduled for February 2014.

Progress is being tracked in [http://jira.pcgen.org/browse/CODE-2418 CODE-2418 FreeMarker Output Generation - Phase 1]

== FreeMarker Template How-To ==

=== Introduction to FreeMarker ===

[http://freemarker.org/ FreeMarker] is a template engine that has now been incorporated into PCGen's export system as an alternative to our venerable export syntax. The FreeMarker engine brings some important benefits:
* Industry standard syntax
* Support for macros to output parameterised blocks
* Improved flow-control and logic instructions
* Support for including other files, e.g. macro libraries or common blocks
* Calculations and state within the output template
* Built-in syntax support in [http://freemarker.org/editors.html many text editors]

Here's a simple example FreeMarker PCGen template
<nowiki>

<h1>Freemarker Sheet for <@pcstring tag="NAME"/> - ${.now?date}</h1>

 Character Name: <@pcstring tag="NAME"/> 
 Player Name: <@pcstring tag="PLAYERNAME"/> 

 Fighter: ${pcvar("CL=Fighter")} 
 Rogue: ${pcvar("CL=Rogue")} 

<@loop from=0 to=pcvar('countdistinct("CLASSES")')-1 ; class , class_has_next >
<@pcstring tag="CLASSABB.${class}"/> <#t>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if><#t>
</@loop></nowiki>

which produces the output
<nowiki>

<h1>Freemarker Sheet for Ronald 'Surefingers' Millbridge - 29/10/2013</h1>

 Character Name: Ronald 'Surefingers' Millbridge 
 Player Name: James 

 Fighter: 0 
 Rogue: 11 

Rog 11,Wiz 2</nowiki>

=== FreeMarker Documentation ===

FreeMarker has quite thorough documentation. The main references output sheet authors will use are:
# [http://freemarker.org/docs/dgui.html Template Author's Guide]
# [http://freemarker.org/docs/ref.html Reference Guide]
# [http://freemarker.org/ Main FreeMarker page]

In addition, see testsuite/base-xml.ftl for a fully worked example of xml output.

=== Creating a Sheet ===

FreeMarker sheets are detected by PCGen by their file name suffix. A template ending in .ftl will be processed by FreeMarker rather than by PCGen's legacy output engine. The extension of the file to be produced should be immediately before that and preceded by a . or -. So a template to produce html output might be named csheet-first.html.ftl or chseet-compact-html.ftl and PCGen would pick up that it was a template to be processed by FreeMarker template that would produce output of a html file.

=== PCGen's Custom Functions ===

To provide output of PCGen characters we need to be able to access the character data and the output tags. The following tags are provided for that purpose.

==== pcstring ====

This tag evaluates a PCGen export token for the current character and returns the value as a string. It may be called as a directive (with a single parameter named 'tag') or as a function (with a single unnamed parameter).

''Examples''
<nowiki>
<@pcstring tag="PLAYERNAME"/>
<@pcstring tag="CLASSABB.${class}"/>
${pcstring('CLASSABB.${class}')}
<#if (pcstring('SPELLLISTCLASS.${class}')?length > 0)>present</#if></nowiki>

==== pcvar ====

This tag allows character variable values to be exported to a FreeMarker template. It evaluates a variable for the current character and returns the value as a number.

''Examples''
<nowiki>
<#assign numClasses=pcvar('countdistinct("CLASSES")')/>
${pcvar('count("ABILITIES","CATEGORY=FEAT","TYPE=Metamagic","VISIBILITY=DEFAULT[or]VISIBILITY=OUTPUT_ONLY")')}
${pcvar("CL=Fighter")}
</nowiki>

==== pcboolean ====

pcboolean allows character boolean values to be exported to a FreeMarker template. It evaluates an export token for the current character and returns the value as a boolean.

''Examples''
<nowiki>
<#if pcboolean('WEAPON.${weap}.ISTYPE.Double')>
<#if (pcboolean('HASVAR:Manifester.OR.HASVAR:PsychicWarriorManifester')) ></nowiki>

==== loop ====

The loop tag provides a way to repeat content a certain number of times. Unlike the inbuilt list directive it can loop zero times.

'''Parameters'''

* from (optional) - The starting value, defaults to 0.
* to - The ending value (inclusive). If this is less than from then the contents will not be output.
* step (optional) - The amount to increment b each loop, defaults to 1.

In addition up to two loopvars may be specified. The first will be populated with the current index value of the loop and the second will be a boolean indicating if there are more iterations of the loop to go. We recommend that the second variable, if present, is named after the first variable with _has_next added. e.g. class, class_has_next . This is in order to match the list directive, which provides a similarly named variable automatically.

''Example''
<nowiki>
<@loop from=0 to=pcvar('countdistinct("CLASSES")')-1 ; class , class_has_next >
<@pcstring tag="CLASSABB.${class}"/>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if>
</@loop></nowiki>
might produce
<nowiki>
Rog 11, Wiz 5</nowiki>

== Phase 1 ==

The aim of phase 1 is to utilise the already built output system and add the ability to
# Detect Freemarker templates and use the Freemarker engine to process them
# Add custom directives that can be called from a template (output sheet) to allow the existing output tags to be used.

This gives us a simple change-over and use of our existing well tested output tags.

We need to ensure that freemarker templates can be used in html, and PDF output styles.

See [http://freemarker.org/docs/dgui_misc_userdefdir.html User Defined Directives] and [http://freemarker.org/docs/pgui_config_sharedvariables.html Shared Variables] for information on creating custom directives/tags.

=== 1b Assisted Looping ===

Freemarker's inbuilt looping mechanism is object oriented. It expects to receive a list and process through it. In contrast, PCGen currently only outputs strings and numbers. The technique described at [http://stackoverflow.com/questions/15461721/freemarker-template-for-loop-statement For loop] can be used, which results in a structure like the following to loop through a list:
<nowiki>
<#assign max=pcvar('countdistinct("CLASSES")')-1>
<#if (max>=0)>
<#list 0..max as class>
<@pcstring tag="CLASSABB.${class}"/>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if>
</#list>
</#if></nowiki>

Note The if test is to allow the loop to be skipped if the list is empty.

Now this is a bit verbose so I have instead created a custom 'loop' directive to allow looping a number of times. This also deals with the empty loop scenario. See [[#loop|loop]]

=== 1c Object Output ===

To more closely align with FreeMarker's object oriented approach, we should examine the potential for exporting objects for output. So for example, exporting a list of spell objects that can then be looped over and each object queried as needed. A base for this output interface could be the Facade work done for the user interface.

<nowiki>
<#list pc.knownspells as spell>
<li>${spell.name} School: ${spell.school} <#if spell.subschool??> [${spell.school}] </#if></li>
</#list></nowiki>

Template Engine

2013-12-24T04:22:31Z

James: Add usage documentation

== Template Engine Sub Project ==

The aim of the project is to examine the Freemarker library with a view to using it to replace our export engine. In particular it would cover functionality logic functions like looping and if tests. This would leave our code to deal with the important things like TO HIT values etc.

We would do this in three phases:
# Add support for Freemarker templates for output
# Once sufficient sheets have been converted/rewritten, deprecate support for old sheet types
# Finally after a few releases, remove support for the old sheet types.

There are a few reasons for exploring this change
* Add a richer set of logic commands to enable more customisable output
* Simpler more consistent logic commands and more widely understood syntax
* Remove one of the more complex and difficult to maintain sections of the PCGen code base.

== Status ==

Currently working on phase 1.

FreeMarker support has been added to PCGen and is available in the [http://pcgen.org/autobuilds/ trunk autobuilds]. It will first be available in the 6.03.00 alpha release scheduled for February 2014.

Progress is being tracked in [http://jira.pcgen.org/browse/CODE-2418 CODE-2418 FreeMarker Output Generation - Phase 1]

== FreeMarker Template How-To ==

=== Introduction to FreeMarker ===

[http://freemarker.org/ FreeMarker] is a template engine that has now been incorporated into PCGen's export system as an alternative to our venerable export syntax. The FreeMarker engine brings some important benefits:
* Industry standard syntax
* Support for macros to output parameterised blocks
* Improved flow-control and logic instructions
* Support for including other files, e.g. macro libraries or common blocks
* Calculations and state within the output template
* Built in syntax support to [http://freemarker.org/editors.html many text editors]

Here's a simple example FreeMarker PCGen template
<nowiki>

<h1>Freemarker Sheet for <@pcstring tag="NAME"/> - ${.now?date}</h1>

 Character Name: <@pcstring tag="NAME"/> 
 Player Name: <@pcstring tag="PLAYERNAME"/> 

 Fighter: ${pcvar("CL=Fighter")} 
 Rogue: ${pcvar("CL=Rogue")} 

<@loop from=0 to=pcvar('countdistinct("CLASSES")')-1 ; class , class_has_next >
<@pcstring tag="CLASSABB.${class}"/> <#t>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if><#t>
</@loop></nowiki>

which produces the output
<nowiki>

<h1>Freemarker Sheet for Ronald 'Surefingers' Millbridge - 29/10/2013</h1>

 Character Name: Ronald 'Surefingers' Millbridge 
 Player Name: James 

 Fighter: 0 
 Rogue: 11 

Rog 11,Wiz 2</nowiki>

=== FreeMarker Documentation ===

FreeMarker has quite thorough documentation. The main references output sheet authors will use are:
# [http://freemarker.org/docs/dgui.html Template Author's Guide]
# [http://freemarker.org/docs/ref.html Reference Guide]
# [http://freemarker.org/ Main FreeMarker page]

In addition, see testsuite/base-xml.ftl for afully worked example of xml output.

=== Creating a Sheet ===

FreeMarker sheets are detected by PCGen by their file name suffix. A template ending in .ftl will be processed by FreeMarker rather than by PCGen's legacy output engine. The extension of the file to be produced should be immediately before that. So a template to produce html output might be named csheet-first.html.ftl or chseet-compact-html.ftl and PCGen would pick up that it was a template to be processed by FreeMarker template that would produce output of a html file.

=== PCGen's Custom Functions ===

To provide output of PCGen characters we need to be able to access the character data and the output tags.

==== pcstring ====

This tag evaluates a PCGen export token for the current character and returns the value as a string. It may be called as a directive (with a single parameter named 'tag') or as a function (with a single unnamed parameter).

''Examples''
<nowiki>
<@pcstring tag="PLAYERNAME"/>
<@pcstring tag="CLASSABB.${class}"/>
${pcstring('CLASSABB.${class}')}
<#if (pcstring('SPELLLISTCLASS.${class}')?length > 0)>present</#if></nowiki>

==== pcvar ====

This tag allows character variable values to be exported to a FreeMarker template. It evaluates a variable for the current character and returns the value as a number.

''Examples''
<nowiki>
<#assign numClasses=pcvar('countdistinct("CLASSES")')/>
${pcvar('count("ABILITIES","CATEGORY=FEAT","TYPE=Metamagic","VISIBILITY=DEFAULT[or]VISIBILITY=OUTPUT_ONLY")')}
${pcvar("CL=Fighter")}
</nowiki>

==== pcboolean ====

pcboolean allows character boolean values to be exported to a FreeMarker template. It evaluates an export token for the current character and returns the value as a boolean.

''Examples''
<nowiki>
<#if pcboolean('WEAPON.${weap}.ISTYPE.Double')>
<#if (pcboolean('HASVAR:Manifester.OR.HASVAR:PsychicWarriorManifester')) ></nowiki>

==== loop ====

The loop tag provides a way to repeat content a certain number of times. Unlike the inbuilt list directive it can loop zero times.

'''Parameters'''

* from (optional) - The starting value, defaults to 0.
* to - The ending value (inclusive). If this is less than from then the contents will not be output.
* step (optional) - The amount to increment b each loop, defaults to 1.

In addition up to two loopvars may be specified. The first will be populated with the current index value of the loop and the second will be a boolean indicating if there are more iterations of the loop to go. We recommend that the second variable, if present, is named after the first variable with _has_next added. e.g. class, class_has_next . This is in order to match the list directive, which provides a similarly named variable automatically.

''Example''
<nowiki>
<@loop from=0 to=pcvar('countdistinct("CLASSES")')-1 ; class , class_has_next >
<@pcstring tag="CLASSABB.${class}"/>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if>
</@loop></nowiki>
might produce
<nowiki>
Rog 11, Wiz 5</nowiki>

== Phase 1 ==

The aim of phase 1 is to utilise the already built output system and add the ability to
# Detect Freemarker templates and use the Freemarker engine to process them
# Add custom directives that can be called from a template (output sheet) to allow the existing output tags to be used.

This gives us a simple change-over and use of our existing well tested output tags.

We need to ensure that freemarker templates can be used in html, and PDF output styles.

See [http://freemarker.org/docs/dgui_misc_userdefdir.html User Defined Directives] and [http://freemarker.org/docs/pgui_config_sharedvariables.html Shared Variables] for information on creating custom directives/tags.

=== 1b Assisted Looping ===

Freemarker's inbuilt looping mechanism is object oriented. It expects to receive a list and process through it. In contrast, PCGen currently only outputs strings and numbers. The technique described at [http://stackoverflow.com/questions/15461721/freemarker-template-for-loop-statement For loop] can be used, which results in a structure like the following to loop through a list:
<nowiki>
<#assign max=pcvar('countdistinct("CLASSES")')-1>
<#if (max>=0)>
<#list 0..max as class>
<@pcstring tag="CLASSABB.${class}"/>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if>
</#list>
</#if></nowiki>

Note The if test is to allow the loop to be skipped if the list is empty.

Now this is a bit verbose so I have instead created a custom 'loop' directive to allow looping a number of times. This also deals with the empty loop scenario. See [[#loop|loop]]

=== 1c Object Output ===

To more closely align with FreeMarker's object oriented approach, we should examine the potential for exporting objects for output. So for example, exporting a list of spell objects that can then be looped over and each object queried as needed. A base for this output interface could be the Facade work done for the user interface.

<nowiki>
<#list pc.knownspells as spell>
<li>${spell.name} School: ${spell.school} <#if spell.subschool??> [${spell.school}] </#if></li>
</#list></nowiki>

Template Engine

2013-12-24T03:31:26Z

James: Add initial freemarker documentation

== Template Engine Sub Project ==

The aim of the project is to examine the Freemarker library with a view to using it to replace our export engine. In particular it would cover functionality logic functions like looping and if tests. This would leave our code to deal with the important things like TO HIT values etc.

We would do this in three phases:
# Add support for Freemarker templates for output
# Once sufficient sheets have been converted/rewritten, deprecate support for old sheet types
# Finally after a few releases, remove support for the old sheet types.

There are a few reasons for exploring this change
* Add a richer set of logic commands to enable more customisable output
* Simpler more consistent logic commands and more widely understood syntax
* Remove one of the more complex and difficult to maintain sections of the PCGen code base.

== Status ==

Currently working on phase 1.

FreeMarker support has been added to PCGen and is available in the [http://pcgen.org/autobuilds/ trunk autobuilds]. It will first be available in the 6.03.00 alpha release scheduled for February 2014.

Progress is being tracked in [http://jira.pcgen.org/browse/CODE-2418 CODE-2418 FreeMarker Output Generation - Phase 1]

== FreeMarker Template How-To ==

=== Introduction to FreeMarker ===

[http://freemarker.org/ FreeMarker] is a template engine that has now been incorporated into PCGen's export system as an alternative to our venerable export syntax. The FreeMarker engine brings some important benefits:
* Industry standard syntax
* Support for macros to output parameterised blocks
* Improved flow-control and logic instructions
* Support for including other files, e.g. macro libraries or common blocks
* Calculations and state within the output template
* Built in syntax support to [http://freemarker.org/editors.html many text editors]

Here's a simple example FreeMarker PCGen template
<nowiki>

<h1>Freemarker Sheet for <@pcstring tag="NAME"/> - ${.now?date}</h1>

 Character Name: <@pcstring tag="NAME"/> 
 Player Name: <@pcstring tag="PLAYERNAME"/> 

 Fighter: ${pcvar("CL=Fighter")} 
 Rogue: ${pcvar("CL=Rogue")} 

<@loop from=0 to=pcvar('countdistinct("CLASSES")')-1 ; class , class_has_next >
<@pcstring tag="CLASSABB.${class}"/> <#t>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if><#t>
</@loop></nowiki>

which produces the output
<nowiki>

<h1>Freemarker Sheet for Ronald 'Surefingers' Millbridge - 29/10/2013</h1>

 Character Name: Ronald 'Surefingers' Millbridge 
 Player Name: James 

 Fighter: 0 
 Rogue: 11 

Rog 11,Wiz 2</nowiki>

=== FreeMarker Documentation ===

FreeMarker has quite thorough documentation. The main references output sheet authors will use are:
# [http://freemarker.org/docs/dgui.html Template Author's Guide]
# [http://freemarker.org/docs/ref.html Reference Guide]
# [http://freemarker.org/ Main FreeMarker page]

In addition, see testsuite/base-xml.ftl for afully worked example of xml output.

=== Creating a Sheet ===

FreeMarker sheets are detected by PCGen by their file name suffix. A template ending in .ftl will be processed by FreeMarker rather than by PCGen's legacy output engine. The extension of the file to be produced should be immediately before that. So a template to produce html output might be named csheet-first.html.ftl or chseet-compact-html.ftl and PCGen would pick up that it was a template to be processed by FreeMarker template that would produce output of a html file.

=== PCGen's Custom Functions ===

To provide output of PCGen characters we need to be able to access the character data and the output tags.

==== pcstring ====

This tag evaluates a PCGen export token for the current character and returns the value as a string. e.g. <@pcstring tag="PLAYERNAME"/> or ${pcstring('PLAYERNAME')}

==== pcvar ====

This tag allows character variable values to be exported to a FreeMarker template. It evaluates a variable for the current character and returns the value as a number. e.g. ${pcvar("CL=Fighter")}

==== pcboolean ====

pcboolean allows character boolean values to be exported to a FreeMarker template. It evaluates an export token for the current character and returns the value as a boolean. e.g. ${pcboolean("WEAPON.0.ISTYPE.Double")}

==== loop ====

The loop tag provides a way to loop a certain number of times. Unlike the inbuilt list directive it can loop zero times.

Parameters

* from (optional) - The starting value, defaults to 0.
* to - The ending value (inclusive). If this is less than from then the contents will not be output.
* step (optional) - The amount to increment b each loop, defaults to 1.

In addition up to two loopvars may be specified. The first will be populated with the current index value of the loop and the second will be a boolean indicating if there are more iterations of the loop to go.

Nested content is output once for each loop

== Phase 1 ==

The aim would be to utilise the already built output system and add the ability to
# Detect Freemarker templates and use the Freemarker engine to process them
# Add custom directives that can be called from a template (output sheet) to allow the existing output tags to be used.

This would give us a simple change-over and use our existing well tested output code base.

Example of outputting an export tag
<nowiki>
<@pcstring tag="NAME"/>
<@pcstring tag="SPELLMEM.0.1.1.1.NAME"/>
<@pcstring tag="PLAYERNAME"/></nowiki>

Example of accessing a character variable value:
<nowiki>
${pcvar("CL=Fighter")}
${pcvar("CL=Rogue")}
${pcvar("count(\"ABILITIES\",\"CATEGORY=FEAT\",\"TYPE=Metamagic\",\"VISIBILITY=DEFAULT[or]VISIBILITY=OUTPUT_ONLY\")")}</nowiki>

We would need to ensure that freemarker templates can be used in html, and PDF output styles.

See [http://freemarker.org/docs/dgui_misc_userdefdir.html User Defined Directives] and [http://freemarker.org/docs/pgui_config_sharedvariables.html Shared Variables] for information on creating custom directives/tags.

For example, the sheet
<nowiki>

<h1>Freemarker Sheet for <@pcstring tag="NAME"/> - ${.now?date}</h1>

 Character Name: <@pcstring tag="NAME"/> 
 Player Name: <@pcstring tag="PLAYERNAME"/> 

 Fighter: ${pcvar("CL=Fighter")} 
 Rogue: ${pcvar("CL=Rogue")} </nowiki>

produced the output
<nowiki>

<h1>Freemarker Sheet for Ronald 'Surefingers' Millbridge - 29/10/2013</h1>

 Character Name: Ronald 'Surefingers' Millbridge 
 Player Name: James 

 Fighter: 0 
 Rogue: 11 

Rog 11,Wiz 2</nowiki>

=== 1b Assisted Looping ===

Freemarker's inbuilt looping mechanism is object oriented. It expects to receive a list and process through it. In contrast, PCGen currently only outputs strings and numbers. The technique described at [http://stackoverflow.com/questions/15461721/freemarker-template-for-loop-statement For loop] can be used, which results in a structure like the following to loop through a list:
<nowiki>
<#assign max=pcvar('countdistinct("CLASSES")')-1>
<#if (max>=0)>
<#list 0..max as class>
<@pcstring tag="CLASSABB.${class}"/>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if>
</#list>
</#if></nowiki>

Note The if test is to allow the loop yo be skipped if the list is empty.

Now this is a bit verbose so I have instead created a custom directive to allow looping a number of times. This also deals with the empty loop scenario.

<nowiki>
<@loop from=0 to=pcvar('countdistinct("CLASSES")')-1 ; class , class_has_next >
<@pcstring tag="CLASSABB.${class}"/>
<@pcstring tag="CLASS.${class}.LEVEL"/><#if class_has_next>,</#if>
</@loop>
</nowiki>
=== 1c Object Output ===

To more closely align with FreeMarker's object oriented approach, we should examine the potential for exporting objects for output. So for example, exporting a list of spell objects that can then be looped over and each object queried as needed. A base for this output interface could be the Facade work done for the user interface.

<nowiki>
<#list pc.knownspells as spell>
<li>${spell.name} School: ${spell.school} <#if spell.subschool??> [${spell.school}] </#if></li>
</#list></nowiki>

Release 6.2.x

2013-12-21T02:03:57Z

James: /* Release dates */

{| align="right"
| __TOC__
|}

=Release dates=

We are aiming to release 6.2.0 in Nov-Dec 2013. The schedule for the run up to release is:

* 6.01.08 (Alpha) - 26 October, 2013
* 6.01.09 (Beta) - 11 November, 2013 - Note: Feature set frozen at this point, changes up until prod are almost entirely bug fixes.
* 6.01.10 (Beta) - 25 November, 2013
* 6.02.00 RC1 - 5 December, 2013
* 6.02.00 RC2 - 13 December, 2013
* 6.02.00 (Prod) - 21 December, 2013

=Team Goals=

==[[Architecture]]==

* Further implementation of [[CDOM]] (Character Document Object Model), led by [[Tom Parker]]
* Continuation of [[Architecture Changes 5.17]], led by [[Tom Parker]]

==[[Code]]==
* Consolidation of the new user interface, lead by [[James Dempsey]]

==[[Data]]==
* There are no specific plans for new data sets although as always there will be some sets included as part of this release. Since we can now roll out data sets in between official releases this will simply be an ongoing process. You can check a number of places to see if a favourite data set is being actively worked on at:

* [http://jira.pcgen.org/browse/NEWSOURCE New Data Source Development for 6.2]
* [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DATA+AND+issuetype+%3D+%22New+Feature%22+ORDER+BY+fixVersion%2C+Status%2C+priority+DESC Data Feature Requests for 6.2]

==[[Output Sheets]]==
* Various minor updates to the existing sheets and their structure.

==[[Documentation]]==
* Various minor enhancements

==[[Publisher Liaison]]==
* No major projects, continuation of existing work

==[[Data License]]==
* No major projects, continuation of existing work

==[[Advertising]]==
* No major projects, continuation of existing work

Template Engine

2013-12-18T12:54:06Z

James: Add new loop directive

Release 6.2.x

2013-12-07T12:18:23Z

James: Update schedule to reflect extra RC

{| align="right"
| __TOC__
|}

=Release dates=

We are aiming to release 6.2.0 in Nov-Dec 2013. The schedule for the run up to release is:

* 6.01.08 (Alpha) - 26 October, 2013
* 6.01.09 (Beta) - 11 November, 2013 - Note: Feature set frozen at this point, changes up until prod are almost entirely bug fixes.
* 6.01.10 (Beta) - 25 November, 2013
* 6.02.00 RC1 - 5 December, 2013
* 6.02.00 RC2 - 10 December, 2013
* 6.02.00 (Prod) - 17 December, 2013

=Team Goals=

==[[Architecture]]==

* Further implementation of [[CDOM]] (Character Document Object Model), led by [[Tom Parker]]
* Continuation of [[Architecture Changes 5.17]], led by [[Tom Parker]]

==[[Code]]==
* Consolidation of the new user interface, lead by [[James Dempsey]]

==[[Data]]==
* There are no specific plans for new data sets although as always there will be some sets included as part of this release. Since we can now roll out data sets in between official releases this will simply be an ongoing process. You can check a number of places to see if a favourite data set is being actively worked on at:

* [http://jira.pcgen.org/browse/NEWSOURCE New Data Source Development for 6.2]
* [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DATA+AND+issuetype+%3D+%22New+Feature%22+ORDER+BY+fixVersion%2C+Status%2C+priority+DESC Data Feature Requests for 6.2]

==[[Output Sheets]]==
* Various minor updates to the existing sheets and their structure.

==[[Documentation]]==
* Various minor enhancements

==[[Publisher Liaison]]==
* No major projects, continuation of existing work

==[[Data License]]==
* No major projects, continuation of existing work

==[[Advertising]]==
* No major projects, continuation of existing work

Template Engine

2013-11-26T20:46:42Z

James: Add some more detail on where things are up to, add section 1c

Release 6.2.x

2013-11-11T09:05:11Z

James: /* Release dates */

{| align="right"
| __TOC__
|}

=Release dates=

We are aiming to release 6.2.0 in Nov-Dec 2013. The schedule for the run up to release is:

* 6.01.08 (Alpha) - 26 October, 2013
* 6.01.09 (Beta) - 11 November, 2013 - Note: Feature set frozen at this point, changes up until prod are almost entirely bug fixes.
* 6.01.10 (Beta) - 25 November, 2013
* 6.02.00 RC1 - 2 December, 2013
* 6.02.00 (Prod) - 8 December, 2013

=Team Goals=

==[[Architecture]]==

* Further implementation of [[CDOM]] (Character Document Object Model), led by [[Tom Parker]]
* Continuation of [[Architecture Changes 5.17]], led by [[Tom Parker]]

==[[Code]]==
* Consolidation of the new user interface, lead by [[James Dempsey]]

==[[Data]]==
* There are no specific plans for new data sets although as always there will be some sets included as part of this release. Since we can now roll out data sets in between official releases this will simply be an ongoing process. You can check a number of places to see if a favourite data set is being actively worked on at:

* [http://jira.pcgen.org/browse/NEWSOURCE New Data Source Development for 6.2]
* [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DATA+AND+issuetype+%3D+%22New+Feature%22+ORDER+BY+fixVersion%2C+Status%2C+priority+DESC Data Feature Requests for 6.2]

==[[Output Sheets]]==
* Various minor updates to the existing sheets and their structure.

==[[Documentation]]==
* Various minor enhancements

==[[Publisher Liaison]]==
* No major projects, continuation of existing work

==[[Data License]]==
* No major projects, continuation of existing work

==[[Advertising]]==
* No major projects, continuation of existing work

PCGen Code Exploration Almanac

2013-11-03T00:29:27Z

James:

{| align="right"
| __TOC__
|}

=Introduction=
This guide is a collection of strategies and ways to tackle tasks in the PCGen code. It doesn’t try to be an architectural guide, for that I would start with [[Explanation_of_the_Code_Base]] , which is a good document to be familiar with. There is also some good info at [[Architecture]]

=Important Tools=

There are a few commands I use all the time to explore/move around the PCGen code base.
* '''Open Type''' - Eclipse shift-ctrl-T - This allows you to search for a class by its name. Searches can be by the start of the name, use wildcards and even use camel case (NPE finds NullPointerException)
* '''Call Hierarchy''' - Eclipse ctrl-alt-H - This shows you where a method is called from. Its great way of tracing execution paths and seeing what the assumptions of callers are.

=Lst Tokens as an Entry Point=
Quite often you will know the data that is associated with a problem or request. An important tip to remember is that almost all LST tokens are processed by a class which starts with the same name. e.g. the kit EQUIPBUY token is processed by the class plugin.lsttokens.kit.startpack.EquipBuyToken

All token classes then have a parse and unparsed method (sometimes it is in a parent class). You can look at these to find out how the token is interpreted and where the value is stored. Generally the token value is stored in a map in the rules object with a specific constant as a key (e.g. Objectkey.EQUIP_BUY). You can use this key to trace where the token value is processed, thus quickly getting to the code you want to look at.

So, typically in Eclipse I will
# Search for a class starting with the token name
# Read through the parse method to see the key used to store the value (or relevant part of the value).
# Open the Call hierarchy for the key to identify where the token’s value is processed.

=Creating a New Lst Token=
Adding a new LST token follows a fairly standard pattern:
# Create a new token class
# Add a unit test or two
# Update the pluginbuild.xml
# Test it out
# Update the documentation

Also, if you hit any issues when you are creating a new tag post on the dev list for help and someone will be able to assist.

===Create a new token class===
Creating the new token class is the biggest step. First you need to decide where to create it. All new lst tokens should be under the plugin.lsttokens package. If it is restricted to a single object (Ability, Skill etc) then it should be created under the specific package e.g. plugin.lsttokens.ability. Once created, ensure you have added the LGPL license header and a basic description of the tag in the class java docs.

Now have a look at other tokens in the same package and pick one as an example, hopefully something that works in a similar way to the new tag you are adding. Have a look first at the class definition. Usually you will have something like
<pre>
public class FooLst
extends AbstractNonEmptyToken<CDOMObject>
implements CDOMPrimaryToken<CDOMObject></pre>

Here we are using the AbstractNonEmptyToken as the parent class, and thus getting all that classes functionality for free. We are also declaring this to be a CDOMPrimaryToken (i.e. a standalone Lst tag) which wil define what methods we need to implement for the new tag to work properly.

Every token will have a parse and an unparse method. What you will generally do is create a new StringKey, ObjectKey etc to record the new item against and then when you parse the tag you can record it against your key as follows:

<pre>
context.getObjectContext().put(obj, StringKey.OUTPUT_NAME, value);</pre>

Then when you unparse it can read that key and write out the value:
<pre>
String oname = context.getObjectContext().getString(obj,
StringKey.OUTPUT_NAME);
if (oname == null)
{
return null;
}
return new String[] { oname };</pre>
Unparsing is used by the LST converter (and the future LST editor) to write out the tag with the correct syntax.

===Add a unit test or two===
Tom has set up some great unit testing structures which will give your tag a full workout for little effort. Again, the best way is to copy and adjust the test for your example tag. You should be aiming to have a quick isolated test in the code/src/utest folder (e.g. OutputNameLstTest) and a parse/unparse test in the code/src/itest folder (e.g. OutputNameIntegrationTest). These will ensure that your new tags are working as you expect.

===Update the pluginbuild.xml===
The next step is updating the pluginbuild.xml file to add in your new tag. This creates a jar file for that tag which is then read by the PCGen plugin system on load. As a result PCGen will automatically know about your new tag with no further registration required. Again, use your example existing token as a guide. Once done, you should run the ant build and then run the PluginBuildTest unit test to check that the plguinbuild.xml file has been updated correctly - it will let you know if the name is incorrect etc.

===Test it out===
OK, now you have the tag added to PCGen. You can add it to some data, load the data and check that it is read in correctly.

===Update the documentation===
The last step is updating the documentation. When you advance your NEWTAG entry in jira to say the tag is implemented it goes to the docs team. Now they will add in the docs when they get time, but if you want to help out, you can base a new docs entry on the syntax description in your NEWTAG issue. The sample tag you used above can also be a good guide for how to enter it. Also don't forget to mark it as new for the version you added it in.

PCGen Code Exploration Almanac

2013-11-03T00:26:17Z

James: Add Creating a New Lst Token section plus tools

{| align="right"
| __TOC__
|}

=Introduction=
This guide is a collection of strategies and ways to tackle tasks in the PCGen code. It doesn’t try to be an architectural guide, for that I would start with [[Explanation_of_the_Code_Base]] , which is a good document to be familiar with. There is also some good info at [[Architecture]]

=Important Tools=

There are a few commands I use all the time to explore/move around the PCGen code base.
* '''Open Type''' - Eclipse shift-ctrl-T - This allows you to search for a class by its name. Searches can be by the start of the name, use wildcards and even use camel case (NPE finds NullPointerException)
* '''Call Hierarchy''' - Eclipse ctrl-alt-H - This shows you where a method is called from. Its great way of tracing execution paths and seeing what the assumptions of callers are.

=Lst Tokens as an Entry Point=
Quite often you will know the data that is associated with a problem or request. An important tip to remember is that almost all LST tokens are processed by a class which starts with the same name. e.g. the kit EQUIPBUY token is processed by the class plugin.lsttokens.kit.startpack.EquipBuyToken

All token classes then have a parse and unparsed method (sometimes it is in a parent class). You can look at these to find out how the token is interpreted and where the value is stored. Generally the token value is stored in a map in the rules object with a specific constant as a key (e.g. Objectkey.EQUIP_BUY). You can use this key to trace where the token value is processed, thus quickly getting to the code you want to look at.

So, typically in Eclipse I will
# Search for a class starting with the token name
# Read through the parse method to see the key used to store the value (or relevant part of the value).
# Open the Call hierarchy for the key to identify where the token’s value is processed.

=Creating a New Lst Token=
Adding a new LST token follows a fairly standard pattern:
# Create a new token class
# Add a unit test or two
# Update the pluginbuild.xml
# Test it out
# Update the documentation

===Create a new token class===
Creating the new token class is the biggest step. First you need to decide where to create it. All new lst tokens should be under the plugin.lsttokens package. If it is restricted to a single object (Ability, Skill etc) then it should be created under the specific package e.g. plugin.lsttokens.ability. Once created, ensure you have added the LGPL license header and a basic description of the tag in the class java docs.

Now have a look at other tokens in the same package and pick one as an example, hopefully something that works in a similar way to the new tag you are adding. Have a look first at the class definition. Usually you will have something like
<pre>
public class FooLst
extends AbstractNonEmptyToken<CDOMObject>
implements CDOMPrimaryToken<CDOMObject></pre>

Here we are using the AbstractNonEmptyToken as the parent class, and thus getting all that classes functionality for free. We are also declaring this to be a CDOMPrimaryToken (i.e. a standalone Lst tag) which wil define what methods we need to implement for the new tag to work properly.

Every token will have a parse and an unparse method. What you will generally do is create a new StringKey, ObjectKey etc to record the new item against and then when you parse the tag you can record it against your key as follows:

<pre>
context.getObjectContext().put(obj, StringKey.OUTPUT_NAME, value);</pre>

Then when you unparse it can read that key and write out the value:
<pre>
String oname = context.getObjectContext().getString(obj,
StringKey.OUTPUT_NAME);
if (oname == null)
{
return null;
}
return new String[] { oname };</pre>
Unparsing is used by the LST converter (and the future LST editor) to write out the tag with the correct syntax.

===Add a unit test or two===
Tom has set up some great unit testing structures which will give your tag a full workout for little effort. Again, the best way is to copy and adjust the test for your example tag. You should be aiming to have a quick isolated test in the code/src/utest folder (e.g. OutputNameLstTest) and a parse/unparse test in the code/src/itest folder (e.g. OutputNameIntegrationTest). These will ensure that your new tags are wokring as you expect.

===Update the pluginbuild.xml===
The next step is updating the pluginbuild.xml file to add in your new tag. This creates a jar file for that tag which is then read by the PCGen plugin system on load. As a result PCGen will automatically know about your new tag with no further registration required. Again, use your example existing token as a guide. Once done, you should run the ant build and then run the PluginBuildTest unit test to check that the plguinbuild.xml file has been updated correctly - it will let you know if the name is incorrect etc.

===Test it out===
OK, now you have the tag added to PCGen. You can add it to some data, load the data and check that it is read in correctly.

===Update the documentation===
The last step is updating the documentation. When you advance your NEWTAG entry in jira to say the tag is implemented it goes to the doco team. Now they will add i the doco when they get time, but if you want to help out, you can base a new doco entry on the syntax description in your NEWTAG issue. The sample tag you used above can also be a good guide fr how to enter it. Also don;t forget to mark it as new for the version you added it in.

Template Engine

2013-10-29T11:19:41Z

James: Show initial implementation results

Release 6.2.x

2013-10-25T22:29:13Z

James: /* Release dates */

{| align="right"
| __TOC__
|}

=Release dates=

We are aiming to release 6.2.0 in Nov-Dec 2013. The schedule for the run up to release is:

* 6.01.08 (Alpha) - 26 October, 2013
* 6.01.09 (Beta) - 10 November, 2013 - Note: Feature set frozen at this point, changes up until prod are almost entirely bug fixes.
* 6.01.10 (Beta) - 24 November, 2013
* 6.02.00 RC1 - 1 December, 2013
* 6.02.00 (Prod) - 8 December, 2013

=Team Goals=

==[[Architecture]]==

* Further implementation of [[CDOM]] (Character Document Object Model), led by [[Tom Parker]]
* Continuation of [[Architecture Changes 5.17]], led by [[Tom Parker]]

==[[Code]]==
* Consolidation of the new user interface, lead by [[James Dempsey]]

==[[Data]]==
* There are no specific plans for new data sets although as always there will be some sets included as part of this release. Since we can now roll out data sets in between official releases this will simply be an ongoing process. You can check a number of places to see if a favourite data set is being actively worked on at:

* [http://jira.pcgen.org/browse/NEWSOURCE New Data Source Development for 6.2]
* [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DATA+AND+issuetype+%3D+%22New+Feature%22+ORDER+BY+fixVersion%2C+Status%2C+priority+DESC Data Feature Requests for 6.2]

==[[Output Sheets]]==
* Various minor updates to the existing sheets and their structure.

==[[Documentation]]==
* Various minor enhancements

==[[Publisher Liaison]]==
* No major projects, continuation of existing work

==[[Data License]]==
* No major projects, continuation of existing work

==[[Advertising]]==
* No major projects, continuation of existing work

Release 6.2.x

2013-10-25T21:53:52Z

James: Add 6.2 release schedule

{| align="right"
| __TOC__
|}

=Release dates=

We are aiming to release 6.2.0 in Nov-Dec 2013. The schedule for the run up to release is:

* 6.01.08 (Alpha) - 26 October, 2013
* 6.01.09 (Beta) - 10 November, 2013 - Note: Feature set frozen at this point, changes up until prod are almost entirely bug fixes.
* 6.01.10 (Beta) - 24 November, 2013
* 6.02.01 RC1 - 1 December, 2013
* 6.02.01 (Prod) - 8 December, 2013

=Team Goals=

==[[Architecture]]==

* Further implementation of [[CDOM]] (Character Document Object Model), led by [[Tom Parker]]
* Continuation of [[Architecture Changes 5.17]], led by [[Tom Parker]]

==[[Code]]==
* Consolidation of the new user interface, lead by [[James Dempsey]]

==[[Data]]==
* There are no specific plans for new data sets although as always there will be some sets included as part of this release. Since we can now roll out data sets in between official releases this will simply be an ongoing process. You can check a number of places to see if a favourite data set is being actively worked on at:

* [http://jira.pcgen.org/browse/NEWSOURCE New Data Source Development for 6.2]
* [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DATA+AND+issuetype+%3D+%22New+Feature%22+ORDER+BY+fixVersion%2C+Status%2C+priority+DESC Data Feature Requests for 6.2]

==[[Output Sheets]]==
* Various minor updates to the existing sheets and their structure.

==[[Documentation]]==
* Various minor enhancements

==[[Publisher Liaison]]==
* No major projects, continuation of existing work

==[[Data License]]==
* No major projects, continuation of existing work

==[[Advertising]]==
* No major projects, continuation of existing work

Template Engine

2013-10-23T23:00:24Z

James: /* Phase 1 */

Building PCGen

2013-10-20T04:59:48Z

James:

{| align="right"
| __TOC__
|}
=Building PCGen from the command line=

This process uses the [[ANT]] tool, you need the following software packages:

* Java Development Kit (aka Java SDK or JDK). You should use the latest version (update) of the JDK 6.0 available for download from [http://www.oracle.com/technetwork/java/javase/downloads/index.html here]. At the time of writing this was Java SE 6 Update 29. Java 7 will also work for the new UI, but no 1.7 specific features should be used in the code. Other JDKs might work, but no one has tried.
* Ant 1.7.0 (or later) from [http://jakarta.apache.org/ant/ here]. Ant is an all-Java replacement for make, and is fully cross-platform. Note: You will also need to download the jakarta-ant optional.jar file if using certain versions of Ant. See [[ANT]] section for further details
* If you wish to run the test suite you will need JUnit 3.6 from [http://www.junit.org/ here].
* You will also need the latest version of the PCGen source code available from SVN. See [[Subversion Setup]] for details.

Open a command window and change to the root directory/folder where you installed the PCGen source code. There should be a file called build.xml there.

Type ant clean at the command prompt. This will make sure you have a clean start. Then run ant. This will build the pcgen.jar file. The jar file will be in ./bin. You can run pcgendev.bat or pcgendev.sh to run it or manually copy the jar file to the PCGen root directory.

'''NOTE'''
* If you get a "Could not create task of type: javacc" you need to ensure you have the jakarta-ant optional.jar file in the $ANT_HOME/lib directory. (You only need this for older versions of Ant).
* If you get a "Could not create task of type: junit" you need to copy the junit.jar file from the pcgen/libs directory to the $ANT_HOME/lib directory. (You only need this for older versions of Ant).

To generate the JavaDocs use ant docs, and for deployments you can use ant deploy, and finally ant all does all of the above (clean, build, docs, deploy), and ant complete does everything including a full testing cycle (which can take a while).

Typing the command <pre>ant</pre> will build the code and run a small selection of tests.

Typing the command <pre>ant dotest</pre> will build the code and run the full test suite.

Typing the command <pre>ant reporttest</pre> after running the tests will generate a test report. The xml result files are generated while running the tests, they can be found in ./code/build/test-results/xml/ after making the reporttest target, a browsable set of html reports can be found in ./code/build/rpt/test-results/

=Using Eclipse to build PCGen=

You can build PCGen from within Eclipse. You will need to do a little bit of setup first though:
# Go to Window > Preferences, then Ant > Runtime then select Ant Home Entries under the Classpath tab.
# Click Add Jars. Select the junit.jar under pcgen/lib.
Now you should be able to select the build.xml, right click and hit Run > Ant Build and it should work.

==Running and debugging==

# Open the PCGen project.
# Open the Run dialog by right-clicking on the PCGen project and selecting Run As > Run Configurations
# Select the Java Application node.
# Press the New button for a new configuration. Edit by field, thus:
Name -> PCGen

Main class -> pcgen.system.Main

VM arguments (Arguments tab) -> -Xmx1024M
# Press Apply to save the configuration.
# Press Run to start PCGen.

You can also run a single test by right clicking on the test and selecting Debug > JUnit Test. This is a great way to track through a bug too.

=Using IDEA to build PCGen=

You can build PCGen from within IDEA. You will need to do a little bit of setup first though:
# Go to the Window > Tool Windows > Ant Build. Press the [+] button to add a build file.
# Navigate to and select the build.xml Ant script in the root of the PCGen project tree. Press Ok.

You can now select any Ant target you wish. Particularly helpful are the build and fetch-data targets.

==Running and debugging==

NB - IDEA will build the software sufficient for running and debugging within the IDE automatically just by following these step. This is not the same as the build from the Building section, above, which builds the software suitable for command-line use.

# Open the PCGen.ipr project file.
# Get the Run/Debug Configurations dialog with Run > Edit Configurations from the menu bar.
# Select the Application tab.
# Press the [+] button for a new configuration. Edit by field, thus:
Name -> PCGen

Main class -> pcgen.system.Main
# Uncheck Display settings before running/debugging.
# Press Ok.

You can now run PCGen with the green right-pointing triangle on the toolbar and debug with the green right-facing beetle on a blue diamond. Or just use the Run menu.

=Using Maven to build PCGen=

See [[MAVEN]]

PCGen Code Exploration Almanac

2013-10-18T12:17:26Z

James: Initial page

Code

2013-10-18T12:11:41Z

James: /* Coding */

{| align="right"
| __TOC__
|}

=Introduction=
Welcome to the Wiki section for the Code Monkey team!

=Mission Statement=
'''TBA'''

=Resources=
* [[Developers Meeting]]
* [[Dev Meeting Log 20120309]]
* [[Dev Meeting Log 20120429]]
* [[Dev Meeting Log 20121103]]

==For New Starters==
* [[Joining the Code Team]] General steps to take to prepare yourself
* [[Code Monkey Introduction]]

==Developer Environment==
* [[Basic Developer Setup]]
* [[Subversion Setup]]
* [[Merging]] with SVN
* [[Building PCGen]], also see [[ANT]] and [[MAVEN]]
* [[Continuous Integration]]

==Coding==
* [[Coding Standards]]
* [[Deprecating a Token]]
* [[Explanation of the Code Base]]
* [[PCGen Code Exploration Almanac]]
* [[Graph Theory]]
* [[Logging in the Code Base]]
* [[Unit Testing]]
* [[Removing Libraries]]
* [[Unnecessary Code Detector]]

=Completed Sub Projects=
* [[Ability Object TODO List]]
* [[LST_Editor_Verification]]

=Open Sub Projects=
* [[Internationalization]]
* [[CDOM]]
* [[UI Overhaul]]
* [[LST_Editor]]
* [[Major Code Projects]]
* [[Template Engine]]

=Active Team Members=

===[[Explanation of Teams#Silverback|Silverback]]===
* [[James Dempsey]]

===[[Explanation of Teams#Second|2nd]]===
* TBA

===[[Explanation of Teams#Chimp|Chimp]]===
* [[Tom Parker]]

===[[Explanation of Teams#Gibbon|Gibbon]]===
* Jayme Cox
* [[Stefan Radermacher]]

===[[Explanation of Teams#Tamarin|Tamarin]]===
* [[Andrew Wilson]]
* [[Martijn Verburg]]
* [[Connor Petty]]

===[[Explanation of Teams#Lemur|Lemur]]===
* [[Eddy Anthony]]
* Per Christian Henden
* Thomas Cooper
* [[Tod Milam]] - Mac Developer
* [[Kim Winz]]

===[[X-Terminator Mark II]]===
* [[Greg Bingleman]] - [http://www.codemonkeypublishing.com Code Monkey Publishing]

===Other===
* Brad Stiles, SVN advice
* Jason Buchanan, Advice on old code
* [[Jonas Karlson]], Advice on old code

=Passive Team Members=

* B. K. Oxley (Provides IntelliJ licenses)

=Inactive Team Members=

===[[Explanation_of_Teams#2nd|2nd]]===
* Devon Jones

===[[Explanation_of_Teams#Chimp|Chimp]]===
* Aaron Divinsky

===[[Explanation_of_Teams#Tamarin|Tamarin]]===
* Andriy Sen
* [[Kevin Fernandes]]
* [[Koen Van Daele]]
* [[Joe Frazier, Jr.]]
* Per Christian Henden

===[[Explanation_of_Teams#Lemur|Lemur]]===
* Bill Neumann
* Dan Parks
* [[Eduard Martinescu]]
* Eric Jarman
* Jasper Spaans
* Julio Esslinger Viegas
* Peter Barker
* [[Rick Ryker]]
* Thomas Clegg
* Tony Lavalle
* Hades Lucifer [7/20/10]
* Josh Johnston [7/20/10]
* MotorViper [7/20/10]
* [[Steven West]] [7/20/10]
* [[Alec Ross]] [7/20/10]
* [[Tir Gwaith]] [7/20/10]

===Other===
* [[Andargor]], Suggestions
* [[Bryan McRoberts]], Advice on old code
* Kurt Wimmer, Suggestions
* Walter Duncan, Held the old pcgen_autobuild user

Roadmap

2013-08-06T11:59:27Z

James: /* Releases */

{| align="right"
| __TOC__
|}
=Introduction=

This page contains the PCGen Roadmap

=Releases=
* [[Release 5.6.x]] - There is no further active development on this branch
* [[Release 5.8.x]] - 5.8.1 was last production release of this branch, there is no further active development
* [[Release 5.10.x]] - 5.10.2 was the last production release of this branch, there is no further active development
* [[Release 5.12.x]] - 5.12.1 was the last production release of this branch, there is no further active development
* [[Release 5.14.x]] - 5.14.1 was the last production release of this branch, there is no further active development
* [[Release 5.16.x]] - 5.16.4 was the last production release of this branch, there is no further active development
* [[Release 6.0.x]] - Release 6.0.1 is the current production release
* [[Release 6.2.x]] - Release 6.2.0 will contain various feature enhancements to PCGen
* [[Release 6.4.x]] - Release 6.4.0 will contain various feature enhancements to PCGen

=Planning=
* [[Proposed FREQ Roadmap]]

Release 6.4.x

2013-08-06T11:57:28Z

James: Created page with "{| align="right" | __TOC__ |} =Release dates= TBA =Team Goals= ==Architecture== TBA ==Code== * LST Editor overhaul * Freemarker implementation for output..."

{| align="right"
| __TOC__
|}

=Release dates=

TBA

=Team Goals=

==[[Architecture]]==

TBA

==[[Code]]==
* [[LST Editor]] overhaul
* Freemarker implementation for output sheets

==[[Data]]==
TBA

==[[Output Sheets]]==
TBA

==[[Documentation]]==
TBA

==[[Publisher Liaison]]==
* No major projects, continuation of existing work

==[[Data License]]==
* No major projects, continuation of existing work

==[[Advertising]]==
* No major projects, continuation of existing work

Release 6.2.x

2013-08-06T11:55:44Z

James: Starting Page

{| align="right"
| __TOC__
|}

=Release dates=

We are aiming to release 6.2.0 in Nov-Dec 2013.

=Team Goals=

==[[Architecture]]==

* Further implementation of [[CDOM]] (Character Document Object Model), led by [[Tom Parker]]
* Continuation of [[Architecture Changes 5.17]], led by [[Tom Parker]]

==[[Code]]==
* Consolidation of the new user interface, lead by [[James Dempsey]]

==[[Data]]==
* There are no specific plans for new data sets although as always there will be some sets included as part of this release. Since we can now roll out data sets in between official releases this will simply be an ongoing process. You can check a number of places to see if a favourite data set is being actively worked on at:

* [http://jira.pcgen.org/browse/NEWSOURCE New Data Source Development for 6.2]
* [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DATA+AND+issuetype+%3D+%22New+Feature%22+ORDER+BY+fixVersion%2C+Status%2C+priority+DESC Data Feature Requests for 6.2]

==[[Output Sheets]]==
* Various minor updates to the existing sheets and their structure.

==[[Documentation]]==
* Various minor enhancements

==[[Publisher Liaison]]==
* No major projects, continuation of existing work

==[[Data License]]==
* No major projects, continuation of existing work

==[[Advertising]]==
* No major projects, continuation of existing work

Basic Developer Setup

2013-07-23T21:21:08Z

James: /* Setting up with Eclipse */

{| align="right"
| __TOC__
|}
=Introduction=

# Get a JAVA IDE of your choice (most people use Eclipse; some prefer IDEA). There are already project files in Subversion for several IDEs. (Although /bin/vi works just fine for some of us crusty old-timers, and Emacs for those sorts who are the GNU elite.)
# Get a Subversion client and set it up (most people use Eclipse integration; ditto for IDEA - see below for instructions for these though), see the [[Subversion Setup]] for details (you can view this via the web access to SVN).
# [[James Dempsey]] is the official Help New Code Monkeys guy, feel free to bug him lots! (But try the lists first, please.)

=Participating in PCGen=

# Play nice. Use common sense. We're all here because we enjoy it and want to participate in this project. Challenging ideas is ok (all of us will not always agree on a specific point), but don't attack people (no flames!)
# Make sure to run the unit tests (given that I can't get PCGen to build in ant without running them, this probably won't be hard!) and only check in when they all pass. Having said that, I suspect we've all broken the code at least once, so *don't stress* about it if it happens. Just participate in fixing it or get help from someone who can (if you really have no idea what's broken).
# If you're changing LST Token syntax (from our data files) then you need to get permission from the Data monkeys. You will find them on the PCGen_experimental Yahoo! group and you can also read their [[LST Syntax FREQ]] Usually, items in the issue tracking system as feature requests are already vetted by the _experimental folks, but if it's pretty old or very complicated, a double check doesn't hurt.
# Try to change as little of the formatting in the code as possible. Others may look at your check-in (to ensure it isn't interacting with other items we are working on that aren't checked in yet), and if the check-in is mostly formatting change, one loses the content. If there are formatting changes to be made, they should be done in a separate check-in. It is preferable to ask permission on significant formatting changes, since they make merging very difficult, and if one of us has a large project we are working on, it can become really hard to keep up and make sure we are actually doing useful work rather than formatting changes.
# Given the formatting comment above as more important, there are [[Coding Standards]] (for braces and the like).
# No major feature changes in a beta cycle - that's what the Alphas are for. Betas fix bugs for releases.
# You won't always know everything that is happening... but knowing where not to be is useful. Generally, in cases where someone is the major owner of an in-process change, it is best to check with that individual if you intend to propose/make major changes in code they are actively changing. When large check-ins are involved as components develop, parallel changes can be hard to deal with.

=Setting up with Eclipse=

# Install the subclipse extension found [http://subclipse.tigris.org/ here] or follow the instructions [http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA here]
# Switch to the SVN Exploring Perspective (e.g. via the menu item Window > Open Perspective > Other... )
# Create a new Repository Location for ''svn://svn.code.sf.net/p/pcgen/code/'' or ''svn+ssh://userid@svn.code.sf.net/p/pcgen/code/'' if you have commit access See [[Subversion_Setup]] for full details.
# Drill down to Trunk/pcgen and right click and select Checkout...
# Fill in the project details and wait while it downloads all of the source.
# Build the application '''using ant''' as this will create the '''code/build/src''' folder. (See Eclipse section in [[Building PCGen]])
# Refresh the project (right click on the project and select Refresh)
# Now your project should have no red ink and you can create a Run entry for the class pcgen.gui.pcGenGUI (Again see Eclipse Running section in [[Building PCGen]])

Any questions, don't hesitate to ask!

=Setting up with Netbeans (without the maven plugin)=
# Install the netbeans subversion plugin
# Checkout the Trunk/pcgen branch and if it asks to scan for projects select No.
# Go to menu and create a new java free form project. For the locations select the directory you just checked out and netbeans should fill the rest of the information for you.
# Compile the project
# Close netbeans
# replace the project.xml file in the nbproject dir with this file:[https://pcgen.svn.sourceforge.net/svnroot/pcgen/Trunk/IDE/project.xml project.xml]
# download the [https://pcgen.svn.sourceforge.net/svnroot/pcgen/Trunk/IDE/license-pcgen.txt license file]
# Reopen netbeans, go to Tools->Templates and add the license file to the Licenses category.
# Now your are ready to go!

=Tools and IDE Plugins=

Outside of Eclipse if you want to do independent testing and code coverage, Emma: http://emma.sourceforge.net/

==Eclipse==

* [http://pmd.sourceforge.net/ PMD]
* [http://findbugs.sourceforge.net/ FindBugs]
* [http://checkstyle.sourceforge.net/ Checkstyle]
* [http://sourceforge.net/projects/metrics Metrics]
* [http://www.eclipse.org/tptp/ Eclipse TPTP] (note: gets memory hungry)

Meeting 2013 06 22

2013-06-22T09:32:45Z

James: Created page with "=Board of Directors Meeting on 22nd June, 2013= * Status: Quorum (3 silverbacks) * Duration: 80 minutes ==Attending:== * Andrew Maitland [Acting Chair, Silver Back for Admin,..."

=Board of Directors Meeting on 22nd June, 2013=
* Status: Quorum (3 silverbacks)
* Duration: 80 minutes

==Attending:==
* Andrew Maitland [Acting Chair, Silver Back for Admin, 2nd for Content/Data]
* James Dempsey [Silverback for Code]
* Tom Parker [Silverback for Architecture]
* Stefan Radermacher [Code Gibbon, Data Chimp]

==SUMMARY:==
* Next alpha due 1 July 2013; a Final 6.0 Branch will be release after the pending sets are finished.
* Code: welcome to Mark Schrijver; Mostly break fix work in the past fortnight, plus new features to support data.
* Content: AEG - Empire released
* Data Sets being worked on Ultimate Equipment (Paizo), Bestiary 3 (Paizo) which is close to the finish line, Advanced Races Guide (Paizo) is now in License Review.
* Admin: Anestis and Jamie got the Website live - pcgen.org
* We have a presence on GitHub now, need to plan move of primary repo there.
* Proposal to split current data/d20ogl folder into data/gamemode folders (then publisher/setting/book structure under there) - Accepted for trunk
* Proposal for new LST file naming standard (and rules package support) will be posted to pcgen_experimental list for discussion.
* Next meting to be at a euro friendly time - to be discussed on BoD list

==RAW LOG:==
* [8:25] [Chair]Drew: *Bangs Gavel* Welcome all to our Board of Directors meeting, 1524 hours (PDT?), on June 21st, 2013
* [8:25] [Chair]Drew: Our full agenda of items today is:
* [8:25] [Chair]Drew: Agenda Items:
* [8:25] [Chair]Drew: * Team Reports (Code, Arch, Content, Admin, PR)
* [8:25] [Chair]Drew: ** Code - GIT Report - How is GITHUB working out?
* [8:25] [Chair]Drew: ** Code - Outside Projects report? (We had a server project, Chris Dolan's Drools Project, etc. Do
* [8:25] [Chair]Drew: we know where these projects are presently?)
* [8:25] [Chair]Drew: ** Code - Unit Tests updates and reports? Code Coverage status?
* [8:25] [Chair]Drew: ** Code - Clean up of Code?
* [8:25] [Chair]Drew: ** Web (Website is live, how about the Forum?)
* [8:25] [Chair]Drew: ** Content - Book Updates - B3 and ARG book statuses
* [8:25] [Chair]Drew: ** Content - Data Directory Restructuring and file naming standardization - Stefan and Andrew proposals
* [8:25] [Chair]Drew: ** Content - OS Directory set up - With the File Path in place, making sure the OS directory is set
* [8:25] [Chair]Drew: up correctly is imperative
* [8:25] [Chair]Drew: * Status of Team Meetings - Are the teams having any meetings?
* [8:25] [Chair]Drew: * Road Map Update - where are we, and where are we going? Is 6.0 on track, and how are we looking
* [8:25] [Chair]Drew: for 6.2?
* [8:25] [Chair]Drew: * Board of Directors - Are they still all present and active? We haven't a Quorum meeting in a long
* [8:25] [Chair]Drew: time. Are the meeting times still the best for the majority? (Do we have a status on Tom Parker -
* [8:25] [Chair]Drew: Arch SB, and on Barak - Content SB; Are we seriously letting Karianna step down as Chair? - Finds
* [8:25] [Chair]Drew: the Ninja Monkeys!)
* [8:25] [Chair]Drew: * Board of Directors - Are we still on task for our Mission Statement?
* [8:25] [Chair]Drew: * Open forum - Other discussions
* [8:26] [Chair]Drew: Let's begin with Team Reports - James, the floor is yours. :)
* [8:27] James[Code_SB]: ok, so first the stats
* [8:27] James[Code_SB]: Features: 9 created and 5 resolved, Bugs: 7 created and 9 resolved, New tags: 2 created and 4 resolved - all since the last meeting
* [8:28] James[Code_SB]: Stefan has been powering through some nice tidy ups to our export code
* [8:28] James[Code_SB]: We've also had a new code monkey join the team: mark schrijver
* [8:29] James[Code_SB]: Welcome Mark!
* [8:29] James[Code_SB]: He has started looking at allowing file names to be clickable in the debug log (F10)
* [8:30] James[Code_SB]: I've made a but more progress on the retirement of the old choosers, with the radio button choosers now ported to the new ui
* [8:30] James[Code_SB]: as well as addressing a number of things that have cropped up
* [8:31] James[Code_SB]: Lastly I've added a new build to Jenkins which does a data test twice a day - it hasn't given a clean result yet so emails haven't been sent
* [8:31] James[Code_SB]: Any questions?
* [8:32] [Arch_SB]thpr: What part of the data is being tested?
* [8:33] James[Code_SB]: This is a load test to see if any errors are found loading the common data sets
* [8:33] James[Code_SB]: It also checks for orphaned or missing files
* [8:33] [Arch_SB]thpr: nice
* [8:34] [Chair]Drew: Sounds good. - Which tests are still failing?
* [8:34] James[Code_SB]: Yes it picked up a few issues before the 6.0.1 release and replicates what we often do manually
* [8:35] James[Code_SB]: Pathfinder: Equipment Shield (Heavy/Wooden) may not have both WEAPON and SHIELD Proficiencies, Equipment Shield (Light/Steel) may not have both WEAPON and SHIELD Proficiencies, Equipment Shield (Light/Wooden) may not have both WEAPON and SHIELD Proficiencies]
* [8:35] [Chair]Drew: Ah, the new one I raised a JIRA for.
* [8:35] James[Code_SB]: 3e:
* [8:35] James[Code_SB]: data/d20ogl/srd/psionics/srd_spells_psionic.lst (385): PObject Contingency not found; .MOD skipped.,
* [8:35] James[Code_SB]: data/d20ogl/srd/psionics/srd_spells_psionic.lst (440): PObject Fabricate not found; .MOD skipped.,
* [8:35] James[Code_SB]: data/d20ogl/srd/psionics/srd_spells_psionic.lst (462): PObject Grease not found; .MOD skipped.,
* [8:35] James[Code_SB]: data/d20ogl/srd/psionics/srd_spells_psionic.lst (490): PObject Invisibility Purge not found; .MOD skipped.,
* [8:35] James[Code_SB]: data/d20ogl/srd/psionics/srd_spells_psionic.lst (582): PObject Telekinetic Sphere not found; .MOD skipped.,
* [8:35] James[Code_SB]: data/d20ogl/srd/psionics/srd_spells_psionic.lst (585): PObject Teleportation Circle not found; .MOD skipped.
* [8:36] [Chair]Drew: Alright, I'll look into those after the meeting then
* [8:36] James[Code_SB]: and that affects xcrawl also
* [8:36] Zaister: these probably all need to be "Spell Name (Psionic)"
* [8:36] James[Code_SB]: Also got one for spycraft
* [8:36] [Chair]Drew: Yeah. (Can we toss these into a JIRA?)
* [8:36] James[Code_SB]: sure
* [8:36] James[Code_SB]: one for the lot?
* [8:36] [Chair]Drew: Thanks.
* [8:36] James[Code_SB]: or split by game?
* [8:37] [Chair]Drew: Yeah, call it load test Errors
* [8:37] James[Code_SB]: ok
* [8:37] [Chair]Drew: Tom, you're up for an Arch report - we've missed these :)
* [8:38] [Arch_SB]thpr: I've been idle for some time. No report to make
* [8:38] [Chair]Drew: So, any plans?
* [8:38] [Chair]Drew: Goals?
* [8:39] [Arch_SB]thpr: get back up to speed on what is going on
* [8:39] [Arch_SB]thpr: Not sure there is much to say right now
* [8:39] [Chair]Drew: Cool, well welcome back. You've been missed.
* [8:39] [Chair]Drew: I guess it's my turn then for Content
* [8:41] [Chair]Drew: Content has been bustling. (James, Can you set me up a fancy filter to grab the numbers?) We've had a few bug fixes, several feature requests and some good progress with the books - AEG - Empire made it into the release, Bestiary 3 is getting close to the finish line, and Advanced Race Guide is now in License Review.
* [8:42] [Chair]Drew: We've had a resurgence in update requests to the RSRD materials, but we're hitting the same issue of it's not released via RSRD, so do we update or let it lie.
* [8:44] James[Code_SB]: Stats: http://jira.pcgen.org/secure/Dashboard.jspa?selectPageId=10270
* [8:44] [Chair]Drew: Our Pathfinder community is doing a fine job on keeping the data up to speed with their errata requests. We've had several people approach to work on Data sets, so hopefully we'll have some more data monkeys pushing updates here in the next month.
* [8:44] [Chair]Drew: Thanks James -
* [8:45] [Chair]Drew: Data Features 7 created, 5 resolved
* [8:45] [Chair]Drew: Data Bugs: 22 created, 21 Resolved
* [8:45] [Chair]Drew: Newsource - 2? Resolved (Empire and what else?)
* [8:45] jujutsunerd left the room (quit: Read error: Connection reset by peer).
* [8:46] [Chair]Drew: Off list, I've been hit up by 7 individuals for Character Help or Data set help
* [8:46] [Chair]Drew: the 'help@pcgen.org' has been very helpful in making our users happy.
* [8:46] James[Code_SB]: [Dreamscarred Press] Psionics Expanded - Pawns and Powers
* [8:47] [Chair]Drew: Thanks James
* [8:47] [Chair]Drew: Any questions for the Content side?
* [8:47] James[Code_SB]: If anyone wants to pitch in with Ultimate Equipment, they would be welcome
* [8:48] [Chair]Drew: I had a user volunteer, so you might be getting help in that direction
* [8:48] [Chair]Drew: ;)
* [8:48] James[Code_SB]: Excellent
* [8:48] [Chair]Drew: Admin Report:
* [8:49] [Chair]Drew: Anestis and Jamie got the Website live - pcgen.org, the web team is now working on a forum solution next.
* [8:50] [Chair]Drew: JIRA has an update out Major Development upgrade. James was waiting a bit to allow any fresh bugs get ironed out before we push it in
* [8:51] James[Code_SB]: See http://www.atlassian.com/software/jira/whats-new for what we will be getting
* [8:51] [Chair]Drew: Release - We're good for the next Alpha whenever James wishes to push it. 6.0 we're in a holding pattern for UE, B3.
* [8:52] [Chair]Drew: Questions?
* [8:53] James[Code_SB]: Next alpha is scheduled for 1 July - I've moved to a 3 week timeframe
* [8:54] James[Code_SB]: Just to add to that since the last meeting we've put out the 6.1.3 alpha
* [8:55] [Chair]Drew: Anyone got any thing for PR?
* [8:55] Zaister: did we hear back from Jason Bulmahn regarding Minotaur Games books?
* [8:56] James[Code_SB]: Also, could we get the latest couple of release up at http://pcgen.org/blog/ please
* [8:58] [Chair]Drew: @Stefan - Yes, IIRC we've got permission
* [8:58] Zaister: ah good
* [8:58] Zaister: I was cc'ed on the mail to Jason, but I never saw a reply, so I asked
* [9:01] [Chair]Drew: @James - I'll see about updating those
* [9:03] [Chair]Drew: Moving forward - CODE questions - GIT Report - How is GITHUB Working out? I saw a reply from Henk on this as well.
* [9:04] James[Code_SB]: Yep, we currently have a presence on github but have not moved to it as the primary source location
* [9:05] James[Code_SB]: We've had a few errors on sourceforge SVN lately, so to me that increases the incentive to move across
* [9:05] James[Code_SB]: However we still need the move planned out properly before starting
* [9:07] James[Code_SB]: That's all for that report
* [9:09] [Chair]Drew: my only with GIT is it's lack of sequential numbering for commits
* [9:09] [Chair]Drew: so if you have an issue, it's not readily apparent
* [9:10] James[Code_SB]: Yep, that's inherent with the DVCS design
* [9:10] [Chair]Drew: it does have a bit of a learning curve if you have experience with SVN, but for the push and pull it works nicely. I think we should all give it a test run with our GITHUB before making any move.
* [9:11] [Arch_SB]thpr: I think it just makes it more important to ensure that every commit has a JIRA associated with it rather than leaving it blank. That's probably a more important tracker than sequential #s
* [9:11] [Chair]Drew: True
* [9:11] [Chair]Drew: I've been giving it a bit of a play, and I didn't see the nice issue interface we're used to in SVN... am I missing something?
* [9:12] Zaister: do not confuse subversion in general with what you know from TortoiseSVN
* [9:12] [Chair]Drew: I likes my friendly GUIs
* [9:12] James[Code_SB]: No, you just put in the issue key into the comment, which is what the svn interface does anyway
* [9:13] [Chair]Drew: cool, so one less step then.
* [9:13] James[Code_SB]: Yep
* [9:13] Zaister: how specific is JIRA with that comment requirement?
* [9:14] James[Code_SB]: pretty lenient - it can be anywhere and just surrounded by whitespace and/or common punctuation
* [9:14] Zaister: ah ok
* [9:14] [Chair]Drew: Next Code question - Outside Projects - Drools, Android Port, Server Support - do we know how these developers/projects are going?
* [9:14] Zaister: nice
* [9:15] [Arch_SB]thpr: I think it's fair to call a few of those more like experiments than projects
* [9:15] [Chair]Drew: Project/Experiments ;)
* [9:16] [Arch_SB]thpr: The issue is less around semantics than around expectations. I don't think there is an expectation that Drools or the Android Port are on a path to become "real"
* [9:16] [Arch_SB]thpr: They are each, as programmers would put it, a "proof of concept"
* [9:17] [Chair]Drew: Gotcha, I had high hopes for the Server one.
* [9:17] [Arch_SB]thpr: I guess my point being they are interesting to mention that folks are trying them, but not necessarily something we should be trying to project manage
* [9:18] James[Code_SB]: @thpr yes agreed
* [9:18] [Arch_SB]thpr: I have to admit I'm not familiar with the server one or who was working that, so can't speak to it's reality
* [9:18] [Chair]Drew: I was looking to make sure they have support if they want it, but not manage.
* [9:19] [Chair]Drew: I'm drawing a blank on the name, I'd have to look in the log.
* [9:19] [Arch_SB]thpr: Chris isn't shy on _devel, so I don't have much worry he'll speak up if there is something he thinks would be useful
* [9:21] [Arch_SB]thpr: as an aside, I will need to bolt in ~15min
* [9:21] AndrewAAM: Javy_dreamer
* [9:22] James[Code_SB]: Yes I'll need to leave in a similar time frame
* [9:23] [Chair]Drew2: Okay, pressing forward then -
* [9:23] James[Code_SB]: We can skip the unit tests and cleanup reports - not sure why they are there - they are just things we do as normal
* [9:24] [Chair]Drew2: You and Stefan discussed the Data Re-organization?
* [9:24] [Chair]Drew2 is now known as [Chair]Drew
* [9:24] Zaister: no
* [9:24] James[Code_SB]: no
* [9:24] Zaister: just code stuff
* [9:25] [Chair]Drew: Okay, the quick gist of it - Pathfinder is becoming a bit 'huge' and we have 35e and Pathfinder mode stuff mixed together.
* [9:26] [Chair]Drew: The main thrust is to split the directory from d20ogl and make it gamemode folder specific
* [9:26] [Chair]Drew: data/gamemode/publisher/setting/book
* [9:26] [Chair]Drew: Stefan had a more radical idea for Pathfinder which he'll push into a proposal
* [9:26] Zaister: and in the meantime rename the files to use the new, mostly Paizo-official abbreviation in uppercase
* [9:27] Zaister: so pfapg_classes_base.lst -> APG_classes_base.lst
* [9:27] James[Code_SB]: the game mode approach does seem sensible
* [9:27] Zaister: I'll want to create some standards for file naming
* [9:27] James[Code_SB]: I'm not normally a fan of upper case abbreviations in file names though
* [9:27] Zaister: we have some unwritten ones which are not always followed
* [9:28] James[Code_SB]: If we do create standards, lets see if they can be enforced in the data test
* [9:28] Zaister: James[Code_SB]: this is to set off the book from the rest of the name
* [9:28] Zaister: another idea was to use double underscore, but I actually like the uppercase better, since these Abbreviations are usually uppercase anyway
* [9:28] [Chair]Drew: only the book abbr would use UPPER CASE
* [9:29] Zaister: for Pathfinder RPG books these are CR, APG, ARG, UC, UCA, UM, UE, B1, B2, B3
* [9:29] [Arch_SB]thpr: if the book is the directory name why is the book repeated in the file name?
* [9:29] Zaister: for convenience when editing these files, mostly
* [9:30] [Chair]Drew: a very good question - file names is what you see in the main editing programs.
* [9:30] [Chair]Drew: If you're in two files with 'abilities' it's nice to know which one you're in
* [9:30] James[Code_SB]: Yes the abbreviation in the file name is essential when you are comparing two files
* [9:30] Zaister: also useful if you do file operations at command line level
* [9:30] Zaister: otherwise you have a hundred different files all called feats.lst
* [9:30] [Arch_SB]thpr: expected some form of that answer, but wanted to ask anyway...
* [9:30] James[Code_SB]: That has been very helpful with UE when pulling data in from say ultimate combat and core rules
* [9:31] Zaister: my other idea is to try organize the data in a logical way instead of physically by book, if possible
* [9:32] Zaister: some books contained various rule "packages" a user might not always want all of
* [9:32] Zaister: and some rules are spread over multiple books
* [9:32] Zaister: you can see that in that we have all kind of stuff in the CR dataset that has noting to do with that book
* [9:33] Zaister: but I'm not yet sure how this would look
* [9:33] Zaister: and it would be a set of alternative PCC files, the book PCCS would not go away probably
* [9:34] [Chair]Drew: I actually think supporting both ideas is a winner. But most people will likely stick with the books.
* [9:34] [Chair]Drew: So, no objections, and Stefan, let's see a proposal on how the new idea would work. :)
* [9:34] Zaister: It's just an idea I've been thinking about :)
* [9:34] Zaister: yeah that will take a few days though :)
* [9:34] James[Code_SB]: Yes it would be interesting to see the proposal
* [9:35] [Arch_SB]thpr: agree, would be best to see it wrapped up in one description
* [9:35] Zaister: sure
* [9:35] [Chair]Drew: Unless people see a major issue, I'll slowly begin the data structure changes - starting with the less used ones.
* [9:36] [Arch_SB]thpr: umm, before we read the proposal?
* [9:36] Zaister: I'll draw up a naming standard for the pathfinder stuff over the weekend
* [9:36] [Chair]Drew: Stefan's proposal is separate from the Data Structure
* [9:36] [Chair]Drew: We're talking the Directory Structure by GameMode
* [9:36] [Arch_SB]thpr: So you're talking about the data/gamemode/blah stuff
* [9:36] [Chair]Drew: Yes
* [9:36] [Arch_SB]thpr: ok, I'm good with that
* [9:37] Zaister: including file renaming
* [9:37] Zaister: but not the "logical orgnaization of PCCs"
* [9:37] James[Code_SB]: Before we do that we'll need to warn the homebrewers as it will break their stuff
* [9:37] [Chair]Drew: Stefan's proposal is a new system and won't be enacted until we have a solid proposal
* [9:37] Zaister: definitely
* [9:37] James[Code_SB]: This should be in the 6.2 release only too , not try to squeeze it into 6.0.2
* [9:37] Zaister: yes
* [9:37] [Chair]Drew: Oh, dear lord only DEV
* [9:38] James[Code_SB]: That's for the folder reorg too
* [9:38] [Chair]Drew: Agreed
* [9:38] James[Code_SB]: Cool, it is good to have these things stated not assumed :)
* [9:38] [Chair]Drew: I'm only backporting bug fixes at this point
* [9:38] James[Code_SB]: and B3, ARG and UE ?
* [9:39] [Chair]Drew: Playing the 6.0 trunk tango is getting old... Yes, B3, ARG and UE are all slated for 6.0
* [9:39] James[Code_SB]: Oh agreed on the backporting
* [9:39] [Chair]Drew: after that, I'm happy to close 6.0 completely and focus on trunk
* [9:39] Zaister: sounds good
* [9:39] [Arch_SB]thpr: Anything else we need to touch on before I log?
* [9:40] James[Code_SB]: Which is why I'd like to have a new trunk release out later this year - get us away from needing to update the old stuff too often
* [9:40] Zaister: of course code support for those sets, if any, need to be backported too
* [9:40] [Chair]Drew: Nothing in those sets is trunk specific
* [9:40] Zaister: ok
* [9:40] James[Code_SB]: I've ported back most of what can be done
* [9:40] [Chair]Drew: the alternative NATURALWEAPON will be trunk only
* [9:40] James[Code_SB]: Absolutely
* [9:41] [Chair]Drew: I think we touched on the roadmap, any comments about Kar?
* [9:41] Zaister: what's up with him?
* [9:41] James[Code_SB]: Look, we need to get a meeting in a time suitable for the Europeans to discuss that one I think
* [9:42] James[Code_SB]: Lets hash out a time on the BoD group
* [9:42] [Chair]Drew: Fair enough.
* [9:43] [Chair]Drew: OKay folks, I think we're pushing two hours, so I'm happy to call this meeting and deal with the remainder on the BoD list.
* [9:43] [Chair]Drew: Any objections?
* [9:43] James[Code_SB]: Sounds good
* [9:43] [Arch_SB]thpr: agree, sounds good
* [9:43] [Chair]Drew: *Bangs Gavel* Meeting Adjourned

Meeting Logs

2013-06-22T09:06:15Z

James:

{| align="right"
| __TOC__
|}

This is a new section to hold the Meeting Logs.

=2013=
* [[Meeting_2013_06_22]]
* [[Meeting_2013_05_28]]
* [[Meeting_2013_05_10]]
* [[Meeting_2013_03_05]]
* [[Meeting_2013_02_01]]
* [[Meeting_2013_01_22]]
* [[Meeting_2013_01_04]]

=2012=
* [[Meeting_2012_12_11]]
* [[Meeting_2012_11_23]]
* [[Meeting_2012_11_09]]
* [[Meeting_2012_10_30]]
* [[Meeting_2012_10_12]]
* [[Meeting_2012_09_28]]
* [[Meeting_2012_09_18]]
* [[Meeting_2012_08_31]]
* [[Meeting_2012_08_17]]
* [[Meeting_2012_08_07]]
* [[Meeting_2012_06_26]]
* [[Meeting_2012_06_08]]
* [[Meeting_2012_05_25]]
* [[Meeting_2012_March_16]]

=2010=

* [[Meeting_2010_08_02]]
* [[Meeting_2010_07_19]]
* [[Meeting_2010_July_5]]
* [[Meeting_2010_June_7]]

Joining the Code Team

2013-04-15T08:44:55Z

James: /* Your first change */

{| align="right"
| __TOC__
|}

=Introduction=

A list of what to do to join the code team

=General steps=

# Get a [http://groups.yahoo.com Yahoo Groups] id.
# Be sure to subscribe to the [http://groups.yahoo.com/group/pcgen_developers/ Developer's mailing list]
# Introduce yourself on the list
# Find the [http://games.groups.yahoo.com/group/pcgen/ pcgen] project on Yahoo! Groups and join.
# Get as many IM IDs as possible (most people use Pidgin, Meebo or Gaim) and get online with them.
# Also join the IRC channel #pcgen on ~DALnet & ~Freenode, we have our meetings and group discussions there in real time.
# Get the latest official version of PCGen from SF and run it.
# Get an id at [http://sourceforge.net sourceforge].
# Find the [http://sourceforge.net/projects/pcgen pcgen] project.

=Your first change=
# Get your [[Basic Developer Setup|development environment set up]]
# Select an issue that interests you, either from our issues flagged as bitsize in the [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=component+%3D+Bitesize+AND+project+%3D+CODE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Code] and [http://jira.pcgen.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=component+%3D+Bitesize+AND+project+%3D+NEWTAG+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC New Tag] projects, or one you have encountered.
# Build a fix that fixes the bug or implements the new feature
# Test the fix, preferably by writing a unit test
# Send the fix as a patch to the developers list asking for a review.
# Your patch will be reviewed and friendly feedback provided by one of the team.

=Joining the team=

# Once our patch is accepted, the Code Silverback will add you the project on Sourceforge.
# Your first check-in will be your fix
# Your second should be adding your name to the team listing!
# Put your details in this wiki under the [[Code]] team!

Any questions, don't hesitate to ask!

Meeting 2013 01 22

2013-01-24T12:19:54Z

James: Created page with "{| align="right" | __TOC__ |} [http://wiki.pcgen.org/Meeting_Logs PCGen BoD Meeting Minutes Home] =Attendance= * Chair - James (Code SB) * Content - Eric (Docs) * Admin ..."

{| align="right"
| __TOC__
|}

[http://wiki.pcgen.org/Meeting_Logs PCGen BoD Meeting Minutes Home]

=Attendance=
* Chair - James (Code SB)
* Content - Eric (Docs)
* Admin - Paul (PR)
* Architecture - Tom (Arch SB)

=Summary=
* We will be releasing a 6.0.1 prod patch after 6.1.1 is out
* Next release is 6.1.1 - no holdups known
* We won't make early cutoff for Gencon but will need community support if we want to get a booth

=Log=
[13:11] James[Code_SB]: ok, so lets start 
[13:11] James[Code_SB]: The Agenda from Kar was 
[13:11] James[Code_SB]: * Are we planning a 6.0.1 release? 
[13:11] James[Code_SB]: * Can we settle on a definitive roadmap for 6.1.0? 
[13:11] James[Code_SB]: * A report on the data migration to 6.0.x data standards 
[13:11] James[Code_SB]: * PR - Are we going to Gencon - can we get the $200 deposit? 
[13:11] James[Code_SB]: So, lets start with releases 
[13:12] James[Code_SB]: The 6.0.1 release is waiting on 6.1.1, which is waiting on the go ahead from data 
[13:12] James[Code_SB]: Does anyone know how that data work is going? 
[13:13] [Arch_SB]thpr: I'm afraid Andrew is the expert on that 
[13:13] James[Code_SB]: Yes I suspected that 
[13:14] James[Code_SB]: So Tom, did you have anything you were aiming to include for the 6.1.1 release? 
[13:16] [Arch_SB]thpr: not specifically, no 
[13:16] [Arch_SB]thpr: None of the major things I'm working on would be ready and I wouldn't want to hold it up 
[13:17] James[Code_SB]: Sounds good then 
[13:17] James[Code_SB]: I've already committed some improvements to source selection and am also keen to get a better method of changing a character's sources in place 
[13:18] [PR]Nylanfs: Yes that is close to the number one first question 
[13:18] James[Code_SB]: It does seem to be a frequent one 
[13:19] James[Code_SB]: I'm also wondering if we should have a new quick source for pathfinder which is all player materials that includes all the sources we have coded such as UC, UM etc and we just keep adding the new stuff to that 
[13:20] James[Code_SB]: Anyone with anything else to raise for 6.1.1? 
[13:22] [DOC2nd]Maredudd: Nothing from Docs. 
[13:23] James[Code_SB]: ok, I am guessing the data conversion question is one for Andrew, so we'll leave that 
[13:24] James[Code_SB]: So gencon 
[13:25] [PR]Nylanfs: That weould be me :) 
[13:25] [PR]Nylanfs: Okay if we want to get registered by tomorrow a booth would be $1400, $700 of which would be due immediately 
[13:26] [PR]Nylanfs: Waiting would only bump the price by $200 (to $1600) 
[13:26] [PR]Nylanfs: At this point I think getting registered and check/CC sent by tomorrow is a little late. 
[13:26] [Arch_SB]thpr: and we have like $19 in the bank or something? 
[13:27] [PR]Nylanfs: Yes $19.55 after paying for the website hosting last month 
[13:28] [Arch_SB]thpr: seems to me there's a bit of a budget discussion there that makes getting registered a bit impractical 
[13:28] James[Code_SB]: So unless we get a lot of community interest it doesn't look like a booth on our own is realistic 
[13:29] [Arch_SB]thpr: That takes seeing what we can get by the final cutoff, but I think for the immediate discussion there is no way to register early 
[13:30] [PR]Nylanfs: Yes I was planning on doing a Mailing list/FB and Twitter posts to drum up interest. 
[13:31] [Arch_SB]thpr: What's the final cutoff? 
[13:31] [PR]Nylanfs: April 23rd? I believe 
[13:31] [PR]Nylanfs: April 3rd, final deposit by May 1st 
[13:32] [Arch_SB]thpr: ok. Why don't you catch up with Kar on his status and then we can evaluate what plan would need to be put together to support a booth 
[13:34] [PR]Nylanfs: I cover the costs of my badge, flyers, and meals so basically the only cost is the both and some minor incidentals 
[13:35] [PR]Nylanfs: I think that's it for GenCon from me 
[13:35] James[Code_SB]: ok, anything else to report or raise from anyone? Any open questions? 
[13:36] [DOC2nd]Maredudd: I got a question. 
[13:36] James[Code_SB]: sure 
[13:36] [DOC2nd]Maredudd: Are we planning on OOC data sets for 6.0.0? 
[13:37] James[Code_SB]: not for 6.0.0, we would use 6.0.1 for that I expect 
[13:37] James[Code_SB]: Particularly as there has been a big data reorg so it would get complex 
[13:38] [DOC2nd]Maredudd: If they get in by then . . . :-) 
[13:38] Swiftbrook: Just a comment: I've been using 6.0.0 in Pathfinder heavily for the past month and it's working great. Nice job folks. 
[13:39] [PR]Nylanfs: :) 
[13:39] James[Code_SB]: Great to hear - thank-you 
[13:40] James[Code_SB]: ok, any last questions or issues? 
[13:42] [DOC2nd]Maredudd: None here. 
[13:42] James[Code_SB]: ok, then meeting closed 
[13:42] James[Code_SB]: Thanks for coming along everyone

Meeting Logs

2013-01-24T12:05:52Z

James: /* 2013 */

{| align="right"
| __TOC__
|}

This is a new section to hold the Meeting Logs.

=2013=
* [[Meeting_2013_01_22]]
* [[Meeting_2013_01_04]]

=2012=
* [[Meeting_2012_12_11]]
* [[Meeting_2012_11_23]]
* [[Meeting_2012_11_09]]
* [[Meeting_2012_10_30]]
* [[Meeting_2012_10_12]]
* [[Meeting_2012_09_28]]
* [[Meeting_2012_09_18]]
* [[Meeting_2012_08_31]]
* [[Meeting_2012_08_17]]
* [[Meeting_2012_08_07]]
* [[Meeting_2012_06_26]]
* [[Meeting_2012_06_08]]
* [[Meeting_2012_05_25]]
* [[Meeting_2012_March_16]]

=2010=

* [[Meeting_2010_08_02]]
* [[Meeting_2010_07_19]]
* [[Meeting_2010_July_5]]
* [[Meeting_2010_June_7]]

File:Win Installer Components.png

2012-12-29T21:54:48Z

James:

Meeting 2012 12 11

2012-12-12T08:06:07Z

James:

'''Attendance:'''
* Chair - James (Code SB)
* Content - Eric (Docs)

'''SUMMARY:'''
* SF Update completed with some hiccups
* Next release will be early next year
* Some confusion about the start time with the reminder in UTC+11 time zone (AEDT)

'''Log'''

[13:15] jamesd[Code_SB]: Well, might do a quick meeting then 
[13:17] [Doc]Maredudd: Well, what do we talk about? 
[13:18] jamesd[Code_SB]: Well from the code side not a huge amount 
[13:18] jamesd[Code_SB]: I've had a bit of a break 
[13:18] jamesd[Code_SB]: and am starting back into some dev work 
[13:19] jamesd[Code_SB]: Tom has started some tidy up of the facets, as discussed in an earlier dev meeting 
[13:19] jamesd[Code_SB]: On the admin side, the migration to the new SourceForge resources has been completed but wasn't painless. 
[13:20] [Doc]Maredudd: Amazingly it was nearly painless for me . . . 
[13:20] jamesd[Code_SB]: However Jira and Jenkins are now pointing to the new SVN repo and the majority of contributors seem to have made it across too. 
[13:20] jamesd[Code_SB]: Good to hear 
[13:21] jamesd[Code_SB]: Have you committed changes yet? 
[13:21] [Doc]Maredudd: For Admin, or rather Release, did you see the JIRA I opened for a users problem with PCGen on Mac OSX 10.8? 
[13:21] [Doc]Maredudd: Yes I have. At least I think I have. 
[13:22] jamesd[Code_SB]: yeah I did see that one - was a bit odd 
[13:22] jamesd[Code_SB]: Any ideas on what might have changed? 
[13:24] [Doc]Maredudd: Not yet. I've asked Stefan to look at it but haven't heard anything from him. I'll have some time next week to look at it, but as I have little dev experience I'm not sure what I can do. I'll at least dig around to see if similar issues have arrisen in other JAVA programs. 
[13:25] [Doc]Maredudd: I will also follow up with looking at my release process and setup. 
[13:25] jamesd[Code_SB]: Yeah I can't really do much testing either 
[13:25] [Doc]Maredudd: I need to check when I moved to Eclipse Juno. 
[13:25] jamesd[Code_SB]: It isn't the new Mac OS security model is it? 
[13:26] [Doc]Maredudd: It didn't look like it. 
[13:26] [Doc]Maredudd: I'll startup a dialog with the OP. 
[13:26] [Doc]Maredudd: btw, I moved back to Helios. 
[13:27] [Doc]Maredudd: I couldn't get the ANT script for zipping files to work on Juno. 
[13:29] jamesd[Code_SB]: Very odd - I'll be upgrading over Christmas so I'll give it a go then 
[13:30] [Doc]Maredudd: Cool. I'll be interested in any issues you identify. 
[13:30] jamesd[Code_SB]: Just to wrap up the admin side, I think we'll wait until after new year now for the next builds - both an RC for a patch to 6.0.0 and the first 6.1 alpha 
[13:30] jamesd[Code_SB]: That is unless there are objections or anything urgent 
[13:31] [Doc]Maredudd: Sounds like a plan. 
[13:33] [Doc]Maredudd: As the only Content team member I can only report that Andrew continues to move data sets out of the alpha folder. 
[13:34] [Doc]Maredudd: The docs have seen little work since 6.0 came out but will see more work over the holiday. 
[13:35] [Doc]Maredudd: Additionally, there are a number of new sources that we have recieved permission for that are looking for Data Monkey to work them. 
[13:36] jamesd[Code_SB]: Great to hear we have new permissions 
[13:36] [Doc]Maredudd: Yep. 
[13:37] [Doc]Maredudd: Thats all I have for Content. 
[13:39] jamesd[Code_SB]: k, any questions from anyone else? 
[13:39] [Doc]Maredudd: I have a question concerning XML. Is that in the cards for PCGen in the future? 
[13:40] [Doc]Maredudd: Do we gain anything by one day moving to XML? 
[13:40] jamesd[Code_SB]: As a LST format? Noone is driving it currently so I can't see it happening 
[13:41] [Doc]Maredudd: Thats what I thought. I still pickedup the ownership of the pcgen_xml group. 
[13:42] jamesd[Code_SB]: Yes good to have it archived if we ever revisit it 
[13:43] [Doc]Maredudd: I do plan on doing something with the docs in that direction but I need to understand better how to approach it before I make a push. 
[13:43] jamesd[Code_SB]: Yes that's a different beast though :) 
[13:44] [Doc]Maredudd: Yep. 
[13:44] jamesd[Code_SB]: ok, anything else to raise? 
[13:45] [Doc]Maredudd: I'd like to get to the point where doing a conversion to PDF is nearly automatic, and that means moving to at least xhtml. 
[13:45] [Doc]Maredudd: Nope. 
[13:45] jamesd[Code_SB]: Yes that would be nice 
[13:45] jamesd[Code_SB]: ok, meeting closed then

Meeting 2012 12 11

2012-12-12T08:04:59Z

James: Log for today's meeting

'''Attendance:'''
* Chair - James (Code SB)
* Content - Eric (Docs)

'''SUMMARY:'''
* SF Update completed with some hiccups
* Next release will be early next year

'''Log'''

[13:15] jamesd[Code_SB]: Well, might do a quick meeting then 
[13:17] [Doc]Maredudd: Well, what do we talk about? 
[13:18] jamesd[Code_SB]: Well from the code side not a huge amount 
[13:18] jamesd[Code_SB]: I've had a bit of a break 
[13:18] jamesd[Code_SB]: and am starting back into some dev work 
[13:19] jamesd[Code_SB]: Tom has started some tidy up of the facets, as discussed in an earlier dev meeting 
[13:19] jamesd[Code_SB]: On the admin side, the migration to the new SourceForge resources has been completed but wasn't painless. 
[13:20] [Doc]Maredudd: Amazingly it was nearly painless for me . . . 
[13:20] jamesd[Code_SB]: However Jira and Jenkins are now pointing to the new SVN repo and the majority of contributors seem to have made it across too. 
[13:20] jamesd[Code_SB]: Good to hear 
[13:21] jamesd[Code_SB]: Have you committed changes yet? 
[13:21] [Doc]Maredudd: For Admin, or rather Release, did you see the JIRA I opened for a users problem with PCGen on Mac OSX 10.8? 
[13:21] [Doc]Maredudd: Yes I have. At least I think I have. 
[13:22] jamesd[Code_SB]: yeah I did see that one - was a bit odd 
[13:22] jamesd[Code_SB]: Any ideas on what might have changed? 
[13:24] [Doc]Maredudd: Not yet. I've asked Stefan to look at it but haven't heard anything from him. I'll have some time next week to look at it, but as I have little dev experience I'm not sure what I can do. I'll at least dig around to see if similar issues have arrisen in other JAVA programs. 
[13:25] [Doc]Maredudd: I will also follow up with looking at my release process and setup. 
[13:25] jamesd[Code_SB]: Yeah I can't really do much testing either 
[13:25] [Doc]Maredudd: I need to check when I moved to Eclipse Juno. 
[13:25] jamesd[Code_SB]: It isn't the new Mac OS security model is it? 
[13:26] [Doc]Maredudd: It didn't look like it. 
[13:26] [Doc]Maredudd: I'll startup a dialog with the OP. 
[13:26] [Doc]Maredudd: btw, I moved back to Helios. 
[13:27] [Doc]Maredudd: I couldn't get the ANT script for zipping files to work on Juno. 
[13:29] jamesd[Code_SB]: Very odd - I'll be upgrading over Christmas so I'll give it a go then 
[13:30] [Doc]Maredudd: Cool. I'll be interested in any issues you identify. 
[13:30] jamesd[Code_SB]: Just to wrap up the admin side, I think we'll wait until after new year now for the next builds - both an RC for a patch to 6.0.0 and the first 6.1 alpha 
[13:30] jamesd[Code_SB]: That is unless there are objections or anything urgent 
[13:31] [Doc]Maredudd: Sounds like a plan. 
[13:33] [Doc]Maredudd: As the only Content team member I can only report that Andrew continues to move data sets out of the alpha folder. 
[13:34] [Doc]Maredudd: The docs have seen little work since 6.0 came out but will see more work over the holiday. 
[13:35] [Doc]Maredudd: Additionally, there are a number of new sources that we have recieved permission for that are looking for Data Monkey to work them. 
[13:36] jamesd[Code_SB]: Great to hear we have new permissions 
[13:36] [Doc]Maredudd: Yep. 
[13:37] [Doc]Maredudd: Thats all I have for Content. 
[13:39] jamesd[Code_SB]: k, any questions from anyone else? 
[13:39] [Doc]Maredudd: I have a question concerning XML. Is that in the cards for PCGen in the future? 
[13:40] [Doc]Maredudd: Do we gain anything by one day moving to XML? 
[13:40] jamesd[Code_SB]: As a LST format? Noone is driving it currently so I can't see it happening 
[13:41] [Doc]Maredudd: Thats what I thought. I still pickedup the ownership of the pcgen_xml group. 
[13:42] jamesd[Code_SB]: Yes good to have it archived if we ever revisit it 
[13:43] [Doc]Maredudd: I do plan on doing something with the docs in that direction but I need to understand better how to approach it before I make a push. 
[13:43] jamesd[Code_SB]: Yes that's a different beast though :) 
[13:44] [Doc]Maredudd: Yep. 
[13:44] jamesd[Code_SB]: ok, anything else to raise? 
[13:45] [Doc]Maredudd: I'd like to get to the point where doing a conversion to PDF is nearly automatic, and that means moving to at least xhtml. 
[13:45] [Doc]Maredudd: Nope. 
[13:45] jamesd[Code_SB]: Yes that would be nice 
[13:45] jamesd[Code_SB]: ok, meeting closed then