How can I use jars that buildr loads by default into the local maven repo, rather than creating new (and repetitive) artifact tasks/dependencies?
For example, if were creating a scala or groovy application buildr would automatically download the scala or groovy jars respectively. Is it possible to include or merge these (default) jars into an application rather than creating a new artifact?
I think that is not possible or doable in a one step, easy way. I recommend you talk with us on the dev list of Buildr and we can probably create an enhancement for that.
For each library you would like to depend on, you usual can grep the code to find where we define the default jar we depend on.
For the example you mention, here are the default method to retrieve the default jars:
For Groovy: Buildr::Groovy::Groovyc.dependencies
For Scala: Buildr::Scala::Scalac.dependencies
I hope that helps.
Related
I have a spring boot application with maven.
I need to use an external jar say "tp.jar". I have used the method of system scope to do the same but seems it has been deprecated. Is there any better alternative which doesn't involve running maven commands to do the same. I found some solutions here Can I add jars to maven 2 build classpath without installing them?
But the posts are pretty old was wondering if any new solution and convenient solution has been found.
If you are in a company doing Java, you probably have a Nexus or Artifactory server running. This is the place to put the jar. Then you can use all Maven mechanisms to use it.
I'm creating a library having sub-modules for internal purposes. In one of those sub-module, I am using a spring based dependency. In order to allow the library's client using different spring versions to use the library, I was thinking to provide 2 different versions of the same code with different dependency version compiled (one for Spring 1 and another for Spring 2) and publish the same to mavenLocal.
What is the best way to achieve this (or is there a better way to achieve this for the clients) ? I don't want to maintain another module with same code and just a different dependency version.
Is it good to have different versions of a dependency in the same project that will be used for creating multiple artifacts?
If it is ok to do that, how do I create artifacts with different versions and publish them to mavenLocal corresponding to each versioned artifact? (if you can provide the gradle script it'll be really helpful)
I am new to using gradle and it'll be really helpful if someone can guide me for this problem.
while working on spring mvc 4, how to find the jar for offline project like the jar Spring Security Config,spring-security-web for spring 4 ... etc as thet are not available with default package of jars and I do not want to use maven at this time so where one can find the jar for spring 4
?
First of all, foregoing proper dependency management is a bad idea and will make development that much harder, especially when it comes to transitive dependency resolving.
However, if you really want to do it then you can download .jars straight from Maven Repository or any other online repo that hosts them.
If that fails then a Google search will give you some source to download them from.
Trying to avoid a dependency management tool that to with a framework like Spring which complements many other frameworks is a bad idea in the long run. It will be painful to upgrade the versions in future.
But if you still don't want to use maven/gradle kind of build tool, just use pom.xml/build.gradle just for onetime use and let maven/gradle download all the dependencies and copy all those jars in some folder of your code.
Again I strongly suggest to use a build tool, especially for Spring. Maven/Gradle are not that bad if you don't want to do crazy things!!
In a large maven multimodule context,
how can I gather javadoc-comments programmatically for a specific set of classes (e.g. all classes implementing some interface) or modules ?
I have tried a stupid doclet and looked at QDox, but neither seems to do the job well.
Actually I think this should be simple if done correctly.
Specifically, I do not know how to do this in a maven-build: How can I depend on and use the src-jars?
This should be possible with QDox, as long as you have the sources. QDox-2.x can also read source-files from jars, which can be generated by the maven-source-plugin.
We are using Maven(3.0.3) as build tool and we need to have different version for different environments (DEV , TEST, QA ) . If we pass version property value during build time based on environment , the installed POM doesn't have the passed property values instead it still has the ${app-version} string.
I saw already there is a bug for this http://jira.codehaus.org/browse/MNG-2971
Is there any other alternative ,because we cannot different POM file for different environments ,which will be hard to maintain..
Thanks
Vijay
Create different artifacts for the environments and use the parameter as a classifier. The pom is the same for all three artifacts but the classifier separates them.
Apparently Maven does not make any variable/property substitution when installing the POM. It is installed as is, that is the principle. You'd better not read any properties from POM (unless this is e.g. version number), bout you should configure your properties in external file (one per stage, e.g. dev.properties, test.properties, ...) and then configure Maven profiles (again, one per stage) and invoke Maven like mvn -Pdev depending on what you want to build. In profile you can package your final application with whatever properties you like (e.g. with the help of build-helper-maven-plugin:add-resource or maven-antrun-plugin + copy rule).
Alternatively you can filter your resources. For example, you can filter your Spring context XML file, which refers the properties file (so you package all property files, but Spring will refer only some specific). Or you can filter another properties file from which you will learn what is the "main" properties file to use (double indirection).
You should create the archives for your different targets within a single build and use as already mentioned the classifier to separate those artifacts from each others.