Status: Closed (View Workflow)
Affects Version/s: JBoss Parent POM - 6
Fix Version/s: JBoss Parent POM - 7
Component/s: JBoss Parent POM
Similar Issues:Show 10 results
JBBUILD-338 Create parent maven pom for all JBoss project poms to inherit from. JBBUILD-704 Add GPG signature configuration to jboss parent pom JBBUILD-726 org.apache.maven:maven-plugin-api:jar:2.1.0-M2-SNAPSHOT has a snapshot parent org.apache.maven:maven-parent:pom:11-SNAPSHOT that doesn't exist anymore JBBUILD-700 Remove reporting config from parent pom JBBUILD-640 Remove reporting section from the parent pom JBBUILD-699 Add javadocs generation to jboss-parent JBBUILD-547 maven-deploy goal should handle stand-alone poms and jars not listed in component-info JBBUILD-353 Add controls to parent pom to build releases from jboss-repository. JBBUILD-569 jboss-parent POM should include wagon-webdav configuration JBBUILD-592 Update the deployment URLs of the jboss parent pom to point to the new repository
This might be a controversial change, but before dismissing this issue, please listen to my experience with profiles:
The current profiles in the pom can be removed:
- enforce: Instead of doing -Dskip-enforce use -Denforcer.skip=true as documented here: http://maven.apache.org/plugins/maven-enforcer-plugin/enforce-mojo.html#skip
- source: Instead of doing -Dskip-sources, create an issue on the maven-source-plugin to skip it there. I see no point in skipping this though as it's not slow and the JBoss repo doesn't accept artifacts with sources.
- release: Why is that configuration in a profile? They 'll definitely forget to activate that profile during release. (Especially since -Denforce does not work but -Penforce does, but the later disables the use of other profiles). Fix on the deploy-plugin (by activating updateReleaseInfo on non-SNAPSHOT)
- dev-reports: Why does this need to be in a profile? A "mvn clean install" doesn't run them anyway. An everyone knows that a "mvn site" takes forever, so it's ok to add them there by default.
Furthermore, the motivation behind this:
- Profiles complicate the build, making it harder to understand what's happening.
- In practice, contributors want 2 profiles:
- fast (the default, no profile): includes as much as possible (including enforcer and sources jars) but nothing that is slow (like building docbook docs or assemblies)
- full (-Dfull): include everything (docbook docs, javadocs, signing, assemblies, ...): if the output missing something, it's a bug, not a missing build option
- Having more than these 2 profiles, confuses contributors and makes build maintance harder.
- When importing a pom.xml in IntelliJ or m2eclipse, you get asked which profiles you want to activate. You'll want to check the "full" profile so you get the sources of the slow modules (docbook, assemblies) too. Having other profiles there just confuses the developers.