Merge with main JMRI?

[pabender]

Would it be beneficial to integrate XtrkCADreader into the main JMRI distribution?

Conceptually, this can be accomplished with an import option in the panels menu that would perform the current translation action of XtrkCADreader and then immediately open the panel.

These are the actions currently performed by users of XtrkCAD reader, but XtrkCAD reader isn't integrated into JMRI, so it requires running two seperate programs.

Paul

[mattharris]

I was thinking the same thing. But I've got some updates I'm working on right now that I'd like to finish off first.

[rhwood]

Would it be beneficial to integrate XtrkCADreader into the main JMRI distribution?

Yes, that would be awesome. But I'm going to suggest we don't. Instead I am going to suggest we figure out the bits we need to be able to add the XtrkCADreader JAR to the JMRI classpath so that once added, we get the same effect as integrating it into JMRI. I suggest this so that we a plugin capability in JMRI and ship a working demonstration of that capability.

[bobjacobsen]

Yes, that would be awesome. But I'm going to suggest we don't. Instead I am going to suggest we figure out the bits we need to be able to add the XtrkCADreader JAR to the JMRI classpath so that once added, we get the same effect as integrating it into JMRI. I suggest this so that we a plugin capability in JMRI and ship a working demonstration of that capability.

Would the net result be that we distribute that JAR with JMRI, so that somebody who just downloads & installs gets the capability without anything additional required?

[rhwood]

Yes, that would be awesome. But I'm going to suggest we don't. Instead I am going to suggest we figure out the bits we need to be able to add the XtrkCADreader JAR to the JMRI classpath so that once added, we get the same effect as integrating it into JMRI. I suggest this so that we a plugin capability in JMRI and ship a working demonstration of that capability.

Would the net result be that we distribute that JAR with JMRI, so that somebody who just downloads & installs gets the capability without anything additional required?

Yes, if we wanted to.

[pabender]

On Dec 3, 2016, at 5:24 PM, Randall Wood notifications@github.com wrote:

Would it be beneficial to integrate XtrkCADreader into the main JMRI distribution?

Yes, that would be awesome. But I'm going to suggest we don't. Instead I am going to suggest we figure out the bits we need to be able to add the XtrkCADreader JAR to the JMRI classpath so that once added, we get the same effect as integrating it into JMRI. I suggest this so that we a plugin capability in JMRI and ship a working demonstration of that capability.

It is true that from a user interface perspective, there shouldn't be any difference between calling functions in a separate jar vs including the functionality in the main JMRI tree.

The main advantage I see to including it in the main JMRI tree is that way it receives all the same maintenance that the main repository gets ( I.e. the same level of testing, the same bulk edits, etc ) many of the things Matt has been doing as cleanup are just things we normally do in the main repository, but everyone forgets about because the code isn't kept there.

Now the big arguments for integrating this into the main JMRI code base: 1) There isn't a use case for this outside of JMRI. 2) There is duplicated code. At a minimum, XtrkCADReader uses it's own methods when writing the file to XML. 3) It's possible to read from the XtrkCAD file file directly into the objects, but the changes to XtrkCADReader needed to do this are extensive enough it requires significant rewrites of the code. This also requires access to JMRI structures, which the current code doesn't.

Paul

[bobjacobsen]

We could do both.

• Bring XtrkCADreader into the GitHub JMRI/JMRi repository at java/src/xtrkcadreader,
• then teach Ant to build it into a separate JAR
• that we distribute as part of the standard distributions

That would ship a working demonstration of the plug-in capability (which I think has value), while also bringing XtrkCADreader under our maintenance umbrella (which I think has value).

Incidentally, making CATS (The cats.apps.Crandic app) work as a JMRI plug-in would be awesome. That would solve the recurring problems with CATS distribution, JMRI lib/ changes, launcher conflicts, etc while still allowing CATS to be developed separately.

Bob

[nschertz]

Has anything come of bringing XtrkCADreader into the main JMRI distribution as Bob suggested? His suggestion sounds like a good compromise. I've set up a batch file to automate the conversion, but this is still a multi-step process to get into JMRI. It would be much easier to have a menu item in JMRI that would create a JMRI panel file executing XtrkCADreader in the background. Suggest a separate preference item in JMRI to point to the XtrkCAD file location directory.

Thanks for considering this.

Norb