8000 Package dependency analysis features as a Clojure/Java/JavaScript library for use in static analysis or other apps · Issue #1 · connexta/osg-eyes · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Package dependency analysis features as a Clojure/Java/JavaScript library for use in static analysis or other apps #1

New issue

Have a question about this project? 8000 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

Open
Lambeaux opened this issue Apr 17, 2020 · 2 comments
Labels
capabilities/interfaces Concerns accessibility, runtime platforms, and interaction modes type/enhancement Something that isn't working - this is a feature that needs more polish or quality control

Comments

@Lambeaux
Copy link
Contributor
Lambeaux commented Apr 17, 2020

Summary

To get actionable results quickly, everything is going to live in a single module and the only artifact from build output will be a command line tool for working with the data. This issue concerns the next steps for making a shared, stable library available to consumers.

  • Splitting out the module into two separate modules (or more) as it makes sense
  • Ensuring Clojure code is packaged into the artifact
  • Leveraging specs and providing API documentation from the specs
  • Providing the adapter layer for other languages as needed

Ensuring Clojure code is packaged into the artifact

I do not think Clojure can be called by other Clojure programs or used at the REPL when it is AOT compiled. The pom would need to change so that clojure/ directories get copied into the jar as a resource, like so:

<sourceDirectory>src/test/clojure</sourceDirectory>
<resources>
  <resource>
    <directory>src/main/resources</directory>
  </resource>
  <resource>
    <directory>src/main/clojure</directory>
  </resource>
</resources>

Also the AOT settings would need to be fine tuned beyond the defaults.

@Lambeaux Lambeaux added the type/enhancement Something that isn't working - this is a feature that needs more polish or quality control label Apr 17, 2020
@Lambeaux
Copy link
Contributor Author
Lambeaux commented Apr 18, 2020

Turns out that the Clojure maven plugin supports adding source directories properly, so the build helper plugin was able to be removed 👍
https://github.com/talios/clojure-maven-plugin#available-goals

After some fine tuning I found the crux of an issue that was making compilation take a long time with default Clojure maven plugin settings. The idea was to leverage the Clojure :gen-class feature so that managing a main class ourselves wasn't necessary. Since our main class wraps REPLy's main class, this led to the AOT compilation of our code and all transitive dependency code. Since emitted bytecode is tied to the Clojure version, I doubt you can (or should) mix and match Clojure source and bytecode across projects & dependencies.

In light of this we're taking a hint from REPLy's main class and will just manage the Java main class ourselves without any compilation of our Clojure main. Other namespaces will be compiled and discarded to ensure the code is correct. In the future, a build option for AOT-ing the entire app including transitives would make sense if we want the slight performance boost for released artifacts.
https://github.com/talios/clojure-maven-plugin#namespace-configuration

IMO it seems the only remaining task for this issue is to split out modules when appropriate.

@Lambeaux Lambeaux added the capabilities/interfaces Concerns accessibility, runtime platforms, and interaction modes label Dec 4, 2020
@Lambeaux
Copy link
Contributor Author
Lambeaux commented Dec 4, 2020

Possible duplicate of #21 - there's definitely some overlap in the relevant work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
capabilities/interfaces Concerns accessibility, runtime platforms, and interaction modes type/enhancement Something that isn't working - this is a feature that needs more polish or quality control
Projects
None yet
Development

No branches or pull requests

1 participant
0