special checkout behavior for hardcoded ptolemy module names
org.kepler.build.Get.getModule(Module module) has special behavior when it comes across the modules with names: ptolemy, ptolemy-8.0, and ptolemy-kepler-2.3. This seems to allow checking out a specific revision of pII from the ptII repository. I added ptolemy-kepler-2.3, and not ptolemy-kepler-*, because for some reason ptolemy-kepler-2.2 has a "local" copy of ptII, and i don't want to change how 2.2 works.
We'll have to revisit this for 2.4.
#1 Updated by jianwu jianwu over 7 years ago
I changed the code locally from
"if (module.getName().equals(Module.PTOLEMY) || module.getName().equals(Module.PTOLEMY_8_0) || module.getName().equals(Module.PTOLEMY_KEPLER_2_3))"
to be "if (module.getName().startsWith(Module.PTOLEMY))".
With the changes, I think we do not need to change the code for each Kepler release. I think it is only used for module downloading when using the command like "ant change-to -Dsuite=kepler-2.3". My tests for it works.
Do you know whether it is used somewhere else?
#2 Updated by Derik Barseghian over 7 years ago
That looks similar to the regex I mentioned I didn't use so as not to change the checkout behavior of ptolemy-kepler-2.2. If you make that change, and someone tries to use 2.4 to checkout ptolemy-kepler-2.2, it will attempt to fetch it from the ptII repo and not ours, which is different to how things work for 2.2.
Instead you'd need something like !PTOLEMY_KEPLER_2_2 && startsWith(PTOLEMY_KEPLER). It's debatable whether this is better or worse than just appending one more fully specified PTOLEMY_KEPLER_2_4 variable.
If you do either of those, please don't close the bug, just push it back. The right solution is to remove as much behavior hardcoded to module names as possible.
I'd definitely look around to see what all the other hardcoded uses of "ptolemy" are for. At 27924 and 27949 I put a lot of the hardcoded "ptolemy" strings into variables, e.g. at the top of Module.java, so you can search your workspace for references to those.
#3 Updated by jianwu jianwu over 7 years ago
Thanks Derik. I didn't know Kepler 2.2 has ptolemy branch (namely ptolemy-kepler-2.2) at kepler svn yet other Kepler versions have ptolemy branch at ptolemy svn.
For Kepler 2.4, I think we will have ptolemy branch at ptolemy svn since Christopher said ptolemy will release a new version around the same time of Kepler 2.4 release, and Kepler 2.4 will use this new ptolemy version. So either change solutions you mentioned for this bug are good for Kepler 2.4.
For future Kepler releases, Ptolemy may or may not have new releases/branches. We can discuss this issue during the next release meeting and hopeful we can make a decision so this code does not need to be updated for every release.
If we decide to have a new Ptolemy branch at Ptolemy svn for each future Kepler release, we'd better use the condition like !PTOLEMY_KEPLER_2_2 &&
startsWith(PTOLEMY_KEPLER). If we will have a new Ptolemy branch at Kepler svn for each future Kepler release, we'd better use the condition like module.getName().equals(Module.PTOLEMY_KEPLER_2_3)) ||
module.getName().equals(Module.PTOLEMY_KEPLER_2_4). By this way, we can minimize the future changes for this class.
With current 4 release starting with Kepler 2.0, only Kepler 2.2 has ptolemy branch (namely ptolemy-kepler-2.2) at kepler svn. I don't know why. I think a better solution is to have a new Ptolemy branch at Ptolemy svn for each future Kepler release.
I checked your changes at 27924 and 27949, and don't think we need further changes except this part.