I've created a maven project in eclipse without specifying the settings.xml and it works just fine. Why do we need settings.xml? To create a cache of downloaded dependency jars or something?
You can overwrite and define some maven settings relevant to your build environment. This especially includes proxy mirrors, default repositories, refresh settings and credentials for servers. Typically you should be able to use maven without any settings (as least if you have an unrestricted internet connection and dont want to use private servers).
Details: https://maven.apache.org/settings.html
Some settings (repositories) can also be specified inside the POM. The reason why this is specified in a external settings file is two-fold. On the one hand they might be specific to your machine/network or you want to keep it secret (passwords).
And on the other hand they also might affect plugins or functions running with no pom or before the pom is resolved.
Generally speaking settings.xml contain unshared stuff which you do not want to check-in or publish.
Related
To keep artifacts separate, origin of packages differentiated and my development environments clean; I use separate settings.xml files for groups of projects. So and I invoke maven with command as:
mvn -s $PROJECT_ROOT/mvn_settings.xml compile
How can I configure sbt in a similar way? My workplace provides an internally hosted JFrog repository which has sbt and Ivy plugins enabled. I have tried looking up search engine with various keyword but couldn't find matching documentation.
I use IntelliJ Idea CE with Scala plugin, if this is relevant.
Edit 1: I want to be able to control where my artifacts are stored, their origin and their association with individual projects.
Edit 2: Consider two settings.xml's
For my random project with minimal libs from maven central: https://pastebin.com/nLc1PGa3
My company's projects in one big bin: https://pastebin.com/R6a4jGQC All from separate sources, in their own respective folders. Also I can move my projects independently, not worrying which dependency link might break something else unrelated.
First grouping things by settings.xml in Maven is not the best way to go. Better is to use the repository manager which can have routes to the particular repositories and to separate repositories and their specific intention. (I'm using a single settings.xml for years which has not been changed. Only the configuration in my repository manager is handling that; This makes life easier and also on CI systems).
Based on the docs of sbt you can configure the proxy repositories like this in the ~/.sbt/repositories file:
[repositories]
local
my-ivy-proxy-releases: http://repo.company.com/ivy-releases/, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
my-maven-proxy-releases: http://repo.company.com/maven-releases/
Though anytime later or soon I would suggest the same practice as by #khmarbaise to be followed in any of the projects that you are building.
Since there seems to be no point of keeping different folders for repositories if they are from the same group and artifact or even if they are different with maven/sbt providing the support to build different projects using differently specified dependencies.
Similar to maven there can be a Build Settings Concatenation for build.sbt which would work as -
They are appended in this order:
Settings from Build.settings and Project.settings in your .scala files.
Your user-global settings; for example in ~/.sbt/build.sbt you can define settings affecting all your projects.
Settings injected by plugins, see using plugins coming up next.
Settings from .sbt files in the project.
Build definition projects (i.e. projects inside project) have settings from global plugins (~/.sbt/plugins) added. Using plugins
explains this more. Later settings override earlier ones. The entire
list of settings forms the build definition.
So you can override your global build.sbt to specify the repository path using
"Local Maven" at Path.userHome.asFile.toURI.toURL + ".m2/repository"
You should be able to use a Configuration object to do this.
For example in an .sbt file:
val MyConfig = Configurations.config("my-config").extend(Compile)
(resolvers in MyConfig) := Seq(???)
Then when you use the sbt shell you can call
my-config/compile
And it will use the settings you've declared only for that scope.
Then you can declare as many configurations as needed.
I think you are looking for publishing artifacts to your company's internal JFrog repository.
The relevant JFrog documentation can be found here - https://www.jfrog.com/confluence/display/RTF/SBT+Repositories#SBTRepositories-DeployingArtifacts
I was looking at sbt command line help and I found I can set path to local ivy repository using -ivy option.
We have some Maven modules shared between several teams, with the mandate to share the source code even though our projects use different dependencies and resources. To accomplish this, we have our modules set up as recommended in Using Maven When You Can't Use the Conventions under "Producing Multiple Unique JARs from a Single Source Directory." Specifically, we have a shared parent module containing the src directory but whose pom declares <packaging>pom</packaging> and only builds the two submodules. Each submodule inherits from this parent and refers to the shared src directory using this:
<build>
<sourceDirectory>../src/main/java</sourceDirectory>
</build>
The two submodules have different artifact ids, allowing dependent modules and projects to specify which version and dependency set they need. It also upholds the Maven principle of "one module, one output."
This all works great in Maven-land: compilation, installation, deployments, etc. What doesn't work well is Eclipse integration. Some things work fine: building the modules, deploying to our Maven repo, pulling in dependencies to build our project. But things such as code completion and jumping to class/method definitions do not work at all. It's as though Eclipse doesn't recognize the source at all.
If we just check out a module from SVN, Eclipse doesn't know about the classes but instead uses jars from the repo. If we then import the modules as Maven modules, they show up in package explorer and the project build path. However, all references to those classes and methods are now flagged as errors by Eclipse. And we still do not have code completion or navigation.
So my questions are these: How can we get Eclipse to recognize the code and do its normal code navigation while still satisfying our varying project requirements? Am I missing some simple Eclipse configuration? Do we need to rework our Maven module structure, and if so, how?
Some additional context: The different dependencies for the projects are rather large, including different major versions for things such as Weblogic and Spring. The Weblogic versions will converge some time next year, but the other dependencies will be slower (and some resource files will likely always remain distinct). So for the near- to mid-future, we have to account for different dependencies between the projects.
We are using profiles to allow our Jenkins server to build both submodules while allowing individual developers to build only the submodule their project needs. Using profiles to manage the dependencies is problematic because we lose transitivity of dependencies.
Update (12/8/15)
I was eventually able to make Eclipse recognize the source directory by using "Link Source..." on the "Configure Build Path..." dialog. Adding a source folder would not let me reference the module's parent directory, but Link Source let me assign an arbitrary directory to use. It's not ideal, but it seems to be working.
I was eventually able to make Eclipse recognize the source directory by using "Link Source..." on the "Configure Build Path..." dialog. Adding a source folder would not let me reference the module's parent directory, which derailed me for a while. However,Link Source let me assign an arbitrary directory to use.
It's not ideal, but it seems to be working. We can now jump to definitions with F3, and errors are now highlighted correctly. It's good enough that I don't feel bad recommending it to the other team. I wish Eclipse would automatically allow a parent source directory to be referenced, but at least the manual intervention worked right.
Hello!
My question is related to eclipse and maven integration, maven repositories and global index update from central mirror.
The quiz is:
Let's supose that I don't have specified any special mirror, nor
{maveninstallationfolder}\conf\settings.xml
neither
{user-home}.m2\settings.xml
So then, why or how eclipse 'maven repositories' tab decides to fetch central at
repo.maven.apache.org/maven2
or
repo1.maven.org/maven2
?
Which settings.xml is reloading eclipse when I click on 'reload settings' button?
I ask this because I have two different eclipse installations ('indigo' at work, 'juno' at home).
At home when I click on 'update index' it works ok. It updates it from central mirror repo.maven.apache.org
At work, doing the same operation it always fails trying to update it from repo1.maven.org (I don't know neither I care if because of firewall or proxy issues)
I would like to know how to change it and force it to fetch it from one or another.
I attach a picture to clarify
thanks in advance
If you have a preferred central repo or if you are using a company maven proxy (like nexus or artifactory) you can set it in the user settings.xml. You may have to create this file. This is normally in ~/.m2 on linux or c:\Users\YourUser\.m2 on Win7 or c:\Documents and Settings\YourUser\.m2 on WinXP (IIRC). Note that this is the same place as your local repostitory base folder.
When I create a new settings.xml on a machine that doesn't have one, I go to the maven2 documentations web pages, find the sample settings.xml that is there and copy it to a new file I create.
There is a global settings.xml in $M2_HOME\conf but it usually isn't changed from the default. It does document all the sections you can add to your settings.xml since both have the same sections. (If you are using the embedded version of maven in something like MyEclipse or the maven eclipse plugin, I don't know where they put it.)
For another question, if you need to configure Maven to use a corporate proxy to get out of the company network to maven central, you can put that information in your user settings.xml file--the same one you create to set the URL to use.
You may have different versions of Maven running on the two machines. That would explain the different names for central. But the two names both point to the same place.
When sharing a project with team members through version control, it is customary to include the .project in the source under version control. This makes sure that others on the team get all the dependencies and resources for the project. But the .project uses full/rooted paths to the resource, and not all members of a team will be working in the same environment. Even if all the members are on the same platform, the paths can often be in the user's home directory.
For the .classpath file, we can get around this problem by using build path variables. Each member defines the path to location of dependent libraries on their system, and the .classpath only refers to the variable.
This is a particular concern for Grails project - when we add a plugin, it updates the .project accordingly.
IMO resources themselves should not be part of the project at all. There is excellent plugin called m2eclipse which simplifies such tasks using Maven. It will immensely simplify your dependency management. All you'd have to keep in your version control system, besides your source code, is project configuration (pom.xml) - all the dependencies will be downloaded and cached automatically no matter what environment developer works in. There a lot more advantages in this approach - just read up on it :)
UPDATE: Just noticed "grails" tag on your question. if you're using Groovy - Maven can be replaced with Gradle. STS is probably the best Eclipse build to use if you're coding in Groovy. Next version of STS will have Gradle support.
General Approach
As others have mentioned, you should not keep the IDE files in VCS, you should keep an IDE-agnostic description of the project in VCS and generate the IDE-specific project files from them.
Java-Maven Example
Keep the pom.xml file(s) in VCS and generate the Eclipse files by running mvn eclipse:eclipse
Grails Example
A Grails project is described by application.properties and grails-app/conf/BuildConfig.groovy. These files are present in every Grails application. You can generate the Eclipse project descriptions from them by running:
grails integrate-with --eclipse
This command also supports other tools such as IntelliJ and Textmate
I don't think its standard practice to include the project file. I personally tell my VCS to ignore all IDE files, and just use VCS for the source. I include at the root level a README telling others how to configure the project (e.g. jars are in lib)
The resource links feature that you are referring to also has ability to use path variables. These are defined under Preferences -> General -> Workspace -> Linked Resources.
You could try keeping the project files in a shared Dropbox with an agreed upon path for each developer.
I have a Java web app that offloads some environment specific settings (Hibernate configurations, required directory paths, etc.) in a properties file that is ultimately packaged in the deployed WAR. If I wish to distribute this web app, what's the best way to handle the mangement of these settings? It's not feasible to ask the user to open up the WAR, update the properties file, repackage the WAR, and then deploy. I was thinking of either creating an installer (e.g. NSIS, WiX) that asks for the properties, writes them in the WAR, and then asks for the deployment location for the WAR. The other option is to have the properties file external to the WAR, and based on convention the web app will know where to read the file. What's the best practice in this case?
Some projects that require this sort of configuration, and face this issue, use the approach of building the projects (and the .war) on the server where it will be deployed.
So instead of:
Copy a pre-packaged .war file to a meaningful location
You get:
Check source code out of SCM (Subversion, CVS, etc.)
Configure to taste
Build the project (automated with Maven or Ant)
Deploy the project (also typically automated using Maven or Ant)
From here you can get fancy by checking each server's configuration files into SCM as well. This approach allows you to version & audit configuration changes.
I was also facing the same problem in the project. The developer before me had done crude fix for the solution which was adding all the required configuration in the hibernate.hbm.cfg.xml file and commenting them. The required configurations were uncommented as per the need. There is a better solution to problem however.
Use a configuration folder schema
Using configuration Parameter Reader
Use of ConfigurationReader component
Source : http://www.javaworld.com/javaworld/jw-11-2004/jw-1108-config.html