Re: [Lucene.Net] 2.9.4

[Itamar Syn-Hershko]

Big OK from our end

Sorry to be nagging on this again, but it would be very nice if you could
incorporate https://issues.apache.org/jira/browse/LUCENENET-431 in 2.9.4 as
well. It is one of those bugfixes that really fix a lot more than they can
possible break, so I hope this will justify a small divergence from JL.

On Wed, Sep 21, 2011 at 1:29 AM, Michael Herndon <
mhern...@wickedsoftware.net> wrote:

> We should probably  fix the ClsCompliance warnings if they have not already
> been fixed & find a place to put the generated documentation.
>
> I remember someone mentioning he/she was unable to access a class from
> VB.NET. The class had public fields & properties with the same names but
> different casing.  The fields should be private.
>
> The link in the readme is a dead link:
> http://lucene.apache.org/lucene.net/docs/2.4.0/   The docs generated by
> sandcastle & SHFB require a server that allows aspx files to be executed.
>  We should either remove the link from the readme or find the docs a new
> home and update the link.
>
> I'll see if I can setup automating Lucene.Net  nuget
> package creation for trunk in the next day or so.
>
> - Michael
>
> On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser  >wrote:
>
> > Hey all seems like we are set with 2.9.4? Feedback has been positive and
> > its been quiet. Do we feel ready to vote for a new release?
> >
> > -Prescott
> >
> > Sent from my Windows Phone
>

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

>
> We should probably fix the ClsCompliance warnings if they have not already
> been fixed 

 

 

We will have some issues with this - some are marked volatile - which basically 
have to be a non-CLS compliant type (as far as my research is finding) Anyone 
have thoughts? I went through and replaced sbyte -> Int16, and uint -> Int64, 
but I'm having an issue with this, and I don't think removing the volatile 
keyword is the right solution.

 

> find a place to put the generated documentation.


We have a folder /trunk/docs, shouldn't this be the place for that?

 

>
> I remember someone mentioning he/she was unable to access a class from
> VB.NET. The class had public fields & properties with the same names but
> different casing. The fields should be private.
>


 

 

> The link in the readme is a dead link:
> http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
> sandcastle & SHFB require a server that allows aspx files to be executed.
> We should either remove the link from the readme or find the docs a new
> home and update the link.


We should generate new documentation and update the link

 

>
> I'll see if I can setup automating Lucene.Net  nuget
> package creation for trunk in the next day or so.
>
> - Michael
>
> On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser wrote:
>
> > Hey all seems like we are set with 2.9.4? Feedback has been positive and
> > its been quiet. Do we feel ready to vote for a new release?
> >
> > -Prescott
> >
> > Sent from my Windows Phone

[Lucene.Net] Nuget, Lucene.Net, and Your Thoughts

[Michael Herndon]

We're taking a quick poll over the next few days to see how people would
like use Lucene.Net through Nuget on the developers mailing list**

Currently version 2.9.2 is hosted on nuget.org, but that package was not
create by the project maintainers, thus nuget is not currently set up in
source.  Going forward, we would like to continue what someone else started
by creating nuget packages for Lucene.Net.

Right now there are two packages: Lucene & Lucene.Contrib.  My question to
the community is do you wish to finer grain packages, i.e. a package for
each contrib project or continue to keep it simple.

The granular approach will let you use only what you need. We can also
create additional higher level packages which have dependencies on the other
ones.   Possibly a Lucene.Net-Essentials and Lucene.Net-Full.

Or we can keep it simple and continue with only two packages.

My concerns are that the granular approach might overwhelm people with
choice. The simple choice might be considered bloat for importing and then
installing assemblies that you might never use.


Another topic to converse about is would you like to see an out-of-band
project nuget feed for  nightly builds, branches with new or experimental
features, or stable code snapshots for a projected release?


** when you post, please respond to lucene-net-dev@lucene.apache.org.  This
was posted to both lists to make sure everyone subscribed to both lists has
a chance to voice their use cases or concerns.

RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts

[Prescott Nasser]

> Right now there are two packages: Lucene & Lucene.Contrib. My question to
> the community is do you wish to finer grain packages, i.e. a package for
> each contrib project or continue to keep it simple.
>


+1 Granular, we just need to be good about descriptions.


>
> Another topic to converse about is would you like to see an out-of-band
> project nuget feed for nightly builds, branches with new or experimental
> features, or stable code snapshots for a projected release?


Having a package for the latest RC would probably be a good idea
  

RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts

[Aaron Powell]

I'm going to vote +1 for granular.

With the RC you could look at myget and have a Lucene.Net repository on there 
so people can go for unstable on myget, stables on nuget.

Also, I came across this article which explains how to setup a build server to 
automatically push to nuget/ myget which could be useful to the maintainers: 
http://brendanforster.com/doing-the-build-server-dance-with-nuget.html

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team Member

http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | Github | 
BitBucket 

-Original Message-
From: Prescott Nasser [mailto:geobmx...@hotmail.com] 
Sent: Wednesday, 21 September 2011 2:05 PM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts


> Right now there are two packages: Lucene & Lucene.Contrib. My question 
> to the community is do you wish to finer grain packages, i.e. a 
> package for each contrib project or continue to keep it simple.
>


+1 Granular, we just need to be good about descriptions.


>
> Another topic to converse about is would you like to see an 
> out-of-band project nuget feed for nightly builds, branches with new 
> or experimental features, or stable code snapshots for a projected release?


Having a package for the latest RC would probably be a good idea
  

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

>We have a folder /trunk/docs, shouldn't this be the place for that?

We should have a live site for the documentation that people can browse,
similar to the parent project's site.
http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
documentation more accessible.

The rub is that Sandcastle & SHFB generates html files with guid names, xml
& bin files that map to the html files, and aspx pages which acts as the
glue. The aspx pages parses the xml/bin files which creates the document
site.  Thus we're now required to use a server that knows how to serve up
aspx pages.

If any one knows a way to generate just vanilla html using Sandcastle &
SHFB, I could just create a folder per version and push the docs to
incubator site. But so far I haven't found an option for this.

Keeping the generated help docs inside of source would still require for
users to setup a local website just to view the documentation and it adds
extra noise in the project.

In the release we can provide a zipped file of the site and a generated .chm
or even help2/3 files.

On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser wrote:

>
> >
> > We should probably fix the ClsCompliance warnings if they have not
> already
> > been fixed
>
>
>
>
>
> We will have some issues with this - some are marked volatile - which
> basically have to be a non-CLS compliant type (as far as my research is
> finding) Anyone have thoughts? I went through and replaced sbyte -> Int16,
> and uint -> Int64, but I'm having an issue with this, and I don't think
> removing the volatile keyword is the right solution.
>
>
>
> > find a place to put the generated documentation.
>
>
> We have a folder /trunk/docs, shouldn't this be the place for that?
>
>
>
> >
> > I remember someone mentioning he/she was unable to access a class from
> > VB.NET. The class had public fields & properties with the same names but
> > different casing. The fields should be private.
> >
>
>
>
>
>
>
> > The link in the readme is a dead link:
> > http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
> > sandcastle & SHFB require a server that allows aspx files to be executed.
> > We should either remove the link from the readme or find the docs a new
> > home and update the link.
>
>
> We should generate new documentation and update the link
>
>
>
> >
> > I'll see if I can setup automating Lucene.Net  nuget
> > package creation for trunk in the next day or so.
> >
> > - Michael
> >
> > On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser  >wrote:
> >
> > > Hey all seems like we are set with 2.9.4? Feedback has been positive
> and
> > > its been quiet. Do we feel ready to vote for a new release?
> > >
> > > -Prescott
> > >
> > > Sent from my Windows Phone
>

Re: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts

[Troy Howard]

While it may be a bit redundant, why couldn't there be an individual
package for each piece of contrib and a "Lucene.Net Contrib (All)"
package that drags them all down.

That way users can grab just the bit they need, or if they just want
to get the whole thing, grab the "All" package.

Thanks,
Troy


On Tue, Sep 20, 2011 at 9:11 PM, Aaron Powell  wrote:
> I'm going to vote +1 for granular.
>
> With the RC you could look at myget and have a Lucene.Net repository on there 
> so people can go for unstable on myget, stables on nuget.
>
> Also, I came across this article which explains how to setup a build server 
> to automatically push to nuget/ myget which could be useful to the 
> maintainers: 
> http://brendanforster.com/doing-the-build-server-dance-with-nuget.html
>
> Aaron Powell
> MVP - Internet Explorer (Development) | FunnelWeb Team Member
>
> http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | Github 
> | BitBucket
>
> -Original Message-
> From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> Sent: Wednesday, 21 September 2011 2:05 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
>
>
>> Right now there are two packages: Lucene & Lucene.Contrib. My question
>> to the community is do you wish to finer grain packages, i.e. a
>> package for each contrib project or continue to keep it simple.
>>
>
>
> +1 Granular, we just need to be good about descriptions.
>
>
>>
>> Another topic to converse about is would you like to see an
>> out-of-band project nuget feed for nightly builds, branches with new
>> or experimental features, or stable code snapshots for a projected release?
>
>
> Having a package for the latest RC would probably be a good idea
>

Re: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts

[Michael Herndon]

On Wed, Sep 21, 2011 at 12:31 AM, Troy Howard  wrote:

> While it may be a bit redundant, why couldn't there be an individual
> package for each piece of contrib and a "Lucene.Net Contrib (All)"
> package that drags them all down.
>
> That way users can grab just the bit they need, or if they just want
> to get the whole thing, grab the "All" package.
>
> Thanks,
> Troy
>


That was the idea for the Lucene.Net-Essentials & Lucene.Net-Full packages.

"We can also create additional higher level packages which have dependencies
on the other ones.   Possibly a Lucene.Net-Essentials and Lucene.Net-Full."



>
>
> On Tue, Sep 20, 2011 at 9:11 PM, Aaron Powell  wrote:
> > I'm going to vote +1 for granular.
> >
> > With the RC you could look at myget and have a Lucene.Net repository on
> there so people can go for unstable on myget, stables on nuget.
> >
> > Also, I came across this article which explains how to setup a build
> server to automatically push to nuget/ myget which could be useful to the
> maintainers:
> http://brendanforster.com/doing-the-build-server-dance-with-nuget.html
> >
> > Aaron Powell
> > MVP - Internet Explorer (Development) | FunnelWeb Team Member
> >
> > http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell |
> Github | BitBucket
> >
> > -Original Message-
> > From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> > Sent: Wednesday, 21 September 2011 2:05 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
> >
> >
> >> Right now there are two packages: Lucene & Lucene.Contrib. My question
> >> to the community is do you wish to finer grain packages, i.e. a
> >> package for each contrib project or continue to keep it simple.
> >>
> >
> >
> > +1 Granular, we just need to be good about descriptions.
> >
> >
> >>
> >> Another topic to converse about is would you like to see an
> >> out-of-band project nuget feed for nightly builds, branches with new
> >> or experimental features, or stable code snapshots for a projected
> release?
> >
> >
> > Having a package for the latest RC would probably be a good idea
> >
>

Re: [Lucene.Net] 2.9.4

[Troy Howard]

At one time I had a SVN server set up at work that had a post-commit
hook set up that would generate a static HTML site from the XML doc
files using Sandcastle. So.. It can be done. That was about 3-4 years
ago and I don't work at that company any longer, so I don't have
access to the details of how that was done.

Regarding SVN locations...

Autogenerated XML doc files should go in the ~/trunk/doc/
folders. The Sandcastle generated static HTML should go under
~/site/docs/ folders.

I'll see if I can't dig up some info on how to generate static HTML
with Sandcastle.

Thanks,
Troy


On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
 wrote:
>>We have a folder /trunk/docs, shouldn't this be the place for that?
>
> We should have a live site for the documentation that people can browse,
> similar to the parent project's site.
> http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
> documentation more accessible.
>
> The rub is that Sandcastle & SHFB generates html files with guid names, xml
> & bin files that map to the html files, and aspx pages which acts as the
> glue. The aspx pages parses the xml/bin files which creates the document
> site.  Thus we're now required to use a server that knows how to serve up
> aspx pages.
>
> If any one knows a way to generate just vanilla html using Sandcastle &
> SHFB, I could just create a folder per version and push the docs to
> incubator site. But so far I haven't found an option for this.
>
> Keeping the generated help docs inside of source would still require for
> users to setup a local website just to view the documentation and it adds
> extra noise in the project.
>
> In the release we can provide a zipped file of the site and a generated .chm
> or even help2/3 files.
>
> On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser 
> wrote:
>
>>
>> >
>> > We should probably fix the ClsCompliance warnings if they have not
>> already
>> > been fixed
>>
>>
>>
>>
>>
>> We will have some issues with this - some are marked volatile - which
>> basically have to be a non-CLS compliant type (as far as my research is
>> finding) Anyone have thoughts? I went through and replaced sbyte -> Int16,
>> and uint -> Int64, but I'm having an issue with this, and I don't think
>> removing the volatile keyword is the right solution.
>>
>>
>>
>> > find a place to put the generated documentation.
>>
>>
>> We have a folder /trunk/docs, shouldn't this be the place for that?
>>
>>
>>
>> >
>> > I remember someone mentioning he/she was unable to access a class from
>> > VB.NET. The class had public fields & properties with the same names but
>> > different casing. The fields should be private.
>> >
>>
>>
>>
>>
>>
>>
>> > The link in the readme is a dead link:
>> > http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
>> > sandcastle & SHFB require a server that allows aspx files to be executed.
>> > We should either remove the link from the readme or find the docs a new
>> > home and update the link.
>>
>>
>> We should generate new documentation and update the link
>>
>>
>>
>> >
>> > I'll see if I can setup automating Lucene.Net  nuget
>> > package creation for trunk in the next day or so.
>> >
>> > - Michael
>> >
>> > On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser > >wrote:
>> >
>> > > Hey all seems like we are set with 2.9.4? Feedback has been positive
>> and
>> > > its been quiet. Do we feel ready to vote for a new release?
>> > >
>> > > -Prescott
>> > >
>> > > Sent from my Windows Phone
>>
>

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

Could we store sandcastle docs as a single zip/chm?



On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard  wrote:

> At one time I had a SVN server set up at work that had a post-commit
> hook set up that would generate a static HTML site from the XML doc
> files using Sandcastle. So.. It can be done. That was about 3-4 years
> ago and I don't work at that company any longer, so I don't have
> access to the details of how that was done.
>
> Regarding SVN locations...
>
> Autogenerated XML doc files should go in the ~/trunk/doc/
> folders. The Sandcastle generated static HTML should go under
> ~/site/docs/ folders.
>
> I'll see if I can't dig up some info on how to generate static HTML
> with Sandcastle.
>
> Thanks,
> Troy
>
>
> On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
>  wrote:
> >>We have a folder /trunk/docs, shouldn't this be the place for that?
> >
> > We should have a live site for the documentation that people can browse,
> > similar to the parent project's site.
> > http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
> > documentation more accessible.
> >
> > The rub is that Sandcastle & SHFB generates html files with guid names,
> xml
> > & bin files that map to the html files, and aspx pages which acts as the
> > glue. The aspx pages parses the xml/bin files which creates the document
> > site.  Thus we're now required to use a server that knows how to serve up
> > aspx pages.
> >
> > If any one knows a way to generate just vanilla html using Sandcastle &
> > SHFB, I could just create a folder per version and push the docs to
> > incubator site. But so far I haven't found an option for this.
> >
> > Keeping the generated help docs inside of source would still require for
> > users to setup a local website just to view the documentation and it adds
> > extra noise in the project.
> >
> > In the release we can provide a zipped file of the site and a generated
> .chm
> > or even help2/3 files.
> >
> > On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser  >wrote:
> >
> >>
> >> >
> >> > We should probably fix the ClsCompliance warnings if they have not
> >> already
> >> > been fixed
> >>
> >>
> >>
> >>
> >>
> >> We will have some issues with this - some are marked volatile - which
> >> basically have to be a non-CLS compliant type (as far as my research is
> >> finding) Anyone have thoughts? I went through and replaced sbyte ->
> Int16,
> >> and uint -> Int64, but I'm having an issue with this, and I don't think
> >> removing the volatile keyword is the right solution.
> >>
> >>
> >>
> >> > find a place to put the generated documentation.
> >>
> >>
> >> We have a folder /trunk/docs, shouldn't this be the place for that?
> >>
> >>
> >>
> >> >
> >> > I remember someone mentioning he/she was unable to access a class from
> >> > VB.NET. The class had public fields & properties with the same names
> but
> >> > different casing. The fields should be private.
> >> >
> >>
> >>
> >>
> >>
> >>
> >>
> >> > The link in the readme is a dead link:
> >> > http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
> >> > sandcastle & SHFB require a server that allows aspx files to be
> executed.
> >> > We should either remove the link from the readme or find the docs a
> new
> >> > home and update the link.
> >>
> >>
> >> We should generate new documentation and update the link
> >>
> >>
> >>
> >> >
> >> > I'll see if I can setup automating Lucene.Net 
> nuget
> >> > package creation for trunk in the next day or so.
> >> >
> >> > - Michael
> >> >
> >> > On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser <
> geobmx...@hotmail.com
> >> >wrote:
> >> >
> >> > > Hey all seems like we are set with 2.9.4? Feedback has been positive
> >> and
> >> > > its been quiet. Do we feel ready to vote for a new release?
> >> > >
> >> > > -Prescott
> >> > >
> >> > > Sent from my Windows Phone
> >>
> >
>

Re: [Lucene.Net] 2.9.4

[Troy Howard]

Why would we want to do that?

Under the /site/docs directory, they need to be served up as loose HTML...

IMO the XML files shouldn't be checked into SVN because they are
auto-generated. The same goes for Sandcastle files.. However, in the
release packages, I think we should include the XML files as well as a
fully functional version of the Sandcastle docs that can be viewed
locally. I personally thing CHMs are terrible user experience, and I'd
much rather have a static HTML site I can browse locally, if we're
going to bother including a copy of the documentation in the package,
vs just hosting it online and calling that good (this is what most
projects these days do). Good thing about hosting online -- searchable
via google.

Thanks,
Troy


On Tue, Sep 20, 2011 at 9:48 PM, Michael Herndon
 wrote:
> Could we store sandcastle docs as a single zip/chm?
>
>
>
> On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard  wrote:
>
>> At one time I had a SVN server set up at work that had a post-commit
>> hook set up that would generate a static HTML site from the XML doc
>> files using Sandcastle. So.. It can be done. That was about 3-4 years
>> ago and I don't work at that company any longer, so I don't have
>> access to the details of how that was done.
>>
>> Regarding SVN locations...
>>
>> Autogenerated XML doc files should go in the ~/trunk/doc/
>> folders. The Sandcastle generated static HTML should go under
>> ~/site/docs/ folders.
>>
>> I'll see if I can't dig up some info on how to generate static HTML
>> with Sandcastle.
>>
>> Thanks,
>> Troy
>>
>>
>> On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
>>  wrote:
>> >>We have a folder /trunk/docs, shouldn't this be the place for that?
>> >
>> > We should have a live site for the documentation that people can browse,
>> > similar to the parent project's site.
>> > http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
>> > documentation more accessible.
>> >
>> > The rub is that Sandcastle & SHFB generates html files with guid names,
>> xml
>> > & bin files that map to the html files, and aspx pages which acts as the
>> > glue. The aspx pages parses the xml/bin files which creates the document
>> > site.  Thus we're now required to use a server that knows how to serve up
>> > aspx pages.
>> >
>> > If any one knows a way to generate just vanilla html using Sandcastle &
>> > SHFB, I could just create a folder per version and push the docs to
>> > incubator site. But so far I haven't found an option for this.
>> >
>> > Keeping the generated help docs inside of source would still require for
>> > users to setup a local website just to view the documentation and it adds
>> > extra noise in the project.
>> >
>> > In the release we can provide a zipped file of the site and a generated
>> .chm
>> > or even help2/3 files.
>> >
>> > On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser > >wrote:
>> >
>> >>
>> >> >
>> >> > We should probably fix the ClsCompliance warnings if they have not
>> >> already
>> >> > been fixed
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> We will have some issues with this - some are marked volatile - which
>> >> basically have to be a non-CLS compliant type (as far as my research is
>> >> finding) Anyone have thoughts? I went through and replaced sbyte ->
>> Int16,
>> >> and uint -> Int64, but I'm having an issue with this, and I don't think
>> >> removing the volatile keyword is the right solution.
>> >>
>> >>
>> >>
>> >> > find a place to put the generated documentation.
>> >>
>> >>
>> >> We have a folder /trunk/docs, shouldn't this be the place for that?
>> >>
>> >>
>> >>
>> >> >
>> >> > I remember someone mentioning he/she was unable to access a class from
>> >> > VB.NET. The class had public fields & properties with the same names
>> but
>> >> > different casing. The fields should be private.
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> > The link in the readme is a dead link:
>> >> > http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
>> >> > sandcastle & SHFB require a server that allows aspx files to be
>> executed.
>> >> > We should either remove the link from the readme or find the docs a
>> new
>> >> > home and update the link.
>> >>
>> >>
>> >> We should generate new documentation and update the link
>> >>
>> >>
>> >>
>> >> >
>> >> > I'll see if I can setup automating Lucene.Net 
>> nuget
>> >> > package creation for trunk in the next day or so.
>> >> >
>> >> > - Michael
>> >> >
>> >> > On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser <
>> geobmx...@hotmail.com
>> >> >wrote:
>> >> >
>> >> > > Hey all seems like we are set with 2.9.4? Feedback has been positive
>> >> and
>> >> > > its been quiet. Do we feel ready to vote for a new release?
>> >> > >
>> >> > > -Prescott
>> >> > >
>> >> > > Sent from my Windows Phone
>> >>
>> >
>>
>

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

I'm with you on checking in the static files into ~/site/doc/version

that would be pretty easy to automate from jenkins & msbuild if we can get
the docs into static html.

 I currently just push all assemblies, help files, xml docs into ~/trunk/bin
on the user's local once the scripts finish building, running tests, and
reports. Nothing gets commited into svn from this at the moment.  The site
is generated, but not pushed anywhere.

I was waiting to see how aspx thing plays out & getting CI up with nuget
before setting up a build release build task that automates everything
including pushing the docs, finalized content, etc.

So my real question is, do we need to store static docs that are generate in
~/trunk/docs/?

If so, could we store those in a single file format and just provide a setup
script that takes care of extracting the latest for the user versus putting
all those files into trunk.

Technically someone could build an post process hook that builds up a static
html index  from xml & bin files, but I'm hoping it does not come to that.


 - Michael







On Wed, Sep 21, 2011 at 12:56 AM, Troy Howard  wrote:

> Why would we want to do that?
>
> Under the /site/docs directory, they need to be served up as loose HTML...
>
> IMO the XML files shouldn't be checked into SVN because they are
> auto-generated. The same goes for Sandcastle files.. However, in the
> release packages, I think we should include the XML files as well as a
> fully functional version of the Sandcastle docs that can be viewed
> locally. I personally thing CHMs are terrible user experience, and I'd
> much rather have a static HTML site I can browse locally, if we're
> going to bother including a copy of the documentation in the package,
> vs just hosting it online and calling that good (this is what most
> projects these days do). Good thing about hosting online -- searchable
> via google.
>
> Thanks,
> Troy
>
>
> On Tue, Sep 20, 2011 at 9:48 PM, Michael Herndon
>  wrote:
> > Could we store sandcastle docs as a single zip/chm?
> >
> >
> >
> > On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard 
> wrote:
> >
> >> At one time I had a SVN server set up at work that had a post-commit
> >> hook set up that would generate a static HTML site from the XML doc
> >> files using Sandcastle. So.. It can be done. That was about 3-4 years
> >> ago and I don't work at that company any longer, so I don't have
> >> access to the details of how that was done.
> >>
> >> Regarding SVN locations...
> >>
> >> Autogenerated XML doc files should go in the ~/trunk/doc/
> >> folders. The Sandcastle generated static HTML should go under
> >> ~/site/docs/ folders.
> >>
> >> I'll see if I can't dig up some info on how to generate static HTML
> >> with Sandcastle.
> >>
> >> Thanks,
> >> Troy
> >>
> >>
> >> On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
> >>  wrote:
> >> >>We have a folder /trunk/docs, shouldn't this be the place for that?
> >> >
> >> > We should have a live site for the documentation that people can
> browse,
> >> > similar to the parent project's site.
> >> > http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it
> the
> >> > documentation more accessible.
> >> >
> >> > The rub is that Sandcastle & SHFB generates html files with guid
> names,
> >> xml
> >> > & bin files that map to the html files, and aspx pages which acts as
> the
> >> > glue. The aspx pages parses the xml/bin files which creates the
> document
> >> > site.  Thus we're now required to use a server that knows how to serve
> up
> >> > aspx pages.
> >> >
> >> > If any one knows a way to generate just vanilla html using Sandcastle
> &
> >> > SHFB, I could just create a folder per version and push the docs to
> >> > incubator site. But so far I haven't found an option for this.
> >> >
> >> > Keeping the generated help docs inside of source would still require
> for
> >> > users to setup a local website just to view the documentation and it
> adds
> >> > extra noise in the project.
> >> >
> >> > In the release we can provide a zipped file of the site and a
> generated
> >> .chm
> >> > or even help2/3 files.
> >> >
> >> > On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser <
> geobmx...@hotmail.com
> >> >wrote:
> >> >
> >> >>
> >> >> >
> >> >> > We should probably fix the ClsCompliance warnings if they have not
> >> >> already
> >> >> > been fixed
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> We will have some issues with this - some are marked volatile - which
> >> >> basically have to be a non-CLS compliant type (as far as my research
> is
> >> >> finding) Anyone have thoughts? I went through and replaced sbyte ->
> >> Int16,
> >> >> and uint -> Int64, but I'm having an issue with this, and I don't
> think
> >> >> removing the volatile keyword is the right solution.
> >> >>
> >> >>
> >> >>
> >> >> > find a place to put the generated documentation.
> >> >>
> >> >>
> >> >> We have a folder /trunk/docs, shouldn't this be the place for that?
> >> >>
> >> >>
> >> >>
> >> >>