You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Wade Chandler <wa...@apache.org> on 2017/04/24 16:36:03 UTC
NetBeans Apache Site Static Site Generator and Plan; Discussion
All,
I have been reviewing different static site generators for a good bit. I have also been reviewing the current NB site structure and content/files. I have also been working on this document in the Wiki:
https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning <https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning>
I give reasonings for static site generator choices as well as some context on things reviewed/studied. Notice I’m suggesting JBake as a starting point along with a Gradle build which can fill in some preprocessing gaps. I’m also starting to work on a plan for using it to get the current site moved over; have to start some where.
I bring this up to have a conversation about it if needed, and then finally after that, to vote to make sure we have made some decisions. I think if nobody has an issue with using JBake as a starting point as mentioned in the document, then we could have a vote on it soon/immediately, and then later the plan or options.
To come up with a full on plan takes writing some scripts as mentioned in the document, and trying out some things with Groovy and JSoup at the moment, so not super trivial, but not really hard either, but does take time. Then, once some tools for conversion which will be needed no matter the SSG choice are in place, we can generate a sub-set of what is on netbeans.org <http://netbeans.org/> merged with what Christian Lenz has already started for the new site.
This will be working with the Oracle folks (mainly Gj) to get the files over to Apache as part of the donation, but moving them over into this structure to be statically generated by automation at some point, but initially manually and pushed by an individual albeit running the tools (still simpler and less time consuming). I’m hoping the scripts I mentioned make this easier, and is what I’m focusing on now to get together a subset for demonstration.
I’m also working on setting up a Salon for my wife’s business at the moment, so a lot of different pots on the fire at the moment, so please be patient, but it will be soon.
Thanks much, and look forward to input and discussion,
Wade
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Neil C Smith <ne...@googlemail.com>.
Hi,
On Tue, May 2, 2017 at 2:37 PM Bernd Ruehlicke <
bernd.ruehlicke@eriksfiord.com> wrote:
> Just my 5 cents: We cannot afford to split the community. All
> users/developers should be using netbeans.apache.org as primary point of
> entry. As now, there should be an area for IDE and one for the Platform.
> Having both will allow users to possible explore new things they else
> never would see.
>
>
In my view I'd say the opposite. Losing the netbeans.org domain for the
primary user facing links would be a mistake in my opinion, given the huge
number of inbound links out there (yes, I know we can redirect, but it
doesn't mean we should). Having a site focused purely on development of
the IDE and platform at netbeans.apache.org as required doesn't mean we'd
split the community. Lots of organisations use multiple sub-domains /
domains for different purposes - the key is to integrate the layout/design
so that people can easily find what they're looking for, with header links
back-and-forth, etc. OpenOffice roughly has this approach by the look of
it.
My 5 cents. I'm old enough to remember when it was 2 cents. Inflation's a
killer! ;-)
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Awesome. Write it up, looking forward to trying it all out. Moving the
tutorials and any relevant content over is a trivial matter, as I've
discovered today -- though these other matters you describe need to be
resolved first, the sooner the better.
Gj
On Tue, May 2, 2017 at 4:13 PM, Wade Chandler <wa...@apache.org>
wrote:
> This was my point earlier in the thread about how we can bring the sites (
> platform.netbeans.org/www.netbeans.org <http://platform.netbeans.org/
> www.netbeans.org>) etc into the SSG based site. We can use the same path
> layout, and even have .html on the end to allow for links to continue to
> work. Then, later, when fully at Apache, we can then get the domain names
> to point to the same content under the hood. i.e. platform.netbeans.org <
> http://platform.netbeans.org/> would just be a CNAME for www.netbeans.org
> <http://www.netbeans.org/>, and all the content would be under one source
> tree. Then, once that happens, and if we moved things over that way, the
> old links will work. I think there are some things which perhaps are no
> longer useful, but we can worry about that later. Too, we can later work on
> some redirect scheme if we decide we need to.
>
> I suggest we work on the document here https://cwiki.apache.org/
> confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning <
> https://cwiki.apache.org/confluence/display/NETBEANS/
> New+NetBeans+Web+Site+Planning>
>
> I can write up how that will work with JBake, Gradle, and Scripts, for the
> above. The idea is to have Groovy scripts which strip out the base content
> specific sections of sites leaving the headers etc for the templates. Those
> different pages, based on the section of the site they are in, will be
> different page types, which means they link to different templates,
> allowing links on the sides of the pages in the templates to be context
> sensitive. The Groovy scripts (using JSoup to easily parse out HTML
> content) will also then add the required front matter/meta-data to the
> files to represent the page type. This can all be pretty automatic fed by a
> JSON document for guidance per sections and structures.
>
> I can also put together examples of this, and that is what I’m doing now.
> The end result should support what you are wanting Gj, and is something I
> think is important too. This will also address what Christian and I are
> talking about related to templates and the site layout which is what allows
> us to maintain this stuff easier. The SSG also makes it easy to have a
> static blog section we can contribute to. I think future content we should
> use MD for the base content, to provide an easier editing experience, but
> what we bring over initially will be the HTML fragments that will be
> plugged into the templates by the SSG. Those MD content files will make
> adding new articles and posts to the site fairly trivial IMO.
>
> Wade
>
>
> ===================
>
> Wade Chandler
> e: consult@wadechandler.com
>
>
>
> > On May 2, 2017, at 09:53, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com> wrote:
> >
> > On Tue, May 2, 2017 at 3:37 PM, Bernd Ruehlicke wrote:
> >
> > Just my 5 cents: We cannot afford to split the community. All
> >> users/developers should be using netbeans.apache.org as primary point
> of
> >> entry
> >
> >
> > Does that mean that everything on netbeans.org should redirect to
> > netbeans.apache.org?
> >
> > I don't know anything about that side of things -- i.e., if someone goes
> to
> > netbeans.org/kb/docs/java/quickstart.html, which is a URL that's all
> over
> > the web, at schools, universities, etc, should there simply be a redirect
> > from there to netbeans.apache.org/kb/docs/java/quickstart.html -- or is
> > there a different/better solution?
> >
> > Gj
> >
> >
> >
> > On Tue, May 2, 2017 at 3:49 PM, Christian Lenz <Ch...@gmx.net>
> > wrote:
> >
> >> In my opinion, it should work as before. E.g. we can check other IDEs
> and
> >> editors how they handle it.
> >>
> >> @Geertjan, this is the only content, what we need, yes. And than we
> should
> >> have a template around it with header, footer, nav and a common style
> for
> >> it.
> >>
> >>> Gesendet: Dienstag, 02. Mai 2017 um 15:37 Uhr
> >>> Von: "Bernd Ruehlicke" <be...@eriksfiord.com>
> >>> An: dev@netbeans.incubator.apache.org
> >>> Betreff: Re: NetBeans Apache Site Static Site Generator and Plan;
> >> Discussion
> >>>
> >>> Just my 5 cents: We cannot afford to split the community. All
> >>> users/developers should be using netbeans.apache.org as primary point
> of
> >>> entry. As now, there should be an area for IDE and one for the
> Platform.
> >>> Having both will allow users to possible explore new things they else
> >>> never would see.
> >>>
> >>> On 5/2/2017 7:58 AM, Geertjan Wielenga wrote:
> >>>> will netbeans.apache.org be for Apache NetBeans
> >>>> developers only or also for Apache NetBeans users,
> >>>
> >>>
> >>
>
>
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Wade Chandler <wa...@apache.org>.
This was my point earlier in the thread about how we can bring the sites (platform.netbeans.org/www.netbeans.org <http://platform.netbeans.org/www.netbeans.org>) etc into the SSG based site. We can use the same path layout, and even have .html on the end to allow for links to continue to work. Then, later, when fully at Apache, we can then get the domain names to point to the same content under the hood. i.e. platform.netbeans.org <http://platform.netbeans.org/> would just be a CNAME for www.netbeans.org <http://www.netbeans.org/>, and all the content would be under one source tree. Then, once that happens, and if we moved things over that way, the old links will work. I think there are some things which perhaps are no longer useful, but we can worry about that later. Too, we can later work on some redirect scheme if we decide we need to.
I suggest we work on the document here https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning <https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning>
I can write up how that will work with JBake, Gradle, and Scripts, for the above. The idea is to have Groovy scripts which strip out the base content specific sections of sites leaving the headers etc for the templates. Those different pages, based on the section of the site they are in, will be different page types, which means they link to different templates, allowing links on the sides of the pages in the templates to be context sensitive. The Groovy scripts (using JSoup to easily parse out HTML content) will also then add the required front matter/meta-data to the files to represent the page type. This can all be pretty automatic fed by a JSON document for guidance per sections and structures.
I can also put together examples of this, and that is what I’m doing now. The end result should support what you are wanting Gj, and is something I think is important too. This will also address what Christian and I are talking about related to templates and the site layout which is what allows us to maintain this stuff easier. The SSG also makes it easy to have a static blog section we can contribute to. I think future content we should use MD for the base content, to provide an easier editing experience, but what we bring over initially will be the HTML fragments that will be plugged into the templates by the SSG. Those MD content files will make adding new articles and posts to the site fairly trivial IMO.
Wade
===================
Wade Chandler
e: consult@wadechandler.com
> On May 2, 2017, at 09:53, Geertjan Wielenga <ge...@googlemail.com> wrote:
>
> On Tue, May 2, 2017 at 3:37 PM, Bernd Ruehlicke wrote:
>
> Just my 5 cents: We cannot afford to split the community. All
>> users/developers should be using netbeans.apache.org as primary point of
>> entry
>
>
> Does that mean that everything on netbeans.org should redirect to
> netbeans.apache.org?
>
> I don't know anything about that side of things -- i.e., if someone goes to
> netbeans.org/kb/docs/java/quickstart.html, which is a URL that's all over
> the web, at schools, universities, etc, should there simply be a redirect
> from there to netbeans.apache.org/kb/docs/java/quickstart.html -- or is
> there a different/better solution?
>
> Gj
>
>
>
> On Tue, May 2, 2017 at 3:49 PM, Christian Lenz <Ch...@gmx.net>
> wrote:
>
>> In my opinion, it should work as before. E.g. we can check other IDEs and
>> editors how they handle it.
>>
>> @Geertjan, this is the only content, what we need, yes. And than we should
>> have a template around it with header, footer, nav and a common style for
>> it.
>>
>>> Gesendet: Dienstag, 02. Mai 2017 um 15:37 Uhr
>>> Von: "Bernd Ruehlicke" <be...@eriksfiord.com>
>>> An: dev@netbeans.incubator.apache.org
>>> Betreff: Re: NetBeans Apache Site Static Site Generator and Plan;
>> Discussion
>>>
>>> Just my 5 cents: We cannot afford to split the community. All
>>> users/developers should be using netbeans.apache.org as primary point of
>>> entry. As now, there should be an area for IDE and one for the Platform.
>>> Having both will allow users to possible explore new things they else
>>> never would see.
>>>
>>> On 5/2/2017 7:58 AM, Geertjan Wielenga wrote:
>>>> will netbeans.apache.org be for Apache NetBeans
>>>> developers only or also for Apache NetBeans users,
>>>
>>>
>>
Re: Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Tue, May 2, 2017 at 3:37 PM, Bernd Ruehlicke wrote:
Just my 5 cents: We cannot afford to split the community. All
> users/developers should be using netbeans.apache.org as primary point of
> entry
Does that mean that everything on netbeans.org should redirect to
netbeans.apache.org?
I don't know anything about that side of things -- i.e., if someone goes to
netbeans.org/kb/docs/java/quickstart.html, which is a URL that's all over
the web, at schools, universities, etc, should there simply be a redirect
from there to netbeans.apache.org/kb/docs/java/quickstart.html -- or is
there a different/better solution?
Gj
On Tue, May 2, 2017 at 3:49 PM, Christian Lenz <Ch...@gmx.net>
wrote:
> In my opinion, it should work as before. E.g. we can check other IDEs and
> editors how they handle it.
>
> @Geertjan, this is the only content, what we need, yes. And than we should
> have a template around it with header, footer, nav and a common style for
> it.
>
> > Gesendet: Dienstag, 02. Mai 2017 um 15:37 Uhr
> > Von: "Bernd Ruehlicke" <be...@eriksfiord.com>
> > An: dev@netbeans.incubator.apache.org
> > Betreff: Re: NetBeans Apache Site Static Site Generator and Plan;
> Discussion
> >
> > Just my 5 cents: We cannot afford to split the community. All
> > users/developers should be using netbeans.apache.org as primary point of
> > entry. As now, there should be an area for IDE and one for the Platform.
> > Having both will allow users to possible explore new things they else
> > never would see.
> >
> > On 5/2/2017 7:58 AM, Geertjan Wielenga wrote:
> > > will netbeans.apache.org be for Apache NetBeans
> > > developers only or also for Apache NetBeans users,
> >
> >
>
Aw: Re: NetBeans Apache Site Static Site Generator and Plan;
Discussion
Posted by Christian Lenz <Ch...@gmx.net>.
In my opinion, it should work as before. E.g. we can check other IDEs and editors how they handle it.
@Geertjan, this is the only content, what we need, yes. And than we should have a template around it with header, footer, nav and a common style for it.
> Gesendet: Dienstag, 02. Mai 2017 um 15:37 Uhr
> Von: "Bernd Ruehlicke" <be...@eriksfiord.com>
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
>
> Just my 5 cents: We cannot afford to split the community. All
> users/developers should be using netbeans.apache.org as primary point of
> entry. As now, there should be an area for IDE and one for the Platform.
> Having both will allow users to possible explore new things they else
> never would see.
>
> On 5/2/2017 7:58 AM, Geertjan Wielenga wrote:
> > will netbeans.apache.org be for Apache NetBeans
> > developers only or also for Apache NetBeans users,
>
>
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Bernd Ruehlicke <be...@eriksfiord.com>.
Just my 5 cents: We cannot afford to split the community. All
users/developers should be using netbeans.apache.org as primary point of
entry. As now, there should be an area for IDE and one for the Platform.
Having both will allow users to possible explore new things they else
never would see.
On 5/2/2017 7:58 AM, Geertjan Wielenga wrote:
> will netbeans.apache.org be for Apache NetBeans
> developers only or also for Apache NetBeans users,
Re: Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Geertjan Wielenga <ge...@googlemail.com>.
http://netbeans.apache.org/kb/docs/java/quickstart.html
As a small temporary proof of concept experiment, I have copied the
NetBeans Quick Start tutorial in the above location.
Here's the original location on netbeans.org:
https://netbeans.org/kb/docs/java/quickstart.html
Now I understand better what I think we mean about the static site
generator etc, i.e., there's navigation and headers and footers and so on
that are currently missing in the netbeans.apache.org version of the
tutorial compared to the original.
The question is also whether netbeans.apache.org is going to be the same as
netbeans.org. I.e., will netbeans.apache.org be for Apache NetBeans
developers only or also for Apache NetBeans users, will it contain only
technical documents for developing NetBeans itself or will it also host
tutorials for NetBeans end users?
The same structure as at netbeans.org can be rebuilt at netbeans.apache.org,
that's something I can do after the documentation has officially been
donated as part of the 1st code donation.
Thoughts welcome.
Gj
On Mon, May 1, 2017 at 2:54 PM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> OK, maybe it got stripped out.
>
> Anyway, as far as I know, no static site generator is currently used. If
> all we're interested in is adding headers and footers automatically, then I
> suggest that's not something to concern ourselves with initially.
>
> Let's just get the tutorials in place as they are, with their headers and
> footers included, and worry later about how to include them automatically.
>
> Gj
>
>
> On Mon, May 1, 2017 at 2:46 PM, Emilian Bold <em...@gmail.com>
> wrote:
>
>> > Attached is one of the NetBeans tutorials, not generated from anywhere,
>> but exactly as it is worked on by the technical writers at Oracle.
>>
>> I see no attachment.
>>
>>
>> --emi
>>
>> On Mon, May 1, 2017 at 3:35 PM, Geertjan Wielenga <
>> geertjan.wielenga@googlemail.com> wrote:
>>
>> > Attached is one of the NetBeans tutorials, not generated from anywhere,
>> > but exactly as it is worked on by the technical writers at Oracle.
>> >
>> > Please note that if we use some kind of static site generator to
>> generate
>> > headers and footers, we'll first need to remove all the headers and
>> footers
>> > that are currently in the tutorials.
>> >
>> > I propose as a first step we (I, since I have access to all the
>> tutorials)
>> > move the tutorials into the new Apache website, i.e.,
>> netbeans.apache.org,
>> > and that after that we look at whether or not the headers and footers
>> need
>> > to be generated somehow.
>> >
>> > However, related to that, if we'll have netbeans.apache.org as well as
>> > netbeans.org, doesn't that means that the tutorials will be at
>> > netbeans.org and not at netbeans.apache.org?
>> >
>> > Gj
>> >
>> >
>> > On Mon, May 1, 2017 at 2:29 PM, Christian Lenz <Ch...@gmx.net>
>> > wrote:
>> >
>> >> We need a technology to not duplicate code at all. So have fixed
>> >> templates for header, nav and footer is a must have and a common
>> pattern to
>> >> not write the header, nav and footer each time. What happens if you
>> have to
>> >> change smth?
>> >> Maybe I miss smth or I misunderstood smth but this is what templates
>> are
>> >> made for. The static site generators are working the same AFAIK.
>> >>
>> >> > Gesendet: Montag, 01. Mai 2017 um 14:18 Uhr
>> >> > Von: "Geertjan Wielenga" <ge...@googlemail.com>
>> >> > An: dev@netbeans.incubator.apache.org
>> >> > Betreff: Re: NetBeans Apache Site Static Site Generator and Plan;
>> >> Discussion
>> >> >
>> >> > Do we need a static site generator at all? When I look at the
>> NetBeans
>> >> > tutorials, i.e., at the source documents of the NetBeans tutorials,
>> they
>> >> > all have their headers and footers etc hardcoded into the document
>> >> itself.
>> >> >
>> >> > I prefer simplicity over pretty much everything else -- and this
>> >> discussion
>> >> > is taking very long without much movement. All I believe we need is a
>> >> clear
>> >> > source structure and then the tutorials can simply be copied over.
>> >> >
>> >> > Gj
>> >> >
>> >> >
>> >> > On Thu, Apr 27, 2017 at 4:56 PM, Eric Barboni <sk...@apache.org>
>> wrote:
>> >> >
>> >> > > Hi,
>> >> > >
>> >> > > If possible, I will be happy to help or test even in early stage.
>> >> > > Regards,
>> >> > >
>> >> > > Eric
>> >> > > -----Message d'origine-----
>> >> > > De : Wade Chandler [mailto:wadechandler@apache.org]
>> >> > > Envoyé : jeudi 27 avril 2017 15:05
>> >> > > À : dev@netbeans.incubator.apache.org
>> >> > > Objet : Re: NetBeans Apache Site Static Site Generator and Plan;
>> >> Discussion
>> >> > >
>> >> > > On Apr 27, 2017 8:17 AM, "Bertrand Delacretaz" <
>> >> bdelacretaz@apache.org>
>> >> > > wrote:
>> >> > >
>> >> > > Hi,
>> >> > >
>> >> > > On Mon, Apr 24, 2017 at 6:36 PM, Wade Chandler <
>> >> wadechandler@apache.org>
>> >> > > wrote:
>> >> > > > ...I bring this up to have a conversation about it if needed, and
>> >> then
>> >> > > finally after that, to vote to make sure we have made some
>> >> decisions....
>> >> > >
>> >> > > I think it's very difficult to agree on such things without having
>> a
>> >> > > prototype to play with.
>> >> > >
>> >> > > I don't know how much work that is but it might be more efficient
>> for
>> >> you
>> >> > > to create a prototype of what you envision so that people can play
>> >> with it
>> >> > > and challenge assumptions based on concrete cases.
>> >> > >
>> >> > >
>> >> > > Indeed, and that is the next step I am working on, but I wanted to
>> be
>> >> sure
>> >> > > I use my tight time wisely, and nobody would vehemently appose as a
>> >> start.
>> >> > > I am working on a Gradle build with JBake and some Groovy scripts
>> to
>> >> > > massage in some content.
>> >> > >
>> >> > > Thanks
>> >> > >
>> >> > > Wade
>> >> > >
>> >> > >
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Geertjan Wielenga <ge...@googlemail.com>.
OK, maybe it got stripped out.
Anyway, as far as I know, no static site generator is currently used. If
all we're interested in is adding headers and footers automatically, then I
suggest that's not something to concern ourselves with initially.
Let's just get the tutorials in place as they are, with their headers and
footers included, and worry later about how to include them automatically.
Gj
On Mon, May 1, 2017 at 2:46 PM, Emilian Bold <em...@gmail.com> wrote:
> > Attached is one of the NetBeans tutorials, not generated from anywhere,
> but exactly as it is worked on by the technical writers at Oracle.
>
> I see no attachment.
>
>
> --emi
>
> On Mon, May 1, 2017 at 3:35 PM, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com> wrote:
>
> > Attached is one of the NetBeans tutorials, not generated from anywhere,
> > but exactly as it is worked on by the technical writers at Oracle.
> >
> > Please note that if we use some kind of static site generator to generate
> > headers and footers, we'll first need to remove all the headers and
> footers
> > that are currently in the tutorials.
> >
> > I propose as a first step we (I, since I have access to all the
> tutorials)
> > move the tutorials into the new Apache website, i.e.,
> netbeans.apache.org,
> > and that after that we look at whether or not the headers and footers
> need
> > to be generated somehow.
> >
> > However, related to that, if we'll have netbeans.apache.org as well as
> > netbeans.org, doesn't that means that the tutorials will be at
> > netbeans.org and not at netbeans.apache.org?
> >
> > Gj
> >
> >
> > On Mon, May 1, 2017 at 2:29 PM, Christian Lenz <Ch...@gmx.net>
> > wrote:
> >
> >> We need a technology to not duplicate code at all. So have fixed
> >> templates for header, nav and footer is a must have and a common
> pattern to
> >> not write the header, nav and footer each time. What happens if you
> have to
> >> change smth?
> >> Maybe I miss smth or I misunderstood smth but this is what templates are
> >> made for. The static site generators are working the same AFAIK.
> >>
> >> > Gesendet: Montag, 01. Mai 2017 um 14:18 Uhr
> >> > Von: "Geertjan Wielenga" <ge...@googlemail.com>
> >> > An: dev@netbeans.incubator.apache.org
> >> > Betreff: Re: NetBeans Apache Site Static Site Generator and Plan;
> >> Discussion
> >> >
> >> > Do we need a static site generator at all? When I look at the NetBeans
> >> > tutorials, i.e., at the source documents of the NetBeans tutorials,
> they
> >> > all have their headers and footers etc hardcoded into the document
> >> itself.
> >> >
> >> > I prefer simplicity over pretty much everything else -- and this
> >> discussion
> >> > is taking very long without much movement. All I believe we need is a
> >> clear
> >> > source structure and then the tutorials can simply be copied over.
> >> >
> >> > Gj
> >> >
> >> >
> >> > On Thu, Apr 27, 2017 at 4:56 PM, Eric Barboni <sk...@apache.org>
> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > If possible, I will be happy to help or test even in early stage.
> >> > > Regards,
> >> > >
> >> > > Eric
> >> > > -----Message d'origine-----
> >> > > De : Wade Chandler [mailto:wadechandler@apache.org]
> >> > > Envoyé : jeudi 27 avril 2017 15:05
> >> > > À : dev@netbeans.incubator.apache.org
> >> > > Objet : Re: NetBeans Apache Site Static Site Generator and Plan;
> >> Discussion
> >> > >
> >> > > On Apr 27, 2017 8:17 AM, "Bertrand Delacretaz" <
> >> bdelacretaz@apache.org>
> >> > > wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > On Mon, Apr 24, 2017 at 6:36 PM, Wade Chandler <
> >> wadechandler@apache.org>
> >> > > wrote:
> >> > > > ...I bring this up to have a conversation about it if needed, and
> >> then
> >> > > finally after that, to vote to make sure we have made some
> >> decisions....
> >> > >
> >> > > I think it's very difficult to agree on such things without having a
> >> > > prototype to play with.
> >> > >
> >> > > I don't know how much work that is but it might be more efficient
> for
> >> you
> >> > > to create a prototype of what you envision so that people can play
> >> with it
> >> > > and challenge assumptions based on concrete cases.
> >> > >
> >> > >
> >> > > Indeed, and that is the next step I am working on, but I wanted to
> be
> >> sure
> >> > > I use my tight time wisely, and nobody would vehemently appose as a
> >> start.
> >> > > I am working on a Gradle build with JBake and some Groovy scripts to
> >> > > massage in some content.
> >> > >
> >> > > Thanks
> >> > >
> >> > > Wade
> >> > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Emilian Bold <em...@gmail.com>.
> Attached is one of the NetBeans tutorials, not generated from anywhere,
but exactly as it is worked on by the technical writers at Oracle.
I see no attachment.
--emi
On Mon, May 1, 2017 at 3:35 PM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> Attached is one of the NetBeans tutorials, not generated from anywhere,
> but exactly as it is worked on by the technical writers at Oracle.
>
> Please note that if we use some kind of static site generator to generate
> headers and footers, we'll first need to remove all the headers and footers
> that are currently in the tutorials.
>
> I propose as a first step we (I, since I have access to all the tutorials)
> move the tutorials into the new Apache website, i.e., netbeans.apache.org,
> and that after that we look at whether or not the headers and footers need
> to be generated somehow.
>
> However, related to that, if we'll have netbeans.apache.org as well as
> netbeans.org, doesn't that means that the tutorials will be at
> netbeans.org and not at netbeans.apache.org?
>
> Gj
>
>
> On Mon, May 1, 2017 at 2:29 PM, Christian Lenz <Ch...@gmx.net>
> wrote:
>
>> We need a technology to not duplicate code at all. So have fixed
>> templates for header, nav and footer is a must have and a common pattern to
>> not write the header, nav and footer each time. What happens if you have to
>> change smth?
>> Maybe I miss smth or I misunderstood smth but this is what templates are
>> made for. The static site generators are working the same AFAIK.
>>
>> > Gesendet: Montag, 01. Mai 2017 um 14:18 Uhr
>> > Von: "Geertjan Wielenga" <ge...@googlemail.com>
>> > An: dev@netbeans.incubator.apache.org
>> > Betreff: Re: NetBeans Apache Site Static Site Generator and Plan;
>> Discussion
>> >
>> > Do we need a static site generator at all? When I look at the NetBeans
>> > tutorials, i.e., at the source documents of the NetBeans tutorials, they
>> > all have their headers and footers etc hardcoded into the document
>> itself.
>> >
>> > I prefer simplicity over pretty much everything else -- and this
>> discussion
>> > is taking very long without much movement. All I believe we need is a
>> clear
>> > source structure and then the tutorials can simply be copied over.
>> >
>> > Gj
>> >
>> >
>> > On Thu, Apr 27, 2017 at 4:56 PM, Eric Barboni <sk...@apache.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > If possible, I will be happy to help or test even in early stage.
>> > > Regards,
>> > >
>> > > Eric
>> > > -----Message d'origine-----
>> > > De : Wade Chandler [mailto:wadechandler@apache.org]
>> > > Envoyé : jeudi 27 avril 2017 15:05
>> > > À : dev@netbeans.incubator.apache.org
>> > > Objet : Re: NetBeans Apache Site Static Site Generator and Plan;
>> Discussion
>> > >
>> > > On Apr 27, 2017 8:17 AM, "Bertrand Delacretaz" <
>> bdelacretaz@apache.org>
>> > > wrote:
>> > >
>> > > Hi,
>> > >
>> > > On Mon, Apr 24, 2017 at 6:36 PM, Wade Chandler <
>> wadechandler@apache.org>
>> > > wrote:
>> > > > ...I bring this up to have a conversation about it if needed, and
>> then
>> > > finally after that, to vote to make sure we have made some
>> decisions....
>> > >
>> > > I think it's very difficult to agree on such things without having a
>> > > prototype to play with.
>> > >
>> > > I don't know how much work that is but it might be more efficient for
>> you
>> > > to create a prototype of what you envision so that people can play
>> with it
>> > > and challenge assumptions based on concrete cases.
>> > >
>> > >
>> > > Indeed, and that is the next step I am working on, but I wanted to be
>> sure
>> > > I use my tight time wisely, and nobody would vehemently appose as a
>> start.
>> > > I am working on a Gradle build with JBake and some Groovy scripts to
>> > > massage in some content.
>> > >
>> > > Thanks
>> > >
>> > > Wade
>> > >
>> > >
>> >
>>
>
>
Re: Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Attached is one of the NetBeans tutorials, not generated from anywhere, but
exactly as it is worked on by the technical writers at Oracle.
Please note that if we use some kind of static site generator to generate
headers and footers, we'll first need to remove all the headers and footers
that are currently in the tutorials.
I propose as a first step we (I, since I have access to all the tutorials)
move the tutorials into the new Apache website, i.e., netbeans.apache.org,
and that after that we look at whether or not the headers and footers need
to be generated somehow.
However, related to that, if we'll have netbeans.apache.org as well as
netbeans.org, doesn't that means that the tutorials will be at netbeans.org
and not at netbeans.apache.org?
Gj
On Mon, May 1, 2017 at 2:29 PM, Christian Lenz <Ch...@gmx.net>
wrote:
> We need a technology to not duplicate code at all. So have fixed templates
> for header, nav and footer is a must have and a common pattern to not write
> the header, nav and footer each time. What happens if you have to change
> smth?
> Maybe I miss smth or I misunderstood smth but this is what templates are
> made for. The static site generators are working the same AFAIK.
>
> > Gesendet: Montag, 01. Mai 2017 um 14:18 Uhr
> > Von: "Geertjan Wielenga" <ge...@googlemail.com>
> > An: dev@netbeans.incubator.apache.org
> > Betreff: Re: NetBeans Apache Site Static Site Generator and Plan;
> Discussion
> >
> > Do we need a static site generator at all? When I look at the NetBeans
> > tutorials, i.e., at the source documents of the NetBeans tutorials, they
> > all have their headers and footers etc hardcoded into the document
> itself.
> >
> > I prefer simplicity over pretty much everything else -- and this
> discussion
> > is taking very long without much movement. All I believe we need is a
> clear
> > source structure and then the tutorials can simply be copied over.
> >
> > Gj
> >
> >
> > On Thu, Apr 27, 2017 at 4:56 PM, Eric Barboni <sk...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > If possible, I will be happy to help or test even in early stage.
> > > Regards,
> > >
> > > Eric
> > > -----Message d'origine-----
> > > De : Wade Chandler [mailto:wadechandler@apache.org]
> > > Envoyé : jeudi 27 avril 2017 15:05
> > > À : dev@netbeans.incubator.apache.org
> > > Objet : Re: NetBeans Apache Site Static Site Generator and Plan;
> Discussion
> > >
> > > On Apr 27, 2017 8:17 AM, "Bertrand Delacretaz" <bdelacretaz@apache.org
> >
> > > wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Apr 24, 2017 at 6:36 PM, Wade Chandler <
> wadechandler@apache.org>
> > > wrote:
> > > > ...I bring this up to have a conversation about it if needed, and
> then
> > > finally after that, to vote to make sure we have made some
> decisions....
> > >
> > > I think it's very difficult to agree on such things without having a
> > > prototype to play with.
> > >
> > > I don't know how much work that is but it might be more efficient for
> you
> > > to create a prototype of what you envision so that people can play
> with it
> > > and challenge assumptions based on concrete cases.
> > >
> > >
> > > Indeed, and that is the next step I am working on, but I wanted to be
> sure
> > > I use my tight time wisely, and nobody would vehemently appose as a
> start.
> > > I am working on a Gradle build with JBake and some Groovy scripts to
> > > massage in some content.
> > >
> > > Thanks
> > >
> > > Wade
> > >
> > >
> >
>
Aw: Re: NetBeans Apache Site Static Site Generator and Plan;
Discussion
Posted by Christian Lenz <Ch...@gmx.net>.
We need a technology to not duplicate code at all. So have fixed templates for header, nav and footer is a must have and a common pattern to not write the header, nav and footer each time. What happens if you have to change smth?
Maybe I miss smth or I misunderstood smth but this is what templates are made for. The static site generators are working the same AFAIK.
> Gesendet: Montag, 01. Mai 2017 um 14:18 Uhr
> Von: "Geertjan Wielenga" <ge...@googlemail.com>
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
>
> Do we need a static site generator at all? When I look at the NetBeans
> tutorials, i.e., at the source documents of the NetBeans tutorials, they
> all have their headers and footers etc hardcoded into the document itself.
>
> I prefer simplicity over pretty much everything else -- and this discussion
> is taking very long without much movement. All I believe we need is a clear
> source structure and then the tutorials can simply be copied over.
>
> Gj
>
>
> On Thu, Apr 27, 2017 at 4:56 PM, Eric Barboni <sk...@apache.org> wrote:
>
> > Hi,
> >
> > If possible, I will be happy to help or test even in early stage.
> > Regards,
> >
> > Eric
> > -----Message d'origine-----
> > De : Wade Chandler [mailto:wadechandler@apache.org]
> > Envoyé : jeudi 27 avril 2017 15:05
> > À : dev@netbeans.incubator.apache.org
> > Objet : Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
> >
> > On Apr 27, 2017 8:17 AM, "Bertrand Delacretaz" <bd...@apache.org>
> > wrote:
> >
> > Hi,
> >
> > On Mon, Apr 24, 2017 at 6:36 PM, Wade Chandler <wa...@apache.org>
> > wrote:
> > > ...I bring this up to have a conversation about it if needed, and then
> > finally after that, to vote to make sure we have made some decisions....
> >
> > I think it's very difficult to agree on such things without having a
> > prototype to play with.
> >
> > I don't know how much work that is but it might be more efficient for you
> > to create a prototype of what you envision so that people can play with it
> > and challenge assumptions based on concrete cases.
> >
> >
> > Indeed, and that is the next step I am working on, but I wanted to be sure
> > I use my tight time wisely, and nobody would vehemently appose as a start.
> > I am working on a Gradle build with JBake and some Groovy scripts to
> > massage in some content.
> >
> > Thanks
> >
> > Wade
> >
> >
>
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Do we need a static site generator at all? When I look at the NetBeans
tutorials, i.e., at the source documents of the NetBeans tutorials, they
all have their headers and footers etc hardcoded into the document itself.
I prefer simplicity over pretty much everything else -- and this discussion
is taking very long without much movement. All I believe we need is a clear
source structure and then the tutorials can simply be copied over.
Gj
On Thu, Apr 27, 2017 at 4:56 PM, Eric Barboni <sk...@apache.org> wrote:
> Hi,
>
> If possible, I will be happy to help or test even in early stage.
> Regards,
>
> Eric
> -----Message d'origine-----
> De : Wade Chandler [mailto:wadechandler@apache.org]
> Envoyé : jeudi 27 avril 2017 15:05
> À : dev@netbeans.incubator.apache.org
> Objet : Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
>
> On Apr 27, 2017 8:17 AM, "Bertrand Delacretaz" <bd...@apache.org>
> wrote:
>
> Hi,
>
> On Mon, Apr 24, 2017 at 6:36 PM, Wade Chandler <wa...@apache.org>
> wrote:
> > ...I bring this up to have a conversation about it if needed, and then
> finally after that, to vote to make sure we have made some decisions....
>
> I think it's very difficult to agree on such things without having a
> prototype to play with.
>
> I don't know how much work that is but it might be more efficient for you
> to create a prototype of what you envision so that people can play with it
> and challenge assumptions based on concrete cases.
>
>
> Indeed, and that is the next step I am working on, but I wanted to be sure
> I use my tight time wisely, and nobody would vehemently appose as a start.
> I am working on a Gradle build with JBake and some Groovy scripts to
> massage in some content.
>
> Thanks
>
> Wade
>
>
RE: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Eric Barboni <sk...@apache.org>.
Hi,
If possible, I will be happy to help or test even in early stage.
Regards,
Eric
-----Message d'origine-----
De : Wade Chandler [mailto:wadechandler@apache.org]
Envoyé : jeudi 27 avril 2017 15:05
À : dev@netbeans.incubator.apache.org
Objet : Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
On Apr 27, 2017 8:17 AM, "Bertrand Delacretaz" <bd...@apache.org>
wrote:
Hi,
On Mon, Apr 24, 2017 at 6:36 PM, Wade Chandler <wa...@apache.org>
wrote:
> ...I bring this up to have a conversation about it if needed, and then
finally after that, to vote to make sure we have made some decisions....
I think it's very difficult to agree on such things without having a prototype to play with.
I don't know how much work that is but it might be more efficient for you to create a prototype of what you envision so that people can play with it and challenge assumptions based on concrete cases.
Indeed, and that is the next step I am working on, but I wanted to be sure I use my tight time wisely, and nobody would vehemently appose as a start.
I am working on a Gradle build with JBake and some Groovy scripts to massage in some content.
Thanks
Wade
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Emilian Bold <em...@gmail.com>.
I'm arriving late some maybe I've missed this but: do we have the raw
NetBeans website content somewhere?
I mean, I could run a recursive wget, but I assume they are not all static
HTML pages, no? There is some CMS on NetBeans servers that stores only the
body without the headers, footers, etc. Do we get a dump of that CMS?
--emi
On Thu, Apr 27, 2017 at 5:43 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Thu, Apr 27, 2017 at 3:05 PM, Wade Chandler <wa...@apache.org>
> wrote:
> > ...I am working on a Gradle build with JBake and some Groovy scripts to
> > massage in some content...
>
> Cool! FWIW I'm looking at doing something similar for Sling...in my
> non-existent Copious Free Time.
> I'll try to have a look at what you come up with and provide feedback
> from a slighty different angle.
>
> -Bertrand
>
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Apr 27, 2017 at 3:05 PM, Wade Chandler <wa...@apache.org> wrote:
> ...I am working on a Gradle build with JBake and some Groovy scripts to
> massage in some content...
Cool! FWIW I'm looking at doing something similar for Sling...in my
non-existent Copious Free Time.
I'll try to have a look at what you come up with and provide feedback
from a slighty different angle.
-Bertrand
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Wade Chandler <wa...@apache.org>.
On Apr 27, 2017 8:17 AM, "Bertrand Delacretaz" <bd...@apache.org>
wrote:
Hi,
On Mon, Apr 24, 2017 at 6:36 PM, Wade Chandler <wa...@apache.org>
wrote:
> ...I bring this up to have a conversation about it if needed, and then
finally after that, to vote to make sure we have made some decisions....
I think it's very difficult to agree on such things without having a
prototype to play with.
I don't know how much work that is but it might be more efficient for
you to create a prototype of what you envision so that people can play
with it and challenge assumptions based on concrete cases.
Indeed, and that is the next step I am working on, but I wanted to be sure
I use my tight time wisely, and nobody would vehemently appose as a start.
I am working on a Gradle build with JBake and some Groovy scripts to
massage in some content.
Thanks
Wade
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Apr 24, 2017 at 6:36 PM, Wade Chandler <wa...@apache.org> wrote:
> ...I bring this up to have a conversation about it if needed, and then finally after that, to vote to make sure we have made some decisions....
I think it's very difficult to agree on such things without having a
prototype to play with.
I don't know how much work that is but it might be more efficient for
you to create a prototype of what you envision so that people can play
with it and challenge assumptions based on concrete cases.
-Bertrand
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Wade Chandler <wa...@apache.org>.
> On Apr 27, 2017, at 07:26, Neil C Smith <ne...@googlemail.com> wrote:
>
> On Wed, Apr 26, 2017 at 4:08 PM Wade Chandler <wa...@apache.org>
> wrote:>
>
>>> I want to know if ssg can also help maintaining the site. (a bit of
>> NetCAT view)
>>> Assuming I can tag tutorial to precise netbeans version i.e. Netbeans
>> 8.1, and that I build the site setup that current release is Netbeans 8.2
>> can ssg log that tutorials are not reviewed for release 8.2?
>>> others warning, linkcheck …
>>
>> This would be some post processing which can be built in a Gradle build or
>> by way of custom code or contributions. Were this Jekyll, then it would be
>> custom Ruby plugins
>>
>
> Personally I'll be surprised if we *need* custom plugins. Having had more
> of a flick through the docs for Thymeleaf, I'd say Liquid and Thymeleaf
> seem very similar in functionality available (the syntax of Thymeleaf does
> look appealing for editing). The above scenario should be pretty simple to
> achieve without custom plugins. Of course, plugins may sometimes make
> things *nicer* to work with.
>
I caution folks against thinking the SSG template is the end all be all. Link checking is a process separate from static site issues, in that something needs to work through the site verifying links, building a report of broken ones, and placing it some where which may be shown by the SSG just as an example, so different use cases and concerns, and is where Gradle and its many plugins plus Groovy scripts or tests (Geb specifications) can come in really handy.
> One thing that should be considered, and may need a plugin or some thought,
> is media management, and specifically image (re)sizing. We're actually
> using Imgix on out Jekyll client sites to automatically resize/crop images,
> or serve responsive images to different devices. Having image sizes
> defined in one Liquid/Thymeleaf is very useful! Now, we might not want to
> use a resizing image proxy, so a plugin might come into play here.
> However, there are a number of open-source image proxies too. I don't know
> whether this feature is built into or has been considered for Apache
> hosting, but it would seem a nice-to-have across Apache projects.
>
Indeed, but yes, we could do this as a post processing for the SSG with a Gradle plugin (or task with some local CLI) as an example, and then use CSS media for the cases it is a style related graphic. Another approach is to crop and build those while images are being made as well unless different sizes need to be made. Or, yes, a 3rd party service, but certainly that type processing, local or dynamic, has its own drawbacks in some cases where the image can not just be fit or cropped to fit, the screen, but needs more attention, and is where folks using the system need to understand it. Just putting out another cautionary tale about such tools, just so those not familiar are clear.
Thanks,
Wade
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Neil C Smith <ne...@googlemail.com>.
On Wed, Apr 26, 2017 at 4:08 PM Wade Chandler <wa...@apache.org>
wrote:>
> > I want to know if ssg can also help maintaining the site. (a bit of
> NetCAT view)
> > Assuming I can tag tutorial to precise netbeans version i.e. Netbeans
> 8.1, and that I build the site setup that current release is Netbeans 8.2
> can ssg log that tutorials are not reviewed for release 8.2?
> > others warning, linkcheck …
>
> This would be some post processing which can be built in a Gradle build or
> by way of custom code or contributions. Were this Jekyll, then it would be
> custom Ruby plugins
>
Personally I'll be surprised if we *need* custom plugins. Having had more
of a flick through the docs for Thymeleaf, I'd say Liquid and Thymeleaf
seem very similar in functionality available (the syntax of Thymeleaf does
look appealing for editing). The above scenario should be pretty simple to
achieve without custom plugins. Of course, plugins may sometimes make
things *nicer* to work with.
One thing that should be considered, and may need a plugin or some thought,
is media management, and specifically image (re)sizing. We're actually
using Imgix on out Jekyll client sites to automatically resize/crop images,
or serve responsive images to different devices. Having image sizes
defined in one Liquid/Thymeleaf is very useful! Now, we might not want to
use a resizing image proxy, so a plugin might come into play here.
However, there are a number of open-source image proxies too. I don't know
whether this feature is built into or has been considered for Apache
hosting, but it would seem a nice-to-have across Apache projects.
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
RE: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Eric Barboni <sk...@apache.org>.
Hi,
Ok if I get it right, with some kind of plugging we will do we may have the customisation we want for outputting a page.
The linkcheck was a misleading example (but this is maybe kind of tool we may need anyway), I will try to explain better my vision.
I may create a page with a marking language with a link to an issue like that:
[[http://netbeans.org/Bugzilla/issue#23]Issue23]
But with create some plugin to allow a shortcut for making possible to add a lot more of html around and css class...
[macroissue[23]]
So the point now is does ssg allow parsing of the "source" during site build
to get the pattern http://netbeans.org/Bugzilla and generate a list of missing usage of macrosissue in a logfile somewhere on the continuous build server workspace ?
that’s would help building a coherent site step by step.
Same vision can maybe help getting list of tutorial compatible with current release by looking for metadata_headers ..
If all of the ssg tools in the list are able to process we will need to customize for our needs.
At the end, I personally would go for the jbake as it is java based.
Regards
Eric
-----Message d'origine-----
De : Wade Chandler [mailto:wadechandler@apache.org]
Envoyé : mercredi 26 avril 2017 17:08
À : dev@netbeans.incubator.apache.org
Objet : Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
> On Apr 26, 2017, at 08:16, Eric Barboni <sk...@apache.org> wrote:
>
> Hi Wade,
>
> I'm not very aware of the ssg potential. I want to anticipate how ssg may help to maintain Netbeans web site.
To be clear/thorough, an SSG allows us to have a single header or different headers for different sections of the site, along with footers, badges, styling, etc, managed independently from the individual content pages of the site, and really brand the site without repeating ourselves, while yet producing a static web site not served with an application server, or no server side logic ran at Apache, which is a requirement outside of Jira, the Wiki, and other 3rd party services such as Disqus.
>
> I assume it will be possible to have some "macros" to make some abstraction in the site code.
> Some usecase concerning generation:
> in a tutorial page we may put something to declare "this tutorial is for version 6 and 8" and then the ssg generate the nice bagde.
> We may want to link to api doc or Bugzilla/jira by having a macro that may add some complex html/js/css to have status of issue or deprecation of api.
> Table of content generation in some pages, table of content among several page...
>
Templates certainly allow this; see http://jbake.org/docs/2.5.1/#metadata_header <http://jbake.org/docs/2.5.1/#metadata_header> as an example of that type thing in JBake. See “Front Matter” in Jekyll terminology https://jekyllrb.com/docs/frontmatter <https://jekyllrb.com/docs/frontmatter>. Templates will then use this information to fill in extra page details with the content being placed where the content is output in the template; meta-data and content in the file being separate bits in the output.
>
> I want to know if ssg can also help maintaining the site. (a bit of
> NetCAT view) Assuming I can tag tutorial to precise netbeans version i.e. Netbeans 8.1, and that I build the site setup that current release is Netbeans 8.2 can ssg log that tutorials are not reviewed for release 8.2?
> others warning, linkcheck …
This would be some post processing which can be built in a Gradle build or by way of custom code or contributions. Were this Jekyll, then it would be custom Ruby plugins
But, I may not be clear on what you want exactly.
Another way is to maintain that information separate, and then just some pages would display the information from what ever system it is. This could be a JSON file in the sources as a checklist, a Google Doc with those APIs, or something else, but that something else would need an API, and that would need to be handled separately, login etc, as static sites do not have a backend component other than 3rd party services.
Anyways, I think you’d have to get more into that from a requirements perspective, and I think we can do all of these as part of the plan; see more on that below.
Link checks can be done as a post process site check using something like Geb or Selenium etc to specifically address that, and we can upload reports to some location which can be shared on the site. I think we need to figure out what pieces we want to track in source control, and what pieces we want to track outside of that to be sure the best places for any given data.
>
> Import:
> a)We may want to had tutorial that are under other subdomains like
> platform.netbeans.org
> https://platform.netbeans.org/tutorials/nbm-feedreader.html
> b)We may also add some of the wiki page that looks like tutorials or
> good practices http://wiki.netbeans.org/MavenBestPractices
>
Sure, and there will inevitably be some massaging to get the structure and content fully in place with branding etc. The kb site section as an example https://netbeans.org/kb/ <https://netbeans.org/kb/>. I suggest we want as much as we can get, but need to make some decisions. The main static site would be a good start, and then the rest can be worked in.
Those sub-domains, we need to decide what we can do with those to keep links alive as much as possible. i.e. since Oracle is donating netbeans.org <http://netbeans.org/>, then if Apache supports sub-domains in infra, then that should be doable, and if the content can be accessed by either sub-domain, then no worries; we would generate a single static site. If it had to be multiple, then we may be able to do that, but I’m not sure what a project is allowed in that regard ATM.
I’m thinking a single one with sub-domains pointing at the same content just to keep links alive considering how old NetBeans is, meaning a lot of content, unless of course we vote that doesn’t matter, and we clean up a good bit (or leave a good bit). All these pieces will need to be broken down on that plan page, and then discussed separately here I believe; pretty broad topic now.
> Concerning the plan, what will be the process ?
> Any push to site will regenerate the live one ? or staging ?
> How to prepare new content without breaking site.
> Vote to add/remove tutorial ? or committer can publish at will ?
>
All TBD, at the moment we need to get the pieces in place which we can even build from. The first iteration of the plan from my POV is to figure out how to get things setup for an SSG, and how to add current pages, as well as how to run some scripts for massaging the content into the format (pull out the main article content etc; basic first pass importing of some large subset). That is what I plan on working on ATM, and is the plan I’m looking to get in place on the referenced page. Even if we manually have one of us run the build to merge to the asf-site branch, it will be better than nothing. Then, yes, automation.
We haven’t discussed staging versus live yet. Link checking among some other things, if able to be part of the main build, then could be used to gate to the live site, but not sure it requires a staging site to do that as much as a temporary place to hit with tests, which could be “build local", but a staging site does allow us a place to get opinions on new directions. New content itself, if we have templates in place shouldn’t break the site, but could break a given page. Template edits or logic changes, certainly could.
We need to vote on some other policies though after some thread specific discussions I imagine, so this is all good stuff to add to that Wiki page. Everyone please feel free to add questions to the page https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning <https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning> in comments or notes, or make some edits to add some new sections, and if you haven’t used Confluence before, just checkout the best way to annotate the points you need to make such as inline comments (login, and when NOT in “edit mode” highlight some text), comments section at the bottom of the page, or actual page edits (help link if more info needed):
https://confluence.atlassian.com/conf58/getting-help-and-support-771893129.html <https://confluence.atlassian.com/conf58/getting-help-and-support-771893129.html>
> I hope the ssg build tools can handle those concerns.
SSGs can do a lot, but I think some concerns will be separate from the SSG necessarily, and we’ll just have to get into what those are for any given concern/feature.
Thanks,
Wade
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Wade Chandler <wa...@apache.org>.
> On Apr 26, 2017, at 08:16, Eric Barboni <sk...@apache.org> wrote:
>
> Hi Wade,
>
> I'm not very aware of the ssg potential. I want to anticipate how ssg may help to maintain Netbeans web site.
To be clear/thorough, an SSG allows us to have a single header or different headers for different sections of the site, along with footers, badges, styling, etc, managed independently from the individual content pages of the site, and really brand the site without repeating ourselves, while yet producing a static web site not served with an application server, or no server side logic ran at Apache, which is a requirement outside of Jira, the Wiki, and other 3rd party services such as Disqus.
>
> I assume it will be possible to have some "macros" to make some abstraction in the site code.
> Some usecase concerning generation:
> in a tutorial page we may put something to declare "this tutorial is for version 6 and 8" and then the ssg generate the nice bagde.
> We may want to link to api doc or Bugzilla/jira by having a macro that may add some complex html/js/css to have status of issue or deprecation of api.
> Table of content generation in some pages, table of content among several page...
>
Templates certainly allow this; see http://jbake.org/docs/2.5.1/#metadata_header <http://jbake.org/docs/2.5.1/#metadata_header> as an example of that type thing in JBake. See “Front Matter” in Jekyll terminology https://jekyllrb.com/docs/frontmatter <https://jekyllrb.com/docs/frontmatter>. Templates will then use this information to fill in extra page details with the content being placed where the content is output in the template; meta-data and content in the file being separate bits in the output.
>
> I want to know if ssg can also help maintaining the site. (a bit of NetCAT view)
> Assuming I can tag tutorial to precise netbeans version i.e. Netbeans 8.1, and that I build the site setup that current release is Netbeans 8.2 can ssg log that tutorials are not reviewed for release 8.2?
> others warning, linkcheck …
This would be some post processing which can be built in a Gradle build or by way of custom code or contributions. Were this Jekyll, then it would be custom Ruby plugins
But, I may not be clear on what you want exactly.
Another way is to maintain that information separate, and then just some pages would display the information from what ever system it is. This could be a JSON file in the sources as a checklist, a Google Doc with those APIs, or something else, but that something else would need an API, and that would need to be handled separately, login etc, as static sites do not have a backend component other than 3rd party services.
Anyways, I think you’d have to get more into that from a requirements perspective, and I think we can do all of these as part of the plan; see more on that below.
Link checks can be done as a post process site check using something like Geb or Selenium etc to specifically address that, and we can upload reports to some location which can be shared on the site. I think we need to figure out what pieces we want to track in source control, and what pieces we want to track outside of that to be sure the best places for any given data.
>
> Import:
> a)We may want to had tutorial that are under other subdomains like platform.netbeans.org
> https://platform.netbeans.org/tutorials/nbm-feedreader.html
> b)We may also add some of the wiki page that looks like tutorials or good practices
> http://wiki.netbeans.org/MavenBestPractices
>
Sure, and there will inevitably be some massaging to get the structure and content fully in place with branding etc. The kb site section as an example https://netbeans.org/kb/ <https://netbeans.org/kb/>. I suggest we want as much as we can get, but need to make some decisions. The main static site would be a good start, and then the rest can be worked in.
Those sub-domains, we need to decide what we can do with those to keep links alive as much as possible. i.e. since Oracle is donating netbeans.org <http://netbeans.org/>, then if Apache supports sub-domains in infra, then that should be doable, and if the content can be accessed by either sub-domain, then no worries; we would generate a single static site. If it had to be multiple, then we may be able to do that, but I’m not sure what a project is allowed in that regard ATM.
I’m thinking a single one with sub-domains pointing at the same content just to keep links alive considering how old NetBeans is, meaning a lot of content, unless of course we vote that doesn’t matter, and we clean up a good bit (or leave a good bit). All these pieces will need to be broken down on that plan page, and then discussed separately here I believe; pretty broad topic now.
> Concerning the plan, what will be the process ?
> Any push to site will regenerate the live one ? or staging ?
> How to prepare new content without breaking site.
> Vote to add/remove tutorial ? or committer can publish at will ?
>
All TBD, at the moment we need to get the pieces in place which we can even build from. The first iteration of the plan from my POV is to figure out how to get things setup for an SSG, and how to add current pages, as well as how to run some scripts for massaging the content into the format (pull out the main article content etc; basic first pass importing of some large subset). That is what I plan on working on ATM, and is the plan I’m looking to get in place on the referenced page. Even if we manually have one of us run the build to merge to the asf-site branch, it will be better than nothing. Then, yes, automation.
We haven’t discussed staging versus live yet. Link checking among some other things, if able to be part of the main build, then could be used to gate to the live site, but not sure it requires a staging site to do that as much as a temporary place to hit with tests, which could be “build local", but a staging site does allow us a place to get opinions on new directions. New content itself, if we have templates in place shouldn’t break the site, but could break a given page. Template edits or logic changes, certainly could.
We need to vote on some other policies though after some thread specific discussions I imagine, so this is all good stuff to add to that Wiki page. Everyone please feel free to add questions to the page https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning <https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning> in comments or notes, or make some edits to add some new sections, and if you haven’t used Confluence before, just checkout the best way to annotate the points you need to make such as inline comments (login, and when NOT in “edit mode” highlight some text), comments section at the bottom of the page, or actual page edits (help link if more info needed):
https://confluence.atlassian.com/conf58/getting-help-and-support-771893129.html <https://confluence.atlassian.com/conf58/getting-help-and-support-771893129.html>
> I hope the ssg build tools can handle those concerns.
SSGs can do a lot, but I think some concerns will be separate from the SSG necessarily, and we’ll just have to get into what those are for any given concern/feature.
Thanks,
Wade
RE: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Eric Barboni <sk...@apache.org>.
Hi Wade,
I'm not very aware of the ssg potential. I want to anticipate how ssg may help to maintain Netbeans web site.
I assume it will be possible to have some "macros" to make some abstraction in the site code.
Some usecase concerning generation:
in a tutorial page we may put something to declare "this tutorial is for version 6 and 8" and then the ssg generate the nice bagde.
We may want to link to api doc or Bugzilla/jira by having a macro that may add some complex html/js/css to have status of issue or deprecation of api.
Table of content generation in some pages, table of content among several page...
I want to know if ssg can also help maintaining the site. (a bit of NetCAT view)
Assuming I can tag tutorial to precise netbeans version i.e. Netbeans 8.1, and that I build the site setup that current release is Netbeans 8.2 can ssg log that tutorials are not reviewed for release 8.2?
others warning, linkcheck ...
Import:
a)We may want to had tutorial that are under other subdomains like platform.netbeans.org
https://platform.netbeans.org/tutorials/nbm-feedreader.html
b)We may also add some of the wiki page that looks like tutorials or good practices
http://wiki.netbeans.org/MavenBestPractices
Concerning the plan, what will be the process ?
Any push to site will regenerate the live one ? or staging ?
How to prepare new content without breaking site.
Vote to add/remove tutorial ? or committer can publish at will ?
I hope the ssg build tools can handle those concerns.
Best regards
Eric
-----Message d'origine-----
De : Wade Chandler [mailto:wadechandler@apache.org]
Envoyé : lundi 24 avril 2017 18:36
À : dev@netbeans.incubator.apache.org
Objet : NetBeans Apache Site Static Site Generator and Plan; Discussion
All,
I have been reviewing different static site generators for a good bit. I have also been reviewing the current NB site structure and content/files. I have also been working on this document in the Wiki:
https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning <https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning>
I give reasonings for static site generator choices as well as some context on things reviewed/studied. Notice I’m suggesting JBake as a starting point along with a Gradle build which can fill in some preprocessing gaps. I’m also starting to work on a plan for using it to get the current site moved over; have to start some where.
I bring this up to have a conversation about it if needed, and then finally after that, to vote to make sure we have made some decisions. I think if nobody has an issue with using JBake as a starting point as mentioned in the document, then we could have a vote on it soon/immediately, and then later the plan or options.
To come up with a full on plan takes writing some scripts as mentioned in the document, and trying out some things with Groovy and JSoup at the moment, so not super trivial, but not really hard either, but does take time. Then, once some tools for conversion which will be needed no matter the SSG choice are in place, we can generate a sub-set of what is on netbeans.org <http://netbeans.org/> merged with what Christian Lenz has already started for the new site.
This will be working with the Oracle folks (mainly Gj) to get the files over to Apache as part of the donation, but moving them over into this structure to be statically generated by automation at some point, but initially manually and pushed by an individual albeit running the tools (still simpler and less time consuming). I’m hoping the scripts I mentioned make this easier, and is what I’m focusing on now to get together a subset for demonstration.
I’m also working on setting up a Salon for my wife’s business at the moment, so a lot of different pots on the fire at the moment, so please be patient, but it will be soon.
Thanks much, and look forward to input and discussion,
Wade
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Interestingly Codename One is a friend of ours, they're part of the
NetBeans community, have a popular NetBeans plugin, etc.
Gj
On Tuesday, April 25, 2017, John McDonnell <mc...@gmail.com> wrote:
> I don’t know enough about the different SSG’s to effectively comment, but
> looking at the JBake website, they provide a list of sites that use JBake,
> and the only decent one looks to be Codename One, a lot of the rest of them
> look to be blogs(obviously there are exceptions like http://konik.io <
> http://konik.io/> etc) .
>
> Probably not a great advertisement for it, since the existing NB site
> isn’t really set up like a blog?
>
> Maybe we need to trail out a few of these SSGs, i.e. attempt to convert
> parts of the existing NB site to a handful and compare and contrast the
> difficulties faced, and lessons learned, etc..
>
> Regards
>
> John
>
>
>
> > On 24 Apr 2017, at 22:45, Wade Chandler <wadechandler@apache.org
> <javascript:;>> wrote:
> >
> >
> >> On Apr 24, 2017, at 16:02, Neil C Smith <neilcsmith.net@googlemail.com
> <javascript:;>> wrote:
> >>
> >> On Mon, Apr 24, 2017 at 8:59 PM Wade Chandler <wadechandler@apache.org
> <javascript:;>>
> >> wrote:
> >>
> >>> Did you read the page along with the points on content input or using
> .html
> >>> files as content/pages/posts, and the criteria?
> >>>
> >>
> >> My vote would probably be with Jekyll too, at least from a personal
> >> familiarity point of view, as well as the larger user base. It is not
> >> clear from your document what you think is missing for Jekyll to meet
> your
> >> criteria.
> >>
> >
> > I updated the document in the Jekyll section. I thought I had added that
> it seems to not support .html files as content (input) outside of templates
> and static files, but then I was re-reading the docs, and it wasn’t super
> clear, but it does support that out of the box. One limitation I still see
> is that is only supports Liquid templates, and Liquid doesn’t support logic
> as Thymeleaf, Groovy, and Freemarker can, or Nikola’s Python setup, which
> can come in handy for template work, and this due to running on GitHub
> pages build servers (can’t do a lot with it without writing Jekyll plugins
> unless you all know different).
> >
> > I’m not beyond using Jekyll, but would like to know why not weight a
> project which supports other Apache technologies, and which is also using
> the many technologies the NetBeans IDE supports higher or take those things
> into consideration as well? We will not be building with GitHub pages, so
> keep that in mind, so we don’t have limitations Liquid imposes, and I also
> assume that Jekyll is popular because GitHub is popular, and it is the only
> way to automate the GitHub pages builds without pushing a static site from
> another build stack (something else one needs to pay for to run). You
> mention having more experience with it, so if you and Emilian think it a
> great choice, I value those opinions as well, but would like us to weight
> this with other criteria, or at least discuss it.
> >
> > Some of the criteria was based on looking at the ecosystem the IDE
> resides, and it seems we can contribute to JBake just as we do NetBeans
> while supporting that ecosystem. For me there is value in that as well;
> from this new community we find ourselves. I also see value in being able
> to tie into the Gradle, Groovy, and Java toolchains and libraries and
> plugins. JBake also seems rather simplistic, and I can see getting off the
> ground with it plus some other Groovy scripts for some file manipulation
> all driven from a Gradle build.
> >
> > I weighted Java ecosystem technologies higher with an assumption more on
> this list will have more familiarity with those tool chains, and the
> template engines of JBake fall under that criterion. I personally tend
> towards those technologies as they more directly fit into my mental model
> per the tool chains I have been working within the past so many years;
> Gradle, Groovy, Java, and then of course Node JS toolsets with Angular.
> >
> > If we want to contribute to Jekyll for any needs, then we get into Ruby
> land, which I don’t mind so much, but don’t personally find it to be a
> language of choice, but more importantly is completely outside of the
> communities here at Apache other than GitHub usage, but perhaps it doesn’t
> matter.
> >
> > Let’s see what others say, and too what you and Emilian think about the
> above, and can go from there. I think either way we will have to create
> some scripts to do a little find tuning of the content to get it to fit
> into structures (front matter, snippets, templates etc), for which ever SSG
> we choose, and I know I can easily do that with Groovy and JSoup, but that
> doesn’t mean we can’t use various toolchains; I just thought JBake would
> fold nicely with those, and probably make some of it less complex
> initially, but that could be an incorrect assumption.
> >
> > Thanks,
> >
> > Wade
>
>
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Jason Lee <ja...@steeplesoft.com>.
For what it's worth, I use JBake to build my blog (which I won't link so
I don't look like I'm fishing for traffic ;). I have a Maven-based setup
for building and deploying (and I author/edit posts in NetBeans ;).
Quick and easy to use. It's all Java-based, so writing extensions and
submitting bug fixes doesn't require that I learn new tools and
languages (not that that's a problem, but I don't have time ATM). I
should also note that I'm a committer on JBake. :)
At any rate, I've been using JBake for quite a while now. It works well,
it's fast and easy, and, of course, static sites are fast and secure. :)
On 4/25/17 8:25 AM, Steven Yi wrote:
> My initial reaction to this thread was thinking Jekyll would be nice,
> but that comes from my own usage and familiarity with it from various
> open source projects. I took a look at JBake's documentation just now
> and it looks fairly similar, such that I think I'd feel fairly
> comfortable using it as someone who comes from Jekyll.
>
> BTW, as another datapoint, Clojure.org moved to a SSG in the past year
> or so, is open source, and is built using JBake. Viewing the source
> for the site's source may be useful:
>
> site: https://clojure.org
> source: https://github.com/clojure/clojure-site
>
>
>
> On Tue, Apr 25, 2017 at 8:37 AM, Wade Chandler <wa...@apache.org> wrote:
>> The SSG tool doesn't really make your site look good. It allows you to
>> statically process assets. It is the processing and flexibility criteria
>> which matters here. Design makes a site look good.
>>
>> I suggest we start down the road with one, and if it works, then probably
>> good enough for now as long as it matches the criteria, should be fine; of
>> course ignoring the bit about the Apache, Java, and NetBeans ecosystem.
>>
>> From a feature perspective, along with Gradle, if we want SASS, then we can
>> use JBake, plus we get other Gradle plugins etc. We can also use Jekyll per
>> the discussion and the wiki page.
>>
>> I think a long comparison just delays the move. Both of those have
>> obviously been used to generate sites.
>>
>> One of my points on Jekyll was the docs didn't jump out up front to be
>> clear .html files could be used as the content (by templates) plus some
>> structure limits, but have since found that in the docs those can work for
>> what we are doing, but it does use Liquid for templates, and is out of the
>> ecosphere, but if not important then let not that guide the decision, but
>> let's be clear on it; I feel that criteria adds value, but if nobody else
>> does, then I won't be a road block.
>>
>> Given that, how about we choose between Jekyll or JBake? Nikola would work,
>> but I suggest we debate the 2 which have been discussed unless someone
>> really feels strongly that we couldn't do it with either, or that we really
>> look at a different stack with more pluggable template engines.
>>
>> This is all IMO, but, making my pitch we vote between the two (specific
>> thread for that), and get into the work of moving the site as there is more
>> work than the SSG setup, such as massaging the current content into
>> whichever we choose with some scripts plus site design which I hope to hit
>> up Christian Lenz on :-D
>>
>> Thanks
>>
>> Wade
>>
>> On Apr 25, 2017 1:30 AM, "John McDonnell" <mc...@gmail.com> wrote:
>>
>>> I don\u2019t know enough about the different SSG\u2019s to effectively comment, but
>>> looking at the JBake website, they provide a list of sites that use JBake,
>>> and the only decent one looks to be Codename One, a lot of the rest of them
>>> look to be blogs(obviously there are exceptions like http://konik.io <
>>> http://konik.io/> etc) .
>>>
>>> Probably not a great advertisement for it, since the existing NB site
>>> isn\u2019t really set up like a blog?
>>>
>>> Maybe we need to trail out a few of these SSGs, i.e. attempt to convert
>>> parts of the existing NB site to a handful and compare and contrast the
>>> difficulties faced, and lessons learned, etc..
>>>
>>> Regards
>>>
>>> John
>>>
>>>
>>>
>>>> On 24 Apr 2017, at 22:45, Wade Chandler <wa...@apache.org> wrote:
>>>>
>>>>
>>>>> On Apr 24, 2017, at 16:02, Neil C Smith <ne...@googlemail.com>
>>> wrote:
>>>>> On Mon, Apr 24, 2017 at 8:59 PM Wade Chandler <wa...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Did you read the page along with the points on content input or using
>>> .html
>>>>>> files as content/pages/posts, and the criteria?
>>>>>>
>>>>> My vote would probably be with Jekyll too, at least from a personal
>>>>> familiarity point of view, as well as the larger user base. It is not
>>>>> clear from your document what you think is missing for Jekyll to meet
>>> your
>>>>> criteria.
>>>>>
>>>> I updated the document in the Jekyll section. I thought I had added that
>>> it seems to not support .html files as content (input) outside of templates
>>> and static files, but then I was re-reading the docs, and it wasn\u2019t super
>>> clear, but it does support that out of the box. One limitation I still see
>>> is that is only supports Liquid templates, and Liquid doesn\u2019t support logic
>>> as Thymeleaf, Groovy, and Freemarker can, or Nikola\u2019s Python setup, which
>>> can come in handy for template work, and this due to running on GitHub
>>> pages build servers (can\u2019t do a lot with it without writing Jekyll plugins
>>> unless you all know different).
>>>> I\u2019m not beyond using Jekyll, but would like to know why not weight a
>>> project which supports other Apache technologies, and which is also using
>>> the many technologies the NetBeans IDE supports higher or take those things
>>> into consideration as well? We will not be building with GitHub pages, so
>>> keep that in mind, so we don\u2019t have limitations Liquid imposes, and I also
>>> assume that Jekyll is popular because GitHub is popular, and it is the only
>>> way to automate the GitHub pages builds without pushing a static site from
>>> another build stack (something else one needs to pay for to run). You
>>> mention having more experience with it, so if you and Emilian think it a
>>> great choice, I value those opinions as well, but would like us to weight
>>> this with other criteria, or at least discuss it.
>>>> Some of the criteria was based on looking at the ecosystem the IDE
>>> resides, and it seems we can contribute to JBake just as we do NetBeans
>>> while supporting that ecosystem. For me there is value in that as well;
>>> from this new community we find ourselves. I also see value in being able
>>> to tie into the Gradle, Groovy, and Java toolchains and libraries and
>>> plugins. JBake also seems rather simplistic, and I can see getting off the
>>> ground with it plus some other Groovy scripts for some file manipulation
>>> all driven from a Gradle build.
>>>> I weighted Java ecosystem technologies higher with an assumption more on
>>> this list will have more familiarity with those tool chains, and the
>>> template engines of JBake fall under that criterion. I personally tend
>>> towards those technologies as they more directly fit into my mental model
>>> per the tool chains I have been working within the past so many years;
>>> Gradle, Groovy, Java, and then of course Node JS toolsets with Angular.
>>>> If we want to contribute to Jekyll for any needs, then we get into Ruby
>>> land, which I don\u2019t mind so much, but don\u2019t personally find it to be a
>>> language of choice, but more importantly is completely outside of the
>>> communities here at Apache other than GitHub usage, but perhaps it doesn\u2019t
>>> matter.
>>>> Let\u2019s see what others say, and too what you and Emilian think about the
>>> above, and can go from there. I think either way we will have to create
>>> some scripts to do a little find tuning of the content to get it to fit
>>> into structures (front matter, snippets, templates etc), for which ever SSG
>>> we choose, and I know I can easily do that with Groovy and JSoup, but that
>>> doesn\u2019t mean we can\u2019t use various toolchains; I just thought JBake would
>>> fold nicely with those, and probably make some of it less complex
>>> initially, but that could be an incorrect assumption.
>>>> Thanks,
>>>>
>>>> Wade
>>>
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Steven Yi <st...@gmail.com>.
My initial reaction to this thread was thinking Jekyll would be nice,
but that comes from my own usage and familiarity with it from various
open source projects. I took a look at JBake's documentation just now
and it looks fairly similar, such that I think I'd feel fairly
comfortable using it as someone who comes from Jekyll.
BTW, as another datapoint, Clojure.org moved to a SSG in the past year
or so, is open source, and is built using JBake. Viewing the source
for the site's source may be useful:
site: https://clojure.org
source: https://github.com/clojure/clojure-site
On Tue, Apr 25, 2017 at 8:37 AM, Wade Chandler <wa...@apache.org> wrote:
> The SSG tool doesn't really make your site look good. It allows you to
> statically process assets. It is the processing and flexibility criteria
> which matters here. Design makes a site look good.
>
> I suggest we start down the road with one, and if it works, then probably
> good enough for now as long as it matches the criteria, should be fine; of
> course ignoring the bit about the Apache, Java, and NetBeans ecosystem.
>
> From a feature perspective, along with Gradle, if we want SASS, then we can
> use JBake, plus we get other Gradle plugins etc. We can also use Jekyll per
> the discussion and the wiki page.
>
> I think a long comparison just delays the move. Both of those have
> obviously been used to generate sites.
>
> One of my points on Jekyll was the docs didn't jump out up front to be
> clear .html files could be used as the content (by templates) plus some
> structure limits, but have since found that in the docs those can work for
> what we are doing, but it does use Liquid for templates, and is out of the
> ecosphere, but if not important then let not that guide the decision, but
> let's be clear on it; I feel that criteria adds value, but if nobody else
> does, then I won't be a road block.
>
> Given that, how about we choose between Jekyll or JBake? Nikola would work,
> but I suggest we debate the 2 which have been discussed unless someone
> really feels strongly that we couldn't do it with either, or that we really
> look at a different stack with more pluggable template engines.
>
> This is all IMO, but, making my pitch we vote between the two (specific
> thread for that), and get into the work of moving the site as there is more
> work than the SSG setup, such as massaging the current content into
> whichever we choose with some scripts plus site design which I hope to hit
> up Christian Lenz on :-D
>
> Thanks
>
> Wade
>
> On Apr 25, 2017 1:30 AM, "John McDonnell" <mc...@gmail.com> wrote:
>
>> I don’t know enough about the different SSG’s to effectively comment, but
>> looking at the JBake website, they provide a list of sites that use JBake,
>> and the only decent one looks to be Codename One, a lot of the rest of them
>> look to be blogs(obviously there are exceptions like http://konik.io <
>> http://konik.io/> etc) .
>>
>> Probably not a great advertisement for it, since the existing NB site
>> isn’t really set up like a blog?
>>
>> Maybe we need to trail out a few of these SSGs, i.e. attempt to convert
>> parts of the existing NB site to a handful and compare and contrast the
>> difficulties faced, and lessons learned, etc..
>>
>> Regards
>>
>> John
>>
>>
>>
>> > On 24 Apr 2017, at 22:45, Wade Chandler <wa...@apache.org> wrote:
>> >
>> >
>> >> On Apr 24, 2017, at 16:02, Neil C Smith <ne...@googlemail.com>
>> wrote:
>> >>
>> >> On Mon, Apr 24, 2017 at 8:59 PM Wade Chandler <wa...@apache.org>
>> >> wrote:
>> >>
>> >>> Did you read the page along with the points on content input or using
>> .html
>> >>> files as content/pages/posts, and the criteria?
>> >>>
>> >>
>> >> My vote would probably be with Jekyll too, at least from a personal
>> >> familiarity point of view, as well as the larger user base. It is not
>> >> clear from your document what you think is missing for Jekyll to meet
>> your
>> >> criteria.
>> >>
>> >
>> > I updated the document in the Jekyll section. I thought I had added that
>> it seems to not support .html files as content (input) outside of templates
>> and static files, but then I was re-reading the docs, and it wasn’t super
>> clear, but it does support that out of the box. One limitation I still see
>> is that is only supports Liquid templates, and Liquid doesn’t support logic
>> as Thymeleaf, Groovy, and Freemarker can, or Nikola’s Python setup, which
>> can come in handy for template work, and this due to running on GitHub
>> pages build servers (can’t do a lot with it without writing Jekyll plugins
>> unless you all know different).
>> >
>> > I’m not beyond using Jekyll, but would like to know why not weight a
>> project which supports other Apache technologies, and which is also using
>> the many technologies the NetBeans IDE supports higher or take those things
>> into consideration as well? We will not be building with GitHub pages, so
>> keep that in mind, so we don’t have limitations Liquid imposes, and I also
>> assume that Jekyll is popular because GitHub is popular, and it is the only
>> way to automate the GitHub pages builds without pushing a static site from
>> another build stack (something else one needs to pay for to run). You
>> mention having more experience with it, so if you and Emilian think it a
>> great choice, I value those opinions as well, but would like us to weight
>> this with other criteria, or at least discuss it.
>> >
>> > Some of the criteria was based on looking at the ecosystem the IDE
>> resides, and it seems we can contribute to JBake just as we do NetBeans
>> while supporting that ecosystem. For me there is value in that as well;
>> from this new community we find ourselves. I also see value in being able
>> to tie into the Gradle, Groovy, and Java toolchains and libraries and
>> plugins. JBake also seems rather simplistic, and I can see getting off the
>> ground with it plus some other Groovy scripts for some file manipulation
>> all driven from a Gradle build.
>> >
>> > I weighted Java ecosystem technologies higher with an assumption more on
>> this list will have more familiarity with those tool chains, and the
>> template engines of JBake fall under that criterion. I personally tend
>> towards those technologies as they more directly fit into my mental model
>> per the tool chains I have been working within the past so many years;
>> Gradle, Groovy, Java, and then of course Node JS toolsets with Angular.
>> >
>> > If we want to contribute to Jekyll for any needs, then we get into Ruby
>> land, which I don’t mind so much, but don’t personally find it to be a
>> language of choice, but more importantly is completely outside of the
>> communities here at Apache other than GitHub usage, but perhaps it doesn’t
>> matter.
>> >
>> > Let’s see what others say, and too what you and Emilian think about the
>> above, and can go from there. I think either way we will have to create
>> some scripts to do a little find tuning of the content to get it to fit
>> into structures (front matter, snippets, templates etc), for which ever SSG
>> we choose, and I know I can easily do that with Groovy and JSoup, but that
>> doesn’t mean we can’t use various toolchains; I just thought JBake would
>> fold nicely with those, and probably make some of it less complex
>> initially, but that could be an incorrect assumption.
>> >
>> > Thanks,
>> >
>> > Wade
>>
>>
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Wade Chandler <wa...@apache.org>.
The SSG tool doesn't really make your site look good. It allows you to
statically process assets. It is the processing and flexibility criteria
which matters here. Design makes a site look good.
I suggest we start down the road with one, and if it works, then probably
good enough for now as long as it matches the criteria, should be fine; of
course ignoring the bit about the Apache, Java, and NetBeans ecosystem.
From a feature perspective, along with Gradle, if we want SASS, then we can
use JBake, plus we get other Gradle plugins etc. We can also use Jekyll per
the discussion and the wiki page.
I think a long comparison just delays the move. Both of those have
obviously been used to generate sites.
One of my points on Jekyll was the docs didn't jump out up front to be
clear .html files could be used as the content (by templates) plus some
structure limits, but have since found that in the docs those can work for
what we are doing, but it does use Liquid for templates, and is out of the
ecosphere, but if not important then let not that guide the decision, but
let's be clear on it; I feel that criteria adds value, but if nobody else
does, then I won't be a road block.
Given that, how about we choose between Jekyll or JBake? Nikola would work,
but I suggest we debate the 2 which have been discussed unless someone
really feels strongly that we couldn't do it with either, or that we really
look at a different stack with more pluggable template engines.
This is all IMO, but, making my pitch we vote between the two (specific
thread for that), and get into the work of moving the site as there is more
work than the SSG setup, such as massaging the current content into
whichever we choose with some scripts plus site design which I hope to hit
up Christian Lenz on :-D
Thanks
Wade
On Apr 25, 2017 1:30 AM, "John McDonnell" <mc...@gmail.com> wrote:
> I don’t know enough about the different SSG’s to effectively comment, but
> looking at the JBake website, they provide a list of sites that use JBake,
> and the only decent one looks to be Codename One, a lot of the rest of them
> look to be blogs(obviously there are exceptions like http://konik.io <
> http://konik.io/> etc) .
>
> Probably not a great advertisement for it, since the existing NB site
> isn’t really set up like a blog?
>
> Maybe we need to trail out a few of these SSGs, i.e. attempt to convert
> parts of the existing NB site to a handful and compare and contrast the
> difficulties faced, and lessons learned, etc..
>
> Regards
>
> John
>
>
>
> > On 24 Apr 2017, at 22:45, Wade Chandler <wa...@apache.org> wrote:
> >
> >
> >> On Apr 24, 2017, at 16:02, Neil C Smith <ne...@googlemail.com>
> wrote:
> >>
> >> On Mon, Apr 24, 2017 at 8:59 PM Wade Chandler <wa...@apache.org>
> >> wrote:
> >>
> >>> Did you read the page along with the points on content input or using
> .html
> >>> files as content/pages/posts, and the criteria?
> >>>
> >>
> >> My vote would probably be with Jekyll too, at least from a personal
> >> familiarity point of view, as well as the larger user base. It is not
> >> clear from your document what you think is missing for Jekyll to meet
> your
> >> criteria.
> >>
> >
> > I updated the document in the Jekyll section. I thought I had added that
> it seems to not support .html files as content (input) outside of templates
> and static files, but then I was re-reading the docs, and it wasn’t super
> clear, but it does support that out of the box. One limitation I still see
> is that is only supports Liquid templates, and Liquid doesn’t support logic
> as Thymeleaf, Groovy, and Freemarker can, or Nikola’s Python setup, which
> can come in handy for template work, and this due to running on GitHub
> pages build servers (can’t do a lot with it without writing Jekyll plugins
> unless you all know different).
> >
> > I’m not beyond using Jekyll, but would like to know why not weight a
> project which supports other Apache technologies, and which is also using
> the many technologies the NetBeans IDE supports higher or take those things
> into consideration as well? We will not be building with GitHub pages, so
> keep that in mind, so we don’t have limitations Liquid imposes, and I also
> assume that Jekyll is popular because GitHub is popular, and it is the only
> way to automate the GitHub pages builds without pushing a static site from
> another build stack (something else one needs to pay for to run). You
> mention having more experience with it, so if you and Emilian think it a
> great choice, I value those opinions as well, but would like us to weight
> this with other criteria, or at least discuss it.
> >
> > Some of the criteria was based on looking at the ecosystem the IDE
> resides, and it seems we can contribute to JBake just as we do NetBeans
> while supporting that ecosystem. For me there is value in that as well;
> from this new community we find ourselves. I also see value in being able
> to tie into the Gradle, Groovy, and Java toolchains and libraries and
> plugins. JBake also seems rather simplistic, and I can see getting off the
> ground with it plus some other Groovy scripts for some file manipulation
> all driven from a Gradle build.
> >
> > I weighted Java ecosystem technologies higher with an assumption more on
> this list will have more familiarity with those tool chains, and the
> template engines of JBake fall under that criterion. I personally tend
> towards those technologies as they more directly fit into my mental model
> per the tool chains I have been working within the past so many years;
> Gradle, Groovy, Java, and then of course Node JS toolsets with Angular.
> >
> > If we want to contribute to Jekyll for any needs, then we get into Ruby
> land, which I don’t mind so much, but don’t personally find it to be a
> language of choice, but more importantly is completely outside of the
> communities here at Apache other than GitHub usage, but perhaps it doesn’t
> matter.
> >
> > Let’s see what others say, and too what you and Emilian think about the
> above, and can go from there. I think either way we will have to create
> some scripts to do a little find tuning of the content to get it to fit
> into structures (front matter, snippets, templates etc), for which ever SSG
> we choose, and I know I can easily do that with Groovy and JSoup, but that
> doesn’t mean we can’t use various toolchains; I just thought JBake would
> fold nicely with those, and probably make some of it less complex
> initially, but that could be an incorrect assumption.
> >
> > Thanks,
> >
> > Wade
>
>
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by John McDonnell <mc...@gmail.com>.
I don’t know enough about the different SSG’s to effectively comment, but looking at the JBake website, they provide a list of sites that use JBake, and the only decent one looks to be Codename One, a lot of the rest of them look to be blogs(obviously there are exceptions like http://konik.io <http://konik.io/> etc) .
Probably not a great advertisement for it, since the existing NB site isn’t really set up like a blog?
Maybe we need to trail out a few of these SSGs, i.e. attempt to convert parts of the existing NB site to a handful and compare and contrast the difficulties faced, and lessons learned, etc..
Regards
John
> On 24 Apr 2017, at 22:45, Wade Chandler <wa...@apache.org> wrote:
>
>
>> On Apr 24, 2017, at 16:02, Neil C Smith <ne...@googlemail.com> wrote:
>>
>> On Mon, Apr 24, 2017 at 8:59 PM Wade Chandler <wa...@apache.org>
>> wrote:
>>
>>> Did you read the page along with the points on content input or using .html
>>> files as content/pages/posts, and the criteria?
>>>
>>
>> My vote would probably be with Jekyll too, at least from a personal
>> familiarity point of view, as well as the larger user base. It is not
>> clear from your document what you think is missing for Jekyll to meet your
>> criteria.
>>
>
> I updated the document in the Jekyll section. I thought I had added that it seems to not support .html files as content (input) outside of templates and static files, but then I was re-reading the docs, and it wasn’t super clear, but it does support that out of the box. One limitation I still see is that is only supports Liquid templates, and Liquid doesn’t support logic as Thymeleaf, Groovy, and Freemarker can, or Nikola’s Python setup, which can come in handy for template work, and this due to running on GitHub pages build servers (can’t do a lot with it without writing Jekyll plugins unless you all know different).
>
> I’m not beyond using Jekyll, but would like to know why not weight a project which supports other Apache technologies, and which is also using the many technologies the NetBeans IDE supports higher or take those things into consideration as well? We will not be building with GitHub pages, so keep that in mind, so we don’t have limitations Liquid imposes, and I also assume that Jekyll is popular because GitHub is popular, and it is the only way to automate the GitHub pages builds without pushing a static site from another build stack (something else one needs to pay for to run). You mention having more experience with it, so if you and Emilian think it a great choice, I value those opinions as well, but would like us to weight this with other criteria, or at least discuss it.
>
> Some of the criteria was based on looking at the ecosystem the IDE resides, and it seems we can contribute to JBake just as we do NetBeans while supporting that ecosystem. For me there is value in that as well; from this new community we find ourselves. I also see value in being able to tie into the Gradle, Groovy, and Java toolchains and libraries and plugins. JBake also seems rather simplistic, and I can see getting off the ground with it plus some other Groovy scripts for some file manipulation all driven from a Gradle build.
>
> I weighted Java ecosystem technologies higher with an assumption more on this list will have more familiarity with those tool chains, and the template engines of JBake fall under that criterion. I personally tend towards those technologies as they more directly fit into my mental model per the tool chains I have been working within the past so many years; Gradle, Groovy, Java, and then of course Node JS toolsets with Angular.
>
> If we want to contribute to Jekyll for any needs, then we get into Ruby land, which I don’t mind so much, but don’t personally find it to be a language of choice, but more importantly is completely outside of the communities here at Apache other than GitHub usage, but perhaps it doesn’t matter.
>
> Let’s see what others say, and too what you and Emilian think about the above, and can go from there. I think either way we will have to create some scripts to do a little find tuning of the content to get it to fit into structures (front matter, snippets, templates etc), for which ever SSG we choose, and I know I can easily do that with Groovy and JSoup, but that doesn’t mean we can’t use various toolchains; I just thought JBake would fold nicely with those, and probably make some of it less complex initially, but that could be an incorrect assumption.
>
> Thanks,
>
> Wade
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Wade Chandler <wa...@apache.org>.
On Apr 25, 2017 3:02 PM, "Neil C Smith" <ne...@googlemail.com>
wrote:
Also, I think the arguments on the wiki page about Jekyll are somewhat
incorrect - it can do HTML,
The wiki page points that out about HTML.
doesn't really specify a structure
Yes, further reading suggests, its structure _site and _posts are not
necessary or are fluid.
and Liquid
is capable of a lot of logic (if not necessarily always nicely!).
Right, compared to Groovy and Thymeleaf, not really the same, as you are
locked into which ever filters, tags, and objects the environment provides,
unless you build extras or install them, and was the main difference I was
getting at. With a Gradle build, there can be subproject libs, other
plugins, plus JBake, and that is all able to access Java libs and the JDK.
That sounds pretty powerful.
One interesting difference is Jekyll allows Liquid in content, and JBake
only allows logic in the templates, but that doesn't sound limiting per
looking at what one would do for content itself as the main page layout
would come from the templates.
One
feature that was useful to us that I'm not sure if JBake supports out of
the box (docs are ambiguous) is that a traditional static site is a valid
Jekyll site - ie. files without "front matter" are copied in place
verbatim. This is useful for taking an existing static copy of a site and
upgrading it piecemeal.
Should be doable with the assets directory, as it is copied verbatim, but I
am hoping we don't do that as the branding will look rough.
And, yes, we'd want SASS surely!
I think so too, but should be doable with Gradle.
Having said all of the above - JBake looks really good, and not looked into
it much before. If it really fits the skills available in this community
better then it might be a good fit - IMO that's more important than the
technical merits. I'm sure as hell not extending anything in Ruby. :-)
That was my point too; Java extensions are easy for this group. I get your
point on JBake not being what we are building, but the tool we are building
here (NB IDE) supports the templates JBake uses and the tech stack it is
written and runs on (unless NB Liquid support is added I guess). I suppose
the NB Ruby support could be started back up at Apache though :-D I
envision using the IDE to work on the site project.
I think it is worth noting using projects which use and promote sister
Apache projects is good too. I also have this vision of a dev tools track
at ApacheCon with NB as the IDE. Not this has to be part of that, but am
suggesting using the ecosystem supports and promotes it too; just as the
clojure site project can be referenced as using such tools per Steven's
reply.
Thanks
Wade
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Neil C Smith <ne...@googlemail.com>.
Hi,
On Mon, Apr 24, 2017 at 10:45 PM Wade Chandler <wa...@apache.org>
wrote:
> Let’s see what others say, and too what you and Emilian think about the
> above, and can go from there. I think either way we will have to create
> some scripts to do a little find tuning of the content to get it to fit
> into structures (front matter, snippets, templates etc), for which ever SSG
> we choose, and I know I can easily do that with Groovy and JSoup, but that
> doesn’t mean we can’t use various toolchains; I just thought JBake would
> fold nicely with those, and probably make some of it less complex
> initially, but that could be an incorrect assumption.
>
I completely understand that perspective, and it has a lot of merit. My
concern I guess would be ensuring that whatever tech is chosen is a
sustainable project and this community has enough people with the
knowledge, or is likely to attract people with enough knowledge, to sustain
its usage. To parallel a similar point I made at a hackspace I'm involved
in - this community's role is to work on NetBeans, not JBake. ;-)
I've used Jekyll quite a bit over the last ~18 months developing stuff for
clients. My company needed something for clients that we could pitch for
those with simple sites where a traditional CMS wasn't justified, that we
could pitch as a sustainable tech, and one they weren't locked into us for
support. All shipped with client editing via a headless CMS. Not all of
that is relevant to us, but similar arguments might be valid.
Some links that might be interesting to look at are -
https://www.staticgen.com/ and https://headlesscms.org/ - not necessarily
accurate but gives some idea of the difference in usage.
Also, I think the arguments on the wiki page about Jekyll are somewhat
incorrect - it can do HTML, doesn't really specify a structure, and Liquid
is capable of a lot of logic (if not necessarily always nicely!). One
feature that was useful to us that I'm not sure if JBake supports out of
the box (docs are ambiguous) is that a traditional static site is a valid
Jekyll site - ie. files without "front matter" are copied in place
verbatim. This is useful for taking an existing static copy of a site and
upgrading it piecemeal.
And, yes, we'd want SASS surely!
Having said all of the above - JBake looks really good, and not looked into
it much before. If it really fits the skills available in this community
better then it might be a good fit - IMO that's more important than the
technical merits. I'm sure as hell not extending anything in Ruby. :-)
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Wade Chandler <wa...@apache.org>.
> On Apr 24, 2017, at 16:02, Neil C Smith <ne...@googlemail.com> wrote:
>
> On Mon, Apr 24, 2017 at 8:59 PM Wade Chandler <wa...@apache.org>
> wrote:
>
>> Did you read the page along with the points on content input or using .html
>> files as content/pages/posts, and the criteria?
>>
>
> My vote would probably be with Jekyll too, at least from a personal
> familiarity point of view, as well as the larger user base. It is not
> clear from your document what you think is missing for Jekyll to meet your
> criteria.
>
I updated the document in the Jekyll section. I thought I had added that it seems to not support .html files as content (input) outside of templates and static files, but then I was re-reading the docs, and it wasn’t super clear, but it does support that out of the box. One limitation I still see is that is only supports Liquid templates, and Liquid doesn’t support logic as Thymeleaf, Groovy, and Freemarker can, or Nikola’s Python setup, which can come in handy for template work, and this due to running on GitHub pages build servers (can’t do a lot with it without writing Jekyll plugins unless you all know different).
I’m not beyond using Jekyll, but would like to know why not weight a project which supports other Apache technologies, and which is also using the many technologies the NetBeans IDE supports higher or take those things into consideration as well? We will not be building with GitHub pages, so keep that in mind, so we don’t have limitations Liquid imposes, and I also assume that Jekyll is popular because GitHub is popular, and it is the only way to automate the GitHub pages builds without pushing a static site from another build stack (something else one needs to pay for to run). You mention having more experience with it, so if you and Emilian think it a great choice, I value those opinions as well, but would like us to weight this with other criteria, or at least discuss it.
Some of the criteria was based on looking at the ecosystem the IDE resides, and it seems we can contribute to JBake just as we do NetBeans while supporting that ecosystem. For me there is value in that as well; from this new community we find ourselves. I also see value in being able to tie into the Gradle, Groovy, and Java toolchains and libraries and plugins. JBake also seems rather simplistic, and I can see getting off the ground with it plus some other Groovy scripts for some file manipulation all driven from a Gradle build.
I weighted Java ecosystem technologies higher with an assumption more on this list will have more familiarity with those tool chains, and the template engines of JBake fall under that criterion. I personally tend towards those technologies as they more directly fit into my mental model per the tool chains I have been working within the past so many years; Gradle, Groovy, Java, and then of course Node JS toolsets with Angular.
If we want to contribute to Jekyll for any needs, then we get into Ruby land, which I don’t mind so much, but don’t personally find it to be a language of choice, but more importantly is completely outside of the communities here at Apache other than GitHub usage, but perhaps it doesn’t matter.
Let’s see what others say, and too what you and Emilian think about the above, and can go from there. I think either way we will have to create some scripts to do a little find tuning of the content to get it to fit into structures (front matter, snippets, templates etc), for which ever SSG we choose, and I know I can easily do that with Groovy and JSoup, but that doesn’t mean we can’t use various toolchains; I just thought JBake would fold nicely with those, and probably make some of it less complex initially, but that could be an incorrect assumption.
Thanks,
Wade
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Neil C Smith <ne...@googlemail.com>.
On Mon, Apr 24, 2017 at 8:59 PM Wade Chandler <wa...@apache.org>
wrote:
> Did you read the page along with the points on content input or using .html
> files as content/pages/posts, and the criteria?
>
My vote would probably be with Jekyll too, at least from a personal
familiarity point of view, as well as the larger user base. It is not
clear from your document what you think is missing for Jekyll to meet your
criteria.
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Wade Chandler <wa...@apache.org>.
Did you read the page along with the points on content input or using .html
files as content/pages/posts, and the criteria? I would like to take
something which can get off the ground with what we have, versus worry
about a tool soley because many use it; codenameone uses JBake as an
example, and Groovy rolls their own. Many use the others as well, and write
to github pages, but we are not using github pages, so not exactly the
reason. Also see the future section on evolution, and the options there.
JBake also supports Freemarker, Groovy, and Thymeleaf.
Thanks
Wade
On Apr 24, 2017 3:03 PM, "Emilian Bold" <em...@gmail.com> wrote:
> I would vote for Jekyll because the repo will be mirrored on GitHub
> and GitHub is also using Jekyll for GitHub Pages. So, lots of people
> use it.
>
> --emi
>
>
> On Mon, Apr 24, 2017 at 7:36 PM, Wade Chandler <wa...@apache.org>
> wrote:
> > All,
> >
> > I have been reviewing different static site generators for a good bit. I
> have also been reviewing the current NB site structure and content/files. I
> have also been working on this document in the Wiki:
> > https://cwiki.apache.org/confluence/display/NETBEANS/
> New+NetBeans+Web+Site+Planning <https://cwiki.apache.org/
> confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning>
> >
> > I give reasonings for static site generator choices as well as some
> context on things reviewed/studied. Notice I’m suggesting JBake as a
> starting point along with a Gradle build which can fill in some
> preprocessing gaps. I’m also starting to work on a plan for using it to get
> the current site moved over; have to start some where.
> >
> > I bring this up to have a conversation about it if needed, and then
> finally after that, to vote to make sure we have made some decisions. I
> think if nobody has an issue with using JBake as a starting point as
> mentioned in the document, then we could have a vote on it
> soon/immediately, and then later the plan or options.
> >
> > To come up with a full on plan takes writing some scripts as mentioned
> in the document, and trying out some things with Groovy and JSoup at the
> moment, so not super trivial, but not really hard either, but does take
> time. Then, once some tools for conversion which will be needed no matter
> the SSG choice are in place, we can generate a sub-set of what is on
> netbeans.org <http://netbeans.org/> merged with what Christian Lenz has
> already started for the new site.
> >
> > This will be working with the Oracle folks (mainly Gj) to get the files
> over to Apache as part of the donation, but moving them over into this
> structure to be statically generated by automation at some point, but
> initially manually and pushed by an individual albeit running the tools
> (still simpler and less time consuming). I’m hoping the scripts I mentioned
> make this easier, and is what I’m focusing on now to get together a subset
> for demonstration.
> >
> > I’m also working on setting up a Salon for my wife’s business at the
> moment, so a lot of different pots on the fire at the moment, so please be
> patient, but it will be soon.
> >
> > Thanks much, and look forward to input and discussion,
> >
> > Wade
> >
> >
> >
>
Re: NetBeans Apache Site Static Site Generator and Plan; Discussion
Posted by Emilian Bold <em...@gmail.com>.
I would vote for Jekyll because the repo will be mirrored on GitHub
and GitHub is also using Jekyll for GitHub Pages. So, lots of people
use it.
--emi
On Mon, Apr 24, 2017 at 7:36 PM, Wade Chandler <wa...@apache.org> wrote:
> All,
>
> I have been reviewing different static site generators for a good bit. I have also been reviewing the current NB site structure and content/files. I have also been working on this document in the Wiki:
> https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning <https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning>
>
> I give reasonings for static site generator choices as well as some context on things reviewed/studied. Notice I’m suggesting JBake as a starting point along with a Gradle build which can fill in some preprocessing gaps. I’m also starting to work on a plan for using it to get the current site moved over; have to start some where.
>
> I bring this up to have a conversation about it if needed, and then finally after that, to vote to make sure we have made some decisions. I think if nobody has an issue with using JBake as a starting point as mentioned in the document, then we could have a vote on it soon/immediately, and then later the plan or options.
>
> To come up with a full on plan takes writing some scripts as mentioned in the document, and trying out some things with Groovy and JSoup at the moment, so not super trivial, but not really hard either, but does take time. Then, once some tools for conversion which will be needed no matter the SSG choice are in place, we can generate a sub-set of what is on netbeans.org <http://netbeans.org/> merged with what Christian Lenz has already started for the new site.
>
> This will be working with the Oracle folks (mainly Gj) to get the files over to Apache as part of the donation, but moving them over into this structure to be statically generated by automation at some point, but initially manually and pushed by an individual albeit running the tools (still simpler and less time consuming). I’m hoping the scripts I mentioned make this easier, and is what I’m focusing on now to get together a subset for demonstration.
>
> I’m also working on setting up a Salon for my wife’s business at the moment, so a lot of different pots on the fire at the moment, so please be patient, but it will be soon.
>
> Thanks much, and look forward to input and discussion,
>
> Wade
>
>
>