lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wyatt Barnett <wyatt.barn...@gmail.com>
Subject Re: Lucene.NET to .NET Core
Date Mon, 20 Jun 2016 15:12:21 GMT
Sorry for the delayed response, I was off at the beach last weekend.

Not a whole lot of seat-time w/ xunit here. In terms of running it, there
is a plugin, we can see if CodeBetter would be willing to install it. The
hand-plumbed option doesn't seem to daunting either. In terms of categories
that is a better question but it seems like Xunit has a [Traits] attribute
that could be used -- see
http://stackoverflow.com/questions/21791739/execute-tests-based-on-xunit-filtered-by-traits-in-teamcity
for
an example.

On Sun, Jun 19, 2016 at 5:49 AM Itamar Syn-Hershko <itamar@code972.com>
wrote:

> "All these issues together lead us to the conclusion that we would be doing
> a disservice to just blindly port to xUnit." - why do you say that? if a
> move to xUnit benefits us on multiple occasions (better API, .NET Core
> support, faster runs) this one-tine effort would be worth it - no?
>
> Wyatt, can you chime in perhaps - you have the most experience getting the
> build system to run, and test categorisation
>
> Thanks
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Lucene.NET committer and PMC member
>
> On Fri, Jun 17, 2016 at 7:06 AM, Elizabeth Maher (NEWMAN) <
> Elizabeth.Maher@microsoft.com> wrote:
>
> > Hi all.  I have a quick update on our progress.
> >
> > We did a test of what it would be like to port Lucene.NET to use xUnit.
> > As Itamer guessed, it is quite a bit of work.  The basic work of renaming
> > attributes and changing out package names and the like is a little
> tedious,
> > but it is doable.  The issues comes in because of the use of categories
> and
> > timeout attributes.  Creating categories in xUnit is possible, but rather
> > complicated.  The bigger issue is that my research indicated that
> TeamCity
> > only has basic integration with xUnit and you have to run all the tests.
> > Running only categories requires extra scripting.  The bigger issue was
> > that there is no TimeOut attribute in xUnit so longer running tests are
> an
> > issue.  We would also have to re-arrange some the test fixture setup and
> > teardown code into class constructors and dispose methods, but that work
> > was doable.  All these issues together lead us to the conclusion that we
> > would be doing a disservice to just blindly port to xUnit.
> >
> > nUnit has just release an alpha package that runs on .NET Core RC2.
> > Connie is looking into getting working this week or next to so we can
> keep
> > the use of such features as testcase timeouts and categories.  We'll send
> > an update when we've tried out the alpha package.
> >
> > Thanks,
> > Elizabeth
> >
> > -----Original Message-----
> > From: Elizabeth Maher (NEWMAN) [mailto:Elizabeth.Maher@microsoft.com]
> > Sent: Monday, May 23, 2016 4:40 PM
> > To: dev@lucenenet.apache.org
> > Subject: RE: Lucene.NET to .NET Core
> >
> > Thank you everyone for the feedback.
> >
> > It's sounds everyone is favor of the move to xUnit.  I've talked to a
> > couple of my co-workers and they said the conversion can be a little
> > tedious, but often worth the effort.  Give me a couple days to see if
> it’s
> > a rabbits hole.  I'll respond back if its more effort that I can expend.
> >
> > Itamar,
> > Regarding your last question.  There are no more know tasks other than
> > what I initially outlined.  Once I merge Connie's change in from master
> we
> > will have a building/ported assembly.  I just need to get the tests
> running
> > to verify everything works as expected.
> >
> > Thanks,
> > Elizabeth
> >
> > -----Original Message-----
> > From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com]
> On
> > Behalf Of Itamar Syn-Hershko
> > Sent: Friday, May 20, 2016 6:46 AM
> > To: dev@lucenenet.apache.org
> > Subject: Re: Lucene.NET to .NET Core
> >
> > Hey there,
> >
> > Thank you so much again for your great work here. Lots of good
> > contributions we could definitely use.
> >
> > Moving to xUnit.Net was actually on my list of things to do - basically
> > also because it's API is much better and more flexible (and less buggy!)
> > and my experience with it was much better than with NUnit (which we use
> an
> > outdated version of). Some people claim xUnit is also faster, so hey -
> why
> > not.
> >
> > Are you sure you can "easily move all tests to xUnit"? From what I can
> > tell this will be a rather rigorous copy-paste job? While the
> > JavaCompatibility bits we have (
> >
> >
> https://github.com/apache/lucenenet/tree/master/src/Lucene.Net.TestFramework/JavaCompatibility
> > )
> > do contain centralized function like assertTrue() etc that save loads of
> > time and effort porting tests, so that could be changed easily to use
> > xUnit, there are many places where asserts etc where ported in full to
> the
> > NUnit API.
> >
> > I am definitely pro this change, but let's make sure we don't go down
> into
> > a rabbit hole first. Let me know what you think.
> >
> > With regards to the status update:
> >
> > 1. I made some last minor comments on the merge scheduler PR - we should
> > be able to merge it within a few days now. Great work there
> >
> > 2. What is keeping us from merging your ICU etc changes? please note some
> > subprojects are absolutely necessary for Lucene.NET to run on Core CLR as
> > well - even though they are "sub" projects and not part of the Lucene
> core
> > itself. Queries and Analysis are probably the biggest ones (latter not
> > fully ported yet, and it's the one with the ICU dep).
> >
> > 3. Other than what you posted - are there any other pending items to get
> > this running on .NET Core?
> >
> > --
> >
> > Itamar Syn-Hershko
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcode972.com&data=01%7c01%7cElizabeth.Maher%40microsoft.com%7c443f03152dfd451ebb1c08d380b51eba%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HxE52%2bFAC6FJAN%2fifQ5V8v27tZZALzBuDw2yhbw%2bkc8%3d
> > | @synhershko <
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fsynhershko&data=01%7c01%7cElizabeth.Maher%40microsoft.com%7c443f03152dfd451ebb1c08d380b51eba%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7iqRqwQwlcNbmwkckUjcS1MWjUPJi3cxLFfRdLc3BnQ%3d
> > >
> > Freelance Developer & Consultant
> > Lucene.NET committer and PMC member
> >
> > On Fri, May 20, 2016 at 3:17 AM, Elizabeth Maher (NEWMAN) <
> > Elizabeth.Maher@microsoft.com> wrote:
> >
> > > Lucene.NET Community,
> > >
> > > Connie and I continue to make progress on moving Lucene.NET to .NET
> Core.
> > > The last challenge we face is to get the tests to successfully run on
> > > .NET Core.  Currently the unit tests use NUnit.  There is a .NET Core
> > > version called NUnitLite.  However, the issue is there is some manual
> > > steps to get NUnitLite tests to work on .NET Core.  We would have to
> > > create console applications for each of the test library, call the
> > > appropriate APIs to create a test results file and then work with the
> > > CI system to manually upload the results.  Also, there is not Test
> > > Runner integration for NUnitLite.  While, this is all possible to do,
> > > I would like to propose a different change.  I could easily move all
> > > the test to use xUnit.  The would benefit Lucene.NET in the long run
> > > as there are both full fx<
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fxunit
> > > .github.io%2fdocs%2fgetting-started-desktop.html&data=01%7c01%7cElizab
> > > eth.Maher%40microsoft.com%7c443f03152dfd451ebb1c08d380b51eba%7c72f988b
> > > f86f141af91ab2d7cd011db47%7c1&sdata=2orwADQfb%2fkpCykXkySekBp0Dxanw0WR
> > > rUupy%2fzRFTY%3d> and core fx<
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fxunit
> > > .github.io%2fdocs%2fgetting-started-dotnet-core.html&data=01%7c01%7cEl
> > > izabeth.Maher%40microsoft.com%7c443f03152dfd451ebb1c08d380b51eba%7c72f
> > > 988bf86f141af91ab2d7cd011db47%7c1&sdata=UGKx5nz6%2foaV2vt2LQDTqkpn0g%2
> > > bu2XXHzE4pDZ0K%2fhU%3d> versions of xUnit, there is a TeamCity plugin
> > > that automatically works<
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fxunit
> > > .github.io%2fdocs%2fgetting-test-results-in-teamcity.html&data=01%7c01
> > > %7cElizabeth.Maher%40microsoft.com%7c443f03152dfd451ebb1c08d380b51eba%
> > > 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=an0p3MTPFYe24wQiPq3SsF3Eb
> > > v3gwJwrr88TjoQ4DnM%3d>, as well as the ability to run tests in Visual
> > > Studio.<
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fxunit
> > > .github.io%2fdocs%2fgetting-started-dotnet-core.html%23run-tests-vs&da
> > > ta=01%7c01%7cElizabeth.Maher%40microsoft.com%7c443f03152dfd451ebb1c08d
> > > 380b51eba%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BN%2f3XEmrUyKQu
> > > 8tdZtoghxSskpFBPP1N1YGxT7e45Vc%3d.>
> > > I believe the long-term maintenance cost for both full and core fx
> > > tests would be lower using xUnit.  Is this an acceptable direction for
> > > me to take the unit tests?  Please let me know.
> > >
> > > Below is the progress of our migration work, for the curious.
> > >
> > > 1.       Remove use of SharpZipLib dependency - completed
> > >
> > > 2.       Update ICU4NET dependency for .NET Core - completed in dev
> > branch
> > >
> > > a.        In https://github.com/conniey/lucenenet/tree/move2dnx.
> > >
> > > 3.       Remove Appache.NMS dependency - completed
> > >
> > > 4.       Move Scheduler to use Tasks - PR submitted
> > >
> > > a.        Pull request at https://github.com/apache/lucenenet/pull/171
> .
> > >
> > > 5.       Make portable libraries to build .NET Core binaries -
> completed
> > > in dev branch
> > >
> > > a.        In https://github.com/conniey/lucenenet/tree/move2dnx.
> > >
> > > 6.       Verify tests pass on both full framework and .Net Core. - In
> > > progress
> > >
> > > a.        Need to get tests to run on .NET Core.
> > >
> > >
> > > Thanks,
> > > Elizabeth
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message