lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Irwin <pir...@feature23.com>
Subject Re: Windows RT / WP8 Version
Date Wed, 21 Aug 2013 14:32:53 GMT
FWIW, Here are the results of the Xamarin Mobility Scanner of the
Lucene.net 4.3.1 code in my fork.
http://scan.xamarin.com/Home/Report?scanId=021c2372-6760-4104-9a3c-07400d51c82e

While it says 90-99% compatibility, there are some very difficult
refactorings to make it support Windows Phone and Windows 8/RT. As for iOS
and Android, it looks pretty easy -- we just need to remove the references
to ConfigurationManager.AppSettings and it should work (according to the
Xamarin scanner) without making it a PCL.


On Wed, Aug 21, 2013 at 10:13 AM, Itamar Syn-Hershko <itamar@code972.com>wrote:

> I'm with Paul on this
>
>
> On Wed, Aug 21, 2013 at 10:11 AM, Paul Irwin <pirwin@feature23.com> wrote:
>
> > I appreciate the idea of having it portable, but after going through most
> > of the code myself with catching it up to 4.3 (still much work to be
> done),
> > I can attest that it would be exceptionally difficult if not impossible
> to
> > maintain an even partial port to PCL in the same codebase. Take a look at
> > the Util.FST classes, or the Util.Packed classes, or any of the Codecs in
> > 4.x to see what I'm talking about. I do not want to see Lucene.net get
> > stuck in the dark ages due to trying to achieve PCL compatibility.
> >
> > If anyone is passionate about having a partial port of Lucene core to PCL
> > (because I do not believe you can achieve a full port), I suggest
> spinning
> > off a new project or keeping the source completely separate rather than
> > filling the Lucene.net code with a bunch of #if statements and thus
> making
> > it much more difficult for us to do line-by-line updates of the Java code
> > in the future.
> >
> >
> > On Wed, Aug 21, 2013 at 3:45 AM, Christopher Currens <
> > currens.chris@gmail.com> wrote:
> >
> > > Prescott,
> > >
> > > You're right in regards to PCL and MonoTouch.  I have no idea what I
> was
> > > thinking.  I seem to recall a year or so ago when you ran into that
> > issue.
> > >  I believe WP8 supports unsigned value types, so it may not be an issue
> > if
> > > WP7 isn't explicitly supported.
> > >
> > > Stefan,
> > >
> > > I'm prepared for it being an arduous task.  Most of the challenges
> you've
> > > listed are addressed by using PCL, except for legacy technologies.
>  When
> > it
> > > comes to unsupported platforms, I think often times the only options is
> > to
> > > drop support for them when it comes to new code.  Like you mentioned,
> we
> > > don't really hit the support level that log4net does, we've already
> made
> > > the decision to not support .NET 3.5 in the 4.x versions of Lucene.
> > >
> > > I still think my biggest blocker against PCL is that it's not in
> > > Express....I'd like to keep support for Express editions instead of
> > > potentially blocking people from contributing.
> > >
> > > Thanks,
> > > Christopher
> > >
> > >
> > > On Tue, Aug 20, 2013 at 11:41 PM, Stefan Bodewig <bodewig@apache.org>
> > > wrote:
> > >
> > > > On 2013-08-21, Christopher Currens wrote:
> > > >
> > > > > I've been thinking lately of doing a real push to have Lucene.Net
> > > support
> > > > > more platforms, specifically Windows RT and Windows Phone 8.  There
> > are
> > > > two
> > > > > ways I can think of doing it, and each has its own specific
> > advantages
> > > > and
> > > > > disadvantages.
> > > >
> > > > One thing I can tell you is that the release process can easily
> become
> > a
> > > > PITA either way.  At least if you want to extend it to platforms VS
> > > > cannot cross-compile to OOTB.
> > > >
> > > > I've been the release manager of the last log4net release and am
> > > > preparing to cut a new one, so memory is fresh.  log4net uses NAnt to
> > > > build and builds for several platforms from the same codebase with
> > > > defines (NET_4_0 and so on) controlling code-paths that need specific
> > > > platform or language features.
> > > >
> > > > For each additional platform you add the release manager must be able
> > to
> > > > build for it - no matter which approach you take.  This might be
> > trivial
> > > > for some platforms as VS supports them today but not for others (say
> > > > MonoTouch) or no longer tomorrow (say you still want to support .NET
> > 2.0
> > > > when VS 2015 drops support for it).
> > > >
> > > > In log4net's case keeping around a virtual machine running XP that
> can
> > > > still build .NET 1.0 is the biggest hurdle.  As Lucene.NET doesn't
> > > > strive to support old platforms as long as log4net does, this may not
> > be
> > > > as big of an issue.
> > > >
> > > > Of course we release sources, not binaries.  So you could say the RM
> > > > only builds the stock .NET stuff and people who want to have a
> version
> > > > for MonoTouch should build them from source - or you have different
> > team
> > > > members contribute binaries for different platforms much like the
> HTTPd
> > > > project does.
> > > >
> > > > Stefan
> > > >
> > >
> >
>

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