Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 98e6d47

Browse files
committed
Initial Commit
0 parents  commit 98e6d47

File tree

123 files changed

+74512
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

123 files changed

+74512
-0
lines changed

.gitignore

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
# Ignore metadata generated by Jekyll
2+
_site/
3+
.sass-cache/
4+
.jekyll-cache/
5+
.jekyll-metadata
6+
7+
# Ignore folders generated by Bundler
8+
.bundle/
9+
vendor/
10+
11+
# Ignore IDE files
12+
.idea/

404.html

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
---
2+
permalink: /404.html
3+
layout: default
4+
---
5+
6+
<style type="text/css" media="screen">
7+
.container {
8+
margin: 10px auto;
9+
max-width: 600px;
10+
text-align: center;
11+
}
12+
h1 {
13+
margin: 30px 0;
14+
font-size: 4em;
15+
line-height: 1;
16+
letter-spacing: -1px;
17+
}
18+
</style>
19+
20+
<div class="container">
21+
<h1>404</h1>
22+
23+
<p><strong>Page not found :(</strong></p>
24+
<p>The requested page could not be found.</p>
25+
</div>

Gemfile

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
source "https://rubygems.org"
2+
# Hello! This is where you manage which Jekyll version is used to run.
3+
# When you want to use a different version, change it below, save the
4+
# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
5+
#
6+
# bundle exec jekyll serve
7+
#
8+
# This will help ensure the proper Jekyll version is running.
9+
# Happy Jekylling!
10+
gem "jekyll", "~> 4.0.0"
11+
# This is the default theme for new Jekyll sites. You may change this to anything you like.
12+
gem "minima", "~> 2.5"
13+
# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
14+
# uncomment the line below. To upgrade, run `bundle update github-pages`.
15+
# gem "github-pages", group: :jekyll_plugins
16+
# If you have any plugins, put them here!
17+
group :jekyll_plugins do
18+
gem "jekyll-feed", "~> 0.12"
19+
end
20+
21+
# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
22+
# and associated library.
23+
install_if -> { RUBY_PLATFORM =~ %r!mingw|mswin|java! } do
24+
gem "tzinfo", "~> 1.2"
25+
gem "tzinfo-data"
26+
end
27+
28+
# Performance-booster for watching directories on Windows
29+
gem "wdm", "~> 0.1.1", :install_if => Gem.win_platform?
30+

Gemfile.lock

Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
1+
GEM
2+
remote: https://rubygems.org/
3+
specs:
4+
addressable (2.7.0)
5+
public_suffix (>= 2.0.2, < 5.0)
6+
colorator (1.1.0)
7+
concurrent-ruby (1.1.5)
8+
em-websocket (0.5.1)
9+
eventmachine (>= 0.12.9)
10+
http_parser.rb (~> 0.6.0)
11+
eventmachine (1.2.7)
12+
ffi (1.11.1)
13+
forwardable-extended (2.6.0)
14+
http_parser.rb (0.6.0)
15+
i18n (1.6.0)
16+
concurrent-ruby (~> 1.0)
17+
jekyll (4.0.0)
18+
addressable (~> 2.4)
19+
colorator (~> 1.0)
20+
em-websocket (~> 0.5)
21+
i18n (>= 0.9.5, < 2)
22+
jekyll-sass-converter (~> 2.0)
23+
jekyll-watch (~> 2.0)
24+
kramdown (~> 2.1)
25+
kramdown-parser-gfm (~> 1.0)
26+
liquid (~> 4.0)
27+
mercenary (~> 0.3.3)
28+
pathutil (~> 0.9)
29+
rouge (~> 3.0)
30+
safe_yaml (~> 1.0)
31+
terminal-table (~> 1.8)
32+
jekyll-feed (0.12.1)
33+
jekyll (>= 3.7, < 5.0)
34+
jekyll-sass-converter (2.0.0)
35+
sassc (> 2.0.1, < 3.0)
36+
jekyll-seo-tag (2.6.1)
37+
jekyll (>= 3.3, < 5.0)
38+
jekyll-watch (2.2.1)
39+
listen (~> 3.0)
40+
kramdown (2.1.0)
41+
kramdown-parser-gfm (1.1.0)
42+
kramdown (~> 2.0)
43+
liquid (4.0.3)
44+
listen (3.1.5)
45+
rb-fsevent (~> 0.9, >= 0.9.4)
46+
rb-inotify (~> 0.9, >= 0.9.7)
47+
ruby_dep (~> 1.2)
48+
mercenary (0.3.6)
49+
minima (2.5.1)
50+
jekyll (>= 3.5, < 5.0)
51+
jekyll-feed (~> 0.9)
52+
jekyll-seo-tag (~> 2.1)
53+
pathutil (0.16.2)
54+
forwardable-extended (~> 2.6)
55+
public_suffix (4.0.1)
56+
rb-fsevent (0.10.3)
57+
rb-inotify (0.10.0)
58+
ffi (~> 1.0)
59+
rouge (3.10.0)
60+
ruby_dep (1.5.0)
61+
safe_yaml (1.0.5)
62+
sassc (2.2.0)
63+
ffi (~> 1.9)
64+
terminal-table (1.8.0)
65+
unicode-display_width (~> 1.1, >= 1.1.1)
66+
thread_safe (0.3.6)
67+
tzinfo (1.2.5)
68+
thread_safe (~> 0.1)
69+
tzinfo-data (1.2019.3)
70+
tzinfo (>= 1.0.0)
71+
unicode-display_width (1.6.0)
72+
wdm (0.1.1)
73+
74+
PLATFORMS
75+
ruby
76+
77+
DEPENDENCIES
78+
jekyll (~> 4.0.0)
79+
jekyll-feed (~> 0.12)
80+
minima (~> 2.5)
81+
tzinfo (~> 1.2)
82+
tzinfo-data
83+
wdm (~> 0.1.1)
84+
85+
BUNDLED WITH
86+
2.0.2

README.md

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
# About
2+
3+
This is the source for the JavaParser.org website.
4+
5+
It uses a combination of static HTML pages and the Jekyll publishing engine.
6+
7+
# Setup
8+
9+
If you wish to edit the static html pages you can clone the repository edit and push the changes as usual.
10+
11+
In order to publish blog posts you will need to setup Jekyll with Bundler, using [this](https://jekyllrb.com/tutorials/using-jekyll-with-bundler/) guide. The current site has been built with Bundler v2.0.2.
12+
13+
From the root of the repository you should be able to run:
14+
15+
```
16+
bundle exec jekyll server
17+
```
18+
19+
The site should be served on `localhost:4000`
20+
21+
# Publishing Blog Posts
22+
23+
1) Create a new markdown file in the `_post` directory using the established naming convention.
24+
25+
2) Providing you are running `bundle exec jekyll server` the markdown file should be generated as html in the `_site` directory.
26+
27+
3) After you have create a post, edit the cards in the blog grid in the `blog.html` page so it is accessible from the blog index.
28+
29+
4) Commit and push the markdown, edits to blog.html and generated html file.
30+

_config.yml

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
# Welcome to Jekyll!
2+
#
3+
# This config file is meant for settings that affect your whole blog, values
4+
# which you are expected to set up once and rarely edit after that. If you find
5+
# yourself editing this file very often, consider using Jekyll's data files
6+
# feature for the data you need to update frequently.
7+
#
8+
# For technical reasons, this file is *NOT* reloaded automatically when you use
9+
# 'bundle exec jekyll serve'. If you change this file, please restart the server process.
10+
#
11+
# If you need help with YAML syntax, here are some quick references for you:
12+
# https://learn-the-web.algonquindesign.ca/topics/markdown-yaml-cheat-sheet/#yaml
13+
# https://learnxinyminutes.com/docs/yaml/
14+
#
15+
# Site settings
16+
# These are used to personalize your new site. If you look in the HTML files,
17+
# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
18+
# You can create any custom variable you would like, and they will be accessible
19+
# in the templates via {{ site.myvariable }}.
20+
21+
title: JavaParser
22+
23+
description: >- # this means to ignore newlines until "baseurl:"
24+
JavaParser Analyse, transform and generate your Java codebase
25+
baseurl: "" # the subpath of your site, e.g. /blog
26+
url: "" # the base hostname & protocol for your site, e.g. http://example.com
27+
#twitter_username: jekyllrb
28+
#github_username: jekyll
29+
30+
# Build settings
31+
theme: minima
32+
plugins:
33+
- jekyll-feed
34+
35+
# Exclude from processing.
36+
# The following items will not be processed, by default.
37+
# Any item listed under the `exclude:` key here will be automatically added to
38+
# the internal "default list".
39+
#
40+
# Excluded items can be processed by explicitly listing the directories or
41+
# their entries' file path in the `include:` list.
42+
#
43+
exclude:
44+
- .idea/
45+
- README.md
46+
- .gitignore
47+
# - .sass-cache/
48+
# - .jekyll-cache/
49+
# - gemfiles/
50+
# - Gemfile
51+
# - Gemfile.lock
52+
# - node_modules/
53+
# - vendor/bundle/
54+
# - vendor/cache/
55+
# - vendor/gems/
56+
# - vendor/ruby/

_includes/youtubePlayer.html

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
<iframe width="560" height="315" src="https://www.youtube.com/embed/{{ include.id }}" frameborder="0" allowfullscreen></iframe>
Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
---
2+
layout: post
3+
title: "Code generation and Maven in JavaParser"
4+
date: 2018-03-03 09:58:46 +0100
5+
categories: [blog]
6+
tags: [guide, danny]
7+
permalink: /code-generation-and-maven-in-javaparser/
8+
---
9+
10+
If you are not working on the JavaParser project itself, ignore this article. What's below is outdated starting from version 3.2.9\. Currently the build does not include any code generation phases anymore. They can be run manually with two scripts, one to generate the metamodel, and one to run the core generators. Sadly this will mean that we will have to run these by hand for every PR, but it sure is a lot clearer!
11+
12+
* `run_metamodel_generator.sh` updates the metamodel when you modify (meaning: edit the source code of) one of JavaParser's node classes.
13+
* `run_core_generators.sh` uses the metamodel to generate a lot of code in javaparser-core.
14+
15+
## Outdated
16+
17+
Since version 3.1.0 I made a start on generating the repetitive parts of the JavaParser code, of which there are many. The way it is done is... _interesting_. I could have set up some kind of template project and generate code from that. We have a large amount of custom code in the nodes though, so that would have to be in the templates. That would put a code-generation step in the middle of developing _anything_ in the nodes. Any change there would need the generators to run before it could be tried or tested. It would be possible to keep the templates in working order, so development could be done on that, but that would mean the templates would have te be updated with the generated code all the time. This didn't sound like an effective, fail-safe way of working. I ended up with a trick: all code generators modifiy the source code _in-place_. Need a new field? Add it to a node, create a basic getter and setter, run the generators and suddenly the getter and setter contain generated code that checks all kinds of things, and the visitors are updated for your new field. Nice! What this did do is confuse the hell out of Maven... In case you are changing the AST structure (adding/removing/replacing nodes and their fields) this is the correct build order:
18+
19+
1. build javaparser-core
20+
2. build javaparser-metamodel-generator
21+
3. build javaparser-core
22+
4. build javaparser-core-generators
23+
5. build javaparser-core
24+
25+
This should be done by calling `mvn clean install` separately for every step. But whyyy? Well, reasoning backwards:
26+
27+
* To make sure all code in `core` is in the right place, we need to run the `core generators` (4) before we can run the final build (5). (Generators are run when their maven project is built, to make sure nobody opens a PR without running them.)
28+
* The `core generators` uses the meta model to know what has to be generated, and the meta model is in `core`. The `core generators` also parse and rewrite a lot of code using JavaParser itself, so it need `core` for this too. So, we need to build core (3)
29+
* `core generators` need an _up to date_ meta model, so we need to run the `metamodel generator` (2) before (3).
30+
* The metamodel generator uses JavaParser (`core`) to generate the metamodel classes in `core` by introspecting the nodes in `core`. Of course we need an up to date build of `core` for that (1)
31+
32+
In practice it looks like this:
33+
34+
1. you make a change to a node.
35+
2. you build `core`, then `metamodel generator` and check if the output is correct. Optionally revert incorrectly generated code. Repeat (1) and (2) until done.
36+
3. you build `core`, then `core generators` and check if the output is correct. Optionally revert incorrectly generated code. Repeat (3) or (1) (2) (3) until done.
37+
4. build `core` once more to be sure. If you're developing a new core generator, you'll find yourself doing step (3) and (4) only. If you're developing anything else, you can ignore this whole article :-)
Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
---
2+
layout: post
3+
title: "Inspecting an AST"
4+
date: 2018-03-03 09:58:46 +0100
5+
categories: [blog]
6+
tags: [guide, danny]
7+
permalink: /inspecting-an-ast/
8+
---
9+
10+
## Inspecting an AST
11+
12+
Two of the more common questions on JavaParser are:
13+
14+
* If I have this piece of code, how do I access that part of it?
15+
* If I want this piece of code, how do I create the AST for it?
16+
17+
and both can be answered the same way: by looking at the AST that is generated when you parse the code you have or want. We offer several ways to do this.
18+
19+
### First: parse the code
20+
21+
This is something like:
22+
23+
package com.github.javaparser;
24+
25+
import com.github.javaparser.ast.CompilationUnit;
26+
27+
public class Inspect {
28+
public static void main(String[] args) {
29+
// Parse the code you want to inspect:
30+
CompilationUnit cu = StaticJavaParser.parse("class X { int x; }");
31+
// Now comes the inspection code:
32+
System.out.println(cu);
33+
}
34+
}
35+
36+
### Option 1: your IDE's debugger
37+
38+
You'll need to figure out how your IDE works to get this to work. Put a breakpoint on `System.out.println(cu);` and run the program in debug mode. When it stops at the breakpoint, you should be able to see the known variables. Look for `cu` and you can click it open, and now you can inspect the whole generated AST.
39+
40+
### Option 2: use one the structure printers
41+
42+
Thanks to [Ryan Beckett](https://www.linkedin.com/in/ryanbeckett/) there are a few printers that will output the structure of the AST with only one purpose: for you to look at. My favourite one outputs Yaml:
43+
44+
// Now comes the inspection code:
45+
YamlPrinter printer = new YamlPrinter(true);
46+
System.out.println(printer.output(cu));
47+
48+
Here's the output. You can see property names (`isInterface`, `identifier`, ...) node types (`Type=CompilationUnit`) and values (`"false"`, `"x"`). You can see how a type has members, how `int x;` is one of those members, that it has type `FieldDeclaration` and can contain multiple variables, but there is only one now: `"x"`.
49+
50+
root(Type=CompilationUnit):
51+
types:
52+
- type(Type=ClassOrInterfaceDeclaration):
53+
isInterface: "false"
54+
name(Type=SimpleName):
55+
identifier: "X"
56+
members:
57+
- member(Type=FieldDeclaration):
58+
variables:
59+
- variable(Type=VariableDeclarator):
60+
name(Type=SimpleName):
61+
identifier: "x"
62+
type(Type=PrimitiveType):
63+
type: "INT"
64+
65+
If you like looking at XML, try:
66+
67+
// Now comes the inspection code:
68+
XmlPrinter printer = new XmlPrinter(true);
69+
System.out.println(printer.output(cu));
70+
71+
You will need to load this into an editor that can format XML. Finally an extra cool one - it outputs the AST as a dot file which can be visualized as a graph with [Graphviz](http://graphviz.org/)!
72+
73+
// Now comes the inspection code:
74+
DotPrinter printer = new DotPrinter(true);
75+
try (FileWriter fileWriter = new FileWriter("ast.dot");
76+
PrintWriter printWriter = new PrintWriter(fileWriter)) {
77+
printWriter.print(printer.output(cu));
78+
}
79+
80+
I've sent the output to Graphiz this way:
81+
82+
dot -Tpng ast.dot > ast.png
83+
84+
![](/img/figures/ast.png)

0 commit comments

Comments
 (0)