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
Related
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.
I'm facing a very unique situation and need some advice:
I'm working on a project which depends on an other project from my same company and now I need to apply some modifications to the dependency.
The problem which I have is that the source code from the dependency has been lost, so the only thing I have is a maven dependency in the repository, with the corresponding jar file.
On top of that, some of the classes in the Jar file where created using JiBX parser, mapping some XSD files which I neither have, and the resulting classes are synthetic and I found no decompiler able to handle them properly.
The only good thing of all of that is that the class which I need to change can be properly decompiled, so went for the following:
I decompiled the whole jar file and ended up with some classes (the
JiBx ones) with empty or wrongly implemented methods.
I commented out the body of the wrong methods to have stub objects, applied the required changes to the right classes and recompiled.
I took the old Jar file, opened it and manually replaced the old class with the new one.
And the resulting Jar worked as expected.
Now my question is: Can I do all of that using Maven?
The idea would be to put the JiBX class files as resources, and keep the stub equivalents as source files and then let maven:
Compile everything as usual, putting all the compiled class files
into target folder
Remove stub class files from target folder and replace them with the old precompiled class files
package the jar.
Which approach would you recommend?
UPDATE
I give some more details about the dependency project structure:
All classes are inside the same package:
my.project.domain.JiBX__c_GeneratedObfuscatedClass1.java
my.project.domain.JiBX__c_GeneratedObfuscatedClass2.java
my.project.domain.JiBX__c_GeneratedObfuscatedClass3.java
my.project.domain.CustomizableClass1.java
my.project.domain.CustomizableClass2.java
my.project.domain.CustomizableClass3.java
JiBX classes are not imported properly as dependency and if I try to put any of the CustmizableClasses into the project source and let the JiBX ones be in a dependency, the compiler reports missing methods.
I also tried using the Shade Plugin as suggested, but since I need to include the JiBX classes into my source path, I will end up having to include into package JiBX classes from jar dependency and compiled CustomizableClasses, but skipping CustomizableClasses from jar dep and compiled JiBX classes.
I looks like it can work, but I admit that I still didn't find the way of doing it.
Any clues will be very welcomed.
UPDATE 2 (RESOLUTION)
I explain here how I finally managed this using the shade plugin as suggested, just in case someone else needs to do the same:
I finally created a project with the decompiled classes inside the same package, and left the methods which didn't want to be decompiled commented out.
In the pom.xml I added the following:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<artifactSet>
<includes>
<include>${project.groupId}:${project.artifactId}</include>
<include>TheDamnedProject:WithoutSources</include>
</includes>
</artifactSet>
<filters>
<filter>
<artifact>TheDamnedProject:WithoutSources</artifact>
<includes>
<!-- These classes will be taken directly from dependency JAR -->
<include>my/package/ClassWhichCouldNotBeDecompiled1.class</include>
<include>my/package/ClassWhichCouldNotBeDecompiled2.class</include>
<include>my/package/ClassWhichCouldNotBeDecompiled3.class</include>
<include>my/package/ClassWhichCouldNotBeDecompiled4.class</include>
</includes>
</filter>
<filter>
<artifact>${project.groupId}:${project.artifactId}</artifact>
<excludes>
<!-- These classes will be overridden by the ones inside the JAR -->
<exclude>my/package/ClassWhichCouldNotBeDecompiled1.class</exclude>
<exclude>my/package/ClassWhichCouldNotBeDecompiled2.class</exclude>
<exclude>my/package/ClassWhichCouldNotBeDecompiled3.class</exclude>
<exclude>my/package/ClassWhichCouldNotBeDecompiled4.class</exclude>
</excludes>
</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
thanks!
Carles
Here's how I would do that:
Create a new Maven project for this Jar file, with packaging type jar
Include the original Jar file as a dependency
Add the one decompiled .java file in the src folder
This should get you to a point where the .java file can be compiled, since the other classes from the jar file are available.
You now have two Jar files: one original, and one that should just contain the single recompiled and changed class.
Adding both to your application class path might work, but will depend on the order on the classpath.
If you want to end up with one jar file, I recommend to take a look at the Maven Shade Plugin (http://maven.apache.org/plugins/maven-shade-plugin/), which will allow you to create a new Jar file with contents from multiple sources. It will allow you to filter what goes into the new Jar file.
The Maven Shade plugin allows you to specify which classes from each artifact are included. It uses wildcards and include/exclude tags for this, as described here: http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html
Once that Jar file is created, I would release it using the Maven Release plugin, and then include that artifact downstream. This will allow you to only update the patched Jar when it is really required, it probably doesn't have to be on every build. But that depends on your usage pattern.
For the version number of the new Jar file, I recommend to use a variation of the original one. Use the same groupId and artifactId, then modify the version number. If the original has 1.0.2, your new, patched file should be released as 1.0.2-1, to indicate that it's based on the 1.0.2 sources. If you need to make an additional change, release that as 1.0.2-2 and so on. This will make it easy to understand which version your patches are based on, and the incrementing patch number will give you a means to distinguis the releases.
I have a maven multi-module project. One of this modules (compiled as .jar) contains only domain objects, which will be used at client and server sides (I add this .jar as dependency to other my modules).
I know that GWT module, where will be used objects from shared .jar, must also have source files for successful compilation. So I tried to add to my pom.xml both:
<resources>
<resource>
<directory>src/main/java/<path></directory>
<includes>
<include>**/*.java</include>
<include>**/*.gwt.xml</include>
</includes>
</resource>
</resources>
and
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<versionRange>[${gwt.version}]</versionRange>
<goals>
<goal>resources</goal>
</goals>
<plugin>
But resulting .jar don't contain GWT module source (i.e gwt.xml). All sources of domain classes are added as well (at root directory of .jar), but ModuleName.gwt.xml not.
Where is problem? Thanks.
If your .gwt.xml file is in src/main/resources/ then it won't get copied if you specify src/main/java/ as the resource path...
You should probably omit the <resource> section and let the GWT plugin include the source in the jar or at least have two sections, one for the .gwt.xml file (src/main/resources or where you put it) and one for the source code (as you have it now).
Cheers,
I was troubleshooting this error today so I'm just posting my fix:
Multi-module gwt project being build with the maven gwt plugin needs an entry in the pom.xml like:
<modules>
<module>../theothermodule</module>
</modules>
In order to compile.
This error have multiple explanations. Check list:
if you are referencing a gwt module you need to point to the *.gwt.xml file in dot notation without the file extension. E.g. com.example.ThirdParty refers to com/example/ThirdParty.gwt.xml module
to import the 3rd party module, add <inherits name="com.example.ThirdParty" /> to your *.gwt.xml file
the ThirdParty.gwt.xml should contain one or more source elements pointing to translatable code. E.g. <source path='shared' />.
all translatable code in ThirdParty.jar needs to include plaintext *.java sources. E.g. com/example/shared/Widget.class and com/example/shared/Widget.java are both present
the ThirdParty.jar is on your classpath
Notes:
if the ThirdParty gwt module does not have entry point it does not need to be compiled with gwt compiler
the gwt compiler does not require extra configuration to include the ThirdParty module as long as its jar is on classpath and your *.gwt.xml inherits ThirdParty.gwt.xml; the same applies to the gwt maven plugin
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.