Our team wants to use the wro4j tool, and we have gotten it setup and able to run the csslint and jslint. We would like to create our own custom CSS rules, but we can't find any documentation on where the csslint rules are stored and how to create our own.
Any help would be greatly appreciated.
In order to add csslint rules, you should update configuration options section of the maven plugin:
<plugins>
<plugin>
<groupid>ro.isdc.wro4j</groupid>
<artifactid>wro4j-maven-plugin</artifactid>
<version>${wro4j.version}</version>
<executions>
<execution>
<goals>
<goal>csslint</goal>
</goals>
</execution>
</executions>
<configuration>
<options>box-model</options>
</configuration>
</plugin>
</plugins>
More details are documented here.
Update:
The rules are defined by csslint library (version 0.9.10). All the rules defined in the library can be referred in the configuration section of the maven plugin. Adding custom rule is not supported out of the box, if you need this feature, feel free to create a feature request.
Related
Is anyone out there using OAuth to authenticate GeoServer users? I've been through installing and configuring this extension. I've tried Google and GitHub providers. I end up with a 404 error trying to access the login page. Same issue as here. There are no errors in the log with the debug level elevated as suggested.
Answering my own question here...
For me the 404 problem solved by building from source and accounting for the required dependencies using a maven plugin. Previously, I was attempting to use the prebuilt binaries and lib/ depedencies.
I built the modules from source (2.18.3) and modified the file maven file to copy the dependencies to the target folder, which I then copied to WEB-INF/lib.
Here is the pom file addition I made to get the dependencies.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/classes/lib</outputDirectory>
<includeScope>runtime</includeScope>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
I have a initial data class which should be excluded in the normal (default profile) build. If I specify for example the run profile this class should be included.
Furthermore this class is needed by the tests. So it needs to be included all the tim.
I used the excludes to achieve the first part, but the dependency from the test breaks the testCompile goal.
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<excludes>
<exclude>**/InitialDataBuilder.java</exclude>
</excludes>
</configuration>
</execution>
<execution>
<id>default-testCompile</id>
<goals>
<goal>testCompile</goal>
</goals>
<configuration>
<testIncludes>
<include>**/*.java</include>
</testIncludes>
</configuration>
</execution>
</executions>
</plugin>
What is wrong with my config?
Is there no way to include an excluded source file for tests?
Maven's directory structure allows you to easily separate source/production code and test code.
The details of how to layout a project are explained here: https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
Basically, you put your production code in:
src/main/java
Test code goes in:
src/test/java
The test code tree should include the actual unit tests themselves and supporting classes. So the code you described belongs there. It will only end up in the test jar, not the production jar.
Also if you do it this way, you don't need to mess with the compiler plugin settings. The defaults will do what you expect.
Oh one other thing I should mention is that if it is needed for another profile, you should likely make it it's own maven module with it's own POM file. Then this class can reference it as a <scope>test</scope> dependency and the other as a production dependency.
I have two classes with main method and one loads the security configuration and the other does not. In order to create two artifacts - secure and non secure jars, I am doing something like the following :
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>1</id>
<configuration>
<mainClass>a.b.c.Secured</mainClass>
<finalName>secured</finalName>
<classifier>secured</classifier>
</configuration>
</execution>
<execution>
<id>2</id>
<configuration>
<mainClass>a.b.c.NonSecured</mainClass>
<finalName>non-secured</finalName>
<classifier>nonSecured</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
And I am seeing the exception -
java.lang.IllegalStateException: Unable to find a single main class from the following candidates.
Can you please let me know, if there is some thing wrong with the above configuration? I may be able to use maven profiles to create different artifacts. However, I wanted to understand the problem with the above configuration. Any help will be greatly appreciated.
I think both those configurations are active at the same time (otherwise how do you tell maven which one to use?). You could put them both in Maven profiles.
I have defined the following configuration in my pom for surefire with TestNg:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
<configuration>
<skipTests>${skip-all-tests}</skipTests>
</configuration>
<executions>
<execution>
<id>unit-tests</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<skip>${skip-unit-tests}</skip>
<groups>unit</groups>
<excludedGroups>integration</excludedGroups>
</configuration>
</execution>
<execution>
<id>integration-tests</id>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<skip>${skip-integration-tests}</skip>
<groups>integration</groups>
<excludedGroups>unit</excludedGroups>
</configuration>
</execution>
</executions>
</plugin>
But it seems the two executions are always preceded by a "default-test" run which seems to run every #test annotated method (at least I think so).
--- maven-surefire-plugin:2.12:test (default-test) # my-project
For example running "mvn test" on the project, two test executions take place. The "default-test" and the "unit-test".
Could someone explain this a little more to me?
Can this be disabled or controlled (configured what is tested and what not)?
People wanted to have a way to override the default built-in executions of plugins within Maven.
Maven 3 (or it may have been introduced as early as 2.1.0 or 2.2.0) solved this by defining a default execution id for each plugin execution added to the effective pom by the packaging's lifecycle.
The name of this implicit id is always default-_____ I cannot recall the exact rule that it is generated for.
You can therefore override the packaging's injected executions by defining a matching execution.
To solve your case I would either change <id>unit-tests</id> to <id>default-test</id> or
add
<execution>
<id>default-test</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
either will have the same effect, though the <id>unit-tests</id> to <id>default-test</id> solution will be slightly more performant as you only need to invoke two executions of surefire.
The other thing I would point out is you would probably be better off using maven-failsafe-plugin to execute your integration tests as at some point in time you may want to do some stuff pre & post integration testing, and failsafe is designed for that use case (though it should be trivial to switch further down the line)
Alternatively to the Stephen's solution, if you don't want the following message to be displayed in the log (which in fact is a bit misleading since you are not skipping tests):
[INFO] --- maven-surefire-plugin:2.22.2:test (default-test) # service-template ---
[INFO] Tests are skipped.
...then go this way:
<execution>
<id>default-test</id>
<phase>none</phase>
</execution>
I changed the title to generalize this question which really isn't specific to Axis2. I eventually gave up on Axis2 altogether and switched to Metro/JAX-WS but am now seriously considering giving up on both and switching to OpenSAML. The real question I'm struggling to get answered here is, how to build complex standards-based SOA services that actually work.
The original phrasing was: Could someone paste in a working example of maven pom to invoke Axis2 java2wsdl with defaults I can live with? Here's a command line incantation that behaves sort of OK.
-o target/generated-sources/java2wsdl \
-l "http://localhost:9763/services/PolicyService" \
-tn urn:sesgg:sc:security:1.0.spec.PolicyService \
-tp ps \
-stn urn:oasis:names:tc:SAML:2.0:protocol \
-stp samlp \
-of PolicyService.wsdl \
-sn PolicyService \
-cp "../../Schema/target/Schema-1.0-SNAPSHOT.jar target/PolicyService-1.0-SNAPSHOT.jar" \
-cn com.technica.pbac.ps.PolicyService \
Everything I do winds up with really squirrely results; e.g. weird reversed namespaces (http://xmldsig._09._2000.w3.org/xsd for example). Could you explain why this is and how to stop it?
There seems to be a lot java2wsdl's out there that expect entirely different arguments, with little consistency between command line and maven pom.
No responses so I'll post current results of my own experiments to help others with
similar problems. Can't guarantee this is correct until testing is finished but at least now I'm getting results I can bear looking at in Eclipse:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.7.5</version>
<configuration>
<schemaExcludes>
<exclude>*saml*.xsd</exclude>
</schemaExcludes>
<strict>true</strict>
<extension>true</extension>
</configuration>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-java2wsdl-maven-plugin</artifactId>
<version>1.5.4</version>
<executions>
<execution>
<goals>
<goal>java2wsdl</goal>
</goals>
</execution>
</executions>
<configuration>
<id>Generate WSDL based on PolicyService Interface</id>
<serviceName>PolicyService</serviceName>
<className>com.technica.pbac.ps.PolicyServiceImpl</className>
<targetNamespace>http://sesgg/sc/security/1.0/spec/PolicyService</targetNamespace>
<targetNamespacePrefix>sesgg</targetNamespacePrefix>
<schemaTargetNamespace>http://sesgg/sc/security/1.0/spec/PolicyService</schemaTargetNamespace>
<schemaTargetNamespacePrefix>sesgg</schemaTargetNamespacePrefix>
<elementFormDefault>qualified</elementFormDefault>
<extension>false</extension>
<package2Namespace>
<property>
<name>urn:sesgg:sc:security:1.0:spec:PolicyService</name>
<value>http://sesgg/sc/security/1.0/spec/PolicyService</value>
</property>
<property>
<name>com.technica.pbac.ps</name>
<value>http://com.technica.pbac.ps</value>
</property>
<property>
<name>oasis.names.tc.saml._2_0.protocol.xsd</name>
<value>http://oasis/names/tc/saml/2.0/protocol</value>
</property>
<property>
<name>oasis.names.tc.saml._2_0.protocol</name>
<value>http://oasis/names/tc/saml/2.0/protocol</value>
</property>
</package2Namespace>
<episodes>
<episode>
<groupId>Technica-PBAC</groupId>
<artifactId>Schema-1.0-SNAPSHOT.jar</artifactId>
</episode>
</episodes>
<outputFileName>target/generated-sources/java2wsdl/PolicyService.wsdl</outputFileName>
<filename>target/generated-sources/java2wsdl/services.xml</filename>
<locationUri>http://localhost:9763/services/PolicyService</locationUri>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-wsdl2code-maven-plugin</artifactId>
<version>1.5.4</version>
<executions>
<execution>
<goals>
<goal>wsdl2code</goal>
</goals>
<configuration>
<wsdlFile>target/generated-sources/java2wsdl/PolicyService.wsdl</wsdlFile>
<packageName>com.technica.pbac.ps</packageName>
<outputDirectory>target/generated-sources/wsdl2java</outputDirectory>
<unwrap>true</unwrap>
<allPorts>true</allPorts>
<databindingName>adb</databindingName>
<generateServerSide>true</generateServerSide>
<generateAllClasses>true</generateAllClasses>
<generateServicesXml>true</generateServicesXml>
<generateTestcase>true</generateTestcase>
<overWrite>true</overWrite>
<serviceName>PolicyService</serviceName>
<syncMode>sync</syncMode>
<backwardCompatible>false</backwardCompatible>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-java2wsdl-maven-plugin</artifactId>
<version>1.5.4</version>
</plugin>
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-wsdl2code-maven-plugin</artifactId>
<version>1.5.4</version>
</plugin>
</plugins>
</pluginManagement>
</build>
One caution: I really doubt its right to be running jaxb, java2wsdl, wsdl2java and compile phases in a single pom. Currently java2wsdl runs after wsdl2java this way which obvously isn't right. This pom is doubly suspicious since java2wsdl needs a compiled jar to run, and seems to be using the one left over from previous runs. Its a bear to get working again after mvn clean. I'll probably wind up splitting it into several poms and will adjust this answer when I do.
I promised to extend this answer with something approximately "right". Here is progress to date, which I'm still not absolutely sure is 100% correct. More about that later.
This is all based on the stack of schema Oasis publishes to define the XACML and SAML-P for XACML standards. The XSD's have been gathered into a Commons-Schema module (not shown), tweaked to fix several Oasis errors, and compiled to Java classes with JAX-B. These classes are the foundation for the services described below. The schema.episode.path and schema.catalog.path properties point to files in this module.
I split each service (PolicyService in this case) into two maven modules. PolicyService-Svc is the service and its pom looks like this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<id>Generate WSDL</id>
<phase>generate-resources</phase>
<goals>
<goal>wsgen</goal>
</goals>
<configuration>
<sei>com.technica.pbac.ps.PolicyService</sei>
<genWsdl>true</genWsdl>
<keep>true</keep>
<verbose>true</verbose>
<extension>true</extension>
<catalog>${schema.catalog.path}</catalog>
<xjcArg>-episode</xjcArg>
<xjcArg>${schema.episode.path}</xjcArg>
<xjcArg>-catalog</xjcArg>
<xjcArg>${schema.catalog.path}</xjcArg>
</configuration>
</execution>
</executions>
</plugin>
PolicyService-Proxy is generic proxy code that any client or service can use to invoke that service (more about problems with this below). Its pom looks like this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<!-- <phase>generate-sources</phase> -->
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<wsdlFiles>
<wsdlFile>localhost_8080/PolicyService-Svc/PolicyService.wsdl</wsdlFile>
</wsdlFiles>
<wsdlLocation>http://localhost:8080/PolicyService-Svc/PolicyService?WSDL</wsdlLocation>
<sourceDestDir>${project.build.directory}/generated-sources/jaxws</sourceDestDir>
<genWsdl>true</genWsdl>
<verbose>true</verbose>
<extension>true</extension>
<catalog>${schema.catalog.path}</catalog>
<xjcArg>-episode</xjcArg>
<xjcArg>${schema.episode.path}</xjcArg>
</configuration>
</execution>
</executions>
</plugin>
Now for the problems, which I'd really appreciate advice on. Even though Commons-Schema provides compiled java classes for all schema, wsgen insists on producing a wsdl with newly-generated xsds, which are slightly different and slightly incorrect in various ways.
As one example of incorrect and different, SAML defines an Extensions element that conflicts with the same name in another schema. So I repaired it in the base Commons-Schema like this:
<element name="Extensions" type="samlp:ExtensionsType">
<annotation>
<appinfo>
<jxb:class name="Extensions-SAML"/>
</appinfo>
</annotation>
</element>
But wsgen/wsimport omits this correction so the conflict turns up again. Infuriating and absolutely fatal to the build.
Another is omitting required includes so eclipse validation reports them as errors until hand-corrected. My workaround is to periodically copy the generated wsdl and xsds from the target folder to src/main/webapp/WEB-Inf/wsdl, repair them by hand, and tweak the poms to use this folder instead of the generated one inside target. This works for invoking services from non-service clients. I copy the same wsdls and xsds to a similar client folder and ensure that the pom references these, not the ones jaxws generates in that module.
The problem I can't solve occurs when any service needs to invoke another service via its proxy. The calling service's proxy jar (with its slightly different versions of important foundation classes) is now mixed in with the calling service jars (based on Commons-Schema's JAXB-generated classes), which causes no end of trouble.
Can someone please advise? Thanks!
The ultimate answer to this question was indeed to give up on trying to fix busted schemas and tools and switch to OpenSAML, which has already done that. This worked fine for the XACML 2.0 compiler and web services based on it. But it fell flat for the XACML 3.0 compilers because OpenSAML doesn't support XACML 3.0 and has no plans to do so, so I had to handle that myself. But with experience with XACML 2.0 to build on, I eventually got both working. This project was far more painful than it had to be and "powerful" tools just made it harder.