Re: Open JIRA issues/retiring plugins
-1 for both archetype and stage plugin. Maybe I will have a look to fix issues if enough spare time.. I don't understand such rush... AFAIK we are not a company with some budget and who need to justify a ratio between number of bugs and time spent on projects. On 2 February 2015 at 20:23, Michael Osipov 1983-01...@gmx.net wrote: Hi folks, I have performed another cleanup on JIRA in the last couple of days, most of on old issues. Right now, we have more than 2000 open issues. Not manageble from my point of view. I have noticed that several plugins haven't been touched in years. What is the status of the following plugins: http://maven.apache.org/plugins/maven-docck-plugin/ http://maven.apache.org/plugins/maven-doap-plugin/ http://maven.apache.org/plugins/maven-repository-plugin/ http://maven.apache.org/plugins/maven-stage-plugin/ http://maven.apache.org/plugins/maven-eclipse-plugin/ http://maven.apache.org/plugins/maven-verifier-plugin/ http://maven.apache.org/plugins/maven-patch-plugin/ http://maven.apache.org/plugins/maven-pdf-plugin/ http://maven.apache.org/archetype/maven-archetype-plugin/ Is anyone working on them or planning to release a version? Any thoughts or objections? I'd like to retire them and clean up JIRA plugin by plugin. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [VOTE] Release Maven PMD Plugin version 3.4
+1 Regards, Hervé Le samedi 31 janvier 2015 20:05:51 Michael Osipov a écrit : Hi, We solved 15 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140version=20 775 There are still a couple of issues left in JIRA: https://jira.codehaus.org/browse/MPMD-186?jql=project%20%3D%20MPMD%20AND%20r esolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1135/ https://repository.apache.org/content/repositories/maven-1135/org/apache/mav en/plugins/maven-pmd-plugin/3.4/maven-pmd-plugin-3.4-source-release.zip Source release checksum(s): maven-pmd-plugin-3.4-source-release.zip sha1: d35664a952fda6eb150ae4c7f517b7e54c55340c Staging site: http://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Best practises for manipulating the JUL Logger in a Plugin
Implying that Maven should simply use SJF4J instead of the Maven logging, I
take it?
And - yes - that would be a simpler approach.
(Or at least an approach where one would not need to wrap/convert loggers
to loggers in a custom manner over and over ... ).
2015-02-02 17:02 GMT+01:00 Jason van Zyl ja...@takari.io:
Would it be easier if we just packaged jul-over-slf4j in the distribution
to cover these cases?
On Feb 2, 2015, at 10:07 AM, Lennart Jörelid lennart.jore...@gmail.com
wrote:
Hello all,
I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
encountered a (presumably) common problem. The plugin delegates most of
its
work to the JDK-distributed tools XJC and SchemaGen. These two tools use
JUL for logging; and their respective outputs should be emitted onto the
Maven Log for debugging and clarity.
Writing a small Handler which delegates the JUL LogRecords to the active
Maven Log is trivial - but I wonder if I need to reset the JUL root
logger
after the tool has been run, or if that is done automagically by Maven.
Basically - will the next downstream plugin which needs to wrap a tool
using JUL be affected by my fiddlings according to the snippet below?
// Redirect the JUL Logging statements to the Maven Log.
final Logger rootLogger = Logger.getLogger();
rootLogger.setLevel(Level.FINER);
for(Handler current : rootLogger.getHandlers()) {
rootLogger.removeHandler(current);
}
rootLogger.addHandler(new MavenLogHandler(getLog(), XJC,
getEncoding(false)));
// Fire XJC
if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
XjcLogAdapter(getLog( { ... display error message ... }
The approach works as expected - the boldfaced logging statements below
are
harvested from the XJC tool being put to work by the jabx2-maven-plugin:
[DEBUG] Created episode directory
[/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
true
[DEBUG] Using explicitly configured encoding [UTF-8]
*[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
com.sun.xml.bind.v2.util.XmlFactory
createSchemaFactoryFIN: SchemaFactory instance:
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df
[DEBUG]
[XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
allowExternalAccessFIN: Property
http://javax.xml.XMLConstants/property/accessExternalSchema
http://javax.xml.XMLConstants/property/accessExternalSchema is
supported
and has been successfully set by used JAXP implementation.*
--
--
+==+
| 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
+==+
Thanks,
Jason
--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
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: Best practises for manipulating the JUL Logger in a Plugin
On Feb 2, 2015, at 6:44 PM, Lennart Jörelid lennart.jore...@gmail.com wrote:
Implying that Maven should simply use SJF4J instead of the Maven logging, I
take it?
Maven does use SLF4J now. We use the slf4j-simple implementation by default. If
there are many libraries that use JUL then SLF4J provides a standard funnel for
that. It has one for commons-logging as well. I think both of these are small.
Not sure if there's any downside to including them if it just helps all these
libraries work in Maven.
And - yes - that would be a simpler approach.
(Or at least an approach where one would not need to wrap/convert loggers
to loggers in a custom manner over and over ... ).
2015-02-02 17:02 GMT+01:00 Jason van Zyl ja...@takari.io:
Would it be easier if we just packaged jul-over-slf4j in the distribution
to cover these cases?
On Feb 2, 2015, at 10:07 AM, Lennart Jörelid lennart.jore...@gmail.com
wrote:
Hello all,
I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
encountered a (presumably) common problem. The plugin delegates most of
its
work to the JDK-distributed tools XJC and SchemaGen. These two tools use
JUL for logging; and their respective outputs should be emitted onto the
Maven Log for debugging and clarity.
Writing a small Handler which delegates the JUL LogRecords to the active
Maven Log is trivial - but I wonder if I need to reset the JUL root
logger
after the tool has been run, or if that is done automagically by Maven.
Basically - will the next downstream plugin which needs to wrap a tool
using JUL be affected by my fiddlings according to the snippet below?
// Redirect the JUL Logging statements to the Maven Log.
final Logger rootLogger = Logger.getLogger();
rootLogger.setLevel(Level.FINER);
for(Handler current : rootLogger.getHandlers()) {
rootLogger.removeHandler(current);
}
rootLogger.addHandler(new MavenLogHandler(getLog(), XJC,
getEncoding(false)));
// Fire XJC
if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
XjcLogAdapter(getLog( { ... display error message ... }
The approach works as expected - the boldfaced logging statements below
are
harvested from the XJC tool being put to work by the jabx2-maven-plugin:
[DEBUG] Created episode directory
[/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
true
[DEBUG] Using explicitly configured encoding [UTF-8]
*[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
com.sun.xml.bind.v2.util.XmlFactory
createSchemaFactoryFIN: SchemaFactory instance:
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df
[DEBUG]
[XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
allowExternalAccessFIN: Property
http://javax.xml.XMLConstants/property/accessExternalSchema
http://javax.xml.XMLConstants/property/accessExternalSchema is
supported
and has been successfully set by used JAXP implementation.*
--
--
+==+
| 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
+==+
Thanks,
Jason
--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
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
+==+
Thanks,
Jason
--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Best practises for manipulating the JUL Logger in a Plugin
From which version of the Maven-Plugin-API are we using SLF4J Loggers,
Jason?
In the 2.2.1 plugin API, the AbstractMojo contains an
org.apache.maven.plugin.logging.Log.
I presume that this is changed in a later version of the plugin API, right?
public abstract class AbstractMojo
implements Mojo, ContextEnabled
{
/** Instance logger */
private Log log;
2015-02-03 0:50 GMT+01:00 Jason van Zyl ja...@takari.io:
On Feb 2, 2015, at 6:44 PM, Lennart Jörelid lennart.jore...@gmail.com
wrote:
Implying that Maven should simply use SJF4J instead of the Maven
logging, I
take it?
Maven does use SLF4J now. We use the slf4j-simple implementation by
default. If there are many libraries that use JUL then SLF4J provides a
standard funnel for that. It has one for commons-logging as well. I think
both of these are small. Not sure if there's any downside to including them
if it just helps all these libraries work in Maven.
And - yes - that would be a simpler approach.
(Or at least an approach where one would not need to wrap/convert loggers
to loggers in a custom manner over and over ... ).
2015-02-02 17:02 GMT+01:00 Jason van Zyl ja...@takari.io:
Would it be easier if we just packaged jul-over-slf4j in the
distribution
to cover these cases?
On Feb 2, 2015, at 10:07 AM, Lennart Jörelid lennart.jore...@gmail.com
wrote:
Hello all,
I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
encountered a (presumably) common problem. The plugin delegates most of
its
work to the JDK-distributed tools XJC and SchemaGen. These two tools
use
JUL for logging; and their respective outputs should be emitted onto
the
Maven Log for debugging and clarity.
Writing a small Handler which delegates the JUL LogRecords to the
active
Maven Log is trivial - but I wonder if I need to reset the JUL root
logger
after the tool has been run, or if that is done automagically by Maven.
Basically - will the next downstream plugin which needs to wrap a tool
using JUL be affected by my fiddlings according to the snippet below?
// Redirect the JUL Logging statements to the Maven Log.
final Logger rootLogger = Logger.getLogger();
rootLogger.setLevel(Level.FINER);
for(Handler current : rootLogger.getHandlers()) {
rootLogger.removeHandler(current);
}
rootLogger.addHandler(new MavenLogHandler(getLog(), XJC,
getEncoding(false)));
// Fire XJC
if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
XjcLogAdapter(getLog( { ... display error message ... }
The approach works as expected - the boldfaced logging statements below
are
harvested from the XJC tool being put to work by the
jabx2-maven-plugin:
[DEBUG] Created episode directory
[/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
true
[DEBUG] Using explicitly configured encoding [UTF-8]
*[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
com.sun.xml.bind.v2.util.XmlFactory
createSchemaFactoryFIN: SchemaFactory instance:
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df
[DEBUG]
[XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
allowExternalAccessFIN: Property
http://javax.xml.XMLConstants/property/accessExternalSchema
http://javax.xml.XMLConstants/property/accessExternalSchema is
supported
and has been successfully set by used JAXP implementation.*
--
--
+==+
| 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
+==+
Thanks,
Jason
--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
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
+==+
Thanks,
Jason
Re: [VOTE] Release Maven PMD Plugin version 3.4
+1 On 1 February 2015 at 06:05, Michael Osipov micha...@apache.org wrote: Hi, We solved 15 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11140version=20775 There are still a couple of issues left in JIRA: https://jira.codehaus.org/browse/MPMD-186?jql=project%20%3D%20MPMD%20AND% 20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1135/ https://repository.apache.org/content/repositories/maven- 1135/org/apache/maven/plugins/maven-pmd-plugin/3.4/maven- pmd-plugin-3.4-source-release.zip Source release checksum(s): maven-pmd-plugin-3.4-source-release.zip sha1: d35664a952fda6eb150ae4c7f517b7e54c55340c Staging site: http://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Best practises for manipulating the JUL Logger in a Plugin
Since Maven 3.1.0 SLF4J is included with the distribution. The Mojo logger is
baked in but you can use SLF4J is you prefer.
On Feb 2, 2015, at 6:58 PM, Lennart Jörelid lennart.jore...@gmail.com wrote:
From which version of the Maven-Plugin-API are we using SLF4J Loggers,
Jason?
In the 2.2.1 plugin API, the AbstractMojo contains an
org.apache.maven.plugin.logging.Log.
I presume that this is changed in a later version of the plugin API, right?
public abstract class AbstractMojo
implements Mojo, ContextEnabled
{
/** Instance logger */
private Log log;
2015-02-03 0:50 GMT+01:00 Jason van Zyl ja...@takari.io:
On Feb 2, 2015, at 6:44 PM, Lennart Jörelid lennart.jore...@gmail.com
wrote:
Implying that Maven should simply use SJF4J instead of the Maven
logging, I
take it?
Maven does use SLF4J now. We use the slf4j-simple implementation by
default. If there are many libraries that use JUL then SLF4J provides a
standard funnel for that. It has one for commons-logging as well. I think
both of these are small. Not sure if there's any downside to including them
if it just helps all these libraries work in Maven.
And - yes - that would be a simpler approach.
(Or at least an approach where one would not need to wrap/convert loggers
to loggers in a custom manner over and over ... ).
2015-02-02 17:02 GMT+01:00 Jason van Zyl ja...@takari.io:
Would it be easier if we just packaged jul-over-slf4j in the
distribution
to cover these cases?
On Feb 2, 2015, at 10:07 AM, Lennart Jörelid lennart.jore...@gmail.com
wrote:
Hello all,
I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
encountered a (presumably) common problem. The plugin delegates most of
its
work to the JDK-distributed tools XJC and SchemaGen. These two tools
use
JUL for logging; and their respective outputs should be emitted onto
the
Maven Log for debugging and clarity.
Writing a small Handler which delegates the JUL LogRecords to the
active
Maven Log is trivial - but I wonder if I need to reset the JUL root
logger
after the tool has been run, or if that is done automagically by Maven.
Basically - will the next downstream plugin which needs to wrap a tool
using JUL be affected by my fiddlings according to the snippet below?
// Redirect the JUL Logging statements to the Maven Log.
final Logger rootLogger = Logger.getLogger();
rootLogger.setLevel(Level.FINER);
for(Handler current : rootLogger.getHandlers()) {
rootLogger.removeHandler(current);
}
rootLogger.addHandler(new MavenLogHandler(getLog(), XJC,
getEncoding(false)));
// Fire XJC
if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
XjcLogAdapter(getLog( { ... display error message ... }
The approach works as expected - the boldfaced logging statements below
are
harvested from the XJC tool being put to work by the
jabx2-maven-plugin:
[DEBUG] Created episode directory
[/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
true
[DEBUG] Using explicitly configured encoding [UTF-8]
*[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
com.sun.xml.bind.v2.util.XmlFactory
createSchemaFactoryFIN: SchemaFactory instance:
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df
[DEBUG]
[XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
allowExternalAccessFIN: Property
http://javax.xml.XMLConstants/property/accessExternalSchema
http://javax.xml.XMLConstants/property/accessExternalSchema is
supported
and has been successfully set by used JAXP implementation.*
--
--
+==+
| 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
+==+
Thanks,
Jason
--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
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
|
Re: Open JIRA issues/retiring plugins
Hi, the plan was to release from almost all the plugins to make a last releases which has Maven 2.2.1 minimum and JDK 5 min. Furthermore I'm working on several of those plugins: maven-docck-plugin, maven-doap-plugin maven-repository-plugin maven-stage-plugin maven-pdf-plugin maven-archetype-plugin The maven-eclipse-plugin is one of them i would go with you to retire it cause m2e is in the meantime the correct way to go... But i would recommend that we make an annoucement on the User list and on google plus, twitter etc. and see how the reactions are On 2/2/15 10:23 AM, Michael Osipov wrote: Hi folks, I have performed another cleanup on JIRA in the last couple of days, most of on old issues. Right now, we have more than 2000 open issues. Not manageble from my point of view. I have noticed that several plugins haven't been touched in years. What is the status of the following plugins: http://maven.apache.org/plugins/maven-docck-plugin/ http://maven.apache.org/plugins/maven-doap-plugin/ http://maven.apache.org/plugins/maven-repository-plugin/ http://maven.apache.org/plugins/maven-stage-plugin/ http://maven.apache.org/plugins/maven-eclipse-plugin/ http://maven.apache.org/plugins/maven-verifier-plugin/ http://maven.apache.org/plugins/maven-patch-plugin/ http://maven.apache.org/plugins/maven-pdf-plugin/ http://maven.apache.org/archetype/maven-archetype-plugin/ Is anyone working on them or planning to release a version? Any thoughts or objections? I'd like to retire them and clean up JIRA plugin by plugin. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Open JIRA issues/retiring plugins
Agree with Anders: * +1 to deprecate maven-eclipse-plugin (coming from an happy M2E user from years), the community must acknowledge that this plugin is not the way to go and there's a modern an well-maintained alternative. * -1 to deprecate maven-archetype-plugin IMO it's still one of those plugins that you'll find in almost every docs, internal or external, to bootstrap project developments. I don't see an alternative as-of today. * -0 maven-docck-plugin: it's still referenced here at MOJO http://mojo.codehaus.org/development/performing-a-release.html#Preparing_for_the_First_Production_Release but I don't know its feature enough to have a strong opinion on this one. Just thought I would point this reference out. No opinion for this others. 2015-02-02 10:32 GMT+01:00 Anders Hammar and...@hammar.net: I strongly second that the maven-eclipse-plugin be retired. For us working in Eclipse, the m2e integration is the way to go. Also, there has not been any active work on that plugin for many years and I think we should clearly indicate to the community that there is very little hope anyone would fix any issues that people (still) using m-eclipse-p run into. However, I don't think that the maven-archetype-plugin should be retired. Although there might not be very much work on it, it is used in many Get Started guides on the Internet. /Anders On Mon, Feb 2, 2015 at 10:23 AM, Michael Osipov 1983-01...@gmx.net wrote: Hi folks, I have performed another cleanup on JIRA in the last couple of days, most of on old issues. Right now, we have more than 2000 open issues. Not manageble from my point of view. I have noticed that several plugins haven't been touched in years. What is the status of the following plugins: http://maven.apache.org/plugins/maven-docck-plugin/ http://maven.apache.org/plugins/maven-doap-plugin/ http://maven.apache.org/plugins/maven-repository-plugin/ http://maven.apache.org/plugins/maven-stage-plugin/ http://maven.apache.org/plugins/maven-eclipse-plugin/ http://maven.apache.org/plugins/maven-verifier-plugin/ http://maven.apache.org/plugins/maven-patch-plugin/ http://maven.apache.org/plugins/maven-pdf-plugin/ http://maven.apache.org/archetype/maven-archetype-plugin/ Is anyone working on them or planning to release a version? Any thoughts or objections? I'd like to retire them and clean up JIRA plugin by plugin. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!
Re: Open JIRA issues/retiring plugins
People are making new archetypes every day. I did a round of bugfixing a couple of years ago, I could do one again. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Open JIRA issues/retiring plugins
Just to be perfectly clear: I am volunteering to include archetype in the herd. I have submitted INFRA-9100 to move it to git. I have assigned http://jira.codehaus.org/browse/ARCHETYPE-471 to myself. So no need to send any email announcing its demise. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Roadmap Proposal Plugin Releases
Sounds good to me. I especially like the Maven 3.0 (not 3.0.5) requirement. /Anders On Mon, Feb 2, 2015 at 12:42 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, after some discussions at FOSDEM with Hervé, Kristian and Robert in Brussels i will summarize some ideas we would like to share here: Make a final release of all plugins with minium Maven 2.2.1 (prerequisites) and Java 1.5 The current state of this approach can be watched on the dist-tool [2] page. After that we can start making releases of the plugins which have minimum Maven 3.0 and JDK 6 (I think this will bring many cleanups in code etc.) To make this more clear for the users the plugin versions should be bumped to 3.0independant from their current version. This approach gives us the possibility to make in case of real bugs bug fix releases of the older plugins for JDK 5 etc. without confusion JDK 5/JDK6 etc. These are the steps to leave Maven 2 completely behind..Yeah ;-) Currently we have two (three) exceptions maven-site-plugin (some kind of special case), maven-scm-publish-plugin and maven-shade-plugin which already have the Maven 3 requirement. [1] http://www.mail-archive.com/dev%40maven.apache.org/msg102539.html [2] https://builds.apache.org/job/dist-tool-plugin/site/dist- tool-prerequisites.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [jira] (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations
Hi, On 2/2/15 10:15 AM, Michael Osipov wrote: Hi Karl Heinz, I am aware of the retirement plan. If i take a look into some of jira's it does not look like you are aware of the procedure, cause you have closed issues with the comment: Project has been retired, closing as won't fix. which is simply not true... Sorry...I don't like this... This is the procedure I will go. Anyawy, I will post the list first to figure out which plugins are really dead. Sorry on my part. Michael Hi Michael, If you like to prepare a list of plugins which should be retired it's a good idea but this should be shared on the DEV list before changing the JIRA in that way... furthermore only mark retired project in Jira AFTER the project has VOTEd accordingly... Apart from that i'm working on that and other plugins to be released... Furthermore please be aware of http://maven.apache.org/developers/retirement-plan-plugins.html Kind regards Karl Heinz Marbaise On 2/2/15 8:02 AM, Michael Osipov wrote: Am 2015-02-02 um 03:35 schrieb Olivier Lamy: Project retired?? Where is the vote for that? I'm using it sometimes so I will be very happy to not see it retired... Salut Olivier, I have performed a cleanup on JIRA in the last couple of days. Moreover, I have prepared a list of projects I'd like to propose for retirement which have not been updated for several years. Don't worry, I will cast the vote. If you thing anyone is going to solve that issue and push a release anytime soon, reopen it. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Open JIRA issues/retiring plugins
I strongly second that the maven-eclipse-plugin be retired. For us working in Eclipse, the m2e integration is the way to go. Also, there has not been any active work on that plugin for many years and I think we should clearly indicate to the community that there is very little hope anyone would fix any issues that people (still) using m-eclipse-p run into. However, I don't think that the maven-archetype-plugin should be retired. Although there might not be very much work on it, it is used in many Get Started guides on the Internet. /Anders On Mon, Feb 2, 2015 at 10:23 AM, Michael Osipov 1983-01...@gmx.net wrote: Hi folks, I have performed another cleanup on JIRA in the last couple of days, most of on old issues. Right now, we have more than 2000 open issues. Not manageble from my point of view. I have noticed that several plugins haven't been touched in years. What is the status of the following plugins: http://maven.apache.org/plugins/maven-docck-plugin/ http://maven.apache.org/plugins/maven-doap-plugin/ http://maven.apache.org/plugins/maven-repository-plugin/ http://maven.apache.org/plugins/maven-stage-plugin/ http://maven.apache.org/plugins/maven-eclipse-plugin/ http://maven.apache.org/plugins/maven-verifier-plugin/ http://maven.apache.org/plugins/maven-patch-plugin/ http://maven.apache.org/plugins/maven-pdf-plugin/ http://maven.apache.org/archetype/maven-archetype-plugin/ Is anyone working on them or planning to release a version? Any thoughts or objections? I'd like to retire them and clean up JIRA plugin by plugin. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Roadmap Proposal Plugin Releases
Hi, after some discussions at FOSDEM with Hervé, Kristian and Robert in Brussels i will summarize some ideas we would like to share here: Make a final release of all plugins with minium Maven 2.2.1 (prerequisites) and Java 1.5 The current state of this approach can be watched on the dist-tool [2] page. After that we can start making releases of the plugins which have minimum Maven 3.0 and JDK 6 (I think this will bring many cleanups in code etc.) To make this more clear for the users the plugin versions should be bumped to 3.0independant from their current version. This approach gives us the possibility to make in case of real bugs bug fix releases of the older plugins for JDK 5 etc. without confusion JDK 5/JDK6 etc. These are the steps to leave Maven 2 completely behind..Yeah ;-) Currently we have two (three) exceptions maven-site-plugin (some kind of special case), maven-scm-publish-plugin and maven-shade-plugin which already have the Maven 3 requirement. [1] http://www.mail-archive.com/dev%40maven.apache.org/msg102539.html [2] https://builds.apache.org/job/dist-tool-plugin/site/dist-tool-prerequisites.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plexus versus maven-artifact-manager
So all is well with 1.0-alpha-9-stable-1, of plexus-container-default,
but nothing newer! I suppose that I should keep that dependency for
the release at the 2.2.1 level, and then reconsider things.
On Mon, Feb 2, 2015 at 9:43 AM, Benson Margulies bimargul...@gmail.com wrote:
I'm attempting to pull archetype up to 2.2.1. I seem to have found a
disagreement between 2.2.1 of maven-artifact-manager and some version
of some part of plexus.
Is this a familiar story to anyone; is there, for example, some plexus
piece I need a different version of?
DefaultArtifactTransfomationManager has ...
public void initialize() throws InitializationException {
// TODO this is a hack until plexus can fix the ordering of the arrays
ArtifactTransformation transforms[] =
artifactTransformations.toArray( new ArtifactTransformation[]{} );
for (int x = 0; x transforms.length; x++)
{
if (transforms[x].getClass().getName().indexOf(Snapshot) != -1) {
artifactTransformations.remove(transforms[x]);
artifactTransformations.add(transforms[x]);
}
}
}
Resulting in
Caused by: java.lang.UnsupportedOperationException: You cannot modify
this list. This list is a requirement of role:
'org.apache.maven.artifact.transform.ArtifactTransformationManager',
implementation:
'org.apache.maven.artifact.transform.DefaultArtifactTransformationManager',
role hint: 'default' and managed by the container.
at
org.codehaus.plexus.component.collections.ComponentList.remove(ComponentList.java:91)
at
org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.initialize(DefaultArtifactTransformationManager.java:44)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:96)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.start(AbstractComponentManager.java:167)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder.startComponentLifecycle(XBeanComponentBuilder.java:283)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder.build(XBeanComponentBuilder.java:129)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:181)
at
org.codehaus.plexus.component.manager.SingletonComponentManager.getComponent(SingletonComponentManager.java:67)
at
org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:358)
at
org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:178)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:393)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder$RequirementRecipe.internalCreate(XBeanComponentBuilder.java:402)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:167)
at org.apache.xbean.recipe.ObjectRecipe.setProperty(ObjectRecipe.java:497)
... 79 more
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Plexus versus maven-artifact-manager
I'm attempting to pull archetype up to 2.2.1. I seem to have found a
disagreement between 2.2.1 of maven-artifact-manager and some version
of some part of plexus.
Is this a familiar story to anyone; is there, for example, some plexus
piece I need a different version of?
DefaultArtifactTransfomationManager has ...
public void initialize() throws InitializationException {
// TODO this is a hack until plexus can fix the ordering of the arrays
ArtifactTransformation transforms[] =
artifactTransformations.toArray( new ArtifactTransformation[]{} );
for (int x = 0; x transforms.length; x++)
{
if (transforms[x].getClass().getName().indexOf(Snapshot) != -1) {
artifactTransformations.remove(transforms[x]);
artifactTransformations.add(transforms[x]);
}
}
}
Resulting in
Caused by: java.lang.UnsupportedOperationException: You cannot modify
this list. This list is a requirement of role:
'org.apache.maven.artifact.transform.ArtifactTransformationManager',
implementation:
'org.apache.maven.artifact.transform.DefaultArtifactTransformationManager',
role hint: 'default' and managed by the container.
at
org.codehaus.plexus.component.collections.ComponentList.remove(ComponentList.java:91)
at
org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.initialize(DefaultArtifactTransformationManager.java:44)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:96)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.start(AbstractComponentManager.java:167)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder.startComponentLifecycle(XBeanComponentBuilder.java:283)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder.build(XBeanComponentBuilder.java:129)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:181)
at
org.codehaus.plexus.component.manager.SingletonComponentManager.getComponent(SingletonComponentManager.java:67)
at
org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:358)
at
org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:178)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:393)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder$RequirementRecipe.internalCreate(XBeanComponentBuilder.java:402)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:167)
at org.apache.xbean.recipe.ObjectRecipe.setProperty(ObjectRecipe.java:497)
... 79 more
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Best practises for manipulating the JUL Logger in a Plugin
Hello all,
I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
encountered a (presumably) common problem. The plugin delegates most of its
work to the JDK-distributed tools XJC and SchemaGen. These two tools use
JUL for logging; and their respective outputs should be emitted onto the
Maven Log for debugging and clarity.
Writing a small Handler which delegates the JUL LogRecords to the active
Maven Log is trivial - but I wonder if I need to reset the JUL root logger
after the tool has been run, or if that is done automagically by Maven.
Basically - will the next downstream plugin which needs to wrap a tool
using JUL be affected by my fiddlings according to the snippet below?
// Redirect the JUL Logging statements to the Maven Log.
final Logger rootLogger = Logger.getLogger();
rootLogger.setLevel(Level.FINER);
for(Handler current : rootLogger.getHandlers()) {
rootLogger.removeHandler(current);
}
rootLogger.addHandler(new MavenLogHandler(getLog(), XJC, getEncoding(false)));
// Fire XJC
if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
XjcLogAdapter(getLog( { ... display error message ... }
The approach works as expected - the boldfaced logging statements below are
harvested from the XJC tool being put to work by the jabx2-maven-plugin:
[DEBUG] Created episode directory
[/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
true
[DEBUG] Using explicitly configured encoding [UTF-8]
*[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
createSchemaFactoryFIN: SchemaFactory instance:
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df[DEBUG]
[XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
allowExternalAccessFIN: Property
http://javax.xml.XMLConstants/property/accessExternalSchema
http://javax.xml.XMLConstants/property/accessExternalSchema is supported
and has been successfully set by used JAXP implementation.*
--
--
+==+
| 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: Plexus versus maven-artifact-manager
On Monday, 2 February 2015 at 14:43, Benson Margulies wrote:
I'm attempting to pull archetype up to 2.2.1. I seem to have found a
disagreement between 2.2.1 of maven-artifact-manager and some version
of some part of plexus.
Is this a familiar story to anyone; is there, for example, some plexus
piece I need a different version of?
The 2.2.1 version of DefaultArtifactTransformationManager (from
maven-artifact-manager, a transitive dependency of maven-core 2.x) is
attempting to mutate a managed/read-only collection. You could get away with
this in Plexus 1.0-alpha-9-stable-1 because it just happened to expose the
underlying mutable collection. This is not allowed in later versions of both
Plexus and the Guice-Plexus shim. Ideally it should use its own collection to
do the local mutation/filtering, but since there won’t be any more releases of
that particular module then you need to test it with the old container.
Note that the maven-artifact-manager API (a transitive dependency of
maven-core) is gone in Maven3 - it was moved into the maven-compat module and
subsequently moved to a different package:
https://github.com/apache/maven/commit/ee5dd78bd1a0b96edf2cc53480b342bb74b9a173
https://jira.codehaus.org/browse/MNG-4221
So this won’t cause any issues at runtime since Maven filters out core
dependencies, it’s just at test-time that you have to be careful about keeping
the versions of maven and the container in sync.
DefaultArtifactTransfomationManager has ...
public void initialize() throws InitializationException {
// TODO this is a hack until plexus can fix the ordering of the arrays
ArtifactTransformation transforms[] =
artifactTransformations.toArray( new ArtifactTransformation[]{} );
for (int x = 0; x transforms.length; x++)
{
if (transforms[x].getClass().getName().indexOf(Snapshot) != -1) {
artifactTransformations.remove(transforms[x]);
artifactTransformations.add(transforms[x]);
}
}
}
Resulting in
Caused by: java.lang.UnsupportedOperationException: You cannot modify
this list. This list is a requirement of role:
'org.apache.maven.artifact.transform.ArtifactTransformationManager',
implementation:
'org.apache.maven.artifact.transform.DefaultArtifactTransformationManager',
role hint: 'default' and managed by the container.
at
org.codehaus.plexus.component.collections.ComponentList.remove(ComponentList.java:91)
at
org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.initialize(DefaultArtifactTransformationManager.java:44)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:96)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.start(AbstractComponentManager.java:167)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder.startComponentLifecycle(XBeanComponentBuilder.java:283)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder.build(XBeanComponentBuilder.java:129)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:181)
at
org.codehaus.plexus.component.manager.SingletonComponentManager.getComponent(SingletonComponentManager.java:67)
at
org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:358)
at
org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:178)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:393)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder$RequirementRecipe.internalCreate(XBeanComponentBuilder.java:402)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:167)
at org.apache.xbean.recipe.ObjectRecipe.setProperty(ObjectRecipe.java:497)
... 79 more
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
(mailto:dev-unsubscr...@maven.apache.org)
For additional commands, e-mail: dev-h...@maven.apache.org
(mailto:dev-h...@maven.apache.org)
Re: Best practises for manipulating the JUL Logger in a Plugin
Would it be easier if we just packaged jul-over-slf4j in the distribution to
cover these cases?
On Feb 2, 2015, at 10:07 AM, Lennart Jörelid lennart.jore...@gmail.com wrote:
Hello all,
I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
encountered a (presumably) common problem. The plugin delegates most of its
work to the JDK-distributed tools XJC and SchemaGen. These two tools use
JUL for logging; and their respective outputs should be emitted onto the
Maven Log for debugging and clarity.
Writing a small Handler which delegates the JUL LogRecords to the active
Maven Log is trivial - but I wonder if I need to reset the JUL root logger
after the tool has been run, or if that is done automagically by Maven.
Basically - will the next downstream plugin which needs to wrap a tool
using JUL be affected by my fiddlings according to the snippet below?
// Redirect the JUL Logging statements to the Maven Log.
final Logger rootLogger = Logger.getLogger();
rootLogger.setLevel(Level.FINER);
for(Handler current : rootLogger.getHandlers()) {
rootLogger.removeHandler(current);
}
rootLogger.addHandler(new MavenLogHandler(getLog(), XJC,
getEncoding(false)));
// Fire XJC
if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
XjcLogAdapter(getLog( { ... display error message ... }
The approach works as expected - the boldfaced logging statements below are
harvested from the XJC tool being put to work by the jabx2-maven-plugin:
[DEBUG] Created episode directory
[/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
true
[DEBUG] Using explicitly configured encoding [UTF-8]
*[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
createSchemaFactoryFIN: SchemaFactory instance:
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df[DEBUG]
[XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
allowExternalAccessFIN: Property
http://javax.xml.XMLConstants/property/accessExternalSchema
http://javax.xml.XMLConstants/property/accessExternalSchema is supported
and has been successfully set by used JAXP implementation.*
--
--
+==+
| 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
+==+
Thanks,
Jason
--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [mojo-dev] Best practises for manipulating the JUL Logger in a Plugin
Should you really be using the JVM of maven to run these tools?
I would argue no. You should be forking the toolchains specified JVM and
using that forked JVM to do the work. If you do it that way you can
completely control what logging those forked JVMs uses and route it to the
Maven logger of choice
On 2 February 2015 at 15:07, Lennart Jörelid lennart.jore...@gmail.com
wrote:
Hello all,
I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
encountered a (presumably) common problem. The plugin delegates most of its
work to the JDK-distributed tools XJC and SchemaGen. These two tools use
JUL for logging; and their respective outputs should be emitted onto the
Maven Log for debugging and clarity.
Writing a small Handler which delegates the JUL LogRecords to the active
Maven Log is trivial - but I wonder if I need to reset the JUL root logger
after the tool has been run, or if that is done automagically by Maven.
Basically - will the next downstream plugin which needs to wrap a tool
using JUL be affected by my fiddlings according to the snippet below?
// Redirect the JUL Logging statements to the Maven Log.
final Logger rootLogger = Logger.getLogger();
rootLogger.setLevel(Level.FINER);
for(Handler current : rootLogger.getHandlers()) {
rootLogger.removeHandler(current);
}
rootLogger.addHandler(new MavenLogHandler(getLog(), XJC,
getEncoding(false)));
// Fire XJC
if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
XjcLogAdapter(getLog( { ... display error message ... }
The approach works as expected - the boldfaced logging statements below
are harvested from the XJC tool being put to work by the jabx2-maven-plugin:
[DEBUG] Created episode directory
[/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
true
[DEBUG] Using explicitly configured encoding [UTF-8]
*[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
com.sun.xml.bind.v2.util.XmlFactory createSchemaFactoryFIN: SchemaFactory
instance:
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df[DEBUG]
[XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
allowExternalAccessFIN: Property
http://javax.xml.XMLConstants/property/accessExternalSchema
http://javax.xml.XMLConstants/property/accessExternalSchema is supported
and has been successfully set by used JAXP implementation.*
--
--
+==+
| 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: Open JIRA issues/retiring plugins
I’m -1 to retiring the maven-eclipse-plugin until the m2e stuff is at a state where it can be as flexible and useful as the maven-eclipse-plugin. Trying to bring a large complex project like CXF into eclipse with m2e is PAINFUL and doesn’t even result in fully configured and ready workspace. The developer experience within eclipse is so much better after using the maven-eclipse-plugin. I suppose that does mean I should step up and look at some of the JIRA’s and get a release out. I’ll see if I can find some time. Dan On Feb 2, 2015, at 4:23 AM, Michael Osipov 1983-01...@gmx.net wrote: Hi folks, I have performed another cleanup on JIRA in the last couple of days, most of on old issues. Right now, we have more than 2000 open issues. Not manageble from my point of view. I have noticed that several plugins haven't been touched in years. What is the status of the following plugins: http://maven.apache.org/plugins/maven-docck-plugin/ http://maven.apache.org/plugins/maven-doap-plugin/ http://maven.apache.org/plugins/maven-repository-plugin/ http://maven.apache.org/plugins/maven-stage-plugin/ http://maven.apache.org/plugins/maven-eclipse-plugin/ http://maven.apache.org/plugins/maven-verifier-plugin/ http://maven.apache.org/plugins/maven-patch-plugin/ http://maven.apache.org/plugins/maven-pdf-plugin/ http://maven.apache.org/archetype/maven-archetype-plugin/ Is anyone working on them or planning to release a version? Any thoughts or objections? I'd like to retire them and clean up JIRA plugin by plugin. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Open JIRA issues/retiring plugins
I'm pretty sure I might be bashed for writing this, but what the heck... ;-) I do still see some need for the maven-eclipse-plugin. To be perfectly clear, I agree that m2e is by far superior in many ways, not only tech-wise, but also conceptionally. Still, at work we had to migrate from m2e to m-eclipse-p a couple of years ago, which included some minor adaptations to the plugin, and it works like a charm since then (that was back in the days when m2e was far away from version 1.0.0). We have a workspace with about 500 projects and we commit the eclipse metadata for each project to our source repository. Changes in the poms don't happen that often, and if needed that one colleague runs m-eclipse-p to update the metadata and commits everything in one go. The other colleagues do their update, refresh in eclipse, maybe run a batch file to download newly referenced jars to the local repo, and they're done. Eclipse will build quite quickly. I just tried the latest m2e version with our projects and, although it's by far better than it was some years ago, I had to tripple my memory settings and wait 20 minutes for the update project... and the following build. That's something I can't sell to my colleagues (many of them don't even have enough RAM for that, sadly enough). So I'm herby volunteering to go ahead and pull out some of the adjustments that I did for my customer and I'd be happy to do a release. If there's a chance to get some PMC votes on such a thing ;-). I'd also include a disclaimer on the site that builds with m2e are in many cases closer to the real maven build, that m2e is much more maintained, that it is discouraged to use m-eclipse-p, and that the maven team strongly suggests using m2e. Something like that. WDYT? Andreas 2015-02-02 14:00 GMT+01:00 Benson Margulies bimargul...@gmail.com: Just to be perfectly clear: I am volunteering to include archetype in the herd. I have submitted INFRA-9100 to move it to git. I have assigned http://jira.codehaus.org/browse/ARCHETYPE-471 to myself. So no need to send any email announcing its demise. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Open JIRA issues/retiring plugins
Great, Daniel, I thought I'm the only one thinking that way... ;-) 2015-02-02 19:38 GMT+01:00 Daniel Kulp dk...@apache.org: I’m -1 to retiring the maven-eclipse-plugin until the m2e stuff is at a state where it can be as flexible and useful as the maven-eclipse-plugin. Trying to bring a large complex project like CXF into eclipse with m2e is PAINFUL and doesn’t even result in fully configured and ready workspace. The developer experience within eclipse is so much better after using the maven-eclipse-plugin. I suppose that does mean I should step up and look at some of the JIRA’s and get a release out. I’ll see if I can find some time. Dan On Feb 2, 2015, at 4:23 AM, Michael Osipov 1983-01...@gmx.net wrote: Hi folks, I have performed another cleanup on JIRA in the last couple of days, most of on old issues. Right now, we have more than 2000 open issues. Not manageble from my point of view. I have noticed that several plugins haven't been touched in years. What is the status of the following plugins: http://maven.apache.org/plugins/maven-docck-plugin/ http://maven.apache.org/plugins/maven-doap-plugin/ http://maven.apache.org/plugins/maven-repository-plugin/ http://maven.apache.org/plugins/maven-stage-plugin/ http://maven.apache.org/plugins/maven-eclipse-plugin/ http://maven.apache.org/plugins/maven-verifier-plugin/ http://maven.apache.org/plugins/maven-patch-plugin/ http://maven.apache.org/plugins/maven-pdf-plugin/ http://maven.apache.org/archetype/maven-archetype-plugin/ Is anyone working on them or planning to release a version? Any thoughts or objections? I'd like to retire them and clean up JIRA plugin by plugin. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
MavenProjectBuilder
Somewhere between 2.0 and 2.2, MavenProjectBuilder changed to build
projects with property references in them. For example,
.getBuild().getDirectory():
${project.basedir}/target
There are tests in archetype that are pretty confused by this. Can
someone remind me of how to obtain an interpolated value for these
items?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-plugins pull request: Update error-prone integration test
Github user cushon closed the pull request at: https://github.com/apache/maven-plugins/pull/43 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MavenProjectBuilder
To be exact, DefaultMavenProjectBuilder goes to extra trouble to end
up with a 'dynamic' version of the Build, not the resolved version,
and this test needs the resolved one.
On Mon, Feb 2, 2015 at 12:19 PM, Benson Margulies bimargul...@gmail.com wrote:
Somewhere between 2.0 and 2.2, MavenProjectBuilder changed to build
projects with property references in them. For example,
.getBuild().getDirectory():
${project.basedir}/target
There are tests in archetype that are pretty confused by this. Can
someone remind me of how to obtain an interpolated value for these
items?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [jira] (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations
Hi Michael, If you like to prepare a list of plugins which should be retired it's a good idea but this should be shared on the DEV list before changing the JIRA in that way... furthermore only mark retired project in Jira AFTER the project has VOTEd accordingly... Apart from that i'm working on that and other plugins to be released... Furthermore please be aware of http://maven.apache.org/developers/retirement-plan-plugins.html Kind regards Karl Heinz Marbaise On 2/2/15 8:02 AM, Michael Osipov wrote: Am 2015-02-02 um 03:35 schrieb Olivier Lamy: Project retired?? Where is the vote for that? I'm using it sometimes so I will be very happy to not see it retired... Salut Olivier, I have performed a cleanup on JIRA in the last couple of days. Moreover, I have prepared a list of projects I'd like to propose for retirement which have not been updated for several years. Don't worry, I will cast the vote. If you thing anyone is going to solve that issue and push a release anytime soon, reopen it. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: [jira] (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations
Hi Karl Heinz, I am aware of the retirement plan. This is the procedure I will go. Anyawy, I will post the list first to figure out which plugins are really dead. Sorry on my part. Michael Hi Michael, If you like to prepare a list of plugins which should be retired it's a good idea but this should be shared on the DEV list before changing the JIRA in that way... furthermore only mark retired project in Jira AFTER the project has VOTEd accordingly... Apart from that i'm working on that and other plugins to be released... Furthermore please be aware of http://maven.apache.org/developers/retirement-plan-plugins.html Kind regards Karl Heinz Marbaise On 2/2/15 8:02 AM, Michael Osipov wrote: Am 2015-02-02 um 03:35 schrieb Olivier Lamy: Project retired?? Where is the vote for that? I'm using it sometimes so I will be very happy to not see it retired... Salut Olivier, I have performed a cleanup on JIRA in the last couple of days. Moreover, I have prepared a list of projects I'd like to propose for retirement which have not been updated for several years. Don't worry, I will cast the vote. If you thing anyone is going to solve that issue and push a release anytime soon, reopen it. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Open JIRA issues/retiring plugins
Hi folks, I have performed another cleanup on JIRA in the last couple of days, most of on old issues. Right now, we have more than 2000 open issues. Not manageble from my point of view. I have noticed that several plugins haven't been touched in years. What is the status of the following plugins: http://maven.apache.org/plugins/maven-docck-plugin/ http://maven.apache.org/plugins/maven-doap-plugin/ http://maven.apache.org/plugins/maven-repository-plugin/ http://maven.apache.org/plugins/maven-stage-plugin/ http://maven.apache.org/plugins/maven-eclipse-plugin/ http://maven.apache.org/plugins/maven-verifier-plugin/ http://maven.apache.org/plugins/maven-patch-plugin/ http://maven.apache.org/plugins/maven-pdf-plugin/ http://maven.apache.org/archetype/maven-archetype-plugin/ Is anyone working on them or planning to release a version? Any thoughts or objections? I'd like to retire them and clean up JIRA plugin by plugin. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
