Re: 2.1.x ITs
On 18-Apr-08, at 7:22 PM, Brett Porter wrote: On 19/04/2008, at 12:32 AM, Jason van Zyl wrote: If this is the only one failing then it's a Maven problem and I'm going to merge in XBR to Plexus and then in Maven. Can you elaborate on what this will facilitate in Maven? Employing a more widely used DI mechanism (Geronimo, OpenEJB) that provides constructor injection, factory beans and full support for generics. I looked at Guice and XBean reflect. Guice cannot support what we do as it only does annotations, and Dain wanted to do the work in this first phase and Paul/Mauro will also help when we get to the next stage which is merging all of this with Pico. It's part of getting XBR, Pico, and Plexus all cooperating. XBR also seamlessly integrated in a completely non-invasive way which is pretty impressive. I didn't have to make a single change in Maven, and no one will have to make a single change in any Plexus component or Maven plugin which is really quite amazing. So we can go forward with many more features that XBR provides without violating any existing contracts. Dain just made it all work. I'm frankly excited as it injects some new blood into the core of Maven. We'll now have Dain and David to help on very core issues, and when Pico enters the mix we'll have Paul and Mauro. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1.x ITs
On 19/04/2008, at 12:32 AM, Jason van Zyl wrote: If this is the only one failing then it's a Maven problem and I'm going to merge in XBR to Plexus and then in Maven. Can you elaborate on what this will facilitate in Maven? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
2.0.9 and self referential properties failing
It looks like Maven 2.0.9 is refusing to resolve the JRuby 1.0 dependencies
due to a self referential property in its POM:
[WARNING] POM for 'org.jruby:jruby:pom:1.0:test' is invalid. It will be
ignored for artifact resolution. Reason: The POM expression:
${java.specification.version} could not be evaluated. Reason: Expression
value '${java.specification.version}' references itself in
'org.jruby:jruby:jar:1.0'. for project org.jruby:jruby at Artifact
[org.jruby:jruby:pom:1.0:test]
Obviously the ${java.specification.version} property should be resolved via
system properties, so I am wondering if there is a change in property
resolution order or something similar that has caused this to start failing
where it was working with 2.0.8.
The property entry:
${java.specification.version}
I would think that this should resolve to the system property first and not
cause the failure to resolve, but I wanted to pass this along here before
filing a bug. Thoughts?
Chris
RE: Maven PMD plugin dependency on pmd Jar is out of date
FWIW, in 2.0.9 you can override the plugin dependency and force a newer version of the PMD jar (provided the api is compatible of course) -Original Message- From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2008 3:08 PM To: dev@maven.apache.org Subject: Re: Maven PMD plugin dependency on pmd Jar is out of date Amir Eliaz wrote: > So the problem really is a wrong dependency in maven-pmd-plugin-2.3.pom, > which is the latest for this plugin. The dependency in general is not wrong, it's just inappropriate for users that would like to use newer rules. The SVN head has just been updated to use 4.2.1 (see http://jira.codehaus.org/browse/MPMD-78). Until the PMD Plugin 2.4 gets released, the following should solve your problem: ... maven-pmd-plugin 2.3 pmd pmd-jdk14 4.2.1 ... i.e. overwrite the plugin class path with the PMD version your require. Note that this must be done using , there is no element under . Benjamin -- View this message in context: http://www.nabble.com/Maven-PMD-plugin-dependency-on-pmd-Jar-is-out-of-d ate-tp16746339s177p16764207.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deployment of maven-pmd-plugin:2.4-SNAPSHOT
You'll have to check who owns them and ask them to run the fix-permissions script in the root of the m2-snap repo. -Original Message- From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2008 7:09 PM To: Maven Developers List Subject: Deployment of maven-pmd-plugin:2.4-SNAPSHOT Hi, I wanted to deploy a new 2.4-snapshot of the PMD Plugin but failed because the existing metadata files are not group-writable. Can somebody help and fix the file permissions? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deployment of maven-pmd-plugin:2.4-SNAPSHOT
Hi, I wanted to deploy a new 2.4-snapshot of the PMD Plugin but failed because the existing metadata files are not group-writable. Can somebody help and fix the file permissions? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven PMD plugin dependency on pmd Jar is out of date
Amir Eliaz wrote: > So the problem really is a wrong dependency in maven-pmd-plugin-2.3.pom, > which is the latest for this plugin. The dependency in general is not wrong, it's just inappropriate for users that would like to use newer rules. The SVN head has just been updated to use 4.2.1 (see http://jira.codehaus.org/browse/MPMD-78). Until the PMD Plugin 2.4 gets released, the following should solve your problem: ... maven-pmd-plugin 2.3 pmd pmd-jdk14 4.2.1 ... i.e. overwrite the plugin class path with the PMD version your require. Note that this must be done using , there is no element under . Benjamin -- View this message in context: http://www.nabble.com/Maven-PMD-plugin-dependency-on-pmd-Jar-is-out-of-date-tp16746339s177p16764207.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Maven Archetype plugin version 2.0-alpha-3 [take 2]
Hi, We solved 22 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088 Staging repo: http://people.apache.org/~rafale/archetype-stage-repository/ Staging site: http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Raphaël
Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-3 [take 2]
My +1 Raphaël 2008/4/18, Raphaël Piéroni <[EMAIL PROTECTED]>: > Hi, > > We solved 22 issues: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088 > > Staging repo: > http://people.apache.org/~rafale/archetype-stage-repository/ > > Staging site: > http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > Raphaël >
Re: Change to artifact version handling.
Hi Paul, I think this thread is very close to this one: http://www.nabble.com/How-to-use-central-repo-into-an-Eclipse-project--td16676423s177.html Cheers, Vincent 2008/4/15, Paul Gier <[EMAIL PROTECTED]>: > Hi everyone, > > I'd like to make a small change to the artifact version parsing. We > currently have several released projects that use a non-standard version > scheme. So instead of something like: > 1.0.1-beta-1 > we have > 1.0.1.beta1 > > This was originally done to conform to the OSGi standard which requires a > "." instead of a "-" for the qualifier. If you ask me, the maven standard > is better ;) > > I created a jira issue with the attached fix here: > http://jira.codehaus.org/browse/MNG-3526 > > Since this change could potentially (although I think unlikely) break some > dependency management I wanted to bring it up here to discuss. > > Thanks! > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Change to artifact version handling.
yes, see http://docs.codehaus.org/display/MAVEN/Versioning Le vendredi 18 avril 2008, Brett Porter a écrit : > I believe Kenney wrote a proposal on the wiki, and maybe even some > code, for some changes - it would be worth reviewing them too. > > - Brett > > On 18/04/2008, at 12:27 AM, Paul Gier wrote: > > While looking into this, I noticed that the release plugin uses it's > > own version parsing instead of the parsing in the maven-artifact > > component. > > > > https://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manage > >r/src/main/java/org/apache/maven/shared/release/versions/DefaultVersionInf > >o.java > > > > It uses a regular expression to parse the version which is probably > > better than the parsing in maven-artifact. Maybe maven 2.1 version > > parsing should be changed to something like this. > > > > Christian Edward Gruber wrote: > >> Would it not be helpful to have a version pattern, somewhat the way > >> dates have patterns for parsing, so that there can be the default, > >> an osgi standard pattern, and a custom one specified in the pom? > >> So a pattern might be xx.[yy.[zz.[pp]]] or xx.yy.pp- > >> Where xx == major, yy == medium, zz == minor, pp == patch, and > >> == alphanumeric. > >> The parsing engine could treat xx/yy/zz/pp as numeric for > >> comparison, and can do lexical comparison. dots and dashes > >> would be both available as punctuation. Square brackets would > >> indicate scopes of optional use. You could even add ## for > >> supplementary numericals. > >> The maven default sounds like xx.yy[-], and osgi sounds like > >> xx.yy.zz. (no optionals) > >> Having said that, a simpler option would be to have - or . parsed > >> as equivalent punctuation tokens, and have numerical ordering if > >> it's convertable to a number or lexical ordering if not, on each > >> item between the punctuations. so: > >> 1.2.3-beta-2 would come after 1.2.2.alpha-3, and 1.2.3-alpha-1 > >> would come between them. > >> Of course, the above works with the "pluggable" bit spoken of > >> elsewhere in this thread. > >> Christian. > >> > >> On 17-Apr-08, at 09:59 , Paul Gier wrote: > >>> Since it doesn't change the parsing of the standard maven version > >>> string, I think the risk is pretty low. I see it as basically > >>> better handling of one type of non-standard format. But I > >>> understand your concern, that's why I brought it up for > >>> discussion ;) > >>> > >>> Brian E. Fox wrote: > These kinds of changes in the 2.0.x branch concern me. There's no > way to > predict what impact this will have out there. > -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, > April 17, 2008 5:23 AM > To: Maven Developers List > Subject: Re: Change to artifact version handling. > I haven't yet applied it, but at first thought it seems a > reasonable change. > - Brett > > On 16/04/2008, at 6:37 AM, Paul Gier wrote: > > Hi everyone, > > > > I'd like to make a small change to the artifact version > > parsing. We currently have several released projects that use > > a non-standard version scheme. So instead of something like: > > 1.0.1-beta-1 > > we have > > 1.0.1.beta1 > > > > This was originally done to conform to the OSGi standard which > > requires a "." instead of a "-" for the qualifier. If you ask > > me, the maven standard is better ;) > > > > I created a jira issue with the attached fix here: > > http://jira.codehaus.org/browse/MNG-3526 > > > > Since this change could potentially (although I think unlikely) > > break some dependency management I wanted to bring it up here > > to discuss. > > > > Thanks! > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-m
Re: 2.1.x ITs
I fixed that test last week in maven 2.1 -john On Apr 18, 2008, at 12:32 PM, Jason van Zyl wrote: John, was just talking to Brian to see how many ITs were failing with 2.1.x as I used the whole system using xbean reflect and I only see one IT failing: testitMNG3473 (org.apache.maven.integrationtests.MavenITmng3473PluginReportCrash) I'm loading this back up in Hudson as the the last run didn't even get started. If this is the only one failing then it's a Maven problem and I'm going to merge in XBR to Plexus and then in Maven. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
2.1.x ITs
John, was just talking to Brian to see how many ITs were failing with 2.1.x as I used the whole system using xbean reflect and I only see one IT failing: testitMNG3473 (org.apache.maven.integrationtests.MavenITmng3473PluginReportCrash) I'm loading this back up in Hudson as the the last run didn't even get started. If this is the only one failing then it's a Maven problem and I'm going to merge in XBR to Plexus and then in Maven. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] eclipse plugin extensibility
Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some "extension" file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : maven-eclipse-plugin ... sysdeo-tomcat org.codehaus.mojo sysdeo-tomcat-maven-plugin x Beeing added to the plugin classpath, the "plugin-extension" could add it's EclipseWriters, and maybe other optional components (to setup ProjectNatures ?). Many other extensions could be added this way to the eclipse plugin : generate SpringIDE configuration, setup Checkstyle in sync with the maven-checkstyle configuration, etc. Another benefict is that the "extension" could benefict from the forked generate-source execution that the eclipse-plugin runs, to access the list of multi-project modules. Any suggestion is welcome. Nicolas.
