How do you download Spring Framework jars if you can't stand Maven or any of the other build management tools. From what I can tell it seems you have to spend many frustrating hours on Google to find out how to do this. I thought Spring was supposed to be easy. All I'm trying to do is to write a simple Hello World application using Eclipse and Tomcat. Why is it so difficult with Spring 3?
go there
http://repo.spring.io/release/org/springframework/spring/
you can see all versions, like old school
Why can't you stand Maven? I like Maven, but I really like Gradle.
Either way, if you only build with your IDE, you can't automate your build (so no chance at continuous integration/delivery), and it's tough to integrate new members of your team. Specifically with this question about Spring dependencies, it is a lot easier to automate management of transitive dependencies rather than download them all yourself--and figuring out which new jars to download by tracing through one NoClassDefFoundError after another.
I think the Spring guys can't imagine why anyone would want to endure all these downsides. But it's your project and you should do what you think is right.
So if you must, grab the jars starting with this one from Maven Central yourself and have some fun.
That's funny. It seems everyone wants you to use a dependency management tool. You can always browse a maven repository and download the parts you need:
http://mvnrepository.com/artifact/org.springframework
Related
As I am new to learn either maven or Gradle build tools. Therefore I wonder which one I select to study between maven and Gradle and which one has more requirement and demand in the industry. I want to use these build tools for Spring and Hibernate based projects. Any suggestion would be very helpful.
Thanks
Before this is closed for "not being a good question", I'll get some comments in.
You might want to learn the same thing that most other developers want to learn. Look at the third slide of the following slideware, which shows the results of Zeroturnaround's yearly developer survey. For this set of >2k developers, when asked what technologies they were interested in learning, Gradle was at the top of the list.
You can use either Maven or Gradle to build projects using Spring or Hibernate, but it's useful to point out that both the Spring and Hibernate code bases (not necessarily the applications using them) use Gradle to build their deliverables.
Maven provided the best build solution for quite a few years, but it's difficult to customize a build, and most Maven build scripts are very "noisy". Gradle solves those problems, while providing a smooth migration path from Maven or even Ant.
I´ve been reading lot about, but since there are several web frameworks that uses Maven for the project, I got confused, so I´m not entirely sure if Maven is an archetype that defines an schema to start developing apps by following good practices, or is just some piece of sdk that converts my code to bytecode. Thanks in advance to anyone who can drag me out of my confusion and gave me the required info. BTW is that rigth to say an archetype is a directory structure?
I am not sure if you are reading enough about maven, Maven is a build system which can help you build your application, manage your dependencies, run your tests, create reports and many other things.
First link in google result is http://maven.apache.org/
Apache Maven is a software project management and comprehension tool.
Based on the concept of a project object model (POM), Maven can manage
a project's build, reporting and documentation from a central piece of
information.
Each application has many dependencies and many small tasks that needs to be done before you can run your application, developers define them in a file called POM and that will be a instruction for Maven to build the application. Maven can do pretty much everything other than writing your code. In that sense it is like Genie in the story of Aladdin, you wish for something it will bring it for you.
There is a Grails maven plugin that can populate Grails project with the same convention that Grails uses. It can work with Grails to execute your commands and many other. More importantly it will manage your dependencies.
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 :-)
We check all of our source code's dependent third-party JARs into source control along with our source code. When needed, we manually download updates to third party JARs and replace those JARs that are in source control with the newer versions. We haven't felt the need to use Maven yet as this process seems simple enough for us. But are we missing something of great value by not using Maven? Or does our scenario not warrant using Maven?
"JARs dont change much", I hear this all the time.....
Storing jars in the SCM is simple in the beginning of the project. Over time the number of jars gets larger and larger.... Wait 2 or 3 years and nobody remembers where the jars came from, what their licensing terms were and most commonly what versions are being used (important to know when analysing security vulnerabilities).....
The best article I've read recently making the case for a repository manager is:
http://www.sonatype.com/people/2012/07/wait-you-dont-have-a-repository-manager/
A little irreverant, but does make a valid point about the kind of technical inertia one encounters all the time.
Switching a project team from ANT to Maven can be scary.... Maven works quite differently, so I find it is best deployed with greenfield or adventurous project teams. For the old-school ANT users, I recommend using the Apache ivy plugin. Ivy allows such teams to outsource the management of their dependencies but keep the build technology they're comfortable with.
Ultimately the biggest benefit of using Maven are not dependency management. It's the standized build process. I've seen several failed attempts to create a "standard" ANT build process. Problem every build engineer has his opinion on what the standard should be.... Maven's approach of forcing users to write build plugins may appear restrictive in the beginning, but just like the iPhone eventually developers discover "there's a Maven plugin for that" :-)
When it comes to dependency management Maven really can be quite valuable. As Mark O'Connor suggests, running a local repository manager would likely be better than checking the artifacts into source control.
There are many tools (like m2e in eclipse) that can help with dependency management and provide valuable feedback on which modules or dependencies require which other dependencies. Maven will also make sure to get the appropriate version of a dependency even if different modules depend on different versions of a given library. That will help prevent duplicate versions of the same jar showing up in your deployed project as long as they have the same group and artifact id.
Even for a very simple project I don't think I would resort to checking dependencies into the source control system.
It's not only about 3rd Party Libraries. Mostly if you have multiple repositories. In our case, we had four repositories with lots of inter- and intra-dependencies.
Actually I started this answer and then I had to go for 15 minutes to talk to some colleague about a problem happened after someone forgot to update the .jar of one project in the other's lib directory.
And it looks more professional :)
we have several projects in our company with many dependencies among them. we have gathered our projects (EJB,Web, Enterprise Application and ...), on a SVN server, now we have difficulties with our projects, because after checking out a project from SVN, we have to waste a long time to gather the required libraries and projects for the checked-out project to build.
i want to some help about that, how the maven technology could help us to easily gather the dependencies and build our projects automatically. we use myeclipse IDE.
moreover i need some help and resources, to learn how to achieve this goal.
any guide and help will be appreciated.
thanks in advance.
Depending on the amount of projects you have, and how complex their build is, switching to Maven can be a hell of a task. It might still be worthwhile, mainly because Maven forces you to do things "the Maven way"1, and that such a "Maven way" is becoming more standard with time: you might end up with a simplified/more standardized build procedure.
If your projects are currently built using ant, chances are that ivy can quite more easily solve your problem of offloading JARs from your VCS system, with a minimal impact to your current build configuration.
Otherwise, if you really think Maven is the right tool for you, I strongly suggest you to have a look at the official tutorial, the POM reference and start playing with simple, self generated projects to start having an idea about how to deal with Maven. Using the archetype:generate mechanism you have access to dozens (hundreds?) of sample projects (archetypes, in Maven jargon) that illustrate you how to deal with different kinds of projects, from simple JAR to more complex ones, maybe leveraging exotic frameworks or products. Have a look at the generated POM for such projects and try to understand how it works.
Integration with Eclipse is achieved via two different plugins. I'm not using Eclipse anymore since quite a while, but I think m2eclipse is still probably the best one to start with.
1- WARN: his is one of the things people coming to Maven heavily dislike more often than not