New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update to Concordion 2.1.0 #15

Open
ShaKaRee opened this Issue Jan 27, 2017 · 13 comments

Comments

Projects
None yet
7 participants
@ShaKaRee
Member

ShaKaRee commented Jan 27, 2017

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

@ShaKaRee

This comment has been minimized.

Show comment
Hide comment
@ShaKaRee

ShaKaRee Jan 27, 2017

Member

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

Member

ShaKaRee commented Jan 27, 2017

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

@eugene-griaznov

This comment has been minimized.

Show comment
Hide comment
@eugene-griaznov

eugene-griaznov Jan 31, 2017

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

eugene-griaznov commented Jan 31, 2017

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

@jproSea

This comment has been minimized.

Show comment
Hide comment
@jproSea

jproSea Jul 19, 2017

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

jproSea commented Jul 19, 2017

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

@nigelcharman

This comment has been minimized.

Show comment
Hide comment
@nigelcharman

nigelcharman Jul 21, 2017

Member

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

Member

nigelcharman commented Jul 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jproSea

jproSea Jul 25, 2017

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

jproSea commented Jul 25, 2017

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

@nigelcharman

This comment has been minimized.

Show comment
Hide comment
@nigelcharman

nigelcharman Jul 30, 2017

Member

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.

Member

nigelcharman commented Jul 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nigelcharman

nigelcharman Jul 30, 2017

Member

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 :)

Member

nigelcharman commented Jul 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nigelcharman

nigelcharman Aug 5, 2017

Member

Videos now added to this presentation :)

Member

nigelcharman commented Aug 5, 2017

Videos now added to this presentation :)

@Navatha24

This comment has been minimized.

Show comment
Hide comment
@Navatha24

Navatha24 Aug 5, 2017

Interested.

Navatha24 commented Aug 5, 2017

Interested.

@KimmoMW

This comment has been minimized.

Show comment
Hide comment
@KimmoMW

KimmoMW Aug 7, 2017

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

KimmoMW commented Aug 7, 2017

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

@nigelcharman

This comment has been minimized.

Show comment
Hide comment
@nigelcharman

nigelcharman Aug 9, 2017

Member

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?

Member

nigelcharman commented Aug 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nigelcharman

nigelcharman Aug 9, 2017

Member

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

Member

nigelcharman commented Aug 9, 2017

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

@KidFashion

This comment has been minimized.

Show comment
Hide comment
@KidFashion

KidFashion Aug 16, 2017

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

Angelo

KidFashion commented Aug 16, 2017

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

Angelo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment