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
