I have a huge project that is a set of about 40 subprojects. It is built with an Ant script.
In each subproject I have some library dependencies, split in a set of folders (lets say: 'lib1', 'lib2', and so on).
It's a huge problem mantaining these libraries.
So, my team decided to move on a more modern built system. We decided to go on Gradle. At this moment, the only thing we will be performed with Gradle is the dependency management.
The lib sets ('lib1', 'lib2' etc) will be each of them put in different folders during the distribution phase. Some of them will not be distributed (are used on for compiling).
The structure so far is like this:
Root project
|- settings.gradle
|- project1
| |- build.gradle
|- project2
| |- build.gradle
...
The root project only includes the subprojects by include ':project1' and so on.
We have now two main challenges:
Download the projects dependencies in different folders depending on the dependency type and check if there are dependencies conflicts.
We presume (but not sure) that we will have to declare some configurations, like:
configurations{
lib1
lib2
compile.extendsFrom(lib1, lib2)
}
Just to be clear, I'd like to download each lib set in a folder like dist/lib1. The Ant script will continue to gather these libs and copying them in to the dest folder.
So, the following questions that remain:
How to declare the dependencies configurations (The above format doesn't seem to work, since compileJava does not include them (although compile configuration extends from them)).
How to download the dependencies in a given folder.
How to check dependencies from all subprojects at once.
Edit: I just found this question which answered questions number 1 and 2. But, when I ran this task:
task copyWebinf( type: Copy ) {
into "$buildDir/libs/WEB-INF"
from configurations.webinf
}
I noticed that I have some libs that I suspect are dupicates:
-rw-rw-r-- 1 thiago thiago 93395 Nov 7 18:00 xpp3-1.1.3.3.jar
-rw-rw-r-- 1 thiago thiago 24956 Nov 7 18:00 xpp3_min-1.1.4c.jar
and
-rw-rw-r-- 1 thiago thiago 246867 Nov 7 18:00 xstream-1.1.2.jar
-rw-rw-r-- 1 thiago thiago 411090 Nov 7 18:00 xstream-1.3.jar
These duplicates might be related to my question number 3 (dependency check).
Related
I've been using dependabots with github with some degree of success on typical maven projets, as it sends correct pull requests updating the versions of the dependencies in the pom.xml.
On an Eclipse plugin project however, the dependencies and their versions are also listed in 2 other files MANIFEST.MF and in build.properties.
Example build.properties :
bin.includes = META-INF/,\
.,\
plugin.xml,\
lib/,\
plugin.properties,\
lib/nexus-indexer-lucene-model-2.14.20-02.jar,\
lib/jaxb-api-2.3.1.jar,\
lib/activation-1.1.1.jar,\
lib/jaxb-impl-2.3.3.jar,\
lib/jaxb-runtime-2.3.3.jar
Example MANIFEST.MF :
Bundle-ClassPath: lib/cvsclient-20060125.jar,
lib/maven-scm-api-1.9.4.jar,
lib/maven-scm-provider-accurev-1.9.4.jar,
lib/maven-scm-provider-bazaar-1.9.4.jar,
lib/maven-scm-provider-clearcase-1.9.4.jar,
lib/maven-scm-provider-cvs-commons-1.9.4.jar,
lib/maven-scm-provider-cvsexe-1.9.4.jar,
lib/maven-scm-provider-cvsjava-1.9.4.jar,
lib/maven-scm-provider-git-commons-1.9.4.jar,
lib/maven-scm-provider-gitexe-1.9.4.jar,
lib/maven-scm-provider-hg-1.9.4.jar,
lib/maven-scm-provider-integrity-1.9.4.jar,
lib/maven-scm-provider-jazz-1.9.4.jar,
lib/maven-scm-provider-local-1.9.4.jar,
lib/maven-scm-provider-perforce-1.9.4.jar,
lib/maven-scm-provider-starteam-1.9.4.jar,
lib/maven-scm-provider-svn-commons-1.9.4.jar,
lib/maven-scm-provider-svnexe-1.9.4.jar,
lib/maven-scm-provider-synergy-1.9.4.jar,
lib/maven-scm-provider-tfs-1.9.4.jar,
lib/maven-scm-provider-vss-1.9.4.jar,
lib/plexus-utils-3.0.16.jar,
lib/nexus-indexer-lucene-model-2.14.20-02.jar,
lib/nexus-restlet1x-model-2.9.2-01.jar,
lib/maven-scm-provider-jgit-1.9.4.jar,
lib/jaxb-api-2.3.1.jar,
lib/jaxb-impl-2.3.3.jar,
lib/jaxb-runtime-2.3.3.jar,
lib/activation-1.1.1.jar,
.
I use a minimalist dependabots.yml suited for maven :
# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates
version: 2
updates:
- package-ecosystem: "maven" # See documentation for possible values
directory: "/" # Location of package manifests
schedule:
interval: "daily"
Dependabots sent a pull request "Bump nexus-indexer-lucene-model from 2.14.20-02 to 2.15.1-02" but the pull request only updates the version in the POM, which makes the build fail, because the other files MANIFEST.MF and build.properties were not updated.
How do I get depandabots to update these 2 files MANIFEST.MF and build.properties ?
I've got a spring boot application build as multi-modular gradle project (old-style, not fancy jigsaw)
What I want to achieve - is replace java platform loggers (e.g., SSlLogger/ System.getLogger) with sl4j & logback that are used in my app and are managed by spring-boot-admin server at runtime. I need all my loggers to write to file instead of console - or else I won't see logs in Logz.io.
I do not control how my app is deployed, but I control the way fat jar is built (so, manuals with terminal commands 'java - ...' are not very helpful :( )
I started to follow https://www.baeldung.com/java-9-logging-api guide, but got stuck.
for simplicity, my structure is ->
build.gradle
/application-module
build.gradle (combines 3 other modules)
/src /...
/rest-module
build.gradle
/src /...
/service-module
build.gradle
/src /...
/persistency-module
build.gradle
/src /...
So, I want to add one more module
/log-module
/src -> with actual classes
module-info.java
Slf4jLogger implements System.Logger
Slf4jLoggerFinder extends System.LoggerFinder
and include it into my application-module
but when trying to build it all, I get 'error: module not found: org.slf4j', and app is not build.
So, what am I doing wrong? What additional plugins/config do I need? And will it even allow me to achieve my goal?
Okay, I managed to find the solution. It's a combination of
https://www.baeldung.com/java-9-logging-api
https://www.baeldung.com/java-spi
So, I don't even needed jigsaw modules - only the JDK's service provider mechanism
So, in fact you need 3 files [these are id's of pastebin's samples; but they are almost the same as in the java-9-logging-api article]
AkXY3zgu -> adapter class
YFUkZwat -> logger provider
CD6NNibj -> meta-inf file - and that's the trickiest part (with file name :) )
file name -> META_INF/services/java.lang.System$LoggerFinder
com.my-projects.commons.logs.Slf4jLoggerFinder
An now on regular app startup system logger will be replaced with slf4j-adapter.
But still, check how system logger is created -> for example, I mostly need SSLLogger, and there is some system-prop-based logic there...
I started working with Maven and I am not sure how to handle the package-hierarchy.
Lets say I have a project-topic "MyPrj" that has 2 programms "ProgA" and "ProgB" (both with their own main) and both use classes together (e.g. "Both").
3 packages:
MyPrj.ProgA
MyPrj.ProgB
MyPrj.Both
ProgA and ProgB do have differnt dependencies!
So should I create 1 Maven project with subdirs ProgA, ProgB and Both and all dependencies in 1 POM
OR
should I create 3 Maven projects and somehow reference to Both
OR
something else?
How do I compile a single module in the following scenario of two multi-module Maven projects A and B.
Both projects are located in the same directory so that the directory structure looks like this:
root
|-- A
| |-- A1
| |-- A2
| `-- A3
`-- B
|-- B1
`-- B2
All directories except root have their own pom.xml files and each submodule is referencing its parent module (A1 has parent A, etc.) and the parent is referencing its submodules (A has modules A1-A3). The problem I have is that A1 depends also on B1, since project B is a collection of utilities that I want to use in other projects.
My question is how do I reference B1 correctly so that I can build A1 without having to install B1 first. I mean I want to build A1 with all its dependencies using one maven command.
My current solution is to make B1 a module of A (via module reference ../B/B1). Then I can call mvn package from directory A and it works fine. But building the whole project A is sometimes very time consuming. Therefore I would like to build only A1 + deps. How can I do that? When I call mvn reactor:make -Dmake.folders=A1 from directory A I get the following build error:
Reason: Cannot find parent: B:B for project: B:B1:jar:1.0-SNAPSHOT for project B:B1:jar:1.0-SNAPSHOT
So it seems that maven suddenly cannot find B1's parent module anymore when using the reactor plugin. Does anybody know a solution for that or an alternative approach for referencing a submodule from another project that allows building A1 in the way described above?
Note, I don't want to set up a super module in root that includes modules A and B, because this pom file, because every user that checks out A and B might have also other projects in his root directory and therefore would have to write his own pom file for root.
Simple create a root pom which has modules in there and do referencing the parent in A and B then it would work. Otherwise it does not work.
The files residing in .settings in a Dynamic Web Project are:
.settings/
|-- org.eclipse.jdt.core.prefs
|-- org.eclipse.jst.common.project.facet.core.prefs
|-- org.eclipse.jst.j2ee.ejb.annotations.xdoclet.prefs
|-- org.eclipse.wst.common.component
|-- org.eclipse.wst.common.project.facet.core.xml
|-- org.eclipse.wst.jsdt.ui.superType.container
|-- org.eclipse.wst.jsdt.ui.superType.name
`-- org.eclipse.wst.validation.prefs
The above file list is pretty much a clean new Dynamic Web Project, except that I'm using the IvyDE plug in, but I think it only affects the .classpath file.
How do I learn more about these files? I'm wondering if I can get rid of any of them without loosing something important? Finding this information at Eclipse.org was not very easy, a link or an explanation would be very welcome.
I'm trying to learn more about these files as I want to slim down the Eclipse files as much as possible before I check them into version control.
In case it helps I list the above files and their contents:
org.eclipse.jdt.core.prefs:
#Mon Jan 26 03:01:22 CET 2009
eclipse.preferences.version=1
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
org.eclipse.jdt.core.compiler.compliance=1.5
org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
org.eclipse.jdt.core.compiler.source=1.5
org.eclipse.jst.common.project.facet.core.prefs:
#Mon Jan 26 03:01:22 CET 2009
classpath.helper/org.eclipse.jdt.launching.JRE_CONTAINER\:\:org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType\:\:java-6-sun-1.6.0.07/owners=jst.java\:5.0
eclipse.preferences.version=1
org.eclipse.jst.j2ee.ejb.annotations.xdoclet.prefs:
#Mon Jan 26 03:23:25 CET 2009
XDOCLETBUILDERACTIVE=false
XDOCLETHOME=
XDOCLETUSEGLOBAL=false
XDOCLETVERSION=1.2.1
eclipse.preferences.version=1
org.eclipse.wst.common.component:
<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
<wb-module deploy-name="webcookie">
<wb-resource deploy-path="/" source-path="/src/main/webapp"/>
<wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
<wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/>
<wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/resources"/>
<property name="context-root" value="webcookie"/>
<property name="java-output-path"/>
</wb-module>
</project-modules>
org.eclipse.wst.common.project.facet.core.xml:
<?xml version="1.0" encoding="UTF-8"?>
<faceted-project>
<fixed facet="jst.java"/>
<fixed facet="jst.web"/>
<installed facet="jst.java" version="5.0"/>
<installed facet="jst.web" version="2.5"/>
</faceted-project>
org.eclipse.wst.jsdt.ui.superType.container:
org.eclipse.wst.jsdt.l
org.eclipse.wst.validation.prefs:
#Mon Jan 26 03:31:54 CET 2009
DELEGATES_PREFERENCE=delegateValidatorList
USER_BUILD_PREFERENCE=enabledBuildValidatorListorg.eclipse.jst.j2ee.internal.classpathdep.ClasspathDependencyValidator;org.eclipse.wst.common.componentcore.internal.ModuleCoreValidator;org.eclipse.wst.wsi.ui.internal.WSIMessageValidator;
USER_MANUAL_PREFERENCE=enaunching.baseBrowserLibrary
org.eclipse.wst.jsdt.ui.superType.name:
Window
org.eclipse.wst.validation.prefs:
#Mon Jan 26 03:31:54 CET 2009
DELEGATES_PREFERENCE=delegateValidatorList
USER_BUILD_PREFERENCE=enabledBuildValidatorListorg.eclipse.jst.j2ee.internal.classpathdep.ClasspathDependencyValidator;org.eclipse.wst.common.componentcore.internal.ModuleCoreValidator;org.eclipse.wst.wsi.ui.internal.WSIMessageValidator;
USER_MANUAL_PREFERENCE=enabledManualValidatorListorg.eclipse.jst.j2ee.internal.classpathdep.ClasspathDependencyValidator;org.eclipse.wst.common.componentcore.internal.ModuleCoreValidator;org.eclipse.wst.wsi.ui.internal.WSIMessageValidator;
USER_PREFERENCE=overrideGlobalPreferencesfalse
eclipse.preferences.version=1
override=false
suspend=false
vf.version=3
Let's see:
org.eclipse.jdt.core.prefs is really important and control how you compile your java project.
org.eclipse.jst.common.project.facet.core.prefs adds a Facet, basically a way to introduce functionality to projects in Eclipse, therefore a project can have one or more facets (ie. it could be a Java project and a EJB project). See here for illustration (search the word 'Facet')
org.eclipse.jst.j2ee.ejb.annotations.xdoclet.prefs is a way to Configuring XDoclet annotation support
org.eclipse.wst.common.component is relate to the deployment structure.
org.eclipse.wst.common.project.facet.core.xml is used to Specifying target servers for J2EE projects
org.eclipse.wst.validation.prefs refers to Wst validation
org.eclipse.wst.jsdt.ui.superType.container/name as explained here, is a configuration for JSDT part:
By default, plain javascript files (.js) inherit members from object Global. HTML files contained in a static/dynamic web project inherit members from object Window.
So if your context is a plain javaScript file it will appear that only Window.window or Window.alert(..) is valid since none of the Window members are inherited. What you really want is to inherit this field + method from an instance of the Window object.
,
The JSDT supports a configurable super type at the project level. Each .js or .html file within a project inherits all the fields and methods from the projects super type. By default the type is Global for standalone JavaScript projects and Window for Static/Dynamic Web Projects.
,
You can change the super type for a project from the JavaScript Include Path properties page from Object Global to Object Window to achieve the results you desire... On the Global Order/SuperType page change the Super Type to Window in the ECMA library.
You should use and trust the "Dependencies" tab in the MANIFEST.MF. After working about a year with Eclipse plugins only i would not try to find out which eclipse plugin dependency is necessary or not.
When you miss a plugin which is needed at runtime, you get exceptions which are not very useful and solutions are not obvious.
The MANIFEST actions "Find unused dependencies" should selected every time you refactor your code. It also helps to check the classes, eclipse will create, when you generate complete new plugin from scratch. The eclipse plugins are not good documented, so i would use the actions which are offered and dont spend so many times to understand them all.
If you realy want to find out which plugins are used, when you create a plugin from scratch, you can delete some extend declarations or variables and press the "Find unused dependencies" action to see, which plugin is for a call.