I have no idea why I thought we were using Nant.
I think it's just "our release structure". I figured a little out this weekend,
splitting the XML and .dll files into separate directories. The documentation
you have on the wiki was actually pretty helpful.
Whatever more you can add would be great
~P
> Date: Mon, 25 Jun 2012 10:04:21 -0400
> Subject: Re: Outstanding issues for 3.0.3
> From: mhern...@wickedsoftware.net
> To: lucene-net-dev@lucene.apache.org
>
> On Sat, Jun 23, 2012 at 1:38 AM, Prescott Nasser <geobmx...@hotmail.com>wrote:
>
> >
> >
> > > -- Task 470, a non-serious one, is listed only because it's mostly done
> > and
> > > just need a few loose ends tied up. I'll hopefully have time to take care
> > > of that this weekend.
> >
> >
> > How many GetX/SetX are left? I did a quick search for 'public * Get*()'
> > Most of them looked to be actual methods - perhaps a few to replace
> >
> >
> > > -- Task 446 (CLS Compliance), is important, but there's no way we can get
> > > this done quickly. The current state of this issue is that all of the
> > > names of public members are now compliant. There are a few things that
> > > aren't, the use of sbyte (particularly those related to the FieldCache)
> > and
> > > some conflicts with *protected or internal* fields (some with public
> > > members). Opinions on this one will be appreciated the most. My opinion
> > > is that we should draw a line on the amount of CLS compliance to have in
> > > this release, and push the rest into 3.5.
> >
> >
> >
> > I count roughly 53 CLS compliant issues. the sbyte stuff will run into
> > trouble when you do bit shifting (I ran into this issue when trying to do
> > this for 2.9.4. I'd like to see if we can't get rid of the easier stuff
> > (internal/protected stuff). I would not try getting rid of sbyte or
> > volatile for thile release. It's going to take some serious consideration
> > to get rid of those
> >
> >
> > > -- Improvement 337 - Are we going to add this code (not present in java)
> > to
> > > the core library?
> >
> >
> >
> > I'd skip it and re-evaluate the community desire for this in 3.5.
> >
> >
> > > -- Improvement 456 - This is related to builds being output in Apache's
> > > release format. Do we want to do this for this release?
> > >
> >
> >
> > I looked into this last weekend - I'm terrible with Nant, so I didn't get
> > anywhere. It would be nice to have, but I don't think I'll figure it out.
> > If Michael has some time to maybe make the adjustment, he knows these
> > scripts best. If not I'm going to look into it, but I don't call this a
> > show stopper - either we have it or we don't when the rest is done.
> >
>
> With some Flo Rida and expresso shots, anything is possible.
>
> Did we switch to Nant?
>
> I saw the jira ticket for this. Is there an official apache release
> structure or this just our* apache release structure that we are using?
> Can I take the latest release and use that to model the structure you guys
> want?
>
> @Prescott declarative xml build scripts are a pita in general. only reason
> we're using this over powershell or a scripting language is that mono
> supports it and most .NET devs have it already installed.
>
> I'll spend some more time documenting it so that others can work on it and
> even refactor it.
>
> >
> >
> >
> >
> >
> > ~P
