6:39 a.m.
Hi,
I saw that there was some discussion about whitespace in a javascript file on a PR
yesterday. Now it seems to me that among the things to discuss whitespace is just noise,
especially because formatting can be done automatically. Talking with qmx and lholmquist
about this it seems that JS land doesn't have good tools for this.
To have something in the mean time we could use something like the eclipse formatter,
because it can format JS has a ton of options and there are already a lot of external
tools that use it:
https://github.com/krasa/EclipseCodeFormatter
https://code.google.com/p/maven-java-formatter-plugin
http://liviutudor.com/2012/03/02/batch-source-formatting-in-eclipse-indigo/
So how about having something like this that will format our JS for us? We could integrate
something like this in our build, or that or create our own CLI tool as long as we have
something that will work so that we don't have to discuss formatting anymore, what do
you think?
Cheers,
Erik Jan
6:48 a.m.
On Tue, Oct 29, 2013 at 11:39 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
I saw that there was some discussion about whitespace in a javascript file
on a PR yesterday. Now it seems to me that among the things to discuss
whitespace is just noise,
+1 - especially the amount of comments
especially because formatting can be done automatically.
Isn't it ? I did run 'grunt' on that PR and that tool was already crying
about formating issues
Talking with qmx and lholmquist about this it seems that JS land
doesn't
have good tools for this.
hrm - the grunt worked for me; but I don't know if it is _that_ good
To have something in the mean time we could use something like the eclipse
formatter, because it can format JS has a ton of options and there are
already a lot of external tools that use it:
https://github.com/krasa/EclipseCodeFormatter
I doubt that a JS weenie will use Eclipse/IDEA
similar w/ maven, adding maven to a JS build is a bit....
not sure about eclipse dependency;
So how about having something like this that will format our JS for us? We
could integrate something like this in our build, or that or create our own
CLI tool as long as we have something that will work so that we don't have
to discuss formatting anymore, what do you think?
Again, not sure if something like grunt does already help us.
-M
Cheers,
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
7:08 a.m.
Talking with qmx and lholmquist about this it seems that JS land doesn't have good
tools for this.
hrm - the grunt worked for me; but I don't know if it is _that_ good
The formatter that is available with grunt seems to have very little settings [1], but if
that is fine for most of us by all means we should use it!
[1] https://npmjs.org/package/grunt-jsbeautifier
To have something in the mean time we could use something like the eclipse formatter,
because it can format JS has a ton of options and there are already a lot of external
tools that use it:
https://github.com/krasa/EclipseCodeFormatter
I doubt that a JS weenie will use Eclipse/IDEA
It's meant as an example you don't need the full eclipse IDE to use the formatting
tool. It can be used standalone and it has a ton of options about where to put whitespace.
We could also build our own javascript code formatter, but why not have something that
works today. And I think even a javascript coder can execute a command line utility.
Just trying to be pragmatic
7:14 a.m.
On Tue, Oct 29, 2013 at 12:08 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
> Talking with qmx and lholmquist about this it seems that JS land doesn't
> have good tools for this.
>
hrm - the grunt worked for me; but I don't know if it is _that_ good
The formatter that is available with grunt seems to have very little
settings [1], but if that is fine for most of us by all means we should use
it!
[1] https://npmjs.org/package/grunt-jsbeautifier
perhaps here we could help/improve ?
>
> To have something in the mean time we could use something like the
> eclipse formatter, because it can format JS has a ton of options and there
> are already a lot of external tools that use it:
>
> https://github.com/krasa/EclipseCodeFormatter
>
I doubt that a JS weenie will use Eclipse/IDEA
It's meant as an example you don't need the full eclipse IDE to use the
formatting tool. It can be used standalone and it has a ton of options
about where to put whitespace. We could also build our own javascript code
formatter, but why not have something that works today. And I think even a
javascript coder can execute a command line utility.
Just trying to be pragmatic
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
7:53 a.m.
On Oct 29, 2013, at 7:14 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Oct 29, 2013 at 12:08 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
>
> Talking with qmx and lholmquist about this it seems that JS land doesn't have
good tools for this.
>
>
> hrm - the grunt worked for me; but I don't know if it is _that_ good
grunt will run jshint, which doesn't do the formatting for you, but tells you what
you need to fix. but until up to a point.
I think there is a difference between formatting and whitespace
The formatter that is available with grunt seems to have very little settings [1], but if
that is fine for most of us by all means we should use it!
[1] https://npmjs.org/package/grunt-jsbeautifier
perhaps here we could help/improve ?
+1 to this option
>
>
> To have something in the mean time we could use something like the eclipse formatter,
because it can format JS has a ton of options and there are already a lot of external
tools that use it:
>
> https://github.com/krasa/EclipseCodeFormatter
>
> I doubt that a JS weenie will use Eclipse/IDEA
Correct, none of us "Rock Stars" would use an IDE :)
It's meant as an example you don't need the full eclipse IDE
to use the formatting tool. It can be used standalone and it has a ton of options about
where to put whitespace. We could also build our own javascript code formatter, but why
not have something that works today. And I think even a javascript coder can execute a
command line utility.
if there is a java dependency then it is a no go for JS land
Just trying to be pragmatic
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:02 a.m.
A couple of options the jQuery project has been looking at but still hasn't decided on
are node-jscs https://github.com/mdevils/node-jscs and esformatter
https://github.com/millermedeiros/esformatter. Neither of them are perfect and neither are
grunt plugins (probably not too hard to make them work with grunt) but they get close.
On Oct 29, 2013, at 6:53 AM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
On Oct 29, 2013, at 7:14 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>
>
> On Tue, Oct 29, 2013 at 12:08 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
>>
>> Talking with qmx and lholmquist about this it seems that JS land doesn't have
good tools for this.
>>
>>
>> hrm - the grunt worked for me; but I don't know if it is _that_ good
grunt will run jshint, which doesn't do the formatting for you, but tells you what
you need to fix. but until up to a point.
I think there is a difference between formatting and whitespace
>
> The formatter that is available with grunt seems to have very little settings [1],
but if that is fine for most of us by all means we should use it!
>
> [1] https://npmjs.org/package/grunt-jsbeautifier
>
> perhaps here we could help/improve ?
+1 to this option
>
>
>>
>>
>> To have something in the mean time we could use something like the eclipse
formatter, because it can format JS has a ton of options and there are already a lot of
external tools that use it:
>>
>> https://github.com/krasa/EclipseCodeFormatter
>>
>> I doubt that a JS weenie will use Eclipse/IDEA
>
Correct, none of us "Rock Stars" would use an IDE :)
> It's meant as an example you don't need the full eclipse IDE to use the
formatting tool. It can be used standalone and it has a ton of options about where to put
whitespace. We could also build our own javascript code formatter, but why not have
something that works today. And I think even a javascript coder can execute a command line
utility.
if there is a java dependency then it is a no go for JS land
>
> Just trying to be pragmatic
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:20 a.m.
On Oct 29, 2013, at 6:39 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
I saw that there was some discussion about whitespace in a javascript file on a PR
yesterday. Now it seems to me that among the things to discuss whitespace is just noise,
especially because formatting can be done automatically.
I think part of this was the fact that somethings didn't need to be revisioned.( some
IDE's like to do stuff ).
I think it is important as part of the commit process that we need to be making sure
that we are only committing changes that we made.
Talking with qmx and lholmquist about this it seems that JS land
doesn't have good tools for this.
To have something in the mean time we could use something like the eclipse formatter,
because it can format JS has a ton of options and there are already a lot of external
tools that use it:
https://github.com/krasa/EclipseCodeFormatter
https://code.google.com/p/maven-java-formatter-plugin
http://liviutudor.com/2012/03/02/batch-source-formatting-in-eclipse-indigo/
So how about having something like this that will format our JS for us? We could
integrate something like this in our build, or that or create our own CLI tool as long as
we have something that will work so that we don't have to discuss formatting anymore,
what do you think?
Cheers,
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:22 a.m.
On Oct 29, 2013, at 8:20 AM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
On Oct 29, 2013, at 6:39 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
> Hi,
>
> I saw that there was some discussion about whitespace in a javascript file on a PR
yesterday. Now it seems to me that among the things to discuss whitespace is just noise,
especially because formatting can be done automatically.
I think part of this was the fact that somethings didn't need to be revisioned.( some
IDE's like to do stuff ).
I think it is important as part of the commit process that we need to be making sure
that we are only committing changes that we made.
Exactly!! It makes it impossible to review a PR when the committer or the IDE makes
whitespace or other insignificant changes to unrelated lines because the diff is
impossible to read.
> Talking with qmx and lholmquist about this it seems that JS land doesn't have
good tools for this.
>
> To have something in the mean time we could use something like the eclipse formatter,
because it can format JS has a ton of options and there are already a lot of external
tools that use it:
>
> https://github.com/krasa/EclipseCodeFormatter
> https://code.google.com/p/maven-java-formatter-plugin
> http://liviutudor.com/2012/03/02/batch-source-formatting-in-eclipse-indigo/
>
> So how about having something like this that will format our JS for us? We could
integrate something like this in our build, or that or create our own CLI tool as long as
we have something that will work so that we don't have to discuss formatting anymore,
what do you think?
>
> Cheers,
> Erik Jan
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:23 a.m.
On Tue, Oct 29, 2013 at 2:20 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
On Oct 29, 2013, at 6:39 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
I saw that there was some discussion about whitespace in a javascript file
on a PR yesterday. Now it seems to me that among the things to discuss
whitespace is just noise, especially because formatting can be done
automatically.
I think part of this was the fact that somethings didn't need to be
revisioned.( some IDE's like to do stuff ).
I think it is important as part of the commit process that we need to be
making sure that we are only committing changes that we made.
+1 and I take entirely responsibility for this one. Auto format from IDEs
are evil. And running grunt without any warning should be a condition
before pushing.
Talking with qmx and lholmquist about this it seems that JS land doesn't
have good tools for this.
To have something in the mean time we could use something like the eclipse
formatter, because it can format JS has a ton of options and there are
already a lot of external tools that use it:
https://github.com/krasa/EclipseCodeFormatter
https://code.google.com/p/maven-java-formatter-plugin
http://liviutudor.com/2012/03/02/batch-source-formatting-in-eclipse-indigo/
So how about having something like this that will format our JS for us? We
could integrate something like this in our build, or that or create our own
CLI tool as long as we have something that will work so that we don't have
to discuss formatting anymore, what do you think?
Cheers,
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:29 a.m.
On Oct 29, 2013, at 8:23 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
On Tue, Oct 29, 2013 at 2:20 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
On Oct 29, 2013, at 6:39 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
> Hi,
>
> I saw that there was some discussion about whitespace in a javascript file on a PR
yesterday. Now it seems to me that among the things to discuss whitespace is just noise,
especially because formatting can be done automatically.
I think part of this was the fact that somethings didn't need to be revisioned.( some
IDE's like to do stuff ).
I think it is important as part of the commit process that we need to be making sure
that we are only committing changes that we made.
+1 and I take entirely responsibility for this one. Auto format from IDEs are evil. And
running grunt without any warning should be a condition before pushing.
Well, isn't that an implied condition?? You should always make sure the build passes
before you send a PR or push any code.
> Talking with qmx and lholmquist about this it seems that JS land doesn't have
good tools for this.
>
> To have something in the mean time we could use something like the eclipse formatter,
because it can format JS has a ton of options and there are already a lot of external
tools that use it:
>
> https://github.com/krasa/EclipseCodeFormatter
> https://code.google.com/p/maven-java-formatter-plugin
> http://liviutudor.com/2012/03/02/batch-source-formatting-in-eclipse-indigo/
>
> So how about having something like this that will format our JS for us? We could
integrate something like this in our build, or that or create our own CLI tool as long as
we have something that will work so that we don't have to discuss formatting anymore,
what do you think?
>
> Cheers,
> Erik Jan
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:31 a.m.
On Tue, Oct 29, 2013 at 2:29 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Oct 29, 2013, at 8:23 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
On Tue, Oct 29, 2013 at 2:20 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
>
> On Oct 29, 2013, at 6:39 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
>
> Hi,
>
> I saw that there was some discussion about whitespace in a javascript
> file on a PR yesterday. Now it seems to me that among the things to
> discuss whitespace is just noise, especially because formatting can be done
> automatically.
>
>
> I think part of this was the fact that somethings didn't need to be
> revisioned.( some IDE's like to do stuff ).
>
> I think it is important as part of the commit process that we need to
> be making sure that we are only committing changes that we made.
>
+1 and I take entirely responsibility for this one. Auto format from IDEs
are evil. And running grunt without any warning should be a condition
before pushing.
Well, isn't that an implied condition?? You should always make sure the
build passes before you send a PR or push any code.
Totally, again, mistake from me. Speaking of that when having grunt server
running , should it be possible to have jslint running on the fly when a
file is saved ?
>
>
> Talking with qmx and lholmquist about this it seems that JS land doesn't
> have good tools for this.
>
> To have something in the mean time we could use something like the
> eclipse formatter, because it can format JS has a ton of options and there
> are already a lot of external tools that use it:
>
> https://github.com/krasa/EclipseCodeFormatter
> https://code.google.com/p/maven-java-formatter-plugin
>
> http://liviutudor.com/2012/03/02/batch-source-formatting-in-eclipse-indigo/
>
> So how about having something like this that will format our JS for us?
> We could integrate something like this in our build, or that or create our
> own CLI tool as long as we have something that will work so that we don't
> have to discuss formatting anymore, what do you think?
>
> Cheers,
> Erik Jan
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:53 a.m.
On Tue, Oct 29, 2013 at 2:29 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Oct 29, 2013, at 8:23 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
On Tue, Oct 29, 2013 at 2:20 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
>
> On Oct 29, 2013, at 6:39 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
>
> Hi,
>
> I saw that there was some discussion about whitespace in a javascript
> file on a PR yesterday. Now it seems to me that among the things to
> discuss whitespace is just noise, especially because formatting can be done
> automatically.
>
>
> I think part of this was the fact that somethings didn't need to be
> revisioned.( some IDE's like to do stuff ).
>
> I think it is important as part of the commit process that we need to
> be making sure that we are only committing changes that we made.
>
+1 and I take entirely responsibility for this one. Auto format from IDEs
are evil. And running grunt without any warning should be a condition
before pushing.
Well, isn't that an implied condition?? You should always make sure the
build passes before you send a PR or push any code.
chillax - mistakes happened and will happen. it was not done on purpose
-M
>
>
> Talking with qmx and lholmquist about this it seems that JS land doesn't
> have good tools for this.
>
> To have something in the mean time we could use something like the
> eclipse formatter, because it can format JS has a ton of options and there
> are already a lot of external tools that use it:
>
> https://github.com/krasa/EclipseCodeFormatter
> https://code.google.com/p/maven-java-formatter-plugin
>
> http://liviutudor.com/2012/03/02/batch-source-formatting-in-eclipse-indigo/
>
> So how about having something like this that will format our JS for us?
> We could integrate something like this in our build, or that or create our
> own CLI tool as long as we have something that will work so that we don't
> have to discuss formatting anymore, what do you think?
>
> Cheers,
> Erik Jan
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11:51 a.m.
> I think it is important as part of the commit process that we
need to be making sure that we are only committing changes that we made.
Exactly!! It makes it impossible to review a PR when the committer or the IDE makes
whitespace or other insignificant changes to unrelated lines because the diff is
impossible to read.
Totally agree that having lots of changes in a PR that are just whitespace are not good,
but if we all use the same style settings this will not happen because there will be
nothing to change as it's already checked-in in the 'right' style.
It would be nice if we can find a tool that will suffice and have a 'aerogear' JS
format that we all use. We could even opt that the build will fail if the checked in
source doesn't conform the style that we agreed!
So far the tools mentioned are:
https://github.com/mdevils/node-jscs -- doesn't seem to format code but does extra
jshint checks
https://github.com/millermedeiros/esformatter -- nice but not done yet, but already
supports a ton of settings… << has my vote
https://npmjs.org/package/grunt-prettify -- limited control over whitespace
eclipse formatter -- very java based, lot's of control where whitespace is placed, but
very java based :)
Can we vote on what tool we want, and set it up with our preferences?
Cheers,
Erik Jan
7:54 a.m.
On Tue, 29 Oct 2013 11:39:14 +0100
Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
I saw that there was some discussion about whitespace in a javascript file
on a PR yesterday. Now it seems to me that among the things to discuss
whitespace is just noise, especially because formatting can be done
automatically. Talking with qmx and lholmquist about this it seems that JS
land doesn't have good tools for this.
To have something in the mean time we could use something like the eclipse
formatter, because it can format JS has a ton of options and there are
already a lot of external tools that use it:
https://github.com/krasa/EclipseCodeFormatter
https://code.google.com/p/maven-java-formatter-plugin
http://liviutudor.com/2012/03/02/batch-source-formatting-in-eclipse-indigo/
So how about having something like this that will format our JS for us? We
could integrate something like this in our build, or that or create our own
CLI tool as long as we have something that will work so that we don't have to
discuss formatting anymore, what do you think?
Not only JavaScript. For instance, it would be great to have Maven Checkstyle
Plugin for Java/Android.
Cheers,
Erik Jan
8:15 a.m.
On Wed, Oct 30, 2013 at 12:54 PM, Karel Piwko <kpiwko(a)redhat.com> wrote:
On Tue, 29 Oct 2013 11:39:14 +0100
Erik Jan de Wit <edewit(a)redhat.com> wrote:
> Hi,
>
> I saw that there was some discussion about whitespace in a javascript
file
> on a PR yesterday. Now it seems to me that among the things to discuss
> whitespace is just noise, especially because formatting can be done
> automatically. Talking with qmx and lholmquist about this it seems that
JS
> land doesn't have good tools for this.
>
> To have something in the mean time we could use something like the
eclipse
> formatter, because it can format JS has a ton of options and there are
> already a lot of external tools that use it:
>
> https://github.com/krasa/EclipseCodeFormatter
> https://code.google.com/p/maven-java-formatter-plugin
>
http://liviutudor.com/2012/03/02/batch-source-formatting-in-eclipse-indigo/
>
> So how about having something like this that will format our JS for us?
We
> could integrate something like this in our build, or that or create our
own
> CLI tool as long as we have something that will work so that we don't
have to
> discuss formatting anymore, what do you think?
Not only JavaScript. For instance, it would be great to have Maven
Checkstyle
Plugin for Java/Android.
+1
>
> Cheers,
> Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9:54 a.m.
On Wed, Oct 30, 2013 at 12:54:36PM +0100, Karel Piwko wrote:
Not only JavaScript. For instance, it would be great to have Maven
Checkstyle
Plugin for Java/Android.
I actually did look on integrating checkstyle on our java projects. And
then I found out it's a regex-based check, so lots of false positives
and some deep annoyances. Just not worth it.
--
qmx
10:24 a.m.
On 30 Oct,2013, at 14:54 , Douglas Campos <qmx(a)qmx.me> wrote:
On Wed, Oct 30, 2013 at 12:54:36PM +0100, Karel Piwko wrote:
> Not only JavaScript. For instance, it would be great to have Maven Checkstyle
> Plugin for Java/Android.
I actually did look on integrating checkstyle on our java projects. And
then I found out it's a regex-based check, so lots of false positives
and some deep annoyances. Just not worth it.
I think you got check style confused with an other tool because it works on an abstract
syntax tree see http://checkstyle.sourceforge.net/config.html
+1 for enabling check style on java / android projects
11:08 a.m.
On Wed, Oct 30, 2013 at 03:24:58PM +0100, Erik Jan de Wit wrote:
I think you got check style confused with an other tool because it
works on an abstract syntax tree see
http://checkstyle.sourceforge.net/config.html
Thanks for pointing this out - I've got this wrong impression by looking
at the netty project checkstyle settings (they are using regex checker)
I already have a JIRA assigned to me to look into this, will get back to
it soon then (we need to ship security first)
--
qmx
11:09 a.m.
There are PRs for a few months
for AEROGEAR-336: https://github.com/aerogear/aerogear-parent/pull/4 and
https://github.com/aerogear/aerogear-misc/pull/1 .
All that's needed is:
1/ Release new version of aerogear-misc
2/ Release new version of aerogear-parent
3/ Bump parent in all Maven based project
So far checkstyle only checks for unused imports, but the file itself can
easily be updated to accommodate your needs.
Karel
On Wed, 30 Oct 2013 15:24:58 +0100
Erik Jan de Wit <edewit(a)redhat.com> wrote:
On 30 Oct,2013, at 14:54 , Douglas Campos <qmx(a)qmx.me> wrote:
> On Wed, Oct 30, 2013 at 12:54:36PM +0100, Karel Piwko wrote:
>> Not only JavaScript. For instance, it would be great to have Maven
>> Checkstyle Plugin for Java/Android.
>
> I actually did look on integrating checkstyle on our java projects. And
> then I found out it's a regex-based check, so lots of false positives
> and some deep annoyances. Just not worth it.
>
I think you got check style confused with an other tool because it works on
an abstract syntax tree see http://checkstyle.sourceforge.net/config.html
+1 for enabling check style on java / android projects
11:13 a.m.
On Wed, Oct 30, 2013 at 04:09:54PM +0100, Karel Piwko wrote:
There are PRs for a few months
That's my fault, sorry - this just got into the low priority lane and
got forgotten :(
for AEROGEAR-336: https://github.com/aerogear/aerogear-parent/pull/4
and
https://github.com/aerogear/aerogear-misc/pull/1 .
All that's needed is:
1/ Release new version of aerogear-misc
2/ Release new version of aerogear-parent
3/ Bump parent in all Maven based project
So far checkstyle only checks for unused imports, but the file itself can
easily be updated to accommodate your needs.
I'll take care of putting a good set of rules before turning this on,
specially since it needs some care from our side on not breaking the
builds because of style ;)
Thanks for caring!
--
qmx
3828
days inactive
3829
days old
19 comments
7 participants
participants (7)
-
Douglas Campos -
Erik Jan de Wit -
Karel Piwko -
Kris Borchers -
Lucas Holmquist -
Matthias Wessendorf -
Sebastien Blanc