I have used SBT to build a pure-java project. This project consists of multiple modules, and projectB depends on projectA.
Now after switching to JDK 11, this dependency should be modeled not via classpath but via module path.
Is it possible to tell SBT that module depencencies must be resolved via module path instead of the classpath?
Basically I have set up a inter-(sbt-)module depencencs that says projB.dependsOn(projA) - so can I tell SBT somehow to put this depencency on the javac module-path instead of using the classpath? I see currently no way of doing that.
EDIT: Further analysis showed that I needed also to use normal library depencencies (from libraries on a nexus repository) as module depencencies. So the next question would be - how can I treat these library depencencies as module depencencies in SBT?
I do know that SBT is a scala build tool, and that it is something of a stretch to use it for a java-only project, but I use SBT for other (scala-)projects, and I do not want to introduce too many different build tools, until I really have to. So - is there a sbt-level solution for this?
EDIT: To clarify the issue - the project in question is a kind of open-source library which we modified. The SBT build file is from our organization, so I have to maintain it.
The project switched to using module-info classes, and it depends on other (binary-only) libraries via module path, if you include module-info.java in the compilation, that is.
So in our SBT build I have to use the module path for some of the external library depencencies.
Also the SBT-subprojects have dependencies on each other, i.e. we also have to use the module path for that.
Is there a way to tell SBT that:
This library must be on the module path, and not on the classpath
This project dependency must be on the module path, and not via classpath?
That is the core of the question. I may be able to write a plugin for the first problem (having not libraryDepencencies, but modularLibraryDepencencies for example) - but I do not yet know how I could handle the second part (tell a project that project depencencies must be on the module path and not on the class path).
Related
I want to create a library in JAVA with all its dependencies contained in it so that the versions of the dependencies do not conflict with the versions that may be available in the environment in which the library will be used. I have explored the concept of a module in JAVA. I was also able to create a module using Maven in Eclipse. Now I am not sure how to create a JAR out of it. Or is there any alternative to a modular jar for such a library. ( P.S. I am very new to JAVA)
If I understand you correctly it is not a module you would like to do, but rather a distribution with all jar files included.
To fix this you could do a fat jar with Maven.
I have an application that has both JPMS modules and old fashioned non modular jar files. I don't want to put all of the jars on the classpath because then I loose some specific functionality baked into the modules (such as JPMS service provider interface). I also can't put the old fashioned jars on the module path as automatic modules because they have many package name conflicts.
The solution is to use both the module path and classpath at once. I could define the contents of my classpath and module path manually but this is liable to breaking if a dependency changes with a new version. As such this really needs to be done automatically and I have seen that this is actually done with maven-surefire when running unit tests as well as eclipse when launching the application from the IDE.
Does anyone know if there is a an existing library (or preferably maven plugin) that allows me to separate the dependencies that can be on the module path and the dependencies that have to be on the classpath in the same way that surefire or eclipse does?
My application use ViewPageIndicator, HoloEverywhere, ActionBarSherlock, and all it uses android-support-v4.jar library. But when I include this library into /libs folder of each module, it causes build error:
com.android.sdklib.build.DuplicateFileException:
Duplicate files at the same path inside the APK
at com.android.sdklib.build.ApkBuilder$JavaAndNativeResourceFilter.checkEntry(ApkBuilder.java:125)
...
If I remove these libraries from any module, build failed in this module, because can not find library classes.
How to fix it and build the project?
Do you need the modules to build on their own, or do you just need your application to build? Assuming it's the latter, what happens if you include the jar in only your project? Eclipse may not like this since there will be errors in the workspace, but at least with command-line Ant, you can just reference a library project without building it ahead of time and your app should compile, since it will pull in all the classes/resources and build everything at once.
I.e., suppose:
projectA references libraryProjectB
projectA depends on libFoo
libraryProjectB depends on libFoo
Then try:
put libFoo in projectA
build projectA only
Not positive this will solve your problem, but I encountered a similar situation with shared C/C++ libraries and leaving them only in the library project solved my own issue, so hopefully this is helpful.
I have a Netbeans Java Project under Subversion (svn). This is shared with another guy working on the project.
The project requires an external library that we have as a jar file. Now, when either of us makes a change and commits it, the project's library dependencies fail as we have different paths for the library ( as we are working on different machines the location of the jar file is different ).
This means that every time I update my repository, I have to resolve library dependencies.
Is there a way I can prevent this?
1st way: You can use NetBeans Library support.
Go to Tools->Libraries, and new Library with your jar. Name it the same way on both machines and include to your NB project as Library rather then direct path to jar.
2nd way: use relative path.
Agree on having jar located at ../lib/foo.jar and use this path in NB project
3rd way: use property file.
Add file named, for example, build.properties but don't commit it to svn. So both of you will have different local version of that file.
Content should be something like next:
myproject.library.foojar=C:/foopath/foo.jar
In your build.xml include this file:
<property file="../build.properties"/>
In your nbproject/project.properties find a reference to the jar -- it will look like:
file.reference.foo.jar=C:/foopath/foo.jar
change it to
file.reference.foo.jar=${myproject.library.foojar}
Also you may want to add build.properties into ignore list for svn to avoid commiting it.
I recommend you to use Maven to control library dependencies(jars). It is easy to use and NetBeans has a module to use it easily.
Maven download all the dependencies you declared into a local repertory so you don't need to worried about managing libraries, Maven do it for you.
Also with this module you can search libraries in the Maven repertory(Has a lot of java librarys) only you need to type the name and maven download it for you.
Here there are some links for how to use Maven With NetBeans:
http://platform.netbeans.org/tutorials/nbm-maven-quickstart.html
http://today.java.net/article/2009/10/14/working-maven-netbeans-671
My project requires some external libraries to build in in Eclipse. They live in /trunk/lib whereas my project is in /trunk/projectA. To get Eclipse to find the libraries on all machines we set a variable PROJECT_A_HOME.
Now I'm trying to get some builds going with maven and I can not figure out how to add that path (be it environmental variable or relative to $(basedir)) to the build. I really do not want to set up a repository for these dependencies, as I keep them in source control and want builds to continue to work in Eclipse.
I've seen talk about but that hasn't worked for me.
Ideas ?
You should put your static configuration files in resources/ dir. If you have your own or proprietary jars you should set a your own repository so you can download them from the repository or better yet just install them manually , here is how
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
Setting up a file-based repository as suggested in this previous question would allow to keep the libs in your version control system and work seamlessly at the Eclipse level (the libs would be treated like any other dependency). The only problem I can think of could be at the continuous integration level: a build of projectA would require a checkout of trunk/lib. Many CI tools would allow to implement this though. And if not, moving the libs under projectA (or another mavenized project project if you need to share them between modules) would do the trick.