sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From o...@apache.org
Subject svn commit: r1585099 - in /sling/site/trunk/content: documentation/development/dependency-management.mdtext site/.htaccess site/dependency-management.html
Date Sat, 05 Apr 2014 15:07:29 GMT
Author: olli
Date: Sat Apr  5 15:07:28 2014
New Revision: 1585099

URL: http://svn.apache.org/r1585099
Log:
finalize translation, fix some glitches

Removed:
    sling/site/trunk/content/site/dependency-management.html
Modified:
    sling/site/trunk/content/documentation/development/dependency-management.mdtext
    sling/site/trunk/content/site/.htaccess

Modified: sling/site/trunk/content/documentation/development/dependency-management.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/development/dependency-management.mdtext?rev=1585099&r1=1585098&r2=1585099&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/development/dependency-management.mdtext (original)
+++ sling/site/trunk/content/documentation/development/dependency-management.mdtext Sat Apr
 5 15:07:28 2014
@@ -1,4 +1,3 @@
-translation_pending: true
 Title: Dependency Management
 Excerpt: This page is about how we do and don't do dependency management in the Sling project.
 
@@ -14,37 +13,39 @@ After working with this some time and tr
 
 Why ? Maven's dependency management is aimed at traditional applicaitons, which are glued
together statically during the build process. For this environment, dependency management
is a great thing, since it guarantees a consistent application setup.
 
-In a dynamic application setup as provided by an OSGi framework the static dependency management
of Maven does not help. Actually it even causes problematic results with respect to backwards
compatibility when using the Maven Bundle plugin.
+In a dynamic application setup as provided by an OSGi framework the static dependency management
of Maven does not help. Actually it even causes problematic results with respect to backwards
compatibility when using the Maven Bundle Plugin.
 
-Why's that ? The Maven Bundle plugin is constructs the bundle manifest and will generally
automatically create the Import-Package header. If the providing library (from maven's dependency
list) has `Export-Package` headers with version numbers, the Maven Bundle plugin will insert
the respective version numbers for the `Import-Package` header. This makes perfect sense,
because it is expected, that the artifact required at least the given package version.
+Why's that ? The Maven Bundle Plugin constructs the bundle manifest and will generally automatically
create the Import-Package header. If the providing library (from Maven's dependency list)
has `Export-Package` headers with version numbers, the Maven Bundle Plugin will insert the
respective version numbers for the `Import-Package` header. This makes perfect sense, because
it is expected, that the artifact required at least the given package version.
 
-When using Maven dependency management, upgrading any dependencies in the parent POM may
automatically increse the version numbers in the `Import-Package` headers and hence may cause
any such bundle to fail resolution if deployed - even though the bundle did not change and
does not really require a new version of the dependency.
+When using Maven dependency management, upgrading any dependencies in the parent POM may
automatically increase the version numbers in the `Import-Package` headers and hence may cause
any such bundle to fail resolution if deployed - even though the bundle did not change and
does not really require a new version of the dependency.
 
 So, in the case of OSGi deployment, Maven's dependency management actually interferes with
the OSGi framework dependency management.
 
-As a consequence, I suggest we drop dependency management in the parent pom (almost) completely
and state the followin.
+As a consequence, I suggest we drop dependency management in the parent POM (almost) completely
and state the following.
 
 
 ## Dependency Management
 
 
-The parent pom only does dependency management for build time dependencies and a very limited
number of API dependencies used Sling wide. These dependencies are:
+The parent POM only does dependency management for build time dependencies and a very limited
number of API dependencies used Sling wide. These dependencies are:
 
-   * All plugin dependencies. That is `PluginManagement` is still used. Maven plugins are
actualy build time dependencies and therefore have no influence on the actual deployment.
+   * All plugin dependencies. That is `pluginManagement` is still used. Maven plugins are
actually build time dependencies and therefore have no influence on the actual deployment.
    * Dependencies on commonly used testing environment helpers. Test helper classes are also
build time dependencies used to run the unit and integration tests. As such, they may well
be managed.
-   * Sling makes a small number of assumptions about the environment, which we codify in
the dependency management: The minimum version number of the OSGi specificaiton used, the
servlet API version and the JCR API version.
+   * Sling makes a small number of assumptions about the environment, which we codify in
the dependency management: The minimum version number of the OSGi specificaiton used, the
Servlet API version and the JCR API version.
 
-The `<DependencyManagement>` element currently contains the following managed dependencies:
+The `<dependencyManagement>` element currently contains the following managed dependencies:
 
 | Group ID | Artifact ID | Version | Scope |
 |--|--|--|--|
-| org.apache.felix | org.osgi.core | 1.2.0 | provided |
-| org.apache.felix | org.osgi.compendium | 1.2.0 | provided |
+| org.osgi | org.osgi.core | 4.1.0 | provided |
+| org.osgi | org.osgi.compendium | 4.1.0 | provided |
 | javax.servlet | servlet-api | 2.4 | provided |
 | javax.jcr | jcr | 1.0 | provided |
 | org.slf4j | slf4j-api | 1.5.2 | provided |
-| junit | junit | 4.3 | test |
-| org.jmock | jmock-junit4 | 2.2.0 | test |
+| org.apache.felix | org.apache.felix.scr.annotations | 1.9.8 | provided |
+| biz.aQute | bndlib | 1.50.0 | provided |
+| junit | junit | 4.11 | test |
+| org.jmock | jmock-junit4 | 2.5.1 | test |
 | org.slf4j | slf4j-simple | 1.5.2 | test |
 
 
@@ -57,5 +58,5 @@ Generally there is a constant flow of re
 
 ## References
 
-* [Dependency ManagementLink to this message](http://markmail.org/message/5qpmsukdk4mdacdy)
-- Discussion thread about reducing Maven 2 `DependencyManagement`
+* [Dependency Management](http://markmail.org/message/5qpmsukdk4mdacdy) -- Discussion thread
about reducing Maven Dependency Management
 * [SLING-811](https://issues.apache.org/jira/browse/SLING-811) -- The actual issue governing
the changes to the project descriptors
\ No newline at end of file

Modified: sling/site/trunk/content/site/.htaccess
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/site/.htaccess?rev=1585099&r1=1585098&r2=1585099&view=diff
==============================================================================
--- sling/site/trunk/content/site/.htaccess (original)
+++ sling/site/trunk/content/site/.htaccess Sat Apr  5 15:07:28 2014
@@ -74,3 +74,4 @@ Redirect Permanent /site/contributing.ht
 Redirect Permanent /site/project-information.html /project-information.html
 Redirect Permanent /site/release-management.html /documentation/development/release-management.html
 Redirect Permanent /site/scheduler-service-commons-scheduler.htm /documentation/bundles/scheduler-service-commons-scheduler.html
+Redirect Permanent /site/dependency-management.html /documentation/development/dependency-management.html



Mime
View raw message