Opened 11 years ago

Closed 6 years ago

#149 closed Bug (invalid)

Setup build process breaks whenever the external peers@play interface changes

Reported by: Matthäus Wander Owned by: coredevs
Priority: Must have Milestone: CrypTool 2.1 BETA 1
Component: Installer Keywords:
Cc: Arno Wacker


Within the current CT2 development process it is intended to build and replace the peers@play assemblies manually. However in the setup build process the HEAD revision is being used. This leads to a version mismatch between the trunk and the setup versions of CT2:

  • Errors due to version changes are hard to trace.
  • The setup build breaks whenever a pap developers changes peers@play interfaces, constructors or settings being accessed by CT2.

None of these errors will be noticed by trunk developers.

Requirement: CT2 trunk and setup shall use the same pap version. CT2 trunk developers should experience the same errors as setup users (having errors is ok, as long as there is any chance for the trunk developers to notice them).

The requirement may be realized either by letting CT2 developers manually devide which pap revision is being referenced, or by automatically switching to the current HEAD pap revision. Whatever approach is being chosen, trunk and setup must behave the same. If the pap version being used in trunk changes, it shall change in the setup too. If the pap references in the setup break, they shall break in the trunk too.

Current challenge: pap developers don't use assembly versioning, but pap assemblies bundled with CT2 must use it (or they won't be updated by the setup in case of changes, once #144 is closed). The current CT2 setup versioning scheme (using the SVN revision number) is very convenient and worth to keep.

Solution proposal: trunk developers should have access to a script which builds pap with our versioning scheme and places the assemblies in the right location (run script -> commit -> assemblies available to other trunk developers). The script may either automatically retrieve the HEAD revision from pap SVN or may require manual configuration of the revision number. The setup process shall either use and sign the existing pap assemblies from trunk or shall build and sign the same pap revision as existing in trunk.

Change History (4)

comment:1 Changed 11 years ago by Matthäus Wander

Owner: changed from saternus to Matthäus Wander
Status: newassigned

Current solution: use fixed pap revision number in MSBuild process. This does not avoid all failures, but works in most cases. See UpdatingPapLibs how to change the pap revision.

I will keep this about until I thought about whether we have a better solution for this.

comment:2 Changed 10 years ago by Matthäus Wander

Milestone: CrypTool 2.0 RELEASECrypTool 2.1

p2p-related, postponed

comment:3 Changed 10 years ago by Matthäus Wander

Owner: changed from Matthäus Wander to coredevs

comment:4 Changed 6 years ago by kopal

Resolution: invalid
Status: assignedclosed

we completely removed the peers@play framework, thus, this bug is not possible anymore

Note: See TracTickets for help on using tickets.