On Tue, 16 Jul 2019 at 00:36, Michał Dymecki <mic...@dymecki.com> wrote: > Neil and Antonio commited that not working code into the repository, now > they want to close the PR that fixes their code, and when Chris wants to > help with fixing it too, he's being disrespected. Did I miss something?
Maybe stop throwing git blame around. It's definitely not about defending a couple of hours work I did on tidying up and modularising sass files (which incidentally did not fix the *existing* problem you're pointing out). Or maybe realise that Antonio has spent many, many hours on this and understands better than you or Chris the full requirements we have! If you want to put time and effort into fixing this, please talk to people and work on a *complete* proposal that handles the full requirements around building, content and deployment rather than tinkering at the edges and making a complex system more complex. So, yes, the PR *as is* isn't the right approach. That doesn't mean that a complete JS-based SSG isn't, should you wish to start working on that, but it has to do *everything* the current framework does. > The mentioned projects Apache Tamaya (Incubating) and Apache Incubator > are not the best examples because they don't even use Sass and there are > no frontend assets to compile. And Chris is right - with Gradle (or some > other Java tool) we won't get too far with frontend assets. I have (and had) quite a few reservations about JBake, this being one of them. We can handle a frontend assets pipeline in Gradle if we really have to. Or we can look to simplify or move stack. Of Chris' 4 SSG options, as far as I can tell 3 fail at the first hurdle (asciidoc), which leaves Hugo - written in Go and potentially harder for us to extend if we need to. At least with JBake we can easily extend and have built a relationship with the main developer. So, either propose an SSG framework and full migration plan, or help us work out an easier way for people to work with the existing system we have. Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
