I am a newbie to J2EE and I am not able to understand the directory structure created on building the java web project. After bit of googling i understood what we store in WEB-INF but
1)i am not able to understand that what we store in META-INF ?
2)how target folder get created?
3)where we mention that what all files should be placed in target folder?
I am using Maven to build the project which is a spring-hibernate based project.
thanks in advance
1) What's the purpose of META-INF?
2) Maven creates the target folder for you. It's where all of the Maven plugins dump their work by default.
3) Maven has mechanisms for excluding files from it.
The key to understanding Maven is that Maven works on conventions. That means that Maven will do a lot of things really well with almost no effort on your part if you structure your project according to Maven's expectations. For example, this is how you differentiate between Java classes and resources in the source directory:
src/main/java/com/mycompany/MyObj.java
src/main/resources/my/company/spring.context.xml
src/test/java/com/mycompany/MyObjTest.java
src/test/resources/my/company/spring.context.xml
When you run mvn test it will compile all of that, move it appropriately over to the target folder, load the JUnit runner and give you a classpath that will let Spring have easy access to the spring context under the test folder. It'll run the tests and drop the reports under target.
Maven is not like Ant. In Ant, you have to tell it everything. Maven works on the opposite end in that it assumes everything by default until you tell it otherwise.
This is a common problem because java has grown so big. Its often hard to tell where one technology ends and another begins. You need to familiarize yourself with the documentation for all the various components you are using.
For instance, if you have a 'target' folder then I assume you are using maven. Maven is a java utility used for dependency management. When you 'mavenize' a project, you agree to adhere to a bunch of standards and maven in turn does a lot of the grunt work for you(compiling code, finding dependent libraries, and running tests). Part of what maven does is create standard maven directories in this case 'target'
more maven info - http://maven.apache.org/
As for META-INF this is part of the Java EE spec. It does have a purpose concerning packaging and deployment, but you'll generally not finding yourself using it very often. Its generally the same principle as maven. You adhere to the Java EE standard and the Java EE compliant tools do most of the work for you.
For more info look at this link - http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/packaging_deployment/index.html
In general to understand these you should check out some tutorials on Java EE and refer to your container's examples and documentation.
1) What is the purpose of the META-INF
2-3)Target folder creates Macven, it manages all dependensies, etc: one, two
Related
I work with a partner in java programming, I use intellij and he uses Eclipse.
Is there a way that we can somehow mutually share our code with each other so we could work on the same code each in our own time?
Thanks
There is that possibility using GIT or another Code repository. Look at https://github.com/
or https://bitbucket.org/. There is also very helpfull article.
To be also independant you can simply integrate your code with Maven, both incellij and eclipse can import project based only on pom.xml file created in maven setup.
In this your should use repository when there are more than one programmer on a single project whether you are using even same IDE. SVN will be one of the choices for repository
Given that you guys need to implement version control, one important aspect of co-operating together is to keep your codebase IDE-agnostic.
Thankfully, with java and maven there is an easy way to do this.
Firstly, commit to building your project with a build tool such as maven. Therefore, using this example, the pom.xml is the master configuration file for your project.
In contrast, your "project" files (either your .idea folder for intellij or your .project, .classpath and related files for eclipse) should not be checked into version control at all.
You can then add "ignores" to your VCS so that IDE-specific configuration files are not checked in - this way you won't interfere with each other with IDE-specific things.
Then, it is relatively easy for both of you to share a maven (pom.xml) based project with each other, and to configure your IDE independently from each other (i.e.: locally).
I've been asked to apply Maven to a project. After browsing a dozen sites it appears that it's quite vast and I'm not familiar as I'd like with similar tools like Ant. Why is it used/preferred and what does it offer over a standard Eclipse project? Also, how could it be added to an existing project?
Why is it used/preferred and what does
it offer over a standard Eclipse
project?
It is a build tool which can build your project without the need for an IDE like Eclipse. It can create a jar or war or other artifacts from the source, performing a bunch of steps like compilation, running unit tests, etc.
Where maven scores over ant is in managing third-party dependencies and in convention over configuration (which mean less lines of build script if you follow convention).
Also, how could it be added to an
existing project?
You start by creating a new maven project, following the step here.
Place it in the root folder of your project
If your source and resource files do not follow maven folder convention, update maven properties suitably referring to this documentation.
Run mvn package
It will fail if it needs any third party dependencies, which you can add as specified in the doc
With some trial and error, you should have your project running with maven, possibly, much quicker than if you were to set up the same with ant.
Others are already provided sufficient resources to read more about maven.
I suggest to start reading here:
http://www.sonatype.com/books/mvnref-book/reference/public-book.html
Maven is a great tool when you know how to use it. Maven (at core) is a dependency manager.
You include in your pom.xml (similar in function to the build.xml from Ant) all the librairies your project depends on (example : apache commons) along with their version and Maven get them directly from a repository (by default, the central maven repository)
Then you do not have to manually install any jar to make your project work. All is downloaded and cached on your local machine. You can even create an enterprise repository where you put all the jars needed by your company
Maven uses the concept of artifacts which are pre-built library projects with their own dependencies
To mavenize a project, you'll have to write a pom.xml describing your project (examples are numerous), get rid of your libs directory (or whatever classpath you described under Eclipse) and add all your dependencies to your pom.xml
You could also check Mavenizer for a first-start
But Maven is a lot more what i've just said. Read the docs, read poms from librairies and you'll get used to it quickly ;-)
If you use the M2Eclipse plugin from Sonatype, it's just a matter of right clicking the project in the package explorer and choosing Enable Dependency Management in the Maven menu. You are also advised to adjust the directories that contain the sources to the Maven standard directory layout but if you absolutely can't, you can configure that later.
Apart from that: Well, look for tutorials and documentation (for example there is the free book Better builds with Maven. Maven is very complex (yes, I don't think it is simple) and very powerful.
Quite new to maven here so let me explain first what I am trying to do:
We have certain JAR files which will not be added to the repo. This is because they are specific to Oracle ADF and are already placed on our application server. There is only 1 version to be used for all apps at anyone time. In order to compile though, we need to have these on the class path. There are a LOT of these JARS, so if we were to upgrade to a newer version of ADF, we would have to go into every application and redefine some pretty redundant dependencies. So again, my goal is to just add these JARs to the classpath, since we will control what version is actually used elsewhere.
So basically, I want to just add every JAR in a given network directory (of which devs do not have permission to modify) to maven's classpath for when it compiles. And without putting any of these JAR files in a repository. And of course, these JARs are not to be packaged into any EAR/WAR.
edit:
Amongst other reasons why I do not want to add these to the corporate repo is that:
These JARs are not used by anything else. There are a lot of them, uncommon and exclusive to Oracle.
There will only be one version of a given JAR used at anyone time. There will never be the case where Application A depends on 1.0 and Application B depends on 1.1. Both App A and B will depend on either 1.1 or 1.2 solely.
We are planning to maintain 100+ applications. That is a lot of pom.xml files, meaning anytime we upgrade Oracle ADF, if any dependency wasn't correctly specified (via human error) we will have to fix each mistake every time we edit those 100+ pom.xml files for an upgrade.
I see three options:
Put the dependencies in a repository (could be a file repository as described in this answer) and declare them with a scope provided.
Use the dirty system scope trick (i.e. declare the dependencies with a system scope and set the path to the jars in your file system.
Little variation of #2: create a jar with a MANIFEST.MF referencing all the jars (using a relative path) and declare a dependency on this almost empty jar with a system scope.
The clean way is option #1 but others would work too in your case. Option #3 seems be the closest to what you're looking for.
Update: To clarify option #3
Let's say you have a directory with a.jar and b.jar. Create a c.jar with a Class-Path entry in its META-INF/MANIFEST.MF listing other jars, something like this:
Class-Path: ./a.jar ./b.jar
Then declare a dependency in your POM on c (and only on c) with a system scope, other jars will become "visible" without having to explicitly list them in your POM (sure, you need to declare them in the manifest but this can be very easily scripted).
Although you explicitly stated you don't want them in the repository, your reasons are not justified. Here's my suggestion:
install these jars in your repostory
add them as maven dependencies, with <scope>provided</scope>. This means that they are provided by your runtime (the application server) and will not be included in your artifacts (war/ear)
Check this similar question
It is advisable that an organization that's using maven extensively has its own repository. You can see Nexus. Then you can install these jars in your repository and all developers will use them, rather than having the jars in each local repository only.
(The "ugliest" option would be not to use maven at all, put put the jars on a relative location and add them to the classpath of the project, submitting the classpath properties file (depending on the IDE))
if you are developing ADF (10g / 11g I guess) components, I suppose you'll be using JDeveloper as IDE. JDeveloper comes with a very rich Library Management Tool that allows you to define which libaries are required for compiling or which ones should be packaged for deployment. I I suppose you will already know how to add libraries to projects and indicate in the deployment profile which ones should be picked while packaging. If you want to keep your libraries out of maven, maybe this could be the best approach. Let´s say the libraries you refer too are the "Webcenter" ones, using this approach will guarantee you you have the adequate libraries as JDeveloper will come with the right version libraries.
Nevertheless, as you are using maven I would not recommend to keep some libraries out of control and maven repositories. I´d recommend choose between maven and Oracle JDeveloper library management. In our current project we are working with JDeveloper ADF 11g (and WebCenter) and we use maven, it simply make us library management easier. At the end of the day, we will have a big amount of third party libraries (say Apache, Spring, etc.) that are useful to be managed by maven and not so many Oracle libraries really required for compiling in the IDE (as you would only need the API ones and not their implementations). Our approach has been to add the Oracle libraries to our maven repository whenever they are required and let maven to control the whole dependency management.
As others say in their answers if you don´t want the dependencies to be included in any of your artifacts use <scope>provided</scope>. Once you configure your development environment you will be grateful maven does the work and you can (almost) forget about dependency management. To build the JDeveloper IDE files we are using the maven jdev plugin, so mvn jdev:jdev would build generate our project files and set up dependencies on libraries and among them to compile properly.
Updated:
Of course, you need to refer to ADF libraries in your pom files. In our project we just refer to the ones used on each application, say ADF Tag Libraries or a specific service, not the whole ADF/WebCenter stack. For this purpose use the "provided" scope. You can still let JDeveloper to manage your libraries, but we have found that it's simpler to either have a 100% JDeveloper libraries approach or a 100% maven approach. If you go with the maven approach it will take you some time to build your local repo at first, but once that's done it's very easy to maintain, and the whole cycle (development, build, test, packaging and deployment) will be simpler, having a more consistent configuration. It's true that in a future you'll have to update to later ADF versions, but as your repository structure will already be defined it should be something fast. For future upgrades I'd recommend to keep the ADF version as a property on the top pom, that will allow you to switch faster to a new version.
Perhaps the reason I stalled learning Java until now is because I HATE how Java handles external libraries. I'm stuck keeping them in one place, adding them individually, fixing problems with versioning and every time I move/rename them, and copying and writing the classpath over and over each time I release a Java application.
There has to be an elegant solution to all of this. I keep all of my libraries (regardless of task, platform, or other) in their own little folder inside a "lib" folder in my development folder, kind of like this:
Dev
-lib
+JS-jQuery
+Flex-Degrafa
-Java-Xerces
+Xerces-1.2.3
+More libraries
I can use either Netbeans or Eclipse for Java dev, but none of them provide a very streamlined (and not to mention idiot-proof) way of managing all of these.
A nudge in the right direction or an online article/tutorial on this would be greatly appreciated.
You can either use Ant + Ivy or Maven to manage your library dependencies.
If it is only dependency management you're after and you're happy with the rest of your build process, I would use Ivy, as it can unobtrusively manage your dependencies, leaving your existing build process intact. There is a plugin for Eclipse called IvyIDE that contributes your dependencies via a classpath container.
Maven 2 has a steeper learning curve but provides a much richer set of functionality for building your projects and Eclipse integration through m2eclipse or IAM.
Personally I use Maven as I have a large number of projects to work with and Maven is particularly suited to efficient development across lots of projects.
Have a look at the introductory documentation to see what works for you.
Ivy Tutorial
Maven Getting Started Guide
Netbeans 6.7.1's Maven support is quite good and comes out of the box with the IDE.
The Eclipse addon was frustrating enough that I gave Netbeans another try.
A third choice besides ChssPly76's options is to use Ant with the Maven Ant Tasks. I don't know if I'd call any of these solutions particularly "elegant," but they do spare you the need to manage your own lib/ directory and classpath variables.
If you're working on Linux you can install Java libraries with APT or RPM.
Otherwise, I normally check precompiled JARs into a lib directory in my project's version control repository and make sure the names of the JAR files include full version information. E.g. lib/foo-1.5.6.jar, not lib/foo.jar.
To avoid having to manually set the classpath before running your app, you can set the classpath in the Manifests of the JARs themselves to define the dependencies of each JAR file. The JVM will follow all the dependencies when loading classes.
Maven is often more trouble than it's worth, but the ability to open a maven project directly into IDEs such as IntelliJ is excellent. For example, IntelliJ will download all dependencies and have them available without having to run a build first, or an mvn command and then a project refresh. It also isn't necessary to re-generate the project every time a dependency is added. I work with a number of Eclipse developers who switched to IntelliJ for this alone.
However, one shortfall of Maven is that many libraries (or versions of libraries) are not available on public repositories. Therefore it is often necessary to set up a local repository such as archiva. In ant, it would just be a matter of adding it to the lib directory in the repository.
Maven can also attack when you need to do something that maven doesn't directly support via a plugin. What would normally be a few lines of ant can often turn into a morning's worth of work.
Finally, buildr is an excellent way of using Maven's dependency management and plugins, while also supporting ad-hoc tasks.
My Maven 2 project consists of several sub-modules. It s structured containing and EJB, WAR and Jar sub modules.. Now i want to instrument the packaged EAR that contains all submodules as mentioned.
Example:
Interface Maven Project consists of several modules:
- InterfacePOM --> parent pom
- InterfaceEAR --> EAR module which does not actual code but is the packaging for Domain, EJB and WAR
- InterfaceEJB --> EJB module
- interfaceWAR --> WAR module
- interfaceDomain --> JAR module
When using Cobertura i can succesfully instrument all various independent modules but that generated a .ser file per module. Is there a way to instrument an enitre EAR file at once? So that the result will be a single .ser file which i can use??
Short answer: no (have a look at this previous answer for more details). You'll need an external plugin like the dashboard (actually, don't use it, see my previous answer), XRadar or Sonar to aggregate the reports. But in this area, Sonar is the clear winner (this project just rocks) and I'd recommend it without any hesitation. Check out Nemo, their public instance, pick up any project and have a look at the drill down of code coverage (for example Apache CXF) to get an idea of what it can do.
UPDATE: It appears that I missed the point of the initial question so I'm updating my answer accordingly. Basically, I now understand the question as "how to instrument an ear with cobertura" and this is indeed a totally different story.
Unfortunately, while cobertura can instrument an ear, sar, zip, war, jar, I' don't think that the cobertura-maven-plugin supports this out-of-the-box and it may be a better option to use cobertura's ant task with the antrun plugin. See MCOBERTURA-86, this thread and this discussion for more background on this (and an antrun sample).
TBH, what you are trying to do is really not easy in terms of build lifecycle, packaging, reporting, etc and is going to be a tough task because of the lack of support from the cobertura plugin. I'd really think about it twice (time to invest to get the whole thing working vs the value generated) or consider spending that time (understand money) to get a clover license (which offers better support for this).
I implemented a solution now based on your previous answers around Maven 2. It is still not very easy to use but so far it goes OK. The implementation is as follows:
1. Modified my parent pom to generate cobertura instrumented classes when giving a specific profile.This generates the .ser files and the instrumented classes.
2. The instrumented classes are copied to the /target/classes folder by using the maven-resource-plugin, so the actual packaging uses the instrumented classes.
3. As there is no module wide .ser file i manually combine those .ser files from the EJB,WAR,JAR and ear file using the commandline solution given by Cobertura. coberture-merge.bat/.sh
4. Deploy the .ser file into my JBoss container and also deploy the instrumented EAR.
5. After testing i run a report on the merged .ser file and voila.. it seems to work..
I surely will look into Clover as the solution implemented is somewhat manual..
It looks like there is no task in the cobertura-maven-plugin for merging .ser files from individual projects into a single report.
A google search turned up this feature request and patch for the plugin to add a merge task, but it doesn't look like it was accepted. One of the comments suggests using the dashboard plugin to accomplish the same thing, you might have some success with that.