Re: IKVM (or rather OpenJDK) License Problem

2011-01-27 Thread Stefan Bodewig 
On 2011-01-27, Granroth, Neal V. wrote:

> Use of IKVM was discussed before.

I'm really sorry.  Normally I wouldn't have brought it up without
searching the archive - I did so in the context of "this is a question
the people we hope to attract might ask".

Please be patient with the new people we want to attract, they will not
hunt down the mailing list archives for every idea they have.  This is
why putting things on the Wiki like Scott has started is a better
approach.  You can tell people "was discussed before and URL-HERE is the
outcome".

> Adding this layer (or any other shim) on top of Lucene.NET is
> extremely unpalatable in the environment in which our products are
> deployed.

The license rules it out anyway (unless we ikvmc'ed Harmony, yet another
can of worms) so this question is moot.  But still, out of curiosity: is
there any technical reason that turned it into a bad idea?  The
discussion from the other thread seemed to indicate that performance was
not an issue.

Thanks

Stefan

Re: IKVM (or rather OpenJDK) License Problem

2011-01-27 Thread Ayende Rahien 
It would also have drastic affects on other people using Lucene for
commercial and OSS projects.

On Thu, Jan 27, 2011 at 11:36 AM, Stefan Bodewig  wrote:

> Hi,
>
> sorry I started this before doing my homework.  If we took the IKVM
> route Lucene.NET's binary distribution could not bundle the OpenJDK
> derived DLLs.  They are licensed as GPL2 + Classpath Exception[1] which
> is part of the list of explicitly prohibited licenses for ASF
> distributions[2].
>
> This would mean users had to download the DLL from the IKVM site
> themselves which sounds pretty inconvient.
>
> Stefan
>
> [1] http://sourceforge.net/apps/mediawiki/ikvm/index.php?title=License
>
> [2] http://www.apache.org/legal/resolved.html#category-x
>

IKVM (or rather OpenJDK) License Problem

2011-01-27 Thread Stefan Bodewig 
Hi,

sorry I started this before doing my homework.  If we took the IKVM
route Lucene.NET's binary distribution could not bundle the OpenJDK
derived DLLs.  They are licensed as GPL2 + Classpath Exception[1] which
is part of the list of explicitly prohibited licenses for ASF
distributions[2].

This would mean users had to download the DLL from the IKVM site
themselves which sounds pretty inconvient.

Stefan

[1] http://sourceforge.net/apps/mediawiki/ikvm/index.php?title=License

[2] http://www.apache.org/legal/resolved.html#category-x

Re: Build & CI Considerations

2011-01-27 Thread Stefan Bodewig 
On 2011-01-26, Wyatt Barnett wrote:

> 2) CI : oh hells yeah. My vision would be to setup something where the
> automated conversion would be triggered by commits to the "stable"
> branch of the java project. I think if we can construct this bit right
> we can even really get down the road of automatically running all the
> conversion options until we get it "right".

Sounds good.  "Back to the mundane" as you said later the ASF runs a few
options for CI , one of them is Hudson
 which has at least one Windows slave
installation (Server 2008) and is supposed to support MSBuild.  Buildbot
might work as well.

I'm not up to speed with the state of xbuild but adding support for it
to Gump (which fills quite a different role from a traditional CI)
wouldn't be too hard and give us builds on Mono - albeit 2.4 right now,
this could be changed by adding the Mono PPAs to the Ubuntu servers.

Stefan