root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

SPR-6092: add section on Ivy

This commit is contained in:
David Syer 2009-12-04 12:47:47 +00:00
parent 0400ccc11f
commit ebd15e3287
1 changed files with 108 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

162
spring-framework-reference/src/overview.xml
View File

@ -415,7 +415,9 @@ TR: OK. Added to diagram.--></para>
(<code>org.springframework.*-&lt;version&gt;.jar</code>), and the (<code>org.springframework.*-&lt;version&gt;.jar</code>), and the
dependencies are also in this "long" form, with external libraries dependencies are also in this "long" form, with external libraries
(not from SpringSource) having the prefix (not from SpringSource) having the prefix
<code>com.springsource</code>.</para> <code>com.springsource</code>. See the <ulink security=""
url="http://www.springsource.com/repository/app/faq">FAQ</ulink>
for more information.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -576,10 +578,23 @@ TR: OK. Added to diagram.--></para>
libraries in order to use Spring for simple use cases. For basic libraries in order to use Spring for simple use cases. For basic
dependency injection there is only one mandatory external dependency, dependency injection there is only one mandatory external dependency,
and that is for logging (see below for a more detailed description of and that is for logging (see below for a more detailed description of
logging options). If you are using Maven for dependency management you logging options).</para>
don't even need to supply the logging dependency explicitly. For
example, to create an application context and use dependency injection <para>Next we outline the basic steps needed to configure an
to configure an application, your Maven dependencies will look like application that depends on Spring, first with Maven and then with
Ivy. In all cases, if anything is unclear, refer to the documentation
of your dependency management system, or look at some sample code -
Spring itself uses Ivy to manage dependencies when it is building, and
our samples mostly use Maven.</para>
</section>
<section>
<title>Maven Dependency Management</title>
<para>If you are using Maven for dependency management you don't even
need to supply the logging dependency explicitly. For example, to
create an application context and use dependency injection to
configure an application, your Maven dependencies will look like
this:</para> this:</para>
<para><programlisting>&lt;dependencies&gt; <para><programlisting>&lt;dependencies&gt;
@ -659,14 +674,53 @@ TR: OK. Added to diagram.--></para>
that can be used to search for and download dependencies. It also has that can be used to search for and download dependencies. It also has
handy snippets of Maven and Ivy configuration that you can copy and handy snippets of Maven and Ivy configuration that you can copy and
paste if you are using those tools.</para> paste if you are using those tools.</para>
</section>
<para>If you prefer to use <ulink url="http://ant.apache.org/ivy"> <section>
Ivy</ulink> to manage dependencies then there are <title>Ivy Dependency Management</title>
similar names and configuration options there (refer to the
documentation of your dependency management system, or look at some
sample code - Spring itself uses Ivy to manage dependencies when it is
building).</para>
<para>If you prefer to use <ulink
url="http://ant.apache.org/ivy">Ivy</ulink> to manage dependencies
then there are similar names and configuration options. </para>
<para>To configure Ivy to point to the SpringSource EBR add the
following resolvers to your
<filename>ivysettings.xml</filename>:</para>
<programlisting>&lt;resolvers&gt;
&lt;url name="com.springsource.repository.bundles.release"&gt;
&lt;ivy pattern="http://repository.springsource.com/ivy/bundles/release/
[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /&gt;
&lt;artifact pattern="http://repository.springsource.com/ivy/bundles/release/
[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /&gt;
&lt;/url&gt;
&lt;url name="com.springsource.repository.bundles.external"&gt;
&lt;ivy pattern="http://repository.springsource.com/ivy/bundles/external/
[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /&gt;
&lt;artifact pattern="http://repository.springsource.com/ivy/bundles/external/
[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /&gt;
&lt;/url&gt;
&lt;/resolvers&gt;</programlisting>
<para>The XML above is not valid because the lines are too long - if
you copy-paste then remove the extra line endings in the middle of the
url patterns.</para>
<para>Once Ivy is configured to look in the EBR adding a dependency is
easy. Simply pull up the details page for the bundle in question in
the repository browser and you'll find an Ivy snippet ready for you to
include in your dependencies section. For example (in
<filename>ivy.xml</filename>): </para>
<programlisting>&lt;dependency org="org.springframework"
name="org.springframework.core" rev="3.0.0.RELEASE" conf="compile-&gt;runtime"/&gt;</programlisting>
</section> </section>
</section> </section>
@ -697,32 +751,33 @@ TR: OK. Added to diagram.--></para>
Spring and specifically from the central module called Spring and specifically from the central module called
<code>spring-core</code>.</para> <code>spring-core</code>.</para>
<para>The nice thing about <code>commons-logging</code> is that you don't need <para>The nice thing about <code>commons-logging</code> is that you
anything else to make your application work. It has a runtime discovery don't need anything else to make your application work. It has a runtime
algorithm that looks for other logging frameworks in well known places discovery algorithm that looks for other logging frameworks in well
on the classpath and uses one that it thinks is appropriate (or you can known places on the classpath and uses one that it thinks is appropriate
tell it which one if you need to). If nothing else is available you get (or you can tell it which one if you need to). If nothing else is
pretty nice looking logs just from the JDK (java.util.logging or JUL for available you get pretty nice looking logs just from the JDK
short). You should find that your Spring application works and logs (java.util.logging or JUL for short). You should find that your Spring
happily to the console out of the box in most situations, and that's application works and logs happily to the console out of the box in most
important.</para> situations, and that's important.</para>
<section> <section>
<title>Not Using Commons Logging</title> <title>Not Using Commons Logging</title>
<para>Unfortunately, the worst thing about <code>commons-logging</code>, and what <para>Unfortunately, the worst thing about
has made it unpopular with new tools, is also the runtime discovery <code>commons-logging</code>, and what has made it unpopular with new
algorithm. If we could turn back the clock and start Spring now as a tools, is also the runtime discovery algorithm. If we could turn back
new project it would use a different logging dependency. Probably the the clock and start Spring now as a new project it would use a
first choice would be the Simple Logging Framework for Java (<ulink different logging dependency. Probably the first choice would be the
url="http://www.slf4j.org">SLF4J</ulink>), Simple Logging Framework for Java (<ulink
which is also used by a lot of other tools url="http://www.slf4j.org">SLF4J</ulink>), which is also used by a lot
that people use with Spring inside their applications.</para> of other tools that people use with Spring inside their
applications.</para>
<para>To switch off <code>commons-logging</code> is easy: just make sure it isn't <para>To switch off <code>commons-logging</code> is easy: just make
on the classpath at runtime. In Maven terms you exclude the sure it isn't on the classpath at runtime. In Maven terms you exclude
dependency, and because of the way that the Spring dependencies are the dependency, and because of the way that the Spring dependencies
declared, you only have to do that once.</para> are declared, you only have to do that once.</para>
<programlisting>&lt;dependencies&gt; <programlisting>&lt;dependencies&gt;
&lt;dependency&gt; &lt;dependency&gt;
@ -750,28 +805,28 @@ TR: OK. Added to diagram.--></para>
</section> </section>
<para>SLF4J is a cleaner dependency and more efficient at runtime than <para>SLF4J is a cleaner dependency and more efficient at runtime than
<code>commons-logging</code> because it uses compile-time bindings instead of runtime <code>commons-logging</code> because it uses compile-time bindings
discovery of the other logging frameworks it integrates. This also means instead of runtime discovery of the other logging frameworks it
that you have to be more explicit about what you want to happen at integrates. This also means that you have to be more explicit about what
runtime, and declare it or configure it accordingly. SLF4J provides you want to happen at runtime, and declare it or configure it
bindings to many common logging frameworks, so you can usually choose accordingly. SLF4J provides bindings to many common logging frameworks,
one that you already use, and bind to that for configuration and so you can usually choose one that you already use, and bind to that for
management.</para> configuration and management.</para>
<para>SLF4J provides bindings to many common logging frameworks, <para>SLF4J provides bindings to many common logging frameworks,
including JCL, and it also does the reverse: bridges between other including JCL, and it also does the reverse: bridges between other
logging frameworks and itself. So to use SLF4J with Spring you need to logging frameworks and itself. So to use SLF4J with Spring you need to
replace the <code>commons-logging</code> dependency with the SLF4J-JCL bridge. Once replace the <code>commons-logging</code> dependency with the SLF4J-JCL
you have done that then logging calls from within Spring will be bridge. Once you have done that then logging calls from within Spring
translated into logging calls to the SLF4J API, so if other libraries in will be translated into logging calls to the SLF4J API, so if other
your application use that API, then you have a single place to configure libraries in your application use that API, then you have a single place
and manage logging.</para> to configure and manage logging.</para>
<para>A common choice might be to bridge Spring to SLF4J, and then <para>A common choice might be to bridge Spring to SLF4J, and then
provide explicit binding from SLF4J to Log4J. You need to supply 4 provide explicit binding from SLF4J to Log4J. You need to supply 4
dependencies (and exclude the existing <code>commons-logging</code>): the bridge, the dependencies (and exclude the existing <code>commons-logging</code>):
SLF4J API, the binding to Log4J, and the Log4J implementation itself. In the bridge, the SLF4J API, the binding to Log4J, and the Log4J
Maven you would do that like this</para> implementation itself. In Maven you would do that like this</para>
<programlisting>&lt;dependencies&gt; <programlisting>&lt;dependencies&gt;
&lt;dependency&gt; &lt;dependency&gt;
@ -821,13 +876,12 @@ TR: OK. Added to diagram.--></para>
<para>A more common choice amongst SLF4J users, which uses fewer steps <para>A more common choice amongst SLF4J users, which uses fewer steps
and generates fewer dependencies, is to bind directly to <ulink type="" and generates fewer dependencies, is to bind directly to <ulink type=""
url="http://logback.qos.ch">Logback</ulink>. url="http://logback.qos.ch">Logback</ulink>. This removes the extra
This removes the extra binding step because binding step because Logback implements SLF4J directly, so you only need
Logback implements SLF4J directly, so you only need to depend on two to depend on two libaries not four (<code>jcl-slf4j</code> and
libaries not four (<code>jcl-slf4j</code> and <code>logback</code>). If <code>logback</code>). If you do that you might also need to exlude the
you do that you might also need to exlude the slf4j-api dependency from slf4j-api dependency from other external dependencies (not Spring),
other external dependencies (not Spring), because you only want one because you only want one version of that API on the classpath.</para>
version of that API on the classpath.</para>
<section> <section>
<title>Using Log4J</title> <title>Using Log4J</title>