Can't Import Java Projects

[JoelProminic]

I saw this behavior in my tests today:

1. Create a new Java Maven Project
2. Close the project
3. Delete the javaproj file
4. Project > Open/Import Project
5. Moonshine shows prompt: "This directory is missing the Moonshine project configuration files. Do you want to generate a new project by locating existing source?"
6. Click Yes. BUG: Nothing happens after the prompt closes. There is no error on the console.

[rat-moonshine]

The handler method-process to the prompt seems do not permits to continue if it can guess the folder is a Visual Editor or Java project type of here.

(Note, this check can easily fail if the folder name doesn't consists of targeted string)

If I remove that check and let the process continue, then it'll open the regular project creation dialog. This dialog managed by project creation API to create AS3/Flex/Feathers etc. type of projects. Java project creations handles by another API and opens its own managed dialog.

The regular project creation API has close logic to work on in such request and handles the UI differently, i.e. providing option to choose project type etc. These logic are missing in the Java project creation API. I see if I continue to create a new Java project by the regular API/dialog it throws error.

This probably error-prone to determine between others and Java project files by looking into the target directory's files/folders and choose between regular project creation or Java project creation API. Since project with existing source creation codes are very closely-coupled to regular project creation source, extracting those codes as standalone class and use it between regular and Java project creation may take time. But I don't like the idea to have these codes duplicated in the Java project creation again.

I see Java project creation API has duplicated-like codes from regular project creation API, though. Maybe, it would have been better if the API could extend from a common base class that may used by regular project creation API too.

I'd keep this for post-v2.1 release.

[piotrzarzycki21]

I see Java project creation API has duplicated-like codes from regular project creation API, though. Maybe, it would have been better if the API could extend from a common base class that may used by regular project creation API too.

Well that can happen only if we will have enough good abstraction called CreateProject and than each types of project can have CreateActionScriptProject, CreateJavaProject or even more granular CrateFlexProject, CreateJavaGradleProject etc. However we don't have such abstraction yet.

[piotrzarzycki21]

This probably error-prone to determine between others and Java project files by looking into the target directory's files/folders and choose between regular project creation or Java project creation API. Since project with existing source creation codes are very closely-coupled to regular project creation source, extracting those codes as standalone class and use it between regular and Java project creation may take time. But I don't like the idea to have these codes duplicated in the Java project creation again.

Can you point specific about what code are you talking about ?

[rat-moonshine]

This probably error-prone to determine between others and Java project files by looking into the target directory's files/folders and choose between regular project creation or Java project creation API. Since project with existing source creation codes are very closely-coupled to regular project creation source, extracting those codes as standalone class and use it between regular and Java project creation may take time. But I don't like the idea to have these codes duplicated in the Java project creation again.

Can you point specific about what code are you talking about ?

You can look into CreateProject class and look for the isOpenProjectCall followed by processes.

[piotrzarzycki21]

We don't have too much options than having this for next release. Are you going to work on that or do you want me to take it ?

[piotrzarzycki21]

I think I should start working on that. It seems to be too crucial. User has to be able import his project without any problems. I will try avoid code duplication as much as I can.

[piotrzarzycki21]

@JoelProminic , @rat-moonshine I have spent today a big portion of time fighting with that issue and I feel like I'm nowhere. That task should be pretty straightforward:

1. User pointing to folder where there is no Moonshine IDE project file
2. We are open View and present options

Problem in our case is that we have everything MODEL (AS3ProjectVO, JavaProjectVO) + VIEW (SettingsView) mixed together in one class. Today is my third time when I was trying to make some distinguish. I thought that I have good plan for that, but It always end up with growing amount of condition and more code in CreateProject class. I'm feeling that code which was created previously now is completely unprepared for good expanding to different type of projects.

When I'm looking into that view which is similar to what we are seeing for import project from source and create project:

I see some checkboxes, text inputs and combo box - Currently everything what you are seeing is literally connected to AS3ProjectVO and JavaProjectVO (CreateJavaProject). This is the problem cause we need to take care of what type of object it is etc.
I'm thinking right now about removing CreateProject and CreateJavaProject and start from scratch. I think we would like to have in the future more and more stuff in area of creating/importing project and class CreateProject will be monolitic.

The first question what do you think about such radical approach? - it's obviously may influence our schedule. I have some idea and plan which I can present, but it won't have any meaning if we do not think about that area the same and would like to hold current code. Let me know what do you think about that.

[rat-moonshine]

The thought behind the CreateProject class is larger, even I feel lost if I try to explain what many things/functionalities and conditions the class file handles. From creating all different kind of projects to importing-and-creating new project from existing source files. I do agree, the file grown to quite an extent in these years since we decide to introduce many different project types.

It would have better if we could break the things in a more modular manner. At the same time, this is sort of scary thinking what features are going to break during a new implementation. Since the logic are too dense covering many past requirement, this is valid that we may loose or fail-to-remember many things to cover.

One question, is 'project with existing source' doable with current project creation dialog having 'Project with Existing Source' checkbox and source folder/file things, for Java Maven/Gradle projects? I never tried this before. This approach anyway may valid as every application may have their gateway class-file (not sure if this is not necessary in case of Java project).

Where are you stuck particularly at this point? Opening to the above project dialog or how to continue from this project dialog (if already opened)?

[piotrzarzycki21]

The thought behind the CreateProject class is larger, even I feel lost if I try to explain what many things/functionalities and conditions the class file handles.

It doesn't matter right now what was the reason behind current implementation. What matter currently is that we are growing and this part of code is just unprepared for having more projects. It is now rather matter of choose between going farther in to the mess or having more proper solution - well discussed and planned.

[piotrzarzycki21]

One question, is 'project with existing source' doable with current project creation dialog having 'Project with Existing Source' checkbox and source folder/file things, for Java Maven/Gradle projects? I never tried this before. This approach anyway may valid as every application may have their gateway class-file (not sure if this is not necessary in case of Java project).

No currently you don't have an option create Java project using existing source at all, this is what is the subject of that issue at some point.

[piotrzarzycki21]

Where are you stuck particularly at this point? Opening to the above project dialog or how to continue from this project dialog (if already opened)?

It is hard to explain, but let me try to put here. I have currently CreateProject and CreateJavaProject - Ideally I would see that those two classes get's proper input and make what's needed with AS3ProjectVO and JavaProjectVO without absolutely any interaction with SettingsView!
My approach which I'm trying to make was at least put common things like SettingsView to some base class so both CreateProject and CreateJavaProject could be fed with. However AS3ProjectVO interacting with this view in so many places - that I have no idea how actually make it separated.

Like I said in previous post either now we make hard decision and try to do that in more proper way or I will add another bunch of conditions which recognize whether my project will be a Java and do what is needed. - In the results we will face more problems when Haxe support has come to our IDE.

[piotrzarzycki21]

FYI: In order to move forward I'm trying to use what we have - We will see where I end up.

[piotrzarzycki21]

@JoelProminic I have merged today my branch with Java import. It is non automatic import, so user need to choose appropriate template and point to the src folder and main app class. Give a try and let me know if it's working for you.

[piotrzarzycki21]

I get this error when creating a new Java Gradle or Maven project:

: Error #1069
: ReferenceError: Error #1069
: 	at actionScripts.plugin.settings::SettingsView/save()
: 	at actionScripts.plugin.settings::SettingsView/handleSaveClicked()
:
: Click here to Report a Bug

I cannot reproduce this error.

[piotrzarzycki21]

I tried this with an existing project, but I also get an error:

1. Find an existing Java Gradle project
2. Close the project
3. Remove .javaproj
4. Project > Open/Import Project and select this project. Accept the prompt to import the project
5. Change the project type to Java Gradle, and set the source directory and main application file
6. Submit the form. BUG: I get this error, and the project doesn't open:
   : Error [Domino Visual Editor] Interface Similar to "Objects" from Domino Designer #1009
   : TypeError: Error [Domino Visual Editor] Interface Similar to "Objects" from Domino Designer #1009
   : at actionScripts.plugin.java.javaproject.importer::JavaImporter$/parse()
   : at actionScripts.plugin.project.vo::ProjectShellVO/getProjectOutOfShell()
   : at actionScripts.plugins.as3project::CreateProject/getProjectWithTemplate()
   : at actionScripts.plugins.as3project::CreateProject/createFileSystemBeforeSave()
   : at actionScripts.plugins.as3project::CreateProject/onCreateProjectSave()
   : at flash.events::EventDispatcher/dispatchEvent()
   : at mx.core::UIComponent/dispatchEvent()
   : at MethodInfo-25844()
   : at actionScripts.plugin.settings::SettingsView/save()
   : at actionScripts.plugin.settings::SettingsView/handleSaveClicked()
   :
   : Click here to Report a Bug

However, I can successfully reimport an existing Java Maven project using similar instructions.

I have fixed this issue and made some small improvements. Try new build today.

[JoelProminic]

I did some testing with a Prominic Project today, and I found that the project import was overwriting build.gradle. This will overwrite configuration like:

• Custom dependencies - see my example projects above
• Custom main classes
• Custom build tasks

I think Moonshine should not overwrite build.gradle (or pom.xml) when importing Java projects, so that it repects the existing configuration. Some implications of this:

• The Source Directory and Main Class selected in the import prompt would not be needed for the build script (though they could still be used in the project file)
• If build.gradle does not have the "eclipse" plugin, then "gradle eclipse" will fail (Support Java Projects with Dependencies #547). This should trigger an error, which I already defined in Build Java Gradle Applications #519: "Unable to regenerate classpath for Gradle project. Please check that you have included the 'eclipse' plugin, and verify that your dependencies are correct."

Let me know if there are other issues I need to consider for this.

[JoelProminic]

When I try importing a Java Gradle project from SVN, I get this error:

: Error #1009
: TypeError: Error #1009
: 	at actionScripts.plugins.svn::SVNPlugin/handleCheckSVNRepository()
: 	at actionScripts.plugins.svn::SVNPlugin/handleProjectOpen()
: 	at flash.events::EventDispatcher/dispatchEvent()
: 	at actionScripts.plugins.as3project::CreateProject/onCreateProjectSave()
: 	at flash.events::EventDispatcher/dispatchEvent()
: 	at mx.core::UIComponent/dispatchEvent()
: 	at MethodInfo-25846()
: 	at actionScripts.plugin.settings::SettingsView/save()
: 	at actionScripts.plugin.settings::SettingsView/handleSaveClicked()
:
: Click here to Report a Bug

The javaproj was created:

<project>
  <gradleBuild>
    <option commandLine="clean run"/>
  </gradleBuild>
  <classpaths>
    <class path="src"/>
  </classpaths>
  <build>
    <option mainclass="CheckNotesUser"/> </build>
</project>

However, when I restarted Moonshine the project was removed automatically and could not be reopened without reimporting.

@rat-moonshine may need to help with this, since he has access to the SVN server. I'll send him a repository link.

[piotrzarzycki21]

I did some testing with a Prominic Project today, and I found that the project import was overwriting build.gradle. This will overwrite configuration like:

• Custom dependencies - see my example projects above
• Custom main classes
• Custom build tasks

I think Moonshine should not overwrite build.gradle (or pom.xml) when importing Java projects, so that it repects the existing configuration. Some implications of this:

• The Source Directory and Main Class selected in the import prompt would not be needed for the build script (though they could still be used in the project file)
• If build.gradle does not have the "eclipse" plugin, then "gradle eclipse" will fail (Support Java Projects with Dependencies #547). This should trigger an error, which I already defined in Build Java Gradle Applications #519: "Unable to regenerate classpath for Gradle project. Please check that you have included the 'eclipse' plugin, and verify that your dependencies are correct."

Let me know if there are other issues I need to consider for this.

I will look into that tomorrow morning and make sure that I'm not touching Gradle build script at all. It was leftover when we were trying to remember some information and reuse it using build script.

[rat-moonshine]

I confirm I have received the repository link from @JoelProminic . I'll check for the break in SVNPlugin and later move this to @piotrzarzycki21 .

[rat-moonshine]

When I try importing a Java Gradle project from SVN, I get this error:

: Error #1009
: TypeError: Error #1009
: 	at actionScripts.plugins.svn::SVNPlugin/handleCheckSVNRepository()
: 	at actionScripts.plugins.svn::SVNPlugin/handleProjectOpen()
: 	at flash.events::EventDispatcher/dispatchEvent()
: 	at actionScripts.plugins.as3project::CreateProject/onCreateProjectSave()
: 	at flash.events::EventDispatcher/dispatchEvent()
: 	at mx.core::UIComponent/dispatchEvent()
: 	at MethodInfo-25846()
: 	at actionScripts.plugin.settings::SettingsView/save()
: 	at actionScripts.plugin.settings::SettingsView/handleSaveClicked()
:
: Click here to Report a Bug

The above problem should have resolve now. Here are my test results:

1. Checkout Java project from Prominic repository
2. After above completes, Moonshine ask the directory is missing any configuration file, and if we want to create a new project with existing source
3. Upon choosing 'Yes' it opens new project creation dialog with existing source
4. I choose project type to Gradle (I don't know if this what I should choose)
5. Submitting the form Moonshine opens the project to sidebar and started language-server

I confirm I can see the new project link to the recent list after Moonshine restart, too.

While having the above tests, I noticed that double-clicking .javaproj configuration file or dragging into Moonshine, do not opens the project. This should work now for regular Java projects created with Moonshine template.

However, the above case I do not found fits for the Java project that Moonshine created by 'create-project-by-existing-source' method (after the above repository checkout).

I found two problems in this case:

1. When clicking from recently opened projects list, Moonshine throws error "Can't import: Not a valid Flex project directory." (phrase can be updated later for non-flex projects). I noticed the existing project-tests here do not thinks it's a Java project (@piotrzarzycki21 can look into the validation logic?)
2. While importing the same project with "Open/Import Project" option in splash-screen, Moonshine again prompts that the directory does not contain a valid Moonshine project, do we want to create a new project

For above.2 I understand the break is elsewhere, and we may need a separate issue to track the issue once above.1 is addressed.

For above.1, here is the project structure:

|------ dist
|--- lib
|--- src ---------------------------
|--- $projectName.javaproj          |
                                    |
                                    |--- net
                                            |--- prominic
                                                       |--- domino
                                                                  |---- folderA ---- *.java
                                                                  |---- folderB ---- *.java

[piotrzarzycki21]

I did some testing with a Prominic Project today, and I found that the project import was overwriting build.gradle. This will overwrite configuration like:

• Custom dependencies - see my example projects above
• Custom main classes
• Custom build tasks

I think Moonshine should not overwrite build.gradle (or pom.xml) when importing Java projects, so that it repects the existing configuration. Some implications of this:

• The Source Directory and Main Class selected in the import prompt would not be needed for the build script (though they could still be used in the project file)
• If build.gradle does not have the "eclipse" plugin, then "gradle eclipse" will fail (Support Java Projects with Dependencies #547). This should trigger an error, which I already defined in Build Java Gradle Applications #519: "Unable to regenerate classpath for Gradle project. Please check that you have included the 'eclipse' plugin, and verify that your dependencies are correct."

Let me know if there are other issues I need to consider for this.

I took care all of those points - I haven't seen any side effect yet after disabling source and main class selection, but maybe you will find something. New build should have all changes.

[JoelProminic]

Talking with @rat-moonshine, it looks like the SVN project is failing to reopen because of this code:
https://github.com/prominic/Moonshine-IDE/blob/e0183016159e3c2837759b26b7926850428dce4d/ide/MoonshineSharedCore/src/actionScripts/plugin/java/javaproject/importer/JavaImporter.as#L23

I can reproduce the behavior with this example project where I changed the source directory from src/main/java (the Maven standard) to src/ (the old Java/Eclipse standard).
2019_05_22__TestGradleSourcePath.zip

[piotrzarzycki21]

@JoelProminic I have fixed issue. Next bamboo build will have my changes. Let me know whether it helps.

[JoelProminic]

I confirmed that I can now reopen an imported project where the source directory is src/. This works from both the RECENTS list and on Moonshine restart.

[JoelProminic]

I tested importing some simple Java projects from GitHub, and they imported with no problems. They also reopened properly from RECENTS, Open/Import Project, and Moonshine restart.
Gradle: https://github.com/gradle/gradle-build-scan-quickstart.git
Maven: https://github.com/jitpack/maven-simple

If I have time, I'll look for some realistic projects that I can try.

[piotrzarzycki21]

I tested importing some simple Java projects from GitHub, and they imported with no problems. They also reopened properly from RECENTS, Open/Import Project, and Moonshine restart.
Gradle: https://github.com/gradle/gradle-build-scan-quickstart.git
Maven: https://github.com/jitpack/maven-simple

If I have time, I'll look for some realistic projects that I can try.

I will hold with closing this one in that case.

[JoelProminic]

I did some more testing importing some Prominic projects from SVN today, and this worked well (except for some problems with the projects themselves).

I tried importing the jdt-language-server project. However, I again got the behavior where the project would not reopen without going through the import process again. However, after further investigation, I found that this project uses Maven Modules. So, the source code is in the subprojects instead.

I'll create a separate issue to explore support for Maven Modules, since this doesn't really fit with the Moonshine project design.

[piotrzarzycki21]

I tried importing the jdt-language-server project. However, I again got the behavior where the project would not reopen without going through the import process again. However, after further investigation, I found that this project uses Maven Modules. So, the source code is in the subprojects instead.

The way how it is behave right now it is an expected way. As part of this issue there wasn't any work done on automatic import, where project is being recognize based on some conditions. In facet I would opt to leave it such behavior once we refactor stuff. I don't want to go as much deep into current code and make another bunch of condition just to have automatic import. We can live for now with couple of additional clicks after importing project.

I'm closing this one and move any further discussion to issue related to modules.