anon315
Član broj: 315 Poruke: 1657 *.adsl.sezampro.yu.
|
Vidi Leko, Maven je i nastao zbog toga sto su Ant skripte morale da budu glomazne da bi se odradio neki posao i zbog toga sto je Ant skripta za manje vise svaki projekat bila drugacija, a onda se radi copy-paste delova skripti.
Ono sto je najveca zabluda je da je Maven samo build sistem. Recimo, glavna stvar koja privlaci ljude ka Mavenu je dependency management sistem!
Sto se tice komentara za gore pomenuti XML, to je banalan primer. Maven dolazi do izrazaja kada se primenjuje na kopleksne JEE projekte na primer. Pogledaj kako izgleda "hello world" u Mavenu2 i shvatices da sam pomom od 15-ak linija (koji se btw AUTOMATSKI generise), mozes da izgradis strukturu projekata, da kompajliras kod, test kod, da uradis testiranje, da zapakujes jar, da odradis dependenecy menadzment, bez da brines o tome gde se nalaze biblioteke i artifakti, da deployujes tvoj artifakt! Takodje iz takve strukture, on the fly mozes da generises projektne fajlove za Eclipse, NetBeans, Ideau, a ako nema plugina za tvoj IDE (kao sto nema za ono sto meni treba), onda sednes, pa lepo sam napises plugin. Sa jos dve linije koda generises kompletan sajt projekta itd, itd.
Ima gomila stvari koje Make sigurno nema - artifakti, kontrola biuld lifecycle-a pomocu pluginova. Da ne govorim da postoji gomila pluginova za popularne stvari, ajde da dam jedan primer - imam XSD semu koja nije zakucana, znaci menjam je vremenom. Posle svake promene (posto korisim JAXB), ja moram da pokrenem rucno xjc kompajler da bih generisao java klase. Ok, moze da se napise skripta, nije problem. Ali to ce morati da uradi svaki programer. A pazi sad ovo u Mavenu - ja dodjem i kazem, ok ja cu da koristim Jaxb Maven2 plugin i samo je dovoljno da konfigurisem plugin sa 2 linije koda, gde kazem da modifikujem lifecycle tako da se u fazi generate-sources poziva odredjeni goal mog plugina koji odradi posao za mene. I cao.
Pored toga, postoji gomila podprojekata u okviru Mavena kao sto su Continuum, SCM, Wagon, Doxia i sl.
Maven je build sistem, dependency management sistem, repozitorijum, project management sistem, reporting sistem itd.
Znam da te nisam ubedio da je Maven dobra stvar, ali to je iz razloga sto sam ga i ja samo zagrebao. Nadam se da cu za nekih mesec dana moci da prenesem puna iskustva i odgovore na sva pitanja..
Mozda nije lose da citiram jedan deo knjige:
---------------------------
Maven... What is it?
This is a complex question, but a good one. Maven is a lot of things to a lot of people. If you use Maven to its fullest extent, it is a build and deployment tool vis-a-vis Ant, a dependency management tool like Ivy, a metric reporting tool, a documentation generator, a software project manager, a parent project, a build lifecycle, a project repository, a convention, a concept, and a community. A user may utilize one or many of these pieces, or use it for purposes hitherto undiscovered. At its core Maven is a framework for managing various aspects of a project, providing its own conventions and tools to meet this end and acting as glue for making existing disparate tools work in a tractable and orderly manner.
Convention over Configuration
Convention is at the heart of Maven. Convention over configuration is a popular aphorism these days, and Maven fully embraces this concept. Convention over configuration is at the central philosophy of frameworks such as Ruby on Rails, and more recently, the EJB3 specification. In its most basic sense it means that, while configuration is certainly necessary, the majority of users will never utilize such edge-cases those complex configurations provide. Although a powerful framework certainly needs to have the power to configure when necessary, it is certainly reasonable to create defaults to allow the 95% of similar use-cases to work without defining anything at all... the system can assume these defaults. In other words, the system has its own convention. Because of this, the monstrous configurations required of build tools like Ant (where a majority of Ant scripts are cut-and-pasted from existing projects) are non-existent for those projects that follow Maven's conventions.
Another driving force behind the popularity of convention over configuration is the speed at which new users may pick up a new technology, or the speed by which a seasoned user may begin using the tool without concerning him/herself with details that need not come up until later in the development process. The computer world is finally beginning to embrace the idea that ease of use and reduced configurations do not have to interfere with the power of advanced configurability. Convention and configuration reside together within the Maven world, each providing their own unique perspective of a power tool.
A Brief History of Build Tools
There are literally thousands of books, "collateral damage" if you will, filled with supposed "perfect solutions": perfect programming languages, perfect platforms, perfect IDEs, or perfect processes. But far fewer books cover the build tools that are often every bit as important as the languages themselves. Build tools have a historically under-appreciated symbiotic co-history with the programming languages and methodologies that they try to manage. Each has left its own indelible mark on the world of software development; some good (Make), some not so good (shell scripts). But along the way we have inched ever toward the ultimate goals of programming: ease of use, reusability, reliability, portability. Someday Maven, too, will be a footnote in this history adding another step to some unknown end. Until such a time, however, it is currently the best tool we have on our collective belt.
Make / Ant / Maven
In the beginning, there was no standard build tool. If one wanted to compile and link code, cave-dwelling developers were forced to input system commands with their own hairy-knuckled hands; this worked well as long as the whole tribe of developers knew all of the esoteric grunts and commands to make the build work. As their programs increased in complexity, however, it became immediately obvious such methods could be automated using simple tools.
As programming languages themselves have evolved, the focus of incremental improvements have centered on more than just readability and maintainability they were also developed to be more portable. C was a large improvement over previous languages (as was the operating system) in a large part due to its portability between different types of machines. But despite its undeniable success in this realm, machine architectures were largely diametrical, and system tools were incompatible by today's standards. Eventually, shells became more standard, and the ability to script common commands in a common language became more ubiquitous. This caused a new problem. Although a program was portable between machines with similar setups, computers would often contain different tools for completing the same job, such as a different implementation of the C compiler. Building code across various machines still proved rather painful. Enter: Make. Make was a marked improvement over shell scripting due to its abstraction of specific shell commands into a more general and consistent syntax.
Fast forward a few years to the birth of Java, a popular machine-portable programming language created to relieve the burden of cross-compilation by compiling to machine portable byte code. Now the machine-specific aspects of Make made the build tool even less portable than the code it was meant to build, in addition to other issues the frustrated Java developers (who are you to tell me where to put whitespaces?!), July 19 2000 birthed the first release of Ant as an independent build tool.
Ant is a pure Java build tool defined by XML syntax. Its ease of use and agility at extension made this seemingly simple concept explode to the de facto Java build tool in less than a year's time.
Why not just use Ant?
Ant is a great project. So was Make. However, they both suffer from the inherent weakness of the "Inner-Platform Effect" anti-pattern. The Inner-Platform Effect roughly states that by making a system too flexible and configurable, the configuration of the system itself becomes so complex it takes a specialist in order to maintain it - thus re-introducing the problem that the system was attempting to solve. Or in other words, the configuration becomes a platform itself, requiring all of the tools and special knowledge of any programming language... effectively creating a system in a system. For non-trivial projects Ant scripts can become almost as complex than the projects that they are required to build.
Ant is still an excellent tool, and is available as part of the Maven core collection of plugins - enabling you to create custom extensions out of existing Ant scripts, or even embed Ant directly into your project's build lifecycle (more on that later). Maven was created to deal with some of Ant's more egregious limitations. Firstly, the size of an Ant's build file directly correlates to its complexity. In short, the more things you want Ant to do, the larger the build file gets. This is due to the fact that Ant build files are procedural. A user must specify each step that the build system is to take. In Maven, due to its in-built conventions, there is a very good chance that your Maven configuration file will not grow at all (or at least, not grow very much) despite what you use it for because Maven configuration files are declarative. It is up to individual plug-ins and the Maven core to decide how to take action; you need only direct it with a modicum of information about your project.
Second is the question of portability. Ant is portable only if your users have the same set of tasks that you have. It is up to Ant's users to download and manage their own library of tasks, and it is expected that for any particular task, they know which tasks are required - as well as the correct versions. Oftentimes the most prudent method is to bundle the build tools along with the code to be built, which is hardly pragmatic (though problems of this nature can actually be rectified with Ant extensions like Ivy, which in all fairness, uses the Maven repository writ-large). Maven, on the other hand, deals with this problem natively and automatically, making portability effortless, and keeping even the largest teams in synch.
---------------------------
[Ovu poruku je menjao Vanja Petreski dana 10.06.2007. u 20:50 GMT+1]
|