Yet another post on Windchill, GIT and customization management

[avillanueva]

I've been following the posts of the year's on Windchill development and how folks are managing their customizations and their steps for deployment. Being historically untrained and old school, I had opted for simplicity but these "bad habits" might be preventing me for moving forward. I have completed as restructuring of my Git repo and removed Eclipse compiled class files from its management. Just for context, I develop offline on my laptop pushing changes up to Bitbucket then down to the local repos on Dev, Test or Prod as needed. Feel free to throw stones at any point. I can duck, bob and weave. 

Now, I have been exploring  methods to automate or script build and deploy to the Windchill directory. Ant seems to be what I've chosen to work with for the moment. Historically, I've made use of the wtSafeArea and wtCustom area to stage updates and the "installSiteChanges" to push into codebase.  I also started looking at tools.xml scripts and it seems that these were designed with compilation straight into codebase, even options to delete all .class files (dangerous?). 

Since installSiteChanges pushes files into Windchill home in the relative folders, I've leveraged that siteMod as as the staging area which contains custom properties files, classes, JSP, resource bundles, scripts, xml config files and a static .xconf files. Its a bit of a hop here to hop there but just giving a sense of where I am currently. 

Build process in my head would work something like this:

• Update local repo
• Compile classes (incremental if possible, only what's changed)
• move class and non-class other files to wtSafeArea
• installSiteChanges
• Optionally update resource bundles if necessary (if changed)

A few questions and observations. 

• As mentioned, tools.xml assumes you are developing inside of Windchill install. Is this normal? Do you make use of this ant script or roll your own?
• Tools.xml seems to compile all, not incremental. So if source has not changed, class files are still re-compiled. Correct observation?
• I've been able to get "class" target to accept my repo as source and even change the build output folder. I would like to stage it since I would not proceed if there was a build failure. Good idea?

I will be heading to New Orleans so would chat more in person about this with folks. 

Current repo structure:

codebase has custom code, java source, JSP, properties files etc.

conf contains security labels modified file

src folder is my custom resource bundles

wtCustom is my modified resource bundles (additions and mods from PTC default)

other files would be stuff that appears at Windchill root.

[avillanueva]

Ok, some progress that I wanted to document more clearly than PTC documentation. Since my repo exists apart from the Windchill folder, I am taking an approach of moving in changed files and doing full compile of .java files or only differences. For the move, I found rsync to be helpful:

rsync -av --no-times --checksum --exclude '*.java' <repo folder> <staging folder>

My repo mirrors the Windchill structure so these just need to move to the relative folder location. Git timestamps cannot be relied on since it gets impacted by when you did a pull. I opted to compare checksums and sync if different.

For .java compilation, I did many tests with the tools.xml ant script which is included in the Windchill bin folder. The "class" target is what does the recompilation. Depending on options, it can recompile resource bundles as well though I think it does all or nothing. I also was able to provide options to point it to my repo and direct output to a folder of my choosing.

To do a full recompile, I used this command:

ant -f <wt_home>/bin/tools.xml class -Dclass.force=false -Dclass.source=<repo folder>/codebase -Dclass.includes=** -Dbuildroot=<staging folder>

The "class.includes=**" should direct to recurse to all subfolders but you can be specific to call out a certain package if you want. 

The "class.force=false" confused me since in the help notes and docs, they show this being set to "true". I found that the mere presence of this attribute was the trigger and the value did not matter. So, removing this caused an incremental build, like this:

ant -f <wt_home>/bin/tools.xml class -Dclass.source=<repo folder>/codebase -Dclass.includes=** -Dbuildroot=<staging folder>

So getting close to being able to script whole process. The tools.xml seems to have a lot of good stuff in it but it seems like it was built with the assumption you were developing inside of the Windchill folder directly, doing database modeling and modifications. Am I correct is stating there is a possibility to run an accidental clean and delete all PTC class files the the codebase? That would be terrible!

 <target name="class.clean"                   depends="class.init,class.check"
           if="class.force">
      <delete quiet="true">
         <fileset dir="${class.output}" includes="${class.includes}">
            <filename name="**/*.class"/>
         </fileset>
      </delete>
   </target>

[FabioValente]

Hi Avilla!
Thank you for share your progress!

I'm developing for Windchill about 3 years, and still looking for a good structure and organization.

For now i put everything on "<windchill>\src" directly and i need to manage (actually) 3 projects (Don't like to this way, but couldn't found another one betters yet).

I try to manage like this:
<wc\src> -> com -> <company>
Here i separated the folders:
. -> on root i got only the README.md and .gitIgnore
core -> Here i'm put all the main classes from my company that share a generic behavior (like my custom logger, epmDocument, wtPart, Persistable etc.)
esi -> Only data related stuff (adapters that record on Windchill, connector and fields definitions to re-use on load or write operations.
And here stay the integration folders (the ERP)
Inside each this folders there are a similar structure of the root
core -> The related classes to the company been integrated (custom masks, config etc.)
esi -> Here is the files that use on Windchill specific (like Adapters, WTPart extended, etc.) and to ERP ( custom fields objects, Persistable - like change status, write a log info into the windchill object to user communication etc.)
. -> And the root has the safe callers and the properties configuration definition to read on start process.

For now, all my integrations are started by a change state, it's not a automatic functionality (maybe on the future). 

I`ll test your incremental build.

And i`m got a doubt.
When you change some class, after compile, you need to restart the windchill to try the changes?
When in debug mode, sometime works "on the fly", but the major time not.

PS: I'm developing on VSCode.

Regards,