Re: svn commit: r1734070 - /maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt
Hi Herve,
just from intuition I would say it's the update date, but I don't think
there is a formal definition/specification on the level of the sink API.
The only distinction between creation and update date that I remember is
in the document MetaData (org.apache.maven.doxia.document.DocumentMeta).
HTH,
-Lukas
Am 09.03.2016 um 08:28 schrieb Hervé BOUTEMY:
question to old Doxia developers: is date in title of a Doxia source file
expected to be *creation* or *update* date
since it seems we use this field inconsistently for these 2 purposes,
depending on who and when does an update
what is it intended to represent precisely?
in apt format doc [1], there is documentation about the format but not about
which date it is...
Regards,
Hervé
[1] http://maven.apache.org/doxia/references/apt-format.html#Title
Le mardi 8 mars 2016 13:06:31 denn...@apache.org a écrit :
Author: dennisl
Date: Tue Mar 8 13:06:31 2016
New Revision: 1734070
URL: http://svn.apache.org/viewvc?rev=1734070=rev
Log:
Update links to ex-codehaus plugins which are now at mojohaus.
Modified:
maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt
Modified:
maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt URL:
http://svn.apache.org/viewvc/maven/site/trunk/content/apt/guides/mini/guide
-using-toolchains.apt?rev=1734070=1734069=1734070=diff
===
=== --- maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt
(original) +++
maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt Tue Mar
8 13:06:31 2016 @@ -5,7 +5,7 @@
Dennis Lundberg
Karl Heinz Marbaise
--
- 2015-06-12
+ 2016-03-08
--
~~ Licensed to the Apache Software Foundation (ASF) under one
@@ -59,15 +59,15 @@ Guide to Using Toolchains
*-*
--+-+---
-+
| jdk |
| <<<{{{/plugins/maven-surefire-plugin/}maven-surefire-plugin}}>>>
| | 2.5 | Apache Maven
*-*
--+-+---
-+ -| jdk |
<<<{{{http://mojo.codehaus.org/animal-sniffer-maven-plugin/}animal-sniffer->
maven-plugin}}>>> | 1.3 | Codehaus Mojo +| jdk |
<<<{{{http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/}a
nimal-sniffer-maven-plugin}}>>> | 1.3 | Codehaus Mojo
*-*
--+-+---
-+ -| jdk |
<<<{{{http://mojo.codehaus.org/cassandra-maven-plugin/}cassandra-maven-plug
in}}>>> | 0.7.0-1 | Codehaus Mojo +| jdk |
<<<{{{http://www.mojohaus.org/cassandra-maven-plugin/}cassandra-maven-plugi
n}}>>>| 0.7.0-1 | Codehaus Mojo
*-*
--+-+---
-+ -| jdk |
<<<{{{http://www.mojohaus.org/exec-maven-plugin/}exec-maven-plugin}}>>>
| 1.1.1 | Codehaus Mojo +| jdk |
<<<{{{http://www.mojohaus.org/exec-maven-plugin/}exec-maven-plugin}}>>>
| 1.1.1 | Codehaus Mojo
*-*
--+-+---
-+ -| jdk |
<<<{{{http://www.mojohaus.org/jdiff-maven-plugin/}jdiff-maven-plugin}}>>>
| 1.0-beta-1-SNAPSHOT | Codehaus Mojo +| jdk |
<<<{{{http://www.mojohaus.org/jdiff-maven-plugin/}jdiff-maven-plugin}}>>>
| 1.0-beta-1-SNAPSHOT | Codehaus Mojo
*-*
--+-+---
-+ -| jdk |
<<<{{{http://mojo.codehaus.org/keytool-maven-plugin/}keytool-maven-plugin}}
| 1.4 | Codehaus Mojo +| jdk |
<<<{{{http://www.mojohaus.org/keytool/keytool-maven-plugin/}keytool-maven-p
lugin}}>>>| 1.4 | Codehaus Mojo
*-*
--+-+---
-+
| protobuf|
| <<<{{{http://sergei-ivanov.github.io/maven-protoc-plugin/examples/protob
| uf-toolchain.html}maven-protoc-plugin}}>>> | 0.3.2 | github
*-*
--+-+---
-+
Re: svn commit: r1695142 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
see related https://issues.apache.org/jira/browse/DOXIA-436
Greetings! :)
-Lukas
Am 12.08.2015 um 23:54 schrieb herve.bout...@free.fr:
now that you told it, I'd seriously prefer change Doxia Markdown parser to use
an XhtmlParser instance internally instead of extending XhtmlParser while
completely replacing content parsed by the Xhtml parser: this would be a lot
more clear (and would avoid adding bloat to getType())
I didn't really try, I don't know if this change is really complex
did you try?
Regards,
Hervé
- Mail original -
De: Petar Tahchiev paranoia...@gmail.com
À: Maven Developers List dev@maven.apache.org
Envoyé: Mercredi 12 Août 2015 08:39:12
Objet: Re: svn commit: r1695142 -
/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
OK,
sorry I wasn't aware that user specifying an input encoding for xml file
would be considered as introducing a bug. Great for the test-case - I will
revert my changes and work for a fix in the MarkdownParser. Would
overriding the getType() method of the MarkdownParser be considered as a
valid solution?
2015-08-12 2:42 GMT+03:00 herve.bout...@free.fr:
IIUC, your concerns are about Mardown: if Markdown parser has a bug, don't
hesitate to fix it
but do not break content for normal XML parsers, like fml or xdoc
since your change did not make unit tests fail, this proves unit tests are
too weak: I just improved them in r1695408 to fail (and show clearly what
you are breaking)
and I reopened DOXIASITETOOLS-104
You're probably right that making Markdown parser *extend* XhtmlParser is
probably wrong: it should *use* an XhtmlParser, but not extend it
Regards,
Hervé
- Mail original -
De: Petar Tahchiev paranoia...@gmail.com
À: Maven Developers List dev@maven.apache.org
Envoyé: Mardi 11 Août 2015 11:36:28
Objet: Re: svn commit: r1695142 -
/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Hi Herve,
I did this because seems like a parser can be of type XML even if it's not
parsing only XML - for example the MarkdownParser (which is in doxia and
extends from the XmlParser) getType() returns 2 (XML parser type). I guess
there are two ways to go here - 1) first would be to allow the user to
force an encoding. It's his/hers decision and he/she takes the
responsibility. 2) Would be to override the XmlParser:getType() method in
MarkdownParser and make it return 0 (UNKNOWN_TYPE). To me this would lead
to inconsistency, because the MarkdownParser extends from XmlParser, but
returns another type. Furthermore I don't agree markdown syntax is in fact
xml syntax.
2015-08-11 11:04 GMT+03:00 herve.bout...@free.fr:
wow, I don't like this
in XML, encoding is self provided
with such feature, an XML-invalid document can be read by Maven (and
Maven
only, since it is XML-invalid)
I'm -1 on this: we can't help people make Maven-specific pseudo XML
Regards,
Hervé
- Mail original -
De: ptahch...@apache.org
À: comm...@maven.apache.org
Envoyé: Lundi 10 Août 2015 20:00:00
Objet: svn commit: r1695142 -
/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Author: ptahchiev
Date: Mon Aug 10 18:00:00 2015
New Revision: 1695142
URL: http://svn.apache.org/r1695142
Log:
Check for user's provided encoding, and only if it's null then use the
encoding of the xml document. Closes [DOXIASITETOOLS-104]
Modified:
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Modified:
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
URL:
http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java?rev=1695142r1=1695141r2=1695142view=diff
==
---
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
(original)
+++
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Mon Aug 10 18:00:00 2015
@@ -389,7 +389,14 @@ public class DefaultSiteRenderer
switch ( parser.getType() )
{
case Parser.XML_TYPE:
-reader = ReaderFactory.newXmlReader( doc );
+if ( siteContext.getInputEncoding() != null )
+{
+reader = ReaderFactory.newReader( doc,
siteContext.getInputEncoding() );
+}
+else
+{
+reader =
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
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
-1 (non-binding) -Lukas On 05/29/2013 12:01 PM, Stephen Connolly wrote: We have been using a policy of only making releases without skipping version numbers, e.g. 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc Whereby if there is something wrong with the artifacts staged for release, we drop the staging repo, delete the tag, roll back the version, and run again. This vote is to change the policy to: drop the staging repo, document the release as not released, and run with the next version. Under this new proposal, if the staged artifacts for 3.1.0 fail to meet the release criteria, then the artifacts would be dropped from the staging repository and never see the light of day. The tag would remain in SCM, and we would document (somewhere) that the release was cancelled. The respin would have version number 3.1.1 and there would never be a 3.1.0. This change could mean that the first actual release of 3.1.x might end up being 3.1.67 (though I personally view that as unlikely, and in the context of 3.1.x I think we are very nearly there) Please Note: http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes not actually specify what it means by the process will need to be restarted so this vote will effect a change either outcome +1: Never respin with the same version number, always increment the version for a respin 0: Don't care -1: Always respin with the same version number until that version number gets released This vote will be open for 72 hours. A Majority of PMC votes greater that 3 will be deemed as decisive in either direction (i.e. if the sum is -3 or +3 then there is a documented result) For any releases in progress at this point in time, it is up to the release manager to decide what to do if they need to do a respin. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Doxia base + Sitetools version 1.4
+1 (non-binding) However, the staging sites are still not there...? Thanks! -Lukas On 04/24/2013 12:21 AM, Hervé BOUTEMY wrote: Hi, We solved 21 issues in Doxia base: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780version=18423 We solved 4 issues in Doxia Sitetools: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624version=18427 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780status=1 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11624status=1 Staging repo: https://repository.apache.org/content/repositories/maven-131/ https://repository.apache.org/content/repositories/maven-131/org/apache/maven/doxia/doxia/1.4/doxia-1.4- source-release.zip https://repository.apache.org/content/repositories/maven-131/org/apache/maven/doxia/doxia- sitetools/1.4/doxia-sitetools-1.4-source-release.zip Staging site (svnpubsub check-in in progress): http://maven.apache.org/doxia-archives/doxia-1.4/ http://maven.apache.org/doxia-sitetools-archives/doxia-sitetools-1.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: r1465234 - in /maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src: main/java/org/apache/maven/doxia/module/apt/AptParser.java test/java/org/apache/maven/doxia/module/apt/AptPar
Seems to be a good fix, thanks Robert!
I'm only missing some documentation, could you add an example to
http://maven.apache.org/doxia/references/doxia-apt.html ?
Cheers,
-Lukas
rfscho...@apache.org wrote:
Author: rfscholte
Date: Sat Apr 6 12:21:13 2013
New Revision: 1465234
URL: http://svn.apache.org/r1465234
Log:
[DOXIA-397] Cannot link to javadoc methods
Modified:
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/test/java/org/apache/maven/doxia/module/apt/AptParserTest.java
Modified:
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
URL:
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java?rev=1465234r1=1465233r2=1465234view=diff
==
---
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
(original)
+++
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
Sat Apr 6 12:21:13 2013
@@ -477,7 +477,12 @@ public class AptParser
logMessage( ambiguousLink, msg );
}
-if ( !DoxiaUtils.isValidId( hash ) )
+// link##anchor means literal
+if( hash.startsWith( # ) )
+{
+linkAnchor = linkAnchor.substring( 0,
hashIndex ) + hash;
+}
+else if ( !DoxiaUtils.isValidId( hash ) )
{
linkAnchor =
linkAnchor.substring( 0, hashIndex ) +
#
Modified:
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/test/java/org/apache/maven/doxia/module/apt/AptParserTest.java
URL:
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/test/java/org/apache/maven/doxia/module/apt/AptParserTest.java?rev=1465234r1=1465233r2=1465234view=diff
==
---
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/test/java/org/apache/maven/doxia/module/apt/AptParserTest.java
(original)
+++
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/test/java/org/apache/maven/doxia/module/apt/AptParserTest.java
Sat Apr 6 12:21:13 2013
@@ -513,6 +513,26 @@ public class AptParserTest
assertFalse( it.hasNext() );
}
+public void testLiteralAnchor()
+throws Exception
+{
+// DOXIA-397
+String text =
+
{{{../apidocs/groovyx/net/http/ParserRegistry.html##parseText(org.apache.http.HttpResponse)}ParserRegistry}};
+
+SinkEventTestingSink sink = new SinkEventTestingSink();
+
+parser.parse( text, sink );
+
+IteratorSinkEventElement it = sink.getEventList().iterator();
+assertEquals( it, head, head_, body, section1, sectionTitle1
);
+assertEquals( it.next(), link,
+
../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)
);
+assertEquals( it.next(), text, ParserRegistry );
+assertEquals( it, link_, sectionTitle1_, section1_, body_ );
+assertFalse( it.hasNext() );
+}
+
/** {@inheritDoc} */
protected String outputExtension()
{
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1465234 - in /maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src: main/java/org/apache/maven/doxia/module/apt/AptParser.java test/java/org/apache/maven/doxia/module/apt/AptPar
Excellent, I didn't see that. Thanks!
-Lukas
Hervé BOUTEMY wrote:
yes, I like this nice new markup idea too
Lukas, documentation was added in http://svn.apache.org/r1465238
did you overlooked it or do you have a more precise documentation idea?
Regards,
Hervé
Le dimanche 7 avril 2013 09:12:37 Lukas Theussl a écrit :
Seems to be a good fix, thanks Robert!
I'm only missing some documentation, could you add an example to
http://maven.apache.org/doxia/references/doxia-apt.html ?
Cheers,
-Lukas
rfscho...@apache.org wrote:
Author: rfscholte
Date: Sat Apr 6 12:21:13 2013
New Revision: 1465234
URL: http://svn.apache.org/r1465234
Log:
[DOXIA-397] Cannot link to javadoc methods
Modified:
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/
org/apache/maven/doxia/module/apt/AptParser.java
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/test/java
/org/apache/maven/doxia/module/apt/AptParserTest.java
Modified:
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/
apache/maven/doxia/module/apt/AptParser.java URL:
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-
module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java?
rev=1465234r1=1465233r2=1465234view=diff
=
= ---
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/
apache/maven/doxia/module/apt/AptParser.java (original) +++
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/
apache/maven/doxia/module/apt/AptParser.java Sat Apr 6 12:21:13 2013 @@
-477,7 +477,12 @@ public class AptParser
logMessage( ambiguousLink, msg );
}
-if ( !DoxiaUtils.isValidId( hash ) )
+// link##anchor means literal
+if( hash.startsWith( # ) )
+{
+linkAnchor = linkAnchor.substring( 0,
hashIndex ) + hash; +}
+else if ( !DoxiaUtils.isValidId( hash ) )
{
linkAnchor =
linkAnchor.substring( 0,
hashIndex ) + #
Modified:
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/test/java/org/
apache/maven/doxia/module/apt/AptParserTest.java URL:
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-
module-apt/src/test/java/org/apache/maven/doxia/module/apt/AptParserTest.j
ava?rev=1465234r1=1465233r2=1465234view=diff
=
= ---
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/test/java/org/
apache/maven/doxia/module/apt/AptParserTest.java (original) +++
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/test/java/org/
apache/maven/doxia/module/apt/AptParserTest.java Sat Apr 6 12:21:13 2013
@@ -513,6 +513,26 @@ public class AptParserTest
assertFalse( it.hasNext() );
}
+public void testLiteralAnchor()
+throws Exception
+{
+// DOXIA-397
+String text =
+
{{{../apidocs/groovyx/net/http/ParserRegistry.html##parseText(org.apache
.http.HttpResponse)}ParserRegistry}}; +
+SinkEventTestingSink sink = new SinkEventTestingSink();
+
+parser.parse( text, sink );
+
+IteratorSinkEventElement it = sink.getEventList().iterator();
+assertEquals( it, head, head_, body, section1,
sectionTitle1 ); +assertEquals( it.next(), link,
+
../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.htt
p.HttpResponse) ); +assertEquals( it.next(), text,
ParserRegistry );
+assertEquals( it, link_, sectionTitle1_, section1_, body_
); +assertFalse( it.hasNext() );
+}
+
/** {@inheritDoc} */
protected String outputExtension()
{
-
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: [VOTE] formally end support for Maven 1
+1 (not binding) -Lukas Benson Margulies wrote: Based on the sentiment on the discussion thread, I call a formal vote to end support for Maven 1.x. This is a vote to: 1: Remove maven 1 release materials from the primary distribution area, leaving them only on the archive. 2: Make appropriate changes to the web site to state clearly that the community no longer provides support for Maven 1. This vote will be open for until Wed March 6, 00:00 GMT (we're not in a hurry here). Here is my +1. - 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: Some issues with Doxia
Hi, First: are you aware of the maven pdf plugin: http://maven.apache.org/plugins/maven-pdf-plugin/ It seems that you are trying to re-write it? ;) See further comments in-line: On 02/25/2013 11:22 AM, Corentin Groix wrote: Hi First, I am quite a newbie at submitting feedback to an apache project, so I am not sure if I chose the right place, but I haven't found how to create an account in the JIRA issue tracker. I am using Doxia as a stand alone library in my application to generate PDF files using a source written in Markdown, with markdown and FO modules, and Apache Fop. I don't know if this a frequent use case, but I found some issues: - First, I encountered this issue: http://jira.codehaus.org/browse/DOXIA-480 (html entities ignored by the xhtml parser) , but the consequence were more dramatic in my case: The AbstractXMLParser.handleEntity(parser,sink) create a null String and give it to sink.text(), causing a nullPointerException in FoSink.escaped(String,boolean) (line 1600). Exception in thread main java.lang.NullPointerException at org.apache.maven.doxia.module.fo.FoSink.escaped(FoSink.java:1600) at org.apache.maven.doxia.module.fo.FoSink.content(FoSink.java:1588) at org.apache.maven.doxia.module.fo.FoSink.text(FoSink.java:1315) at org.apache.maven.doxia.module.fo.FoSink.text(FoSink.java:1321) at org.apache.maven.doxia.parser.AbstractXmlParser.handleEntity(AbstractXmlParser.java:390) at org.apache.maven.doxia.parser.AbstractXmlParser.parseXml(AbstractXmlParser.java:251) at org.apache.maven.doxia.parser.AbstractXmlParser.parse(AbstractXmlParser.java:141) at org.apache.maven.doxia.parser.XhtmlBaseParser.parse(XhtmlBaseParser.java:90) at org.apache.maven.doxia.module.markdown.MarkdownParser.parse(MarkdownParser.java:71) The correction of DOXIA-480 bug corrected this problem, but I think a null-check in FoSink.text or FoSink.escaped would be useful. Unfortunately the Sink javadocs do not explicitly specify it http://maven.apache.org/doxia/doxia/doxia-sink-api/apidocs/org/apache/maven/doxia/sink/Sink.html#text(java.lang.String, org.apache.maven.doxia.sink.SinkEventAttributes) but the description seems to imply that the text argument be non-null. In particular, the most frequently-used Sink (XhtmlSink) does not check for null text. I think DOXIA-480 is the correct fix for this issue. - A second issue: Is there any reason the h1 tag is ignored by the xhtml parser? Unfortunately, the doxia Sink API only knows 5 section levels which are mapped by the html parser/sink to h2-h6. See https://jira.codehaus.org/browse/DOXIA-203 I fix this by using the title() method, since my markdown document doesn't have head. - A more annoying problem: The FoSink class produce invalid XSL-FO document: more precisely, the fo:flow and fo:page-sequence are ended, by the body_() end method, but the body() start method does not open them. There is a startPageSequence() protected function, but it is not called in the FOSink class, even if it called in the FPAggregateSink subclasse. I vaguely remember that this was done to work around some other issues, probably the apt or xdoc parser. If you change this behavior, you should make sure that all tests pass, in particular also those of doxia sitetools. I can provide my patch to fix these issues if necessary, and I attached an example using the Markdown parser, Fo Sink and Fop demonstrating these issues (the first with Doxia 1.3, the others using latest Doxia source). The correct way to proceed would be to open a JIRA and attach your patches there. Not sure why you can't register an account, maybe send another specific mail to the user list, or ask on IRC. HTH, -Lukas Best regards Corentin Groix - 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: Site:stage relativization against a variable URL
Lennart Jörelid wrote:
Good evening, all.
Today, maven-site-plugin performs its site:stage goal by copying the site
of a project into a staging directory, and relativizing some URLs. The
latter part is done by calculating the difference between the current
project's ${project.distributionManagement.site.url} and
the ${project.distributionManagement.site.url} of the topmost parent pom,
retrieved from the current project.
The MSITE-699 patch (https://jira.codehaus.org/browse/MSITE-669) currently
introduces an optional parameter to permit relativizing the URLs in a
staged site against the ${project.distributionManagement.site.url} of the
reactor root pom instead. This flexibility simplifies site:stage for
nonstandard reactor layouts.
However - I believe it could be more powerful/flexible/desirable to simply
add an optional parameter to the site:stage goal with the desired root URL
(i.e. giving the users the ability to supply the effective site:stage root
URL as a [command line] configuration parameter). This would enable users
to create staged sites for parts of a reactor with relative ease - which
would be an improvement to the current site:stage goal.
It would certainly be a simple patch to supply.
What do you think?
This would be a more general solution than the current MSITE-699, sounds
reasonable to me.
-Lukas
--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect Integrator
|
| Phone
| (skype):jgurueurope
+==+
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: release of maven-pdf-plugin
grrr, I wanted to do that for such a long time, I have also been using the snapshot ever since I fixed MPDF-36 (almost 3 years ago!). Unfortunately, I still have no time to help but you'll have my +1 for a release! Thanks! -Lukas On Mon, Nov 5, 2012 at 2:35 PM, Benson Margulies bimargul...@gmail.com wrote: There's a lot of pent-up fixes there, I'll run a release tonight unless I hear an objection. I see no reason to wait for other fixes. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven PDF Plugin Version 1.2
+1 !!! (non-binding) There is still one open issue [1] scheduled for this release. I am not using Maven 2 anymore, so I don't know what the status is there, but it's assigned to Herve anyway... :p Thanks! -Lukas [1] http://jira.codehaus.org/browse/MPDF-46 Benson Margulies wrote: To: Maven Developers List dev@maven.apache.org Subject: [VOTE] Release Maven XXX Plugin version Y.Z Hi, We solved 15 issues:http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11932version=16050 There are still a couple of issues left in JIRA:http://jira.codehaus.org/browse/MPDF#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel Staging repo:https://repository.apache.org/content/repositories/maven-018/https://repository.apache.org/content/repositories/maven-018/org/apache/maven/plugins/maven-pdf-plugin/1.2/maven-pdf-plugin-1.2-source-release.zip Staging site:http://maven.apache.org/plugins/maven-pdf-plugin-1.2/ Guide to testing staged releases:http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MSITE-604 - Properties from settings.xml are not recognized in site distribution management
Hi, First: thanks for working on this! I have had a brief look and have a few comments: 1) your patch of IT MSITE-604 seems to address a different issue than the one originally described in the JIRA. If this is the case you should open a separate ticket. 2) I am wondering about the validity of the use case. You are putting the following property into a profile inside settings.xml: msite604.siteRepositoryUrlfile://@project.build.directory@/it/MSITE-604/target/settingsRepositoryUrl/msite604.siteRepositoryUrl However, the settings guide [1] states that only system and environment variables can be interpolated in settings.xml and furthermore, properties defined in profiles within the settings.xml cannot be used for interpolation at all. 3) Finally, the syntax @project.build.directory@ is known and used only by the invoker plugin (AFAIK) [2], the site plugin shouldn't be concerned with interpolating this. It is not clear to me how this would be relevant in a stand-alone project, maybe you can attach a small test project to reproduce the issue. I'd also appreciate the opinion of other devs with better property/interpolation knowledge, I confess I am confused by this issue... Cheers, -Lukas [1] http://maven.apache.org/settings.html [2] http://maven.apache.org/plugins/maven-invoker-plugin/examples/filtering.html On Mon, Oct 29, 2012 at 5:38 PM, Vincent Latombe vincent.lato...@gmail.com wrote: Hello, I think I have an acceptable IT + fix for this issue [1] (at least in Maven 3 context), so I would be really grateful if someone with karma could take a look at it and let me know about it :) Cheers, [1] http://jira.codehaus.org/browse/MSITE-604 -- Vincent - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Doxia Tools parent version 2 and Doxia Integration Tools version 1.5
+1 -Lukas Dennis Lundberg wrote: Hi, This is the first release of the Doxia Tools parent after the restructuring of these components. It now works in the same way as the parents for Plugins and Shared Components. Doxia Integration Tools moved from Shared Components to Doxia Tools in this release. We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12125component=15480version=18406styleName=Html There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=12125component=15480status=1 Staging repo: https://repository.apache.org/content/repositories/maven-023/ https://repository.apache.org/content/repositories/maven-023/org/apache/maven/doxia/doxia-tools/2/doxia-tools-2-source-release.ziphttps://repository.apache.org/content/repositories/maven-023/org/apache/maven/doxia/doxia-integration-tools/1.5/doxia-integration-tools-1.5-source-release.zip Staging sites (wait for the sync): http://maven.apache.org/doxia/doxia-tools/doxia-tools-2/ http://maven.apache.org/doxia/doxia-tools/doxia-integration-tools-1.5/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Followup: use the #evaluate Velocity macro in the skin Velocity emplate
Hi Simone, I will try to have a look if you create a JIRA with a test project that I can play with. No promises though, my velocity skills are quite rusty by now... -Lukas Simone Tripodi wrote: Hi all guys, I invested some time on trying the upgrade and I miserably failed :( The fact is that I didn't get explicit warnings/errors, the macro was simply ignored and rendered as #evaluate String, with arguments. Can someone please, with more doxia background, help me on give a try? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Aug 29, 2012 at 8:15 AM, Lukas Theussl ltheu...@apache.org wrote: FYI: I've had troubles trying to upgrade velocity beyond version 1.5: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 IIRC, the main problem was backward compatibility. It should be ok with current skin versions but that's not tested. HTH, -Lukas Hervé BOUTEMY wrote: Hi Simone, Velocity is a direct dependency of doxia-site-renderer [2] and maven- reporting-exec [3] and ultimately of maven-site-plugin. I had a look at m-site-p trunk sources and actual Velocity version is 1.5. For immediate tests, you can try to override Velocity dependency in your pom's m-site-p plugin configuration. And later, add a Jira issue and change dependency in m-site-p trunk if you know Velocity well and are sure this won't break actual user sites (using Velocity 1.5 implicitely). I added explicit Velocity version in r1378417. Regards, Hervé [2] http://maven.apache.org/doxia/doxia-sitetools/index.html [3] http://maven.apache.org/shared/maven-reporting-exec/ Le mardi 28 aoűt 2012 14:02:12 Simone Tripodi a écrit : Hi all guys, as per subject, before cutting the current fluido RC, Robert and I gave some tries to evaluate strings inside the skin template using the #evaluate Velocity macro[1] but with no success... I guess mainly because the used velocity engine is a previous version which doesn't support that yet, but my question is if someone can point me to the direction on how I can provide my help on performing that upgrade. TIA, all the best! -Simo [1] http://velocity.apache.org/engine/devel/vtl-reference-guide.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: use the #evaluate Velocity macro in the skin Velocity emplate
FYI: I've had troubles trying to upgrade velocity beyond version 1.5: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 IIRC, the main problem was backward compatibility. It should be ok with current skin versions but that's not tested. HTH, -Lukas Hervé BOUTEMY wrote: Hi Simone, Velocity is a direct dependency of doxia-site-renderer [2] and maven- reporting-exec [3] and ultimately of maven-site-plugin. I had a look at m-site-p trunk sources and actual Velocity version is 1.5. For immediate tests, you can try to override Velocity dependency in your pom's m-site-p plugin configuration. And later, add a Jira issue and change dependency in m-site-p trunk if you know Velocity well and are sure this won't break actual user sites (using Velocity 1.5 implicitely). I added explicit Velocity version in r1378417. Regards, Hervé [2] http://maven.apache.org/doxia/doxia-sitetools/index.html [3] http://maven.apache.org/shared/maven-reporting-exec/ Le mardi 28 août 2012 14:02:12 Simone Tripodi a écrit : Hi all guys, as per subject, before cutting the current fluido RC, Robert and I gave some tries to evaluate strings inside the skin template using the #evaluate Velocity macro[1] but with no success... I guess mainly because the used velocity engine is a previous version which doesn't support that yet, but my question is if someone can point me to the direction on how I can provide my help on performing that upgrade. TIA, all the best! -Simo [1] http://velocity.apache.org/engine/devel/vtl-reference-guide.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [VOTE] Release Maven Project Info Reports Plugin version 2.5.1
+1 -Lukas Hervé BOUTEMY wrote: Hi, We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142version=18715styleName=Html There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11142status=1 Staging repo: https://repository.apache.org/content/repositories/maven-013/ https://repository.apache.org/content/repositories/maven-013/org/apache/maven/plugins/maven- project-info-reports-plugin/2.5.1/maven-project-info-reports-plugin-2.5.1- source-release.zip Staging site: (sync pending) http://maven.apache.org/plugins/maven-project-info-reports-plugin-2.5.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: [VOTE] Tony Chemit as Apache Maven committer
+1 -Lukas On Fri, Jul 6, 2012 at 11:28 PM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to propose Tony Chemit as a committer. He is active on Mojo for long time now. He proposed some patches time ago and recently some more (I'm a bit boring applying his patches: it probably means it's time to have him here :-) ). Here my +1. Vote open for 72H. Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Clean Plugin 2.5
+1 (non-binding) -Lukas Olivier Lamy wrote: Hi, I'd like to release Maven Clean Plugin 2.5 We fixed 3 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128version=16456 Staging repository: https://repository.apache.org/content/repositories/maven-122 Staging site: http://maven.apache.org/plugins/maven-clean-plugin-2.5 (wait sync). [+1] [0] [-1] Thanks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven clean plugin release
I see the same problem on osx with svn 1.7.4 but not on linux with svn 1.6.17. Maybe an svn issue? -Lukas Olivier Lamy wrote: Hi, A user asked a release of maven clean plugin and I said: yes I will take care!. But I have some issues with svn on osx and some filenames used for an it test. (yes I have issues with french characters :-) ) see https://gist.github.com/2732233 So if someone can take care of the release, I will be happy Thanks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-changes-plugin 2.7.1
+1 -Lukas Benson Margulies wrote: Hi, We solved 1 issues: MCHANGES-281 There are still plenty of issues left in JIRA. Staging repo: https://repository.apache.org/content/repositories/maven-077/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.7.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here's my +1. Release Notes - Maven 2.x Changes Plugin - Version 2.7.1 ** Bug * [MCHANGES-281] - jira report fails with Jira 5.0.3 (NPE) - 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: [RESULT] [VOTE] Release Maven Changes Plugin version 2.7
For the record: my vote is not binding. Thanks for the release anyway! :) -Lukas Benson Margulies wrote: Subject: Hi, The vote has passed with the following result : +1 (binding): hboutemy, bimargulies, olamy, ltheussl +1 (non binding): Tony Chemit I will promote the artifacts to the central repo. - 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: [RESULT][VOTE] Apache Maven Compiler Plugin 2.4
same here: my vote is not binding. same here: thanks for the release anyway! :) -Lukas Olivier Lamy wrote: Hi, The vote has passed with the following result: +1 (binding): Hervé Boutemy, Kristian Rosenvold, Stephane Nicoll, Mark Struberg, Lukas Theussl, Emmanuel Venisse, Olivier Lamy +1 (non binding): Mark Derricutt, Karl Heinz Marbaise, Tony Chemit, I will continue the release process. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RFC] Reimagining the artifact and repository-interaction APIs
Hervé BOUTEMY wrote: I'm a little late, but needed time to think more on my comments :) Le lundi 9 avril 2012 17:27:09 John Casey a écrit : Hi all, I finally have some cycles free to work on Maven, and I'd like to spend some time thinking about how we might tackle some of the bigger-picture things. Personally, the first thing I'd like to see tackled is Maven's relationship to both Artifacts and the Repository system. IMO, these should be separate API artifacts with each having its own release cycle. The reasoning is that the APIs should be a contract with third parties (plugin devs, repository connector devs, etc.). The reasoning for separating them is that I believe what we do with Artifacts in Maven is largely orthogonal to the ways in which we interact with the repository system. I think we need to reimagine the way Maven interacts with the repository system (currently, I'm thinking of calling this the maven-artifact-portal system, unless something less lame comes along...it's bidirectional, so -fetcher, -retriever, etc. are out). I'd like to go all the way to refactoring the verbs given to these interactions: - 'resolve' - 'resolve' (Ok, that one's intuitive IMO) - 'deploy' - 'publish' - 'install' - 'cache' +1 for the verbs and perhaps we should not have separate install and deploy plugins but a unique artifact plugin with these verbs: the plugin name probably needs more ideas This may not be relevant at all but it just struck me that this is actually how it used to be in the maven 1 artifact plugin [1]. Not sure what the reason was to separate the two, but there probably was a reason, maybe someone remembers. Otherwise I find this whole discussion pretty useful and forward going, thanks in advance to all those who contribute! -Lukas [1] http://maven.apache.org/maven-1.x/plugins/artifact/tags.html Then, I'd like to turn the notion of a LocalRepository into an on-disk cache, whose storage format doesn't matter to the user, and which is manageable as such (flushing the cache, both in targeted and global fashion for instance). I'd also like to refactor the design to allow wholesale swapping of the repository system to a completely different architecture, or just swapping out parts (like the caching component), or even just adding in new connectors the way we can now. That's one consequence of the new verbs: we won't install to a local repository, which is misleading but cache on disk. The repository term for the local cache has always been something misleading. This urge to refactor of the repository system is something I haven't been able to get out of my head since the last time I gave up working on the decentralized maven repository code. That routing code would work fine, EXCEPT there's no place to plug it in. Part of the reason is that Maven resolves from locations that are specified on the scale of entire repositories, not on the scale of individual artifacts. Switching to an artifact-centric routing mechanism requires modification of dozens of classes. We could change all this, EXCEPT the most of those classes now reside in Aether, and that means convincing the powers that be over there that this is a worthwhile effort...probably not an easy thing. This exercise has convinced me that Maven needs to insulate itself in order to remain flexible and able to adapt to its evolving needs. Beyond the issues related to resolving artifacts, I'd like to make the depgraph more of a first-class citizen, so Maven components can query it for paths to a given artifact, along with other information. +1 what about updating shared/maven-dependency-tree to have a Maven 3 compatible version? I'd also like to build better support for pluggable versioning schemes (even if it's just for sorting versions), then make sure those schemes are actually selectable in some way. I'm skeptical, even twice skeptical: 1. is it useful? what verison numbers comparison is not good actually? Do you have an example? 2. can it be usable? I can't imagine a place to configure the choice of scheme that would be usable. Something at groupId level? But certainly not at artifact level, which is the only place that we could do at the moment AFAIK. Sure, this is a lot of work. I don't expect it to be done anytime soon, particularly if I'm the only one working on it, and only when I'm not working $dayjob or tending to Henry. But these problems are part of what's been depressing my enthusiasm for Maven in recent months, and I'd like to see them fixed. +1 to try and fix things, and +1000 to not work alone I'm looking into the SCM stuff for this work; currently, I'm tentatively planning to work out on GitHub, but maybe there's a way to use Git @ASF for this, since it'll be a few new subprojects in Maven. I'm not sure yet. I'm going to try like hell to avoid having to work with SVN (directly, at least). Git support at ASF should be sufficient by now to ask for it instead of using not connected github
Re: [VOTE] Release Maven Site Plugin version 3.1
+1 -Lukas Dennis Lundberg wrote: Hi, We solved 19 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16489 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: https://repository.apache.org/content/repositories/maven-009/ Staging site: http://maven.apache.org/plugins/maven-site-plugin-3.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Changes Plugin version 2.7
+1 -Lukas Benson Margulies wrote: Hi, We resolved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9IAS%7Cb183085c89ca85abde86540c1f02cb433b8719dd%7Cloutversion=17447styleName=TextprojectId=11212Create=Create There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-005/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.7/ There may be a delay while this copies itself. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 /to save people a click, here's the issue list/ Release Notes - Maven 2.x Changes Plugin - Version 2.7 ** Bug * [MCHANGES-237] - The goal jira-report always results in HTTP 400 error when accessing https://*.jira.com * [MCHANGES-261] - Mail sender specification pointlessly difficult * [MCHANGES-262] - Using custom issue types mapping (MCHANGES-245) throws a llegalArgumentException ** Improvement * [MCHANGES-213] - Update Velocity 1.7 * [MCHANGES-264] - [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata * [MCHANGES-279] - ability to skip for Jira is offlince ** New Feature * [MCHANGES-76] - Add an option to hava an aggregated Changes Report * [MCHANGES-272] - Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions. * [MCHANGES-275] - versionPrefix configurable by expression 'changes.versionPrefix' - 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: [VOTE] Apache Maven Compiler Plugin 2.4
+1 -Lukas Olivier Lamy wrote: Hi, I'd like to release Apache Maven Compiler Plugin 2.4. We fixed: 13 issues (http://s.apache.org/MCOMPILER-2.4) Staging repository: https://repository.apache.org/content/repositories/maven-008/ Staging site: http://maven.apache.org/plugins/maven-compiler-plugin-2.4 (wait sync). Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 2.4
+1 -Lukas Dennis Lundberg wrote: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=17454 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: https://repository.apache.org/content/repositories/maven-086/ Staging site: http://maven.apache.org/plugins/maven-site-plugin-2.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Invoker Plugin 1.6
See http://maven.apache.org/doxia/issues/index.html#Verbatim_blocks_not_boxed I have fixed the apt sources. Cheers, -Lukas Karl Heinz Marbaise wrote: Hi, i have checked the staged Site and observed that the frames around the source examples or code snippet are not there... For example if you compare http://maven.apache.org/plugins/maven-invoker-plugin-1.6/examples/invoker-properties.html http://maven.apache.org/plugins/maven-invoker-plugin/examples/invoker-properties.html I assume this is based on the staging site ? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 2.4
Hi, The newly added IT for MSITE-582 fails when run with maven 3.0.4. Not a blocking issue, since everything else works (site-plugin-2 with m2, site-plugin-3 with m2 3), but I'd like to understand why, if someone has a clue... -Lukas Dennis Lundberg wrote: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=17454 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: https://repository.apache.org/content/repositories/maven-086/ Staging site: http://maven.apache.org/plugins/maven-site-plugin-2.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Preparing for two releases of Maven Site Plugin
AbstractSiteMojo.isMaven3OrMore() is an example how to check if you're running maven 3. In any case, fixing this this would require a release of doxia-integration-tools-1.5. Or was that planned anyway? -Lukas Vincent Latombe wrote: On my side, I really would like to see MSITE-604 fixed, I've given it some thoughts today, and unfortunately I can only fix it for Maven 3, not for Maven 2 (because of MNG-1943 http://jira.codehaus.org/browse/MNG-1943that is only fixed with Maven 3). I've proposed a patch that is still work in progress (since I don't know a clean way to detect from this context whether we are in maven 2 or maven 3 context). Vincent 2012/4/20 Lukas Theusslltheu...@apache.org MSITE-601 is a wagon issue IIUC, the other issues can be delayed. Thanks Denis for doing this! -Lukas Robert Scholte wrote: Hi Dennis, I don't see any blockers in Jira, only one critical (MSITE-601) but this seems to be a rare case, so I'd prefer to push that one to a later release too. MSITE-582 is confirmed by Hervé, an IT has been added. I'd expect that the new Doxia versions should result in a very enhanced version of the m-site-p. I don't see issues I'd like to pick up for this release. -Robert Op Wed, 18 Apr 2012 22:01:43 +0200 schreef Dennis Lundberg denn...@apache.org: Hi, Now that the Doxia releases are done, I'd like to focus on Maven Site Plugin. We have two pending releases; 2.4 which will be the last release of the 2.x series and then 3.1. Looking in JIRA, all the issues scheduled for 2.4 have been fixed and closed. Does anyone want to add anything more to that release? If not, I'll prepare the 2.4 release this weekend. When we look at the 3.1 release in JIRA there are 5 scheduled issues that have not been solved. Here's a summary of them and how I'd like to handle them: MSITE-484 Support adding and overriding report plugins in new maven-site-plugin 3.x reportPlugins configuration format http://jira.codehaus.org/**browse/MSITE-484http://jira.codehaus.org/browse/MSITE-484 This is a major issue that might require changes to Maven core. Push it to later release. MSITE-582 Make it possible to remove breadcrumbs in child projects again http://jira.codehaus.org/**browse/MSITE-582http://jira.codehaus.org/browse/MSITE-582 Might already be solved. MSITE-596 inheritedReports IT fails http://jira.codehaus.org/**browse/MSITE-596http://jira.codehaus.org/browse/MSITE-596 Proposed solution requires changes to Maven core. Push to a later release, but document the current behavior as per Lukas' comment. MSITE-601 Period added to URL prevents proper cloning with Mercurial http://jira.codehaus.org/**browse/MSITE-601http://jira.codehaus.org/browse/MSITE-601 Unless someone has a patch for it, I'd like to unschedule it. MSITE-604 Properties from settings.xml are not recognized in site distribution management http://jira.codehaus.org/**browse/MSITE-604http://jira.codehaus.org/browse/MSITE-604 This is strangely related to MSITE-632, but I cannot find a suitable solution to either of them. Push to a later release. Do we want to add any more issues to the 3.1 release? Please comment on this. --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-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: Preparing for two releases of Maven Site Plugin
MSITE-601 is a wagon issue IIUC, the other issues can be delayed. Thanks Denis for doing this! -Lukas Robert Scholte wrote: Hi Dennis, I don't see any blockers in Jira, only one critical (MSITE-601) but this seems to be a rare case, so I'd prefer to push that one to a later release too. MSITE-582 is confirmed by Hervé, an IT has been added. I'd expect that the new Doxia versions should result in a very enhanced version of the m-site-p. I don't see issues I'd like to pick up for this release. -Robert Op Wed, 18 Apr 2012 22:01:43 +0200 schreef Dennis Lundberg denn...@apache.org: Hi, Now that the Doxia releases are done, I'd like to focus on Maven Site Plugin. We have two pending releases; 2.4 which will be the last release of the 2.x series and then 3.1. Looking in JIRA, all the issues scheduled for 2.4 have been fixed and closed. Does anyone want to add anything more to that release? If not, I'll prepare the 2.4 release this weekend. When we look at the 3.1 release in JIRA there are 5 scheduled issues that have not been solved. Here's a summary of them and how I'd like to handle them: MSITE-484 Support adding and overriding report plugins in new maven-site-plugin 3.x reportPlugins configuration format http://jira.codehaus.org/browse/MSITE-484 This is a major issue that might require changes to Maven core. Push it to later release. MSITE-582 Make it possible to remove breadcrumbs in child projects again http://jira.codehaus.org/browse/MSITE-582 Might already be solved. MSITE-596 inheritedReports IT fails http://jira.codehaus.org/browse/MSITE-596 Proposed solution requires changes to Maven core. Push to a later release, but document the current behavior as per Lukas' comment. MSITE-601 Period added to URL prevents proper cloning with Mercurial http://jira.codehaus.org/browse/MSITE-601 Unless someone has a patch for it, I'd like to unschedule it. MSITE-604 Properties from settings.xml are not recognized in site distribution management http://jira.codehaus.org/browse/MSITE-604 This is strangely related to MSITE-632, but I cannot find a suitable solution to either of them. Push to a later release. Do we want to add any more issues to the 3.1 release? Please comment on this. - 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: [VOTE] Release Maven Doxia Sitetools version 1.3
+1 -Lukas Dennis Lundberg wrote: Hi, We solved 12 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624styleName=Htmlversion=13714 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11624status=1 Staging repo: https://repository.apache.org/content/repositories/maven-044/ Staging site: http://maven.apache.org/doxia/doxia-sitetools-1.3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Doxia version 1.3
+1 -Lukas Dennis Lundberg wrote: Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleName=Htmlversion=17336 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780status=1 Staging repo: https://repository.apache.org/content/repositories/maven-031/ Staging site: http://maven.apache.org/doxia/doxia-1.3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Reporting Executor version 1.0.2
+1 -Lukas Dennis Lundberg wrote: Hi, This is the first in a series of release culminating with the release of Maven Site Plugin 3.1. We solved 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17469 There are no issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761status=1component=14716 Staging repo: https://repository.apache.org/content/repositories/maven-019/ Staging site: http://maven.apache.org/shared/maven-reporting-exec-1.0.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
Hervé BOUTEMY wrote: ok so: 1. doxia-book from Doxia to Doxia Sitetools, same artifact coordinates: org.apache.maven.doxia:doxia-book, 1.2 is from Doxia tree, 1.3-SNAPSHOT will be from Doxia Sitetools 2. doxia-maven-plugin from Doxia to Doxia Tools, same artifact coordinates: org.apache.maven.doxia:doxia-maven-plugin 1.2 is from Doxia tree, 1.3-SNAPSHOT will be from Doxia Tools The other way round was it? doxia-book into Doxia Tools and doxia-maven-plugin into Sitetools. -Lukas 3. maven-doxia-tools from Maven Shared to Doxia Sitetools, changing artifact coordinates from org.apache.maven.shared:maven-doxia-tools to org.apache.maven.doxia:maven-doxia-tools Notice: the actual name in pom [1] is Maven Doxia Integration Tools, changing the artifactId to maven-doxia-integration-tools would be more complete but IMHO somewhat verbose doxia-test-docs is another story I still don't fully understand, it stays for the moment in Doxia: we can have another look at it after previous changes Regards, Hervé [1] http://maven.apache.org/shared/maven-doxia-tools/project-summary.html Le vendredi 30 mars 2012 10:07:16 Lukas Theussl a écrit : Dennis Lundberg wrote: On 2012-03-29 09:13, Lukas Theussl wrote: I agree that they don't belong into core, but I rather thought of moving them into doxia-tools instead. Not sure what is better. This was my thought also. OTOH, neither book nor maven-plugin have been maintained (AFAIK) since they were moved out of the sandbox, and IMO they don't work too well. In particular there are problems reported with Maven 3 (DOXIA-438) which I haven't tested, but I wanted to suggest a long time ago to deprecate and ultimately remove them. If agree that they should be moved, let's start with that. If the target is doxia-tools then let's move them there, prior to the 1.3 release of Doxia and Doxia Sitetools. My feeling about Doxia Tools is that their sub projects shouldn't be released all at the same time. They are individual projects and should have their own release cycles, much like our shared components or plugins. I agree for doxia-tools. Doxia and doxia-sitetools are closer coupled though, I think they should be released together. Maybe the doxia-maven-plugin should go into sitetools, and the book into tools? Also I'd like to move maven-doxia-tools from shared over to Doxia. Given its description Assists in using Doxia for site generation and report creation. Don't know where you got that from, the current pom [1] says A collection of tools to help the integration of Doxia in Maven plugins. I think we also talked about renaming it to 'doxia-integration-tools' which sounds more descriptive. [1] http://svn.apache.org/viewvc/maven/shared/trunk/maven-doxia-tools/pom.xml?re vision=1214494view=markup I think that Sitetools would be a good home for it. Sounds reasonable. Also the doxia-test-docs should move somewhere else. What are those? They look like they could be the basis of an IT suite. Perhaps it should be a completely separate project under the Doxia umbrella? It's not a project actually, just a collection of test resources. They were originally added to check the correctness of the XSDs, see this mail thread: http://mail-archives.apache.org/mod_mbox/maven-doxia-dev/200812.mbox/%3C493D 50DF.3040705%40udo.edu%3E It's currently used by xdoc and fml modules, however, I'm not sure of the usefulness, see eg my comment in XdocValidatorTest#testValidateFiles. IMO the validation test would be useful if it tested either a new xsd against the old test files, or some new test files (created by a new doxia module) against the existing xsd. But currently the test takes the old test files (from test-docs) and validates it with the established xsds (fml-1.0-1, xdoc-2.2), so I don't see the point. Just some thoughts, unfortunately I don't have time right now to help with any 'real' work... -Lukas -Lukas Hervé BOUTEMY wrote: while working on the relations between components, I finally found why there was something I didn't understand for a long time about Doxia suite structure: Doxia base contains book support through a plugin, but Doxia base doesn't contain documents support -- it's Doxia Sitetools. So we have a circular dependency: doxia-maven-plugin (from Doxia base) -maven-doxia-tools - Doxia-decoration- model (from Doxia SiteTools) -Doxia base (xhtml, fo and itext) IMHO, doxia-book and doxia-maven-plugin should move to Doxia Sitetools [1]. This won't change the artifacts coordinate, so won't change anything for users. But this should help when explaining Doxia suite structure, which has been difficult for a long time, and having a consequence on versioning decision: should we keep base and Sitetools version at the same level or not? Any objection? Did I miss something? Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html
Re: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
Hervé BOUTEMY wrote: Le samedi 31 mars 2012 08:24:50 Lukas Theussl a écrit : The other way round was it? doxia-book into Doxia Tools and doxia-maven-plugin into Sitetools. -Lukas no, Tools can depend on Sitetools, but not the other way Right, didn't think about the dependencies. I'd move both to Tools then, that way they can have independent releases from doxia/sitetools. -Lukas the other ways would be do move both modules to Tools or Sitetools but not doxia-book to Tools and doxia-maven-plugin to Sitetools Regards, Hervé - 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: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
Why do you want to remove doxia-tools? I like the idea to have all the independent apps collected in one folder. Also, I think the original reason for maven-doxia-tools to go into shared was to de-couple it from doxia, so it could be released independently. I would prefer to leave it outside doxia/doxia-sitetools. Here's my bid: doxia +-- doxia-base (was doxia) +-- doxia-core +-- doxia-logging-api +-- doxia-modules +-- doxia-sink-api +-- doxia-test-docs (stays here for now) +-- doxia-sitetools +-- doxia-decoration-model +-- doxia-doc-renderer +-- doxia-site-renderer +-- doxia-tools +-- doxia-book-renderer (was doxia/doxia-book) +-- doxia-book-maven-plugin (was doxia/doxia-maven-plugin) +-- doxia-converter +-- doxia-ide (moved here from root) +-- doxia-linkcheck +-- doxia-integration-tools (was shared/maven-doxia-tools) Cheers, -Lukas Dennis Lundberg wrote: Hi guys Here's an attempt to summarize this discussion and also add some of my personal preference. This is how I want the directory structure, which matches the inheritance structure, to be doxia +-- doxia-base (was doxia) +-- doxia-core +-- doxia-logging-api +-- doxia-modules +-- doxia-sink-api +-- doxia-test-docs (stays here for now) +-- doxia-sitetools +-- doxia-decoration-model +-- doxia-doc-renderer +-- doxia-integration-tools (was shared/maven-doxia-tools) +-- doxia-linkcheck (moved here from doxia-tools) +-- doxia-site-renderer +-- doxia-book-renderer (was doxia/doxia-book) +-- doxia-book-maven-plugin (was doxia/doxia-maven-plugin) +-- doxia-converter (moved here from doxia-tools) +-- doxia-ide a. Rebrand Doxia to Doxia base to differentiate it from Doxia - the umbrella. We do not change the groupId. b. doxia-test-docs stays where it is for now, until someone has the time to look at it c. shared/maven-doxia-tools moves to doxia-sitetools/doxia-integration-tools. We should change the artifactId and groupId now, because the current version of shared/maven-doxia-tools is 1.4, but the new one will be 1.3. d. In order to completely remove the psuedo-umbrella project doxia-tools we move doxia-converter to the root and doxia-linkcheck to doxia-sitetools. Another alternative is to move doxia-linkcheck to root. e. doxia-book and doxia-maven-plugin work together, but should be allowed to have independent release cycles, so they both move from doxia to the root. I also suggest changing their names to better reflect what they do. doxia-book therefor becomes doxia-book-renderer and doxia-maven-plugin becomes doxia-book-maven-plugin. This change should include changing the artifactId for both of them. Do we agree on this? On 2012-03-31 08:55, Lukas Theussl wrote: Hervé BOUTEMY wrote: Le samedi 31 mars 2012 08:24:50 Lukas Theussl a écrit : The other way round was it? doxia-book into Doxia Tools and doxia-maven-plugin into Sitetools. -Lukas no, Tools can depend on Sitetools, but not the other way Right, didn't think about the dependencies. I'd move both to Tools then, that way they can have independent releases from doxia/sitetools. -Lukas the other ways would be do move both modules to Tools or Sitetools but not doxia-book to Tools and doxia-maven-plugin to Sitetools Regards, Hervé - 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: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
Dennis Lundberg wrote: On 2012-03-31 14:31, Lukas Theussl wrote: Why do you want to remove doxia-tools? I like the idea to have all the independent apps collected in one folder. There are two problems as I see it: 1. It looks like an umbrella for releasing several modules at once, but in reality the modules each have their individual release cycles. The doxia-tools pom should be just an aggregator, not a parent pom. I'd just like a separate directory for these independent projects, as they are not at the same level of importance as the other root projects. 2. We have some troubling naming conflicts. We have: - doxia-sitetools - doxia-tools - maven-doxia-tools Removing doxia-tools would make this at least a little better. I agree. We could call it something else, say doxia-apps? -Lukas Do you see any problem moving them to the root? They'd all just inherit from the maven-parent pom, instead of from the doxia-tools pom. That means one less pom to maintain. Also, I think the original reason for maven-doxia-tools to go into shared was to de-couple it from doxia, so it could be released independently. I would prefer to leave it outside doxia/doxia-sitetools. That's fine with me, although I would prefer to put it at the root for the reasons I explained above. Here's my bid: doxia +-- doxia-base (was doxia) +-- doxia-core +-- doxia-logging-api +-- doxia-modules +-- doxia-sink-api +-- doxia-test-docs (stays here for now) +-- doxia-sitetools +-- doxia-decoration-model +-- doxia-doc-renderer +-- doxia-site-renderer +-- doxia-tools +-- doxia-book-renderer (was doxia/doxia-book) +-- doxia-book-maven-plugin (was doxia/doxia-maven-plugin) +-- doxia-converter +-- doxia-ide (moved here from root) +-- doxia-linkcheck +-- doxia-integration-tools (was shared/maven-doxia-tools) The only thing we seem to not agree on, is whether to keep the doxia-tools directory or not. Apart from that I'm fine with your bid. Cheers, -Lukas Dennis Lundberg wrote: Hi guys Here's an attempt to summarize this discussion and also add some of my personal preference. This is how I want the directory structure, which matches the inheritance structure, to be doxia +-- doxia-base (was doxia) +-- doxia-core +-- doxia-logging-api +-- doxia-modules +-- doxia-sink-api +-- doxia-test-docs (stays here for now) +-- doxia-sitetools +-- doxia-decoration-model +-- doxia-doc-renderer +-- doxia-integration-tools (was shared/maven-doxia-tools) +-- doxia-linkcheck (moved here from doxia-tools) +-- doxia-site-renderer +-- doxia-book-renderer (was doxia/doxia-book) +-- doxia-book-maven-plugin (was doxia/doxia-maven-plugin) +-- doxia-converter (moved here from doxia-tools) +-- doxia-ide a. Rebrand Doxia to Doxia base to differentiate it from Doxia - the umbrella. We do not change the groupId. b. doxia-test-docs stays where it is for now, until someone has the time to look at it c. shared/maven-doxia-tools moves to doxia-sitetools/doxia-integration-tools. We should change the artifactId and groupId now, because the current version of shared/maven-doxia-tools is 1.4, but the new one will be 1.3. d. In order to completely remove the psuedo-umbrella project doxia-tools we move doxia-converter to the root and doxia-linkcheck to doxia-sitetools. Another alternative is to move doxia-linkcheck to root. e. doxia-book and doxia-maven-plugin work together, but should be allowed to have independent release cycles, so they both move from doxia to the root. I also suggest changing their names to better reflect what they do. doxia-book therefor becomes doxia-book-renderer and doxia-maven-plugin becomes doxia-book-maven-plugin. This change should include changing the artifactId for both of them. Do we agree on this? On 2012-03-31 08:55, Lukas Theussl wrote: Hervé BOUTEMY wrote: Le samedi 31 mars 2012 08:24:50 Lukas Theussl a écrit : The other way round was it? doxia-book into Doxia Tools and doxia-maven-plugin into Sitetools. -Lukas no, Tools can depend on Sitetools, but not the other way Right, didn't think about the dependencies. I'd move both to Tools then, that way they can have independent releases from doxia/sitetools. -Lukas the other ways would be do move both modules to Tools or Sitetools but not doxia-book to Tools and doxia-maven-plugin to Sitetools Regards, Hervé - 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
Re: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
Dennis Lundberg wrote: On 2012-03-29 09:13, Lukas Theussl wrote: I agree that they don't belong into core, but I rather thought of moving them into doxia-tools instead. Not sure what is better. This was my thought also. OTOH, neither book nor maven-plugin have been maintained (AFAIK) since they were moved out of the sandbox, and IMO they don't work too well. In particular there are problems reported with Maven 3 (DOXIA-438) which I haven't tested, but I wanted to suggest a long time ago to deprecate and ultimately remove them. If agree that they should be moved, let's start with that. If the target is doxia-tools then let's move them there, prior to the 1.3 release of Doxia and Doxia Sitetools. My feeling about Doxia Tools is that their sub projects shouldn't be released all at the same time. They are individual projects and should have their own release cycles, much like our shared components or plugins. I agree for doxia-tools. Doxia and doxia-sitetools are closer coupled though, I think they should be released together. Maybe the doxia-maven-plugin should go into sitetools, and the book into tools? Also I'd like to move maven-doxia-tools from shared over to Doxia. Given its description Assists in using Doxia for site generation and report creation. Don't know where you got that from, the current pom [1] says A collection of tools to help the integration of Doxia in Maven plugins. I think we also talked about renaming it to 'doxia-integration-tools' which sounds more descriptive. [1] http://svn.apache.org/viewvc/maven/shared/trunk/maven-doxia-tools/pom.xml?revision=1214494view=markup I think that Sitetools would be a good home for it. Sounds reasonable. Also the doxia-test-docs should move somewhere else. What are those? They look like they could be the basis of an IT suite. Perhaps it should be a completely separate project under the Doxia umbrella? It's not a project actually, just a collection of test resources. They were originally added to check the correctness of the XSDs, see this mail thread: http://mail-archives.apache.org/mod_mbox/maven-doxia-dev/200812.mbox/%3C493D50DF.3040705%40udo.edu%3E It's currently used by xdoc and fml modules, however, I'm not sure of the usefulness, see eg my comment in XdocValidatorTest#testValidateFiles. IMO the validation test would be useful if it tested either a new xsd against the old test files, or some new test files (created by a new doxia module) against the existing xsd. But currently the test takes the old test files (from test-docs) and validates it with the established xsds (fml-1.0-1, xdoc-2.2), so I don't see the point. Just some thoughts, unfortunately I don't have time right now to help with any 'real' work... -Lukas -Lukas Hervé BOUTEMY wrote: while working on the relations between components, I finally found why there was something I didn't understand for a long time about Doxia suite structure: Doxia base contains book support through a plugin, but Doxia base doesn't contain documents support -- it's Doxia Sitetools. So we have a circular dependency: doxia-maven-plugin (from Doxia base) - maven-doxia-tools - Doxia-decoration- model (from Doxia SiteTools) - Doxia base (xhtml, fo and itext) IMHO, doxia-book and doxia-maven-plugin should move to Doxia Sitetools [1]. This won't change the artifacts coordinate, so won't change anything for users. But this should help when explaining Doxia suite structure, which has been difficult for a long time, and having a consequence on versioning decision: should we keep base and Sitetools version at the same level or not? Any objection? Did I miss something? Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html - 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: [PROPOSAL] Merge the Doxia site into the Maven site
Hervé BOUTEMY wrote:
yes, that's what I meant
my point is that it is then published only on release: either we wait for next
release, or we copy the actual report by hand as if it was generated during
the 1.2 release
I don't get the point: the jira report is always generated for a given
release (not the current development version) as configured in the
report, so it can always be re-generated.
Cheers,
-Lukas
Regards,
Hervé
Le mercredi 28 mars 2012 21:36:47 Dennis Lundberg a écrit :
On 2012-03-28 08:35, Lukas Theussl wrote:
The JIRA report should go into the doxia sub-site (and corresponding
doxia-sitetools, etc), then you link to that from the base site for each
sub-project. WDYT?
Yup, that sounds like a good plan.
-Lukas
Hervé BOUTEMY wrote:
notice that I tried to commit improvements based on previous thoughts
and found in index.apt.vm the following link:
{{{./jira-report.html}Release Notes
for ${doxiaVersion}}}
And since the Jira report isn't available in Doxia base site, if you
simply
remove the actual JIRA report from Doxia site, we're stuck: we need to
add the
report to Doxia base and publish it (either manually for 1.2 or wait
for
1.3)
Regards
Hervé
Le mercredi 28 mars 2012 07:11:00 Hervé BOUTEMY a écrit :
The Doxia site expert is Vincent Siveton: I hope he can express his
opinion
Doxia (base + sitetools + tools) deserves IMHO the dedicated menus
from the
actual Doxia site [1] to let people understand: it can/should be
improved,
but if we merge the Doxia site with regular Maven site, we loose
this
dedicated menu: I don't think this will help.
But you're right with the JIRA report being inappropriate: Doxia
site
doesn't cover only Doxia base, which is [2].
I'm sure that this menu could be made more explicit to help people
understand the relation between Doxia site and each 3 components:
removing
the JIRA configuration is the first step.
Since infra hasn't problems with having a few number of sub-sites
being
treated as dedicated CMS site, I don't see any problem with
maintaining
Doxia site.
To sum up:
- +1 to JIRA configuration removel from Doxia site
- -1 to merging into Maven regular site
Regards,
Hervé
[1] http://maven.apache.org/doxia/index.html
[2] http://maven.apache.org/doxia/doxia/index.html
Le lundi 26 mars 2012 22:13:17 Dennis Lundberg a écrit :
Hi
When I saw some of the commits by Hervé on the CMS integration it
hit
me: Why do we have a separate site module for the Doxia site?
Unless there are any difficult technical hurdles standing in the
way,
why don't we just merge it into the regular Maven site?
I had a quick look at the POM and the only odd things in there is
a
configuration snippet for doxia-maven-plugin that is injected into
the
generated site somewhere, as well as creating some output files
(RTF
and
PDF) from a Doxia book example which are then copied to the
generated
site using maven-antrun-plugin.
There's also a JIRA report in the Doxia site, which in my opinion
is
wrong since Doxia is not one project anymore but rather an
umbrella
like
Plugins or Shared. So the solution would be to remove the report
from
the site and add it to the project sites of Doxia, Doxia Site
Tools and Doxia Tools.
Thoughts?
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
I agree that they don't belong into core, but I rather thought of moving them into doxia-tools instead. Not sure what is better. OTOH, neither book nor maven-plugin have been maintained (AFAIK) since they were moved out of the sandbox, and IMO they don't work too well. In particular there are problems reported with Maven 3 (DOXIA-438) which I haven't tested, but I wanted to suggest a long time ago to deprecate and ultimately remove them. Also the doxia-test-docs should move somewhere else. -Lukas Hervé BOUTEMY wrote: while working on the relations between components, I finally found why there was something I didn't understand for a long time about Doxia suite structure: Doxia base contains book support through a plugin, but Doxia base doesn't contain documents support -- it's Doxia Sitetools. So we have a circular dependency: doxia-maven-plugin (from Doxia base) - maven-doxia-tools - Doxia-decoration- model (from Doxia SiteTools) - Doxia base (xhtml, fo and itext) IMHO, doxia-book and doxia-maven-plugin should move to Doxia Sitetools [1]. This won't change the artifacts coordinate, so won't change anything for users. But this should help when explaining Doxia suite structure, which has been difficult for a long time, and having a consequence on versioning decision: should we keep base and Sitetools version at the same level or not? Any objection? Did I miss something? Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html - 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: [PROPOSAL] Merge the Doxia site into the Maven site
The JIRA report should go into the doxia sub-site (and corresponding
doxia-sitetools, etc), then you link to that from the base site for each
sub-project. WDYT?
-Lukas
Hervé BOUTEMY wrote:
notice that I tried to commit improvements based on previous thoughts and
found in index.apt.vm the following link: {{{./jira-report.html}Release Notes
for ${doxiaVersion}}}
And since the Jira report isn't available in Doxia base site, if you simply
remove the actual JIRA report from Doxia site, we're stuck: we need to add the
report to Doxia base and publish it (either manually for 1.2 or wait for
1.3)
Regards
Hervé
Le mercredi 28 mars 2012 07:11:00 Hervé BOUTEMY a écrit :
The Doxia site expert is Vincent Siveton: I hope he can express his opinion
Doxia (base + sitetools + tools) deserves IMHO the dedicated menus from the
actual Doxia site [1] to let people understand: it can/should be improved,
but if we merge the Doxia site with regular Maven site, we loose this
dedicated menu: I don't think this will help.
But you're right with the JIRA report being inappropriate: Doxia site
doesn't cover only Doxia base, which is [2].
I'm sure that this menu could be made more explicit to help people
understand the relation between Doxia site and each 3 components: removing
the JIRA configuration is the first step.
Since infra hasn't problems with having a few number of sub-sites being
treated as dedicated CMS site, I don't see any problem with maintaining
Doxia site.
To sum up:
- +1 to JIRA configuration removel from Doxia site
- -1 to merging into Maven regular site
Regards,
Hervé
[1] http://maven.apache.org/doxia/index.html
[2] http://maven.apache.org/doxia/doxia/index.html
Le lundi 26 mars 2012 22:13:17 Dennis Lundberg a écrit :
Hi
When I saw some of the commits by Hervé on the CMS integration it hit
me: Why do we have a separate site module for the Doxia site?
Unless there are any difficult technical hurdles standing in the way,
why don't we just merge it into the regular Maven site?
I had a quick look at the POM and the only odd things in there is a
configuration snippet for doxia-maven-plugin that is injected into the
generated site somewhere, as well as creating some output files (RTF and
PDF) from a Doxia book example which are then copied to the generated
site using maven-antrun-plugin.
There's also a JIRA report in the Doxia site, which in my opinion is
wrong since Doxia is not one project anymore but rather an umbrella like
Plugins or Shared. So the solution would be to remove the report from
the site and add it to the project sites of Doxia, Doxia Site Tools and
Doxia Tools.
Thoughts?
-
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: r1293991 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Salut Herve,
Just a comment: my IDE (netbeans) now shows a javadoc error because the
{@inheritDoc} doesn't pick up the description of the corresponding
parameter. Could the parameter name be changed in the interface as well?
-Lukas
hbout...@apache.org wrote:
Author: hboutemy
Date: Mon Feb 27 01:34:11 2012
New Revision: 1293991
URL: http://svn.apache.org/viewvc?rev=1293991view=rev
Log:
renamed parameter for better understanding
Modified:
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Modified:
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
URL:
http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java?rev=1293991r1=1293990r2=1293991view=diff
==
---
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
(original)
+++
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Mon Feb 27 01:34:11 2012
@@ -334,7 +334,7 @@ public class DefaultSiteRenderer
}
/** {@inheritDoc} */
-public void renderDocument( Writer writer, RenderingContext
renderingContext, SiteRenderingContext context )
+public void renderDocument( Writer writer, RenderingContext
renderingContext, SiteRenderingContext siteContext )
throws RendererException, FileNotFoundException,
UnsupportedEncodingException
{
SiteRendererSink sink = new SiteRendererSink( renderingContext );
@@ -355,14 +355,14 @@ public class DefaultSiteRenderer
{
SiteResourceLoader.setResource( resource );
-Context vc = createVelocityContext( sink, context );
+Context vc = createVelocityContext( sink, siteContext );
StringWriter sw = new StringWriter();
-velocity.getEngine().mergeTemplate( resource,
context.getInputEncoding(), vc, sw );
+velocity.getEngine().mergeTemplate( resource,
siteContext.getInputEncoding(), vc, sw );
reader = new StringReader( sw.toString() );
-if ( parser.getType() == Parser.XML_TYPE
context.isValidate() )
+if ( parser.getType() == Parser.XML_TYPE
siteContext.isValidate() )
{
reader = validate( reader, resource );
}
@@ -385,7 +385,7 @@ public class DefaultSiteRenderer
{
case Parser.XML_TYPE:
reader = ReaderFactory.newXmlReader( doc );
-if ( context.isValidate() )
+if ( siteContext.isValidate() )
{
reader = validate( reader, resource );
}
@@ -394,7 +394,7 @@ public class DefaultSiteRenderer
case Parser.TXT_TYPE:
case Parser.UNKNOWN_TYPE:
default:
-reader = ReaderFactory.newReader( doc,
context.getInputEncoding() );
+reader = ReaderFactory.newReader( doc,
siteContext.getInputEncoding() );
}
}
sink.enableLogging( new PlexusLoggerWrapper( getLogger() ) );
@@ -422,7 +422,7 @@ public class DefaultSiteRenderer
IOUtil.close( reader );
}
-generateDocument( writer, sink, context );
+generateDocument( writer, sink, siteContext );
}
private Context createVelocityContext( SiteRendererSink sink,
SiteRenderingContext siteRenderingContext )
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Inconsistent newlines in site output
Benson Margulies wrote: The maven-project-info-reports-plugin generates files with 'inconsistent newlines'. Is it worthwhile to try to fix this, or is it the beginning of an unbounded collection of other examples. Shooting from the hip I would guess the latter. I know I started investigating it once but don't remember all the details, see eg http://jira.codehaus.org/browse/MSITE-121 and linked issues. -Lukas - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [site] site.xml head/footer inheritance
A quick look at the source code shows that the footer is not taken care of in doxia-decoration-model's DefaultDecorationModelInheritanceAssembler. The footer was only introduced in the last doxia release and this was apparently overlooked. So the only thing to do is file an issue... :) -Lukas Simone Tripodi wrote: Hi all guys, I am having troubles with the skin (lst check before re-proposing the skins releases) and while trying to apply fluido on Apache Commons I noticed that, attaching a site.xml descriptor to a parent, while the body.head element is inherited from cildren, body.footer is not. Did I miss something or this is the right behavior? Is there something to set or I have to provide an additional feature to the skin? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [site] missing project name prefix in title in the generated page
Which version of site-plugin-2.x are you comparing with? I would expect 2.3 to be equivalent with 3.0. -Lukas Simone Tripodi wrote: Hi all guys, while redeploying the Cocoon3 site, using mvn3+site-plugin:3.0, I noticed a big difference in the generated page using mvn2+site-plugin:2.X, indeed the old tools used the project name defined in site.xml, i.e project name=Cocoon 3 ... /project to put as a prefix in generated page, i.e. html head titleCocoon 3 - ... [...] using the new tools, that doesn't happen. Did I miss something in the changelist or it is a known feature/bug? Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: Syntax coloured code snippets in Site - existing or DYO
Hi Lennart, Thanks for picking this up! Personally I don't like either of the two solutions you propose... :p The APT format was above all designed to be simple, which necessarily implies some functional limitations. Eg it is on purpose that APT does not support styles [1], if any fancy layout features are required, like the one we are talking about here, I would always recommend to use something else than APT (xdoc,...). Also, changing/enhancing a well-established format spec like APT is likely to cause disturbance, we did it once with the Doxia 1.1 release [2], and frankly, I wouldn't do it again. See further comments in-line below. Cheers, -Lukas [1] http://maven.apache.org/doxia/faq.html#How_to_handle_style_in_the_APT_markup_language [2] http://maven.apache.org/doxia/references/doxia-apt.html Lennart Jörelid wrote: Hello Lukas, A question here... It seems simple enough to add the required constants conveying the choice to provide syntax coloring or line number visibility to Doxia's SinkEventAttributes. It also seems simple enough to make a smallish change to the core SinkAdapter, to recognize more properties than the boxed attribute, and to propagate this change to all relevant doxia modules. These changes caters for the need to convey the semantics of some extra properties to all modules. Fair enough. However, each module interested in interpreting these new attributes in a meaningful way must have some means to configure them in its native markup. According to the SunkUtils class, code of all kinds is rendered within div or pre tags - implying Verbatim SinkEventAttributes. Confused here what you are referring to,.. the SinkUtils class doesn't mention anything like that AFAICS and div and pre are html specific, so shouldn't occur anywhere in the generic Sink API. While the documentation for SinkEventAttributes.DECORATION claims that 'Generally accepted values are underline, overline, line-through, boxed', the SinkAdapter.verbatim() method in its current form only recognizes the value boxed. To provide the ability to set optional properties (boxed, syntaxColored, lineNumbersVisible), one could simply create more SinkEventAttributes values. No biggie. Note that the SinkAdapter class is just an empty base implementation, it gets overridden by practically all low-level Sinks, see eg the XhtmlBaseSink. But ... taking the APT module (which seems a decently frequently used one) as an example, we have 2 choices for markup alterations: a) Permutations of the currently available one, or b) Mutator elements within the verbatim block If we choose (a), we end up with several markup permutations (with/without syntax coloring; with/without line numbers displayed). Currently, the only two choices in the AptMarkup interface are BOXED_VERBATIM_START_MARKUP (+--+) and HEADER_START_MARKUP ( -). What seems the dim way to solve the problem would then be simply creating several new markup starts along the lines of: /** Syntax for the boxed verbatim start, indicating syntax coloring should be used: +c-+ */ String BOXED_VERBATIM_WITH_SYNTAX_COLORING_START_MARKUP = String.valueOf( PLUS ) + StringUtils.repeat( String.valueOf( MINUS ), 6 ) + String.valueOf( PLUS ); /** Syntax for the boxed verbatim start, indicating line numbers should be used: +cl+ */ String BOXED_VERBATIM_WITH_LINE_NUMBERS_START_MARKUP = String.valueOf( PLUS ) + StringUtils.repeat( String.valueOf( MINUS ), 6 ) + String.valueOf( PLUS ); If we choose (b), we would be required to introduce mutators within the verbatim markup elements - something along the lines of: +--+ [option: [displayLineNumbers] [useSyntaxColoring]] ... code goes here ... +--+ I prefer the latter solution, and I hope to be able to grab the last part of the start line within the APT module given a small tweak to the AptSink in order for it not to use the verbatim(boolean) method. Do you have comments or suggestions for me so far? 2011/11/26 Lukas Theusslltheu...@apache.org There is a feature request for that: https://jira.codehaus.org/browse/DOXIA-439 It's not implemented yet... HTH, -Lukas On Sat, Nov 26, 2011 at 2:16 AM, Lennart Jörelid lennart.jore...@gmail.comwrote: Hello Simone, Looking good. So ... given that this is a skin to maven, could you include the CSS and JS of the syntax highlighter (i.e. http://alexgorbatchev.com/SyntaxHighlighter/ )? However, I guess my question is on a more fundamental level. What do we need to do in an APT file (or one of the other site documentation format files) to achieve pretty-printed/syntax colored source snippets in Java or XML? There seems to be no mention of exactly how to craft code snippet examples - as far as I can see - on the http://maven.apache.org/doxia/references/doxia-apt.html (and friends) pages. 2011/11/26 Simone Tripodisimonetrip...@apache.org Hi Lennart, we are going to release the
Re: Syntax coloured code snippets in Site - existing or DYO
There is a feature request for that: https://jira.codehaus.org/browse/DOXIA-439 It's not implemented yet... HTH, -Lukas On Sat, Nov 26, 2011 at 2:16 AM, Lennart Jörelid lennart.jore...@gmail.comwrote: Hello Simone, Looking good. So ... given that this is a skin to maven, could you include the CSS and JS of the syntax highlighter (i.e. http://alexgorbatchev.com/SyntaxHighlighter/ )? However, I guess my question is on a more fundamental level. What do we need to do in an APT file (or one of the other site documentation format files) to achieve pretty-printed/syntax colored source snippets in Java or XML? There seems to be no mention of exactly how to craft code snippet examples - as far as I can see - on the http://maven.apache.org/doxia/references/doxia-apt.html (and friends) pages. 2011/11/26 Simone Tripodi simonetrip...@apache.org Hi Lennart, we are going to release the maven-fluido-skin[1] that does also code prettyprint ans syntax highlight. HTH! Simo [1] http://maven.apache.org/skins/maven-fluido-skin/ http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Nov 26, 2011 at 1:15 AM, Lennart Jörelid lennart.jore...@gmail.com wrote: Hello folks, I need to include some pretty-printed and syntax coloured code snippets into the maven site of a set of projects. After a tad of searching, I haven't found any plugin or extension to Doxia that seems to do this. There seems to be several box text and don't ruin its formatting-type tags and operations - but I would like to pretty print and syntax colour both Java and XML files. ... and I suppose this is fixed by some nice doxia-based utility already. Could you point me in the correct direction? // Bästa hälsningar, // [sw. Best regards // // Lennart Jörelid // lennart.jore...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- Lennart Jörelid
Re: What is the status on doxia 1.3 (a.k.a. when will we have markdown support released)
Have you actually tested the doxia markdown module? It's new and not yet complete IMO (see http://jira.codehaus.org/browse/DOXIA-436). OTOH, xdoc is well supported and tested, especially with the new doxia 1.1 API. If it's just for one page, I would go for xdoc. -Lukas On 11/23/2011 09:59 AM, Stephen Connolly wrote: Yes but you _can_ include pure HTML... and to make a home page that is like openejb's being able to put in html where you need it can help, while the rest of the content can be kept in a nice plain text format... whereas going the xdoc route means that the whole page is xml-ized rather than just the one section that we'd want 3-column 2011/11/23 Arnaud Héritieraherit...@gmail.com: AFAIK we can do less things in Markdown than existing APT and others For example Markdown doesn't allow to create tables. You have to include pure HTML to do them. Arnaud On Wed, Nov 23, 2011 at 9:50 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Just a query as I suspect markdown would help with the new fluido skin for doing a fancier front page... - 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: What is the status on doxia 1.3 (a.k.a. when will we have markdown support released)
I moved it out of the sandbox after a standard set of test cases was supplied, as documented at http://jira.codehaus.org/browse/DOXIA-426. So the module should be functional for basic purposes, but it hasn't been hard-core tested (or tested at all AFAIK) for anything else. Also, fixing DOXIA-436 is likely to bring some change in behaviour, so it's not yet stable is all I'm saying. OTOH, the maven home page would be a good test bed I suppose... ;) -Lukas On 11/23/2011 10:49 AM, Stephen Connolly wrote: I have not tested it at all I was under the impression that if it had been moved from sandbox to trunk it might have had some testing! ;-) Of course assume makes an ass of u and me On 23 November 2011 09:45, Lukas Theusslltheu...@apache.org wrote: Have you actually tested the doxia markdown module? It's new and not yet complete IMO (see http://jira.codehaus.org/browse/DOXIA-436). OTOH, xdoc is well supported and tested, especially with the new doxia 1.1 API. If it's just for one page, I would go for xdoc. -Lukas On 11/23/2011 09:59 AM, Stephen Connolly wrote: Yes but you _can_ include pure HTML... and to make a home page that is like openejb's being able to put in html where you need it can help, while the rest of the content can be kept in a nice plain text format... whereas going the xdoc route means that the whole page is xml-ized rather than just the one section that we'd want 3-column 2011/11/23 Arnaud Héritieraherit...@gmail.com: AFAIK we can do less things in Markdown than existing APT and others For example Markdown doesn't allow to create tables. You have to include pure HTML to do them. Arnaud On Wed, Nov 23, 2011 at 9:50 AM, Stephen Connolly stephen.alan.conno...@gmail.comwrote: Just a query as I suspect markdown would help with the new fluido skin for doing a fancier front page... - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [site] #evaluate Velocity macro ignored
It's been a while for me but I remember I ran into several issues when trying to upgrade to a newer velocity version, see eg [1]. For the trademark, there has been an attempt to improve the footer customization [2], but I'm not sure how far this went. -Lukas [1] http://jira.codehaus.org/browse/DOXIASITETOOLS-39 [2] http://jira.codehaus.org/browse/MSITE-549 On 11/21/2011 09:03 AM, Simone Tripodi wrote: Hi Lukas! thanks for the clarification, very appreciated! Are you aware of any turnaround? It would be really useful to let users use placeholders inside of $decoration.body.(head|foot)er elements. It is a requirement I have to satisfy in order to let other ASF communities adopt the fluido-skin, mainly because we have to fill trademarks... Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Nov 21, 2011 at 8:39 AM, Lukas Theusslltheu...@apache.org wrote: Hi Simone, The evaluate directive was added in velocity 1.6 [1], doxia-site-renderer still uses velocity 1.5. HTH, -Lukas [1] https://issues.apache.org/jira/browse/VELOCITY-509 On 11/20/2011 04:45 PM, Simone Tripodi wrote: Hi all guys, is anyone aware about some Issue that prevents Velocity execute the #evaluate directive in the skins? It looks like it is just rendered as #evaluate(arg) string... Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [site] #evaluate Velocity macro ignored
Hi Simone, The evaluate directive was added in velocity 1.6 [1], doxia-site-renderer still uses velocity 1.5. HTH, -Lukas [1] https://issues.apache.org/jira/browse/VELOCITY-509 On 11/20/2011 04:45 PM, Simone Tripodi wrote: Hi all guys, is anyone aware about some Issue that prevents Velocity execute the #evaluate directive in the skins? It looks like it is just rendered as #evaluate(arg) string... Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [VOTE] Release PMD Plugin 2.6
+1 -Lukas On 11/08/2011 07:05 PM, Olivier Lamy wrote: Hello, I'd like to release Apache Maven PMD Plugin 2.6. We fixed 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140version=16437. Staging repository: https://repository.apache.org/content/repositories/maven-169/ Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.6 (wait sync) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72H. Here my +1 Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Promote maven-app-engine (mae) from sandbox and release 1.0-alpha-1
+1 -Lukas On Wed, Oct 26, 2011 at 11:36 PM, John Casey jdca...@commonjava.org wrote: Hi everyone, MAE is a new project that I've been working on for about a year and a half. It's goal is to wrap the Maven APIs and make them easier to embed inside other applications. This enables applications to orchestrate Maven builds, but it also enables the easy reuse of Maven components outside of Maven proper. Though I've been working on this project for awhile now, I don't have any really great examples built into the codebase just yet; I need to distill a few that illustrate the two broad use cases from the applications I've been building around MAE. This is just the 1.0-alpha-1 release. It doesn't have an issue tracker or proper website yet, but the code is relatively stable as-is (I've left this vote for awhile to make sure of that). My hope was to promote the project out of the sandbox and get a first alpha released, then start beefing up examples and documentation that will go on a website. The staging repository is here: https://repository.apache.org/**content/repositories/maven-**103/https://repository.apache.org/content/repositories/maven-103/ FWIW, the guide to testing staged releases is here: http://maven.apache.org/**guides/development/guide-**testing-releases.htmlhttp://maven.apache.org/guides/development/guide-testing-releases.html This vote is open for 72h: (practically speaking, it'll be Monday before I can circle back to it) [ ] +1 [ ] +0 [ ] -1 -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.**name/http://www.johnofalltrades.name/ --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Checkstyle Plugin version 2.8
+1 -Lukas On 10/24/2011 04:03 PM, Mark Hobson wrote: Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127version=17520 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=1 Staging repo: https://repository.apache.org/content/repositories/maven-091/ Staging site: http://maven.apache.org/plugins/maven-checkstyle-plugin-2.8/plugins/maven-checkstyle-plugin/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Cheers, Mark - 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: [skin / doxia] escaping issue with menu items
looks like http://jira.codehaus.org/browse/MSITE-333 The problem is certainly in Doxia, not velocity. -Lukas On 10/17/2011 08:55 PM, Robert Scholte wrote: I've just discovered there's an escaping issue with the menu items (both fluido and current maven skin). The ampersand of 'Maven 2 3' is not escaped. The question is: which of the following is responsible for escaping: the doxia model decorator or the velocity template? If it's the latter I'd like to fix it with DOXIA-450[1] The fix itself isn't that hard, but I'd like to confirm it with an IT first, which seems a bit harder. There are no such tests yet. -Robert [1] http://jira.codehaus.org/browse/DOXIA-450 [2] http://velocity.apache.org/tools/devel/standalone.html - 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: [site] custom elements in site.xml not merged
Looking at the source code of doxia's DefaultDecorationModelInheritanceAssembler, I would expect this to work. Can you provide a test project? -Lukas Simone Tripodi wrote: Hi again guys I just figured out that if project B pom inherits from project A pom which has attached the site descriptor withcustom elements, in project B the declaredcustom elements are just ignored... Is it a known bug or it is an issue to be filled? Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [Doxia] Site generation replicates class attribute
It's a bug. -Lukas On 10/13/2011 10:03 PM, Simone Tripodi wrote: Hi all guys! while generating the Apache DirectMemory site[1] using the xdoc format, I noticed that for everysection element, if `class` attribute is specified, it is replicated to the nestedh2 element. For example, for section name=Apache DirectMemory class=hero-unit pApache DirectMemory is a multi layered cache implementation featuring off-heap memory management (a-la BigMemory) to enable efficient handling of a large number of java objects without affecting jvm garbage collection performance./p /section Has been rendered as div class=hero-unit h2 class=hero-unitApache DirectMemorya name=Apache_DirectMemory/a/h2 pApache DirectMemory is a multi layered cache implementation featuring off-heap memory management (a-la BigMemory) to enable efficient handling of a large number of java objects without affecting jvm garbage collection performance./p /div Of course, depending on the skin, it could cause undesired effects. I wonder if this is a bug or a feature. If you confirm is a bug, I'll fill an issue. TIA, all the best! Simo [1] http://incubator.apache.org/directmemory/index.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [Doxia] Site generation replicates class attribute
Doxia's JIRA is still at codehaus: http://jira.codehaus.org/browse/DOXIA Cheers, -Lukas On 10/14/2011 09:19 AM, Simone Tripodi wrote: Thanks for confirming Lukas! I just need to know if the Issue has to be filled in the Apache's or Codehaus' JIRA... TIA! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Oct 14, 2011 at 9:14 AM, Lukas Theusslltheu...@apache.org wrote: It's a bug. -Lukas On 10/13/2011 10:03 PM, Simone Tripodi wrote: Hi all guys! while generating the Apache DirectMemory site[1] using the xdoc format, I noticed that for everysectionelement, if `class` attribute is specified, it is replicated to the nestedh2element. For example, for section name=Apache DirectMemory class=hero-unit pApache DirectMemory is a multi layered cache implementation featuring off-heap memory management (a-la BigMemory) to enable efficient handling of a large number of java objects without affecting jvm garbage collection performance./p /section Has been rendered as div class=hero-unit h2 class=hero-unitApache DirectMemorya name=Apache_DirectMemory/a/h2 pApache DirectMemory is a multi layered cache implementation featuring off-heap memory management (a-la BigMemory) to enable efficient handling of a large number of java objects without affecting jvm garbage collection performance./p /div Of course, depending on the skin, it could cause undesired effects. I wonder if this is a bug or a feature. If you confirm is a bug, I'll fill an issue. TIA, all the best! Simo [1] http://incubator.apache.org/directmemory/index.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [skin][fluido] BannerLeft always outputed
Note that this is the default behaviour of all standard maven skins, your workaround is actually the solution I would have suggested. You can change this default in the fluido skin site template if you wish. -Lukas On 10/14/2011 10:18 AM, Christian Grobmeier wrote: Hey folks, did you reckon that if you don't have a bannerleft section in fluido, it is always the name outputed? I think if it is missing, it should not be written anything. At the moment one need to add this to leave out the logo: bannerLeft name/name /bannerLeft Cheers - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [skin][fluido] Optional header tag not working
This is a bug in Doxia, it should work by wrapping the content of the
style tag in a CDATA section, but it doesn't. I will file an issue.
Cheers,
-Lukas
On 10/14/2011 10:29 AM, Christian Grobmeier wrote:
Just found out... as per defintion you can usually add additional head
elements to xdoc:
http://maven.apache.org/doxia/references/xdoc-format.html
head
style type=text/css
h2 {
font-size: 50px;
}
/style
/head
This should appear in the generated files, but doesnt. This is what we get:
!-- Optional HEAD element, which is copied as is into the XHTML
head element --style/style
-
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: [skin][fluido] BannerLeft always outputed
On 10/14/2011 11:31 AM, Christian Grobmeier wrote: On Fri, Oct 14, 2011 at 11:16 AM, Lukas Theusslltheu...@apache.org wrote: Note that this is the default behaviour of all standard maven skins, your workaround is actually the solution I would have suggested. You can change this default in the fluido skin site template if you wish. hmm... I would prefer to put the default to null and output nothing (because fluido has already the projects name in a special section). I have looked into my site.vm - but could not find how I change the output. Can you point me to that? You did it already in your commit r1183250 (which I saw only after I sent my comment). Cheers, -Lukas Thanks Christian -Lukas On 10/14/2011 10:18 AM, Christian Grobmeier wrote: Hey folks, did you reckon that if you don't have a bannerleft section in fluido, it is always the name outputed? I think if it is missing, it should not be written anything. At the moment one need to add this to leave out the logo: bannerLeft name/name /bannerLeft Cheers - 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: Site element generation
Could you specify what exactly you mean with element generation behavior? What are you trying to achieve? -Lukas On 10/11/2011 11:17 AM, Simone Tripodi wrote: Salut Olivier! apologize for my lack of knowledge about it, but I didn't understand if I can customize element generation behavior - and how, if it is possible :P Don't we have any reference about it? Many thanks in advance and sorry for the noise! All the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 11, 2011 at 10:41 AM, Olivier Lamyol...@apache.org wrote: Hello Simone, All is done in doxia. Check here http://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-modules/doxia-module-xhtml/ 2011/10/10 Simone Tripodisimonetrip...@apache.org: Hi all guys, While modifying the original site layout to integrate Boostrap, I figured out that some elements, such as thesource section and the paragraph, are not generated inside the .vm template... When that trax happens? Is it something can be changed or it is hardcoded somewhere? I'm asking because if can modify such elements generation, it would be easier integrate Bootstrap toys :) Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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: Site element generation
I would have guessed that this should work with source class=prettyprint but it doesn't, I have just filed an issue: http://jira.codehaus.org/browse/DOXIA-446 So unfortunately the answer to your last question is 'no' for the moment... -Lukas On 10/11/2011 12:11 PM, Simone Tripodi wrote: Hi Lukas! in the site generation, instead of rendering thesource section with div class=sourcepre.../pre/div I would like to have pre class=prettyprint/pre Is it possible? Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 11, 2011 at 11:29 AM, Lukas Theusslltheu...@apache.org wrote: Could you specify what exactly you mean with element generation behavior? What are you trying to achieve? -Lukas On 10/11/2011 11:17 AM, Simone Tripodi wrote: Salut Olivier! apologize for my lack of knowledge about it, but I didn't understand if I can customize element generation behavior - and how, if it is possible :P Don't we have any reference about it? Many thanks in advance and sorry for the noise! All the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 11, 2011 at 10:41 AM, Olivier Lamyol...@apache.orgwrote: Hello Simone, All is done in doxia. Check here http://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-modules/doxia-module-xhtml/ 2011/10/10 Simone Tripodisimonetrip...@apache.org: Hi all guys, While modifying the original site layout to integrate Boostrap, I figured out that some elements, such as thesourcesection and the paragraph, are not generated inside the .vm template... When that trax happens? Is it something can be changed or it is hardcoded somewhere? I'm asking because if can modify such elements generation, it would be easier integrate Bootstrap toys :) Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site element generation
Dennis Lundberg wrote: So for xdoc we need a fix in doxia, but what about for apt documents? Is that even possible with the current model? No, not with the current apt format specification, apt doesn't know anything about styles [1]. But this is a limitation of the specific language format, not doxia. -Lukas [1] http://maven.apache.org/doxia/faq.html#How_to_handle_style_in_the_APT_markup_language On Tuesday, October 11, 2011, Lukas Theusslltheu...@apache.org wrote: I would have guessed that this should work with source class=prettyprint but it doesn't, I have just filed an issue: http://jira.codehaus.org/browse/DOXIA-446 So unfortunately the answer to your last question is 'no' for the moment... -Lukas On 10/11/2011 12:11 PM, Simone Tripodi wrote: Hi Lukas! in the site generation, instead of rendering thesource section with div class=sourcepre.../pre/div I would like to have pre class=prettyprint/pre Is it possible? Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 11, 2011 at 11:29 AM, Lukas Theusslltheu...@apache.org wrote: Could you specify what exactly you mean with element generation behavior? What are you trying to achieve? -Lukas On 10/11/2011 11:17 AM, Simone Tripodi wrote: Salut Olivier! apologize for my lack of knowledge about it, but I didn't understand if I can customize element generation behavior - and how, if it is possible :P Don't we have any reference about it? Many thanks in advance and sorry for the noise! All the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 11, 2011 at 10:41 AM, Olivier Lamyol...@apache.org wrote: Hello Simone, All is done in doxia. Check here http://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-modules/doxia-module-xhtml/ 2011/10/10 Simone Tripodisimonetrip...@apache.org: Hi all guys, While modifying the original site layout to integrate Boostrap, I figured out that some elements, such as thesource section and the paragraph, are not generated inside the .vm template... When that trax happens? Is it something can be changed or it is hardcoded somewhere? I'm asking because if can modify such elements generation, it would be easier integrate Bootstrap toys :) Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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 - 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: r1177032 - /maven/plugins/trunk/maven-site-plugin/src/site/apt/examples/sitedescriptor.apt
Thanks Dennis, that must have been a bad copypaste from a web page. -Lukas On 09/28/2011 09:55 PM, denn...@apache.org wrote: Author: dennisl Date: Wed Sep 28 19:55:13 2011 New Revision: 1177032 URL: http://svn.apache.org/viewvc?rev=1177032view=rev Log: Fix garbage characters. Modified: maven/plugins/trunk/maven-site-plugin/src/site/apt/examples/sitedescriptor.apt Modified: maven/plugins/trunk/maven-site-plugin/src/site/apt/examples/sitedescriptor.apt URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/site/apt/examples/sitedescriptor.apt?rev=1177032r1=1177031r2=1177032view=diff == --- maven/plugins/trunk/maven-site-plugin/src/site/apt/examples/sitedescriptor.apt (original) +++ maven/plugins/trunk/maven-site-plugin/src/site/apt/examples/sitedescriptor.apt Wed Sep 28 19:55:13 2011 @@ -233,7 +233,7 @@ Configuring the Site Descriptor * Inject xhtml into \head\ You can inject some xhtml into the generated \head\ element of each page by adding a head element - to the body element of your projectâs site descriptor. The following example adds some javascript: + to the body element of your project's site descriptor. The following example adds some javascript: +-+ project @@ -252,7 +252,7 @@ Configuring the Site Descriptor * Links To add links below your site logo, just add a links element to the body element of the site descriptor. - Each item in the links element will be rendered as a link in a bar directly below your projectâs logo. + Each item in the links element will be rendered as a link in a bar directly below your project's logo. +-+ project @@ -316,7 +316,7 @@ Configuring the Site Descriptor There is also a dummy \custom\ element then can be used to specify some arbitrary content. Note that you need to write your own velocity template to make use of this element, - it is ignored by the default velocity template used by the site plugin. + it is ignored by the default Velocity template used by the Site Plugin. +-+ project - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Wagon 2.0
+1 -Lukas On 09/26/2011 03:56 PM, Olivier Lamy wrote: Hello, I'd like to release Apache Maven Wagon 2.0. We fixed 31 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=17379styleName=TextprojectId=10335Create=Create Staging repo : https://repository.apache.org/content/repositories/maven-104/ Staging site : http://maven.apache.org/wagon-2.0 (wait sync). [+1] [ 0] [-1] An easy way to test it: download jar and put it your $M2_HOME/lib/ext (if you use maven 3). wagon http: wget https://repository.apache.org/content/repositories/maven-104/org/apache/maven/wagon/wagon-http/2.0/wagon-http-2.0-shaded.jar cp wagon-http-2.0-shaded.jar $M2_HOME/lib/ext/ Here my +1. Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1170568 - /maven/plugins/trunk/maven-site-plugin/src/site/fml/faq.fml
Hi Benson, By changing the faq id, you also change the html anchor generated by the site plugin, so any old links to this faq, eg the one I added today [1], will not work anymore. I suggest to leave the id unchanged. Cheers, -Lukas [1] http://svn.apache.org/viewvc?rev=1170457view=rev bimargul...@apache.org wrote: Author: bimargulies Date: Wed Sep 14 12:26:44 2011 New Revision: 1170568 URL: http://svn.apache.org/viewvc?rev=1170568view=rev Log: a little SEO for DocBook users. Arguably XHTML should get the same favor. Modified: maven/plugins/trunk/maven-site-plugin/src/site/fml/faq.fml Modified: maven/plugins/trunk/maven-site-plugin/src/site/fml/faq.fml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/site/fml/faq.fml?rev=1170568r1=1170567r2=1170568view=diff == --- maven/plugins/trunk/maven-site-plugin/src/site/fml/faq.fml (original) +++ maven/plugins/trunk/maven-site-plugin/src/site/fml/faq.fml Wed Sep 14 12:26:44 2011 @@ -49,15 +49,16 @@ under the License. /ul /answer /faq -faq id=How to include a custom Doxia module, like Twiki -questionHow to include a custom Doxia module, like Twiki?/question +!-- mention docbook explicitly so google can find this -- +faq id=How to include a custom Doxia module, like Twiki or Simple DocBook +questionHow to include a custom Doxia module, like Twiki or Simple DocBook?/question answer p The site plugin handles out-of-box apt, xdoc and fml formats. If you want to use a custom format like Twiki (or any other document format for which a doxia parser exists, see the list of a href=http://maven.apache.org/doxia/references/index.html;Doxia Markup Languages/a), - you need to specify the corresponding Doxia dependency, e.g. for Twiki: + you need to specify the corresponding Doxia module dependency, e.g. for Twiki: /p source ![CDATA[project @@ -72,7 +73,7 @@ under the License. dependency groupIdorg.apache.maven.doxia/groupId artifactIddoxia-module-twiki/artifactId -version!-- adapt to your site plugin version! --/version +version!-- doxia version appropriate to the site plugin version --/version /dependency /dependencies /plugin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [codehaus-confluence] Doxia Home
I got those mails as well, but it seems to have been cleared by now. I'd like to keep those pages for historic reference (some issues addressed are still relevant) and make them read only. Only new pages should go to cwiki now. -Lukas On 08/26/2011 12:59 AM, Brett Porter wrote: You'd need to reach out to supp...@codehaus.org. Do we still need that space? Should we delete it, make it read only, move it to cwiki? Looks out of date. - Brett On 26/08/2011, at 7:59 AM, Vincent Siveton wrote: I received 61 mails from Cesar Kamoy which has uploaded files http://docs.codehaus.org/display/DOXIA/Home Does someone could blacklisted this guy and removed the files? I haven't the rights. Thanks Vincent -- Forwarded message -- From: Cesar Kamoy (Confluence)conflue...@codehaus.org Date: 2011/8/25 Subject: [codehaus-confluence] Doxia Home To: vincent.sive...@gmail.com Home File attached by Cesar Kamoy us5.pdf (28 kB application/pdf) Stop watching page | Change email notification preferences View Attachments - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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: wagon website somewhat broken
which version of the site-plugin did you use (it is not fixed in the wagon pom?)? I did a quick build with site-plugin-3.0 and breadcrumbs look ok. HTH, -Lukas On 08/19/2011 04:09 PM, Benson Margulies wrote: http://maven.apache.org/wagon/wagon-providers/wagon-ssh/ Try the breadcumbs. some of them point to 'people.apache...'. I might have done this, but I need help fixing in any case. - 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: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
Dennis Lundberg wrote: Hi I've done some testing, and as far as site generation all is well. Unfortunately site:stage-deploy deploys the site to the wrong place. This is the same issue I saw when releasing, and staging the site for, Maven Site Plugin 2.3. Here's what I get when doing 'mvn clean site:site site:deploy' on maven-checkstyle-plugin using maven-site-plugin:3.0. maven-site-plugin:2.3 does the same thing, but 3.0-beta-3 works correctly. So this is a regression compared to 3.0-beta-3. [INFO] --- maven-site-plugin:3.0:stage-deploy (default-cli) @ maven-checkstyle-plugin --- [INFO] Using this server ID for stage deploy: apache.website [INFO] Using this base URL for stage deploy: scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT [INFO] Parent project loaded from repository: org.apache.maven.plugins:maven-plugins:pom:21 [INFO] Parent project loaded from repository: org.apache.maven:maven-parent:pom:20 [INFO] Parent project loaded from repository: org.apache:apache:pom:9 : Keyboard interactive required, supplied password is ignored Password: : scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ - Session: Opened [INFO] Pushing G:\apache\maven\trunks\plugins\maven-checkstyle-plugin\target\site [INFO] to scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin Executing command: mkdir -p /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin Executing command: mkdir -p /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin Executing command: scp -t /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/wagon592489540427231356.zip Uploading: plugins/maven-checkstyle-plugin/wagon592489540427231356.zip to scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ ### Transfer finished. 224640 bytes copied in 1.699 seconds Executing command: cd /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin; unzip -q -o wagon592489540427231356.zip; rm -f wagon592489540427231356.zip Executing command: chmod -Rf g+w,a+rX /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ - Session: Disconnecting scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ - Session: Disconnected Notice how it gets deployed to /plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/ instead of /plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ Lukas, can this have anything to do with your refactoring of the staging functionality? Yes, most probably. After MSITE-537, if you stage-deploy from a sub-module, the relative path from the top-level site is added to the stage-deploy url. This doesn't seem to work if the default stagingSiteURL is overridden somewhere on the way, probably related to MSITE-600. Unfortunately, I don't have time right now to look at it, but promise I will ASAP when I'm back. -Lukas How should we handle this? I propose we go ahead with the release, but add this as a known issue in the announcement. And then we get started on a fix right away. This release is way to big as it is. On 2011-07-30 17:03, Dennis Lundberg wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
+1 -Lukas Dennis Lundberg wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
Dennis Lundberg wrote: Hi Does MSITE-600 also affect maven-site-plugin version 3? If so, can you please update that JIRA to also have the appropriate 3.0 version as Affects version. I suppose it will affect 3.0 as well, the code is the same. However, it was suggested to release 3.0 in a form as similar as possible to 2.3, for a point of comparison. I have started to investigate MSITE-600 and think I know how to fix it (the culprit is DefaultSiteTool.getRelativePath in doxia-integration-tools), but I will be on vacation now for two weeks (and hopefully stay away from my notebook...), so unless someone beats me to it, I will try to get it fixed ASAP when I'm back. As I said before, I prefer to have 3.0 released now with a series of bug fix releases afterwards. Cheers, -Lukas On 2011-07-30 17:32, Benson Margulies wrote: I'm not binding, but I'm sad about MSITE-600, which blocks my adoption at the day job. So +0 not that it matters. On Sat, Jul 30, 2011 at 11:03 AM, Dennis Lundbergdenn...@apache.org wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - 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: [VOTE] Release Maven Release plugin version 2.2.1
+1 -Lukas On 07/28/2011 04:56 PM, Stephen Connolly wrote: Hi, This is a patch release to fix a particularly nasty regression: http://jira.codehaus.org/browse/MRELEASE-697 We solved 3 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=17502 Staging repo: https://repository.apache.org/content/repositories/maven-009/ Source distribution: https://repository.apache.org/content/repositories/maven-009/org/apache/maven/release/maven-release/2.2.1/maven-release-2.2.1-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2.1 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2.1/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - 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: r1150994 - /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractDeployMojo.java
I won't fight about it but I dislike the idea of providing web links in
error messages. In a few years from now they might not exist any more or
provide irrelevant information. A stack trace is not pretty but google
doesn't mind that. At least log the stack trace at debug level if you
prefer.
-Lukas
On 07/27/2011 12:15 AM, Hervé BOUTEMY wrote:
did you try what an end-user can see when he tries to use an unavailable
protocol?
I'm ok with more detailed error message.
But the stacktrace, which is the only message which is displayed at the end of
Maven reactor run, stating that protocol could not be found, is not helpful:
the detailed error message is more expressive IMHO, telling the user where to
find information on how to fix.
Regards,
Hervé
Le mardi 26 juillet 2011, ltheu...@apache.org a écrit :
Author: ltheussl
Date: Tue Jul 26 06:42:00 2011
New Revision: 1150994
URL: http://svn.apache.org/viewvc?rev=1150994view=rev
Log:
move detailed error message to logger and preserve stacktrace
Modified:
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugi
ns/site/AbstractDeployMojo.java
Modified:
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugi
ns/site/AbstractDeployMojo.java URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/mai
n/java/org/apache/maven/plugins/site/AbstractDeployMojo.java?rev=1150994r1
=1150993r2=1150994view=diff
==
---
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugi
ns/site/AbstractDeployMojo.java (original) +++
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugi
ns/site/AbstractDeployMojo.java Tue Jul 26 06:42:00 2011 @@ -343,7 +343,7
@@ public abstract class AbstractDeployMojo
return buildDirectory;
}
-private Wagon getWagon( final Repository repository, final
WagonManager manager, final Log log ) +private static Wagon getWagon(
final Repository repository, final WagonManager manager, final Log log )
throws MojoExecutionException
{
final Wagon wagon;
@@ -354,13 +354,12 @@ public abstract class AbstractDeployMojo
}
catch ( UnsupportedProtocolException e )
{
-log.error( Unavailable protocol for site deployment: ' +
repository.getProtocol() + ' ); +log.error( Unsupported
protocol for site deployment: ' + repository.getProtocol() +
+ '. For adding new protocols to the site plugin, see +
+
http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-
protocol.html );
-throw new MojoExecutionException(
- this,
- Unavailable protocol for
site deployment: ' + repository.getProtocol() + ', -
To add a new protocol to site plugin, see -
+
http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-
protocol.html ); +throw new MojoExecutionException(
Unsupported protocol for site deployment: ' ++
repository.getProtocol() + '., e );
}
catch ( TransferFailedException e )
{
-
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: Is Maven Site Plugin 3.0-beta-4 ready for release?
green light from here, thanks Herve for the updates! -Lukas On 07/22/2011 12:48 AM, Hervé BOUTEMY wrote: Maven Site Plugin 3.0 is now ready for release (with its documentation) for me If anybody still has something to change, please explain what so we can fix it and release ASAP Regards, Hervé Le samedi 2 juillet 2011, Dennis Lundberg a écrit : Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - 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: No continuous integration of maven-assembly-plugin?
I uncommented the module as it passed for me locally and jenkins seems happy too now: https://builds.apache.org/job/maven-plugins-ITs-2.x/251/changes https://builds.apache.org/job/maven-plugins-ITs-3.x/126/changes (there are failures from other plugins though...). Cheers, -Lukas On 07/22/2011 12:46 PM, Barrie Treloar wrote: On Fri, Jul 22, 2011 at 6:03 PM, Julien HENRYhenr...@yahoo.fr wrote: Hi, I was not able to found a job on [1] building maven-assembly-plugin and associated ITs. Why maven-assembly-plugin is not in http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml ? Doesnt http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml say !-- Excluded due to ongoing failuresmodulemaven-assembly-plugin/module -- Feel free to fix them. - 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: Why does maven 3 still use the M2_HOME variable?
The maven installation instructions [1] explicitly mention the M2_HOME variable (and not MAVEN_HOME), is this obsolete? -Lukas [1] http://maven.apache.org/download.html#Installation On 07/19/2011 08:26 AM, Stephen Connolly wrote: I run m2 and m3 on the same machine at the same time (but from different windows)... no issues at all for me. http://javaadventure.blogspot.com/2011/03/my-magic-maven-and-ant-version.html just don't use M2_HOME at all, use MAVEN_HOME both versions pick it up quite successfully the M2_HOME was only legacy when M1 was around. On 19 July 2011 06:13, Peter Wilkinsonproggerp...@gmail.com wrote: Doing this stops maven 2 and maven 3 being able to run on the same machine. It also makes no sense. Cheers, Peter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1147613 - in /maven/jxr/trunk: maven-jxr-plugin/pom.xml maven-jxr/pom.xml pom.xml
FYI: Dennis has had similar problems at the last release: http://maven.40175.n5.nabble.com/VOTE-Release-Maven-JXR-version-2-2-td216534.html but I'd have guessed that this was fixed since then. There is still something else wrong with the cobertura report: the main index page http://maven.apache.org/staging/plugins/maven-jxr-plugin/ actually expands the cobertura navigation menu and there is no cobertura report generated (even though cobertura runs during site generation). Using current maven-parent-21-SNAPSHOT fixes this (maybe due to MCOBERTURA-145? you should know! :) ) I am still puzzled about the cycle, it seems like maven doesn't distinguish plugins of different versions? HTH, -Lukas On 07/17/2011 06:25 PM, Benson Margulies wrote: OK, I got it. Without plugin-plugin 2.8, the plugin-info doesn't appear. I've restaged. - 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: [VOTE] Release Maven JXR version 2.3
I think it is common usus in maven land to keep plugins inside their respective projects (see eg maven-archetype-plugin, maven-enforcer-plugin, maven-scm-plugin, maven-surefire-plugin,...), the main advantage being that they are released together and kept in sync and up-to date with the main code. I would prefer to leave it that way for jxr. -Lukas On 07/17/2011 12:04 AM, Benson Margulies wrote: For the next release, how would you feel about moving the plugin in with the other plugins, and eliminating the extra level of parent? On Sat, Jul 16, 2011 at 4:09 PM, Hervé BOUTEMYherve.bout...@free.fr wrote: for the old aggregation parameter, it's easy for the goals documentation, yes, I don't understand how it can disappear. It seems to be using m-site-p 2.2: upgrade to 2.3? Or maybe you changed the parent? We're a few working on site improvements to avoid regressions with future releases: site ITs have improved a lot recently, but we probably still need more experience That's exaclty for this one that I proposed you to help: I'm on IRC, dont hesitate to connect Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : By the way, is anyone still active who did the previous release of JXR? It's not obvious how I could have caused these issues. On Sat, Jul 16, 2011 at 3:36 PM, Hervé BOUTEMYherve.bout...@free.fr wrote: qhat I usually do is patch the trunk and when publishing the final version, I copy modified files from site to my local checkout yes, that means that the site published on maven.apache.org isn't reproducible But having a non-reproducible site isn't really an issue AFAIK modifying the svn tag would be cumbersome and more risky IMHO don't hesitate to tell me if you want help to fix issues: for the moment, I'm not working on them to avoid checkin conflicts Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : Hervé, How can I make these site repairs when publishing against the label? Is the idea to go ahead and make fixes to a checkout of the tag, publish the site, and then patch them into trunk? --benson On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMYherve.bout...@free.fr wrote: +1 tested in Maven 3.0.4-SNAPSHOT [1] (sync pending) notice that there are some glitches with documentation: - plugin-info.html isn't there nor goals documentation (?) - aggregating example should be modified like javadoc to show new goals and mark aggregate parameter as obsolete nothing that prevents plugin release, but these should be fixed when the site is published Regards, Hervé Le vendredi 15 juillet 2011, Benson Margulies a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI- QX7 G-9 IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleN am e=Te xtprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= pro ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.htm l Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 - 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: [VOTE] Release Maven JXR version 2.3
an alternative is to give it maven-plugins as parent, but leave it inside jxr, (like scm is doing). WDYT? -Lukas On 07/18/2011 02:50 PM, Benson Margulies wrote: There's a lot of common stuff in the parent of the plugins: announcements, changes, site config. Without mixins :-) we can't take advantage of that. In short, I claim that the maven-jxr-plugin has more in common with the rest of the plugins than it has with jxr. It's only connection to JXR is one dependency. My opinion, of course. On Mon, Jul 18, 2011 at 3:38 AM, Lukas Theusslltheu...@apache.org wrote: I think it is common usus in maven land to keep plugins inside their respective projects (see eg maven-archetype-plugin, maven-enforcer-plugin, maven-scm-plugin, maven-surefire-plugin,...), the main advantage being that they are released together and kept in sync and up-to date with the main code. I would prefer to leave it that way for jxr. -Lukas On 07/17/2011 12:04 AM, Benson Margulies wrote: For the next release, how would you feel about moving the plugin in with the other plugins, and eliminating the extra level of parent? On Sat, Jul 16, 2011 at 4:09 PM, Hervé BOUTEMYherve.bout...@free.fr wrote: for the old aggregation parameter, it's easy for the goals documentation, yes, I don't understand how it can disappear. It seems to be using m-site-p 2.2: upgrade to 2.3? Or maybe you changed the parent? We're a few working on site improvements to avoid regressions with future releases: site ITs have improved a lot recently, but we probably still need more experience That's exaclty for this one that I proposed you to help: I'm on IRC, dont hesitate to connect Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : By the way, is anyone still active who did the previous release of JXR? It's not obvious how I could have caused these issues. On Sat, Jul 16, 2011 at 3:36 PM, Hervé BOUTEMYherve.bout...@free.fr wrote: qhat I usually do is patch the trunk and when publishing the final version, I copy modified files from site to my local checkout yes, that means that the site published on maven.apache.org isn't reproducible But having a non-reproducible site isn't really an issue AFAIK modifying the svn tag would be cumbersome and more risky IMHO don't hesitate to tell me if you want help to fix issues: for the moment, I'm not working on them to avoid checkin conflicts Regards, Hervé Le samedi 16 juillet 2011, Benson Margulies a écrit : Hervé, How can I make these site repairs when publishing against the label? Is the idea to go ahead and make fixes to a checkout of the tag, publish the site, and then patch them into trunk? --benson On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMYherve.bout...@free.fr wrote: +1 tested in Maven 3.0.4-SNAPSHOT [1] (sync pending) notice that there are some glitches with documentation: - plugin-info.html isn't there nor goals documentation (?) - aggregating example should be modified like javadoc to show new goals and mark aggregate parameter as obsolete nothing that prevents plugin release, but these should be fixed when the site is published Regards, Hervé Le vendredi 15 juillet 2011, Benson Margulies a écrit : Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI- QX7 G-9 IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleN am e=Te xtprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= pro ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.htm l Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail:
Re: svn commit: r1147613 - in /maven/jxr/trunk: maven-jxr-plugin/pom.xml maven-jxr/pom.xml pom.xml
Benson: I have locally built and staged the site before and after this
commit and I don't see any of the mentioned issues. Have you actually
checked your local site? Did you run the site phase or the site:site
goal? Anyway, with site-plugin-2.3 the locally built and
stage(-deployed) sites should be completely identical.
-Lukas
bimargul...@apache.org wrote:
Author: bimargulies
Date: Sun Jul 17 13:49:35 2011
New Revision: 1147613
URL: http://svn.apache.org/viewvc?rev=1147613view=rev
Log:
Copy more configuration from the standard plugin parent to see if I can't fix
up the site issues that Hervé
pointed out. This is certainly not all the fixes needed.
Modified:
maven/jxr/trunk/maven-jxr-plugin/pom.xml
maven/jxr/trunk/maven-jxr/pom.xml
maven/jxr/trunk/pom.xml
Modified: maven/jxr/trunk/maven-jxr-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/maven-jxr-plugin/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/maven-jxr-plugin/pom.xml (original)
+++ maven/jxr/trunk/maven-jxr-plugin/pom.xml Sun Jul 17 13:49:35 2011
@@ -48,7 +48,7 @@ under the License.
properties
mavenVersion2.0.9/mavenVersion
-sitePluginVersion2.2/sitePluginVersion
+sitePluginVersion2.3/sitePluginVersion
doxia-sitetoolsVersion1.2/doxia-sitetoolsVersion
doxiaVersion1.2/doxiaVersion
/properties
@@ -73,10 +73,6 @@ under the License.
forkModealways/forkMode
/configuration
/plugin
-plugin
-artifactIdmaven-site-plugin/artifactId
-version${sitePluginVersion}/version
-/plugin
/plugins
/pluginManagement
@@ -84,6 +80,7 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
+ version2.8/version
executions
execution
idgenerated-helpmojo/id
@@ -185,6 +182,7 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
+ version2.8/version
/plugin
/plugins
/reporting
@@ -235,7 +233,7 @@ under the License.
/file
/activation
properties
-sitePluginVersion3.0-beta-1-SNAPSHOT/sitePluginVersion
+sitePluginVersion3.0-beta-4-SNAPSHOT/sitePluginVersion
/properties
/profile
@@ -246,13 +244,13 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
-version2.5/version
+version2.8/version
configuration
tagletArtifacts
tagletArtifact
groupIdorg.apache.maven.plugin-tools/groupId
artifactIdmaven-plugin-tools-javadoc/artifactId
-version2.5/version
+version2.8/version
/tagletArtifact
tagletArtifact
groupIdorg.codehaus.plexus/groupId
Modified: maven/jxr/trunk/maven-jxr/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/maven-jxr/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/maven-jxr/pom.xml (original)
+++ maven/jxr/trunk/maven-jxr/pom.xml Sun Jul 17 13:49:35 2011
@@ -101,6 +101,7 @@ under the License.
/site
/distributionManagement
+
dependencies
dependency
groupIdjunit/groupId
Modified: maven/jxr/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/pom.xml (original)
+++ maven/jxr/trunk/pom.xml Sun Jul 17 13:49:35 2011
@@ -60,6 +60,7 @@ under the License.
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
+ scopetest/scope
version4.8.2/version
/dependency
/dependencies
@@ -69,6 +70,13 @@ under the License.
pluginManagement
plugins
plugin
+artifactIdmaven-site-plugin/artifactId
+ version2.3/version
+configuration
+stagingSiteURLscp://people.apache.org/www/maven.apache.org/jxr/${project.artifactId}-${project.version}/stagingSiteURL
+/configuration
+/plugin
+plugin
artifactIdmaven-release-plugin/artifactId
configuration
tagBasehttps://svn.apache.org/repos/asf/maven/jxr/tags/tagBase
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
Tony Chemit wrote: On Thu, 7 Jul 2011 21:22:43 +0200 Hervé BOUTEMYherve.bout...@free.fr wrote: I forgot we had this great Jenkins instance with lots of OSes and configuration combinations, and improved ITs to cover a lot of cases (more than +50% over 3.0-beta-3) Then I'm now confident that we can release a good quality even without a lot of users having done tests themselves. +1 for 3.0 final: it won't be over-estimated! Something was detected as a regression in last stable version of version 2.3 of the site plugin Lukas added a IT for this case [1] and has also a ticket [2]. If this is not ok, this is for my part a none reason to a final release ? I don't know the difficulty to fix this problem... [1] http://svn.apache.org/viewvc?rev=1126420view=rev [2] http://jira.codehaus.org/browse/MSITE-585 I have committed a fix for the issue, however, I am not sure if it fixes your exact use-case and it probably still requires adjustment of your project (the parent pom requires default values for all variables). I have deployed snapshots (2.4-SNAPSHOT and 3.0-beta-4-SNAPSHOT), please check if it helps anything. cheers, -Lukas - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Trying to address JXR-84, in world of hurt with plugin test harness
SinkEventAttributes was added in Doxia-1.1, so there is apparently a mixup with some some plugin/component that uses the old doxia-1.0. Not sure it helps, but here are some notes about upgrading from doxia-1.0 to 1.1: http://maven.apache.org/doxia/whatsnew-1.1.html http://maven.apache.org/doxia/developers/maven-integration.html HTH, -Lukas Benson Margulies wrote: I'm beginning to make some sense of this. If I keep copying the javadoc plugin I'll find the bottom eventually. Caused by: java.lang.ClassNotFoundException: org.apache.maven.doxia.sink.SinkEventAttributes at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 75 more - 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: [VOTE] Release Wagon version 1.0
+1 -Lukas Benson Margulies wrote: Hi, We solved 4 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9IAS|54cb0a05f789c3d1c147937a1867cbad60dfe04a|linversion=16884styleName=TextprojectId=10335Create=Create There are still a plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+WAGON+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-003/ Staging site: http://maven.apache.org/wagon-1.0 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Please be so kind as to put your apache email address somewhere in your vote email if it isn't sent from there. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: r1144300 - in /maven/plugins/trunk/maven-javadoc-plugin: ./ src/it/MJAVADOC-320/ src/it/MJAVADOC-320/module1/ src/it/MJAVADOC-320/module1/src/ src/it/MJAVADOC-320/module1/src/main/ src
Hi Mark, Please use the Maven SVN Conventions for commit messages: http://maven.apache.org/developers/conventions/svn.html Thanks! -Lukas strub...@apache.org wrote: Author: struberg Date: Fri Jul 8 12:57:27 2011 New Revision: 1144300 URL: http://svn.apache.org/viewvc?rev=1144300view=rev Log: MJAVADOC-320 fix includeTransitiveDependencySources. thanks to Jakob Korherr (apacheId: jakobk)! Added: maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/goals.txt (with props) maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/pom.xml (with props) maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/main/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/main/java/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/main/java/org/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/main/java/org/apache/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/main/java/org/apache/maven/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/main/java/org/apache/maven/plugin/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/main/java/org/apache/maven/plugin/javadoc/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/main/java/org/apache/maven/plugin/javadoc/it/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module1/src/main/java/org/apache/maven/plugin/javadoc/it/Module1Class.java (with props) maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/pom.xml (with props) maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/main/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/main/java/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/main/java/org/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/main/java/org/apache/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/main/java/org/apache/maven/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/main/java/org/apache/maven/plugin/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/main/java/org/apache/maven/plugin/javadoc/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/main/java/org/apache/maven/plugin/javadoc/it/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module2/src/main/java/org/apache/maven/plugin/javadoc/it/Module2Class.java (with props) maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/pom.xml (with props) maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/main/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/main/java/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/main/java/org/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/main/java/org/apache/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/main/java/org/apache/maven/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/main/java/org/apache/maven/plugin/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/main/java/org/apache/maven/plugin/javadoc/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/main/java/org/apache/maven/plugin/javadoc/it/ maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/module3/src/main/java/org/apache/maven/plugin/javadoc/it/Module3Class.java (with props) maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/pom.xml (with props) maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-320/verify.bsh (with props) maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/resolver/ProjectArtifactFilter.java (with props) Modified: maven/plugins/trunk/maven-javadoc-plugin/pom.xml maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/resolver/ResourceResolver.java [snip]
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
Hervé BOUTEMY wrote: the rationale behind not going directly to 3.0 was that site plugin is hard to test, particularly now that it is both compatible with Maven 2 and Maven 3, which is something really new and probably tested by only a few of us I don't quite agree with this rationale. Ease of testing is not a criterion for version naming IMO. The main criterion is how many *known* bugs and missing features there are left. So what are the open issues that we are aware about? If there are none or only a few, then let's call it final. If the people who are working on the release feel that the stuff is stable (which I do) then why not release it as such? sure, 3.0-beta-4 should at least be 3.0-RC-1, but perhaps not 3.0 immediately: I'm pretty sure we'll find some important problems when a lot of people try it seriously The most efficient way to get people to test something, is to release it! :) There are real important factors to test, which makes a lot of combinations: - Maven version: 2.2.x, 3.x - OS - phases: site, site-deploy, site:stage-deploy (run? jar?) should all be covered by our ITs: https://builds.apache.org/job/maven-site-plugin-2.x/ https://builds.apache.org/job/maven-site-plugin-3.x/ https://builds.apache.org/job/maven-site-plugin-3.x-m2/ I am aware that there are some important differences though, (some ITs are skipped with m3, or executed with different parameters), which would be important to review and document I guess. - deploy protocol: scp, webdav not really a site-plugin concern, rather wagon - report plugins used: I don't know how to describe without being a mess... We (devs) cannot test everything, even the more important it is to get user feedback. But at least, with maven-site-plugin 2.3 being out and almost equivalent (particularly when it comes to Doxia and Doxia Site Tools), we have a clear line to check if a problem with 3.0 is a regression from 2.3 or not so this would rather be an argument in favour of 3.0...? Then I'd better be for 3.0-RC-1 for the moment. I will support whatever the release manager decides, but I would prefer 3.0-final with a number of bug fix releases following, rather than an open interval of [RC-1, RC-2,...). More people will test the final release and there will be more pressure on us to push for bug-fix versions (which is good! :) ). -Lukas Such a discussion happened a lot of time in the past: 3.0 and 3.0-RC-1 are good choices, but not 3.0-beta-4 The release manager can choose and I'll be with him. But IMHO we need to ask for people to tell what conditions they tested. Regards, Hervé Le mercredi 6 juillet 2011, Olivier Lamy a écrit : No objections from me. beta cycle has started long time ago. 2011/7/6 Lukas Theusslltheu...@apache.org: Any objections to making this 3.0-final? AFAICT the plugin is functionally (almost) equivalent to the 2.x trunk version (only exception is MSITE-484?), so why keep the beta? -Lukas Dennis Lundberg wrote: Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - 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: [VOTE] Shared Component Maven Reporting Exec 1.0
+1 -Lukas Olivier Lamy wrote: Hi, Here a vote to release the first version of maven-reporting-exec component This component contains necessary code to run site plugin with maven 3. So currently no jira issues as it's a simply an extraction of code from maven site plugin for maven 3 branch [1] Staging repo : https://repository.apache.org/content/repositories/maven-015/ Site : http://maven.apache.org/shared/maven-reporting-exec/ (wait sync as currently it's an old 1.0-SNAPSHOT deployed) You can test it with the site plugin 3.x branch [1] Vote open for 72H. [ ] +1 [ ] +0 [ ] -1 Here my +1. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
Any objections to making this 3.0-final? AFAICT the plugin is functionally (almost) equivalent to the 2.x trunk version (only exception is MSITE-484?), so why keep the beta? -Lukas Dennis Lundberg wrote: Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: core integration tests trunk
I get the same failure on my Mac. I recommend to configure a jenkins job as multi-configuration type, see eg https://builds.apache.org/job/doxia/ (Just choose multi-configuration-project instead of maven2/3 project when adding the job) HTH, -Lukas Benson Margulies wrote: I just added an IT for MNG-5062. When I run the whole set, I get: Tests run: 697, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1,520.853 sec FAILURE! Results : Failed tests: testitMNG3951(org.apache.maven.it.MavenITmng3951AbsolutePathsTest): expected:/private/tmp but was:/tmp Tests run: 697, Failures: 1, Errors: 0, Skipped: 0 This looks like a macosx incompatibity to me. Anyone else with a view? - 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: Woes of site:stage-deploy
The first failure is expected since site-plugin-2.3:
http://maven.apache.org/plugins/maven-site-plugin/migrate.html
The other one, I don't know...
-Lukas
Stephen Connolly wrote:
Hervé, FYI things are not perfect yet
The woes of getting site:stage-deploy to work...
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:2.3:stage-deploy
(default-cli) on project maven-release: The site does not exist,
please run site:site first - [Help 1]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 2.2.1
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO] Searching repository for plugin with prefix: 'site'.
[INFO]
[INFO] Building Maven Release
[INFO]task-segment: [site:stage-deploy]
[INFO]
[INFO] [site:stage-deploy {execution: default-cli}]
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The site does not exist, please run site:site first
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Mon Jun 27 10:03:27 IST 2011
[INFO] Final Memory: 16M/81M
[INFO]
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ usemvn 3.0.2
[stephenc@stephenc ~/apache/maven-release/target/checkout]$ mvn
site:site site:stage-deploy -Preporting
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Maven Release
[INFO] Maven Release Manager
[INFO] Maven Release Plugin
[INFO]
[INFO]
[INFO] Building Maven Release 2.2
[INFO]
[INFO]
[INFO] --- maven-site-plugin:2.3:site (default-cli) @ maven-release ---
[WARNING] Running 2.x site-plugin with Maven 3, use site-plugin-3.x instead!
[INFO] Parent project loaded from repository:
org.apache.maven:maven-parent:pom:20
[INFO] Parent project loaded from repository: org.apache:apache:pom:9
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site_en.xml
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site.xml
Downloaded:
http://repo1.maven.org/maven2/org/apache/maven/maven-parent/20/maven-parent-20-site.xml
(3 KB at 3.2 KB/sec)
[INFO] Relativizing decoration links with respect to project URL:
http://maven.apache.org/maven-release/
[INFO] Rendering site with
org.apache.maven.skins:maven-stylus-skin:jar:1.3 skin.
[INFO]
[INFO] --- maven-site-plugin:2.3:stage-deploy (default-cli) @ maven-release ---
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/staging/
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Maven Release . FAILURE [3.804s]
[INFO] Maven Release Manager . SKIPPED
[INFO] Maven Release Plugin .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.146s
[INFO] Finished at: Mon Jun 27 10:04:07 IST 2011
[INFO] Final Memory: 8M/81M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:2.3:stage-deploy
(default-cli) on project maven-release: Unsupported protocol: 'scp':
Cannot find wagon which supports the requested protocol: scp:
com.google.inject.ProvisionException: Guice provision errors:
[ERROR]
[ERROR] 1) No implementation for
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. -Lukas Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: [VOTE]: release maven-changes-plugin 2.6
Gavin, Don't take it personal. I have expressed my opinion like you have expressed yours, and we are both entitled to do so. But you have to realize that your comments were taken with offence by some developers. I have been with maven for several years now, I know we have taken criticism for not releasing often enough, for releasing incomplete stuff, for releasing broken stuff, for releasing undocumented stuff; but this is the first time I remember that we take some heat for releasing too often. I guess I simply still have to learn how to deal with it! :) -Lukas Gavin McDonald wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. What do you base your vote on exactly? Rolling a new release for a few lines of code that fixes a couple of bugs and does not introduce any new functionality is overkill IMHO. But I will stay out of such votes/threads/opinions in the future , do what I joined this list for, then leave when I'm done. Gav... -Lukas Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing- releases.htm l Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, 20 June 2011 9:00 PM To: Maven Developers List Cc: ga...@16degrees.com.au Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin, When you sent your message containing the words, ignore me, I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond. 1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. Sure, understandable, I too followed the link you gave as part of the vote. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. I'm not sure I mentioned anything about this. ... 3 issues seems like doing a days work ... quoted from http://www.mail-archive.com/dev@maven.apache.org/msg88624.html 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. I'm not sure I mentioned anything about this. ... Don’t release for the sake of releasing... quoted from http://www.mail-archive.com/dev@maven.apache.org/msg88586.html -Lukas 4: An Apache principle is to encourage people to scratch their itches. After 6 years at Apache I get that. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. I don’t get how this is relevant to my voting on the specifics of a few lines of changed code. I was basing this on the link you gave to the 3 Jira Issues. We now know it was 10 issues. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. That’s good, someone else in this thread earlier was making out it’s a really hard process and so therefore why would anyone do it for the sake of it. Glad to be corrected there. Is there some particular reason why you've chosen to blow a whistle about this particular question? This was no vendetta, no campaign of sneer, nothing against yourself, I know what you do it Apache and where, you work hard, do not take this as anything other than querying why would anyone do a release based on 3 issues and a few lines of code. It was just that , no more, no less, I do not get all the hostility that has come from such a query, than one is entitled to do. Please, let s drop this, I have now unsubscribed from the list. Gav... --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 June 2011 10:48, Gavin McDonaldga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have at least three +1
Re: [VOTE] Release Maven Enforcer version 1.0.1 - Take 2
hrm, sorry but I think there is actually a problem now with the stage site. In r1136499 [1] you removed the version number from the staging location. I'm not sure if there is a formal rule but we usually stage the RC sites at a unique location that is kept after the release for reference. For instance: http://maven.apache.org/plugins/maven-surefire-plugin-2.9/ http://maven.apache.org/plugins/maven-surefire-plugin-2.8/ http://maven.apache.org/plugins/maven-surefire-plugin-2.7/ etc. The staging location you specified now will be overwritten at the next release. Problem is I'm not sure if relative links will work with the versioned locations, I will try to find a minute today to test. sigh... :( -Lukas [1] http://svn.apache.org/viewvc?view=revisionrevision=1136499 Kristian Rosenvold wrote: Hi, The release includes the enforcer-plugin, enforcer-rules and enforcer-api modules. The site-staging problems from take 1 were fixed in r1136499. The only diff between this vote and take 1 is the site deployment. We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=16879 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MENFORCER+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-011/ Staging site: http://maven.apache.org/staging/plugins/maven-enforcer-plugin/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - 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: [VOTE] Release Maven Enforcer Plugin version 1.0.1 - Vote Cancelled
Isn't the correct staging site here:? http://maven.apache.org/plugins/maven-enforcer-plugin-1.0.1/ It got deployed by you yesterday... HTH, -Lukas Kristian Rosenvold wrote: There is something weird with the multi-module site in enforcer. I don't have the time to debug this one at the moment so I'm cancelling the enforcer vote instead of keeping you all in suspense. Kristian On Wed, Jun 15, 2011 at 8:48 PM, Karl Heinz Marbaisekhmarba...@gmx.de wrote: Hi, Also the Custom Rules - Writing a custom rule produces the same... after waiting a full day nothing changed...which means the missing pages are there... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - 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: [VOTE] Release Maven Enforcer Plugin version 1.0.1 - Vote Cancelled
Somewhat confused now: is this vote for the enforcer-plugin alone? Ie did you only stage-deploy the plugin site or the whole enforcer site? (I suppose this needs to be released and voted on as well?) The plugin site uses relative links in the menu that lead out of the current project, so these links will get broken if different modules get stage-deployed to different locations, as seems to be the case here. My guess is that using site-plugin-2.3 should fix the problem (and stage-deploy of a multi-module project is a real pain with 2.2 anyway...), but in any case you need to stage-deploy the whole enforcer site if the relative links should work. HTH, -Lukas Kristian Rosenvold wrote: Well yes, it's there, but the left-hand menu items point to the current production version instead of the newly staged versions. This seems to be because the xref between the plugin (with a specific url) and the remaining enforcere modules (with a different url) does not work when staging. If I stage locally and just copy everything manually to a single folder it works. This looks like it'll work if I did the production release, but the cross reference links in site.xml uses relative adressing to link from the plugin to the enforcer rules. I'm a bit at loss at what is the correct way to fix it. Kristian Den 16.06.2011 11:17, skrev Lukas Theussl: Isn't the correct staging site here:? http://maven.apache.org/plugins/maven-enforcer-plugin-1.0.1/ It got deployed by you yesterday... HTH, -Lukas Kristian Rosenvold wrote: There is something weird with the multi-module site in enforcer. I don't have the time to debug this one at the moment so I'm cancelling the enforcer vote instead of keeping you all in suspense. Kristian On Wed, Jun 15, 2011 at 8:48 PM, Karl Heinz Marbaisekhmarba...@gmx.de wrote: Hi, Also the Custom Rules - Writing a custom rule produces the same... after waiting a full day nothing changed...which means the missing pages are there... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Enforcer Plugin version 1.0.1 - Vote Cancelled
PS: I don't think that's a reason to cancel the vote, the links will be correct on the final site. -Lukas Kristian Rosenvold wrote: Well yes, it's there, but the left-hand menu items point to the current production version instead of the newly staged versions. This seems to be because the xref between the plugin (with a specific url) and the remaining enforcere modules (with a different url) does not work when staging. If I stage locally and just copy everything manually to a single folder it works. This looks like it'll work if I did the production release, but the cross reference links in site.xml uses relative adressing to link from the plugin to the enforcer rules. I'm a bit at loss at what is the correct way to fix it. Kristian Den 16.06.2011 11:17, skrev Lukas Theussl: Isn't the correct staging site here:? http://maven.apache.org/plugins/maven-enforcer-plugin-1.0.1/ It got deployed by you yesterday... HTH, -Lukas Kristian Rosenvold wrote: There is something weird with the multi-module site in enforcer. I don't have the time to debug this one at the moment so I'm cancelling the enforcer vote instead of keeping you all in suspense. Kristian On Wed, Jun 15, 2011 at 8:48 PM, Karl Heinz Marbaisekhmarba...@gmx.de wrote: Hi, Also the Custom Rules - Writing a custom rule produces the same... after waiting a full day nothing changed...which means the missing pages are there... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release version 21 of the parent POM for maven plugins
+1 -Lukas Benson Margulies wrote: Hi, We solved 1 issues: ** Improvement * [MPOM-12] - Update maven-plugins to new org.apache.maven:maven-parent:20 There are no open JIRAs against the maven-plugins parent. http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?r1=1135900r2=1135901diff_format=h Staging repo: https://repository.apache.org/content/repositories/maven-014/ Staging site: http://maven.apache.org/plugins/maven-plugins-21/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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
