- Register the p2 artifact repository with the published bundles in a central registry (the ArtifactRepositoryBlackboard). The blackboard implements the artifact repository factory extension point and therefore the registered artifact repositories can be loaded through the normal p2 APIs. - The artifact repositories are registered under a special key (see RepositoryBlackboardKey) which is unique for each module. - The p2 Mojos include the artifact repository with the published bundles of the current module by adding the special key as source/context p2 repository. Through this, POM dependency artifacts can for example be mirrored into an eclipse-repository. This commit resolves TYCHO-570 aka bug 342851. Bug: 342851 Artifacts from POM dependencies missing in eclipse-repository
The the location of the local Maven repository already in the contructor of ResolutionContext so that it can be passes to the classes that the ResolutionContext implementation is composed of.
- ... in order to share it between different packages the same bundle. - The utilities package derives from "org.eclipse.tycho.repository", which eventually shall replace the "org.eclipse.tycho.p2.maven.repository" package. The "p2" and "maven" sections are unnecessary, because all repositories implemented in Tycho deal with bridging the gap between the Maven repository world and p2 repository world.
- Collect artifact descriptors of bundles which are published on the fly when being added to the resolution context. This is necessary because these artifacts are not visible in any p2 repository. - Knowing that the bundle is stored in the local Maven repository, there is no need to store the artifact again, but the bundle artifacts can be made available in an IArtifactRepository through a new sub-class of the refactored AbstractMavenArtifactRepository.
- With the IFileArtifactRepository interface, the publishers can distinguish new artifacts from existing artifacts. This will be useful when new attached artifacts are created by a publisher, e.g. a product publisher. The only existing case where this is done (FeatureRootfileArtifactRepository) doesn't use this feature yet. - Extended RepositoryReader interface to also provide the location of artifacts and not only a stream. Also introduce an abstract base for the extended interface.
- Consolidate the implementations for reading through the p2 IArifactRepository interface in the base class. AbstractMavenArtifactRepository is now a convenient base for readable and writable IArtifactRepository implementations backed by a Maven artifact repository. Additional changes: - Support initialization of the repository content without an TychoRepositoryIndex. - Added missing implementation of addDescriptors (which really should be in the abstract base class from p2, but currently isn't). - Consolidate methods in sub-classes through default implementations in AbstractMavenArtifactRepository.
- The method getContents(String) could not be implemented correctly by all implemetors of the interface. This is an indication that the interface may need to be split. However since the method is not needed acoss the facade, it was simply removed from the RepositoryReader interface.
- The cause of bug 346532 was that PublisherInfo instances were shared when publishing the products of an eclipse-repository. This leads to incorrect results, because the publisher actions use the PublisherInfo instance as black-board and store for example the dependencies of the published product in that instance. - With this commit, the PublisherInfo instances are no longer shared between publisher calls. Bug: 346532 Content leaks between products in the same eclipse-repository projects
- Created a class ResourceUtil that shall be used as single entry point for accessing test resources. The class includes the P2Repository enum, as one special type of resource. Additional change - Set system propert via explicit Verifier API rather manually composing a "-D" command line parameter
- The code in the touched files has been written by SAP employees. - It seems that the project "org.eclipse.tycho.p2.resolver.impl" (formerly "org.eclipse.tycho.p2.impl") was omitted in error when the copyright headers were initially generated in commit be5c841.
- The fact that default values of the target-platform-configuration were repeated in two classes was the reason why bug 341654 could occur. Now the defaults are only specified once: in the initializers of org.eclipse.tycho.core.TargetPlatformConfiguration. Bug: 341654 Tycho repositories enables if target-platform-configuration is omitted
- Fixed/adapted P2Resolver* tests which were using "wrong" methods for their test setup, relying on implementation details or the former implementation of addMavenProject (which changed last commit). - Refactored tests to apply DRY principle. - Restricted P2Resolver to be only able to resolve reactor projects. This allows small simplififications in ResolutionContextImpl.
- This is the only real use case: reference OSGi bundles built by other Maven tools. These artifacts don't have associated p2 metadata, so the metadata needs to be generated on the fly. - Added tests for expected behaviour. - Technically ensure that other artifact types are not published by not re-using the P2Generator.
Updated pom-first build to demonstrate how to use thirdparty libraries available from Maven repositories. Used plexus-utils as an example, probably not the best choice as it is already included in m2e.maven.runtime, but should be good enough to explain the point. Signed-off-by: Igor Fedorenko <firstname.lastname@example.org>
- Added method for warnings. The stub implementation for testing can treat a warning as fatal. - Distinguish between general debugging and "extended" debugging (currently used to print out the full p2 resolution context). This is quite crude, but I am not aware of a more fine-grained Maven log configuration that could be exposed through the MavenLogger iterface instead.
- The resolution context is the context in which the dependencies of a project can be resolved. In other words: the resolver takes a resolution context and creates a target platform. - Since the resolution context can be quite complex, it is justified to implemented it in a separate class. In fact, the implementation might be split up even further - horizontal lines in ResolutionContextImpl indicate where this could be done.
- P2TargetPlatformResolver is the p2 resolver for Tycho, so it should be in the org.eclipse.tycho.p2.resolver package. The fact that it is implemented with the help of OSGi bundle code (-> package p2.resolver.impl) is an implementation detail of the P2TargetPlatformResolver that should not be visible in the package name. - Renamed packages in OSGi/Maven class loader facade (added "facade") to free up p2.resolver package name. - Also: Renamed P2Logger to MavenLogger because it exposes the Maven/Plexus logger in the Tycho OSGi runtime. (Although the Tycho OSGi runtime is mainly used for p2, only classes related to p2 should have "p2" in the name.) Please enter the commit message for your changes. Lines starting
- Make the actual logic of POM dependency handling visible - Also: fail build if only p2metadata.xml can be downloaded but not p2artifacts.xml (or vice versa) because I can only imagine this situation in case of corrupted data or network issues.
This is not a major change because Equinox has osgi.compatibility.bootdelegation set to true by default. Therefore the Maven class loader is still queried as last resort (which is mainly needed because bundles do not properly declare package imports of non-java.* packages.) Nevertheless, with this change the OSGi class loading mechanisms (including system.packages.extra) are preferred over the boot class loader. This improves class loading performance (see http://wiki.eclipse.org/Equinox_Boot_Delegation )
- The (rudimentary) map file support has already been removed in bed5809. Since the test was disabled, it had been overlooked. - Benefit: we get rid of one checked in zip file (which is an issue for the Tycho CQ).