Hi I'm reading up on Ivy for the first time and had a few quick questions:
Need confirmation: the IvyDE plugin is used to configure just the ivyconf.xml file for all workspace projects, correct?
Where does this ivyconf.xml live? I'm running Windows 7 and can't find this hidden .ivy directory anywhere!
Where do you usually place a project's ivy.xml and other xml config files?
Thanks for any nudges in the right direction!
IvyDE allow you to resolve dependencies per project. You could use separate ivyconf.xml in different projects.
You could place ivyconf.xml (or ivysettings.xml) where you want. You could use one per project (as I do) or one for all projects (as I did before).
Usually I put ivy.xml beside Ant's build.xml in the root of my project. But ivysettings.xml I put in project/etc/ivysettings/ directory.
My team uses a separate build project in Eclipse that stores the ivysettings.xml file. The IvyDE plugin provides the Ivy dependency container that the Java projects can use. IvyDE can optionally allow inter-project dependency resolution, but this is off by default.
I'd suggest changing the order of classpath entries in the Ivy Classpath configuration to lexical, otherwise it shows dependencies in the order of the ivy.xml file.
Each project should have their own ivy.xml file - we also follow the same pattern as Alexey uses of using the project's top-level directory.
I've never used an ivyconf.xml file - a quick google suggests this is an alternative (older, deprecated?) name for the ivysettings.xml file.
You will need to write your own ivysettings.xml file to tell IvyDE where your repositories are and which resolvers to use. Leave a comment if you're interested in an example ivysettings.xml file.
Which repositories are you using? Maven Central? Setting up your own repository with Nexus, Artifactory or just using the file system?
Related
I created a Maven project and imported it in Intellij IDEA.
In a run configuration, there is a field "working directory", which points to the root of Maven project.
If I change this folder, it doesn't seem to affect anything. So what is it?
This is the directory that is set as the Java user.dir system property. If you have any code that creates relative files or directories, it will be relative to this directory. So for a well designed application (i.e. resolves resources from the classpath and is configurable for output directories) this will not be a factor. There is also some importance to this value in maven projects, especially multi-module maven projects. This directory specifies the directory IDEA will read the POM from.
If you are unflamilar with what the Java user.dir is, there is some discussion available here and in the class level Javadoc for the File class.
In addition to answer given by #Javaru if you want to update or view your working directory in IntelliJ IDEA go to:
Run | Edit Configurations | Configuration Tab | Working Directory
From the IntellJ help Run/Debug Configuration: Maven
Working directory Specify the path to the Maven project file pom.xml.
I have a project that uses IVY. My build script resolves the dependencies well.
I have a library (lets call it Project_libs) configured in IntelliJ iml file so that when I deploy the application the jars get published to the server.
I have an ant task ide-setup which copies the necessary jars from Ivy local repo to Project_libs so these jars are available to IDEA during deployement.
Lets say I make changes to a common library like utils.
Build the common library.
Go to the projects that declared this common library as a dependency and run ide-setup
Then start the server.
Is there a direct way in which I can configure IDEA to read the dependencies from the ivy.xml file instead of doing this convoluted process of setting up the whole thing.
I don't know anything about InelliJ IDEA, but I believe you could accomplish what you want using ant and IVY. From the IVY documentation
<ivy:buildlist reference="build-path" ivyfilepath="ivy/ivy.xml" leaf="mymodule">
<fileset dir="projects" includes="**/build.xml"/>
</ivy:buildlist>
Builds a list of build.xml files sorted according to the ivy.xml files found in an
ivy directory relative to those build files. Only build.xml files of modules which
have dependencies (direct or transitive) on mymodule are put in the result list.
So if you set leaf equal to utils, it could return you a list of build.xml files that depend on utils in dependency order. Then all you would have to do is go through those build.xml files in order and invode their build process (probably through a subant call)
I've read the Ivy docs and a few other tutorials but am now trying to actually use it in a project for the first time and I am immediately presented with some roadblocks.
For the practice, I would like to write all my own config (XML) files. Not sure where to put ivy.xml, ivyconf.xml or ivy-settings.xml: do I put them in the same directory as my build.xml?
Besides ivy.xml, ivyconf.xml and ivy-settings.xml, are there any other config files that I should know about? Where do I place those?
Is the IvyDE just a graphical Eclipse plugin that graphically edits ivyconf.xml or does it edit other files?
Thanks for any input - it's been surprisingly difficult finding good info on this amazing tool!
You need only one file ivysettings.xml. You could place it beside build.xml or in any desired project directory. Optionally you could use one or more properties files for different uses.
Besides ivysettings.xml remeber about ivy cache directory. Often the best solution for all dependency resolution problems is to clean ivy cache by deleting this directory.
IvyDE allows you to resolve project dependencies inside Eclipse. IvyDE creates new classpath container named ivy.xml. Inside this container you'll find resolved libraries.
And I recomend you to use local or intranet ivy repository with Eclipse, because if resolving takes some time it will slow down loading of your projects.
For example I placed my ivysettings.xml that I use in my projects. As you can see for Eclipse there is eclipse-ivy.properties file. In this file I order Ivy to use local repository inside Eclipse. In Ant script I use remote repository by default, but there is an option to choose local repository.
<?xml version="1.0" encoding="UTF-8" ?>
<ivysettings>
<settings defaultResolver="${ivy.resolver}" />
<statuses default="development">
<status name="release" integration="false"/>
<status name="integration" integration="true"/>
<status name="development" integration="true"/>
</statuses>
<resolvers>
<ssh name="remote" checkconsistency="true" checkmodified="true" descriptor="required">
<ivy pattern="ssh://***/home/ivy/repository/[organisation]/[module]/[revision]/ivy.xml"/>
<artifact pattern="ssh://***/home/ivy/repository/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
</ssh>
<filesystem name="local">
<ivy pattern="${user.home}/.local-ivy-repository/[organisation]/[module]/[revision]/ivy.xml"/>
<artifact pattern="${user.home}/.local-ivy-repository/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
</filesystem>
</resolvers>
</ivysettings>
elipse-ivy.properties:
ivy.resolver=local
In general, it's best to create a single standardized ivy-settings.xml file and host it in a location where your builds can get to it easily. This file will usually be the same for all projects and rarely change once you've got it setup properly. In my development group, we host the ivy-settings.xml file on a web server so that it can easily be referenced by URL.
We build with Ant so we've also come up with a standardized ant build file which can either be hosted somewhere and imported into an Ant build script or simply copied to a project's directory if any kind of customization is necessary.
I've found that it's best to leave the Ivy configuration files as is and do any kind of customization by overriding the default values in your build scripts and/or ivy.xml files. Just about anything you'd need to change can be overridden. I recommend leaving the Ivy configuration files unchanged because it makes it much easier for other users to build your projects. If you've got a bunch of changes to your config files, any other developer wishing to build your project will have to replicate those changes on their local Ivy installs just to run a local build. That's bad mojo.
The IvyDE plugin provides editors for your ivy.xml and ivy-settings.xml files. According to the documentation, it also provides ways to automatically download your project's dependencies, includes a custom console and a reverse dependency explorer to help troubleshoot and resolve dependency conflicts. I only use the editors, though, so I can't vouch for the other tools.
Like Alexey, I'd recommend using a repository manager with Ivy. Artifactory does the job nicely; It's easy to setup and rock solid once it's running.
I agree that the documentation leaves much to be desired; it took me several weeks of experimentation to really grasp how all the pieces fit together. In the end, it was entirely worth it. Once you've got all the kinks ironed out, a well tuned artifact management system is truly something beautiful to behold.
We are planning on restructuring a complex project with many modules/pieces, what ever you wanna call it. In order to move toward a standard directory structure, we would like to adopt the maven file structure.
So the big question is: Can anybody provide a description of the maven file structure, where we don't have to dig through all the maven speak?
Please see
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
src/main/java Application/Library sources
src/main/resources Application/Library resources
src/main/filters Resource filter files
src/main/assembly Assembly descriptors
src/main/config Configuration files
src/main/webapp Web application sources
src/test/java Test sources
src/test/resources Test resources
src/test/filters Test resource filter files
src/site Site
LICENSE.txt Project's license
README.txt Project's readme
BTW, we did that migration on existing projects.
It was a really long and hard task to make everything work as intended, but we are finally done and happy with it.
UPDATED
When you have many projects, you have the same structure for each project.
Now the real problem starts when you want to group them. We had a hard time reading Maven documentation and best-practices, and deciding what was the appropriate structure for us.
The basic idea would be to group related projects in a common directory (that we call a module), allowing to process the module as a whole without listing them. But if you open the module in an IDE (Eclipse in our case), the projects themselves belong to it, but are not opened as subprojects (that notion doesn't exist in Eclipse).
We ended up with a strict hierarchy, that freed us from many maven problems:
The actual coding projects (java projects) are always leaf in our directory tree. They are the only ones we open in the IDE. They are of type JAR, or WAR.
Their parents/modules are always of type POM. They have no java code.
I've been using the same approach as Jens on a number of projects both with Maven 2.2.1 and now with Maven 3.0-alpha-6: POM modules define the module structure of your project tree, JAR/WAR modules are the leaves of the tree. All modules have the same version.
Advantages:
You can
place properties or dependencies on
specific levels in the module
hierarchy and they will be inherited
to all sub-modules.
You can build
related modules simply by going to
the appropriate level in the tree and
running "mvn install" - Maven will
work out the correct build order
according.
Various Maven plugins such
as the release plugin rely on this
tree structure.
The latest Maven
Eclipse plugin can handle this
structure very well and will
represent the tree as a flat list.
There is an experimental feature in
the plugin which ensures that
so-called "shadowed" artifacts appear
only once which helps when searching
for resources in Eclipse.
Disadvantages:
Extension takes some time. For instance, if you decide that a JAR module requires sub-modules, you will need to convert the existing JAR module into a POM module and then distribute its contents to the newly created JAR sub-modules as POM modules cannot contain any code themselves.
All the POM modules will appear in Eclipse and can slow down the build somewhat. Hoever, you can close them and Eclipse will source them from the repository instead.
Hi i am studying Spring In Action 2.0 and i am new to maven.
I am walking through the chapters and codes but i i got following error when i imported project through pom.xml on the pom editor in eclipse.
6/21/09 3:19:42 AM CDT: Missing
indirectly referenced artifact
incubator-activemq:activeio-core:jar:3.0-beta3:compile
6/21/09 3:19:42 AM CDT: Missing
indirectly referenced artifact
incubator-activemq:activemq-core:jar:4.0:compile
I downloaded the jar file and added to the library. still it does not work.
I am stuck what to do next? Can anyone help me with this?
Thanks in advance.
The referenced jars aren't available on the Maven2 central repository, so unless you have an additional repository declaration in your POM or an active profile in your settings, Maven will not know where to obtain the artifacts from.
There are a few public repositories like here and here hosting these artifacts.
To use these repositories you could add the relevant repository declaration to your POM or settings. See here for an example configuration.
Alternatively if you don't trust the repositories you could manually download the jars and put them into your local Maven repository, though you'd need to be careful to replicate the structure Maven expects, and you may well encounter the same problem for different jars.
Another alternative is to use a Maven repository manager like Nexus or Artifactory, to manage Maven's interactions with external repositories, though that is almost certainly too much information if you're just starting out.
For general help/information on Maven, check out the Maven book.