Let us say, my project structure in AEM server is as follows-
/apps/myproject/components/compA
/apps/myproject/components/compB
And my project structure in SVN is as follows -
/apps/myproject/components/compA
/apps/myproject/components/compB
/apps/myproject/components/compC
Now, I want that compC should not be installed while installing package, hence I've added filter in pom.xml -
<filter>
<mode>update</mode>
<root>/apps/myproject</root>
<excludes>
<exclude>/apps/myproject/components/compC(/.*)?</exclude>
</excludes>
</filter>
But it does not work, after package installation compC also gets installed. Please let me know if what is missing here.
Related
I’m starting to use the p2-maven-plugin in order to integrate non-OSGi JARs into our project in a (hopefully) convenient manner.
I have an artifact which I want to OSGi-ify, called com.thirdparty.artifact. I’m current using p2-maven-plugin’s standard configuration, and I list my artifact in the pom.xml like so:
<artifact><id>com.thirdparty:artifact:1.2.3</id></artifact>
This artifact has a transitive dependency called com.thirdparty:library:2.5, which exports a package com.thirdparty.library which is in turn imported by com.thirdparty:artifact. When I run mvn p2:site, I get a P2 site which contains com.thirdparty:artifact:1.2.3 and com.thirdparty:library:2.5 -- all fine so far.
Now, things are turning messy. My existing target platform already contains an artifact called com.othervendor:library (different vendor, it’s there and I cannot change that), which also exports the very same package com.thirdparty.library (but an entirely different version).
At runtime, the OSGi/Eclipse black magic (which I’ll probably never fully understand) tries to resolve com.thirdparty:artifact’s dependency on the package com.thirdparty.library using the com.othervendor:library and not my provided com.thirdparty:library:2.5 -- and I’m obviously in trouble. Here’s a visualization of my situation:
Being absolutely no OSGi rocket scientist, my first idea was to inspect the MANIFEST.MF in com.thirdparty:artifact. Beside others, this shows the following:
Import-Package: com.thirdparty.library
So, this obviously just tells com.thirdparty:artifact to import this package from some bundle, and OSGi/Eclipse thinks “okay, com.othervendor:library is more adequate than com.thirdparty:library”.
There seem to be two methods of narrowing down the dependencies to actually use. However: I’m not sure (a) how to integrate them into my p2-maven-plugin workflow, and (b) I do not understand why p2-maven-plugin does not automatically require the concrete package version in the Import-Package directive (this information is after all already specified in the source pom.xml).
Probably I’m not seeing the forest for the trees here. So any general advice beside my questions above is very welcome!
[edit] Here’s my pom.xml (the concrete library which I’m about to OSGi-ify is Selenium):
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>com.example.p2dependencies</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>pom</packaging>
<build>
<plugins>
<plugin>
<groupId>org.reficio</groupId>
<artifactId>p2-maven-plugin</artifactId>
<version>1.2.0</version>
<executions>
<execution>
<id>default-cli</id>
<configuration>
<artifacts>
<artifact><id>org.seleniumhq.selenium:selenium-java:3.4.0</id></artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
[edit2] Problem seems to be solved, it seems, the issue was an additional package which was only exported by com.othervendor:library.
I am creating an AEM content package and the resulting zip has the requisite META-INF directory with the filter.xml.
The package has content which is organized like so:
/jcr_root/apps/appgroup/myapp/components
/jcr_root/apps/appgroup/myapp/i18n/en_us.xml
/jcr_root/apps/appgroup/myapp/i18n/es_mx.xml
/jcr_root/apps/appgroup/myapp/templates
The filter.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
<filter root="/apps/appgroup/myapp">
<exclude pattern="/apps/appgroup/myapp/i18n(/.*)?" />
</filter>
</workspaceFilter>
Despite having the exclude pattern, the i18n node still gets deployed into the CRX when the package is installed. Shouldn't the filter exclude the i18n node?
Ultimately, I would like to deploy just the en_us node and have the filters block any other languages.
My understanding is that the filter taken into consideration during install and not during compilation. Is this correct?
Filters are applied when the package is built rather than installed. With an exclusion, it shouldn't get installed by your package, but it also means if already present, it also won't get removed either! It should behave as if the package doesn't touch the area covered by the exclude filter.
From the documentation*:
To include all scripts of my application but the forms component:
Root path: /apps/myapp
Rules: Exclude: /apps/myapp/components/form(/.*)?
The form component is not included in the package. If such a component
already existed when installing the package, CRX would not remove it,
because it is not defined by the filters.
…
When building the package, all the content defined by each filter is included. When extracting the package, all existing content that matches the filter is removed or replaced.
Edit: Working from a Maven bundle, you could use specify elements as excluded using a resource declaration, to avoid the content being added to the Zip e.g.:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<excludes>
<exclude>jcr_root/apps/appgroup/myapp/i18n</exclude>
<exclude>jcr_root/apps/appgroup/myapp/i18n/**/*.*</exclude>
</excludes>
</resource>
</resources>
</build>
It's possible that the filter.xml is getting ignored by Maven on build & once the content is in the package, it's getting installed by CQ regardless.
EDIT2: * Initial example is no longer in the documentation now that Day.com is down, but should still hold true. Updated documentation is now available here
Littered throughout my project are various property files located in packages that are not being included when the package goal is run from a Maven build.
Using the 0.10.2 m2eclipse plugin and the default "package" goal.
In the project:
src->main->java->mypackage->MyProperties.java
src->main->java->mypackage->MyProperties.properties
In expanded war directory after the "package" goal is run:
target->classes->mypackage->MyProperties.class
-- no property file --
I'm trying to get the group to adopt Maven and resolving this issue is going to be a deal maker. Moving the properties files isn't going to be practical. Any help is much appreciated.
Put your property files where Application/Library resources belong, i.e. in src/main/resources:
src/main/resources/mypackage/MyProperties.properties
And it will get copied properly.
Pascal's answer is the correct maven way of doing things.
But some developers like to keep resources next to their sources (it's standard procedure in wicket, for example).
If you're going to do that, you will have to add your source folder to the resources:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>src/main/java</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>
</build>
I am working on a gwt module that is built using maven build system. I
had a working module that had the following project structure.
project-name/src/main/java/pkg1/pkg2/pkg3/EntryPoingClass
project-name/src/man/resources/pkg1/pkg2/ModuleDef.gwt.xml
The module definition was looking like this (I have put only this
project specific settings here...normal inherits are not specified for
the sake of brevity)
... <entry-point class='pkg1.pkg2.pkg3.EntryPointClass'/>
<source path='pkg3'/>...
I am not a big fan of having sub packages in the resources folder.
Hence I am trying to change it to something like the following
project-name/src/main/java/pkg1/pkg2/pkg3/EntryPoingClass project-name/src/man/resources/ModuleDef.gwt.xml
Also changed the module definition to
... <entry-point class='pkg1.pkg2.pkg3.EntryPointClass'/>
<source path='pkg1.pkg2.pkg3'/> <!-- Since the module def is not
inside any package I am specifying the entire 'client' package here --> ...
After this, invoking gwt compile fails with the following error
Unable to find type "pkg1.pkg2.pkg3.EntryPointClass"
Can anybody tell me if there is any relation between the package
structure of the EntryPointClass and the module definition package
structure apart from the fact that the EntryPointClass should be
inside the 'client' package specified in the module definition (which
is satisfied here)?
Btw, I could see that the compiled classes are available in the
classpath when invoking the gwt compiler.
Any help in this regard is greatly appreciated.
GWT compiler needs sources of client side classes, not only compiled bytecode. Is it in classpath?
In my company we always set pom.xml to copy sources to target as resources:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/client/**/*.java</include>
<include>**/*.gwt.xml</include>
</includes>
</resource>
</resources>
</build>
Change **/client/**/*.java to anything satisfies your needs (probably pkg1/pkg2/pkg3/**/*.java). This way sources of client part are always in classpath.
I have a maven project and I'd like to create a distribution of it with the dependencies. I've tried the maven-assembly-plugin and built the jar with dependencies, but that unpacked all of the jars and repackaged them all into a big, single jar. What I'd like is something like my jar file and a lib folder that has all of the dependencies. Then when I run it, I could run "java -cp lib/* my.package.MainClass".
What's the best way to go about doing this with maven? Or the recommended way to deploy?
thanks,
Jeff
I have used the Maven assembly just for that in my project.
First enable your plugin in your POM and call your assembly config :
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<!--I recommend 2.1 as later versions have a bug that may
Duplicate files in your archive
-->
<version>2.1</version>
<!--Executes the packaging along with the mvn package phase
-->
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>attached</goal>
</goals>
</execution>
</executions>
<configuration>
<descriptors>
<!--Relative path to your descriptor -->
<descriptor>src/main/assembly/package.xml
</descriptor>
</descriptors>
</configuration>
</plugin>
Then in your descriptor you can decide how you want your layout to be before you package the whole thing
<assembly>
<!-- this will create an extra resource project-1.1.1-package.zip, you can
choose jar as well in the format-->
<id>package</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<!-- Insert here extra files as configs or, batch files, resources, docs etc-->
<fileSets>
<fileSet>
<directory>src/main/assembly/files</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>**/conf/*.*</include>
<include>**/doc/*.*</include>
</includes>
</fileSet>
<!-- I like to integrate the jre as well... simplifies my deployement -->
<fileSet>
<directory>target/jre</directory>
<outputDirectory>/jre</outputDirectory>
</fileSet>
</fileSets>
<!-- This will scrub your dependencies and add them to your lib folder, I excluded
Test stuff as it is not needed, could have declared the resource as a test
only phase as well would not have had to exclude it here
-->
<dependencySets>
<dependencySet>
<outputDirectory>lib</outputDirectory>
<excludes>
<exclude>junit:junit</exclude>
</excludes>
</dependencySet>
</dependencySets>
</assembly>
This will create a zip file with the layout you have specified in your output directory config, package the whole thing as a zip file (you can choose zip, jar, war ...) and deploy it in my repository with the rest.
I skipped bits and pieces to make it simpler but my package expands to include batch files, dlls, config, doc and the JRE so everything needed is in the same zip... all is needed to run the thing is extract and click start.bat !
I could also probably make it in to a jar properly formatted with METADATA and just double click the jar itself to start it all, I did not need or have time to toy around this option but you may try it as well.
Beware of versions above 2.1 of the assembly plugin, it will create duplicate entries if your directives enable it to find the same file in different locations, this will give you a lib folder with the same jars repeating twice. not very dangerous as unzipping will collapse them but still annoying to have the unzip ask you if you want to overwrite files. Plus the fact that you do not know which won if somehow they turned out to be different in content.
Maven is great but I find that it is sometimes frustrating to get it working, Plus documentation can sometimes be hard to find and use. However, used appropriately it will save you tons of time.
good luck
See:
http://maven.apache.org/shared/maven-archiver/index.html
You should be able to use the maven-jar plugin to package up an archive, specify the main class to execute along with the classpath. It can generate a manifest file for you for your project.
http://maven.apache.org/shared/maven-archiver/examples/classpath.html#Prefix