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)
Related
I have a simple Hello World project in AnyPoint Studio. I have folder of additional files (a few jar files and some configuration files) I want to include with the project so they can get published to the cloud (CloudHub). How do I include these files into my project so when I publish my application the additional files are packaged with them.
Part 2 - Say I have a json file I want to read from my Mule application. What path do I reference the json file with after it is published?
Mule 4 projects are Maven based. You need to reference those jar files as Maven dependencies. You might need to install those projects in your local Maven repository. Search for Maven tutorials if needed. Ideally those JAR files are available in Maven repositories and you add only the dependency snippet in your pom.xml. If you are building yourself you can use mvn install command. If they are third party JAR files that you have the file only you have to use the mvn install but you need to define the coordinates (groupId, artifactId, version) yourself, which is not ideal and Maven won't be able to do automatic dependencies resolution for those JAR files. See this answer for details.
In your source project resource files should be in src/main/resources. At execution time you don't need to add a directory. If you add the file in a subdirectory of src/main/resources you need to use the subdirectory name only.
I am distributing a Java package via git for other people to use. I am currently supplying a jar file to go with the source. This way, the user only needs to clone the project once into Intellij IDEA. Projects using the package can then follow this procedure
Correct way to add external jars (lib/*.jar) to an IntelliJ IDEA project
to use the package.
This works, but distributing a jar does not feel nice security-wise. On the other hand, this discussion
IntelliJ IDEA - adding .java file to project dependencies
suggests that to use the source code, you need to copy it into your src folder.
Is there a way to distribute source code (java files) only so that if multiple projects use the same package
the package only needs to be downloaded once
the package can be kept up to date with git pull?
I would really recommend not include jar or any binaries in a Git repo and the best approach to keep these dependencies in a local Nexus repository and use maven or Gradle as your dependency management tool.
I found a working solution:
Supply an Ant build file with the package. The build file compiles classes and packages them into a jar file. The default target is building the jar, which depends on compiling the classes.
Provide users with instructions on how to set the given Ant build file as a build file in Intellij IDEA and build the default target.
Then instruct them to follow the steps in the first link above to add the jar as a dependency.
I have a EAR -
This EAR contains multiple WAR
Inside these WAR files there is a common JAR which is getting downloaded within each WAR file.
I want to remove this common JAR file into a shared Library. Also i want the latest version of JAR file everytime i rebuild my WAR, I am using Tomcat in Dev and Websphere min production.
We are using IVY for dependency management, Now. I have removed the common jar from the war file, but i dont know how to access the latest version of jar and download it in the shared library everytime i restart my server.
Can anyone help on this.?
http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html
You'll need to add a dependency to your ivy.xml file, something along the lines of:
<dependency org="com.orgname" name="jarname" rev="latest.release"/>
Is this a JAR file you make yourself, or is it publicly available? If you make it yourself, you will have to publish it in a repository somewhere in your system.
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?
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.