Hi all! Update on this, just to let you know:
The use of the build-helper-plugin did NOT HELP in our situation! I think we will move the embedded libraries from the bundles and bring them as osgi-enabled dependencies into the target platform. I assume, this will then resolve the case. 2012/6/25 Markward Schubert <[email protected]>: > Hey Dave! > > Here is what I tried with the build-helper-plugin: > > <plugin> > <groupId>org.codehaus.mojo</groupId> > <artifactId>build-helper-maven-plugin</artifactId> > <version>1.7</version> > <executions> > <execution> > <id>add-test-resource</id> > <phase>generate-test-sources</phase> > <goals> > <goal>add-test-resource</goal> > </goals> > <configuration> > <resources> > <resource> > <directory>lib</directory> > </resource> > </resources> > </configuration> > </execution> > </executions> > </plugin> > > > "lib" in this case is the name of the folder, where the jars of the > embedded libraries live in my project. This SEEMS to have solved the > problem with my workspace. As I had the impression that the problem > did not occur in 100% of the cases, I can not guarantee, that this > works, but I will keep you informed. > > > Next is a shortened version of the pom from our p2-repository plugin. > I guess we are using nearly all possible ways to pull in dependencies > into a maven-project. Some local files, some ordingary dependencies > with transient dependency resolution and some via the > maven-dependency-plugin. See also the comments please. > > If you have any further questions, just ask, maybe I can help. > > <project xmlns="http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd";> > <modelVersion>4.0.0</modelVersion> > > <properties> > <tycho-version>0.13.0</tycho-version> > <outputfolder>${project.build.directory}/source/plugins</outputfolder> > </properties> > > [...] > > > <artifactId>p2-repository</artifactId> > <packaging>pom</packaging> > > <dependencies> > > <!-- springframework dependencies edited by FlowFact - > MANIFEST.MF contains > info: eclipse-BuddyPolicy: global --> > > <dependency> > <groupId>org.springframework</groupId> > <artifactId>osgi.core</artifactId> > <version>1.2.0.FF</version> > <scope>system</scope> > > <systemPath>${project.basedir}/lib/plugins/org.springframework.osgi.core_1.2.0.FF.jar</systemPath> > </dependency> > > </dependencies> > > <build> > <plugins> > > <!-- The following plugin downloads all bundles which are > not transitive > dependencies of rcp-api. Also if we must have two > different versions of a > dependency in the target platform, those must be > declared here, as there > is no version management for the artifacts below. --> > > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-dependency-plugin</artifactId> > <version>2.3</version> > <executions> > <execution> > <id>copy</id> > <phase>prepare-package</phase> > <goals> > <goal>copy</goal> > </goals> > <configuration> > > <artifactItems> > > <artifactItem> > <groupId>org.apache.commons</groupId> > > <artifactId>com.springsource.org.apache.commons.codec</artifactId> > <version>1.4.0</version> > > <outputDirectory>${outputfolder}</outputDirectory> > </artifactItem> > > <artifactItem> > <groupId>javax.persistence</groupId> > > <artifactId>com.springsource.javax.persistence</artifactId> > <version>2.0.0</version> > > <outputDirectory>${outputfolder}</outputDirectory> > </artifactItem> > > [...] > > </artifactItems> > </configuration> > </execution> > </executions> > </plugin> > > <!-- Configuration for the PublishFeaturesAndBundlesMojoTest --> > <plugin> > <groupId>org.eclipse.tycho.extras</groupId> > <artifactId>tycho-p2-extras-plugin</artifactId> > <version>${tycho-version}</version> > <executions> > <execution> > <phase>package</phase> > <goals> > <goal>publish-features-and-bundles</goal> > </goals> > </execution> > </executions> > <configuration> > <compress>false</compress> > </configuration> > </plugin> > > <!-- Additional two build plug-ins that allow to also > build this project > from the command line --> > <!-- Copying an artifact to location > ${project.basedir}/target/source/plugins > is only one way how to create content to be published. > Any other source of > bundles and/or features can be used to be published as > long as it end up > in ${project.basedir}/target/source/plugins and or > ~/features The publisher > will use every content that is located in this directory --> > <plugin> > <artifactId>maven-dependency-plugin</artifactId> > <executions> > <execution> > <id>copy-bundles-for-publishing</id> > <phase>process-resources</phase> > <goals> > <goal>copy-dependencies</goal> > </goals> > <configuration> > > <outputDirectory>${project.basedir}/target/source/plugins</outputDirectory> > </configuration> > </execution> > </executions> > </plugin> > </plugins> > </build> > > </project> > > > > > > > 2012/6/22 Dave Hartnoll <[email protected]>: >> Hi Markward, >> >> >> >> Thanks for your input. What you describe in your first paragraph certainly >> fits with my own observations and suggests there may be an issue with m2e >> (or maybe it’s being stretched beyond its intended functionality – I’m not >> sure yet). >> >> >> >> I’d be interested to see specifically what you did with >> build-helper-maven-plugin. I had already come across it and read a little >> about it, but was unsure how I might configure it to help the situation. >> >> >> >> <off-topic> >> >> We used to have our external libs linked statically. However, when we >> recently switched to a Maven build process, I wanted to set everything up as >> neat as possible to help with maintenance in the future. That’s why I’m >> trying to get Maven to re-package the libraries for OSGi in a standard way. >> The example I posted was for log4j, and you are right that there are already >> OSGi versions of it available. However, the same is not necessarily true for >> all libraries so I need a standard way to build them (two other examples are >> clojure.org:clojure:1.4.0, and another compound library that I build from >> net.sourceforge.cssparser:cssparser:0.9.7 and org.w3c.css:sac:1.3). >> >> >> >> I’d also be interested in details of how to create the maven-generated p2 >> repository from a collection of libraries as it might be a good alternative >> to the repackaging. Could you provide a reference or perhaps even share the >> relevant part of your pom? >> >> </off-topic> >> >> >> >> Thanks and Regards, >> >> Dave. >> >> >> >> >> >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Markward Schubert >> Sent: 22 June 2012 16:18 >> To: Maven Integration for Eclipse users mailing list >> Subject: Re: [m2e-users] M2E Update Project issue >> >> >> >> Hi Dave! >> >> I think we have/had a similar issue here. We have plenty of manifest first >> projects, among them three with a legacy folder named "lib", where some >> repackaged libs reside. Whenever we change a branch, the ide notices, that >> the projects are not up to date anymore and suggests a call of "Update >> Project Configuration". Doing this will in the first call "destroy" these >> project's project-setup with an error message. Then triggering "Update >> Project Configuration" again, repairs the project. >> >> Today I was experimenting with the build-helper-maven-plugin. >> I am adding the librarie's directory in the plugins configuration and the >> issue seems to be at least reduced, if not resolved. >> >> But: We have the external libs statically in our projects and do not fetch >> them as part of the maven build process. >> >> I don't know if i missed something in your requirements, but do you know the >> Spring Enterprise Bundle Repository at http://ebr.springsource.com ? >> >> They have osgi-copatible versions of many commonly used libraries. Also we >> made the experience, that recent versions of popular libraries are osgi >> compatible in the meantime. We collect these in our project in a maven >> generated p2-repository, which we use in our targetplatform, so we do not >> need to repackage them. >> >> Hope I could help a bit. >> >> Regards, >> Markward >> >> >> >> >> >> 2012/6/22 Dave Hartnoll <[email protected]> >> >> I am aware of maven-dependency-plugin not being supported. However, I am >> fairly certain that my use of it in the project is safe, and is not the >> cause of the .classpath anomalies I highlighted. As I mentioned in the >> original post, I am getting similar .classpath issues on a multi-package >> maven-structured Java project. This other project definitely does not use >> the maven-dependency-plugin. >> >> It's difficult to re-construct this simple project without >> maven-dependency-plugin as I need somehow to get the dependent library >> copied into the workspace. However, I can simply comment-out the references >> to the plugin after the project has been built for the first time as the >> library is then always present in target/libs (until a clean is done). After >> saving the pom with maven-dependency-plugin removed, and re-running Update >> Project several times, I still see the same .classpath anomolies. >> >> Dave. >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Igor Fedorenko >> Sent: 22 June 2012 14:50 >> To: [email protected] >> Subject: Re: [m2e-users] M2E Update Project issue >> >> Running maven-dependency-plugin inside workspace is not supported. From m2e >> wiki [1] >> >> <quote> >> Beware that m2e does not provide any safeguards against rogue maven plugins >> that leak classloaders, modify random files inside workspace or throw nasty >> exceptions to fail the build. Use this as the last resort and make sure you >> know what you are doing. >> </quote> >> >> Can you reproduce the problem without this? >> >> [1] >> http://wiki.eclipse.org/M2E_plugin_execution_not_covered#execute_plugin_goal >> >> -- >> Regards, >> Igor >> >> On 12-06-22 9:23 AM, Dave Hartnoll wrote: >>> I am putting together a large Eclipse RCP project using Eclipse 3.7.2, >>> Tycho 0.15.0 and m2e 1.1 latest. On several occasions, I have seen errors >>> along the lines of "The project is not up to date with the pom. Run Update >>> Project" (paraphrasing from memory). This happens more often when updating a >>> project from source control such as when committing changes from one PC and >>> updating on another. The problem is that running Maven->Update Project... >>> does not always resolve the problem immediately - it sometimes has to be run >>> twice - with no net change in any of the project data. >>> >>> I've managed to extract and simplify a single small project that can be >>> used to repeat some of the anomalies I am seeing. This project simply >>> repackages a standard jar library (Log4j) as an OSGi plug-in. There may be >>> better ways to do this, and as an aside I'd be interested to hear them, but >>> this is really irrelevant for now as I get similar issues with a larger >>> multi-package maven-structured Java project too. >>> >>> The attached .zip contains the necessary Eclipse project files. >>> 1. Create a new general project (File->New->Project... then >>> General->Project) >>> 2. Copy the contents of the .zip to the project (overwriting the >>> existing .project file). >>> 3. Right-click project, choose Run As->Maven build >>> 4. In the 'Edit Configuration' dialogue, type 'package' into the Goals >>> field >>> 5. Click 'Refresh' tab; click 'Refresh resources upon completion' >>> 6. Click 'Run' >>> >>> Maven should now download some artifacts and build the OSGi version of the >>> Log4j library. >>> >>> Next, open the .classpath from the project so you can see what happens >>> during the next steps. (If you can't see .classpath, open the Package >>> Explorer menu - the down-pointing white triangle - and select >>> 'Filters...'. In the next dialogue, uncheck '.* resources' and click >>> OK.) >>> >>> Now here is the weird behaviour... >>> a. Right-click the project and select 'Maven->Update Project...'. >>> Click OK in the next dialogue. >>> b. Notice what happens to the contents of .classpath >>> >>> Repeat steps a and b a few more times and notice how eventually the >>> project toggles between two states, one of which is OK (but contains more >>> than necessary) and the other which has errors - the .classpath only >>> references a 'classes' folder (that is also not necessary), but loses the >>> reference to the needed library. >>> >>> I'm not sure if this is purely an m2e bug or an >>> understanding/configuration issue that has caused m2e to behave strangely. >>> Any help gratefully received. (NB: although I'm using m2e 1.1 latest from >>> sonatype's repo, I'm seeing similar issues with m2e 1.0 from eclipse.org). >>> >>> Dave. >>> >>> P.S. In case anyone can't access the .zip file, I've listed the 5 >>> files that seed the Eclipse project below >>> >>> ===================================================== >>> META-INF\MANIFEST.MF >>> ===================================================== >>> Manifest-Version: 1.0 >>> Bundle-ManifestVersion: 2 >>> Bundle-Name: Log4j as OSGI plugin >>> Bundle-SymbolicName: jar2plugin.log4j >>> Bundle-Version: 1.2.16 >>> Bundle-ClassPath: target/libs/log4j-1.2.16.jar >>> Export-Package: org.apache.log4j, >>> org.apache.log4j.xml >>> Bundle-RequiredExecutionEnvironment: JavaSE-1.6 >>> >>> >>> ===================================================== >>> .classpath >>> ===================================================== >>> <?xml version="1.0" encoding="UTF-8"?> <classpath> >>> <classpathentry kind="lib" path="target/libs/log4j-1.2.16.jar"/> >>> </classpath> >>> >>> >>> ===================================================== >>> .project >>> ===================================================== >>> <?xml version="1.0" encoding="UTF-8"?> >>> <projectDescription> >>> <name>jar2plugin.log4j</name> >>> <comment></comment> >>> <projects> >>> </projects> >>> <buildSpec> >>> <buildCommand> >>> <name>org.eclipse.pde.ManifestBuilder</name> >>> <arguments> >>> </arguments> >>> </buildCommand> >>> <buildCommand> >>> <name>org.eclipse.m2e.core.maven2Builder</name> >>> <arguments> >>> </arguments> >>> </buildCommand> >>> </buildSpec> >>> <natures> >>> <nature>org.eclipse.m2e.core.maven2Nature</nature> >>> <nature>org.eclipse.pde.PluginNature</nature> >>> <nature>org.eclipse.jdt.core.javanature</nature> >>> </natures> >>> </projectDescription> >>> >>> >>> ===================================================== >>> build.properties >>> ===================================================== >>> bin.includes = META-INF/,\ >>> .,\ >>> target/libs/log4j-1.2.16.jar >>> >>> >>> ===================================================== >>> pom.xml >>> ===================================================== >>> <project xmlns="http://maven.apache.org/POM/4.0.0"; >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 >>> http://maven.apache.org/xsd/maven-4.0.0.xsd";> >>> <modelVersion>4.0.0</modelVersion> >>> <groupId>jar2plugin</groupId> >>> <artifactId>jar2plugin.log4j</artifactId> >>> <version>1.2.16</version> >>> <packaging>eclipse-plugin</packaging> >>> >>> <properties> >>> <tycho-version>0.15.0</tycho-version> >>> >>> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> >>> </properties> >>> >>> <dependencies> >>> <dependency> >>> <groupId>log4j</groupId> >>> <artifactId>log4j</artifactId> >>> <version>1.2.16</version> >>> <type>jar</type> >>> <scope>compile</scope> >>> </dependency> >>> </dependencies> >>> >>> <build> >>> <plugins> >>> >>> <plugin> >>> <groupId>org.eclipse.tycho</groupId> >>> <artifactId>tycho-maven-plugin</artifactId> >>> <version>${tycho-version}</version> >>> <extensions>true</extensions> >>> </plugin> >>> >>> <plugin> >>> <groupId>org.apache.maven.plugins</groupId> >>> >>> <artifactId>maven-dependency-plugin</artifactId> >>> <executions> >>> <execution> >>> <id>copy-dependencies</id> >>> <phase>initialize</phase> >>> <goals> >>> >>> <goal>copy-dependencies</goal> >>> </goals> >>> <configuration> >>> >>> <excludeTransitive>true</excludeTransitive> >>> >>> <includeArtifactIds>log4j</includeArtifactIds> >>> >>> <outputDirectory>target/libs</outputDirectory> >>> >>> <overWriteReleases>true</overWriteReleases> >>> >>> <overWriteSnapshots>true</overWriteSnapshots> >>> >>> <overWriteIfNewer>true</overWriteIfNewer> >>> </configuration> >>> </execution> >>> </executions> >>> </plugin> >>> >>> </plugins> >>> >>> <pluginManagement> >>> <plugins> >>> <plugin> >>> <groupId>org.eclipse.m2e</groupId> >>> >>> <artifactId>lifecycle-mapping</artifactId> >>> <version>1.0.0</version> >>> <configuration> >>> <lifecycleMappingMetadata> >>> <pluginExecutions> >>> >>> <pluginExecution> >>> >>> <pluginExecutionFilter> >>> >>> <groupId>org.apache.maven.plugins</groupId> >>> >>> <artifactId>maven-dependency-plugin</artifactId> >>> >>> <versionRange>[0.0.0,)</versionRange> >>> >>> <goals> >>> >>> <goal>copy-dependencies</goal> >>> >>> <goal>unpack</goal> >>> >>> </goals> >>> >>> </pluginExecutionFilter> >>> >>> <action> >>> >>> <execute> >>> >>> <runOnIncremental>false</runOnIncremental> >>> >>> </execute> >>> >>> </action> >>> >>> </pluginExecution> >>> </pluginExecutions> >>> </lifecycleMappingMetadata> >>> </configuration> >>> </plugin> >>> </plugins> >>> </pluginManagement> >>> </build> >>> >>> </project> >>> >>> >>> >>> _______________________________________________ >>> m2e-users mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>> >> >> _______________________________________________ >> m2e-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/m2e-users >> _______________________________________________ >> m2e-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/m2e-users >> >> >> >> >> _______________________________________________ >> m2e-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/m2e-users >> _______________________________________________ m2e-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/m2e-users
