Re: SIte plugin 1.8 required
Il gio 8 nov 2018, 21:34 Olivier Lamy ha scritto: > Hi > No much negative comments here > https://issues.apache.org/jira/browse/MSITE-828 or > https://github.com/apache/maven-site-plugin/pull/3. > So I guess it's all good? > it looks good to me. Off topic: To me github Pull Requests makes review simpler Cheers Enrico > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy > -- -- Enrico Olivelli
Re: Site plugin
Hi Jason, Looking at the stack trace it seems to be the remote resources plugin that is throwing an NPE. Didn't you release 1.5 of that plugin because of issues with core? Your build is using 1.4... -- Dennis Lundberg Den 22 feb 2014 05:30 skrev Jason van Zyl ja...@takari.io: Not sure who looks after the site plugin these days but I can't run the staging part to copy it over to the production site: In the release checkout I ran: mvn -Preporting site site:stage and got: https://gist.github.com/jvanzyl/9148731 I'll continue on with the rest of the work but I will release tomorrow regardless. I don't have time to debug the site plugin. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Site plugin
That version of the site plugin we have configured just doesn't work with newer versions of Maven. I ran the command with Maven 3.0.4 and it works. We are a long, long, long way from push button releases. On Feb 22, 2014, at 1:54 AM, Dennis Lundberg denn...@apache.org wrote: Hi Jason, Looking at the stack trace it seems to be the remote resources plugin that is throwing an NPE. Didn't you release 1.5 of that plugin because of issues with core? Your build is using 1.4... -- Dennis Lundberg Den 22 feb 2014 05:30 skrev Jason van Zyl ja...@takari.io: Not sure who looks after the site plugin these days but I can't run the staging part to copy it over to the production site: In the release checkout I ran: mvn -Preporting site site:stage and got: https://gist.github.com/jvanzyl/9148731 I'll continue on with the rest of the work but I will release tomorrow regardless. I don't have time to debug the site plugin. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Re: Site plugin
Which versions of Maven failed for you? On Sat, Feb 22, 2014 at 7:03 PM, Jason van Zyl ja...@takari.io wrote: That version of the site plugin we have configured just doesn't work with newer versions of Maven. I ran the command with Maven 3.0.4 and it works. We are a long, long, long way from push button releases. On Feb 22, 2014, at 1:54 AM, Dennis Lundberg denn...@apache.org wrote: Hi Jason, Looking at the stack trace it seems to be the remote resources plugin that is throwing an NPE. Didn't you release 1.5 of that plugin because of issues with core? Your build is using 1.4... -- Dennis Lundberg Den 22 feb 2014 05:30 skrev Jason van Zyl ja...@takari.io: Not sure who looks after the site plugin these days but I can't run the staging part to copy it over to the production site: In the release checkout I ran: mvn -Preporting site site:stage and got: https://gist.github.com/jvanzyl/9148731 I'll continue on with the rest of the work but I will release tomorrow regardless. I don't have time to debug the site plugin. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site plugin
I had build of master I was using. jvz On Feb 22, 2014, at 11:25 AM, Dennis Lundberg dennisl.apa...@gmail.com wrote: Which versions of Maven failed for you? On Sat, Feb 22, 2014 at 7:03 PM, Jason van Zyl ja...@takari.io wrote: That version of the site plugin we have configured just doesn't work with newer versions of Maven. I ran the command with Maven 3.0.4 and it works. We are a long, long, long way from push button releases. On Feb 22, 2014, at 1:54 AM, Dennis Lundberg denn...@apache.org wrote: Hi Jason, Looking at the stack trace it seems to be the remote resources plugin that is throwing an NPE. Didn't you release 1.5 of that plugin because of issues with core? Your build is using 1.4... -- Dennis Lundberg Den 22 feb 2014 05:30 skrev Jason van Zyl ja...@takari.io: Not sure who looks after the site plugin these days but I can't run the staging part to copy it over to the production site: In the release checkout I ran: mvn -Preporting site site:stage and got: https://gist.github.com/jvanzyl/9148731 I'll continue on with the rest of the work but I will release tomorrow regardless. I don't have time to debug the site plugin. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare -- 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
Re: Site plugin
Yeah need to update site plugin to 3.3 and it should work on mvn 2.x and 3.x (yes 2.x is EOL already but anyways) On Saturday, 22 February 2014, Jason van Zyl ja...@tesla.io wrote: I had build of master I was using. jvz On Feb 22, 2014, at 11:25 AM, Dennis Lundberg dennisl.apa...@gmail.comjavascript:; wrote: Which versions of Maven failed for you? On Sat, Feb 22, 2014 at 7:03 PM, Jason van Zyl ja...@takari.iojavascript:; wrote: That version of the site plugin we have configured just doesn't work with newer versions of Maven. I ran the command with Maven 3.0.4 and it works. We are a long, long, long way from push button releases. On Feb 22, 2014, at 1:54 AM, Dennis Lundberg denn...@apache.orgjavascript:; wrote: Hi Jason, Looking at the stack trace it seems to be the remote resources plugin that is throwing an NPE. Didn't you release 1.5 of that plugin because of issues with core? Your build is using 1.4... -- Dennis Lundberg Den 22 feb 2014 05:30 skrev Jason van Zyl ja...@takari.iojavascript:; : Not sure who looks after the site plugin these days but I can't run the staging part to copy it over to the production site: In the release checkout I ran: mvn -Preporting site site:stage and got: https://gist.github.com/jvanzyl/9148731 I'll continue on with the rest of the work but I will release tomorrow regardless. I don't have time to debug the site plugin. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
Re: Site plugin
the site plugin itself works but the site plugin launches a lot of other plugins, like remote resources plugin which is apparently failing here did you try to update remote resources to 1.5, like Dennis proposed? Regards, Hervé Le samedi 22 février 2014 10:03:14 Jason van Zyl a écrit : That version of the site plugin we have configured just doesn't work with newer versions of Maven. I ran the command with Maven 3.0.4 and it works. We are a long, long, long way from push button releases. On Feb 22, 2014, at 1:54 AM, Dennis Lundberg denn...@apache.org wrote: Hi Jason, Looking at the stack trace it seems to be the remote resources plugin that is throwing an NPE. Didn't you release 1.5 of that plugin because of issues with core? Your build is using 1.4... -- Dennis Lundberg Den 22 feb 2014 05:30 skrev Jason van Zyl ja...@takari.io: Not sure who looks after the site plugin these days but I can't run the staging part to copy it over to the production site: In the release checkout I ran: mvn -Preporting site site:stage and got: https://gist.github.com/jvanzyl/9148731 I'll continue on with the rest of the work but I will release tomorrow regardless. I don't have time to debug the site plugin. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.) Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Re: Site plugin and forked executions
I had a second thought about aggregate reporting plugins (or more precisely goal). Since some time, we're applying a new pattern where there is a separate reporting goal for aggregate (previously, aggregate was a parameter). In the maven parent pom, we're explicitely setting a reportSet configuration for m-javadoc-p, which is the first plugin implementing this pattern IIRC. But for other plugins, we don't define reportSets: then by default, every reporting goals are used, ie aggregate and non-aggregate. Now I understand why I'm experiencing twice PMD or Checkstyle runs in components lately... I just created MPOM-39 for tracking this issue. Regards, Hervé [1] https://issues.apache.org/jira/browse/MPOM-39 Le lundi 19 novembre 2012 20:50:07 Dennis Lundberg a écrit : Hi Yes, most likely. There are a bunch of JIRAs for the Site Plugin about issues like the one you're experiencing. The two things that stands out from memory are: - aggregate reporting plugins (like Javadoc in your example) - using the new way of configuring reporting plugins, i.e. under the Site Plugin's configuration element I try to stay away from both if I can... On 2012-11-19 14:31, Benson Margulies wrote: Or is this the real villan: [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [INFO] [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo [INFO] [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies bimargul...@gmail.com wrote: Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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 plugin and forked executions
On Tue, Nov 27, 2012 at 8:48 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: I had a second thought about aggregate reporting plugins (or more precisely goal). Since some time, we're applying a new pattern where there is a separate reporting goal for aggregate (previously, aggregate was a parameter). In the maven parent pom, we're explicitely setting a reportSet configuration for m-javadoc-p, which is the first plugin implementing this pattern IIRC. But for other plugins, we don't define reportSets: then by default, every reporting goals are used, ie aggregate and non-aggregate. Now I understand why I'm experiencing twice PMD or Checkstyle runs in components lately... Now there's no use of the aggregate reportSet. If we wanted aggregation, how would we write it do happen in the right place? I just created MPOM-39 for tracking this issue. Regards, Hervé [1] https://issues.apache.org/jira/browse/MPOM-39 Le lundi 19 novembre 2012 20:50:07 Dennis Lundberg a écrit : Hi Yes, most likely. There are a bunch of JIRAs for the Site Plugin about issues like the one you're experiencing. The two things that stands out from memory are: - aggregate reporting plugins (like Javadoc in your example) - using the new way of configuring reporting plugins, i.e. under the Site Plugin's configuration element I try to stay away from both if I can... On 2012-11-19 14:31, Benson Margulies wrote: Or is this the real villan: [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [INFO] [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo [INFO] [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies bimargul...@gmail.com wrote: Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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 plugin and forked executions
Le mardi 27 novembre 2012 21:45:16 Benson Margulies a écrit : On Tue, Nov 27, 2012 at 8:48 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: I had a second thought about aggregate reporting plugins (or more precisely goal). Since some time, we're applying a new pattern where there is a separate reporting goal for aggregate (previously, aggregate was a parameter). In the maven parent pom, we're explicitely setting a reportSet configuration for m-javadoc-p, which is the first plugin implementing this pattern IIRC. But for other plugins, we don't define reportSets: then by default, every reporting goals are used, ie aggregate and non-aggregate. Now I understand why I'm experiencing twice PMD or Checkstyle runs in components lately... Now there's no use of the aggregate reportSet. If we wanted aggregation, how would we write it do happen in the right place? you can look at Maven core's pom.xml, which defines aggregated reports for javadoc notice: 1. this pom actually defines non-aggregate reportSets, which duplicates the default reportSets: I'm waiting for Git rw to remove them 2. aggregate reportSets are marked inheritfalse/inherit to avoid being run in child modules, which is a good practice to give to users 3. AFAIK, this is not well documented in m-site-p (is it even documented in another place than pom descriptor [1]?): now that I think I understand well, I should be able to write something, probably in [2] , but any help appreciated Regards, Hervé [1] http://maven.apache.org/ref/3.1-SNAPSHOT/maven- model/maven.html#class_reportSet [2] http://maven.apache.org/plugins/maven-site-plugin/examples/configuring- reports.html I just created MPOM-39 for tracking this issue. Regards, Hervé [1] https://issues.apache.org/jira/browse/MPOM-39 Le lundi 19 novembre 2012 20:50:07 Dennis Lundberg a écrit : Hi Yes, most likely. There are a bunch of JIRAs for the Site Plugin about issues like the one you're experiencing. The two things that stands out from memory are: - aggregate reporting plugins (like Javadoc in your example) - using the new way of configuring reporting plugins, i.e. under the Site Plugin's configuration element I try to stay away from both if I can... On 2012-11-19 14:31, Benson Margulies wrote: Or is this the real villan: [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [INFO] [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo [INFO] [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies bimargul...@gmail.com wrote: Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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 plugin and forked executions
Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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 plugin and forked executions
Or is this the real villan: [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [INFO] [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo [INFO] [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies bimargul...@gmail.com wrote: Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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 plugin and forked executions
Hi Yes, most likely. There are a bunch of JIRAs for the Site Plugin about issues like the one you're experiencing. The two things that stands out from memory are: - aggregate reporting plugins (like Javadoc in your example) - using the new way of configuring reporting plugins, i.e. under the Site Plugin's configuration element I try to stay away from both if I can... On 2012-11-19 14:31, Benson Margulies wrote: Or is this the real villan: [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [INFO] [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo [INFO] [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies bimargul...@gmail.com wrote: Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site plugin and forked executions
The second wasn't involved in this case. The first was. On Mon, Nov 19, 2012 at 2:50 PM, Dennis Lundberg denn...@apache.org wrote: Hi Yes, most likely. There are a bunch of JIRAs for the Site Plugin about issues like the one you're experiencing. The two things that stands out from memory are: - aggregate reporting plugins (like Javadoc in your example) - using the new way of configuring reporting plugins, i.e. under the Site Plugin's configuration element I try to stay away from both if I can... On 2012-11-19 14:31, Benson Margulies wrote: Or is this the real villan: [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [INFO] [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo [INFO] [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies bimargul...@gmail.com wrote: Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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 -- 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
Re: Site plugin and forked executions
Feel like doing the manual cleansing of the output file and just keep * lifecycle events [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] * plugin details [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo * forking info messages [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] At least you can get a few more eyes having a look at the problem. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site plugin and forked executions
Le dimanche 18 novembre 2012 17:24:14 Benson Margulies a écrit : Folks, I myself feel like a bit of a looping site build myself on this subject, and I apologize. The build of Apache Accumulo is showing the 'classic' symptoms of running more or less forever with 'site:site', due, apparently, to some forked execution that causes it to do the same things over and over. Is this really the intended behavior? of course not I'd like to help cure it, but I am still very much feeling an idiot about the whole business. this is something really hard to understand then to fix: I'm fighting against such case for a long time now. There was some time I didn't see such a problem. From what I understand, the m-site-p doesn't fork executions but some plugins do, like m-javadoc-p. Perhaps a consequence of MJAVADOC-171? Try to remove some javadoc reports, it can help... (sorry, no better idea...) Regards, Hervé --benson - 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 plugin and forked executions
On Sun, Nov 18, 2012 at 5:45 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 18 novembre 2012 17:24:14 Benson Margulies a écrit : Folks, I myself feel like a bit of a looping site build myself on this subject, and I apologize. The build of Apache Accumulo is showing the 'classic' symptoms of running more or less forever with 'site:site', due, apparently, to some forked execution that causes it to do the same things over and over. Is this really the intended behavior? of course not I'd like to help cure it, but I am still very much feeling an idiot about the whole business. this is something really hard to understand then to fix: I'm fighting against such case for a long time now. There was some time I didn't see such a problem. From what I understand, the m-site-p doesn't fork executions but some plugins do, like m-javadoc-p. Perhaps a consequence of MJAVADOC-171? Try to remove some javadoc reports, it can help... In my past life, javadoc loomed large here. In the accumulo build, what looks most suspicious is cobertura, which is a big forker of executions. However, given that there are reporting plugins that *do* fork executions, what can we do here? Somehow, don't we want to limit the execution plans in the forked executions to avoid all this redundancy? (sorry, no better idea...) Regards, Hervé --benson - 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 plugin and forked executions
cobertura, another usual suspect I really don't understand this aspect, and for the moment, I gave up... Le dimanche 18 novembre 2012 17:50:02 Benson Margulies a écrit : On Sun, Nov 18, 2012 at 5:45 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 18 novembre 2012 17:24:14 Benson Margulies a écrit : Folks, I myself feel like a bit of a looping site build myself on this subject, and I apologize. The build of Apache Accumulo is showing the 'classic' symptoms of running more or less forever with 'site:site', due, apparently, to some forked execution that causes it to do the same things over and over. Is this really the intended behavior? of course not I'd like to help cure it, but I am still very much feeling an idiot about the whole business. this is something really hard to understand then to fix: I'm fighting against such case for a long time now. There was some time I didn't see such a problem. From what I understand, the m-site-p doesn't fork executions but some plugins do, like m-javadoc-p. Perhaps a consequence of MJAVADOC-171? Try to remove some javadoc reports, it can help... In my past life, javadoc loomed large here. In the accumulo build, what looks most suspicious is cobertura, which is a big forker of executions. However, given that there are reporting plugins that *do* fork executions, what can we do here? Somehow, don't we want to limit the execution plans in the forked executions to avoid all this redundancy? (sorry, no better idea...) Regards, Hervé --benson - 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 plugin and forked executions
As Hervé says, it'll depend on the reports you're using. Cobertura forks to ensure the tests are run with the instrumented classes - though I believe most code coverage plugins have some options to inject that into your main build stream and then produce the report on the data at the end. - Brett On 19/11/2012, at 9:52 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: cobertura, another usual suspect I really don't understand this aspect, and for the moment, I gave up... Le dimanche 18 novembre 2012 17:50:02 Benson Margulies a écrit : On Sun, Nov 18, 2012 at 5:45 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 18 novembre 2012 17:24:14 Benson Margulies a écrit : Folks, I myself feel like a bit of a looping site build myself on this subject, and I apologize. The build of Apache Accumulo is showing the 'classic' symptoms of running more or less forever with 'site:site', due, apparently, to some forked execution that causes it to do the same things over and over. Is this really the intended behavior? of course not I'd like to help cure it, but I am still very much feeling an idiot about the whole business. this is something really hard to understand then to fix: I'm fighting against such case for a long time now. There was some time I didn't see such a problem. From what I understand, the m-site-p doesn't fork executions but some plugins do, like m-javadoc-p. Perhaps a consequence of MJAVADOC-171? Try to remove some javadoc reports, it can help... In my past life, javadoc loomed large here. In the accumulo build, what looks most suspicious is cobertura, which is a big forker of executions. However, given that there are reporting plugins that *do* fork executions, what can we do here? Somehow, don't we want to limit the execution plans in the forked executions to avoid all this redundancy? (sorry, no better idea...) Regards, Hervé --benson - 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 -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site plugin and forked executions
On Mon, Nov 19, 2012 at 9:39 AM, Brett Porter br...@apache.org wrote: As Hervé says, it'll depend on the reports you're using. Cobertura forks to ensure the tests are run with the instrumented classes - though I believe most code coverage plugins have some options to inject that into your main build stream and then produce the report on the data at the end. There is another post I've made because I have had this problem in the past. My resolution is to use -X and pipe the output to a file. Then manually go through and Maven 3 has excellent comments about what it is doing so it is obvious where a plugin is starting and potentially forking. I just deleted everything but those markers and then analyze what they are telling me. I recommend doing this in two steps, 1) delete everything else 2) analyze. As trying to scan through the file by eye misses things and caused me to head off in the wrong directions. Once I had just the bits I needed it was obvious where the problem was. Which probably brings us to the logging discussion currently going on... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site plugin and forked executions
On Sun, Nov 18, 2012 at 7:13 PM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 9:39 AM, Brett Porter br...@apache.org wrote: As Hervé says, it'll depend on the reports you're using. Cobertura forks to ensure the tests are run with the instrumented classes - though I believe most code coverage plugins have some options to inject that into your main build stream and then produce the report on the data at the end. There is another post I've made because I have had this problem in the past. My resolution is to use -X and pipe the output to a file. Then manually go through and Maven 3 has excellent comments about what it is doing so it is obvious where a plugin is starting and potentially forking. I just deleted everything but those markers and then analyze what they are telling me. I recommend doing this in two steps, 1) delete everything else 2) analyze. As trying to scan through the file by eye misses things and caused me to head off in the wrong directions. Once I had just the bits I needed it was obvious where the problem was. Which probably brings us to the logging discussion currently going on... Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? - 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 plugin and forked executions
On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site plugin on wiki
confirmed. copypaste did here http://maven.apache.org/plugins/maven-site-plugin/maven-3.html 2012/2/13 Brett Porter br...@apache.org: Hi, I think a few people would have links to https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+and+site+plugin for directions during the transition - but my understanding is that this is all captured on the Site plugin documentation now. Before I replace the page with a pointer to that, can anyone confirm if that is correct? Thanks, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- 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: Site plugin on wiki
Done - thanks! On 14/02/2012, at 8:16 AM, Olivier Lamy wrote: confirmed. copypaste did here http://maven.apache.org/plugins/maven-site-plugin/maven-3.html 2012/2/13 Brett Porter br...@apache.org: Hi, I think a few people would have links to https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+and+site+plugin for directions during the transition - but my understanding is that this is all captured on the Site plugin documentation now. Before I replace the page with a pointer to that, can anyone confirm if that is correct? Thanks, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- 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 -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site Plugin
Jason van Zyl wrote: You can thank Benjamin and Olivier. Not sure about Olivier but I haven't touched maven-site-plugin trunk since months... I believe this compliment belongs more to Dennis, Lukas and Vincent. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site Plugin
Hi, Same for me (except if ralph use maven 3.x and the site plugin for maven 3.x :-) ) -- Olivier 2010/1/1 Benjamin Bentmann benjamin.bentm...@udo.edu: Jason van Zyl wrote: You can thank Benjamin and Olivier. Not sure about Olivier but I haven't touched maven-site-plugin trunk since months... I believe this compliment belongs more to Dennis, Lukas and Vincent. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site Plugin
Sorry, when I see trunk I think core. Yup it's the site plugin people. I initially thought Ralph was running the site plugin with Maven trunk. On 2009-12-31, at 6:25 PM, Ralph Goers wrote: I just wanted to say that I have been unable to build the site for Commons VFS ever since I converted it to use Maven 2 as the links were hopelessly broken. However, today I compiled trunk and configured VFS to use that and it is now working fine. I don't know if this is a result of fixes for http://jira.codehaus.org/browse/MSITE-358 or something else, but I definitely appreciate whoever fixed this. Thanks, Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site Plugin
That sounds like a user visible improvement ;-) You can thank Benjamin and Olivier. On 2009-12-31, at 6:25 PM, Ralph Goers wrote: I just wanted to say that I have been unable to build the site for Commons VFS ever since I converted it to use Maven 2 as the links were hopelessly broken. However, today I compiled trunk and configured VFS to use that and it is now working fine. I don't know if this is a result of fixes for http://jira.codehaus.org/browse/MSITE-358 or something else, but I definitely appreciate whoever fixed this. Thanks, Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: site plugin release planning
Dennis Lundberg wrote: Lukas Theussl wrote: Hi, I was looking at the jira roadmap for the site plugin, thinking about a release plan for 2.1. The main change so far is the upgrade to doxia 1.1, I think it would be a good idea to concentrate the next release on issues that are related that. In particular, I'd like to fix all these annoying bugs with links (eg MSITE-395, MSITE-404, MSITE-409 and many others), which might necessitate another doxia release. It's good to keep the releases small and focused. So +1 from me for a special Doxia upgrade release. +1 also for fixing the path issues you mentioned in the near future. My findings on those issues are that the problem lies somewhere inside Doxia, so I think another Doxia release will be necessary. If that is the case, I think it is wise to do a release of the Site plugin with Doxia 1.1.1 first. I have fixed DOXIASITETOOLS-29 and checked that MSITE-404 gets fixed with it. My preference would be to bump the doxia dep in site-plugin to 1.1.2-SNAP, and push the number of MSITE issues down, fixing doxia bugs as we go along (finally we can use the site plugin to test doxia again... :) ). Some of the open issues have blocker status so I don't see the point of another site release before those are fixed. WDYT? -Lukas Right now there are also a number of other issues scheduled that are not related (eg MSITE-79, MSITE-206, MSITE-326) which I would like to leave out and schedule for a later release. +1 to leave those issues out. Is this ok with everyone? -Lukas - 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 plugin release planning
Lukas Theussl wrote: Dennis Lundberg wrote: Lukas Theussl wrote: Hi, I was looking at the jira roadmap for the site plugin, thinking about a release plan for 2.1. The main change so far is the upgrade to doxia 1.1, I think it would be a good idea to concentrate the next release on issues that are related that. In particular, I'd like to fix all these annoying bugs with links (eg MSITE-395, MSITE-404, MSITE-409 and many others), which might necessitate another doxia release. It's good to keep the releases small and focused. So +1 from me for a special Doxia upgrade release. +1 also for fixing the path issues you mentioned in the near future. My findings on those issues are that the problem lies somewhere inside Doxia, so I think another Doxia release will be necessary. If that is the case, I think it is wise to do a release of the Site plugin with Doxia 1.1.1 first. I have fixed DOXIASITETOOLS-29 and checked that MSITE-404 gets fixed with it. That's great news! One question on this though, as I read through your commits: Doesn't Doxia Sitetools need to upgrade it's dependency on Plexus Utils, since DOXIASITETOOLS-29 is related to PLXUTILS-116? Or did you work around PLXUTILS-116 in your patch for DOXIASITETOOLS-29? My preference would be to bump the doxia dep in site-plugin to 1.1.2-SNAP, and push the number of MSITE issues down, fixing doxia bugs as we go along (finally we can use the site plugin to test doxia again... :) ). Some of the open issues have blocker status so I don't see the point of another site release before those are fixed. WDYT? I have difficulties making my mind up about this. On one hand I think it would be good to get Doxia 1.1.x out ASAP to have it tried in the real world. If we delay the real world deployment for too long, the jump might be to high to release it and it might also drag out over time. On the other hand I acknowledge that the issues you listed are very important to fix, because they are causing users a lot of grief. The blocker status has often been set by users rather than developers though. I do believe that MSITE-404 is the core of these issues and if that is fixed the others might be solved as well. Let's do a 1.1.2 release of Doxia and have Site plugin 2.1 use that version. But let us keep the number of bug fixes for 1.1.2 low, so that it can be released fairly soon. -Lukas Right now there are also a number of other issues scheduled that are not related (eg MSITE-79, MSITE-206, MSITE-326) which I would like to leave out and schedule for a later release. +1 to leave those issues out. Is this ok with everyone? -Lukas - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: site plugin release planning
Lukas Theussl wrote: Right now there are also a number of other issues scheduled that are not related (eg MSITE-79, MSITE-206, MSITE-326) which I would like to leave out and schedule for a later release. Is this ok with everyone? +1, I don't see the point in blocking a release or even just a particular version number just because of some issues that were scheduled long time back and that currently have no committer working on them. Let's move forward, with whatever issue set we can fix. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: site plugin release planning
Lukas Theussl wrote: Hi, I was looking at the jira roadmap for the site plugin, thinking about a release plan for 2.1. The main change so far is the upgrade to doxia 1.1, I think it would be a good idea to concentrate the next release on issues that are related that. In particular, I'd like to fix all these annoying bugs with links (eg MSITE-395, MSITE-404, MSITE-409 and many others), which might necessitate another doxia release. It's good to keep the releases small and focused. So +1 from me for a special Doxia upgrade release. +1 also for fixing the path issues you mentioned in the near future. My findings on those issues are that the problem lies somewhere inside Doxia, so I think another Doxia release will be necessary. If that is the case, I think it is wise to do a release of the Site plugin with Doxia 1.1.1 first. Right now there are also a number of other issues scheduled that are not related (eg MSITE-79, MSITE-206, MSITE-326) which I would like to leave out and schedule for a later release. +1 to leave those issues out. Is this ok with everyone? -Lukas - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: site plugin release planning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Hello, I was looking at the jira roadmap for the site plugin, thinking about a release plan for 2.1. The main change so far is the upgrade to doxia 1.1, I think it would be a good idea to concentrate the next release on issues that are related that. In particular, I'd like to fix all these annoying bugs with links (eg MSITE-395, MSITE-404, MSITE-409 and many others), which might necessitate another doxia release. great to hear. Did already someone report that if distributionManagement is present but has no site then site:stage fails. This is bad if you need to have distributionManagement for having a repository section. I personally think that the entire distributionManagement in the pom.xml was a design mistake because this is something that should be covered by settings.xml but however... I currently comment out my distributionManagement to invoke site:stage and get the expected result because with a site section wired subfolders are created that break my rsync-script. Shall I file a jira ticket or is this already known? Right now there are also a number of other issues scheduled that are not related (eg MSITE-79, MSITE-206, MSITE-326) which I would like to leave out and schedule for a later release. Is this ok with everyone? -Lukas +1 for me but I am no committer... Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpqCEsACgkQmPuec2Dcv/8w4gCePN6jqbMPLVb28Kfh30ETeyf7 jqIAoJbE6jMzKn0AN/4lSuk8B1boGmWN =P0+H -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: site plugin [was: Re: svn commit: r764090 - /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteStageDeployMojo.java]
Hi Dennis, 2009/4/28 Dennis Lundberg denn...@apache.org: Let me do a 2.0.1 release of the stuff that is in trunk, before we make the switch to Doxia 1.1. Doxia 1.1.1 has been released and I plan to release the site plugin 2.1 soon. I see 2 options: - wait for the 2.0.1 release (do you plan it soon?) - create a 2.0.1 branch for the release/maintenance In both cases, we need to bring home the 2.1 branch to trunk. Cheers, Vincent - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: site plugin [was: Re: svn commit: r764090 - /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteStageDeployMojo.java]
Lukas Theussl wrote:
Benjamin Bentmann wrote:
Author: bentmann
Date: Fri Apr 10 22:42:19 2009
New Revision: 764090
URL: http://svn.apache.org/viewvc?rev=764090view=rev
Log:
[MSITE-400] Make repository id for stage-deploy configurable
Modified:
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteStageDeployMojo.java
Modified:
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteStageDeployMojo.java
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteStageDeployMojo.java?rev=764090r1=764089r2=764090view=diff
==
---
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteStageDeployMojo.java
(original)
+++
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/SiteStageDeployMojo.java
Fri Apr 10 22:42:19 2009
@@ -74,6 +74,16 @@
private String stagingSiteURL;
/**
+ * The identifier of the repository where the staging site will
be deployed. This id will be used to lookup a
+ * corresponding codelt;servergt;/code entry from the
codesettings.xml/code. If a matching
+ * codelt;servergt;/code entry is found, its configured
credentials will be used for authentication.
+ * + * @parameter expression=${stagingRepositoryId}
default-value=stagingSite
+ * @since 2.0.1
+ */
+private String stagingRepositoryId;
I would have liked to bump the plugin version to 2.1 due to this
feature addition but noticed there is already a bucket for 2.1 in JIRA
(targetting Doxia 1.1). So I wasn't sure whether the 2.0.1 version
should just be dropped and its issues merged into the 2.1 bucket or
whether 2.0.1 should be renamed to 2.1 and 2.1 to 2.2. Given Dennis is
doing most of the work on the Site Plugin, I'm leaving the proper
versioning to his judgement.
Dennis,
What are your plans for the site plugin? Any objections to bumping trunk
to 2.1-SNAPSHOT using Doxia 1.1? An eventual 2.0.x release could be done
from a branch. WDYT?
Let me do a 2.0.1 release of the stuff that is in trunk, before we make
the switch to Doxia 1.1.
-Lukas
Benjamin
-
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
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site plugin feature of using Velocity
On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
You've lost me, sorry. What type of page are you trying to create?
Any page, Velocity will be used to render any of the pages. It would
just work anywhere in the site.
I can see how this makes it possible to make lightweight reports. I
don't see how it's useful in most documentation. I would think the
former would naturally be in a separate section somewhere, as
opposed to having to specify pages.
I think what Emmanuel was saying was that making everything
velocity would mean stuff that had things that looked like
expressions now would end up different (you are trying to explain $
{project.build.directory} instead of substitute it).
That's really easy to escape, and we can tell people it's a Velocity
document and it's well documented. I think that would be easier then
juggling pages around to be rendered as it will be the case where you
want the literal ${project.build.directory} and interpolate some
other project information. This is always the case with Velocity
documents which is why there are escaping tools, #macros, and the
actual escaping characters.
Jason.
- Brett
On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
I think I'd like the option to, but not every time. Maybe it
belongs closer to the reporting infrastructure (the download
pages are more like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the
ability to write simple velocity pages that get processed to spit
out apt that gets added to the list of docs to generate. Rather
than affecting the APT itself, it is a step before
WDYT?
I'm not sure what you mean, not everytime. I think if you turn it
on you wouldn't want to have to specify what pages you want to be
interpolated. I think that would be inconvenient. And though it
doesn't fully stream now it will so it will actually be faster
then the current site plugin. So the performance will be higher
once it streams instead of collecting the page content in memory
to process it. So speed is not going to be an issue and it's not
really noticeable right now.
This is only for sites and would be very handy. For example would
then be able to make new types of reports and share them. They
just pop them into their site structure (and move toward being
packaged up as reports) and they will render with their project
information.
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
Jason.
- Brett
On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it
but there are a couple options.
1) Use Velocity to process the pages before going to the
respective doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of
model
We can't interpolate every time. Sometimes, we need to
interpolate ${project.*} and sometimes not in dox
Emmanuel
I like the Velocity option, not sure if being on by default or
not is good. When there is a parse error I'm currently just
rendering the original document as is where you can see a
warning and the full error in debug mode. This is for 2.0 so it
is a new feature but would allow some cool stuff with.
Jason.
--
---
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
Could this velocity pre-processor just be a plugin that gets run in the
pre-site phase - unrelated to doxia?
Eric
On 3/17/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
You've lost me, sorry. What type of page are you trying to create?
Any page, Velocity will be used to render any of the pages. It would
just work anywhere in the site.
I can see how this makes it possible to make lightweight reports. I
don't see how it's useful in most documentation. I would think the
former would naturally be in a separate section somewhere, as
opposed to having to specify pages.
I think what Emmanuel was saying was that making everything
velocity would mean stuff that had things that looked like
expressions now would end up different (you are trying to explain $
{project.build.directory} instead of substitute it).
That's really easy to escape, and we can tell people it's a Velocity
document and it's well documented. I think that would be easier then
juggling pages around to be rendered as it will be the case where you
want the literal ${project.build.directory} and interpolate some
other project information. This is always the case with Velocity
documents which is why there are escaping tools, #macros, and the
actual escaping characters.
Jason.
- Brett
On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
I think I'd like the option to, but not every time. Maybe it
belongs closer to the reporting infrastructure (the download
pages are more like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the
ability to write simple velocity pages that get processed to spit
out apt that gets added to the list of docs to generate. Rather
than affecting the APT itself, it is a step before
WDYT?
I'm not sure what you mean, not everytime. I think if you turn it
on you wouldn't want to have to specify what pages you want to be
interpolated. I think that would be inconvenient. And though it
doesn't fully stream now it will so it will actually be faster
then the current site plugin. So the performance will be higher
once it streams instead of collecting the page content in memory
to process it. So speed is not going to be an issue and it's not
really noticeable right now.
This is only for sites and would be very handy. For example would
then be able to make new types of reports and share them. They
just pop them into their site structure (and move toward being
packaged up as reports) and they will render with their project
information.
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
Jason.
- Brett
On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it
but there are a couple options.
1) Use Velocity to process the pages before going to the
respective doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of
model
We can't interpolate every time. Sometimes, we need to
interpolate ${project.*} and sometimes not in dox
Emmanuel
I like the Velocity option, not sure if being on by default or
not is good. When there is a parse error I'm currently just
rendering the original document as is where you can see a
warning and the full error in debug mode. This is for 2.0 so it
is a new feature but would allow some cool stuff with.
Jason.
--
---
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Eric Redmond
http://codehaus.org/~eredmond
Re: Site plugin feature of using Velocity
On 17 Mar 07, at 12:08 PM 17 Mar 07, Eric Redmond wrote:
Could this velocity pre-processor just be a plugin that gets run in
the
pre-site phase - unrelated to doxia?
It could and that's what the velocity people seem to be doing on
their site, but I would really like to not have to configure anything.
I would like it to be useful generally, but if people object to it
being on by default (but for static site generation who cares), then
maybe a directory structure that gets processed by velocity. But then
you end up with a bunch of different directories. What I did was
process it with Velocity and if that attempt fails with a parsing
error just fall back to processing the raw document.
I want zero configuration, and it just work. I'll do any grunt work
to make that possible.
Jason.
Eric
On 3/17/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
You've lost me, sorry. What type of page are you trying to create?
Any page, Velocity will be used to render any of the pages. It would
just work anywhere in the site.
I can see how this makes it possible to make lightweight reports. I
don't see how it's useful in most documentation. I would think the
former would naturally be in a separate section somewhere, as
opposed to having to specify pages.
I think what Emmanuel was saying was that making everything
velocity would mean stuff that had things that looked like
expressions now would end up different (you are trying to explain $
{project.build.directory} instead of substitute it).
That's really easy to escape, and we can tell people it's a Velocity
document and it's well documented. I think that would be easier then
juggling pages around to be rendered as it will be the case where you
want the literal ${project.build.directory} and interpolate some
other project information. This is always the case with Velocity
documents which is why there are escaping tools, #macros, and the
actual escaping characters.
Jason.
- Brett
On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
I think I'd like the option to, but not every time. Maybe it
belongs closer to the reporting infrastructure (the download
pages are more like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the
ability to write simple velocity pages that get processed to spit
out apt that gets added to the list of docs to generate. Rather
than affecting the APT itself, it is a step before
WDYT?
I'm not sure what you mean, not everytime. I think if you turn it
on you wouldn't want to have to specify what pages you want to be
interpolated. I think that would be inconvenient. And though it
doesn't fully stream now it will so it will actually be faster
then the current site plugin. So the performance will be higher
once it streams instead of collecting the page content in memory
to process it. So speed is not going to be an issue and it's not
really noticeable right now.
This is only for sites and would be very handy. For example would
then be able to make new types of reports and share them. They
just pop them into their site structure (and move toward being
packaged up as reports) and they will render with their project
information.
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
Jason.
- Brett
On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it
but there are a couple options.
1) Use Velocity to process the pages before going to the
respective doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of
model
We can't interpolate every time. Sometimes, we need to
interpolate ${project.*} and sometimes not in dox
Emmanuel
I like the Velocity option, not sure if being on by default or
not is good. When there is a parse error I'm currently just
rendering the original document as is where you can see a
warning and the full error in debug mode. This is for 2.0 so it
is a new feature but would allow some cool stuff with.
Jason.
--
---
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Re: Site plugin feature of using Velocity
What about anything with a .vm extension?
download.apt.vm gets processed as vm first, then apt. We can do that
in Doxia with zero-configuration.
I really don't want it on by default, because it'll break existing
documents, and I can see situations where we might want to facilitate
different processors.
- Brett
On 18/03/2007, at 3:35 AM, Jason van Zyl wrote:
On 17 Mar 07, at 12:08 PM 17 Mar 07, Eric Redmond wrote:
Could this velocity pre-processor just be a plugin that gets run
in the
pre-site phase - unrelated to doxia?
It could and that's what the velocity people seem to be doing on
their site, but I would really like to not have to configure anything.
I would like it to be useful generally, but if people object to it
being on by default (but for static site generation who cares),
then maybe a directory structure that gets processed by velocity.
But then you end up with a bunch of different directories. What I
did was process it with Velocity and if that attempt fails with a
parsing error just fall back to processing the raw document.
I want zero configuration, and it just work. I'll do any grunt work
to make that possible.
Jason.
Eric
On 3/17/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
You've lost me, sorry. What type of page are you trying to create?
Any page, Velocity will be used to render any of the pages. It would
just work anywhere in the site.
I can see how this makes it possible to make lightweight
reports. I
don't see how it's useful in most documentation. I would think the
former would naturally be in a separate section somewhere, as
opposed to having to specify pages.
I think what Emmanuel was saying was that making everything
velocity would mean stuff that had things that looked like
expressions now would end up different (you are trying to
explain $
{project.build.directory} instead of substitute it).
That's really easy to escape, and we can tell people it's a Velocity
document and it's well documented. I think that would be easier then
juggling pages around to be rendered as it will be the case where
you
want the literal ${project.build.directory} and interpolate some
other project information. This is always the case with Velocity
documents which is why there are escaping tools, #macros, and the
actual escaping characters.
Jason.
- Brett
On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
I think I'd like the option to, but not every time. Maybe it
belongs closer to the reporting infrastructure (the download
pages are more like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the
ability to write simple velocity pages that get processed to
spit
out apt that gets added to the list of docs to generate. Rather
than affecting the APT itself, it is a step before
WDYT?
I'm not sure what you mean, not everytime. I think if you turn it
on you wouldn't want to have to specify what pages you want to be
interpolated. I think that would be inconvenient. And though it
doesn't fully stream now it will so it will actually be faster
then the current site plugin. So the performance will be higher
once it streams instead of collecting the page content in memory
to process it. So speed is not going to be an issue and it's not
really noticeable right now.
This is only for sites and would be very handy. For example would
then be able to make new types of reports and share them. They
just pop them into their site structure (and move toward being
packaged up as reports) and they will render with their project
information.
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
Jason.
- Brett
On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the
pages of
documentation regardless of format. I've hooked it in to
try it
but there are a couple options.
1) Use Velocity to process the pages before going to the
respective doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of
model
We can't interpolate every time. Sometimes, we need to
interpolate ${project.*} and sometimes not in dox
Emmanuel
I like the Velocity option, not sure if being on by default or
not is good. When there is a parse error I'm currently just
rendering the original document as is where you can see a
warning and the full error in debug mode. This is for 2.0
so it
is a new feature but would allow some cool stuff with.
Jason.
--
---
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
--
To unsubscribe,
Re: Site plugin feature of using Velocity
On 17 Mar 07, at 6:37 PM 17 Mar 07, Brett Porter wrote:
What about anything with a .vm extension?
download.apt.vm gets processed as vm first, then apt. We can do
that in Doxia with zero-configuration.
I really don't want it on by default, because it'll break existing
documents
It won't break any existing documents. If it doesn't parse it just
goes back to processing the raw document.
, and I can see situations where we might want to facilitate
different processors.
Sure, I'll ponder this a bit more. I don't want it to cause any
problems, but zero configuration. What kind of other processors are
you thinking about?
Maybe we could make a configuration and allow the options to be
configured from the site.xml.
Jason.
- Brett
On 18/03/2007, at 3:35 AM, Jason van Zyl wrote:
On 17 Mar 07, at 12:08 PM 17 Mar 07, Eric Redmond wrote:
Could this velocity pre-processor just be a plugin that gets run
in the
pre-site phase - unrelated to doxia?
It could and that's what the velocity people seem to be doing on
their site, but I would really like to not have to configure
anything.
I would like it to be useful generally, but if people object to it
being on by default (but for static site generation who cares),
then maybe a directory structure that gets processed by velocity.
But then you end up with a bunch of different directories. What I
did was process it with Velocity and if that attempt fails with a
parsing error just fall back to processing the raw document.
I want zero configuration, and it just work. I'll do any grunt
work to make that possible.
Jason.
Eric
On 3/17/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 17 Mar 07, at 2:23 AM 17 Mar 07, Brett Porter wrote:
You've lost me, sorry. What type of page are you trying to
create?
Any page, Velocity will be used to render any of the pages. It
would
just work anywhere in the site.
I can see how this makes it possible to make lightweight
reports. I
don't see how it's useful in most documentation. I would think
the
former would naturally be in a separate section somewhere, as
opposed to having to specify pages.
I think what Emmanuel was saying was that making everything
velocity would mean stuff that had things that looked like
expressions now would end up different (you are trying to
explain $
{project.build.directory} instead of substitute it).
That's really easy to escape, and we can tell people it's a
Velocity
document and it's well documented. I think that would be easier
then
juggling pages around to be rendered as it will be the case
where you
want the literal ${project.build.directory} and interpolate some
other project information. This is always the case with Velocity
documents which is why there are escaping tools, #macros, and the
actual escaping characters.
Jason.
- Brett
On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
I think I'd like the option to, but not every time. Maybe it
belongs closer to the reporting infrastructure (the download
pages are more like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the
ability to write simple velocity pages that get processed to
spit
out apt that gets added to the list of docs to generate. Rather
than affecting the APT itself, it is a step before
WDYT?
I'm not sure what you mean, not everytime. I think if you
turn it
on you wouldn't want to have to specify what pages you want
to be
interpolated. I think that would be inconvenient. And though it
doesn't fully stream now it will so it will actually be faster
then the current site plugin. So the performance will be higher
once it streams instead of collecting the page content in memory
to process it. So speed is not going to be an issue and it's not
really noticeable right now.
This is only for sites and would be very handy. For example
would
then be able to make new types of reports and share them. They
just pop them into their site structure (and move toward being
packaged up as reports) and they will render with their project
information.
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
Jason.
- Brett
On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the
pages of
documentation regardless of format. I've hooked it in to
try it
but there are a couple options.
1) Use Velocity to process the pages before going to the
respective doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of
model
We can't interpolate every time. Sometimes, we need to
interpolate ${project.*} and sometimes not in dox
Emmanuel
I like the Velocity option, not sure if being on by
default or
not is good. When there is a parse error I'm currently
Re: Site plugin feature of using Velocity
On 18/03/2007, at 9:56 AM, Jason van Zyl wrote:
On 17 Mar 07, at 6:37 PM 17 Mar 07, Brett Porter wrote:
What about anything with a .vm extension?
download.apt.vm gets processed as vm first, then apt. We can do
that in Doxia with zero-configuration.
I really don't want it on by default, because it'll break existing
documents
It won't break any existing documents. If it doesn't parse it just
goes back to processing the raw document.
Wouldn't documents like:
src/site/apt/guides/getting-started/index.apt
have the ${pom.name} expressions (which are meant to be expressions)
populated with the value?
, and I can see situations where we might want to facilitate
different processors.
Sure, I'll ponder this a bit more. I don't want it to cause any
problems, but zero configuration. What kind of other processors are
you thinking about?
Not that I particularly want to do it now, but this could have been a
useful way to support some of the maven1 docs that used jelly. But I
guess it would allow using other templating solutions if they are a
skillset the team already has.
I'm not sure it's that important, but it seems simple and useful to
make it extensible in that way.
Maybe we could make a configuration and allow the options to be
configured from the site.xml.
Yeah, I think pushing site plugin configuration in general into there
when it's related to rendering is a good idea.
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
On 17 Mar 07, at 7:06 PM 17 Mar 07, Brett Porter wrote:
On 18/03/2007, at 9:56 AM, Jason van Zyl wrote:
On 17 Mar 07, at 6:37 PM 17 Mar 07, Brett Porter wrote:
What about anything with a .vm extension?
download.apt.vm gets processed as vm first, then apt. We can do
that in Doxia with zero-configuration.
I really don't want it on by default, because it'll break
existing documents
It won't break any existing documents. If it doesn't parse it just
goes back to processing the raw document.
Wouldn't documents like:
src/site/apt/guides/getting-started/index.apt
have the ${pom.name} expressions (which are meant to be
expressions) populated with the value?
Wouldn't break them, they would render just interpolate the value.
So, yes, you would have to escape that value or use a literal block.
, and I can see situations where we might want to facilitate
different processors.
Sure, I'll ponder this a bit more. I don't want it to cause any
problems, but zero configuration. What kind of other processors
are you thinking about?
Not that I particularly want to do it now, but this could have been
a useful way to support some of the maven1 docs that used jelly.
I'm going to pretend I didn't hear the word Jelly. La la la la, dum
dee do.
Did we really process documents through Jelly? We were really on
crack. But James was on crack first, so it's not all our fault.
Ultimately I think it would be good if people could configure filter
input streams and chain them and then you can really have whatever
you want. Unfortunately velocity doesn't expose stream processing.
Not yet anyway.
But I guess it would allow using other templating solutions if they
are a skillset the team already has.
I'm not sure it's that important, but it seems simple and useful to
make it extensible in that way.
Maybe we could make a configuration and allow the options to be
configured from the site.xml.
Yeah, I think pushing site plugin configuration in general into
there when it's related to rendering is a good idea.
I will figure out something there then with that.
Jason.
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
On 18/03/2007, at 11:29 AM, Jason van Zyl wrote:
Wouldn't documents like:
src/site/apt/guides/getting-started/index.apt
have the ${pom.name} expressions (which are meant to be
expressions) populated with the value?
Wouldn't break them, they would render just interpolate the value.
So, yes, you would have to escape that value or use a literal block.
Right, as far as I'm concerned that's breaking something :)
I'm going to pretend I didn't hear the word Jelly. La la la la, dum
dee do.
Did we really process documents through Jelly? We were really on
crack. But James was on crack first, so it's not all our fault.
Yeah, I think we did. Or at least there was those jsl reports. I'm
not suggesting we actually go and do it now, but it might have been a
useful migration path at one point :)
Ultimately I think it would be good if people could configure
filter input streams and chain them and then you can really have
whatever you want. Unfortunately velocity doesn't expose stream
processing. Not yet anyway.
Agreed.
I will figure out something there then with that.
Cool, thanks.
The campaign for no-more-alphas seems to be going well. :)
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
On 18 Mar 07, at 12:23 AM 18 Mar 07, Brett Porter wrote:
On 18/03/2007, at 11:29 AM, Jason van Zyl wrote:
Wouldn't documents like:
src/site/apt/guides/getting-started/index.apt
have the ${pom.name} expressions (which are meant to be
expressions) populated with the value?
Wouldn't break them, they would render just interpolate the value.
So, yes, you would have to escape that value or use a literal block.
Right, as far as I'm concerned that's breaking something :)
Yes, but this is 2.0 of the plugin so breaking your documents would
be a new feature :-)
I'm going to pretend I didn't hear the word Jelly. La la la la,
dum dee do.
Did we really process documents through Jelly? We were really on
crack. But James was on crack first, so it's not all our fault.
Yeah, I think we did. Or at least there was those jsl reports. I'm
not suggesting we actually go and do it now, but it might have been
a useful migration path at one point :)
Ultimately I think it would be good if people could configure
filter input streams and chain them and then you can really have
whatever you want. Unfortunately velocity doesn't expose stream
processing. Not yet anyway.
Agreed.
I will figure out something there then with that.
Cool, thanks.
The campaign for no-more-alphas seems to be going well. :)
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it but
there are a couple options.
1) Use Velocity to process the pages before going to the respective
doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of model
We can't interpolate every time. Sometimes, we need to interpolate ${project.*}
and sometimes not in dox
Emmanuel
I like the Velocity option, not sure if being on by default or not is
good. When there is a parse error I'm currently just rendering the
original document as is where you can see a warning and the full error
in debug mode. This is for 2.0 so it is a new feature but would allow
some cool stuff with.
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
I think I'd like the option to, but not every time. Maybe it belongs
closer to the reporting infrastructure (the download pages are more
like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the ability to
write simple velocity pages that get processed to spit out apt that
gets added to the list of docs to generate. Rather than affecting the
APT itself, it is a step before
WDYT?
- Brett
On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it
but there are a couple options.
1) Use Velocity to process the pages before going to the
respective doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of model
We can't interpolate every time. Sometimes, we need to interpolate $
{project.*} and sometimes not in dox
Emmanuel
I like the Velocity option, not sure if being on by default or not
is good. When there is a parse error I'm currently just rendering
the original document as is where you can see a warning and the
full error in debug mode. This is for 2.0 so it is a new feature
but would allow some cool stuff with.
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
On 16 Mar 07, at 6:09 PM 16 Mar 07, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it
but there are a couple options.
1) Use Velocity to process the pages before going to the
respective doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of model
We can't interpolate every time. Sometimes, we need to interpolate $
{project.*} and sometimes not in dox
Sorry, I don't really understand.
Not sure what you mean in that you can't interpolate everytime. The
decorator is still processed by Velocity, I mean the individual APT/
XDoc documents.
Jason.
Emmanuel
I like the Velocity option, not sure if being on by default or not
is good. When there is a parse error I'm currently just rendering
the original document as is where you can see a warning and the
full error in debug mode. This is for 2.0 so it is a new feature
but would allow some cool stuff with.
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
I think I'd like the option to, but not every time. Maybe it
belongs closer to the reporting infrastructure (the download pages
are more like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the ability
to write simple velocity pages that get processed to spit out apt
that gets added to the list of docs to generate. Rather than
affecting the APT itself, it is a step before
WDYT?
I'm not sure what you mean, not everytime. I think if you turn it on
you wouldn't want to have to specify what pages you want to be
interpolated. I think that would be inconvenient. And though it
doesn't fully stream now it will so it will actually be faster then
the current site plugin. So the performance will be higher once it
streams instead of collecting the page content in memory to process
it. So speed is not going to be an issue and it's not really
noticeable right now.
This is only for sites and would be very handy. For example would
then be able to make new types of reports and share them. They just
pop them into their site structure (and move toward being packaged up
as reports) and they will render with their project information.
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
Jason.
- Brett
On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it
but there are a couple options.
1) Use Velocity to process the pages before going to the
respective doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of model
We can't interpolate every time. Sometimes, we need to interpolate
${project.*} and sometimes not in dox
Emmanuel
I like the Velocity option, not sure if being on by default or
not is good. When there is a parse error I'm currently just
rendering the original document as is where you can see a warning
and the full error in debug mode. This is for 2.0 so it is a new
feature but would allow some cool stuff with.
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
On 3/16/07, Jason van Zyl [EMAIL PROTECTED] wrote: I'm leaning toward being on by default and letting people fully utilize Velocity anywhere they like. If Velocity is involved, please make sure the EscapeTool is available so you can convince it *not* to process certain expressions. This is a current problem in the archetype plugin. It's a one-line addition there, I just haven't figured out how to test it so I haven't added it. Would this make it possible to easily replace the templates for, say, the source-repository.html or team-list.html page? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
On 16 Mar 07, at 8:00 PM 16 Mar 07, Wendy Smoak wrote: On 3/16/07, Jason van Zyl [EMAIL PROTECTED] wrote: I'm leaning toward being on by default and letting people fully utilize Velocity anywhere they like. If Velocity is involved, please make sure the EscapeTool is available so you can convince it *not* to process certain expressions. I'm using the existing code to create the context which puts a whole bunch of things in the context, among them the escape tool. This is a current problem in the archetype plugin. It's a one-line addition there, I just haven't figured out how to test it so I haven't added it. Would this make it possible to easily replace the templates for, say, the source-repository.html or team-list.html page? I wouldn't say replace it but you could come up with your own new reports based on any information in the project. Jason. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin feature of using Velocity
You've lost me, sorry. What type of page are you trying to create?
I can see how this makes it possible to make lightweight reports. I
don't see how it's useful in most documentation. I would think the
former would naturally be in a separate section somewhere, as opposed
to having to specify pages.
I think what Emmanuel was saying was that making everything velocity
would mean stuff that had things that looked like expressions now
would end up different (you are trying to explain $
{project.build.directory} instead of substitute it).
- Brett
On 17/03/2007, at 9:32 AM, Jason van Zyl wrote:
On 16 Mar 07, at 6:15 PM 16 Mar 07, Brett Porter wrote:
I think I'd like the option to, but not every time. Maybe it
belongs closer to the reporting infrastructure (the download pages
are more like the SCM/mail list types of pages).
Maybe that's the real future of those types of pages - the ability
to write simple velocity pages that get processed to spit out apt
that gets added to the list of docs to generate. Rather than
affecting the APT itself, it is a step before
WDYT?
I'm not sure what you mean, not everytime. I think if you turn it
on you wouldn't want to have to specify what pages you want to be
interpolated. I think that would be inconvenient. And though it
doesn't fully stream now it will so it will actually be faster then
the current site plugin. So the performance will be higher once it
streams instead of collecting the page content in memory to process
it. So speed is not going to be an issue and it's not really
noticeable right now.
This is only for sites and would be very handy. For example would
then be able to make new types of reports and share them. They just
pop them into their site structure (and move toward being packaged
up as reports) and they will render with their project information.
I'm leaning toward being on by default and letting people fully
utilize Velocity anywhere they like.
Jason.
- Brett
On 17/03/2007, at 9:09 AM, Emmanuel Venisse wrote:
Jason van Zyl a écrit :
Hi,
Do you think people would like to use Velocity for the pages of
documentation regardless of format. I've hooked it in to try it
but there are a couple options.
1) Use Velocity to process the pages before going to the
respective doxia parser
2) Make 1) optional
3) Just interpolate the documents like we do the XML forms of model
We can't interpolate every time. Sometimes, we need to
interpolate ${project.*} and sometimes not in dox
Emmanuel
I like the Velocity option, not sure if being on by default or
not is good. When there is a parse error I'm currently just
rendering the original document as is where you can see a
warning and the full error in debug mode. This is for 2.0 so it
is a new feature but would allow some cool stuff with.
Jason.
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: site plugin - Error parsing site descriptor
Hi Wendy,
I tried tiles (r500806) with site and doxia HEAD and I have no
exception here. HTH
Cheers,
Vincent
2007/1/27, Wendy Smoak [EMAIL PROTECTED]:
On 1/27/07, Brett Porter [EMAIL PROTECTED] wrote:
Maybe the deprecated form got removed from the plugin?
You can change to menu ref=modules / and it should work.
Sorry, it's complaining about ${modules}. You knew what I meant, I think. :)
We should probably investigate why the old one disappeared though.
Yes, since it works in 2.0-beta-4 and -5, it shouldn't just disappear
in a 2.0-SNAPSHOT.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: site plugin - Error parsing site descriptor
On 1/28/07, Vincent Siveton [EMAIL PROTECTED] wrote: I tried tiles (r500806) with site and doxia HEAD and I have no exception here. HTH Thanks. I only built the site plugin locally for that test, so it's probably pulling in the old (Nov '06) doxia snapshots in the repo. :( -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site plugin - Error parsing site descriptor
Maybe the deprecated form got removed from the plugin? You can change to menu ref=modules / and it should work. We should probably investigate why the old one disappeared though. - Brett On 28/01/2007, at 9:46 AM, Wendy Smoak wrote: Any news on this? The site plugin is complaining about modules in site.xml. Sample project: http://svn.apache.org/repos/asf/tiles/framework/trunk/ The snapshot in the repository is okay, it's from Dec 15th. maven-site-plugin-2.0-20061215.144112-12.jar 15-Dec-2006 06:41 96K The latest code in svn does this: [INFO] [site:attach-descriptor] [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Error parsing site descriptor Embedded error: expected START_TAG or END_TAG not TEXT (position: TEXT seen ... /menu\r\n\r\n[tiles-api, tiles-core, tiles-test]\r\n m... @94:11) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site plugin - Error parsing site descriptor
On 1/27/07, Brett Porter [EMAIL PROTECTED] wrote:
Maybe the deprecated form got removed from the plugin?
You can change to menu ref=modules / and it should work.
Sorry, it's complaining about ${modules}. You knew what I meant, I think. :)
We should probably investigate why the old one disappeared though.
Yes, since it works in 2.0-beta-4 and -5, it shouldn't just disappear
in a 2.0-SNAPSHOT.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: site plugin confusion - can we nuke -plugin-with-compat-for-2.0.4?
On 18 Dec 06, at 7:46 PM 18 Dec 06, Brett Porter wrote: I'm confused about where we got to here - is it correct that the main site plugin is fine again now and this one (which should have been a branch anyway) can be nuked? Trunk with the normal name is fine. I'm taking care of it and will finish it. Jason. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Site plugin changes, site:run
Hi Brett, I took time to test your amazing stuff. Very nice feature :) Thanks! You've probably know these but just in case they can help you: - error 404 for subprojects links from a multi project case: http://localhost:8080/index.html Clicks on a sub project http://localhost:8080/framework1/index.html = error404 Yes, multiproject is not really supported yet. It will be, but maybe in the next version. Ok - frenglish project info reports without specify any french language (see http://people.apache.org/~vsiveton/site_run/site_run_pir.jpg based on http://www.javaworld.com/javaworld/jw-02-2006/jw-0227-maven.html) Is this just missing translations or a bug? It is a bug in the DoxiaFilter class: context.setLocale( req.getLocale() ); (I have a French browser) I will open an issue for that. - Javadoc report link doesnt work : blank page Bug in the javadoc plugin, you need the latest snapshot of that. I retried with snapshot and trunk version, I have got always a blank page. Could you retry? Cheers, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin changes, site:run
Vincent Siveton wrote: - Javadoc report link doesnt work : blank page Bug in the javadoc plugin, you need the latest snapshot of that. I retried with snapshot and trunk version, I have got always a blank page. Could you retry? Oh, in site:rnu, that's probably right. Please open a bug. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin changes, site:run
Hi Vincent, Vincent Siveton wrote: Brett, I took time to test your amazing stuff. Very nice feature :) Thanks! You've probably know these but just in case they can help you: - error 404 for subprojects links from a multi project case: http://localhost:8080/index.html Clicks on a sub project http://localhost:8080/framework1/index.html = error404 Yes, multiproject is not really supported yet. It will be, but maybe in the next version. - frenglish project info reports without specify any french language (see http://people.apache.org/~vsiveton/site_run/site_run_pir.jpg based on http://www.javaworld.com/javaworld/jw-02-2006/jw-0227-maven.html) Is this just missing translations or a bug? - Javadoc report link doesnt work : blank page Bug in the javadoc plugin, you need the latest snapshot of that. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin changes, site:run
Brett, I took time to test your amazing stuff. Very nice feature :) Thanks! You've probably know these but just in case they can help you: - error 404 for subprojects links from a multi project case: http://localhost:8080/index.html Clicks on a sub project http://localhost:8080/framework1/index.html = error404 - frenglish project info reports without specify any french language (see http://people.apache.org/~vsiveton/site_run/site_run_pir.jpg based on http://www.javaworld.com/javaworld/jw-02-2006/jw-0227-maven.html) - Javadoc report link doesnt work : blank page Cheers, Vincent 2006/3/14, Brett Porter [EMAIL PROTECTED]: Hi, I've made a round of changes to the site plugin, which should be the last major set. I plan to call a vote for a final beta in a couple of days. Since these changes were pretty large, please test (this includes the project info reports plugin). Either build from source (trunk), or use: pluginRepositories pluginRepository idapache.snapshots/id urlhttp://cvs.apache.org/maven-snapshot-repository/url /pluginRepository /pluginRepositories One of the new features to try out (though its rough - no locale support yet) is: mvn site:run This will start Jetty and if you go to http://localhost:8080/index.html you can dynamically browse the site. The reports and pages re-render each time so you can edit and review on a much faster cycle. Enjoy! Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: site-plugin broken
Only if you've ever compiled it locally. It's not in central. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, December 02, 2005 11:29 PM To: Maven Developers List Subject: Re: site-plugin broken Shouldn't mean it is broken - the old one should still be there? Mike Perham wrote: It depends on: org.codehaus.doxia:doxia-site-renderer:1.0-alpha-6-SNAPSHOT:jar but doxia's groupId has changed: parent artifactIddoxia/artifactId groupIdorg.apache.maven.doxia/groupId version1.0-alpha-6-SNAPSHOT/version /parent artifactIddoxia-site-renderer/artifactId - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site-plugin broken
Shouldn't mean it is broken - the old one should still be there? Mike Perham wrote: It depends on: org.codehaus.doxia:doxia-site-renderer:1.0-alpha-6-SNAPSHOT:jar but doxia's groupId has changed: parent artifactIddoxia/artifactId groupIdorg.apache.maven.doxia/groupId version1.0-alpha-6-SNAPSHOT/version /parent artifactIddoxia-site-renderer/artifactId - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site plugin and ssh
On Fri, 2004-07-09 at 11:52, Carlos Sanchez wrote: Hi, Now that the deployment stuff is done by the artifact plugin using jsch are there any plans to migrate site plugin so it uses also jsch instead of a binary ssh executable? It would be great if Maven needed no external programs. Maybe the scm plugin could use jcvs? That would be nice, there is the netbeans CVS code which is pure java. The JCVS is a rather complicated client interface. I tried it about 2 years ago when I asked the author to change the license to the LGPL (which he did). I think Eric Pugh was going to take a stab at creating a Maven SCM provider that used the netbeans code. Regards Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
