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
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
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,
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
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
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
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
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
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
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
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 =
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
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
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
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]
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,
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'
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
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.
-
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
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
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
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
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
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
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
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
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.
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.
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
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
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
-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
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
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:
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
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?
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
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
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
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,
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
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,
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
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)
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
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
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 -
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
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
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
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
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
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
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
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
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
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.
-
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
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
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
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
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
63 matches
Mail list logo
