bd5a3d190be2a6a6610fc5266c38348204a69d7a
Added 'buildSrc' directory as a git submodule to be shared across
all Spring open-source projects. This eliminates the need to maintain
custom Gradle code within Spring Integration directly.
For a brief introduction to git submodules, see
http://speirs.org/blog/2009/5/11/understanding-git-submodules.html
And of course the official documentation is at
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial
Conflicts:
spring-integration-twitter/src/main/java/org/springframework/integration/twitter/core/Twitter4jTemplate.java
spring-integration-twitter/src/test/java/org/springframework/integration/twitter/inbound/SearchReceivingMessageSourceTests.java
============================== Spring Integration =============================
To check out the project and build from source, do the following:
git clone --recursive git://git.springsource.org/spring-integration/spring-integration.git
cd spring-integration
./gradlew build
Note: the --recursive switch above is important, as spring-integration uses
git submodules, which must themselves be cloned and initialized. If --recursive
is omitted, doing so becomes a multi-step process.
-------------------------------------------------------------------------------
To generate Eclipse metadata (.classpath and .project files), do the following:
./gradlew eclipse
Once complete, you may then import the projects into Eclipse as usual:
File -> Import -> Existing projects into workspace
Browse to the 'spring-integration' root directory. All projects should import
free of errors.
-------------------------------------------------------------------------------
To generate IDEA metadata (.iml and .ipr files), do the following:
./gradlew idea
-------------------------------------------------------------------------------
To build the JavaDoc, do the following from within the root directory:
./gradlew :docs:api
The result will be available in 'docs/build/api'.
###### OSGI Notes ######
1. Dependency on Third Party Bundles
Some adapters depend on third party libraries (bundles).
Spring hosts the Enterprise Bundle Repository (EBR) at
https://ebr.springsource.com/repository/app/, where you can download
many third-party JARs as valid OSGi bundles.
If a particular bundle is not available in Spring's EBR, there are tools
that can convert regular JAR to a bundle JAR. One of them is Bundlor
http://www.springsource.org/bundlor which can auto-generate an OSGi
MANIFEST.MF as part of standard project lifecycle or simply convert a
non-bundle JAR to a bundle JAR.
2. Boot delegation
Some adapters depend on extension packages that are available to the boot
class loader. As a case in point, the Feed Adapter depends on
com.sun.syndication.feed. Since by default OSGi only loads java.* from the
boot class loader, other packages that must be loaded from the boot class
loader can therefore be specified with the
'org.osgi.framework.bootdelegation' System property.
For example:
org.osgi.framework.bootdelegation=com.sun.*,org.w3c.*. . . .
===============================================================================
Description
Languages
Java
99%
XSLT
0.9%