Anyone know why Doxia treats H1 as an unknown event and H2 as section_level_1?
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/XhtmlBaseParser.java?view=markup#l413 Seems strange to me... but perhaps there is a good reason...
Re: [ANN] Maven Jarsigner 1.1 Released
On Tue, 12 Nov 2013 23:59:06 +0100 Tony Chemit che...@codelutin.com wrote: The Maven team is pleased to announce the release of the Maven JArsigner, version 1.1 This component provides some utilities to sign/verify jars/files in your Mojos. http://maven.apache.org/shared/maven-jarsigner/ To use the Maven Jarsigner, add the following dependency to your project: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-jarsinger/artifactId version1.1/version /dependency The dependency is *maven-jarsigner* and not *maven-jarsinger*, dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-jarsigner/artifactId version1.1/version /dependency tony. -- Tony Chemit tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: che...@codelutin.com twitter: https://twitter.com/tchemit - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone know why Doxia treats H1 as an unknown event and H2 as section_level_1?
Hi Stephen, The Sink API only knows 5 section levels, which in html are mapped to h2 - h6: http://jira.codehaus.org/browse/DOXIA-203 HTH, -Lukas Am 13.11.2013 10:13, schrieb Stephen Connolly: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/XhtmlBaseParser.java?view=markup#l413 Seems strange to me... but perhaps there is a good reason... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Anyone object to a Doxia 1.5 release being cut?
I'd really like to get the DOXIA-472 support out so that we can actually use markdown for documentation that has the title set... If anyone has anything they feel really needs to be added... shout out... likely I'll pull the trigger in a couple of hours anyway... but as most of the doxia committers are EU I will wait a while -Stephen
Re: Anyone know why Doxia treats H1 as an unknown event and H2 as section_level_1?
On 13 November 2013 19:56, Lukas Theussl ltheu...@gmail.com wrote: Hi Stephen, The Sink API only knows 5 section levels, which in html are mapped to h2 - h6: http://jira.codehaus.org/browse/DOXIA-203 Probably from a typography point of view H1 is junk (http://practicaltypography.com/point-size.html) and everyone just jumps to H2 instead. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone know why Doxia treats H1 as an unknown event and H2 as section_level_1?
No I think that it is that Doxia is kind of expecting that you only have one H1 in your document and that is for the title... of course it doesn't actually use it for the title The H1 gets generated by the output sinks... but it just does not get the hyperlinking targets set... On 13 November 2013 09:54, Barrie Treloar baerr...@gmail.com wrote: On 13 November 2013 19:56, Lukas Theussl ltheu...@gmail.com wrote: Hi Stephen, The Sink API only knows 5 section levels, which in html are mapped to h2 - h6: http://jira.codehaus.org/browse/DOXIA-203 Probably from a typography point of view H1 is junk (http://practicaltypography.com/point-size.html) and everyone just jumps to H2 instead. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-wagon pull request: Code cleanup
GitHub user ebourg opened a pull request: https://github.com/apache/maven-wagon/pull/8 Code cleanup Here is a patch performing minor code improvements (foreach loops, generics, unused imports, StringBuilders, etc) You can merge this pull request into a Git repository by running: $ git pull https://github.com/ebourg/maven-wagon master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-wagon/pull/8.patch commit c39331881355cbced56ff3fb7e1fdb8c4fbe7f93 Author: Emmanuel Bourg ebo...@apache.org Date: 2013-11-13T09:25:05Z Replaced StringBuffers with StringBuilders commit 6e09858022e3dee0e5aea994a33f2dd89e287661 Author: Emmanuel Bourg ebo...@apache.org Date: 2013-11-13T10:54:21Z Removed unused import statements commit e4db9c20a379befe2fe1d2151852155368a3df89 Author: Emmanuel Bourg ebo...@apache.org Date: 2013-11-13T11:09:06Z Use String.contains() instead of indexOf() when possible commit ddfeecfd34d1ca9363820b3998b4c60b72d0ac8d Author: Emmanuel Bourg ebo...@apache.org Date: 2013-11-13T12:00:26Z Foreach loops commit 0d6d1f3ad432a0a257e0bc7404ac31dbe0ae7810 Author: Emmanuel Bourg ebo...@apache.org Date: 2013-11-13T12:06:55Z Minor code simplifications - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-plugin-testing pull request: Upgrade the dependency on Easymock to 3....
GitHub user ebourg opened a pull request: https://github.com/apache/maven-plugin-testing/pull/2 Upgrade the dependency on Easymock to 3.2 The `MockControl` class used by `MockManager` in the maven-test-tools artifact has been removed from EasyMock starting with version 3.0. This patch updates `MockManager` to use the equivalent class in the latest versions of EasyMock. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ebourg/maven-plugin-testing trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-plugin-testing/pull/2.patch commit 10a2e423de1169c912416fe3e6a767e501630f65 Author: Emmanuel Bourg ebo...@apache.org Date: 2013-11-13T12:39:00Z Upgrade the dependency on Easymock to 3.2 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone object to a Doxia 1.5 release being cut?
OK, I'm fed up waiting *Gold Leader:* Red Leader, This is Gold Leader. We're starting our attack run. On 13 November 2013 09:47, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I'd really like to get the DOXIA-472 support out so that we can actually use markdown for documentation that has the title set... If anyone has anything they feel really needs to be added... shout out... likely I'll pull the trigger in a couple of hours anyway... but as most of the doxia committers are EU I will wait a while -Stephen
Defective Nov 5 upload to Maven central of Eclipse artifacts broke our build
Hi, First, apologies if this is not the right mailing list for Maven Central issues... On Nov 5, someone uploaded to Maven Central some new versions of Eclipse artifacts. In particular, they uploaded: org.eclipse.core : runtime : 3.9.0-v20130326-1255 and org.eclipse.equinox: app : 1.3.100-v20130327-1442 The POM for this runtime artifact has this (faulty) dependency on the app artifact: |dependency||| | groupId||org.eclipse.equinox http://search.maven.org/#/||groupId||| | artifactId||app http://search.maven.org/#/||artifactId||| | version||1.0.0/||version||| | optional||false/||optional||| |||/||dependency||| Specifying the dependency as 1.0.0 causes Maven 3.0.x to fail to locate this artifact. See https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning This has broken our previous source release's ability to build from source. We'll fix this going forward, for our build, but For reference, prior to this change, the previous org.eclipse.core:runtime had this dependency specified with a range notation, as: |dependency||| | groupId||org.eclipse.equinox http://search.maven.org/#/||groupId||| | artifactId||app http://search.maven.org/#/||artifactId||| | version||[1.0.0,2.0.0)/||version||| |||/||dependency||| This has broken our previous source releases' ability to build from source. We'll fix this for our builds, going forward, but it would be nice if the maven central administrators would contact the uploader and have them correct this dependency specification (as well as other errors that might have crept in), so our previously releases could continue to build. -Marshall Schor
Re: Defective Nov 5 upload to Maven central of Eclipse artifacts broke our build
I had a similar issue but I solved it by removing some JBoss repositories Are you sure that the problem is in central ? On Wed, Nov 13, 2013 at 3:57 PM, Marshall Schor m...@schor.com wrote: Hi, First, apologies if this is not the right mailing list for Maven Central issues... On Nov 5, someone uploaded to Maven Central some new versions of Eclipse artifacts. In particular, they uploaded: org.eclipse.core : runtime : 3.9.0-v20130326-1255 and org.eclipse.equinox: app : 1.3.100-v20130327-1442 The POM for this runtime artifact has this (faulty) dependency on the app artifact: |dependency||| | groupId||org.eclipse.equinox http://search.maven.org/# /||groupId||| | artifactId||app http://search.maven.org/#/||artifactId||| | version||1.0.0/||version||| | optional||false/||optional||| |||/||dependency||| Specifying the dependency as 1.0.0 causes Maven 3.0.x to fail to locate this artifact. See https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning This has broken our previous source release's ability to build from source. We'll fix this going forward, for our build, but For reference, prior to this change, the previous org.eclipse.core:runtime had this dependency specified with a range notation, as: |dependency||| | groupId||org.eclipse.equinox http://search.maven.org/# /||groupId||| | artifactId||app http://search.maven.org/#/||artifactId||| | version||[1.0.0,2.0.0)/||version||| |||/||dependency||| This has broken our previous source releases' ability to build from source. We'll fix this for our builds, going forward, but it would be nice if the maven central administrators would contact the uploader and have them correct this dependency specification (as well as other errors that might have crept in), so our previously releases could continue to build. -Marshall Schor -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: svn commit: r1402867 - /maven/pom/trunk/maven/pom.xml
On 27 October 2012 22:00, bimargul...@apache.org wrote:
Author: bimargulies
Date: Sat Oct 27 21:00:24 2012
New Revision: 1402867
URL: http://svn.apache.org/viewvc?rev=1402867view=rev
Log:
MPOM-38: Enable RAT to help us get maven releases to be license-header
compliant
o Also configure the release plugin to turn on rat (quietly)
Modified:
maven/pom/trunk/maven/pom.xml
Modified: maven/pom/trunk/maven/pom.xml
URL:
http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1402867r1=1402866r2=1402867view=diff
==
--- maven/pom/trunk/maven/pom.xml (original)
+++ maven/pom/trunk/maven/pom.xml Sat Oct 27 21:00:24 2012
@@ -806,12 +806,43 @@ under the License.
artifactIdfindbugs-maven-plugin/artifactId
version2.5.2/version
/plugin
+plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-release-plugin/artifactId
+ version2.3.2/version
+ configuration
+useReleaseProfiletrue/useReleaseProfile
+releaseProfilesapache-release,rat/releaseProfiles
+goalsdeploy/goals
+arguments${arguments}/arguments
FYI This just blew up in my face with Doxia 1.5. I had to resort to
re-running release:perform with -DconnectupUrl=...
-Darguments=-P+apache-release,rat to get the release to stage correctly
with GPG signature etc...
+ /configuration
+/plugin
/plugins
/pluginManagement
/build
profiles
profile
+ idrat/id
+ build
+plugins
+ plugin
+groupIdorg.apache.rat/groupId
+artifactIdapache-rat-plugin/artifactId
+executions
+ execution
+phaseverify/phase
+goals
+ !-- rat, not check, because we've got lots of
noncomplaint stuff --
+ goalrat/goal
+/goals
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+profile
idquality-checks/id
activation
property
Re: svn commit: r1402867 - /maven/pom/trunk/maven/pom.xml
On Wed, Nov 13, 2013 at 10:54 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 27 October 2012 22:00, bimargul...@apache.org wrote:
Author: bimargulies
Date: Sat Oct 27 21:00:24 2012
New Revision: 1402867
URL: http://svn.apache.org/viewvc?rev=1402867view=rev
Log:
MPOM-38: Enable RAT to help us get maven releases to be license-header
compliant
o Also configure the release plugin to turn on rat (quietly)
Modified:
maven/pom/trunk/maven/pom.xml
Modified: maven/pom/trunk/maven/pom.xml
URL:
http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1402867r1=1402866r2=1402867view=diff
==
--- maven/pom/trunk/maven/pom.xml (original)
+++ maven/pom/trunk/maven/pom.xml Sat Oct 27 21:00:24 2012
@@ -806,12 +806,43 @@ under the License.
artifactIdfindbugs-maven-plugin/artifactId
version2.5.2/version
/plugin
+plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-release-plugin/artifactId
+ version2.3.2/version
+ configuration
+useReleaseProfiletrue/useReleaseProfile
+releaseProfilesapache-release,rat/releaseProfiles
+goalsdeploy/goals
+arguments${arguments}/arguments
FYI This just blew up in my face with Doxia 1.5. I had to resort to
re-running release:perform with -DconnectupUrl=...
-Darguments=-P+apache-release,rat to get the release to stage correctly
with GPG signature etc...
What's special about doxia, or, alternatively, what's wrong here?
+ /configuration
+/plugin
/plugins
/pluginManagement
/build
profiles
profile
+ idrat/id
+ build
+plugins
+ plugin
+groupIdorg.apache.rat/groupId
+artifactIdapache-rat-plugin/artifactId
+executions
+ execution
+phaseverify/phase
+goals
+ !-- rat, not check, because we've got lots of
noncomplaint stuff --
+ goalrat/goal
+/goals
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+profile
idquality-checks/id
activation
property
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Defective Nov 5 upload to Maven central of Eclipse artifacts broke our build
On 11/13/2013 10:21 AM, Arnaud Héritier wrote: I had a similar issue but I solved it by removing some JBoss repositories Are you sure that the problem is in central ? Not sure. It's found by this website: http://search.maven.org/remotecontent?filepath=org/eclipse/core/runtime/3.9.0-v20130326-1255/runtime-3.9.0-v20130326-1255.pom and I see it's located here: http://central.maven.org/maven2/org/eclipse/core/runtime/3.9.0-v20130326-1255/ which seems to be the central maven repository? -Marshall On Wed, Nov 13, 2013 at 3:57 PM, Marshall Schor m...@schor.com wrote: Hi, First, apologies if this is not the right mailing list for Maven Central issues... On Nov 5, someone uploaded to Maven Central some new versions of Eclipse artifacts. In particular, they uploaded: org.eclipse.core : runtime : 3.9.0-v20130326-1255 and org.eclipse.equinox: app : 1.3.100-v20130327-1442 The POM for this runtime artifact has this (faulty) dependency on the app artifact: |dependency||| | groupId||org.eclipse.equinox http://search.maven.org/# /||groupId||| | artifactId||app http://search.maven.org/#/||artifactId||| | version||1.0.0/||version||| | optional||false/||optional||| |||/||dependency||| Specifying the dependency as 1.0.0 causes Maven 3.0.x to fail to locate this artifact. See https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning This has broken our previous source release's ability to build from source. We'll fix this going forward, for our build, but For reference, prior to this change, the previous org.eclipse.core:runtime had this dependency specified with a range notation, as: |dependency||| | groupId||org.eclipse.equinox http://search.maven.org/# /||groupId||| | artifactId||app http://search.maven.org/#/||artifactId||| | version||[1.0.0,2.0.0)/||version||| |||/||dependency||| This has broken our previous source releases' ability to build from source. We'll fix this for our builds, going forward, but it would be nice if the maven central administrators would contact the uploader and have them correct this dependency specification (as well as other errors that might have crept in), so our previously releases could continue to build. -Marshall Schor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Can somebody (Hervé?) stage the Doxia 1.5 site
WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended. [INFO] Downloading from JIRA at: http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rsspid=10780statusIds=6resolutionIds=1sorter/field=issuekeysorter/order=ASCtempMax=1000reset=truedecorator=none [WARNING] org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML. at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132) at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108) at org.apache.maven.plugin.jira.AbstractJiraDownloader.getIssueList(AbstractJiraDownloader.java:753) at org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:347) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.xml.sax.SAXParseException; lineNumber: 117; columnNumber: 3; The element type meta must be terminated by the matching end-tag /meta. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source) at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:128) ... 30 more [INFO] [INFO] --- maven-site-plugin:3.2:deploy (default-deploy) @ doxia --- [INFO] Parent project loaded from repository: org.apache.maven:maven-parent:pom:23 [INFO] Parent project loaded from repository: org.apache:apache:pom:13 [ERROR] Unsupported protocol: 'scm' for site deployment to distributionManagement.site.url=scm:svn: https://svn.apache.org/repos/infra/websites/production/maven/content/. Currently supported protocols are: http, file, https. Protocols may be added through wagon providers. For more information, see http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-protocol.html [INFO]
Re: svn commit: r1402867 - /maven/pom/trunk/maven/pom.xml
The profiles are not being activated... this is why in the asf pom we use
the -P... in the arguments tag
On 13 November 2013 16:01, Benson Margulies bimargul...@gmail.com wrote:
On Wed, Nov 13, 2013 at 10:54 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 27 October 2012 22:00, bimargul...@apache.org wrote:
Author: bimargulies
Date: Sat Oct 27 21:00:24 2012
New Revision: 1402867
URL: http://svn.apache.org/viewvc?rev=1402867view=rev
Log:
MPOM-38: Enable RAT to help us get maven releases to be license-header
compliant
o Also configure the release plugin to turn on rat (quietly)
Modified:
maven/pom/trunk/maven/pom.xml
Modified: maven/pom/trunk/maven/pom.xml
URL:
http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1402867r1=1402866r2=1402867view=diff
==
--- maven/pom/trunk/maven/pom.xml (original)
+++ maven/pom/trunk/maven/pom.xml Sat Oct 27 21:00:24 2012
@@ -806,12 +806,43 @@ under the License.
artifactIdfindbugs-maven-plugin/artifactId
version2.5.2/version
/plugin
+plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-release-plugin/artifactId
+ version2.3.2/version
+ configuration
+useReleaseProfiletrue/useReleaseProfile
+releaseProfilesapache-release,rat/releaseProfiles
+goalsdeploy/goals
+arguments${arguments}/arguments
FYI This just blew up in my face with Doxia 1.5. I had to resort to
re-running release:perform with -DconnectupUrl=...
-Darguments=-P+apache-release,rat to get the release to stage correctly
with GPG signature etc...
What's special about doxia, or, alternatively, what's wrong here?
+ /configuration
+/plugin
/plugins
/pluginManagement
/build
profiles
profile
+ idrat/id
+ build
+plugins
+ plugin
+groupIdorg.apache.rat/groupId
+artifactIdapache-rat-plugin/artifactId
+executions
+ execution
+phaseverify/phase
+goals
+ !-- rat, not check, because we've got lots of
noncomplaint stuff --
+ goalrat/goal
+/goals
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+profile
idquality-checks/id
activation
property
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1402867 - /maven/pom/trunk/maven/pom.xml
On Wed, Nov 13, 2013 at 11:33 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
The profiles are not being activated... this is why in the asf pom we use
the -P... in the arguments tag
Why aren't the profiles activated? Does 'arguments' disable 'releaseProfiles'?
On 13 November 2013 16:01, Benson Margulies bimargul...@gmail.com wrote:
On Wed, Nov 13, 2013 at 10:54 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 27 October 2012 22:00, bimargul...@apache.org wrote:
Author: bimargulies
Date: Sat Oct 27 21:00:24 2012
New Revision: 1402867
URL: http://svn.apache.org/viewvc?rev=1402867view=rev
Log:
MPOM-38: Enable RAT to help us get maven releases to be license-header
compliant
o Also configure the release plugin to turn on rat (quietly)
Modified:
maven/pom/trunk/maven/pom.xml
Modified: maven/pom/trunk/maven/pom.xml
URL:
http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1402867r1=1402866r2=1402867view=diff
==
--- maven/pom/trunk/maven/pom.xml (original)
+++ maven/pom/trunk/maven/pom.xml Sat Oct 27 21:00:24 2012
@@ -806,12 +806,43 @@ under the License.
artifactIdfindbugs-maven-plugin/artifactId
version2.5.2/version
/plugin
+plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-release-plugin/artifactId
+ version2.3.2/version
+ configuration
+useReleaseProfiletrue/useReleaseProfile
+releaseProfilesapache-release,rat/releaseProfiles
+goalsdeploy/goals
+arguments${arguments}/arguments
FYI This just blew up in my face with Doxia 1.5. I had to resort to
re-running release:perform with -DconnectupUrl=...
-Darguments=-P+apache-release,rat to get the release to stage correctly
with GPG signature etc...
What's special about doxia, or, alternatively, what's wrong here?
+ /configuration
+/plugin
/plugins
/pluginManagement
/build
profiles
profile
+ idrat/id
+ build
+plugins
+ plugin
+groupIdorg.apache.rat/groupId
+artifactIdapache-rat-plugin/artifactId
+executions
+ execution
+phaseverify/phase
+goals
+ !-- rat, not check, because we've got lots of
noncomplaint stuff --
+ goalrat/goal
+/goals
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+profile
idquality-checks/id
activation
property
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1402867 - /maven/pom/trunk/maven/pom.xml
Hi,
I can confirm that I'm having the same issues as Stephen when releasing
but didn't took the time to figure out the cause: I knew the workaround
and thought it had to do with my settings.xml.
The issue of the m-release-p for not picking up the profile was fixed in
MRELEASE-459 [1], together with a lot of other profile related issues.
However, we're still struggling with GIT (SCM-709), so for the apache-pom
we should either stay on m-release-p 2.3.2 or m-release-p 2.4.2 with
scm-1.7 (if possible)
Robert
[1] https://jira.codehaus.org/browse/MRELEASE-459
Op Wed, 13 Nov 2013 17:50:02 +0100 schreef Benson Margulies
bimargul...@gmail.com:
On Wed, Nov 13, 2013 at 11:33 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
The profiles are not being activated... this is why in the asf pom we
use
the -P... in the arguments tag
Why aren't the profiles activated? Does 'arguments' disable
'releaseProfiles'?
On 13 November 2013 16:01, Benson Margulies bimargul...@gmail.com
wrote:
On Wed, Nov 13, 2013 at 10:54 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 27 October 2012 22:00, bimargul...@apache.org wrote:
Author: bimargulies
Date: Sat Oct 27 21:00:24 2012
New Revision: 1402867
URL: http://svn.apache.org/viewvc?rev=1402867view=rev
Log:
MPOM-38: Enable RAT to help us get maven releases to be
license-header
compliant
o Also configure the release plugin to turn on rat (quietly)
Modified:
maven/pom/trunk/maven/pom.xml
Modified: maven/pom/trunk/maven/pom.xml
URL:
http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1402867r1=1402866r2=1402867view=diff
==
--- maven/pom/trunk/maven/pom.xml (original)
+++ maven/pom/trunk/maven/pom.xml Sat Oct 27 21:00:24 2012
@@ -806,12 +806,43 @@ under the License.
artifactIdfindbugs-maven-plugin/artifactId
version2.5.2/version
/plugin
+plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-release-plugin/artifactId
+ version2.3.2/version
+ configuration
+useReleaseProfiletrue/useReleaseProfile
+releaseProfilesapache-release,rat/releaseProfiles
+goalsdeploy/goals
+arguments${arguments}/arguments
FYI This just blew up in my face with Doxia 1.5. I had to resort to
re-running release:perform with -DconnectupUrl=...
-Darguments=-P+apache-release,rat to get the release to stage
correctly
with GPG signature etc...
What's special about doxia, or, alternatively, what's wrong here?
+ /configuration
+/plugin
/plugins
/pluginManagement
/build
profiles
profile
+ idrat/id
+ build
+plugins
+ plugin
+groupIdorg.apache.rat/groupId
+artifactIdapache-rat-plugin/artifactId
+executions
+ execution
+phaseverify/phase
+goals
+ !-- rat, not check, because we've got lots of
noncomplaint stuff --
+ goalrat/goal
+/goals
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+profile
idquality-checks/id
activation
property
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1402867 - /maven/pom/trunk/maven/pom.xml
I'm a trifle swamped, so anyone else who wants to change the pom is
welcome to lead this charge.
On Wed, Nov 13, 2013 at 1:23 PM, Robert Scholte rfscho...@apache.org wrote:
Hi,
I can confirm that I'm having the same issues as Stephen when releasing but
didn't took the time to figure out the cause: I knew the workaround and
thought it had to do with my settings.xml.
The issue of the m-release-p for not picking up the profile was fixed in
MRELEASE-459 [1], together with a lot of other profile related issues.
However, we're still struggling with GIT (SCM-709), so for the apache-pom we
should either stay on m-release-p 2.3.2 or m-release-p 2.4.2 with scm-1.7
(if possible)
Robert
[1] https://jira.codehaus.org/browse/MRELEASE-459
Op Wed, 13 Nov 2013 17:50:02 +0100 schreef Benson Margulies
bimargul...@gmail.com:
On Wed, Nov 13, 2013 at 11:33 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
The profiles are not being activated... this is why in the asf pom we use
the -P... in the arguments tag
Why aren't the profiles activated? Does 'arguments' disable
'releaseProfiles'?
On 13 November 2013 16:01, Benson Margulies bimargul...@gmail.com
wrote:
On Wed, Nov 13, 2013 at 10:54 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 27 October 2012 22:00, bimargul...@apache.org wrote:
Author: bimargulies
Date: Sat Oct 27 21:00:24 2012
New Revision: 1402867
URL: http://svn.apache.org/viewvc?rev=1402867view=rev
Log:
MPOM-38: Enable RAT to help us get maven releases to be
license-header
compliant
o Also configure the release plugin to turn on rat (quietly)
Modified:
maven/pom/trunk/maven/pom.xml
Modified: maven/pom/trunk/maven/pom.xml
URL:
http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1402867r1=1402866r2=1402867view=diff
==
--- maven/pom/trunk/maven/pom.xml (original)
+++ maven/pom/trunk/maven/pom.xml Sat Oct 27 21:00:24 2012
@@ -806,12 +806,43 @@ under the License.
artifactIdfindbugs-maven-plugin/artifactId
version2.5.2/version
/plugin
+plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-release-plugin/artifactId
+ version2.3.2/version
+ configuration
+useReleaseProfiletrue/useReleaseProfile
+releaseProfilesapache-release,rat/releaseProfiles
+goalsdeploy/goals
+arguments${arguments}/arguments
FYI This just blew up in my face with Doxia 1.5. I had to resort to
re-running release:perform with -DconnectupUrl=...
-Darguments=-P+apache-release,rat to get the release to stage
correctly
with GPG signature etc...
What's special about doxia, or, alternatively, what's wrong here?
+ /configuration
+/plugin
/plugins
/pluginManagement
/build
profiles
profile
+ idrat/id
+ build
+plugins
+ plugin
+groupIdorg.apache.rat/groupId
+artifactIdapache-rat-plugin/artifactId
+executions
+ execution
+phaseverify/phase
+goals
+ !-- rat, not check, because we've got lots of
noncomplaint stuff --
+ goalrat/goal
+/goals
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+profile
idquality-checks/id
activation
property
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Can somebody (Hervé?) stage the Doxia 1.5 site
I suppose you did mvn site-deploy but for such a multi-module project, you need to use mvn scm-publish:publish- scm [1] Notice actual Doxia 1.5 can't be injected into maven-site-plugin because of DOXIA-499 + DOXIASITETOOLS-85 perhaps the class should be readded for compatibility, but marked deprecated, waiting for a new full Doxia+DoxiaSiteTools+m-site-p release Regards, Hervé [1] http://maven.apache.org/developers/website/deploy-component-reference-documentation.html Le mercredi 13 novembre 2013 16:33:24 Stephen Connolly a écrit : WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended. [INFO] Downloading from JIRA at: http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rsspid=10780statu sIds=6resolutionIds=1sorter/field=issuekeysorter/order=ASCtempMax=1000r eset=truedecorator=none [WARNING] org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML. at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132) at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108) at org.apache.maven.plugin.jira.AbstractJiraDownloader.getIssueList(AbstractJir aDownloader.java:753) at org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:347) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport. java:190) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDo cumentRenderer.java:219) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(Default SiteRenderer.java:319) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRe nderer.java:135) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPl uginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:2 09) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:1 53) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:1 45) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Life cycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Life cycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(Lif ecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarte r.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.ja va:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher. java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.xml.sax.SAXParseException; lineNumber: 117; columnNumber: 3; The element type meta must be terminated by the matching end-tag /meta. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc her.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source) at
maven-wagon pull request: Code cleanup
Github user ebourg closed the pull request at: https://github.com/apache/maven-wagon/pull/8 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Can somebody (Hervé?) stage the Doxia 1.5 site
content staged here: http://maven.apache.org/doxia/doxia-archives/doxia-LATEST/ notice I had to tweak m-changes-p version (done in trunk too) and fix manually staging site siince the actual automatic location is wrong: I still need to fix trunk (see MSITE-687) I you can wait a little bit before re-rolling the release, I'll fix it tonight (with compatibility with m-site-p 3.3- too) Regards, Hervé Le jeudi 14 novembre 2013 01:40:37 Hervé BOUTEMY a écrit : I suppose you did mvn site-deploy but for such a multi-module project, you need to use mvn scm-publish:publish- scm [1] Notice actual Doxia 1.5 can't be injected into maven-site-plugin because of DOXIA-499 + DOXIASITETOOLS-85 perhaps the class should be readded for compatibility, but marked deprecated, waiting for a new full Doxia+DoxiaSiteTools+m-site-p release Regards, Hervé [1] http://maven.apache.org/developers/website/deploy-component-reference-docum entation.html Le mercredi 13 novembre 2013 16:33:24 Stephen Connolly a écrit : WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended. [INFO] Downloading from JIRA at: http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rsspid=10780sta tu sIds=6resolutionIds=1sorter/field=issuekeysorter/order=ASCtempMax=100 0r eset=truedecorator=none [WARNING] org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML. at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132) at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108) at org.apache.maven.plugin.jira.AbstractJiraDownloader.getIssueList(AbstractJ ir aDownloader.java:753) at org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:347) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenRepor t. java:190) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(Report Do cumentRenderer.java:219) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(Defau lt SiteRenderer.java:319) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSite Re nderer.java:135) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuild Pl uginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java :2 09) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java :1 53) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java :1 45) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Li fe cycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Li fe cycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(L if ecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStar te r.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 57 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl .java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher. ja va:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230 ) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launche r. java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.xml.sax.SAXParseException; lineNumber: 117; columnNumber: 3; The element type meta must be terminated by the matching end-tag /meta. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unkno wn Source) at
