Skip to content

Conversation

@ErnestMatskevich
Copy link

Renamed branch to #500 for tracking issue
Added test for Inspect.java file

ErnestMatskevich and others added 6 commits May 21, 2025 02:29
Added:
qulice plugin in pom.xml
test_inspect.js file with unit test

For testing installed in dev dependencies:
sinon
proxyquire
add stronger signatire for main() in Inspect.java

add test for Inspect.java
@ErnestMatskevich
Copy link
Author

I added simple test for Inspect.java file, but when run qulice I faced with tha same warnings as in previous PR:

[WARNING] Unused declared dependencies found:
org.eolang:eo-runtime:jar:0.56.2:compile
org.junit.jupiter:junit-jupiter-api:jar:5.12.2:compile
org.junit.jupiter:junit-jupiter-engine:jar:5.12.2:compile
org.takes:takes:jar:1.24.6:compile

Also I would like to clarify how to build inspect.jar with Maven. Since currently there is single pom.xml file, Maven makes eoc.jar file as it writen in its . For complete my task I need to create my own file inspect.jar. I would like to use <execution> in pom.xml to separate creating eoc.jar and my inspect.jar. Is it correct idea? I think that after separate creating inspect.jar there will be no more warning about unused dependencies, because qulice will be placed in <execution> of inspect part and will not see junit and eo-runtime dependecies. @yegor256 What do you think about use in pom.xml?

There is 1 falling check in eslint workflow Is it on my side? If it is how can I fix that?

@yegor256
Copy link
Member

@ErnestMatskevich I fixed eslint, please merge master into your branch

@yegor256
Copy link
Member

@ErnestMatskevich show what you are trying to do and show the error (in CI logs). We'll be able to provide help.

@ErnestMatskevich
Copy link
Author

@yegor256 I merged master, now all cheks pass. I will try to edit pom.xml and show if any errors occurs in CI

Added profile section for creating independing inspect.jar file. Placed Takes and qulice inside profile
@ErnestMatskevich
Copy link
Author

@yegor256 I made profile in pom.xml for creating inspect.jar, all cheks passed. Please, take a look, is it good solution?

I have some questions:

  1. Should I create fat-jar (with takes dependency in inspect.jar)?
  2. Why org.junit.jupiter:junit-jupiter-api and org.junit.jupiter:junit-jupiter-engine have scope compile? As I know they are need for testing

@ErnestMatskevich
Copy link
Author

@yegor256 please take a look at my last commit in this PR. If there is no problem, let's merge? or close this PR and I will continue open new PR's with adding other functionality of inspect command. Moreover, I still interesing in questions wrote upper. Could you please clarify for me details about fat jar and scope of junit.

@yegor256
Copy link
Member

@ErnestMatskevich it's better to ask questions as separate tickets, see: https://www.yegor256.com/2025/05/25/bug-driven-development.html

@yegor256
Copy link
Member

@volodya-lombrozo can you please check this design?

@yegor256 yegor256 requested a review from volodya-lombrozo May 28, 2025 03:28
Copy link
Member

@volodya-lombrozo volodya-lombrozo left a comment

Choose a reason for hiding this comment

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

@ErnestMatskevich

Thank you for the contribution! I have a few important notes related to the PR itself. Highly recommend reading "Helping others review your changes". Pay attention to the Write small pull requests and the Provide context and guidance sections. Could you also please make the title of this PR a bit more meaningful, rather than just "500", please?

Copy link
Member

@volodya-lombrozo volodya-lombrozo left a comment

Choose a reason for hiding this comment

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

@yegor256

inspect -> debug

As I understand it, you want to write a debugger. Why not call it eoc debug then? Why should we hide this information under the misleading inspect command?

Separate Project

Why do we need to implement the entire debugger in the eoc repository? Maybe it's better to move it to a separate repo, as other projects do?
Here, we can just leave a thin eoc debug command just to invoke this debugger.
Moreover, eoc is written in JS. Adding Java would create a some sort of mess.

What do you think?

@yegor256
Copy link
Member

@volodya-lombrozo how would you call a tool that allows you go into a working Java virtual machine, find any object and see its details? Would it be a debugger?

Indeed, this tool deserves a separate project/repository, but maybe a bit later, when its first version is ready. So far, it's an early draft.

@volodya-lombrozo
Copy link
Member

volodya-lombrozo commented May 28, 2025

@volodya-lombrozo how would you call a tool that allows you go into a working Java virtual machine, find any object and see its details? Would it be a debugger?

Yes, it's what debuggers allow me to do - to "inspect" runtime.

@ErnestMatskevich ErnestMatskevich changed the title 500 500, adding entry point to inspect commands May 28, 2025
@ErnestMatskevich ErnestMatskevich changed the title 500, adding entry point to inspect commands 500, adding entry point to inspect command May 28, 2025
@ErnestMatskevich
Copy link
Author

@volodya-lombrozo Thank you for your review feedback. I've made the following improvements:

  1. Updated PR title to clearly state the functionality.
  2. Will follow up with smaller, focused PRs containing detailed descriptions

For the current changes in pom.xml added Maven profile section to build self-contained inspect.jar.

inspect command can be run with help

node src/eoc.js inspect 

or it is possible just build inspect.jar with help Maven and use -Pinspect for indepening package/compile.

Could you please review this profile configuration approach.

server.start();
Thread.sleep(2000L);
server.interrupt();
server.join(1000L);
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich Could you add clear assert statements, please? Here is a good paragraph how you can do it.

mvnw/pom.xml Outdated
<build>
<finalName>eoc</finalName>
<sourceDirectory>${eo.generatedDir}</sourceDirectory>
<resources>
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich Why do we need to add this directory to the resources?

mvnw/pom.xml Outdated
<finalName>inspect</finalName>
<plugins>
<plugin>
<groupId>com.qulice</groupId>
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich Why do we need to add qulice in this PR? It's a good tool, but it should be added in a dedicated PR.

module.exports = function(opts) {
return new Promise((resolve, reject) => {
const mvnDir = path.join(process.cwd(), 'mvnw');
console.info('Building EO inspect server with Maven...');
Copy link
Member

@volodya-lombrozo volodya-lombrozo May 29, 2025

Choose a reason for hiding this comment

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

@ErnestMatskevich @yegor256 Do we really need to build a java server each time we execute the eoc inspect command? It's suboptimal. Moreover, it requires Maven to be installed on the machine. And I haven't even mentioned the execution time yet.

Copy link
Member

Choose a reason for hiding this comment

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

@volodya-lombrozo @ErnestMatskevich indeed, it's better to build it once, when we package eoc. Then, simply run it.

const proxyquire = require('proxyquire');
describe('inspect command (mocked)', () => {
it('should send text and receive echoed response, then exit cleanly', async () => {
const mockStdout = new stream.PassThrough();
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich Can we simplify these variable names somehow? A Compound Name Is a Code Smell

ErnestMatskevich and others added 3 commits May 30, 2025 00:40
Added asserts in InspectSmokeTest.java and changed Inspect.java to handle interrupt
Delete qulice plugin and redundant resources section in pom.xml
Delete unused import
Remove redundant variable body
Simplified FkRegex with lambda
@ErnestMatskevich
Copy link
Author

@volodya-lombrozo I fixed feedback items from your review. I splitted them into 2 commits:

  1. Fixed InspectTest.java at this commit
  • Renamed file to InspectTest.java
  • Wrote test with hamcrest
  • Rewrite from wait and see antipattern to adaptive waiting.
  1. Updated Inspect.java at this commit
  • Deleted unused import org.takes.http.Exit since now server could be interrupt
  • Simplify code with lambda. It looks clearly now and has same functionality
  • Removed redundant variable body

There is 1 check falling with building on windows, but macoc and ubuntu cheks passed. Is workflow falled because of my changes? The error in foreign part, but I did not edit it.

Could you please check my commits and help to fix build

Add maven assembly plugin which build inspect.jar

Refactor inspect.js - no more build inspect.jar, just run it

Refacror test_inspect.jar - no more testing maven part since it is not job of inspect command now
@ErnestMatskevich
Copy link
Author

@yegor256 @volodya-lombrozo I changed eoc inspect command behaviour. Now command mvn clean package creates inspect.jar with server and takes dependency inside. inspect.js just load inspect.jar and does not build it every time. Done in commit

I wrote descriptor src/assembly/inspect.xml for maven-assembly-plugin which I use for build inspect.jar and excluded .class files with my code in maven-jar-plugin for eoc.jar.

I deleted Maven part from inspect.js since inspect.jar is building by mvn clean package and deleted checks for Maven in test_inspect.js

There are problems in workflow with build and itests:

  • Build fails

  1. dataize at 0.56.2 version
  2. dataize with command-line argument
    dataization for older version is passed, but this 2 steps fails. Is problem on my side? I did not edit default building except adding exclusions for files with my code to avoid include them in eoc.jar
  • itests fails

Could't find object 'Φ.org.eolang.io'

Could you please take a look for my commit and help to fix build

Copy link
Member

@volodya-lombrozo volodya-lombrozo left a comment

Choose a reason for hiding this comment

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

@ErnestMatskevich There are significant improvements. Thanks! Just a few small comments.

As for filling build, I suggest creating a new issue for that.

/**
* Private constructor.
*/
private Inspect() {
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich Great thanks for the explanation. Now it's clear.

server.isAlive(),
is(true)
);

Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich Can we remove empty lines, please? It's a code smell.

}
assertThat(
"Server thread should be running after start",
server.isAlive(),
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich Here you just check the the thread is alive. It tells nothing about the server availability.
https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#isAlive--

Copy link
Author

Choose a reason for hiding this comment

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

@volodya-lombrozo Yes, the purpose of this test now is just check that server is starting without any errors. The availability of server is cheking in test_inspect.js file.

Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich How do you know there aren't errors? It may be that the server didn't actually start, but the thread is still alive.

}
}
);
server.setDaemon(false);
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich Why do we need this? From https://stackoverflow.com/a/17878439/10423604:

Any thread created by main thread, which runs main method in Java is by default non daemon because Thread inherits its daemon nature from the Thread which creates it i.e. parent Thread and since main thread is a non daemon thread, any other thread created from it will remain non-daemon until explicitly made daemon by calling setDaemon(true).

Remove empty lines as it code smell

Remove .setDaemon(false) as children thread is not daemon by default
@ErnestMatskevich
Copy link
Author

@volodya-lombrozo Thank you for your detail reviewes! I committed last changes.

In InspectTest.java:

  • Deleted empty lines
  • Deleted server.SetDaemon(false)

I opened issue for failing workflow

Could you please check last commit and help to understand reason of failing.

ErnestMatskevich and others added 3 commits June 22, 2025 20:48
Set src/main/java directly to sourceDirectory to show Maven right path to Java code.

Instead add <source>${eo.generatedDir}</source> to org.codehaus.mojo for opportunity run the tests
@ErnestMatskevich
Copy link
Author

Summary for commit

Updated PR to make it satisfactory with current branch and fixed some errors.

There is a bug in CI/CD: itest part and build

The problem is same for both steps and looks like:
Can not find "foo.bar.simple" object (java path is "EOfoo.EObar.EOsimple").

There are such files in generated-source folder, but they do not include in eoc.jar

Will try to solve it

Add new execution to place EOfoo package to classes and inside eoc.jar
Write cleaner exclude for ignoring only package-info.class for Java code of Inspector
@ErnestMatskevich
Copy link
Author

Fixed all errors

  1. Updated package-lock.json for includes node-fetch - commit

  2. Set src/main/java in <sourceDirectory> of <build> section in pom.xml for help Maven to see Java code of Inspector and avoid errors with unrecognising Java code, when run other commands which set different directories in <sourceDirectory>. For takes all previous functionality of other part of eoc source code, in build-helper-maven-plugin from pom.xml was set original <source>${eo.generatedDir}</source>. - commit

  3. The main problem was this line: <exclude>**/package-info.class</exclude> in pom.xml.
    The ** part exclude all package-info.class in project, but should excludes specific package-info.class for Inspect part.
    After refactoring line is: <exclude>org/eolang/package-info.class</exclude> and all checks are passed. - commit

@yegor256 Please, take a look

return new Promise((resolve, reject) => {
const mvnDir = path.join(process.cwd(), 'mvnw');
const jar = path.join(mvnDir, 'target', 'inspect.jar');

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Author

Choose a reason for hiding this comment

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

My bad, fixed in commit

@yegor256
Copy link
Member

@ErnestMatskevich looks good! I'm not sure though, it's a good idea to keep source files in the mvnw/ directory. Maybe we can create a new top-level directory called, for example, inspect/ and place src/main/java/ into it?

@yegor256
Copy link
Member

@volodya-lombrozo please, take a look one more time

@ErnestMatskevich
Copy link
Author

@ErnestMatskevich looks good! I'm not sure though, it's a good idea to keep source files in the mvnw/ directory. Maybe we can create a new top-level directory called, for example, inspect/ and place src/main/java/ into it?

@yegor256 I think while there is only Java code of inspect in project, no need to create new directory and leave Java files in standart Maven path (src/main/java). Moreover since you wrote that is is like a draft and should be placed in different repository in future, I think it is not a problem that for now files in mvnw.

@yegor256
Copy link
Member

@ErnestMatskevich we don't know for how long these files will stay with us. Once they are merged, they are with us (forever). It's better to place them correctly. The mvnw/ is not a "Maven folder". It's "Maven wrapper". The files you commit have nothing to do with the wrapper, right?

Extract source code files from mvnw and place them in inspect folder
@ErnestMatskevich
Copy link
Author

ErnestMatskevich commented Jun 23, 2025

@ErnestMatskevich we don't know for how long these files will stay with us. Once they are merged, they are with us (forever). It's better to place them correctly. The mvnw/ is not a "Maven folder". It's "Maven wrapper". The files you commit have nothing to do with the wrapper, right?

@yegor256 Done in this commit

Yes, I do not work with wrapper directly, i just build JAR file for server

@ErnestMatskevich
Copy link
Author

@volodya-lombrozo Please take a look. I added small commits described below. Also this commit about creating new top-level folder inspect with source code.

Fixed all errors

  1. Updated package-lock.json for includes node-fetch - commit
  2. Set src/main/java in <sourceDirectory> of <build> section in pom.xml for help Maven to see Java code of Inspector and avoid errors with unrecognising Java code, when run other commands which set different directories in <sourceDirectory>. For takes all previous functionality of other part of eoc source code, in build-helper-maven-plugin from pom.xml was set original <source>${eo.generatedDir}</source>. - commit
  3. The main problem was this line: <exclude>**/package-info.class</exclude> in pom.xml.
    The ** part exclude all package-info.class in project, but should excludes specific package-info.class for Inspect part.
    After refactoring line is: <exclude>org/eolang/package-info.class</exclude> and all checks are passed. - commit

@yegor256 Please, take a look

*
* @since 0.29.0
*/
final class InspectTest {
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich It seems, that this test checks nothing. Moreover, it's too error prone. Can we just remove it?

}
console.log('Sending request with body:', input);
try {
const response = await fetch('http://localhost:8080/echo', {
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich What if I already have another application running on 8080 port? Please, don't fix it here. Just leave a puzzle

</build>
<profiles>
<profile>
<id>inspect</id>
Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich I can't find the place in the code where you use this Maven profile. Can you give me a link, please?

Copy link
Member

Choose a reason for hiding this comment

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

@ErnestMatskevich What about this one?

@ErnestMatskevich
Copy link
Author

@volodya-lombrozo Please, take a look. All tasks done, all checks passed

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