Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: Big reorg for handling sources #1272

Merged
merged 12 commits into from
Mar 5, 2022

Conversation

quintesse
Copy link
Contributor

@quintesse quintesse commented Mar 2, 2022

Lot's of changes here, but basically it boils down to 3 things:

  • Introduction of "builders" which allows us to isolate the process of compiling code and turning it into a JAR (and native code). Which will help us in the future to do chains of builds.
  • Introduction of "command generators" which allows us to isolate the process of running code (either compiled or as scripts, think Jshell). Not as important as builders but at least there is a bit of symmetry.
  • Introduction of "source sets". This is the most important bit where instead of being dependent on the idea that all sources start out with a link to a single file which contains a bunch of //-lines that need to be parsed, which can contain references to other sources and files, etc etc we now abstract that as a SourceSet. It contains all the information about a source project; sources, resources, dependencies etc etc. but without defining how that information is obtained. This will allow us in the future to define alternative project types. The new builders use this and are already much more agnostic about JBang-specific scripts. This is a big step but not completely done yet, there are still quite a number of places where assumptions are being made about the project structure but we can weed those out bit by bit in the coming time.

Seems that PowerShell is still bound by some pretty limmited command
lines buffers. So we'll just apply the same rules for PowerShell as we
do for CMD.

Fixes jbangdev#1253
The code for (recursively) obtaining all script information was all
centered on `ScriptSource` which made it hard to create/add alternative
sources of information. This is the first step on the way to remedy that.
No code was added in this refactor but the hierarchy was changed
extensively. First what was before called `Source` is now called `Input`
with the only implementing classes `Jar` and `SourceSet`.
The `ScriptSource` and child classes are now simply named `Script` and
don't inherit from `Source` anymore.
And Java isn't the default anymore for `Script`, but a separate
`JavaScript` (yes yes) was created and `Script` is now abstract.
Copy link
Collaborator

@maxandersen maxandersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks good.

--cds on build seems missing.

Not sure I like Jar instead of JarInput, etc. but you might have reason for that change?

i'll play around it more tomorrow.

Instead of a single `Builder` implementation (`JarBuilder`) we now use
a base implementation and several implementations, one for each of the
support programming languages. `SourceSet`s now know how they should
be built and can return the correct `Builder` for their sources.
A bunch of code was moved from the different `Script` classes to the
new `Builder` classes.
Now that `Source` wasn't used anymore we could use it again for the
classes that represent source files.
`Input` wasn't really a good name because when a `SourceSet` gets
built it's turned into a `Jar` which is an ouput, not an input.
While both a `SourceSet` and a `Jar` represent code, so `Code` seems
like a good generic name.
The `DefaultCmdGenerator` was split into a `BaseCmdGenerator` and pair
of implementations for running jars and jshell scripts.
@codecov
Copy link

codecov bot commented Mar 3, 2022

Codecov Report

Merging #1272 (d8aa209) into main (99ed4b8) will increase coverage by 0.49%.
The diff coverage is 73.14%.

Impacted file tree graph

@@             Coverage Diff              @@
##               main    #1272      +/-   ##
============================================
+ Coverage     58.26%   58.76%   +0.49%     
- Complexity     1077     1126      +49     
============================================
  Files            86       96      +10     
  Lines          5820     5963     +143     
  Branches        997      991       -6     
============================================
+ Hits           3391     3504     +113     
- Misses         1927     1955      +28     
- Partials        502      504       +2     
Flag Coverage Δ
Linux 57.52% <72.28%> (+0.47%) ⬆️
Windows 57.57% <73.04%> (+0.52%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/main/java/dev/jbang/cli/BaseScriptCommand.java 15.78% <0.00%> (ø)
src/main/java/dev/jbang/cli/ExportMixin.java 37.50% <ø> (ø)
.../java/dev/jbang/source/builders/GroovyBuilder.java 0.00% <0.00%> (ø)
.../java/dev/jbang/source/builders/KotlinBuilder.java 0.00% <0.00%> (ø)
...in/java/dev/jbang/source/sources/GroovySource.java 0.00% <0.00%> (ø)
...in/java/dev/jbang/source/sources/KotlinSource.java 0.00% <0.00%> (ø)
src/main/java/dev/jbang/cli/Edit.java 46.95% <29.62%> (-1.05%) ⬇️
.../dev/jbang/source/generators/BaseCmdGenerator.java 52.63% <52.63%> (ø)
...rc/main/java/dev/jbang/spi/IntegrationManager.java 21.35% <66.66%> (ø)
...in/java/dev/jbang/source/builders/BaseBuilder.java 69.25% <69.25%> (ø)
... and 25 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 99ed4b8...d8aa209. Read the comment docs.

@quintesse
Copy link
Contributor Author

Tests have passed yay

@quintesse quintesse requested a review from maxandersen March 3, 2022 22:50
import dev.jbang.source.RunContext;
import dev.jbang.source.ScriptSource;
import dev.jbang.source.Source;
import dev.jbang.source.*;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are * based imports fine?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't have a strong rule against it - but prefer to keep it to minimum.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly I thought Spotless automatically removed all of them.

@maxandersen
Copy link
Collaborator

some of the naming i'm not a super fan of but I prefer to live with it until we find better names (if ever :) than not get this refactor in.

this will make great things easier! thanks @quintesse !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants