Images in table not properly rendered
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 ParagraphBlockParser and not other parsers like SectionBlockParser, FigureBlockParser, and ListBlockParser. To fix this I created the included patch. With this patch applied to version 1.4 of Doxia the example as shown above was properly parsed. Hope this patch can make it in any form to the new release to Doxia confluence module. Cheers, Mark Schenk - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Moving unreleased shared components to the sandbox
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 > our 30 shared components we have 5 that have not yet had a release. I > haven't yet looked in svn to see if there has been any recent work on > these 5 components. Here are the components, that haven't yet had a > release: > > maven-ant > maven-plugin-enforcer > maven-project-utils > maven-script > maven-shared-monitor > > Is anyone working on these? > > If not then I think we should move them to the sandbox, until someone > steps up to do a release of them. > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- -- +==+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+
Re: [Discussion] Simplifying the release process and the maven-release-plugin/maven-site-plugin
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 reasons I bring these thoughts up is that I have been asked the questions about what relevance some of the POM elements have over and over by Maven users. While we can certainly structure the thoughts and prioritize to achieve business as usual, my idea was more to get a healthy discussion going. It is good to ask ourselves "why" every now and then. 2013/7/24 Robert Scholte > 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 know > a top-10 or so for both plugins with the issue and the solution. > > I don't think Maven users have issues with #1, it's sometimes a struggle > for Maven developers. Yes, there's a wish to separate this by making > interfaces for distributed and non-distributed SCMs, but that's a huge, > HUGE job. > #2 I think can only be simplified if you take the SCM into account. So > SCM-based default, but that's even harder to document. I'm not sure if > we're helping the community with such changes. Also, simplifying would mean > that some parameters are redundant or could be combined. The idea has > always been to use logical defaults, so there shouldn't be any need to use > large configuration-blocks for the maven-release-plugin. Your asking to > investigate, but I guess you already have some concrete ideas. Which ones? > #3 Again, I don't see any issues for general Maven users. We're offering a > lot of markup languages because the community wants too. The only > frustrations I can think of is path calculations and the site.xml in > multimodule projects (which parts of the site.xml must inherited, > overridden or extended? Now it's a mixture). > > I'd suggest to start confluence-pages and separate these challenges. > Improvements for both plugins can be investigated and developed apart from > each other. > > Robert > > Op Wed, 24 Jul 2013 20:47:54 +0200 schreef Lennart Jörelid < > lennart.jore...@gmail.com>: > > 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 plugin >> and the slush of required configuration noted in the pom, settings.xml and >> plugin sections. >> >> It could be that Maven-Release-Plugin and Maven-Site-Plugin try to be too >> generic or use too complex underpinnings. For example, we have a Maven/VCS >> integration framework - but it seems that the vast majority of devs only >> ever use this functionality during releases (and, thus, indirectly through >> the maven-release-plugin). Moreover, since Maven (or some of its core >> plugins) assume a SVN-centric view of the world, some Maven/VCS operations >> done during release seem to work poorly or requiring much repetitive >> configuration for DVCSs. All - not most - devs I have spoken to prefer >> using the native VCS client for their daily work over Maven's VCS >> integration, implying that we might define the scope of the Maven/VCS >> integration to fit the release and CI use case instead of being a generic >> VCS integration into Maven (which is not used other than in the release >> cases anyways?). >> >> Could we simplify the release process and the configuration for >> Maven-Release-Plugin and Maven-Site-Plugin by making and reacting to a few >> assumptions? Here goes: >> >> >>1. The vast majority of Devs/CIs use Maven/SCM integration mainly for >> >>checkout and release (which implies mainly tag, commit, checkin/push) >>operations. These operations are used mainly for checking out/pulling >> and >>releasing artifacts. >>2. We should investigate simplifying the configuration used for the >> >>release process, potentially by simplifying the SCM layer to cater >> only for >>the operations used within its main use case (i.e. the release >> process). >>3. We should investigate simplifying the configuration used for >> >>releasing a site - including relativization and aggregation - either by >>documenting the process better or perhaps narrowing down the amount of >>input formats to potentially remove the use of Doxia altogether? (After >>all, there are quite a few good markup/HTML editors out there, and much >>more reference literature on HTML than ... say ... APT). >> >> >> Simplification and usability improvements are - in my view - always Good >> Things(tm). >> >>
Re: [DISCUSS] Moving unreleased shared components to the sandbox
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 shared components we have 5 that have not yet had a release. I > haven't yet looked in svn to see if there has been any recent work on > these 5 components. Here are the components, that haven't yet had a > release: > > maven-ant > maven-plugin-enforcer > maven-project-utils > maven-script > maven-shared-monitor > > Is anyone working on these? > > If not then I think we should move them to the sandbox, until someone > steps up to do a release of them. > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven Model Converter version 2.3
+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://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=14389 > > There are no issues left in JIRA (except for the one to retire, which > I'll close later): > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&component=13272&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-010/ > > https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip > > Staging site (not synced yet): > http://maven.apache.org/shared-archives/maven-model-converter-2.3/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[DISCUSS] Moving unreleased shared components to the sandbox
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 in svn to see if there has been any recent work on these 5 components. Here are the components, that haven't yet had a release: maven-ant maven-plugin-enforcer maven-project-utils maven-script maven-shared-monitor Is anyone working on these? If not then I think we should move them to the sandbox, until someone steps up to do a release of them. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Model Converter version 2.3
+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 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=14389 > > There are no issues left in JIRA (except for the one to retire, which > I'll close later): > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&component=13272&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-010/ > https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip > > Staging site (not synced yet): > http://maven.apache.org/shared-archives/maven-model-converter-2.3/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Dennis Lundberg -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Discussion] Simplifying the release process and the maven-release-plugin/maven-site-plugin
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 know a top-10 or so for both plugins with the issue and the solution. I don't think Maven users have issues with #1, it's sometimes a struggle for Maven developers. Yes, there's a wish to separate this by making interfaces for distributed and non-distributed SCMs, but that's a huge, HUGE job. #2 I think can only be simplified if you take the SCM into account. So SCM-based default, but that's even harder to document. I'm not sure if we're helping the community with such changes. Also, simplifying would mean that some parameters are redundant or could be combined. The idea has always been to use logical defaults, so there shouldn't be any need to use large configuration-blocks for the maven-release-plugin. Your asking to investigate, but I guess you already have some concrete ideas. Which ones? #3 Again, I don't see any issues for general Maven users. We're offering a lot of markup languages because the community wants too. The only frustrations I can think of is path calculations and the site.xml in multimodule projects (which parts of the site.xml must inherited, overridden or extended? Now it's a mixture). I'd suggest to start confluence-pages and separate these challenges. Improvements for both plugins can be investigated and developed apart from each other. Robert Op Wed, 24 Jul 2013 20:47:54 +0200 schreef Lennart Jörelid : 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 plugin and the slush of required configuration noted in the pom, settings.xml and plugin sections. It could be that Maven-Release-Plugin and Maven-Site-Plugin try to be too generic or use too complex underpinnings. For example, we have a Maven/VCS integration framework - but it seems that the vast majority of devs only ever use this functionality during releases (and, thus, indirectly through the maven-release-plugin). Moreover, since Maven (or some of its core plugins) assume a SVN-centric view of the world, some Maven/VCS operations done during release seem to work poorly or requiring much repetitive configuration for DVCSs. All - not most - devs I have spoken to prefer using the native VCS client for their daily work over Maven's VCS integration, implying that we might define the scope of the Maven/VCS integration to fit the release and CI use case instead of being a generic VCS integration into Maven (which is not used other than in the release cases anyways?). Could we simplify the release process and the configuration for Maven-Release-Plugin and Maven-Site-Plugin by making and reacting to a few assumptions? Here goes: 1. The vast majority of Devs/CIs use Maven/SCM integration mainly for checkout and release (which implies mainly tag, commit, checkin/push) operations. These operations are used mainly for checking out/pulling and releasing artifacts. 2. We should investigate simplifying the configuration used for the release process, potentially by simplifying the SCM layer to cater only for the operations used within its main use case (i.e. the release process). 3. We should investigate simplifying the configuration used for releasing a site - including relativization and aggregation - either by documenting the process better or perhaps narrowing down the amount of input formats to potentially remove the use of Doxia altogether? (After all, there are quite a few good markup/HTML editors out there, and much more reference literature on HTML than ... say ... APT). Simplification and usability improvements are - in my view - always Good Things(tm). What do you think? -- +==+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[Discussion] Simplifying the release process and the maven-release-plugin/maven-site-plugin
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 plugin and the slush of required configuration noted in the pom, settings.xml and plugin sections. It could be that Maven-Release-Plugin and Maven-Site-Plugin try to be too generic or use too complex underpinnings. For example, we have a Maven/VCS integration framework - but it seems that the vast majority of devs only ever use this functionality during releases (and, thus, indirectly through the maven-release-plugin). Moreover, since Maven (or some of its core plugins) assume a SVN-centric view of the world, some Maven/VCS operations done during release seem to work poorly or requiring much repetitive configuration for DVCSs. All - not most - devs I have spoken to prefer using the native VCS client for their daily work over Maven's VCS integration, implying that we might define the scope of the Maven/VCS integration to fit the release and CI use case instead of being a generic VCS integration into Maven (which is not used other than in the release cases anyways?). Could we simplify the release process and the configuration for Maven-Release-Plugin and Maven-Site-Plugin by making and reacting to a few assumptions? Here goes: 1. The vast majority of Devs/CIs use Maven/SCM integration mainly for checkout and release (which implies mainly tag, commit, checkin/push) operations. These operations are used mainly for checking out/pulling and releasing artifacts. 2. We should investigate simplifying the configuration used for the release process, potentially by simplifying the SCM layer to cater only for the operations used within its main use case (i.e. the release process). 3. We should investigate simplifying the configuration used for releasing a site - including relativization and aggregation - either by documenting the process better or perhaps narrowing down the amount of input formats to potentially remove the use of Doxia altogether? (After all, there are quite a few good markup/HTML editors out there, and much more reference literature on HTML than ... say ... APT). Simplification and usability improvements are - in my view - always Good Things(tm). What do you think? -- +==+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+
Re: SCM Providers
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 make it part of the SCM-URL If it is a system-wide setting, then create a specific scm-settings.xml. This latter is not very well documented, or it is hard to find. In the past I've written a setup-maven-plugin[1], with which you could create such files and which has a link to the original documentation. If the workitem is variable, then the -D option is probably the best. Would be nice if we could think of a general solution. Robert [1] http://mojo.codehaus.org/setup/setup-maven-plugin/plugin-info.html Op Wed, 24 Jul 2013 01:35:43 +0200 schreef Chris Graham : Hey All. In the RTC/Jazz forum, a request came up for the ability to associate a Work Item with the commits that the SCM plugin does. On the Jazz side, I think that I've worked things out. However, I am unsure as to how to best do this on the maven and scm provider side. The generic question boils down to: How can we supply a scm specific parameter to a specific scm provider? One that is not applicable to all providers. I really do not want to add a -D option. :-) Thoughts/comments/suggestions? -Chris - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
+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 minimum Java requirements of that Maven Core version. In other words, if for example maven-compiler-plugin advertises compatibility with Maven Core 2.0.11+ then that will still need to be compiled targeting Java 1.4 and only using dependencies that are aligned with that runtime requirement. Additionally patch releases to existing releases of Maven Core will not be subject to this requirement. For example [example]*if* this vote passes and *if* on Sep 29th we release Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2, Maven 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security issue that affected all versions of Maven) then only Maven 3.3.0 would be require Java 6 as a minimum runtime requirement, the 2.0.12 release would still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions would all still require Java 1.5.[/example] This is not a requirement that 3rd party plugins need use Java 6 as a minimum. Third party plugins are free to require any Java version >= the corresponding Maven minimum requirement, though obviously from a users perspective it is best if plugins try to adhere to our contracts for corresponding versions of Maven Core. Justification for the cut-off date: * Oracle has gone end of life on Java 6 Feb 2013 (note that there is still extended and sustaining support for existing Oracle customers using Java 5) * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are still with support, but there are other Java vendors for other platforms) * Apple no longer supports any hardware that does not have at least an Apple Java 6 version available. * Red Hat is providing support for OpenJDK 6 * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available. As I see it, that essentially ensures that for the vast majority of platforms there is a very strong likelihood of a Java 6 compatible version of Java available for that platform. Toolchains support or forking of the compiler and surefire can provide support for users who still need to build with older versions of Java (e.g., as was the case for Java 1.4.2 with Maven 2.2.1). Additionally users who are forced to use a java version older than Java 6 also are likely unable to upgrade their version of Maven, so this change will not affect them This vote is open for 72 hours. A minimum of three +1 binding votes (i.e. from the PMC) and the majority of votes cast from committers will be required to pass this vote. +1000: Yes, and when can we have the vote to go for Java 7 as a minimum? (This option is equivalent to +1 but provides people the ability to indicate an additional preference while not contributing to the inevitible noise) +1: Yes 0: No opinion -1: No -Stephen -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Passing information between goals
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. 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?
> >
> >
> > 2013/7/24 Stephen Connolly
> >
> > > 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-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 14:17, "Stephen Connolly" <
> > > > stephen.alan.conno...@gmail.com>
> > > > a écrit :
> > > >
> > > > > 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 caching a value for has
> been
> > > > > collected by GC (think of the users of Maven Embedder who's Maven
> > > process
> > > > > may be long lived and reused multiple times)
> > > > >
> > > > > 2. Easiest way may just be to serialize the value into a string
> form
> > > and
> > > > > set a project property with a non-maven resolvable name to the
> string
> > > > > value. For example I do not think it is possible to have a Maven
> > > property
> > > > > start with the null character.
> > > > >
> > > > > You code will need to be defensive, and if the property (or cache
> > value
> > > > if
> > > > > you go route 1) is missing it will have to calculate the value from
> > > > scratch
> > > > >
> > > > >
> > > > > On 24 July 2013 12:57, Francesco Mari
> > > wrote:
> > > > >
> > > > > > 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 the following ones will just use it.
> > > > > >
> > > > > > Which is the best option? Are there any plugins already
> > implementing
> > > > > such a
> > > > > > strategy, so I can take a look at their source code?
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Passing information between goals
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 information somewhere in the
> ${project.build.directory} folder?
>
> Are there any issues I should aware of if I implement this solution?
>
>
> 2013/7/24 Stephen Connolly
>
> > 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-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 14:17, "Stephen Connolly" <
> > > stephen.alan.conno...@gmail.com>
> > > a écrit :
> > >
> > > > 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 caching a value for has been
> > > > collected by GC (think of the users of Maven Embedder who's Maven
> > process
> > > > may be long lived and reused multiple times)
> > > >
> > > > 2. Easiest way may just be to serialize the value into a string form
> > and
> > > > set a project property with a non-maven resolvable name to the string
> > > > value. For example I do not think it is possible to have a Maven
> > property
> > > > start with the null character.
> > > >
> > > > You code will need to be defensive, and if the property (or cache
> value
> > > if
> > > > you go route 1) is missing it will have to calculate the value from
> > > scratch
> > > >
> > > >
> > > > On 24 July 2013 12:57, Francesco Mari
> > wrote:
> > > >
> > > > > 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 the following ones will just use it.
> > > > >
> > > > > Which is the best option? Are there any plugins already
> implementing
> > > > such a
> > > > > strategy, so I can take a look at their source code?
> > > > >
> > > >
> > >
> >
>
Re: Passing information between goals
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?
2013/7/24 Stephen Connolly
> 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-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 14:17, "Stephen Connolly" <
> > stephen.alan.conno...@gmail.com>
> > a écrit :
> >
> > > 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 caching a value for has been
> > > collected by GC (think of the users of Maven Embedder who's Maven
> process
> > > may be long lived and reused multiple times)
> > >
> > > 2. Easiest way may just be to serialize the value into a string form
> and
> > > set a project property with a non-maven resolvable name to the string
> > > value. For example I do not think it is possible to have a Maven
> property
> > > start with the null character.
> > >
> > > You code will need to be defensive, and if the property (or cache value
> > if
> > > you go route 1) is missing it will have to calculate the value from
> > scratch
> > >
> > >
> > > On 24 July 2013 12:57, Francesco Mari
> wrote:
> > >
> > > > 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 the following ones will just use it.
> > > >
> > > > Which is the best option? Are there any plugins already implementing
> > > such a
> > > > strategy, so I can take a look at their source code?
> > > >
> > >
> >
>
Re: Passing information between goals
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-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 14:17, "Stephen Connolly" < > stephen.alan.conno...@gmail.com> > a écrit : > > > 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 caching a value for has been > > collected by GC (think of the users of Maven Embedder who's Maven process > > may be long lived and reused multiple times) > > > > 2. Easiest way may just be to serialize the value into a string form and > > set a project property with a non-maven resolvable name to the string > > value. For example I do not think it is possible to have a Maven property > > start with the null character. > > > > You code will need to be defensive, and if the property (or cache value > if > > you go route 1) is missing it will have to calculate the value from > scratch > > > > > > On 24 July 2013 12:57, Francesco Mari wrote: > > > > > 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 the following ones will just use it. > > > > > > Which is the best option? Are there any plugins already implementing > > such a > > > strategy, so I can take a look at their source code? > > > > > >
Re: Passing information between goals
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: Passing information between goals > > From: m...@batmat.net > > To: dev@maven.apache.org > > > > 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 14:17, "Stephen Connolly" < > stephen.alan.conno...@gmail.com> > > a écrit : > > > > > 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 caching a value for has been > > > collected by GC (think of the users of Maven Embedder who's Maven > process > > > may be long lived and reused multiple times) > > > > > > 2. Easiest way may just be to serialize the value into a string form > and > > > set a project property with a non-maven resolvable name to the string > > > value. For example I do not think it is possible to have a Maven > property > > > start with the null character. > > > > > > You code will need to be defensive, and if the property (or cache > value if > > > you go route 1) is missing it will have to calculate the value from > scratch > > > > > > > > > On 24 July 2013 12:57, Francesco Mari > wrote: > > > > > > > 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 the following ones will just use it. > > > > > > > > Which is the best option? Are there any plugins already implementing > > > such a > > > > strategy, so I can take a look at their source code? > > > > > > > > >
RE: Passing information between goals
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 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 14:17, "Stephen Connolly" > a écrit : > > > 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 caching a value for has been > > collected by GC (think of the users of Maven Embedder who's Maven process > > may be long lived and reused multiple times) > > > > 2. Easiest way may just be to serialize the value into a string form and > > set a project property with a non-maven resolvable name to the string > > value. For example I do not think it is possible to have a Maven property > > start with the null character. > > > > You code will need to be defensive, and if the property (or cache value if > > you go route 1) is missing it will have to calculate the value from scratch > > > > > > On 24 July 2013 12:57, Francesco Mari wrote: > > > > > 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 the following ones will just use it. > > > > > > Which is the best option? Are there any plugins already implementing > > such a > > > strategy, so I can take a look at their source code? > > > > >
Re: Passing information between goals
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 14:17, "Stephen Connolly" a écrit : > 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 caching a value for has been > collected by GC (think of the users of Maven Embedder who's Maven process > may be long lived and reused multiple times) > > 2. Easiest way may just be to serialize the value into a string form and > set a project property with a non-maven resolvable name to the string > value. For example I do not think it is possible to have a Maven property > start with the null character. > > You code will need to be defensive, and if the property (or cache value if > you go route 1) is missing it will have to calculate the value from scratch > > > On 24 July 2013 12:57, Francesco Mari wrote: > > > 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 the following ones will just use it. > > > > Which is the best option? Are there any plugins already implementing > such a > > strategy, so I can take a look at their source code? > > >
Re: Passing information between goals
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 caching a value for has been collected by GC (think of the users of Maven Embedder who's Maven process may be long lived and reused multiple times) 2. Easiest way may just be to serialize the value into a string form and set a project property with a non-maven resolvable name to the string value. For example I do not think it is possible to have a Maven property start with the null character. You code will need to be defensive, and if the property (or cache value if you go route 1) is missing it will have to calculate the value from scratch On 24 July 2013 12:57, Francesco Mari wrote: > 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 the following ones will just use it. > > Which is the best option? Are there any plugins already implementing such a > strategy, so I can take a look at their source code? >
Passing information between goals
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 the following ones will just use it. Which is the best option? Are there any plugins already implementing such a strategy, so I can take a look at their source code?
maven-plugins pull request: MPIR-271: GIT support in project-info-reports:s...
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
Re: [VOTE] Release Apache Maven IDEA Plugin version 2.2.1
+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 > > There are still a couple of issues left in JIRA: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11135&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-008/ > > https://repository.apache.org/content/repositories/maven-008/org/apache/maven/plugins/maven-idea-plugin/2.2.1/maven-idea-plugin-2.2.1-source-release.zip > > For those interested, the SCM URL can be found in the pom.xml that is > in the staging repo. > > Staging site: > http://maven.apache.org/plugins-archives/maven-idea-plugin-2.2.1/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- -- +==+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+
