All,
In noticed that images within tables are not properly rendered, for example:
||Symbol||Description||
|!images/symbol.png!|text|
Doesn't result in an image shown in the table cell. After investigation I found
out that the renderer of the table (TableBlockParser) only applies the
ParagraphB
Even more refreshing cleanup.
Go Dennis!
:)
2013/7/25 Dennis Lundberg
> Hi
>
> I've been going through our shared components making sure they all
> follow ASF branding rules. While doing this I became curious about a
> couple of the components that seemed alien to me. It turns out that of
> ou
My idea for #1 was not to expand the SCM API for Maven, but to reduce and
simplify it to the parts actually used
(i.e. the operations done by the maven-release-plugin, since that plugin is
really main user of the
SCM API, along with the pull/checkout done typically by CI servers).
Moreover, the re
I'm all for it
On 24 July 2013 23:06, Dennis Lundberg wrote:
> Hi
>
> I've been going through our shared components making sure they all
> follow ASF branding rules. While doing this I became curious about a
> couple of the components that seemed alien to me. It turns out that of
> our 30 share
+1
On 23 July 2013 20:45, Dennis Lundberg wrote:
> Hi,
>
> This will be the final release of this shared component. After this
> release it will retire from the Apache Maven project and move to the
> Apache Archiva project. See separate vote thread about that.
>
> We solved 6 issues:
>
> http:/
Hi
I've been going through our shared components making sure they all
follow ASF branding rules. While doing this I became curious about a
couple of the components that seemed alien to me. It turns out that of
our 30 shared components we have 5 that have not yet had a release. I
haven't yet looked
+1 from me
On Tue, Jul 23, 2013 at 9:45 PM, Dennis Lundberg wrote:
> Hi,
>
> This will be the final release of this shared component. After this
> release it will retire from the Apache Maven project and move to the
> Apache Archiva project. See separate vote thread about that.
>
> We solved 6 is
Hi,
Although I've seen a lot of threads about the maven-release-plugin, IMHO
it is often caused by bad reading. But that could also mean that we need
to improve the docs. I'm not aware of a lot of maven-site-plugin issues.
I'd like to base your opinion on facts, so in both cases I'd like to k
Hello all,
I have pondered a tad about the usability, applicability and underpinnings
of Maven's current way to release artifacts [including source and javadoc
JARs] and sites. I feel that a lot of the confusion posted to diverse
mailing lists and forums originates in the release plugin, the site
Hi,
Recently I had a look at Microsoft Team Foundation Server and faced the
same kind of issue.
I'm not sure if you could/should reuse a WorkItem. For the
maven-release-plugin this could very well be acceptable, but for commits
in general? I don't think so.
If it is static, then you can ma
+1
On 7/23/13 8:59 AM, Stephen Connolly wrote:
This vote is to cover the minimum required version of Java for Maven Core.
Maven Plugins produced by the Apache Maven Project that are flagged as
compatible with older versions of Maven Core as their baseline will still
require to stick to the mini
Thank you all for the useful isnights.
2013/7/24 Stephen Connolly
> getPluginContext() is the one you want. Use that to stash your info.
>
>
> On 24 July 2013 15:15, Francesco Mari wrote:
>
> > Thank you for the link, but I don't need to coordinate multiple projects
> in
> > the same session.
getPluginContext() is the one you want. Use that to stash your info.
On 24 July 2013 15:15, Francesco Mari wrote:
> Thank you for the link, but I don't need to coordinate multiple projects in
> the same session. My use case is only focused on one project.
>
> What about serializing the informat
Thank you for the link, but I don't need to coordinate multiple projects in
the same session. My use case is only focused on one project.
What about serializing the information somewhere in the
${project.build.directory} folder?
Are there any issues I should aware of if I implement this solution?
Ahh yes... that's the one... I spent 3-5 min searching for it.
getPluginContext() is the map you want (unless you want to span modules...
even then I think you can cheat slightly by doing some funky stuff)
On 24 July 2013 14:20, Baptiste MATHUS wrote:
> Hi,
>
> I remember doing that for build-
Just remove the and from the end of it...
On Wed, Jul 24, 2013 at 3:30 PM, Martin Gainty wrote:
>
> can anyone reach the URL?
>
> Baptiste is it possible to repost comments for build-helper to pastebin?
>
> http://pastebin.com/
>
>
>
>
> > Date: Wed, 24 Jul 2013 15:20:33 +0200
> > Subject: Re: P
can anyone reach the URL?
Baptiste is it possible to repost comments for build-helper to pastebin?
http://pastebin.com/
> Date: Wed, 24 Jul 2013 15:20:33 +0200
> Subject: Re: Passing information between goals
> From: m...@batmat.net
> To: dev@maven.apache.org
>
> Hi,
>
> I remember doing
Hi,
I remember doing that for build-helper. It was for many executions of the
same mojo though, not sure how it behaves with different mojos.
See
http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
the ReserveListenerPortMojo
My 2 cents.
Cheers
Le 24 juil. 2013 1
This is generally a tad tricky.
1. Because of class unloading it may not be possible to use the Hack-type
solution of stashing the data in a Class level static field. Though that
solution will work as long as the field uses a collection type that allows
for GC when the MavenProject that it is cach
Hi,
I wrote some MOJOs which use common data. This data depends on the
structure of the project and can't be changed at runtime.
I would like to compute this information at the beginiing of the build
process, and re-use it in each related goal. Ideally, the first goal should
compute the data, and
Github user mfriedenhagen closed the pull request at:
https://github.com/apache/maven-plugins/pull/5
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
+1
2013/7/23 Dennis Lundberg
> Hi,
>
> This is the final release of this plugin. After this release it will
> be retired, see separate vote thread for more info on that.
>
> We solved 1 issue:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11135&styleName=Html&version=14478
>
>
22 matches
Mail list logo
