You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by kh...@apache.org on 2014/10/10 18:35:26 UTC
svn commit: r1630934 - in
/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer:
./ utils/
Author: khmarbaise
Date: Fri Oct 10 16:35:26 2014
New Revision: 1630934
URL: http://svn.apache.org/r1630934
Log:
- Fixed several Checkstyle errors.
Modified:
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractPropertyEnforcerRule.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractVersionEnforcer.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanDuplicatePomDependencyVersions.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedRepositories.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/ReactorModuleConvergence.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireOS.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePrerequisite.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSameVersions.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/ArtifactMatcher.java
maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/EnforcerRuleUtils.java
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java Fri Oct 10 16:35:26 2014
@@ -44,7 +44,7 @@ public abstract class AbstractBanDepende
/** Specify if transitive dependencies should be searched (default) or only look at direct dependencies. */
private boolean searchTransitive = true;
-
+
private transient DependencyGraphBuilder graphBuilder;
/**
@@ -74,17 +74,19 @@ public abstract class AbstractBanDepende
}
catch ( ComponentLookupException e )
{
- // real cause is probably that one of the Maven3 graph builder could not be initiated and fails with a ClassNotFoundException
+ // real cause is probably that one of the Maven3 graph builder could not be initiated and fails with a
+ // ClassNotFoundException
try
{
- graphBuilder = (DependencyGraphBuilder) helper.getComponent( DependencyGraphBuilder.class.getName(), "maven2" );
+ graphBuilder =
+ (DependencyGraphBuilder) helper.getComponent( DependencyGraphBuilder.class.getName(), "maven2" );
}
catch ( ComponentLookupException e1 )
{
throw new EnforcerRuleException( "Unable to lookup DependencyGraphBuilder: ", e );
}
}
-
+
// get the correct list of dependencies
Set<Artifact> dependencies = getDependenciesToCheck( project );
@@ -95,7 +97,7 @@ public abstract class AbstractBanDepende
if ( foundExcludes != null && !foundExcludes.isEmpty() )
{
String message = getMessage();
-
+
StringBuilder buf = new StringBuilder();
if ( message != null )
{
@@ -125,12 +127,12 @@ public abstract class AbstractBanDepende
DependencyNode node = graphBuilder.buildDependencyGraph( project, null );
if ( searchTransitive )
{
- dependencies = getAllDescendants( node );
+ dependencies = getAllDescendants( node );
}
else if ( node.getChildren() != null )
{
dependencies = new HashSet<Artifact>();
- for( DependencyNode depNode : node.getChildren() )
+ for ( DependencyNode depNode : node.getChildren() )
{
dependencies.add( depNode.getArtifact() );
}
@@ -146,7 +148,7 @@ public abstract class AbstractBanDepende
private Set<Artifact> getAllDescendants( DependencyNode node )
{
- Set<Artifact> children = null;
+ Set<Artifact> children = null;
if ( node.getChildren() != null )
{
children = new HashSet<Artifact>();
@@ -172,7 +174,7 @@ public abstract class AbstractBanDepende
* @throws EnforcerRuleException the enforcer rule exception
*/
protected abstract Set<Artifact> checkDependencies( Set<Artifact> dependencies, Log log )
- throws EnforcerRuleException;
+ throws EnforcerRuleException;
/**
* Checks if is search transitive.
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractPropertyEnforcerRule.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractPropertyEnforcerRule.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractPropertyEnforcerRule.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractPropertyEnforcerRule.java Fri Oct 10 16:35:26 2014
@@ -40,7 +40,7 @@ public abstract class AbstractPropertyEn
* @see {@link #setRegex(String)}
* @see {@link #getRegex()}
*/
- public String regex = null;
+ private String regex = null;
/**
* Specify a warning message if the regular expression is not matched.
@@ -49,7 +49,7 @@ public abstract class AbstractPropertyEn
* @see {@link #setRegexMessage(String)}
* @see {@link #getRegexMessage()}
*/
- public String regexMessage = null;
+ private String regexMessage = null;
public AbstractPropertyEnforcerRule()
{
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractVersionEnforcer.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractVersionEnforcer.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractVersionEnforcer.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractVersionEnforcer.java Fri Oct 10 16:35:26 2014
@@ -53,7 +53,6 @@ public abstract class AbstractVersionEnf
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setVersion(String)}
* @see {@link #getVersion()}
-
*/
public String version = null;
@@ -97,7 +96,7 @@ public abstract class AbstractVersionEnf
else
{
String message = getMessage();
-
+
if ( StringUtils.isEmpty( message ) )
{
message = msg + " is not in the allowed range " + vr + ".";
@@ -132,7 +131,7 @@ public abstract class AbstractVersionEnf
{
@SuppressWarnings( "unchecked" )
List<Restriction> restrictions = allowedRange.getRestrictions();
- for ( Restriction restriction : restrictions )
+ for ( Restriction restriction : restrictions )
{
if ( restriction.containsVersion( theVersion ) )
{
@@ -153,7 +152,6 @@ public abstract class AbstractVersionEnf
/*
* (non-Javadoc)
- *
* @see org.apache.maven.enforcer.rule.api.EnforcerRule#getCacheId()
*/
public String getCacheId()
@@ -172,7 +170,6 @@ public abstract class AbstractVersionEnf
/*
* (non-Javadoc)
- *
* @see org.apache.maven.enforcer.rule.api.EnforcerRule#isCacheable()
*/
public boolean isCacheable()
@@ -183,8 +180,8 @@ public abstract class AbstractVersionEnf
/*
* (non-Javadoc)
- *
- * @see org.apache.maven.enforcer.rule.api.EnforcerRule#isResultValid(org.apache.maven.enforcer.rule.api.EnforcerRule)
+ * @see
+ * org.apache.maven.enforcer.rule.api.EnforcerRule#isResultValid(org.apache.maven.enforcer.rule.api.EnforcerRule)
*/
public boolean isResultValid( EnforcerRule theCachedRule )
{
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanDuplicatePomDependencyVersions.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanDuplicatePomDependencyVersions.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanDuplicatePomDependencyVersions.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanDuplicatePomDependencyVersions.java Fri Oct 10 16:35:26 2014
@@ -40,12 +40,11 @@ import org.codehaus.plexus.util.IOUtil;
import org.codehaus.plexus.util.xml.pull.XmlPullParserException;
/**
- * Since Maven 3 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique.
- * Early versions of Maven 3 already warn, this rule can force to break a build for this reason.
+ * Since Maven 3 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique. Early versions of Maven
+ * 3 already warn, this rule can force to break a build for this reason.
*
* @author Robert Scholte
* @since 1.3
- *
*/
public class BanDuplicatePomDependencyVersions
extends AbstractNonCacheableEnforcerRule
@@ -64,8 +63,7 @@ public class BanDuplicatePomDependencyVe
{
throw new EnforcerRuleException( "Unable to retrieve the MavenProject: ", eee );
}
-
-
+
// re-read model, because M3 uses optimized model
MavenXpp3Reader modelReader = new MavenXpp3Reader();
FileReader pomReader = null;
@@ -94,25 +92,24 @@ public class BanDuplicatePomDependencyVe
}
// @todo reuse ModelValidator when possible
-
-// Object modelValidator = null;
-// try
-// {
-// modelValidator = helper.getComponent( "org.apache.maven.model.validation.ModelValidator" );
-// }
-// catch ( ComponentLookupException e1 )
-// {
-// // noop
-// }
-
-
-// if( modelValidator == null )
-// {
- maven2Validation( helper, model );
-// }
-// else
-// {
-// }
+
+ // Object modelValidator = null;
+ // try
+ // {
+ // modelValidator = helper.getComponent( "org.apache.maven.model.validation.ModelValidator" );
+ // }
+ // catch ( ComponentLookupException e1 )
+ // {
+ // // noop
+ // }
+
+ // if( modelValidator == null )
+ // {
+ maven2Validation( helper, model );
+ // }
+ // else
+ // {
+ // }
}
private void maven2Validation( EnforcerRuleHelper helper, Model model )
@@ -122,7 +119,7 @@ public class BanDuplicatePomDependencyVe
Map<String, Integer> duplicateDependencies = validateDependencies( dependencies );
int duplicates = duplicateDependencies.size();
-
+
StringBuilder summary = new StringBuilder();
messageBuilder( duplicateDependencies, "dependencies.dependency", summary );
@@ -134,7 +131,7 @@ public class BanDuplicatePomDependencyVe
messageBuilder( duplicateManagementDependencies, "dependencyManagement.dependencies.dependency", summary );
}
-
+
List<Profile> profiles = model.getProfiles();
for ( Profile profile : profiles )
{
@@ -143,24 +140,24 @@ public class BanDuplicatePomDependencyVe
Map<String, Integer> duplicateProfileDependencies = validateDependencies( profileDependencies );
duplicates += duplicateProfileDependencies.size();
-
+
messageBuilder( duplicateProfileDependencies, "profiles.profile[" + profile.getId()
+ "].dependencies.dependency", summary );
if ( model.getDependencyManagement() != null )
{
List<Dependency> profileManagementDependencies = profile.getDependencies();
-
+
Map<String, Integer> duplicateProfileManagementDependencies =
validateDependencies( profileManagementDependencies );
duplicates += duplicateProfileManagementDependencies.size();
-
+
messageBuilder( duplicateProfileManagementDependencies, "profiles.profile[" + profile.getId()
+ "].dependencyManagement.dependencies.dependency", summary );
}
}
-
+
if ( summary.length() > 0 )
{
StringBuilder message = new StringBuilder();
@@ -181,7 +178,6 @@ public class BanDuplicatePomDependencyVe
}
}
}
-
private Map<String, Integer> validateDependencies( List<Dependency> dependencies )
throws EnforcerRuleException
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedRepositories.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedRepositories.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedRepositories.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedRepositories.java Fri Oct 10 16:35:26 2014
@@ -144,9 +144,9 @@ public class BannedRepositories
// ----------------------------------------------------------------------
// Private methods
// ----------------------------------------------------------------------
-
+
/**
- * Check whether specified repositories have banned repositories.
+ * Check whether specified repositories have banned repositories.
*
* @param repositories: candidate repositories.
* @param includes : 'include' patterns.
@@ -161,13 +161,13 @@ public class BannedRepositories
for ( ArtifactRepository repo : repositories )
{
String url = repo.getUrl().trim();
- if ( includes.size()>0 && !match( url, includes ) )
+ if ( includes.size() > 0 && !match( url, includes ) )
{
bannedRepos.add( repo );
continue;
}
- if ( excludes.size()>0 && match( url, excludes ) )
+ if ( excludes.size() > 0 && match( url, excludes ) )
{
bannedRepos.add( repo );
}
@@ -194,7 +194,7 @@ public class BannedRepositories
{
return text.matches( pattern.replace( "?", ".?" ).replace( "*", ".*?" ) );
}
-
+
private String populateErrorMessage( List<ArtifactRepository> resultBannedRepos, String errorMessagePrefix )
{
StringBuffer errMsg = new StringBuffer( "" );
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java Fri Oct 10 16:35:26 2014
@@ -52,14 +52,14 @@ public class DependencyConvergence
private static Log log;
private static I18N i18n;
-
- private boolean uniqueVersions;
+
+ private boolean uniqueVersions;
public void setUniqueVersions( boolean uniqueVersions )
{
this.uniqueVersions = uniqueVersions;
}
-
+
/**
* Uses the {@link EnforcerRuleHelper} to populate the values of the
* {@link DependencyTreeBuilder#buildDependencyTree(MavenProject, ArtifactRepository, ArtifactFactory, ArtifactMetadataSource, ArtifactFilter, ArtifactCollector)}
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/ReactorModuleConvergence.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/ReactorModuleConvergence.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/ReactorModuleConvergence.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/ReactorModuleConvergence.java Fri Oct 10 16:35:26 2014
@@ -162,7 +162,7 @@ public class ReactorModuleConvergence
private void checkParentsInReactor( List<MavenProject> sortedProjects )
throws EnforcerRuleException
{
- //After we are sure having consistent version we can simply use the first one?
+ // After we are sure having consistent version we can simply use the first one?
String reactorVersion = sortedProjects.get( 0 ).getVersion();
List<MavenProject> areParentsFromTheReactor = areParentsFromTheReactor( reactorVersion, sortedProjects );
@@ -173,10 +173,10 @@ public class ReactorModuleConvergence
for ( MavenProject mavenProject : areParentsFromTheReactor )
{
sb.append( " --> " );
- sb.append(mavenProject.getId());
- sb.append(" parent:");
- sb.append(mavenProject.getParent().getId());
- sb.append(SystemUtils.LINE_SEPARATOR );
+ sb.append( mavenProject.getId() );
+ sb.append( " parent:" );
+ sb.append( mavenProject.getParent().getId() );
+ sb.append( SystemUtils.LINE_SEPARATOR );
}
throw new EnforcerRuleException( "Reactor modules have parents which contain a wrong version."
+ sb.toString() );
@@ -229,7 +229,7 @@ public class ReactorModuleConvergence
}
else
{
- //This situation is currently ignored, cause it's handled by existModulesWithoutParentsInReactor()
+ // This situation is currently ignored, cause it's handled by existModulesWithoutParentsInReactor()
}
}
@@ -278,8 +278,7 @@ public class ReactorModuleConvergence
}
/**
- * This will check if the given <code>groupId/artifactId</code> is part of the
- * current reactor.
+ * This will check if the given <code>groupId/artifactId</code> is part of the current reactor.
*
* @param groupId The groupId
* @param artifactId The artifactId
@@ -318,7 +317,7 @@ public class ReactorModuleConvergence
logger.debug( "Project: " + mavenProject.getId() );
if ( !hasParent( mavenProject ) )
{
- //TODO: Should add an option to force having a parent?
+ // TODO: Should add an option to force having a parent?
if ( mavenProject.isExecutionRoot() )
{
logger.debug( "The root does not need having a parent." );
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireOS.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireOS.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireOS.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireOS.java Fri Oct 10 16:35:26 2014
@@ -65,7 +65,8 @@ public class RequireOS
*/
public String family = null;
- /** The OS name desired.
+ /**
+ * The OS name desired.
*
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setName(String)}
@@ -73,7 +74,8 @@ public class RequireOS
*/
public String name = null;
- /** The OS version desired.
+ /**
+ * The OS version desired.
*
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setVersion(String)}
@@ -81,20 +83,22 @@ public class RequireOS
*/
public String version = null;
- /** The OS architecture desired.
- *
+ /**
+ * The OS architecture desired.
+ *
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setArch(String)}
- * @see {@link #getArch()}
+ * @see {@link #getArch()}
*/
public String arch = null;
- /** Display detected OS information.
- *
+ /**
+ * Display detected OS information.
+ *
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setDisplay(boolean)}
* @see {@link #isDisplay()}
- * */
+ */
public boolean display = false;
/**
@@ -107,8 +111,8 @@ public class RequireOS
/*
* (non-Javadoc)
- *
- * @see org.apache.maven.enforcer.rule.api.EnforcerRule#execute(org.apache.maven.enforcer.rule.api.EnforcerRuleHelper)
+ * @see
+ * org.apache.maven.enforcer.rule.api.EnforcerRule#execute(org.apache.maven.enforcer.rule.api.EnforcerRuleHelper)
*/
public void execute( EnforcerRuleHelper helper )
throws EnforcerRuleException
@@ -118,7 +122,8 @@ public class RequireOS
if ( allParamsEmpty() )
{
- throw new EnforcerRuleException( "All parameters can not be empty. You must pick at least one of (family, name, version, arch) or use -Denforcer.os.display=true to see the current OS information." );
+ throw new EnforcerRuleException(
+ "All parameters can not be empty. You must pick at least one of (family, name, version, arch) or use -Denforcer.os.display=true to see the current OS information." );
}
if ( isValidFamily( this.family ) )
@@ -347,12 +352,12 @@ public class RequireOS
{
this.version = theVersion;
}
-
+
public final void setDisplay( boolean display )
{
this.display = display;
}
-
+
public final boolean isDisplay()
{
return display;
@@ -360,7 +365,6 @@ public class RequireOS
/*
* (non-Javadoc)
- *
* @see org.apache.maven.enforcer.rule.api.EnforcerRule#getCacheId()
*/
public String getCacheId()
@@ -388,7 +392,6 @@ public class RequireOS
/*
* (non-Javadoc)
- *
* @see org.apache.maven.enforcer.rule.api.EnforcerRule#isCacheable()
*/
public boolean isCacheable()
@@ -399,8 +402,8 @@ public class RequireOS
/*
* (non-Javadoc)
- *
- * @see org.apache.maven.enforcer.rule.api.EnforcerRule#isResultValid(org.apache.maven.enforcer.rule.api.EnforcerRule)
+ * @see
+ * org.apache.maven.enforcer.rule.api.EnforcerRule#isResultValid(org.apache.maven.enforcer.rule.api.EnforcerRule)
*/
public boolean isResultValid( EnforcerRule theCachedRule )
{
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java Fri Oct 10 16:35:26 2014
@@ -84,7 +84,8 @@ public class RequirePluginVersions
extends AbstractNonCacheableEnforcerRule
{
- /** Don't allow the LATEST identifier.
+ /**
+ * Don't allow the LATEST identifier.
*
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setBanLatest(boolean)}
@@ -92,15 +93,17 @@ public class RequirePluginVersions
*/
public boolean banLatest = true;
- /** Don't allow the RELEASE identifier.
- *
+ /**
+ * Don't allow the RELEASE identifier.
+ *
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setBanRelease(boolean)}
* @see {@link #isBanRelease()}
*/
public boolean banRelease = true;
- /** Don't allow snapshot plugins.
+ /**
+ * Don't allow snapshot plugins.
*
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setBanSnapshots(boolean)}
@@ -108,7 +111,8 @@ public class RequirePluginVersions
*/
public boolean banSnapshots = true;
- /** Don't allow timestamp snapshot plugins.
+ /**
+ * Don't allow timestamp snapshot plugins.
*
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setBanTimestamps(boolean)}
@@ -150,8 +154,8 @@ public class RequirePluginVersions
/**
* Same as unCheckedPlugins but as a comma list to better support properties. Sample form:
* <code>group:artifactId,group2:artifactId2</code>
- * @since 1.0-beta-1
*
+ * @since 1.0-beta-1
* @deprecated the visibility will be reduced to private with the next major version
* @see {@link #setUnCheckedPlugins(List)}
* @see {@link #getUnCheckedPlugins()}
@@ -190,8 +194,8 @@ public class RequirePluginVersions
/*
* (non-Javadoc)
- *
- * @see org.apache.maven.enforcer.rule.api.EnforcerRule#execute(org.apache.maven.enforcer.rule.api.EnforcerRuleHelper)
+ * @see
+ * org.apache.maven.enforcer.rule.api.EnforcerRule#execute(org.apache.maven.enforcer.rule.api.EnforcerRuleHelper)
*/
public void execute( EnforcerRuleHelper helper )
throws EnforcerRuleException
@@ -217,7 +221,8 @@ public class RequirePluginVersions
(Map) ReflectionUtils.getValueIncludingSuperclasses( "lifecycles", defaultLifeCycles );
lifecycles = lifecyclesMap.values();
}
- else // Using Maven 2
+ else
+ // Using Maven 2
{
lifecycles = (Collection) ReflectionUtils.getValueIncludingSuperclasses( "lifecycles", life );
}
@@ -238,7 +243,6 @@ public class RequirePluginVersions
allPlugins = addAdditionalPlugins( allPlugins, additionalPlugins );
allPlugins.addAll( getProfilePlugins( project ) );
-
// pull out any we should skip
allPlugins =
(Set) removeUncheckedPlugins( combineUncheckedPlugins( unCheckedPlugins, unCheckedPluginList ),
@@ -395,16 +399,17 @@ public class RequirePluginVersions
/**
* Combines the old Collection with the new comma separated list.
+ *
* @param uncheckedPlugins
* @param uncheckedPluginsList
* @return
*/
public Collection<String> combineUncheckedPlugins( Collection<String> uncheckedPlugins, String uncheckedPluginsList )
{
- //if the comma list is empty, then there's nothing to do here.
+ // if the comma list is empty, then there's nothing to do here.
if ( StringUtils.isNotEmpty( uncheckedPluginsList ) )
{
- //make sure there is a collection to add to.
+ // make sure there is a collection to add to.
if ( uncheckedPlugins == null )
{
uncheckedPlugins = new HashSet<String>();
@@ -454,7 +459,7 @@ public class RequirePluginVersions
* Helper method to parse and inject a Plugin.
*
* @param pluginString
- * @param field
+ * @param field
* @throws MojoExecutionException
* @return the plugin
*/
@@ -627,7 +632,8 @@ public class RequirePluginVersions
* @param pluginWrappers the plugins
* @return true, if successful
*/
- protected boolean hasValidVersionSpecified( EnforcerRuleHelper helper, Plugin source, List<PluginWrapper> pluginWrappers )
+ protected boolean hasValidVersionSpecified( EnforcerRuleHelper helper, Plugin source,
+ List<PluginWrapper> pluginWrappers )
{
boolean found = false;
boolean status = false;
@@ -790,7 +796,7 @@ public class RequirePluginVersions
for ( Lifecycle lifecycle : lifecycles )
{
@SuppressWarnings( "unchecked" )
- List<String> phases = lifecycle.getPhases();
+ List<String> phases = lifecycle.getPhases();
for ( String phase : phases )
{
if ( phaseToLifecycleMap.containsKey( phase ) )
@@ -923,7 +929,7 @@ public class RequirePluginVersions
catch ( ComponentLookupException e )
{
log.debug( "Error looking up lifecycle mapping to retrieve optional mojos. Lifecycle ID: "
- + lifecycle.getId() + ". Error: " + e.getMessage(), e );
+ + lifecycle.getId() + ". Error: " + e.getMessage(), e );
}
}
@@ -968,7 +974,7 @@ public class RequirePluginVersions
try
{
pluginComponent = pluginManager.getPluginComponent( plugin, role, roleHint );
-
+
if ( pluginComponent != null )
{
break;
@@ -1056,7 +1062,7 @@ public class RequirePluginVersions
{
List<PluginWrapper> plugins = new ArrayList<PluginWrapper>();
// get all the pom models
-
+
String pomName = null;
try
{
@@ -1076,8 +1082,9 @@ public class RequirePluginVersions
{
try
{
- List<Plugin> modelPlugins = model.getBuild().getPlugins();
- plugins.addAll( PluginWrapper.addAll( utils.resolvePlugins( modelPlugins ), model.getId() + ".build.plugins" ) );
+ List<Plugin> modelPlugins = model.getBuild().getPlugins();
+ plugins.addAll( PluginWrapper.addAll( utils.resolvePlugins( modelPlugins ), model.getId()
+ + ".build.plugins" ) );
}
catch ( NullPointerException e )
{
@@ -1086,9 +1093,10 @@ public class RequirePluginVersions
try
{
- List<ReportPlugin> modelReportPlugins = model.getReporting().getPlugins();
+ List<ReportPlugin> modelReportPlugins = model.getReporting().getPlugins();
// add the reporting plugins
- plugins.addAll( PluginWrapper.addAll( utils.resolveReportPlugins( modelReportPlugins ), model.getId() + ".reporting" ) );
+ plugins.addAll( PluginWrapper.addAll( utils.resolveReportPlugins( modelReportPlugins ), model.getId()
+ + ".reporting" ) );
}
catch ( NullPointerException e )
{
@@ -1097,9 +1105,9 @@ public class RequirePluginVersions
try
{
- List<Plugin> modelPlugins = model.getBuild().getPluginManagement().getPlugins();
- plugins.addAll( PluginWrapper.addAll( utils.resolvePlugins( modelPlugins ),
- model.getId() + ".build.pluginManagement.plugins" ) );
+ List<Plugin> modelPlugins = model.getBuild().getPluginManagement().getPlugins();
+ plugins.addAll( PluginWrapper.addAll( utils.resolvePlugins( modelPlugins ), model.getId()
+ + ".build.pluginManagement.plugins" ) );
}
catch ( NullPointerException e )
{
@@ -1112,7 +1120,7 @@ public class RequirePluginVersions
{
try
{
- List<Plugin> modelPlugins = profile.getBuild().getPlugins();
+ List<Plugin> modelPlugins = profile.getBuild().getPlugins();
plugins.addAll( PluginWrapper.addAll( utils.resolvePlugins( modelPlugins ), model.getId()
+ ".profiles.profile[" + profile.getId() + "].build.plugins" ) );
}
@@ -1123,10 +1131,11 @@ public class RequirePluginVersions
try
{
- List<ReportPlugin> modelReportPlugins = profile.getReporting().getPlugins();
+ List<ReportPlugin> modelReportPlugins = profile.getReporting().getPlugins();
// add the reporting plugins
- plugins.addAll( PluginWrapper.addAll( utils.resolveReportPlugins( modelReportPlugins ), model.getId()
- + "profile[" + profile.getId() + "].reporting.plugins" ) );
+ plugins.addAll( PluginWrapper.addAll( utils.resolveReportPlugins( modelReportPlugins ),
+ model.getId() + "profile[" + profile.getId()
+ + "].reporting.plugins" ) );
}
catch ( NullPointerException e )
{
@@ -1134,10 +1143,9 @@ public class RequirePluginVersions
}
try
{
- List<Plugin> modelPlugins = profile.getBuild().getPluginManagement().getPlugins();
- plugins.addAll( PluginWrapper.addAll( utils.resolvePlugins( modelPlugins ),
- model.getId() + "profile[" + profile.getId()
- + "].build.pluginManagement.plugins" ) );
+ List<Plugin> modelPlugins = profile.getBuild().getPluginManagement().getPlugins();
+ plugins.addAll( PluginWrapper.addAll( utils.resolvePlugins( modelPlugins ), model.getId()
+ + "profile[" + profile.getId() + "].build.pluginManagement.plugins" ) );
}
catch ( NullPointerException e )
{
@@ -1258,22 +1266,22 @@ public class RequirePluginVersions
{
this.unCheckedPlugins = unCheckedPlugins;
}
-
+
public final void setPhases( String phases )
{
this.phases = phases;
}
-
+
public final String getPhases()
{
return phases;
}
-
+
public final void setAdditionalPlugins( List<String> additionalPlugins )
{
this.additionalPlugins = additionalPlugins;
}
-
+
public final List<String> getAdditionalPlugins()
{
return additionalPlugins;
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePrerequisite.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePrerequisite.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePrerequisite.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePrerequisite.java Fri Oct 10 16:35:26 2014
@@ -30,28 +30,26 @@ import org.apache.maven.project.MavenPro
import org.codehaus.plexus.component.configurator.expression.ExpressionEvaluationException;
/**
- *
* @author Robert Scholte
* @since 1.3
*/
-public class RequirePrerequisite extends AbstractNonCacheableEnforcerRule
+public class RequirePrerequisite
+ extends AbstractNonCacheableEnforcerRule
{
/**
* Only the projects with one of these packagings will be enforced to have the correct prerequisite.
- *
+ *
* @since 1.4
*/
private List<String> packagings;
-
+
/**
* Can either be version or a range, e.g. {@code 2.2.1} or {@code [2.2.1,)}
*/
private String mavenVersion;
/**
- * Set the mavenVersion
- *
- * Can either be version or a range, e.g. {@code 2.2.1} or {@code [2.2.1,)}
+ * Set the mavenVersion Can either be version or a range, e.g. {@code 2.2.1} or {@code [2.2.1,)}
*
* @param mavenVersion the version or {@code null}
*/
@@ -59,7 +57,7 @@ public class RequirePrerequisite extends
{
this.mavenVersion = mavenVersion;
}
-
+
/**
* Only the projects with one of these packagings will be enforced to have the correct prerequisite.
*
@@ -70,7 +68,7 @@ public class RequirePrerequisite extends
{
this.packagings = packagings;
}
-
+
/**
* {@inheritDoc}
*/
@@ -92,9 +90,9 @@ public class RequirePrerequisite extends
helper.getLog().debug( "Packaging is " + project.getPackaging() + ", skipping requirePrerequisite rule" );
return;
}
-
- Prerequisites prerequisites = project.getPrerequisites();
-
+
+ Prerequisites prerequisites = project.getPrerequisites();
+
if ( prerequisites == null )
{
throw new EnforcerRuleException( "Requires prerequisite not set" );
@@ -102,18 +100,18 @@ public class RequirePrerequisite extends
if ( mavenVersion != null )
{
-
+
VersionRange requiredVersionRange = VersionRange.createFromVersionSpec( mavenVersion );
if ( !requiredVersionRange.hasRestrictions() )
{
requiredVersionRange = VersionRange.createFromVersionSpec( "[" + mavenVersion + ",)" );
}
-
+
VersionRange specifiedVersion = VersionRange.createFromVersionSpec( prerequisites.getMaven() );
-
+
VersionRange restrictedVersionRange = requiredVersionRange.restrict( specifiedVersion );
-
+
if ( restrictedVersionRange.getRecommendedVersion() == null )
{
throw new EnforcerRuleException( "The specified Maven prerequisite( " + specifiedVersion
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSameVersions.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSameVersions.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSameVersions.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSameVersions.java Fri Oct 10 16:35:26 2014
@@ -35,7 +35,6 @@ import org.apache.maven.project.MavenPro
import org.codehaus.plexus.component.configurator.expression.ExpressionEvaluationException;
/**
- *
* @author Robert Scholte
* @since 1.3
*/
@@ -97,19 +96,19 @@ public class RequireSameVersions
String source )
{
Map<String, List<String>> versionMembers = new LinkedHashMap<String, List<String>>();
-
+
List<Pattern> regExs = new ArrayList<Pattern>();
for ( String pattern : patterns )
{
String regex = pattern.replace( ".", "\\." ).replace( "*", ".*" ).replace( ":", "\\:" ).replace( '?', '.' );
// pattern is groupId[:artifactId[:type[:classifier]]]
- regExs.add( Pattern.compile( regex + "(\\:.+)?" ) );
+ regExs.add( Pattern.compile( regex + "(\\:.+)?" ) );
}
-
+
for ( Artifact artifact : artifacts )
{
- for ( Pattern regEx: regExs )
+ for ( Pattern regEx : regExs )
{
if ( regEx.matcher( artifact.getDependencyConflictId() ).matches() )
{
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/ArtifactMatcher.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/ArtifactMatcher.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/ArtifactMatcher.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/ArtifactMatcher.java Fri Oct 10 16:35:26 2014
@@ -134,13 +134,13 @@ public final class ArtifactMatcher
String regex =
expression.replace( ".", "\\." ).replace( "*", ".*" ).replace( ":", "\\:" ).replace( '?', '.' );
- //TODO: Check if this can be done better or prevented earlier.
+ // TODO: Check if this can be done better or prevented earlier.
if ( input == null )
{
input = "";
}
- return java.util.regex.Pattern.matches( regex , input );
+ return java.util.regex.Pattern.matches( regex, input );
}
@Override
Modified: maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/EnforcerRuleUtils.java
URL: http://svn.apache.org/viewvc/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/EnforcerRuleUtils.java?rev=1630934&r1=1630933&r2=1630934&view=diff
==============================================================================
--- maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/EnforcerRuleUtils.java (original)
+++ maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/EnforcerRuleUtils.java Fri Oct 10 16:35:26 2014
@@ -132,13 +132,11 @@ public class EnforcerRuleUtils
* Gets the pom model for this file.
*
* @param pom the pom
- *
* @return the model
- *
* @throws IOException Signals that an I/O exception has occurred.
* @throws XmlPullParserException the xml pull parser exception
*/
- private Model readModel ( File pom )
+ private Model readModel( File pom )
throws IOException, XmlPullParserException
{
Reader reader = ReaderFactory.newXmlReader( pom );
@@ -157,23 +155,20 @@ public class EnforcerRuleUtils
}
/**
- * This method gets the model for the defined artifact.
- * Looks first in the filesystem, then tries to get it
- * from the repo.
+ * This method gets the model for the defined artifact. Looks first in the filesystem, then tries to get it from the
+ * repo.
*
* @param groupId the group id
* @param artifactId the artifact id
* @param version the version
* @param pom the pom
- *
* @return the pom model
- *
* @throws ArtifactResolutionException the artifact resolution exception
* @throws ArtifactNotFoundException the artifact not found exception
* @throws XmlPullParserException the xml pull parser exception
* @throws IOException Signals that an I/O exception has occurred.
*/
- private Model getPomModel ( String groupId, String artifactId, String version, File pom )
+ private Model getPomModel( String groupId, String artifactId, String version, File pom )
throws ArtifactResolutionException, ArtifactNotFoundException, IOException, XmlPullParserException
{
Model model = null;
@@ -219,22 +214,19 @@ public class EnforcerRuleUtils
}
/**
- * This method loops through all the parents, getting
- * each pom model and then its parent.
+ * This method loops through all the parents, getting each pom model and then its parent.
*
* @param groupId the group id
* @param artifactId the artifact id
* @param version the version
* @param pom the pom
- *
* @return the models recursively
- *
* @throws ArtifactResolutionException the artifact resolution exception
* @throws ArtifactNotFoundException the artifact not found exception
* @throws IOException Signals that an I/O exception has occurred.
* @throws XmlPullParserException the xml pull parser exception
*/
- public List<Model> getModelsRecursively ( String groupId, String artifactId, String version, File pom )
+ public List<Model> getModelsRecursively( String groupId, String artifactId, String version, File pom )
throws ArtifactResolutionException, ArtifactNotFoundException, IOException, XmlPullParserException
{
List<Model> models = null;
@@ -279,10 +271,9 @@ public class EnforcerRuleUtils
* @param artifactId the artifact id
* @param version the version
* @param model Model being checked.
- *
* @return true, if check if model matches
*/
- protected boolean checkIfModelMatches ( String groupId, String artifactId, String version, Model model )
+ protected boolean checkIfModelMatches( String groupId, String artifactId, String version, Model model )
{
// try these first.
String modelGroup = model.getGroupId();
@@ -310,7 +301,7 @@ public class EnforcerRuleUtils
// MENFORCER-30, handle cases where the value is a property like ${project.parent.version}
modelVersion = (String) helper.evaluate( modelVersion );
}
-
+
// Is this only required for Maven2?
modelArtifactId = (String) helper.evaluate( modelArtifactId );
}
@@ -326,11 +317,10 @@ public class EnforcerRuleUtils
{
// as above
}
- return ( StringUtils.equals( groupId, modelGroup ) && StringUtils.equals( version, modelVersion ) && StringUtils
- .equals( artifactId, modelArtifactId ) );
+ return ( StringUtils.equals( groupId, modelGroup ) && StringUtils.equals( version, modelVersion ) && StringUtils.equals( artifactId,
+ modelArtifactId ) );
}
-
-
+
private void resolve( Plugin plugin )
{
try
@@ -344,7 +334,7 @@ public class EnforcerRuleUtils
// this should have gone already before
}
}
-
+
private void resolve( ReportPlugin plugin )
{
try
@@ -358,7 +348,7 @@ public class EnforcerRuleUtils
// this should have gone already before
}
}
-
+
public List<Plugin> resolvePlugins( List<Plugin> plugins )
{
for ( Plugin plugin : plugins )
@@ -367,7 +357,7 @@ public class EnforcerRuleUtils
}
return plugins;
}
-
+
public List<ReportPlugin> resolveReportPlugins( List<ReportPlugin> reportPlugins )
{
for ( ReportPlugin plugin : reportPlugins )
@@ -377,5 +367,4 @@ public class EnforcerRuleUtils
return reportPlugins;
}
-
}
Re: errors reported by Checkstyle
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Hervé,
On 10/11/14 9:00 AM, Hervé BOUTEMY wrote:
>> Log:
>> - Fixed several Checkstyle errors.
>>
> notice that these are errors *reported by* Checkstyle, not really Checkstyle
> errors
>
> Checkstyle should add "don't shoot the messenger" disclaimer ;)
I don't shoot the messager....never......already fixed...;-)
r1630934 | khmarbaise | 2014-10-10 18:35:26 +0200 (Fri, 10 Oct 2014) | 2
lines
- Fixed several errors reported by Checkstyle
>
>
> I report here because next maven-parent version will enable Checkstyle check
> on every build: we must all know that we chose the rules that Checkstyle will
> report to us. If some rules are too strict, perhaps we'll need to relax them,
> but be prepared to avoid blaming Checkstyle :)
I never blame checkstyle ;-...
>
>
> Notice I prepared some escape ways when checkstyle:check will be run on each
> build, to limit frustration:
>
> 1. verify phase only, to let us concentrate on making code work before fixing
> broken coding conventions
>
> 2. @SuppressWarning support (MCHECKSTYLE-241) to ignore individual rules
> directly into source code
>
> 3. CHECKSTYLE_OFF/ON support (MCHECKSTYLE-247) to ignore rules on complete
> code fragments when necessary
>
> 4. fine grained global rule or even rule category (MCHECKSTYLE-242) to ignore
> rules or rule categories of a whole build with a single property in pom.xml
>
>
> I hope everybody will enjoy maven-parent 25 like me...
That's what i tried to do and checked against maven-parent 25-SNAPSHOT
....which resulted in those hints...which i have started to clean up...
Kind regards
Karl-Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: errors reported by Checkstyle
Posted by Hervé BOUTEMY <he...@free.fr>.
in general, annotations on a method are about the method: actual recomendation
is ok for that
but JSR 305 annotations are about the return type: IMHO, these annotations are
best like proposed by Andreas
this would require Checkstyle new feature
and consensus in the Maven team to use it
let's start with the Checkstyle feature request: I suppose this discussion
with Checkstyle dev team will be interesting, to share ideas
Regards,
Hervé
Le dimanche 26 octobre 2014 10:17:13 Dennis Lundberg a écrit :
> Hi,
>
> My personal preference is to have all annotations first, i.e. before the
> visibility modifier.
>
> I checked the JLS, but couldn't find any recommendation. The examples in
> chapter 9.7 use the order that Checkstyle suggests.
>
> --
> Dennis Lundberg
>
> Den 25 okt 2014 20:38 skrev "Andreas Gudian" <an...@gmail.com>:
> > I've started switching on maven-parent 25 in surefire now and I see
> > literary hundreds of checkstyle errors (I ignore the warnings for now).
> > Most of the stuff is fine with me and I'm on fixing them for a couple of
> > days already.
> >
> > But there's one thing that struck me and that I'm a bit reluctant to
> > change
> > - and I'd like your opinion on it.
> >
> > We have for example this method:
> > private @Nonnull List<String> getExcluded() ...
> >
> > Checkstyle now tells me that the @Nonnull should preceed the private
> >
> > modifier:
> > @Nonnull private List<String> getExcluded() ...
> >
> > Especially as Java 8 introduced the notion of annotated type declarations
> > (as in @Nonnull String myNeverNullVariable; ), I think that this
> > particular
> > @Nonnull annotation should be right in front of the return type and not
> > before the visibility modifier.
> >
> > The message is thrown by the ModifierOrder check (which does other good
> > things) and that one can't be configured to behave differently.
> >
> > So now I'd have to specifically ignore that warning on each method for
> > which we qualify the return type with @Nonnull / @Nullable.
> >
> > What's you pick on this? Is the form suggested by checkstyle really to be
> > preferred? I'd open an issue for them if you also think that it might need
> > some tweaking.
> >
> > Thanks,
> > Andreas
> >
> > 2014-10-14 8:34 GMT+02:00 Hervé BOUTEMY <he...@free.fr>:
> > > Le mardi 14 octobre 2014 09:28:21 Olivier Lamy a écrit :
> > > > On 14 October 2014 05:01, Hervé BOUTEMY <he...@free.fr> wrote:
> > > > > 2. if we configured Checkstyle to report an error, this means check
> > >
> > > should
> > >
> > > > > fail: if you find that it should not fail, please help improve
> > >
> > > Checkstyle
> > >
> > > > > configuration by setting severity to warning only
> > > >
> > > > /me not a checkstyle expert configuration :-)
> > >
> > > this makes me remember there is a feature improvement for m-checkstyle-p
> > > 2.13
> > > that I should explain: I was not a Checkstyle configuration master and
> >
> > felt
> >
> > > like you
> > > Than I consistently reported Checkstyle rule name and category in every
> > > message and report, and a link to Checkstyle documentation for each rule
> > > [1]
> > >
> > > this gives a good intro to Checkstyle configuration and help a lot when
> > > needing
> > > to @SuppressWarnings( "checkstyle:name of rule, in lowercase")
> > >
> > > > /me asking himself if having such hard checkstyle requirement help to
> > > > improve user experience.
> > >
> > > from my perspective, previous feature really improved m-checkstyle-p
> > > experience
> > > and I know I should submit patches to Checkstyle itself, because I think
> > > this
> > > could help their users too when using bare-Checkstyle
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > > [1]
> > > http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle.html
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: errors reported by Checkstyle
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
i have a question for this topic:
checkstyle reported that the license header is not correct...
[INFO] There are 5 checkstyle errors.
[ERROR] JavaCodeTransform.java[4] (header) RegexpHeader: Line does not
match expected header line of '^ \* Licensed to the Apache Software
Foundation \(ASF\) under one\s*$'.
I'm more the opinion to let do that the apache-rat-plugin instead of
checkstyle...
WDYT ?
Kind regards
Karl Heinz Marbaise
On 10/26/14 10:19 AM, Dennis Lundberg wrote:
> I agree, and believe that it was Hervè's intention for this to be a "soft"
> rule, at least to start with.
>
> --
> Dennis Lundberg
> Den 26 okt 2014 07:47 skrev "Kristian Rosenvold" <
> kristian.rosenvold@gmail.com>:
>
>> I dont mind the checkstyle stuff, but we have /not/ had a vote that
>> mandates this to be a requirement. Until we do so I think we should
>> safely just add "skip" to checkstyle where it's inappropriate, or
>> ignore more stuff.
>>
>> Kristian
>>
>> 2014-10-25 20:36 GMT+02:00 Andreas Gudian <an...@gmail.com>:
>>> I've started switching on maven-parent 25 in surefire now and I see
>>> literary hundreds of checkstyle errors (I ignore the warnings for now).
>>> Most of the stuff is fine with me and I'm on fixing them for a couple of
>>> days already.
>>>
>>> But there's one thing that struck me and that I'm a bit reluctant to
>> change
>>> - and I'd like your opinion on it.
>>>
>>> We have for example this method:
>>> private @Nonnull List<String> getExcluded() ...
>>>
>>> Checkstyle now tells me that the @Nonnull should preceed the private
>>> modifier:
>>>
>>> @Nonnull private List<String> getExcluded() ...
>>>
>>> Especially as Java 8 introduced the notion of annotated type declarations
>>> (as in @Nonnull String myNeverNullVariable; ), I think that this
>> particular
>>> @Nonnull annotation should be right in front of the return type and not
>>> before the visibility modifier.
>>>
>>> The message is thrown by the ModifierOrder check (which does other good
>>> things) and that one can't be configured to behave differently.
>>>
>>> So now I'd have to specifically ignore that warning on each method for
>>> which we qualify the return type with @Nonnull / @Nullable.
>>>
>>> What's you pick on this? Is the form suggested by checkstyle really to be
>>> preferred? I'd open an issue for them if you also think that it might
>> need
>>> some tweaking.
>>>
>>> Thanks,
>>> Andreas
>>>
>>>
>>>
>>> 2014-10-14 8:34 GMT+02:00 Hervé BOUTEMY <he...@free.fr>:
>>>
>>>> Le mardi 14 octobre 2014 09:28:21 Olivier Lamy a écrit :
>>>>> On 14 October 2014 05:01, Hervé BOUTEMY <he...@free.fr>
>> wrote:
>>>>>> 2. if we configured Checkstyle to report an error, this means check
>>>> should
>>>>>> fail: if you find that it should not fail, please help improve
>>>> Checkstyle
>>>>>> configuration by setting severity to warning only
>>>>>
>>>>> /me not a checkstyle expert configuration :-)
>>>> this makes me remember there is a feature improvement for m-checkstyle-p
>>>> 2.13
>>>> that I should explain: I was not a Checkstyle configuration master and
>> felt
>>>> like you
>>>> Than I consistently reported Checkstyle rule name and category in every
>>>> message and report, and a link to Checkstyle documentation for each rule
>>>> [1]
>>>>
>>>> this gives a good intro to Checkstyle configuration and help a lot when
>>>> needing
>>>> to @SuppressWarnings( "checkstyle:name of rule, in lowercase")
>>>>
>>>>> /me asking himself if having such hard checkstyle requirement help to
>>>>> improve user experience.
>>>> from my perspective, previous feature really improved m-checkstyle-p
>>>> experience
>>>> and I know I should submit patches to Checkstyle itself, because I think
>>>> this
>>>> could help their users too when using bare-Checkstyle
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: errors reported by Checkstyle
Posted by Dennis Lundberg <de...@apache.org>.
I agree, and believe that it was Hervè's intention for this to be a "soft"
rule, at least to start with.
--
Dennis Lundberg
Den 26 okt 2014 07:47 skrev "Kristian Rosenvold" <
kristian.rosenvold@gmail.com>:
> I dont mind the checkstyle stuff, but we have /not/ had a vote that
> mandates this to be a requirement. Until we do so I think we should
> safely just add "skip" to checkstyle where it's inappropriate, or
> ignore more stuff.
>
> Kristian
>
> 2014-10-25 20:36 GMT+02:00 Andreas Gudian <an...@gmail.com>:
> > I've started switching on maven-parent 25 in surefire now and I see
> > literary hundreds of checkstyle errors (I ignore the warnings for now).
> > Most of the stuff is fine with me and I'm on fixing them for a couple of
> > days already.
> >
> > But there's one thing that struck me and that I'm a bit reluctant to
> change
> > - and I'd like your opinion on it.
> >
> > We have for example this method:
> > private @Nonnull List<String> getExcluded() ...
> >
> > Checkstyle now tells me that the @Nonnull should preceed the private
> > modifier:
> >
> > @Nonnull private List<String> getExcluded() ...
> >
> > Especially as Java 8 introduced the notion of annotated type declarations
> > (as in @Nonnull String myNeverNullVariable; ), I think that this
> particular
> > @Nonnull annotation should be right in front of the return type and not
> > before the visibility modifier.
> >
> > The message is thrown by the ModifierOrder check (which does other good
> > things) and that one can't be configured to behave differently.
> >
> > So now I'd have to specifically ignore that warning on each method for
> > which we qualify the return type with @Nonnull / @Nullable.
> >
> > What's you pick on this? Is the form suggested by checkstyle really to be
> > preferred? I'd open an issue for them if you also think that it might
> need
> > some tweaking.
> >
> > Thanks,
> > Andreas
> >
> >
> >
> > 2014-10-14 8:34 GMT+02:00 Hervé BOUTEMY <he...@free.fr>:
> >
> >> Le mardi 14 octobre 2014 09:28:21 Olivier Lamy a écrit :
> >> > On 14 October 2014 05:01, Hervé BOUTEMY <he...@free.fr>
> wrote:
> >> > > 2. if we configured Checkstyle to report an error, this means check
> >> should
> >> > > fail: if you find that it should not fail, please help improve
> >> Checkstyle
> >> > > configuration by setting severity to warning only
> >> >
> >> > /me not a checkstyle expert configuration :-)
> >> this makes me remember there is a feature improvement for m-checkstyle-p
> >> 2.13
> >> that I should explain: I was not a Checkstyle configuration master and
> felt
> >> like you
> >> Than I consistently reported Checkstyle rule name and category in every
> >> message and report, and a link to Checkstyle documentation for each rule
> >> [1]
> >>
> >> this gives a good intro to Checkstyle configuration and help a lot when
> >> needing
> >> to @SuppressWarnings( "checkstyle:name of rule, in lowercase")
> >>
> >> > /me asking himself if having such hard checkstyle requirement help to
> >> > improve user experience.
> >> from my perspective, previous feature really improved m-checkstyle-p
> >> experience
> >> and I know I should submit patches to Checkstyle itself, because I think
> >> this
> >> could help their users too when using bare-Checkstyle
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >>
> >> [1]
> >> http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle.html
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: errors reported by Checkstyle
Posted by Kristian Rosenvold <kr...@gmail.com>.
I dont mind the checkstyle stuff, but we have /not/ had a vote that
mandates this to be a requirement. Until we do so I think we should
safely just add "skip" to checkstyle where it's inappropriate, or
ignore more stuff.
Kristian
2014-10-25 20:36 GMT+02:00 Andreas Gudian <an...@gmail.com>:
> I've started switching on maven-parent 25 in surefire now and I see
> literary hundreds of checkstyle errors (I ignore the warnings for now).
> Most of the stuff is fine with me and I'm on fixing them for a couple of
> days already.
>
> But there's one thing that struck me and that I'm a bit reluctant to change
> - and I'd like your opinion on it.
>
> We have for example this method:
> private @Nonnull List<String> getExcluded() ...
>
> Checkstyle now tells me that the @Nonnull should preceed the private
> modifier:
>
> @Nonnull private List<String> getExcluded() ...
>
> Especially as Java 8 introduced the notion of annotated type declarations
> (as in @Nonnull String myNeverNullVariable; ), I think that this particular
> @Nonnull annotation should be right in front of the return type and not
> before the visibility modifier.
>
> The message is thrown by the ModifierOrder check (which does other good
> things) and that one can't be configured to behave differently.
>
> So now I'd have to specifically ignore that warning on each method for
> which we qualify the return type with @Nonnull / @Nullable.
>
> What's you pick on this? Is the form suggested by checkstyle really to be
> preferred? I'd open an issue for them if you also think that it might need
> some tweaking.
>
> Thanks,
> Andreas
>
>
>
> 2014-10-14 8:34 GMT+02:00 Hervé BOUTEMY <he...@free.fr>:
>
>> Le mardi 14 octobre 2014 09:28:21 Olivier Lamy a écrit :
>> > On 14 October 2014 05:01, Hervé BOUTEMY <he...@free.fr> wrote:
>> > > 2. if we configured Checkstyle to report an error, this means check
>> should
>> > > fail: if you find that it should not fail, please help improve
>> Checkstyle
>> > > configuration by setting severity to warning only
>> >
>> > /me not a checkstyle expert configuration :-)
>> this makes me remember there is a feature improvement for m-checkstyle-p
>> 2.13
>> that I should explain: I was not a Checkstyle configuration master and felt
>> like you
>> Than I consistently reported Checkstyle rule name and category in every
>> message and report, and a link to Checkstyle documentation for each rule
>> [1]
>>
>> this gives a good intro to Checkstyle configuration and help a lot when
>> needing
>> to @SuppressWarnings( "checkstyle:name of rule, in lowercase")
>>
>> > /me asking himself if having such hard checkstyle requirement help to
>> > improve user experience.
>> from my perspective, previous feature really improved m-checkstyle-p
>> experience
>> and I know I should submit patches to Checkstyle itself, because I think
>> this
>> could help their users too when using bare-Checkstyle
>>
>> Regards,
>>
>> Hervé
>>
>>
>> [1]
>> http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: errors reported by Checkstyle
Posted by Dennis Lundberg <de...@apache.org>.
Hi,
My personal preference is to have all annotations first, i.e. before the
visibility modifier.
I checked the JLS, but couldn't find any recommendation. The examples in
chapter 9.7 use the order that Checkstyle suggests.
--
Dennis Lundberg
Den 25 okt 2014 20:38 skrev "Andreas Gudian" <an...@gmail.com>:
> I've started switching on maven-parent 25 in surefire now and I see
> literary hundreds of checkstyle errors (I ignore the warnings for now).
> Most of the stuff is fine with me and I'm on fixing them for a couple of
> days already.
>
> But there's one thing that struck me and that I'm a bit reluctant to change
> - and I'd like your opinion on it.
>
> We have for example this method:
> private @Nonnull List<String> getExcluded() ...
>
> Checkstyle now tells me that the @Nonnull should preceed the private
> modifier:
>
> @Nonnull private List<String> getExcluded() ...
>
> Especially as Java 8 introduced the notion of annotated type declarations
> (as in @Nonnull String myNeverNullVariable; ), I think that this particular
> @Nonnull annotation should be right in front of the return type and not
> before the visibility modifier.
>
> The message is thrown by the ModifierOrder check (which does other good
> things) and that one can't be configured to behave differently.
>
> So now I'd have to specifically ignore that warning on each method for
> which we qualify the return type with @Nonnull / @Nullable.
>
> What's you pick on this? Is the form suggested by checkstyle really to be
> preferred? I'd open an issue for them if you also think that it might need
> some tweaking.
>
> Thanks,
> Andreas
>
>
>
> 2014-10-14 8:34 GMT+02:00 Hervé BOUTEMY <he...@free.fr>:
>
> > Le mardi 14 octobre 2014 09:28:21 Olivier Lamy a écrit :
> > > On 14 October 2014 05:01, Hervé BOUTEMY <he...@free.fr> wrote:
> > > > 2. if we configured Checkstyle to report an error, this means check
> > should
> > > > fail: if you find that it should not fail, please help improve
> > Checkstyle
> > > > configuration by setting severity to warning only
> > >
> > > /me not a checkstyle expert configuration :-)
> > this makes me remember there is a feature improvement for m-checkstyle-p
> > 2.13
> > that I should explain: I was not a Checkstyle configuration master and
> felt
> > like you
> > Than I consistently reported Checkstyle rule name and category in every
> > message and report, and a link to Checkstyle documentation for each rule
> > [1]
> >
> > this gives a good intro to Checkstyle configuration and help a lot when
> > needing
> > to @SuppressWarnings( "checkstyle:name of rule, in lowercase")
> >
> > > /me asking himself if having such hard checkstyle requirement help to
> > > improve user experience.
> > from my perspective, previous feature really improved m-checkstyle-p
> > experience
> > and I know I should submit patches to Checkstyle itself, because I think
> > this
> > could help their users too when using bare-Checkstyle
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1]
> > http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle.html
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: errors reported by Checkstyle
Posted by Andreas Gudian <an...@gmail.com>.
I've started switching on maven-parent 25 in surefire now and I see
literary hundreds of checkstyle errors (I ignore the warnings for now).
Most of the stuff is fine with me and I'm on fixing them for a couple of
days already.
But there's one thing that struck me and that I'm a bit reluctant to change
- and I'd like your opinion on it.
We have for example this method:
private @Nonnull List<String> getExcluded() ...
Checkstyle now tells me that the @Nonnull should preceed the private
modifier:
@Nonnull private List<String> getExcluded() ...
Especially as Java 8 introduced the notion of annotated type declarations
(as in @Nonnull String myNeverNullVariable; ), I think that this particular
@Nonnull annotation should be right in front of the return type and not
before the visibility modifier.
The message is thrown by the ModifierOrder check (which does other good
things) and that one can't be configured to behave differently.
So now I'd have to specifically ignore that warning on each method for
which we qualify the return type with @Nonnull / @Nullable.
What's you pick on this? Is the form suggested by checkstyle really to be
preferred? I'd open an issue for them if you also think that it might need
some tweaking.
Thanks,
Andreas
2014-10-14 8:34 GMT+02:00 Hervé BOUTEMY <he...@free.fr>:
> Le mardi 14 octobre 2014 09:28:21 Olivier Lamy a écrit :
> > On 14 October 2014 05:01, Hervé BOUTEMY <he...@free.fr> wrote:
> > > 2. if we configured Checkstyle to report an error, this means check
> should
> > > fail: if you find that it should not fail, please help improve
> Checkstyle
> > > configuration by setting severity to warning only
> >
> > /me not a checkstyle expert configuration :-)
> this makes me remember there is a feature improvement for m-checkstyle-p
> 2.13
> that I should explain: I was not a Checkstyle configuration master and felt
> like you
> Than I consistently reported Checkstyle rule name and category in every
> message and report, and a link to Checkstyle documentation for each rule
> [1]
>
> this gives a good intro to Checkstyle configuration and help a lot when
> needing
> to @SuppressWarnings( "checkstyle:name of rule, in lowercase")
>
> > /me asking himself if having such hard checkstyle requirement help to
> > improve user experience.
> from my perspective, previous feature really improved m-checkstyle-p
> experience
> and I know I should submit patches to Checkstyle itself, because I think
> this
> could help their users too when using bare-Checkstyle
>
> Regards,
>
> Hervé
>
>
> [1]
> http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: errors reported by Checkstyle
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 14 octobre 2014 09:28:21 Olivier Lamy a écrit :
> On 14 October 2014 05:01, Hervé BOUTEMY <he...@free.fr> wrote:
> > 2. if we configured Checkstyle to report an error, this means check should
> > fail: if you find that it should not fail, please help improve Checkstyle
> > configuration by setting severity to warning only
>
> /me not a checkstyle expert configuration :-)
this makes me remember there is a feature improvement for m-checkstyle-p 2.13
that I should explain: I was not a Checkstyle configuration master and felt
like you
Than I consistently reported Checkstyle rule name and category in every
message and report, and a link to Checkstyle documentation for each rule [1]
this gives a good intro to Checkstyle configuration and help a lot when needing
to @SuppressWarnings( "checkstyle:name of rule, in lowercase")
> /me asking himself if having such hard checkstyle requirement help to
> improve user experience.
from my perspective, previous feature really improved m-checkstyle-p
experience
and I know I should submit patches to Checkstyle itself, because I think this
could help their users too when using bare-Checkstyle
Regards,
Hervé
[1] http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: errors reported by Checkstyle
Posted by Benson Margulies <bi...@gmail.com>.
Members of this PMC are not shy about demanding that code style
conform. I would rather fail a build because I forgot the stupid
spaces around the stupid parameters than have to scramble and fix
something when someone complains. Let's get checkstyle to enforce what
seems we enforce anyway, and then it's a convenience.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: errors reported by Checkstyle
Posted by Olivier Lamy <ol...@apache.org>.
On 14 October 2014 10:43, Stephen Connolly
<st...@gmail.com> wrote:
> On Monday, October 13, 2014, Olivier Lamy <ol...@apache.org> wrote:
>
>> On 14 October 2014 05:01, Hervé BOUTEMY <herve.boutemy@free.fr
>> <javascript:;>> wrote:
>> > Le lundi 13 octobre 2014 09:25:17 Olivier Lamy a écrit :
>> >> Hi,
>> >> You mean with the new setup the build will fail because of a checkstyle
>> >> issue?
>> > yes, it will fail because of an issue reported by Checkstyle, as we
>> configured
>> > its checking rules
>> >
>> >> I personally find really hard for a "style" problem. (i.e something
>> >> not related to a real technical problem).
>> > 1. not every Checkstyle rules are about "style" problem
>>
>> Well... As long as I don't have to write the final twice per single
>> line of code in order to transform the code to a non human readable, I
>> will be fine. :-)
>> I hope that won't be the case...
>>
>>
>> > 2. if we configured Checkstyle to report an error, this means check
>> should
>> > fail: if you find that it should not fail, please help improve Checkstyle
>> > configuration by setting severity to warning only
>>
>> /me not a checkstyle expert configuration :-)
>> /me asking himself if having such hard checkstyle requirement help to
>> improve user experience.
>>
>> Yes I know I'm French so I usually grumble for every changes happening :P
>
>
> Well we're hoping your new adoptive country's "culture" is rubbing some of
> that frenchness off ;-)
LOL
But Keep the root!!
I know checkstyle discussions are always a pain... And I don't want to
start this old holy war "Checkstyle Nazi" vs "coding hipster" :-)
Anyway I find hard to fail a build because of style issues. I'm
interested to know what Hervé called technical problems detected by
Checkstyle.
>
>
>>
>>
>> >
>> >
>> > I know that the first check will give a lot of work to fix long-standing
>> issues
>> > But once the big fix has been done, it's a question of doing the little
>> work to
>> > apply our required conventions on daily operations: nothing really hard
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> >>
>> >> On 11 October 2014 18:00, Hervé BOUTEMY <herve.boutemy@free.fr
>> <javascript:;>> wrote:
>> >> >> Log:
>> >> >> - Fixed several Checkstyle errors.
>> >> >
>> >> > notice that these are errors *reported by* Checkstyle, not really
>> >> > Checkstyle errors
>> >> >
>> >> > Checkstyle should add "don't shoot the messenger" disclaimer ;)
>> >> >
>> >> >
>> >> > I report here because next maven-parent version will enable Checkstyle
>> >> > check on every build: we must all know that we chose the rules that
>> >> > Checkstyle will report to us. If some rules are too strict, perhaps
>> we'll
>> >> > need to relax them, but be prepared to avoid blaming Checkstyle :)
>> >> >
>> >> >
>> >> > Notice I prepared some escape ways when checkstyle:check will be run
>> on
>> >> > each build, to limit frustration:
>> >> >
>> >> > 1. verify phase only, to let us concentrate on making code work before
>> >> > fixing broken coding conventions
>> >> >
>> >> > 2. @SuppressWarning support (MCHECKSTYLE-241) to ignore individual
>> rules
>> >> > directly into source code
>> >> >
>> >> > 3. CHECKSTYLE_OFF/ON support (MCHECKSTYLE-247) to ignore rules on
>> complete
>> >> > code fragments when necessary
>> >> >
>> >> > 4. fine grained global rule or even rule category (MCHECKSTYLE-242) to
>> >> > ignore rules or rule categories of a whole build with a single
>> property
>> >> > in pom.xml
>> >> >
>> >> >
>> >> > I hope everybody will enjoy maven-parent 25 like me...
>> >> >
>> >> > Regards,
>> >> >
>> >> > Hervé
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> <javascript:;>
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;>
>> >
>>
>>
>>
>> --
>> Olivier Lamy
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>>
>>
>
> --
> Sent from my phone
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: errors reported by Checkstyle
Posted by Stephen Connolly <st...@gmail.com>.
On Monday, October 13, 2014, Olivier Lamy <ol...@apache.org> wrote:
> On 14 October 2014 05:01, Hervé BOUTEMY <herve.boutemy@free.fr
> <javascript:;>> wrote:
> > Le lundi 13 octobre 2014 09:25:17 Olivier Lamy a écrit :
> >> Hi,
> >> You mean with the new setup the build will fail because of a checkstyle
> >> issue?
> > yes, it will fail because of an issue reported by Checkstyle, as we
> configured
> > its checking rules
> >
> >> I personally find really hard for a "style" problem. (i.e something
> >> not related to a real technical problem).
> > 1. not every Checkstyle rules are about "style" problem
>
> Well... As long as I don't have to write the final twice per single
> line of code in order to transform the code to a non human readable, I
> will be fine. :-)
> I hope that won't be the case...
>
>
> > 2. if we configured Checkstyle to report an error, this means check
> should
> > fail: if you find that it should not fail, please help improve Checkstyle
> > configuration by setting severity to warning only
>
> /me not a checkstyle expert configuration :-)
> /me asking himself if having such hard checkstyle requirement help to
> improve user experience.
>
> Yes I know I'm French so I usually grumble for every changes happening :P
Well we're hoping your new adoptive country's "culture" is rubbing some of
that frenchness off ;-)
>
>
> >
> >
> > I know that the first check will give a lot of work to fix long-standing
> issues
> > But once the big fix has been done, it's a question of doing the little
> work to
> > apply our required conventions on daily operations: nothing really hard
> >
> > Regards,
> >
> > Hervé
> >
> >>
> >> On 11 October 2014 18:00, Hervé BOUTEMY <herve.boutemy@free.fr
> <javascript:;>> wrote:
> >> >> Log:
> >> >> - Fixed several Checkstyle errors.
> >> >
> >> > notice that these are errors *reported by* Checkstyle, not really
> >> > Checkstyle errors
> >> >
> >> > Checkstyle should add "don't shoot the messenger" disclaimer ;)
> >> >
> >> >
> >> > I report here because next maven-parent version will enable Checkstyle
> >> > check on every build: we must all know that we chose the rules that
> >> > Checkstyle will report to us. If some rules are too strict, perhaps
> we'll
> >> > need to relax them, but be prepared to avoid blaming Checkstyle :)
> >> >
> >> >
> >> > Notice I prepared some escape ways when checkstyle:check will be run
> on
> >> > each build, to limit frustration:
> >> >
> >> > 1. verify phase only, to let us concentrate on making code work before
> >> > fixing broken coding conventions
> >> >
> >> > 2. @SuppressWarning support (MCHECKSTYLE-241) to ignore individual
> rules
> >> > directly into source code
> >> >
> >> > 3. CHECKSTYLE_OFF/ON support (MCHECKSTYLE-247) to ignore rules on
> complete
> >> > code fragments when necessary
> >> >
> >> > 4. fine grained global rule or even rule category (MCHECKSTYLE-242) to
> >> > ignore rules or rule categories of a whole build with a single
> property
> >> > in pom.xml
> >> >
> >> >
> >> > I hope everybody will enjoy maven-parent 25 like me...
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
>
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
--
Sent from my phone
Re: errors reported by Checkstyle
Posted by Olivier Lamy <ol...@apache.org>.
On 14 October 2014 05:01, Hervé BOUTEMY <he...@free.fr> wrote:
> Le lundi 13 octobre 2014 09:25:17 Olivier Lamy a écrit :
>> Hi,
>> You mean with the new setup the build will fail because of a checkstyle
>> issue?
> yes, it will fail because of an issue reported by Checkstyle, as we configured
> its checking rules
>
>> I personally find really hard for a "style" problem. (i.e something
>> not related to a real technical problem).
> 1. not every Checkstyle rules are about "style" problem
Well... As long as I don't have to write the final twice per single
line of code in order to transform the code to a non human readable, I
will be fine. :-)
I hope that won't be the case...
> 2. if we configured Checkstyle to report an error, this means check should
> fail: if you find that it should not fail, please help improve Checkstyle
> configuration by setting severity to warning only
/me not a checkstyle expert configuration :-)
/me asking himself if having such hard checkstyle requirement help to
improve user experience.
Yes I know I'm French so I usually grumble for every changes happening :P
>
>
> I know that the first check will give a lot of work to fix long-standing issues
> But once the big fix has been done, it's a question of doing the little work to
> apply our required conventions on daily operations: nothing really hard
>
> Regards,
>
> Hervé
>
>>
>> On 11 October 2014 18:00, Hervé BOUTEMY <he...@free.fr> wrote:
>> >> Log:
>> >> - Fixed several Checkstyle errors.
>> >
>> > notice that these are errors *reported by* Checkstyle, not really
>> > Checkstyle errors
>> >
>> > Checkstyle should add "don't shoot the messenger" disclaimer ;)
>> >
>> >
>> > I report here because next maven-parent version will enable Checkstyle
>> > check on every build: we must all know that we chose the rules that
>> > Checkstyle will report to us. If some rules are too strict, perhaps we'll
>> > need to relax them, but be prepared to avoid blaming Checkstyle :)
>> >
>> >
>> > Notice I prepared some escape ways when checkstyle:check will be run on
>> > each build, to limit frustration:
>> >
>> > 1. verify phase only, to let us concentrate on making code work before
>> > fixing broken coding conventions
>> >
>> > 2. @SuppressWarning support (MCHECKSTYLE-241) to ignore individual rules
>> > directly into source code
>> >
>> > 3. CHECKSTYLE_OFF/ON support (MCHECKSTYLE-247) to ignore rules on complete
>> > code fragments when necessary
>> >
>> > 4. fine grained global rule or even rule category (MCHECKSTYLE-242) to
>> > ignore rules or rule categories of a whole build with a single property
>> > in pom.xml
>> >
>> >
>> > I hope everybody will enjoy maven-parent 25 like me...
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: errors reported by Checkstyle
Posted by Hervé BOUTEMY <he...@free.fr>.
Le lundi 13 octobre 2014 09:25:17 Olivier Lamy a écrit :
> Hi,
> You mean with the new setup the build will fail because of a checkstyle
> issue?
yes, it will fail because of an issue reported by Checkstyle, as we configured
its checking rules
> I personally find really hard for a "style" problem. (i.e something
> not related to a real technical problem).
1. not every Checkstyle rules are about "style" problem
2. if we configured Checkstyle to report an error, this means check should
fail: if you find that it should not fail, please help improve Checkstyle
configuration by setting severity to warning only
I know that the first check will give a lot of work to fix long-standing issues
But once the big fix has been done, it's a question of doing the little work to
apply our required conventions on daily operations: nothing really hard
Regards,
Hervé
>
> On 11 October 2014 18:00, Hervé BOUTEMY <he...@free.fr> wrote:
> >> Log:
> >> - Fixed several Checkstyle errors.
> >
> > notice that these are errors *reported by* Checkstyle, not really
> > Checkstyle errors
> >
> > Checkstyle should add "don't shoot the messenger" disclaimer ;)
> >
> >
> > I report here because next maven-parent version will enable Checkstyle
> > check on every build: we must all know that we chose the rules that
> > Checkstyle will report to us. If some rules are too strict, perhaps we'll
> > need to relax them, but be prepared to avoid blaming Checkstyle :)
> >
> >
> > Notice I prepared some escape ways when checkstyle:check will be run on
> > each build, to limit frustration:
> >
> > 1. verify phase only, to let us concentrate on making code work before
> > fixing broken coding conventions
> >
> > 2. @SuppressWarning support (MCHECKSTYLE-241) to ignore individual rules
> > directly into source code
> >
> > 3. CHECKSTYLE_OFF/ON support (MCHECKSTYLE-247) to ignore rules on complete
> > code fragments when necessary
> >
> > 4. fine grained global rule or even rule category (MCHECKSTYLE-242) to
> > ignore rules or rule categories of a whole build with a single property
> > in pom.xml
> >
> >
> > I hope everybody will enjoy maven-parent 25 like me...
> >
> > Regards,
> >
> > Hervé
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: errors reported by Checkstyle
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
You mean with the new setup the build will fail because of a checkstyle issue?
I personally find really hard for a "style" problem. (i.e something
not related to a real technical problem).
On 11 October 2014 18:00, Hervé BOUTEMY <he...@free.fr> wrote:
>> Log:
>> - Fixed several Checkstyle errors.
>>
> notice that these are errors *reported by* Checkstyle, not really Checkstyle
> errors
>
> Checkstyle should add "don't shoot the messenger" disclaimer ;)
>
>
> I report here because next maven-parent version will enable Checkstyle check
> on every build: we must all know that we chose the rules that Checkstyle will
> report to us. If some rules are too strict, perhaps we'll need to relax them,
> but be prepared to avoid blaming Checkstyle :)
>
>
> Notice I prepared some escape ways when checkstyle:check will be run on each
> build, to limit frustration:
>
> 1. verify phase only, to let us concentrate on making code work before fixing
> broken coding conventions
>
> 2. @SuppressWarning support (MCHECKSTYLE-241) to ignore individual rules
> directly into source code
>
> 3. CHECKSTYLE_OFF/ON support (MCHECKSTYLE-247) to ignore rules on complete
> code fragments when necessary
>
> 4. fine grained global rule or even rule category (MCHECKSTYLE-242) to ignore
> rules or rule categories of a whole build with a single property in pom.xml
>
>
> I hope everybody will enjoy maven-parent 25 like me...
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
errors reported by Checkstyle
Posted by Hervé BOUTEMY <he...@free.fr>.
> Log:
> - Fixed several Checkstyle errors.
>
notice that these are errors *reported by* Checkstyle, not really Checkstyle
errors
Checkstyle should add "don't shoot the messenger" disclaimer ;)
I report here because next maven-parent version will enable Checkstyle check
on every build: we must all know that we chose the rules that Checkstyle will
report to us. If some rules are too strict, perhaps we'll need to relax them,
but be prepared to avoid blaming Checkstyle :)
Notice I prepared some escape ways when checkstyle:check will be run on each
build, to limit frustration:
1. verify phase only, to let us concentrate on making code work before fixing
broken coding conventions
2. @SuppressWarning support (MCHECKSTYLE-241) to ignore individual rules
directly into source code
3. CHECKSTYLE_OFF/ON support (MCHECKSTYLE-247) to ignore rules on complete
code fragments when necessary
4. fine grained global rule or even rule category (MCHECKSTYLE-242) to ignore
rules or rule categories of a whole build with a single property in pom.xml
I hope everybody will enjoy maven-parent 25 like me...
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org