I am pretty new to Java and Maven and today was studying about maven, how to Mavenize a java app, how to make it good for EClipse, etc... so now I have a question: when we want to write a Java and we know that we want to use Maven too, then we start writing application and creating out directory structure with the layout that Maven likes it? or we just write our app and at the end we mavenize it? Where do we start from when we want to create a java app from beginning and we want it to be mavenized too.
Use Maven from the beginning. Why write in a different structure and convert it again at the end, while you can do it in correct way from start? If you don't use Maven from the start, what build tools you will use then? Ant? I don't see any gain in productivity in such approach.
As Adrian said, you should definitely use Maven since the beggining.
One of its main value is to guide you on "the right way". I should say "The right Maven way". It's sometimes very restrictive, but it's the main advantage : if you do like Maven is waiting for, you are probably on the way that every community or big project do.
If you start your project "by yourself", you may forgot or miss something that will trouble you. For instance, main java sources are expected to be in src/main/java. Most of the plugin use the variable sourceDirectory to bind it ... but you may have to redefine this variable many times for plugins.
Another instance, and quite often confusing, is the multi module project. If you have 2 or more project that are binded (in their life cycle), you should set up a multi module project. If you don't, you will face of code or action duplication (2 tags, 2 build, 2 deployement, etc...).
So, in order to give you a straight answer :
read http://www.sonatype.com/books/mvnref-book/reference/
use the more appropriate archetype to build your project
if you create it under command line (not with an IDE), import it
then work :)
What I'm saying will appear you more and more clear using Maven :).
See Why does Maven have such a bad rep? to better understand why :)
Related
So I have been struggling all afternoon with getting some Gradle build to work for a Kotlin multiplatform project that involves an ANTLR grammar. What I'm trying to do is to have a parser generated by ANTLR from a shared grammar for both a Kotlin (or Java if that doesn't work) and JavaScript target. Based on this I'd like to write some library around the parser that can be used from the JVM and JavaScript.
So I have set up a Kotlin multi-platform project because that seemed like a nice way of killing two birds with one stone (here is a repo https://github.com/derkork/project.txt). I created a source set commonAntlr where I placed the grammar file under commonAntlr/antlr/project_txt.g4. According to the documentation of the ANTLR plugin this is how stuff should be set up. I also apply the antlr plugin at the top (here is the build.gradle.kts - https://github.com/derkork/project.txt/blob/master/build.gradle.kts).
Now I run gradle build in the hopes that the ANTLR plugin will at least try to generate some nice Java code for me from the grammar using the default settings. Alas, it does not. The ANTLR plugin does not even get started, which is what I can tell from the output. The build later fails with some obscure JavaScript problem, but that looks unrelated and I'd like to skip over it for now.
Now my Gradle-foo isn't exactly strong (I have only used it in extremely simple projects, most of my experience is in Maven), and I have the distinct feeling I'm missing something here. However the documentation of the plugin just says
To use the ANTLR plugin, include the following in your build script:
plugins {
antlr
}
Which I did. Since I get zero output, I have a feeling that I need to do a bit more for this to work. I have read a lot of the Gradle documentation up and down to find out how plugins work in general and I found that they add tasks to the build and also add some dependencies so that tasks are invoked when you try to build certain things. However I don't really understand how plugins work together with source sets and how you can tell Gradle "would you please run the generateGrammarSource task for this source set" (or if it even works like this).
So if some of the Gradle gods could enlighten me on this, this would be much appreciated :)
I have met a similar issue: https://gitlab.com/pika-lab/tuprolog/2p-in-kotlin/tree/feature/parser
My solution -- which is still a work in progress -- consists in decomposing the problem.
I reasonable solution in my opinion is to create a Kotlin/JVM project (say parser-jvm) where to put the generated Java code + any JVM specific facility, and a Kotlin/JS project where to put the generated JS code + any JS specific facility (say parser-js). The next step is to create a Kotlin/MPP (say parser-common) project whose JVM implementation depends on parser-jvm and whose JS implementation depends on parser-js.
My approach is actually working for JVM while I'm experiencing some issues for JS, which are mostly caused by this issue.
The main drawback of this approach is that some Gradle coding is required to setup ANTLR with Kotlin/JS. I already faced this problem in my build.gradle and I'm quite satisfied with the result and the overall architecture of the project. However, I believe that my proposal is far less troublesome than configuring a Kotlin/MPP project to work with ANTLR.
I am working on a project and using Maven to build it. The project is a quite big Java web application and it is supposed to work with both Mysql and Oracle databases.
The problem is that there are some specific annotations related to either of the two databases in the source code, plus some other differences, so that I am forced to manually comment/uncomment part of the code before building the application for one of the two databases.
Basically what I would like to achieve is to have my build script, maybe via a Maven profile, to automatically switch the source classes before building depending on the database I want my war to work against.
Putting it simply, the idea is to have MyClass.oracle and MyClass.mysql, and depending on my build profile I should move one of the two in the source dir, rename it MyClass and build. This should be done for some packages, classes, and also configuration files.
Is there any way I can achieve it via "pure" Maven? The only solution I came across till now is to use an antrun plugin and reference an Ant build.xml inside of it.
Thank you,
Mattia
A pure maven solution would be to develop your own maven plugin. Depending on your requirements this can be an overkill, however it is not hard at all, you can see how to achieve this here.
This is a limitation of Maven. One of Maven's purposes is to not have a build script. You should simply use the plugins as available, and setup your project the right way, and magically, everything will build!
There is one solution: Use Ant. Well, not to redo your whole project with Ant, but with the antrun plugin, you can run a few Ant tasks at various phases of your Maven build life cycle.
It's been a long, long time since I've used this, so I am not going to try to write a test pom.xml, but I don't remember it being very difficult to use.
Of course, the correct Maven solution is to divide your project up into "common core" code, and then a separate Oracle and MySql client that uses the "common core". By the way, I hope you're not patching source code. Instead, you're using a properties file to do this for you.
I have recently started using Gradle as a build system.
They first comparison that Gradle makes with the likes of Ant and Maven is that,
Ant is an imperative build system, whereas Maven is a declarative build system.
While Gradle is a declarative build system without the rigidity enforced by Maven.
I wanted to understand these terms declarative and imperative better when it comes to talking about build systems.
In short, an ant script tells the ant tool what to do - "compile these files and then copy them to that folder. Then take the contents of this folder and create an archive."
While a maven pom declares what we would like to have as the result - "here are the names of the libraries the project depends upon, and we would like to generate a web archive". Maven knows how to fetch the libraries and where to find the source classes on it's own.
While ant gives you more flexibility, it also forces you to constantly reinvent the wheel.
Maven on the other side requires less configuration, but may feel too constraining, especially if you are used to a different workflow.
EDIT: An important aspect of the ant-maven comparison is that maven has a convention, describing where the files should lie, where the dependencies are found, where to put the resulting artifact, while ant does not.
So you can think of using maven like riding a bus - you select the stop where you enter and the one where you leave. Using ant is like driving a car - you have to do it yourself. You dont have to tell the bus driver what to do, but the stops may be too far from where you want to go.
EDIT2: 'Reinventing the wheel' metaphor seems to be less clear than I had hoped. This is what I mean:
Without sensible defaults/conventions, you have to define the project structure and the build lifecycle explicitly for each project, often making it a matter of taste and opinion. As preferences vary between teams and companies, so do build processes. This requires more cognitive effort for new project members and later maintainers. Depending on the experience and expertise of the developers, the final solution may be hard to extend and use.
As I said in a comment below, while best practices for ant builds exist, they still have to be implemented for each project, or copy-pasted from project to project, instead of becoming an out-of-the-box default of the build tool itself.
Maven is a bit too far on the other side of the trade-off for my taste. Changing the defaults is not as easy as it could and should be.
I'm a bit surprised at the sheer number of articles / blogs / questions / answers about Clojure mentioning Maven.
In about ten years working as a Java dev, working on both desktop apps and webapps, I've never ever used Maven once (typically --and that's a personal opinion but I know some people do think the same-- the projects I've seen using Maven where including the "kitchen sink" whereas the ones built with a more "controlled" build process where way "cleaner" and producing smaller jars, faster build time, etc.).
Is Maven a requirement when you want to build a Clojure app?
Is Maven mandatory when you want to use Leiningen? For example, can I add external jars as dependencies to a leiningen project "manually", without needing Maven?
I think my question boils down to this: can you, in the Clojure/JVM world get away without ever using Maven, just like you can build, test, package and ship both Java desktop, webapps and Android apps without ever needing Maven?
Short answer: No. Clojure's just a jar and you can use it as "raw" as you like, just like any other Java library.
Longer answer: Maven's not a requirement, but the tooling around Clojure, especially Leiningen, is highly Maven-aligned so your life will be easier if you just submit to Maven's will. But, with a little work, it's not that hard to get along without Maven. At work, I use a mix of Leiningen and our existing Ant/Ivy-based build infrastructure. I use Ant to resolve dependencies (from our curated internal repo) and then use a hack of Leiningen's :resource-paths to get it to pick up the non-Maven jars. At some point I'll make a true plugin to do this stuff, but it's been working fine for me so far.
Also, if you're an Eclipse person and use CounterClockwise, you can treat your project like any other Java project in Eclipse, managing the classpath manually. It just happens that you've got some Clojure code in there as well.
Of course, the drawback in either approach is that if you want to grab something that's available from either Maven central or Clojars, you'll either have to set up some kind of mirror for your infrastructure, or manually pull down the transitive dependencies and add them to your project.
You do not have to use maven, or leiningen, for that matter. You can run the clojure REPL with
java -jar clojure-1.3.0.jar
and it will work just fine. I know where you're coming from, because a year ago, I was in the same boat as you. never used maven, seen a couple of less than great projects that used it poorly, and generally distrusted maven. Ant+ivy works great, who needs maven?
As a result of using leiningen, and starting a new job where we have a very well setup maven config, I've changed my tune completely; I now think maven is great, and far prefer it to ant, which I've used for a long time.
Specifically with clojure, some advantages of leiningen are:
automagic project scaffolding: "lein new" sets up a new project for you. convention is important, it helps other developers understand your project and quickly ramp up on it.
dependency and plugin management. adding a dependency is trivial, and there isn't a great way that I am aware of to do non-maven dependency management that is tightly integrated with clojure.
"lein repl" sets up your classpath and everything correctly, so you don't have to fool with it, you can just start and run a REPL.
artifact creation: building a fat jar (lein uberjar) is straightforward, and already set up for you.
So, while it's definitely possible to use clojure without leiningen, I honestly don't see why you would want to. There are too many niceities for day to day development not to use it, in my opinion.
regarding "Is Maven mandatory when you want to use Leiningen?"
leiningen uses and wraps Maven so you can't truly avoid it, though you don't ever need to touch any XML
Maven is not mandatory for Clojure as others have rightly pointed out.
However, I would like to encourage you to embrace Maven (either directly or via leiningen). It has some big advantages in the Clojure world:
You will be more productive in the long run - once you've got it set up, it is pretty impressive to see a complex build, test and deployment execute in a single command. Do you really want to be manually setting classpaths, downloading dependencies, incrementing version numbers, uploading to FTP sites etc.?
One of the biggest advantages of using Clojure on the JVM is access to the Java library ecosystem. Maven is the tool of choice for automatically managing dependencies on Java libraries. Nearly everything you are likely to need will be in either the Maven Central or Clojars repositories.
Clojure tends to have small focused libraries - this is good because they are "simple" and you can pick and choose the functionality you like. At the same time, it also means that you are likely to have numerically more library dependencies. Hence a build management system is going to be more useful.
You can make Maven builds as "lean" as you like. Obviously you can pull in every dependency under the sun if you like, but you can also create very lean jars by excluding the unnecessary cruft. That's your choice.
It is the de-facto standard in the Clojure world. If nothing else, using it means that you will be able to collaborate with others more easily.
P.S. Like you, I didn't really see the point of Maven 5 years ago. Then I gave it a go and saw how powerful it could be for my workflow. Now I'm a convert :-)
(first, I admit, I have no love for maven/m2eclipse, but it wouldn't be that bad if I could figure out how to overcome these issues)
I am using maven/m2eclipse. m2eclipse is the only good way I know of to suck in the maven jars. Some of these may not have solutions(but I am hoping to be surprised). Maybe solving #9 solves them all?
ISSUES
When I run "mvn clean package", I am dead in the water as far as running a unit test in eclipse while maven is building as I LOVE to multitask but maven prevents me here. How to get around this?
I move eclipse to point to eclipsegen/classes but then the unit tests are still using the classes in target/classes so it's not using my latest code that I just edited in eclipse and debugging is not lining up and it's stepping on blank lines that don't have code.
If I just slightly touch the pom.xml, bam, it builds when I don't really want it to and turning of automatic builds did not seem to help.
On top of #3, I get random pom builds downloading jars which just freezes eclipse from doing anything why the jars are being downloaded(I am a bit multitasker so this frustrates me to no end)
If I want to modify or do something really custom I need, the answer is usually create a java plugin but this then would require me to create another source control project with another automated build making sure the build tags all versions so we can reproduce issues with certain versions. (in ant, I just modify the xml to do custom stuff).
(I hear there is a bug open for 5 years on this one). global exclusions because people on our project keep breaking stuff when they include new things that depend on log4j and sucking that library in breaks us so we want to globally exclude it so people stop breaking the project when adding new things (IVY has global exclusions, why doesn't maven!!!!)
The xml code for generation from an xsd in maven is about 2-3 times the code of doing it in ant. Why is this? That really shouldn't be the case I think.
Running my unit test says xxxx-12.0.8-SNAPSHOT is missing but in my pom.xml it clearly says 12.0.9-SNAPSHOT not .8. ie. m2eclipse gets into some weird state and I get screwed wasting yet more time because someone selected maven
(I don't like IvyDE for the same reasons I don't like m2eclipse). In maven, is there any way like in Ivy to say on a build MOVE ALL jars into target/lib so that I can uninstall m2eclipse(if maven had this one feature, I think all my problems might go away)....That IS AN Ivy feature that rocks by the way!!!!
NOTE: I just realized that uninstalling m2eclipse and running "mvn eclipse:clean eclipse:eclipse" is not really an option since on this project I had to import 30 projects. I think on single projects, that is a great solution.
Is there no way like ant to log the command that was run for debugging purposes? ( in maven how to log the command that was run? )
I should really look into gradle(I hear it's best of maven and ant) as the theory of maven sounded great but you can tell there was a lot of controversy over it(which usually indicates a bad tool). Good tools that really help typically do have some controversy, but not as much as maven has had so it makes me think twice as I don't want to screw the guy who takes over my project(and I know ant will work). Many people I think don't even consider that. They think "I am fine, so why won't the next guy be fine".
Any ideas on how to fix the above issues?
About #9, if you have 2 alternatives :
Execute
mvn dependency:copy-dependencies
See http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html for customization options. You'll have to set your Eclipse classpath manually to point to the newly copied jars.
Use JBoss Tools JDT Extensions to get the "Materialize Library" feature (see http://docs.jboss.org/tools/whatsnew/core/core-news-3.3.0.M4.html). You'll basically just have to right-click on the Maven Classpath library, select a destination folder, select (and rename) the jars you want, and you'll get a m2e-free project in Eclipse (still a valid Maven project in command line though).
You can install JBoss Tools JDT Extensions from http://download.jboss.org/jbosstools/updates/development/indigo/
Disclaimer: I like Maven and M2Eclipse, and I have not experienced any of the issues that you mention. In general, M2Eclipse does not get in the way much for the way I'm working.
One thing that might help is disabling the Maven Builder for the projects (right-click the project, select "Properties", then "Builders"). This will get rid of many of the issues you're complaining about.
One other thing that might help you (and comes close to #9 on your list: Uninstall M2Eclipse and use mvn eclipse:eclipse, which will generate Eclipse .project and .classpath files, which include all dependencies as Eclipse project dependencies. Whenever you add or change dependencies, you will have to run mvn eclipse:eclipse again. Give this a try...
Although it does sound like a faster PC would solve some of your issues I do agree that the m2eclipse plugin sucks (although it sucks a little less since eclipse indigo). Because of this I switched to using Intellij for a while but I switched back to eclipse after a month (for me, eclipse is still the best in spite of m2eclipse).
I use m2eclipse to be able to work in eclipse but nothing more. All my maven builds (package, install, whatever) I run with maven itself (command line) simply because there have been too many occasions where the result was different (working in one, not in the other and and maven was always correct).
So, sorry, no direct answers to your questions, just some tips:
1) do it outside eclipse
2) stick to maven standards (target/classes); that will make your life a lot easier
6) using dependency management in a parent pom might help a bit
8) if you get the same issue when running from command line then there is a problem in your pom (resolve using mvn dependency:tree), if not, see 1
9) maybe assembly is an option here but I would not recommend your approach