I am about to use maven to automate my builds. Unfortunately, I am not able to get all the features I want, even after reading several tutorials :(
I would be glad if somebody could explain a way I can achieve all my goals!
I want to automate 3 specific build tasks with several actions for a project from within eclipse, using m2e:
Build snapshot
compile
define current project version + date as version
build jar file
copy jar file into the local repository in the project path itself (§{project}/builds/)
Debug snapshot
build snapshot as mentioned above
copy jar file to plugins folder of a local test server
build another project the current project depends on, copy its jar file to the plugins folder aswell
launch server / connect to eclipse debugger (I know how to do that, the previous steps are the important ones)
Create release
compile
define current project version as version
build jar file
copy jar file into the local repository in the project path itself
create javadoc
copy source files and javadoc to an archive folder
increase the project version (for example v6 -> v7)
As mentioned I don't need a perfect solution, just a way to realize this ;)
(Annotation: Chaining multiple launch configurations is not a problem.)
Edit:
Which sections of the pom.xml do I have to modify to realize these steps and how can I invoke them using an eclipse launch configuration?
Hi based on your requirements i can say the following:
Build Snapshots
Building a SNAPSHOT is usually the convention during development cycle.
1.1 just using the conventions.
1.2 Date as version
This is a bad idea, cause Maven has some conventions how a version looks like (1.0-SNAPSHOT or 1.2.3-SNAPSHOT etc.)
1.3 Build jar file
Usually done by the jar life cycle (mvn package)
1.4 The local repository is on your home drive in ${HOME}/.m2/repository for all your projects. Technically you can do what you like but it's against the Maven conventions. The question is why do you need such thing?
2.1 Usual procedure
2.2 Usually a deployment is not a job for Maven but you can do such things by using cargo-maven-plugin (integration testing).
2.3 If you have dependencies between project you need CI solution like Jenkins to do such things otherwise you need to do this manually. But that is different from a multi-module build.
2.4 Integration testing different story. Depends on what exactly you like to do.
3.
1-7
The maven-release-plugin will handle such things except copying to the project path itself which is against the conventions. For such purposes you need a repository manager.
I can recommand reading these books: http://www.sonatype.com/Support/Books
Related
Ultimately we are trying to figure out a build/deploy process at my company. As the developer, I need to provide my source code to an audit group. They review the software for security deviations. If the source passes the audit, then the code goes to the Software Configuration Group. Their job is to archive and compile my app to a WAR. The WAR file is then provided to the IT department who will put the WAR on the server. I think the process would be easy if I had one self contained project.
But in Eclipse I have two Maven projects, where one depends on the other. One project core provides core functionality. I separated it because these core functionalites will be used by all my other (internal) web app projects.
Logging
filters
common models (phonebook, employee, etc)
common utilities (Emailing employess, String utils, etc..)
In the other projects, say project1, I add a dependency to core in the POM. Not sure if I need to do this but I also edited the Eclipse project properties and added a reference to the core project. With some finagling (new to Maven) I was able to get Project1 deployed to my local install of JBoss. I opened the WAR and in WEB-INF/lib folder I could see that core-0.0.1-SNAPSHOT.jar was automatically included.
But how do I give SCM my source for project1 which also needs the source for core without manually copying cores source into porject1s source.
I could copy core-0.0.1-SNAPSHOT.jar into Project1 but they should also be reviewing cores source every time I deploy a new app because I may have added or tweaked some core functionality.
You should learn more about maven SNAPSHOT and release repositories. Then install Nexus server as destination for produced jars, wars, javadocs and sources (called artifacts).
After that maybe you will be interested in commercial Nexus version with staged deployment option.
http://www.sonatype.com/people/2009/06/using-staging-repositories-for-deployment-in-nexus/
To solve packaging problem you can use Maven Assembly Plugin. You can have all sources and dependencies in one file.
Maybe there are even more suitable for your needs maven plugins.
From past 90 hours I am trying to know how to use Maven in my web project, generate a war file and deploy it into my JBoss 4.2 Server.
I am not getting.
I am reading all kinds of blogs, googling almost all time, trying out all kinds of way to build a dynamic web project with maven, but trying out different methods make a simple thing more complex.
Few examples tell me how to run, few tell me to change the folder structure, few tell me transfer the contents of web content but nothing is matching my requirements. In some of the examples war file is getting generated, but of some big name, and it does not contain the jars inside. Uff.
I know maven is easy and makes our lives better but learning it for the first time makes it complex.
My requirement is simple.
1) Build a Dynamic web project in eclipse indigo. (Preferably in JAVA perspective )
2) Enable Maven dependencies, in eclipse.
3) Update pom.xml to add dependencies.
4) Finish the web application i want to do by writing classes, html pages, deployment descriptors.
5) Build the war file using maven "IN ECLIPSE ONLY". (the WAR file must have user specific name and not some name like "V1- Snapshot dash dash dash")
6) Deploy my war file in jboss 4.2 server deployment location. (Preferably from eclipse )
7) Run my localhost server and my application from the browser.
And Done.
By spending time on it I am understanding how beautiful is maven, but I am not able to achieve what I want.
Please help me by giving me a detailed procedure on how to use maven to meet my requirements above.
Fist I would suggest to use the newest Eclipse (Juno) with Maven support (m2e and wtp-m2e).
The first step is to define your pom with the appropriate dependencies and the correct packaging type which is in your case war.
If you really need a different naming you should leave Maven, cause maven makes assumptions about the naming of your artifacts which usually isn't a problem. The default version patterns as 1.0.0-SNAPSHOT etc.
If you wan't to deploy the war into JBoss there exist a number of possibilites to do such things and if you like to run your application locally it sounds you wan't to do some kind of testing (integration testing) which is supported by Maven (see maven-failsafe-plugin).
Furthermore you must learn if you like to use Maven to understand that not Eclipse is anymore the leader of the project configuration. This job has been moved to Maven or in other words into the pom file. If you like to use the project in Eclipse you need to import this project into Eclipse.
Apart from the above i would suggest to go to a Maven training to lear all that stuff which is more effective than learning it yourself.
Here is the situation. A development team has a large number (hundreds) of Eclipse projects. The code is very much in churn - new projects are being created; projects are being renamed and project dependencies are constantly changing. The external build system is ant. It is proving extremely challenging to keep the dependencies defined in the ant build files in sync with the state of the world in Eclipse. The external ant build needs constant changes to keep up. For various reasons, using ant as the default builder in Eclipse is not an option. The developers want to continue using Eclipse as the build and edit environment for local use.
Question: Is there a tool which will allow a single set of dependencies to be maintained which can be used by Eclipse as well as an external build system like ant?
I have heard of Gradle but never used it before. Would it make sense in this context? I am pretty sure Maven wouldnt work for what is needed
The typical workflow should be:
1. Developers continue working as they currently do - creating and changing Eclipse project dependencies at will and using the default Eclipse builder to compile and test locally.
2. Some mechanism exists by which these dependencies can be carried into an external build system like ant and an external continuous build triggered on every checkin.
Appreciate your feedback - thanks!
We have been quite successful at using Gradle to tackle a similar problem. Here's the outline of the setup
Each project contains a build.gradle that defines project specific dependencies and tasks (may even be empty).
A special master project contains build.gradle that sets up common dependencies and tasks for child projects, and/or injects settings pertinent to a group of child projects.
Logically master project is the parent project, but it exists as a sibling folder so that Eclipse can be more comfortable with it.
Gradle contains a built-in Eclipse plugin which allows generation of Eclipse settings files for each of the projects from the dependencies information (including inter-project dependencies). It works nicely for simple projects, and as for more complicated ones Gradle allows you to tinker with the settings files, so you can do pretty much everything. From here you have two options:
Not to store Eclipse settings file in the repository and call the generation task every time you do a fresh check-out (I prefer this option).
Tell Gradle to use custom variables to make it generate generic settings files which can be checked-in to the repository. You'll then only need to run the generation task when dependencies or other configuration changes.
(Optional) It's a little tricky, but you can make Gradle parse existing project ivy.xml files and set up dependencies from there. I had some success with this, although I would recommend converting dependencies into Gradle format for more flexibility.
Continuous build system integrate with Gradle very well (same as ant). If you are using Jenkins (Hudson) there is a Gradle plugin.
The advantage of using Gradle is that it scales pretty well, and you can support other IDEs like IntelliJ or Netbeans at the same time without much effort (unless you have lots of crazy custom settings). An advantage and a disadvantage is that Gradle is a powerful build system which requires learning Groovy and Gradle DSL which may take some time to acquire. Also the documentation is awesome.
Gradle has a very active community with the sole purpose of tackling exactly this kind of problem.
Hope this helps, and best of luck!
How about parsing the .classpath files, generate a dependency tree and start building from the root. What you need is a convention on the layout of your projects or an generic (ant-) buildfile that could be changed in each project, if needed (e.g. different project layouts). I´m not sure if Eclipse Tycho could be used for that, since it´s a maven plugin(s) to build eclipse plugins or projects. But it´s able to resolve the bundle and project dependencies against maven repositories and eclipse update sites.
I'm about the setup an automatic (command-line) build for my Eclipse RCP Application.
I have found out the following ways to do it:
Buckminster
Using Maven with the pde-maven-plugin
Headless PDE Build
The problem with all these options is that they require me to create essentially a new representation of the information already contained in my target platform definition. For example in Buckminster, this would be the .rmap file.
In my thinking all the information to build the product should be already there when I have the following:
Plugin project with product configuration file (foo.product)
Target platform definition file (foo.target)
Therefore I would expect there to be a command like the following:
build-rcp-product foo.product foo.target win32
Is there anything like that which I may have missed?
With Buckminster you don't need to replicate the information in your target definition file. You can simply import the target file using the importtargetdefinition command. If all your dependencies defined in the target definition file, then in the rmap you define only from where to materialize your plugins (svn, git, maven, file system etc).
With PDE build, there is a filed request (Bug 266311) and it seems it is still not possible to utilize the target file directly but there are some workarounds suggested in there (which I didn't try, I am using Buckminster).
I use the PDE build and it's pretty simple. It essentially gets what it needs from the MANIFEST.MF file and the build.properties file.
The command to run it is more complicated, as you have to start Eclipse and point it to a few things, but it's very well integrated with the IDE. It does everything by making Ant scripts.
you can try tycho
here's a good start:
Tycho tutorial
Reference card
with tycho, all you need is a POM and you usually will not change this information, which is generated via maven
I have a list of Eclipse projects that I would like to compile based on the existing project configuration.
As far as I can tell, if an ant script could read the .classpath files, it would pretty much be able to infer the project dependencies and perform a "javac" compilation in the right order. This would save time in describing the same dependencies again in the ant script or a Makefile.
The dependencies I am interested in are JAR Dependencies, JRE dependencies, and inter-project dependencies. These are -- as far as I can tell -- part of the .classpath XML file.
Any ideas on how Eclipse project dependencies could used in an ant script?
Right click on your Project -> Export
"General/Ant Buildfiles".
Choose the projects and there you go.
Otherwise...
I have some experience with ant4eclipse and it is a hassle to get it stable.
Go check Buckminster or Maven Tycho for a good solution.
I'm currently using Ivy along with Ant, Eclipse and Maven.
I just love the way Ivy works.
Currently, we have a workspace with many projects using Liferay (with Tomcat) for the front-end and Glassfish for the back-end.
We were looking for a way to manage our dependencies a lot better than how we were doing it.
So I took Ivy, replaced all of the classpaths and deployment dependencies in eclipse and was able to build my application using 1 ivy file per project using either Eclipse or Ant.
Ivy integrates like a charm in ant and builds are done either from the workspace or by command line.
I strongly suggest you look at this avenue. Additionnaly, by adding Artifactory, we have a local repository in which the ivy files look for dependencies. This helps us maintain and rule which jars are to be used by developpers. Once everything is setup, we will build our application nightly using Jenkins and these builds will be using our Artifactory repository to resolve dependencies since our build servers do not have access to the internet.
Hope this helped
If you are running the Ant script only from eclipse using the "External Tools Configurations", you can add the variable ${project_classpath} to the Classpath.
Depending on if you are in a plugin project and dependencies you might need to add the
${eclipse_home}.
In case you get an error launching Variable references empty selection: ${project_classpath}, make sure the ant xml file or at least the project is selected. This is important.
I believe the ant4eclipse project provides support for executing Ant builds based on Eclipse metadata files.
However, in my opinion that is doing things back to front. You shouldn't have your build (Ant) depending on your IDE (Eclipse) environment. But it is useful if you can derive your Eclipse environment from your Ant build.
This is an approach used successfully in a team I worked in. We had a helper Ant target which applied XLST to project build.xml files to transform these into Eclipse .classpath files. Thus the Ant build.xml files were the single configuration point for our projects.