[jira] (DOXIASITETOOLS-85) move RenderingContext from o.a.m.doxia.sink.render package to o.a.m.doxia.siterenderer
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIASITETOOLS-85. --- Resolution: Fixed Fix Version/s: 1.5 Assignee: Herve Boutemy done in [r1535929|http://svn.apache.org/r1535929] > move RenderingContext from o.a.m.doxia.sink.render package to > o.a.m.doxia.siterenderer > -- > > Key: DOXIASITETOOLS-85 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-85 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Critical > Fix For: 1.5 > > > next step after moving from Doxia Core DOXIASITETOOLS-84 > Notice that this change will require code change in code using Doxia > Sitetools, like maven-site-plugin, since this breaks compatibility -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIASITETOOLS-85) move RenderingContext from o.a.m.doxia.sink.render package to o.a.m.doxia.siterenderer
Herve Boutemy created DOXIASITETOOLS-85: --- Summary: move RenderingContext from o.a.m.doxia.sink.render package to o.a.m.doxia.siterenderer Key: DOXIASITETOOLS-85 URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-85 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site renderer Affects Versions: 1.5 Reporter: Herve Boutemy Priority: Critical next step after moving from Doxia Core DOXIASITETOOLS-84 Notice that this change will require code change in code using Doxia Sitetools, like maven-site-plugin, since this breaks compatibility -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-121) Enforcer Plugin Output As Report
[
https://jira.codehaus.org/browse/MENFORCER-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334685#comment-334685
]
Lars Gohlke commented on MENFORCER-121:
---
I implemented this as optional for DependencyConvergence and offer a patch for
this here
against r1535845
{code}
Index:
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
---
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java
(revision 1535845)
+++
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java
(revision )
@@ -24,6 +24,7 @@
import java.util.List;
import org.apache.maven.artifact.Artifact;
+import org.apache.maven.artifact.DefaultArtifact;
import org.apache.maven.artifact.factory.ArtifactFactory;
import org.apache.maven.artifact.metadata.ArtifactMetadataSource;
import org.apache.maven.artifact.repository.ArtifactRepository;
@@ -41,7 +42,11 @@
import
org.codehaus.plexus.component.configurator.expression.ExpressionEvaluationException;
import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
import org.codehaus.plexus.i18n.I18N;
+import org.codehaus.plexus.util.FileUtils;
+import java.io.File;
+import java.io.IOException;
+import com.thoughtworks.xstream.XStream;
/**
* @author mailto:r...@e-hoffman.org";>Rex Hoffman
*/
@@ -52,20 +57,26 @@
private static Log log;
private static I18N i18n;
-
-private boolean uniqueVersions;
+
+private boolean uniqueVersions;
public void setUniqueVersions( boolean uniqueVersions )
{
this.uniqueVersions = uniqueVersions;
}
-
+
+private File xmlReport;
+
+public void setXmlReport(File xmlReport) {
+ this.xmlReport = xmlReport;
+}
+
/**
* Uses the {@link EnforcerRuleHelper} to populate the values of the
* {@link DependencyTreeBuilder#buildDependencyTree(MavenProject,
ArtifactRepository, ArtifactFactory, ArtifactMetadataSource, ArtifactFilter,
ArtifactCollector)}
* factory method.
* This method simply exists to hide all the ugly lookup that the {@link
EnforcerRuleHelper} has to do.
- *
+ *
* @param helper
* @return a Dependency Node which is the root of the project's dependency
tree
* @throws EnforcerRuleException
@@ -121,7 +132,11 @@
visitor.setUniqueVersions( uniqueVersions );
node.accept( visitor );
List errorMsgs = new ArrayList();
-errorMsgs.addAll( getConvergenceErrorMsgs(
visitor.getConflictedVersionNumbers() ) );
+
+List> conflictedVersionNumbers =
visitor.getConflictedVersionNumbers();
+errorMsgs.addAll(
getConvergenceErrorMsgs(conflictedVersionNumbers) );
+writeConflictedVersionNumbers(conflictedVersionNumbers);
+
for ( CharSequence errorMsg : errorMsgs )
{
log.warn( errorMsg );
@@ -138,6 +153,24 @@
catch ( Exception e )
{
throw new EnforcerRuleException( e.getLocalizedMessage(), e );
+}
+}
+
+ private void writeConflictedVersionNumbers(List>
conflictedVersionNumbers) {
+if ( null != xmlReport ){
+ XStream xStream = new XStream();
+ xStream.omitField(DefaultArtifact.class,"artifactHandler");
+ xStream.omitField(DefaultArtifact.class,"versionRange");
+ xStream.omitField(DependencyNode.class,"parent");
+ xStream.omitField(DependencyNode.class,"state");
+
+ xStream.alias("dependency",DependencyNode.class);
+
+ try {
+
FileUtils.fileWrite(xmlReport.getAbsolutePath(),xStream.toXML(conflictedVersionNumbers));
+ } catch (IOException e) {
+throw new IllegalStateException(e);
+ }
}
}
@@ -222,7 +255,7 @@
* allow double checking of the results. Most of the time this can be done
by generating unique ids, but sometimes
* the results of objects returned by the helper need to be queried. You
may for example, store certain objects in
* your rule and then query them later.
- *
+ *
* @param rule
*/
public boolean isResultValid( EnforcerRule rule )
\ No newline at end of file
Index: enforcer-rules/pom.xml
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- enforcer-rules/pom.xml (revision 1535845)
+++ enforcer-rules/pom.xml (revision )
@@ -15,7 +15,7 @@
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and li
[jira] (MJAVADOC-308) OutOfMemoryError
[ https://jira.codehaus.org/browse/MJAVADOC-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334646#comment-334646 ] Jörg Hohwiller edited comment on MJAVADOC-308 at 10/25/13 1:37 PM: --- I spend more time on the analysis and think I traced it down now. 1. The problem does not occur with any heap size. If I use a 64 bit JVM and provide 5GB of heap, the javadoc works. See the attached screenshot. 2. As I already wrote before the problem occurs when generating the overview-tree.html. The implementation of this report in javadoc seems to be very memory exhaustive (in java 1.7). IMHO the developers did not consider that one may make intensive use of multi-inheritance via interfaces. My resulting overview-tree.html is 241 megabytes big. My firefox is almost dying when I open this file and scroll it. I never noticed this feature and do not need it. So even though this is some sort of bug or problem in javadoc 1.7 I can switch it off as a workaround: http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/javadoc.html#notree http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#notree 3. If you omit the maximum heap size java 1.7 grows the heap more dynamically if OS memory is available than java did in earlier versions. Therefore the javadoc generation on a single module succeeded without max heap and failed with -Xmx1024m. Sorry for spamming. This bug is absolutely not related to the maven-javadoc-plugin. was (Author: hohwille): I spend more time on the analysis and think I traced it down now. 1. The problem does not occur with any heap size. If I use a 64 bit JVM and provide 5GB of heap, the javadoc works. See the attached screenshot. 2. As I already wrote before the problem occurs when generating the overview-tree.html. I found out that this is a new feature of JavaDoc introduced with java 1.7. That is why there are no problems with earlier java versions. The implementation of this report in javadoc seems to be very memory exhaustive. IMHO the developers did not consider that one may make intensive use of multi-inheritance via interfaces. My resulting overview-tree.html is 241 megabytes big. My firefox is almost dying when I open this file and scroll it. I never noticed this feature and do not need it. Maybe there is an option to disable it and all my problems are resolved. 3. If you omit the maximum heap size java 1.7 grows the heap more dynamically if OS memory is available than java did in earlier versions. Therefore the javadoc generation on a single module succeeded without max heap and failed with -Xmx1024m. > OutOfMemoryError > > > Key: MJAVADOC-308 > URL: https://jira.codehaus.org/browse/MJAVADOC-308 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6.1, 2.7 > Environment: Maven 3 on MacOS 10.6, Maven 3 on Hudson on Windows >Reporter: Pieter > Attachments: java7-javadoc-memorybug-5GB.png, > java7-javadoc-memorybug-monitor.png, java7-javadoc-memorybug.png > > > I have a 12 module project (+parent) containing not really much code (140 > classes). When running Maven site on this project, it fails with an > OutOfMemoryError. When I run the javadoc plugin with a reportset containing > javadoc, test-javadoc and aggregate is runs well with a maximum heap size of > 512M. When I run it with a reportset containing javadoc, test-javadoc and > test-aggregate also. But when I add all 4 reports to my report set, I get an > OutOfMemoryError, even when setting the maximum heap size to 1.5G. Just > before the error occurs I see my heap usage growing rapidly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-405) Preemptive authentication still not working with Maven 3.0.4+
[ https://jira.codehaus.org/browse/WAGON-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334666#comment-334666 ] Konrad Windszus commented on WAGON-405: --- Even with the new pull request merged (https://github.com/apache/maven-wagon/pull/6) by default there is no preemptive authentication being used. > Preemptive authentication still not working with Maven 3.0.4+ > - > > Key: WAGON-405 > URL: https://jira.codehaus.org/browse/WAGON-405 > Project: Maven Wagon > Issue Type: Bug >Reporter: Konrad Windszus > Attachments: WAGON-405-MVN3.1.1.log > > > Although by default the preemptive authentication should work now with Maven > 3.0.4, a wireshare dump exposes, that each request for downloading a new > dependency does not initially come with the authentication header. Only after > Nexus replied with a 401 the right credentials are set in the authentication > header. According to [1], since Maven 3.0.4 the default HTTP wagon uses > preemptive authentication which cannot be disabled [2]. Even with Maven 3.1.1 > it does not work. > [1] - http://maven.apache.org/guides/mini/guide-http-settings.html#Maven_3.0.4 > [2] - > http://maven.40175.n5.nabble.com/Maven-3-0-4-preemptive-auth-problem-tt5470892.html#none -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-88) Add a generic search form
[ https://jira.codehaus.org/browse/MSKINS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] barnaby relph updated MSKINS-88: Description: For fluido-based sites with an in-house search engine, I'd like to be able to specify a search element (like the existing google search element) but to supply the action URL and field name, so that I can point the search at an in-house server. This seems to be the same requirement as this SO question too: http://stackoverflow.com/questions/14373950/maven-site-search-capabilities Happy to know if there's another way of achieving this. Would something like this work: ## #macro ( customSearch $top ) #set( $customsearchURL = $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' ).getChild( 'customsearchURL' ).getValue() ) #if ( $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' ).getChild( 'customsearchParamName' ) ) #set( $customsearchParamName = $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' ).getChild( 'customsearchParamName' ).getValue() ) #else #set( $customsearchParamName = "q" ) #end #end was: for fluido-based sites with an in-house search engine, I'd like to be able to specify a search element (like the existing google search element) but to supply the action URL and field name, so that I can point the search at an in-house server. This seems to be the same requirement as this SO question too: http://stackoverflow.com/questions/14373950/maven-site-search-capabilities Happy to know if there's another way of achieving this. Would something like this work: ## #macro ( customSearch $top ) #set( $customsearchURL = $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' ).getChild( 'customsearchURL' ).getValue() ) #if ( $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' ).getChild( 'customsearchParamName' ) ) #set( $customsearchParamName = $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' ).getChild( 'customsearchParamName' ).getValue() ) #else #set( $customsearchParamName = "q" ) #end #end > Add a generic search form > - > > Key: MSKINS-88 > URL: https://jira.codehaus.org/browse/MSKINS-88 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.3.0 > Environment: ALL >Reporter: barnaby relph >Priority: Minor > > For fluido-based sites with an in-house search engine, I'd like to be able to > specify a search element (like the existing google search element) but to > supply the action URL and field name, so that I can point the search at an > in-house server. > This seems to be the same requirement as this SO question too: > http://stackoverflow.com/questions/14373950/maven-site-search-capabilities > Happy to know if there's another way of achieving this. > Would something like this work: > ## > #macro ( customSearch $top ) > #set( $customsearchURL = $decoration.custom.getChild( 'fluidoSkin' > ).getChild( 'customSearch' ).getChild( 'customsearchURL' ).getValue() ) > #if ( $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' > ).getChild( 'customsearchParamName' ) ) > #set( $customsearchParamName = $decoration.custom.getChild( 'fluidoSkin' > ).getChild( 'customSearch' ).getChild( 'customsearchParamName' ).getValue() ) > #else > #set( $customsearchParamName = "q" ) > #end > class="navbar-search pull-right" #end> >type="text" /> > > #end -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-88) Add a generic search form
barnaby relph created MSKINS-88: --- Summary: Add a generic search form Key: MSKINS-88 URL: https://jira.codehaus.org/browse/MSKINS-88 Project: Maven Skins Issue Type: New Feature Components: Fluido Skin Affects Versions: fluido-1.3.0 Environment: ALL Reporter: barnaby relph Priority: Minor for fluido-based sites with an in-house search engine, I'd like to be able to specify a search element (like the existing google search element) but to supply the action URL and field name, so that I can point the search at an in-house server. This seems to be the same requirement as this SO question too: http://stackoverflow.com/questions/14373950/maven-site-search-capabilities Happy to know if there's another way of achieving this. Would something like this work: ## #macro ( customSearch $top ) #set( $customsearchURL = $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' ).getChild( 'customsearchURL' ).getValue() ) #if ( $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' ).getChild( 'customsearchParamName' ) ) #set( $customsearchParamName = $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' ).getChild( 'customsearchParamName' ).getValue() ) #else #set( $customsearchParamName = "q" ) #end #end -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334663#comment-334663 ] Catalin Patruica commented on MRELEASE-812: --- I had the same problems but after some hours of search i was finding a sollution that was working for me: just add the dependencies of the maven-release-plugin org.apache.maven.scm maven-scm-api 1.8.1 org.apache.maven.scm maven-scm-provider-gitexe 1.8.1 for testing I have created a test project on github https://github.com/duderoot/maven.release.plugin and also make a more detailed description under http://xlab-iq.blogspot.de/2013/10/maven-release-plugin.html I hope it helps. cheers, cp > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.4 >Reporter: Andrei Pozolotin >Priority: Critical > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
