Re: [VOTE] Release Apache Maven IDEA Plugin version 2.2.1
+1 On Tue, Jul 23, 2013 at 8:23 PM, Dennis Lundberg dennisl.apa...@gmail.comwrote: 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=11135styleName=Htmlversion=14478 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11135status=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
Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
The split verifier should improve cli performance once core and most plugins are on -target 1.6 Any committer is free to call a vote to up the minimum to 1.7 if they want to. From a build tool perspective there are some advantages in 1.6 as a baseline (compiler api, scripting api, split verifier for faster initial classloading, etc). From a non build tool perspective, String.isEmpty() is rather paltry though! On Wednesday, 24 July 2013, Christian Schulte wrote: Am 07/24/13 04:00, schrieb jieryn: Move forward or die. If you are stuck on 1.5, you can continue to use a full stack that is already supported. I am so sick of hearing people complain that they will be broken if a JDK migration to a newer version is undertaken. No, you are not broken, you simply can not upgrade. There is a huge difference between being broken and not having an upgrade path. Upgrade to Java 7 because you make use of the new APIs Java 7 introduces or stay with Java 5. Java 6 does not introduce anything interesting to Maven core. Java 7 does. This form of anti-migration argument has less value than a without any requirement argument for not migrating. I do not argue against migrating. I do argue against migrating without any reason. Since this is a vote thread: +1000 (non-binding) as long as someone explains why there is any need to change '-target 1.5' to '-target 1.6'. Seriously. I don't get it. You are really just changing the class file version and nothing else without any reason. I would like to know the reasioning. Nothing more. -- Christan - 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: [VOTE] Release Apache Maven IDEA Plugin version 2.2.1
+1 2013/7/23 Dennis Lundberg dennisl.apa...@gmail.com 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=11135styleName=Htmlversion=14478 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11135status=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 +==+
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
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?
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 mari.france...@gmail.com 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 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 mari.france...@gmail.com 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 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 mari.france...@gmail.com 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 mgai...@hotmail.com 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 mari.france...@gmail.com 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 m...@batmat.net 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 mari.france...@gmail.com 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 stephen.alan.conno...@gmail.com
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 m...@batmat.net 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 mari.france...@gmail.com
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 mari.france...@gmail.com 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 stephen.alan.conno...@gmail.com
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 m...@batmat.net 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 mari.france...@gmail.com
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 all for the useful isnights.
2013/7/24 Stephen Connolly stephen.alan.conno...@gmail.com
getPluginContext() is the one you want. Use that to stash your info.
On 24 July 2013 15:15, Francesco Mari mari.france...@gmail.com 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 stephen.alan.conno...@gmail.com
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 m...@batmat.net 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 mari.france...@gmail.com
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: [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: 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 chrisgw...@gmail.com: 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
[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 configuration 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: [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 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 configuration 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
Re: [VOTE] Release Apache Maven Model Converter version 2.3
+1 from me On Tue, Jul 23, 2013 at 9:45 PM, Dennis Lundberg denn...@apache.org 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=11761styleName=Htmlversion=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=truepid=11761component=13272status=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
[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 On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org 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=11761styleName=Htmlversion=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=truepid=11761component=13272status=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
Re: [DISCUSS] Moving unreleased shared components to the sandbox
I'm all for it On 24 July 2013 23:06, Dennis Lundberg denn...@apache.org 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: [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 rfscho...@apache.org 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 configuration 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] | |
Re: [DISCUSS] Moving unreleased shared components to the sandbox
Even more refreshing cleanup. Go Dennis! :) 2013/7/25 Dennis Lundberg denn...@apache.org 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 +==+
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
