update to Concordion 2.1.0

[ShaKaRee]

currently Concordion.NET is based on Concordion 1.5. It should be updated to the latest version

[ShaKaRee]

@eugene-griaznov would you be interested to help compiling Concordon.NET against the sources of Concordion 2.1.0?

[eagrzn]

Yes, I would be interested. As much as I will have time.

[jproSea]

Greetings... I'm wondering if any work has been done at this point on moving Concordian.NET to v2 of Concordian.

[nigelcharman]

Not yet, but I'm keen to see it. We've seen a 5-fold increase in Concordion (Java) usage with Concordion 2.0.

The current status is:

• Concordion.NET 1.5.1 uses IKVM to cross-compile the Concordion Java code to .NET. As of April this year, IKVM is no longer supported. In discussions with @ShaKaRee, we think it best to revert to a native .NET implementation (probably based on https://github.com/concordion/concordion-net).
• We're keen to have a common set of specifications that cover both .NET and Java implementations. @ShaKaRee and I have had some off-list discussions about this, which would be structured as a core specification repository, with additional specifications for .NET and Java fixtures (see below). Each implementation would combine the common and language-specific specifications to form its own specification suite.
• The Pegdown library, which provides the Markdown support for the Java implementation, is deprecated. We are considering porting this over to Flexmark, but also need to consider whether there are any libraries that offer consistent interfaces between Java and .NET, or create an interface that will make it easy to plug-in a .NET implementation.

In terms of a project team to port and support the implementation:

• @ShaKaRee and I are keen to support a team, but don't have the time to lead this effort
• We are seeking a project lead
• We are also seeking developers to implement the port. As a step towards this, I am preparing a presentation for the Wellington .NET User Group and will be seeking volunteers.

Are you interested in joining the team @jproSea ?

Specification structure

Common Specifications

commands
results
extension

Java specific

java/integration
java/specification type (would move to common once .NET gets to 2.0)
java/annotation

.NET specific

dotnet/attributes
dotnet/configuration
dotnet/integration

[jproSea]

Thanks for the detailed status. Yes, I would be interested in helping make it happen.

[nigelcharman]

Thanks for your offers of help @eugene-griaznov and @jproSea. I'll have a bit of time to start looking at what needs doing next week. The plan is to start from the concordion-net native port. Initially we'll do a delta between that level of code base and the latest Java code and investigate what needs doing. We'll also be creating some shared specs between Java and .NET.

[nigelcharman]

My presentation for the user group is at http://concordion.org/presentations/2017-07-Concordion.NET/. All comments welcome please!

It's under a creative commons license, so feel to fork it and present it to other meetup groups yourselves :)

[nigelcharman]

Videos now added to this presentation :)

[Navatha24]

Interested.

[KimmoMW]

Hi, I'm interested in helping in this project. Cheers, kimmo

[nigelcharman]

Hi @eugene-griaznov, @jproSea, @yemo, @Navatha24, @KimmoMW,

Thanks for your offers to help with Concordion.NET development.

@ShaKaRee has been involved in development of both the original code base, and the code base that was cross-compiled from Java using IKVM. He's now too busy to support it, but is open for questions and will help guide the project.

As a first step, I propose we move to a stable base for Concordion.NET. As detailed above, this would be based on the original native .NET code base, and would implement a set of specifications that are common to both the Java and .NET codebases.

I have refactored the Java code to extract the common specifications into a new repository https://github.com/concordion/concordion-specification-common, and then included these as a git subtree within the Java code base.

Steps:

1. Create a clean repo based on the original source repo. This repo contains lots of binaries and is about 100Mb. We should reduce down to about 1Mb if possible, to make for easy cloning and updating. I propose that the project is refactored to use NuGet. Then remove the binaries from the repo history using the BFG Repo Cleaner. We'll then need to back up the original repo and push the clean repo.

2. Refactor the .NET specifications to have a folder named common which contains the existing Command, Extension and Results folders. Once this is in place, and the specifications are passing, run a git rm -r on the common folder, and then a git subtree add to add the new subtree from the common specifications.

3. At that point, I expect some of the common tests to fail (for example the example command is new, and verifyRows has some new variants). We'll then be able to break the work up to fix different bits of the code base.

I propose that we have a Slack channel to co-ordinate this, and have set up a #concordion-net channel on concordion.slack.com. Hopefully, you'll get an invitation to this - let me know if you can't join it.

Let us know if you have bandwidth and interest in implementing the steps above.

@ShaKaRee - let me know if I missed anything, or you disagree with the approach?

[nigelcharman]

If you could all send me your email addresses to nigel.charman.nz at gmail, I'll add you to the Slack channel

[KidFashion]

I'm interested in helping as well. Sending my mail to @nigelcharman

Angelo

[nickmellor]

@ShaKaRee I sent a query to @concordion on Twitter too. No need to reply to both.

I would consider getting involved with ongoing work on concordion.net, but would need to seek permission from my organisation. I can't ask that kind of question just yet, as I am a newly-arrived contractor.

I've been tasked with developing a test framework for an application for which Concordion is clearly a better fit than a BDD framework such as SpecFlow. C# is mandated, and MarkDown is a better fit than HTML.

And then I see that:

• all activity on concordion.net seems to have ceased or gone underground since Aug 2017, and code commits seem to have ceased even earlier

• MarkDown is not available on the .NET implementation

• the application is currently tied to the .NET 3.5 runtime which is not allowed(? still investigating) by my organisation.

This is disappointing. I would love to use Concordion for this project.

(1) Can I ask for an update?

(2) Is my code repo link current?

https://github.com/concordion/concordion.net.git

Many thanks,

Nick

[nigelcharman]

Hi Nick

@ShaKaRee has stood down from leading this work due to time constraints. I understand he is still keen to answer questions from anyone picking it up.

I think your timeframe is about right. It would be great if someone were able to kick Concordion.NET back into life and bring it back up to speed with the latest features, including Markdown.

As you'll see, we've had a number of people interested in helping out on this thread, some of whom may still be keen.

Updates

• As per this comment, Concordion.NET relies on IKVM for cross-compilation from Java. IKVM has been discontinued. However, since the comment it has been forked and updated to use Java 8.

• As per this comment, we have refactored the specifications into a common set that can be used by both Java and .NET. Some of the specs use Markdown, so support for Markdown would need to come fairly early in terms of getting the specs working.

• The update to use Flexmark for Concordion Java is just about complete and will be shipped with Concordion 3.0. Concordion 3.0 will require Java 8. (We're decoupling the JUnit 5 work from 3.0 and this will ship in a later version.)

Decision
At this stage, we're at a critical fork in the road and need to make a decision:

1. Continue development on the Concordion.NET version using the forked IKVM, or
2. Revert back to the pure C# Concordion-NET version, bring it up to parity with Concordion.NET and start adding new features.

@ShaKaRee did find some performance issues with the cross-compiled code, and made some workarounds to Concordion Java to improve performance of Concordion.NET.

Either way, I'd be keen that we get down to a single repository and improve clarity for future users/committers.

Which option would be preferred by those interested?

Nigel

[nigelcharman]

I forgot to mention that the PR concordion/concordion-net#27 could be the first step for option 2.