Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Papyrus-RT Build Problems — Blocked

Thanks, Ernesto.

I managed to run the stand-alone code generator once I figured out how to add a bunch of source projects from my workspace (because that’s the only source of Neon-version Papyrus-RT bundles) to the dynamic classpath analyzing PluginFinder thing.

As expected, there were several differences in the generated code for the ComputerSystem, of two kinds:
  • reordering of the registration of states in a state machine
  • different numeric suffixes on what look like auto-generated identifiers for things to do with ChoicePoints in the state machines
Interestingly, there were no differences at all in the code generated for the PingPong and PingPong-data models.  I did have to fix HREFs to the RTS library in the PingPong model, though, in order for the stand-alone code generator to be able to resolve proxies (the model had platform:/plugin URIs where it should have had pathmap: URIs).

Unfortunately, the codegen test case still fails.  Looking at a couple of the files that my codegen run changed, I see in the Hudson build workspace that what was generated in the automated text execution actually resembles the original expected source, not what I re-generated.  So, that seems to have been a pointless exercise.  I have therefore reverted my re-generation of the expected_src for the ComputerSystem.

Is there a way to (easily) determine the diffs that were detected to fail in the test case?  All I see in the build log is a list of file names, which doesn’t help much.

Thanks,

Christian

On 5 April, 2016 at 14:32:09, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

You can go ahead and generate the code yourself.

I'm not sure why the generated code would be different. However we do have some discrepancies between the code generated within Eclipse and the one using the standalone generator, which is the one invoked during the build. These discrepancies seem to be about the order in which certain elements (e.g. member functions) are generated (I'm not sure why yet).

Because of these discrepancies, I would suggest to use the standalone generator. The generator is called 'umlrtgen.sh' and is located under 'org.eclipse.papyrusrt.codegen.standalone'. If you prefer to setup a run/debug configuration in Eclipse, here's some guidance:


The run configuration arguments I use for generating ComputerSystem are:

-d -l ALL -s -p /Users/epp/Development/PapyrusRT/ides/mars-sdk/Eclipse.app/Contents/Eclipse/plugins:/Users/epp/Development/PapyrusRT/git/org.eclipse.papyrus-rt/plugins/umlrt -o /Users/epp/Development/PapyrusRT/gen/ComputerSystem /Users/epp/Development/PapyrusRT/git/org.eclipse.papyrus-rt/models/samples/ComputerSystem/ComputerSystem.uml

The model is in the models/samples folder.

Other models that might have the same issue are PingPong and PingPong-data in models/tests.

If you need help with the generation, let me know.



On Tue, Apr 5, 2016 at 2:17 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Ernesto,

It sounds like we’re close to finishing this.  I am set up for Neon, so if there’s nothing very unusual about this generated code, I’m happy to give it a try.  I would prefer not to disable any more tests than the RCPTT (which problem is not unique to the Neon branch, it seems).

But, this begs the question of why the generated code should be different now?  It shouldn’t matter that the platform is now Neon-based; the code generation logic wouldn’t change, especially because the target language (C++) and model libraries wouldn’t have changed.

cW

On 5 April, 2016 at 13:46:06, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

On second thought, the TEST_MODEL parameter only controls the post-maven test.

I can regenerate the test and copy the sources to the expected_src dir, but I need to update my IDE first (I'm not on Neon yet).



On Tue, Apr 5, 2016 at 1:33 PM, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
The latest build almost succeeds but fails with the ComputerSystem test model generation test.

We can disable that test (delete the "Default value" of the TEST_MODEL configuration parameter in the job) or we can simply manually regenerate code from that model and copy the generated code into the ComputerSystem/expected_src folder.

Do you have a preference?



On Tue, Apr 5, 2016 at 1:13 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Thanks, Ernesto.

Job creation is a Hudson permission, not a job permission.  But that's okay, now you've renamed it.

cW

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Ernesto Posse
Zeligsoft.com




--
Ernesto Posse
Zeligsoft.com

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Ernesto Posse
Zeligsoft.com

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

Back to the top