I am trying to import a Maven project into eclipse but I am having difficulty getting Eclipse to see the java files as source files and not as resource files.
I am able to clean/build the project via eclipse however.
The project has parent pom.xml which lists several sub projects as modules.
If I directly import any of the subprojects it will see the java files as source files, but this will make it difficult to manage different versions of the project if each version will require multiple interrelated projects.
I would ideally like a way to import just the parent project and have all sub projects managed under it.
Project file tree:
ProjectFoo
+.settings
+base
+lib
+SubProjectFooA
| +.settings\
| +scs
| +target
| +.classpath
| +.project
| +pom.xml
+SubProjectFooB
| +.settings\
| +scs
| +target
| +.classpath
| +.project
| +pom.xml
+SubProjectFooC
| +.settings\
| +scs
| +target
| +.classpath
| +.project
| +pom.xml
+SubProjectFooD
| +.settings\
| +scs
| +target
| +.classpath
| +.project
| +pom.xml
+SubProjectFooE
| +.settings\
| +scs
| +target
| +.classpath
| +.project
| +pom.xml
+SubProjectFooF
+.settings\
+scs
+target
+.classpath
+.project
+pom.xml
In the parent pom.xml this is how all the sub projects are added. I am not very familiar with maven and think part of the problem could be the sub projects are added as modules, but I am not certain yet.
<modules>
<module>SubProjectFooA</module>
<module>SubProjectFooB</module>
<module>SubProjectFooC</module>
<module>SubProjectFooD</module>
<module>SubProjectFooE</module>
<module>SubProjectFooF</module>
</modules>
Things I have tried:
Pull copy of project from git, run mvn eclipse:clean eclipse:eclipse, then import into Eclipse
Directly adding javabuilder and javanature to .project file
Agree: this can be cumbersome, especially with a large number of sub-projects.
The parent pom will typically be its own project. Other projects that use the parent pom will also be their own projects, and linked to the parent pom using Maven.
Files/directories such as .settings, .classpath, .project and pom.xml must be at the top level of an Eclipse project (nesting sub-projects inside another related project will probably not work).
While there may be settings for <modules> in Eclipse & Maven that I am not aware of, everything you have with a src/target folder should be in its own Eclipse project. They can then be setup as dependencies of each other (either in Eclipse, Maven, or both).
In the end I followed khmarbaise instructions. (There was a .project file in the root in the repo that needed to be deleted)
After deleting all .classpath, .project and .settings files, I was able to use the import wizard without any issues.
The only other thing I will add is before I primarily used the package explore in eclipse, this will show each of the sub projects as sperate entities. If you go to the Project explorer it will show the root project in the working set you added it to with the sub projects nested underneath.
Related
When I have an aar library how to list all the dependencies of this aar ? for exemple i have facebook-core-5.15.1.aar and the dependencies are :
+--- com.facebook.android:facebook-core:5.15.1
| +--- com.parse.bolts:bolts-android:1.4.0
| | +--- com.parse.bolts:bolts-tasks:1.4.0
| | \--- com.parse.bolts:bolts-applinks:1.4.0
| | \--- com.parse.bolts:bolts-tasks:1.4.0
| +--- com.android.support:support-annotations:27.0.2
| +--- com.android.support:support-core-utils:27.0.2
| | +--- com.android.support:support-annotations:27.0.2
| | \--- com.android.support:support-compat:27.0.2
| | +--- com.android.support:support-annotations:27.0.2
| | \--- android.arch.lifecycle:runtime:1.0.3
| | +--- android.arch.lifecycle:common:1.0.3
| | \--- android.arch.core:common:1.0.0
| \--- com.android.installreferrer:installreferrer:1.1
How to retrieve this dependencies tree from a command line? and accessory how to know where to download all thoses dependencies?
I need to know this because as far as I know If I add com.facebook.android:facebook-core:5.15.1.aar in my project without adding com.parse.bolts:bolts-android:1.4.0.aar (for exemple), then my project will not work.
In the research I did I found this way to know all the dependencies needed by a libraries, I must create a android studio project, add the dependencies like this:
dependencies {
implementation 'com.facebook.android:facebook-core:5.15.1'
}
and then run: gradlew app:dependencies But I want to avoid to create an android project and I need to automate the task from a command line
AFAIK, when you run ./gradlew app:dependencies command, it will report all dependencies of the app module, no command for specific library's dependencies report. However, Android Studio have the resolved dependencies report (after synced project), you may check if it is your need.
File > Project Structure > Dependencies menu > Your modules (app) > Resolved dependencies.
You might be looking for something already existing, for example:
https://github.com/status-im/go-maven-resolver. Usage:
$ echo commons-io:commons-io:2.4 | ./go-maven-resolver
https://repo.maven.apache.org/maven2/commons-io/commons-io/2.4/commons-io-2.4.pom
https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/25/commons-parent-25.pom
https://repo.maven.apache.org/maven2/org/apache/apache/9/apache-9.pom
Although it gives you dependency URLs, but you can easily parse them to get GAV coordinates, or modify the script to print out the tree-like structure.
List of dependencies can be found on mvnrepository.com or search.maven.org
You can write a program that will parse these sites and give out data in the desired format
P.S.
Resolving child dependencies is one of the main purposes of gradle. The fact that you have to manually write child dependencies indicates that you have some kind of error in the configuration (maybe a newer version of the dependency is already included)
A library (aar or jar) does not contain any dependency informations by itself. However, libraries are
generally available in Maven repositories, and such repositories provide dependency informations via
POM files (which are XML files).
The URL where a POM file is available can be constructed from the following elements:
Repository URL
groupId
artifactId
version
The main repository is Maven Central. Its URL is https://repo1.maven.org/maven2/. Most libraries are
available there.
For com.facebook.android:facebook-core:5.15.1, the POM URL is:
https://repo1.maven.org/maven2/com/facebook/android/facebook-core/5.15.1/facebook-core-5.15.1.pom
The file contains a <dependencies> element:
<dependencies>
<dependency>
<groupId>com.parse.bolts</groupId>
<artifactId>bolts-android</artifactId>
<version>1.4.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.android.support</groupId>
<artifactId>support-annotations</artifactId>
<version>27.0.2</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.android.support</groupId>
<artifactId>support-core-utils</artifactId>
<version>27.0.2</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.android.installreferrer</groupId>
<artifactId>installreferrer</artifactId>
<version>1.1</version>
<scope>compile</scope>
</dependency>
</dependencies>
Only the direct dependencies are listed. To get the so-called "transitive dependencies", you need to iterate
the process and fetch the POM files of the dependencies.
Note that Google publishes its Android libraries in its own Maven repository, at this URL:
https://maven.google.com/
So, for com.google.firebase:firebase-messaging:12.0.1, the POM URL is:
https://maven.google.com/com/google/firebase/firebase-messaging/12.0.1/firebase-messaging-12.0.1.pom
I am looking for a way to display all the dependencies and their resolved versions in a Gradle project. I want the result to be flat.
Gradle has the dependencies task which prints the dependency tree, however, it is not flat and hard to read. For e.g. logback-classic has the following dependency tree.
| | | +--- ch.qos.logback:logback-classic:1.2.3
| | | | +--- ch.qos.logback:logback-core:1.2.3
| | | | \--- org.slf4j:slf4j-api:1.7.25 -> 1.7.30
Instead of this tree structure, I want the result to be following(dependencies with their resolved versions):
ch.qos.logback:logback-classic:1.2.3
ch.qos.logback:logback-core:1.2.3
org.slf4j:slf4j-api:1.7.30
This way it would be easy for me to find out the vulnerable libraries(for e.g. log4j), and it would also give me insights on dependent jars even if I don't directly use them.
I'm building an Automation Tool using Java Automation Framework under the hood, to which users will not have access to the main POM.xml file. Sometimes users require to add a custom Java function which requires additional depedencies / repositories. Presently I have to make changes to the main POM file to accommodate the user request. User has access only to "src/test/java/com/script/custom" folder to write custom scripts / functions. I have explored options like Parent/Child POM, Plugin Management, Profile, etc. but examples are mainly for multiple projects. I'm a NodeJs/Angular person, so I'm a beginner at Java.
Project
|
|--src/test/java/com/script/custom
| |
| custom_code.java
| |
| custom_pom.xml
|
--pom.xml
Users should only enter additional dependencies / repos in custom_pom.xml. Parent pom.xml will still hold the main dependencies/repos of the project.
Running code (apart from tests) is against the core concept of Maven as a build tool. There are ways, however, to excute arbitrary code at build time:
Exec Maven Plugin
without an additional plugin (and with cleanly separated projects):
+- project
| +- pom.xml
+- custom
+- src/main/java/com/script/custom
| +- CustomCode.java ... convention for Java class names is CamelCase
+- src/test/java/com/script/custom
| +- CustomCodeTest.java ... instantiates and runs CustomCode
+- pom.xml ... containing <parent><relativePath>../project
For <parent> see Introduction to the POM #Project Inheritance. See also Maven: Lifecycle vs. Phase vs. Plugin vs. Goal for further basics.
I'm trying to organise my maven project.
Let's say my project is called "awesome". "awesome" has several artifact, each of them built differently (e.g., some of them may be built with some plugin, others are built with some other plugins): in general thse build-configurations are finite and limited (let's say there are at most 3 different ways to build an artifact), however, each artifact can only be built with exactly one build (e.g., the utility artifact is built with maven-jar-plugin configured in a particular way, while the artifact client-ui is built with maven-war-plugin configured in a particular way).
Now, I know I could organize the maven project as follows:
awesome-root
|---jars
| |--- utility
| |--- client-model
| |--- task-model
| |--- supplier-model
| |--- client-logic
| |--- task-logic
| ---- supplier-logic
|---wars
|--- client-ui
|--- task-ui
---- supplier-ui
This way, each particular configuration build can be put inside the build --> plugins section of the projects jars and wars, while general properties/dependency management/plugin management can be put in awesome-root.
Problem:
I quickly realized that the developers generates artifacts closely related with eachother but with different builds. In the previous example, we can notice that the artifacts can be grouped in this other way:
awesome-root
|--- tasks
| |--- task-model
| |--- task-logic
| ---- task-ui
|--- clients
| |--- client-model
| |--- client-logic
| ---- client-ui
|--- supplier
| |--- supplier-model
| |--- supplier-logic
| ---- supplier-ui
|--- others
|--- utility
The main advantage of this grouping is that tasks, clients and suppliers are 3 different, independent software sectors. When the developer needs to make a change in the, let's say, client sectors, she has everything she needs in a small part of the file system (or in the project explorer tab in an IDE, like Eclipse). Viceversa, in the first mapping, the clients software sector is scrambled all over in the project repository.
While this may not be a big deal, if "awesome" project starts to get really big, with a lot of artifacts and so on, finding all the related parts of clients sectors start to be annoying (not impossible, IDEs offer searches for this purpose).
I'd say the second structure is much better, developer wise.
However, It's seems difficult to implement this strategy in maven: the main difficulty is to where to put the different build configurations for each artifacts (e.g., *-ui needs to be built in a different way of *-model).
One may be tempted to put such configurations in client-ui, client-logic, client-model, but this would mean duplicate configuration build everywhere (e.g, client-ui, supplier-ui, task-ui has the same build configuration): if a build configuration needs to be changed, you need to change all the other copies;
Another solution might be to declare plugins management in awesome-root and them write the plugin definition in each artifactId: while this seems better, it still suffer from the same duplication problem of option 1;
Use archetype to generate poms with the correct build configuration: same as above;
Profiles: profiles are not inherited and they depend only on system properties, not maven's one;
My questions are:
Is the second structure impossible to achieve in Maven? Is there a way?
If not, do I need to bite the bullet and set on the first structure?
Is there any alternative? (I'm trying not to propose a XY problem, any alternative is appreciated);
Additional information:
OS: Ubuntu 18.04.3 (bionic), 64 bit
java version: openjdk 11.0.4 2019-07-16
IDE: Eclipse 4.10.0
m2e plugin: 1.10.0.20181127-2120
Thanks for any kind reply
I'm interested in embedding a Prolog interpreter in Java. One option is using JPL, but the download links on the JPL site are broken, and the installation page mentions a jpl.zip that I can't find. I downloaded SWI-Prolog which seems to include JPL (it lists it as a component when installing), but I'm still not sure how I'd use it along with Java.
Any ideas on how to use JPL on Windows? Is there another library I could use to achieve the same thing? I've come across a few but they don't seem as stable as JPL.
JPL is no longer an additional download, so you don't need jpl.zip. If you download SWI-Prolog, it will install the necessary files. In comparison to the structure of jpl.zip shown in the installation notes, you'll find it now looks like this:
C:\Program Files\Prolog\
+--- doc\packages\examples\jpl
| +--- Exceptions
| +--- Exceptions2
| +--- Family
| +--- Test
| +--- Test2
| +--- Time
| +--- Zahed
| +--- (and maybe more...)
|
+--- bin\jpl.dll (a native library - for Windows in this case)
|
+--- lib\jpl.jar (a Java library)
|
+--- library\jpl.pl (a Prolog library)
|
+--- doc\packages\jpl\index.html (JPL's documentation "home page")