Re: Proposal: Parent pom for Java 11 and 17 with latest maven plugin versions
Maybe we need a BOM import for all maven plugin versions instead? Currently all projects in the ASF forge have to individually update the compiler, surefire, ... plugin versions individually and figure out which maven plugin versions are compatible. With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Proposal: Parent pom for Java 11 and 17 with latest maven plugin versions
*Summary
*
Specifying the Java version (11, 17, ...)
and latest maven plugin versions (compiler 3.11.0, surefire 3.1.2,
failsafe, ...)
in every pom is a tedious and brittle.
Existing parent poms are de-standarized and bloated.
This proposal solves that by introducing
a standardized parent pom for Java 17 (and Java 11)
that sets the latest maven plugins versions.
*Motivation
*Any professional Maven build:
- has reproducible builds
- uses the latest maven plugin versions
- uses a recent Java version (not Java 5 or 8)
- specify the minimum Maven version
To that do it, users have to add 50+ lines to their pom.xml:
17
3.9.2
3.11.0
3.1.2
3.3.0
3.5.0
3.6.0
3.3.0
...
...
maven-compiler-plugin
${version.compiler.plugin}
...
**
*Existing implementations*
_Superpom_
- The superpom version is not specified in the pom.xml. It's not a
reproducible build.
- The superpom does not enforce a minimum Maven version (catch 22).
- The superpom uses java 8. To overwrite it, do it for the compiler
plugin, the javadoc plugin, ...
- The superpom is not released regularly to update to the latest maven
plugin versions of compiler, surefire, failsafe, etc.
- There is no documention on how to lock in the superpom version.
Therefore, the superpom is not a solution.
_JBoss parent and Spring parent_
The JBoss parent and Spring parent poms target only their own users (=
not every Maven user) and provide a much wider scope (= bloat).
They:
- Set url and mailing lists for springframework.org or jboss.org
- Set the license
- Specify non-standarized maven plugins (spring plugin, cobertura,
injection, ...)
- Add a whole bunch of "sane for them" default plugin configuration that
overwrite the defaults of the Maven plugins.
The JBoss parent pom:
https://central.sonatype.com/artifact/org.jboss/jboss-parent/39
The Spring boot starter parent pom:
https://central.sonatype.com/artifact/org.springframework.boot/spring-boot-starter-parent/3.1.1
More importantly, these groupId are not neutral territory.
Ideally, the Jboss parent and spring parent have a parent with their
common properties.
Therefore, a 3th party parent pom is not a solution.
*Proposal
*Create a standarized, neutral parent for Java 17 that can be used as such:
org.apache.maven.parents
parents-java-17
2023.06.28
(Think "FROM ...:17-jre-alpine" in a Docker file.)
Similarly, there's a org.apache.maven.parents:parents-java-11 pom.
This parent pom has:
- Plugin versions defined for only and all Maven plugins of groupId
org.apache.maven.
- A compatible set of Maven plugin versions
- The latest Maven plugin versions as of 2023.06.28 (not withstanding
the previous line)
- Java set to 17
- The minimum maven set to the latest Final maven release as of 2023.06.28
*GroupId, ArtifactId and Versioning
*The groupId, artifactId and versioning are open for debate:
Proposal A: org.apache.maven.parents:parents-java-17:2023.06.28
The artifactId contains the Java number.
The version contains the release-cut-off date, so it's easy to see how
old it is.
Proposal B: org.apache.maven.parents:parents-java:17.2023.06.28
The version starts with the Java number.
The version contains the release-cut-off date, so it's easy to see how
old it is.
Proposal C: org.apache.maven.parents:parents-java-17:1.0.0
The artifactId contains the Java number.
Every release increases the major version number.
This is Apache version guidelines compatible.
Proposal D: org.apache.maven.parents:parents-java:17.1.0
The major version number is the Java number.
Every release increases the minor version number.
This is Apache version guidelines compatible.
(More proposals welcome.)
What do you think?
--
With kind regards,
Geoffrey De Smet
5 maven dependency puzzlers - How can maven prevent these unwelcome surprises?
Hi, Video with 5 Maven dependency puzzlers - can you answer all 5 correctly? :) http://parleys.com/play/5148922b0364bc17fc56ca05 (they just made the video free) *How can maven prevent these unwelcome surprises?* Watch the video first for context. Here are some proposals (some of which might be worked on already). Question 1: Different groupId Support metadata in the repository to state that - the groupId org.javassist conflicts with the groupId javassist - the groupId:artifactId org.drools.planner:drools-planner-core conflicts with org.optaplanner:optaplanner-core - the artifactId foo-beforeSplit conflicts with foo-afterSplit-part1 and foo-afterSplit-part2 - the fat jar artifactId weld-se conflicts with the jar weld-se-core (which contents it duplicates) Note: the currently solution "a relocation file" has 2 issues (IIRC): - works only 1 way (IIRC) - needs to be created for every version (IIRC) Question 3: Conflict nephews and Question 4: Conflicting cousins Support pluggable conflict resolution. Out-of-the-box, make it easy to switch from "nearest" (default due to backwards compatibility) to "lexicographic highest version" Question 5: Child with dependencyManagement That's a bug. With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: DepMgt is useless because not transitive
On 19-05-13 17:18, Jason van Zyl wrote: I can show you visually whats happening and it's not so much a bug (which I think I explained to you when you showed me the slides initially) but the current design. I'd like to propose to review the current design. Here are some idea's for an improved design: A) Make dependencyManagement transitive: Apply the inherited dependencyManagement on yourproject before processing it in myproject. Or simply put: the dependency graph that yourproject compiles and build with, is the same dependency subgraph that myproject incorporates due to depending on yourproject. B) Transitive dependencies overrides should be declared within the element of the dependency, just like . For example: ... a jbpm-flow 5.3.0.Final If a is upgraded and a no longer depends on jbpm, this gives an error. If a is upgraded and the new version of a requires a higher jbpm-flow, then the guy upgrading a would notice that we explicitly overwrote the jbpm-flow in the past, so there's at least a chance he upgrades jbpm-flow too (and doesn't run into NoSuchMethodError (*)). Declaring a "normal" dependency just to override transitive dependency (regardless if it's in dependencyManagement or not) is in practice a maintenance nightmare, but it's the only option that's available now. B) would fix that. C) Pluggable conflict resolution Out-of-the-box, we should have: 1) "the nearest" (which is part of the reason that the version of direct dependencies win). 2) "the highest version (according to lexicographic version number comparison)". Any sane project will want to use 2): When "the nearest" rule decides to use the lowest version of 2 versions, it's asking for a NoSuchMethodError (*). (*) If you're lucky, in your test coverage. If you're unlucky, in production. Compilation doesn't see it because dependencies are not recompiled. HTH :) On May 19, 2013, at 11:05 AM, Jason van Zyl wrote: You have the POMs handy you made the slides from? On May 17, 2013, at 11:42 AM, Geoffrey De Smet wrote: I've always believed this is a bug, not a feature. I am still hoping to convince Jason etc of that. I talked about this last year already at Devoxx 2012 in my session "Maven dependency puzzlers". I had several reactions that "this must be a bug". Just look at 3 slides, and tell me maven 3.0.4 does the sane thing: The setup (click right to go the next slide) http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#34.0 How maven 3.0.4 resolved it: http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#35.0 And what this means for users: http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#36.0 Look at that last slide and tell me this is not a bug. wkr, Geoffrey On 09-04-13 13:38, Arnaud Héritier wrote: Yes when I analyzed the behavior, seeing it was here for long long time I understood that it was probably done by design. I had a look at our doc ( http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management) and we should probably detail more this behavior which is local to the currently built project (At least to be sure to be able to say RTFM). I'm not the only one to have supposed the wrong behavior which in users mind is more a bug than a feature On Tue, Apr 9, 2013 at 12:59 PM, Jason van Zyl wrote: This is how is was designed to work. Aether can do anything but the original implementation is simply a map of GAs with a version preference. If the GA is encountered then its version is overridden. This effectively gives you a target platform like mechanism but is intended to be controlled from the final application. Maven does not consider depMan at every level in the tree. It's a global map controlled from your project and its functionality is very limited in scope. You would need to do some relatively sophisticated conflict resolution to have every sub graph and its managed dependencies be reconciled with every other. Not that it can not be done but this certainly not how dependency management is implemented currently. This is not a bug, this is how the feature is implemented. On 2013-04-08, at 8:28 AM, Arnaud Héritier wrote: Hi all (and especially Herve, Jason and those who are working on Aether), We are several to hit what we consider to be a bug but myself I don't understand how we did to not see it before. To be short the problem resides in depMgt usage. It is useful only in the project you are building to enforce/lock some versions. If this is in a transitive path of a dep it is unused. For example here
Re: DepMgt is useless because not transitive
On 19-05-13 17:05, Jason van Zyl wrote: You have the POMs handy you made the slides from? Yes :) Each puzzler in my presentation was tested out with this source code: https://github.com/ge0ffrey/maven-dependency-puzzlers That particular problem is in here: https://github.com/ge0ffrey/maven-dependency-puzzlers/tree/master/child-with-dependencyManagement Ignore the "fix" directory, which is a way to fix the bug by using boms (which didn't work, but I've haven't tried decently yet). The other dirs are modules as shown in the slides. On May 17, 2013, at 11:42 AM, Geoffrey De Smet wrote: I've always believed this is a bug, not a feature. I am still hoping to convince Jason etc of that. I talked about this last year already at Devoxx 2012 in my session "Maven dependency puzzlers". I had several reactions that "this must be a bug". Just look at 3 slides, and tell me maven 3.0.4 does the sane thing: The setup (click right to go the next slide) http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#34.0 How maven 3.0.4 resolved it: http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#35.0 And what this means for users: http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#36.0 Look at that last slide and tell me this is not a bug. wkr, Geoffrey On 09-04-13 13:38, Arnaud Héritier wrote: Yes when I analyzed the behavior, seeing it was here for long long time I understood that it was probably done by design. I had a look at our doc ( http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management) and we should probably detail more this behavior which is local to the currently built project (At least to be sure to be able to say RTFM). I'm not the only one to have supposed the wrong behavior which in users mind is more a bug than a feature On Tue, Apr 9, 2013 at 12:59 PM, Jason van Zyl wrote: This is how is was designed to work. Aether can do anything but the original implementation is simply a map of GAs with a version preference. If the GA is encountered then its version is overridden. This effectively gives you a target platform like mechanism but is intended to be controlled from the final application. Maven does not consider depMan at every level in the tree. It's a global map controlled from your project and its functionality is very limited in scope. You would need to do some relatively sophisticated conflict resolution to have every sub graph and its managed dependencies be reconciled with every other. Not that it can not be done but this certainly not how dependency management is implemented currently. This is not a bug, this is how the feature is implemented. On 2013-04-08, at 8:28 AM, Arnaud Héritier wrote: Hi all (and especially Herve, Jason and those who are working on Aether), We are several to hit what we consider to be a bug but myself I don't understand how we did to not see it before. To be short the problem resides in depMgt usage. It is useful only in the project you are building to enforce/lock some versions. If this is in a transitive path of a dep it is unused. For example here is a sample : http://parleys.com/#play/515ef261e4b0cb5a00d98074/chapter34/about The code to test : https://github.com/ndeloof/maven-puzzler/tree/master/3 As far as we don't define the version in the depMgt of the project itself Maven will use the one from dependencies and won't take care of any other depMgt in the transitive path Vincent Massol also reproduced it at code level here : http://jira.codehaus.org/browse/MNG-5462 If someone could have a look at this issue please. -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - 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 Thanks, Jason -- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: DepMgt is useless because not transitive
I've always believed this is a bug, not a feature. I am still hoping to convince Jason etc of that. I talked about this last year already at Devoxx 2012 in my session "Maven dependency puzzlers". I had several reactions that "this must be a bug". Just look at 3 slides, and tell me maven 3.0.4 does the sane thing: The setup (click right to go the next slide) http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#34.0 How maven 3.0.4 resolved it: http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#35.0 And what this means for users: http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#36.0 Look at that last slide and tell me this is not a bug. wkr, Geoffrey On 09-04-13 13:38, Arnaud Héritier wrote: Yes when I analyzed the behavior, seeing it was here for long long time I understood that it was probably done by design. I had a look at our doc ( http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management) and we should probably detail more this behavior which is local to the currently built project (At least to be sure to be able to say RTFM). I'm not the only one to have supposed the wrong behavior which in users mind is more a bug than a feature On Tue, Apr 9, 2013 at 12:59 PM, Jason van Zyl wrote: This is how is was designed to work. Aether can do anything but the original implementation is simply a map of GAs with a version preference. If the GA is encountered then its version is overridden. This effectively gives you a target platform like mechanism but is intended to be controlled from the final application. Maven does not consider depMan at every level in the tree. It's a global map controlled from your project and its functionality is very limited in scope. You would need to do some relatively sophisticated conflict resolution to have every sub graph and its managed dependencies be reconciled with every other. Not that it can not be done but this certainly not how dependency management is implemented currently. This is not a bug, this is how the feature is implemented. On 2013-04-08, at 8:28 AM, Arnaud Héritier wrote: Hi all (and especially Herve, Jason and those who are working on Aether), We are several to hit what we consider to be a bug but myself I don't understand how we did to not see it before. To be short the problem resides in depMgt usage. It is useful only in the project you are building to enforce/lock some versions. If this is in a transitive path of a dep it is unused. For example here is a sample : http://parleys.com/#play/515ef261e4b0cb5a00d98074/chapter34/about The code to test : https://github.com/ndeloof/maven-puzzler/tree/master/3 As far as we don't define the version in the depMgt of the project itself Maven will use the one from dependencies and won't take care of any other depMgt in the transitive path Vincent Massol also reproduced it at code level here : http://jira.codehaus.org/browse/MNG-5462 If someone could have a look at this issue please. -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - 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: Plugin to Increment Project Version
I believe the versions-maven-plugin is the closest what you need, but it will not "increment the hotfix part of the version by one" correctly if you are working on a release branch (for example 1.2.x) and a higher release has been made (for example 1.3.0). More info here: https://jira.codehaus.org/browse/MVERSIONS-185 Op 21-03-12 20:03, Brett Porter schreef: You can use this plugin for a wide range of version changes: http://mojo.codehaus.org/versions-maven-plugin/ For automatic incrementing, you might look at the release plugin: http://maven.apache.org/plugins/maven-release-plugin/ If neither of those do what you want, then it would probably be easier to make an enhancement to them rather than creating a new plugin. Rewriting the POM is not a tool we have generally available - both plugins have gone to some lengths to do that while preserving formatting, etc. - Brett On 22/03/2012, at 4:23 AM, Daniel Jones wrote: Hi all, I'm wondering if it would be possible/feasible to write a plugin that: 1. Looks up the LATEST version of the current project 2. Does some splitting on that version string to increment the minor revision by one 3. Modifies the logical representation of the POM to the new version 4. *Possibly* does some filtering that will then write the POM.xml file with the new version. I'm guessing items 1 and 3 must exist in the codebase somewhere, so the rest shouldn't be too hard. Has anyone attempted this before, and if not, where would you recommend a developer completely new to Maven plug-ins should look first? -- Regards, Daniel Jones | Software Engineer, Platform Team Mendeley Ltd | London, UK | www.mendeley.com<http://www.mendeley.com/> Registered in England and Wales | Company Number 6419015 -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: '+1' vs 'I agree'
For me the difference between +1 "I agree" and +0 "I don't care" is relevant. Especially if you're fixing a problem, but your solution isn't 100% perfect, it's interesting to know if people are daily annoyed by this problem or don't care. If you see many +1's, there might be even just cause to ignore a single -1 :) Op 26-01-11 16:23, Paul Gier schreef: I would even go further and say that if it's not a vote, a +1 or "I agree" by themselves don't really add to the conversation. In general, no response means either "I agree" or "I don't care enough to respond, so do what you want". If a proposal or discussion item is put forward, it's normally safe to assume that unless someone speaks up, people are ok with it. So at a minimum for non-vote items, I would prefer "I agree because...", or "I disagree because...". On 01/26/2011 05:44 AM, Lukas Theussl wrote: This may seem like a peanut issue compared to other things we have to discuss these days, but since so many things are coming up, I thought I toss it in and maybe it will get overlooked... It bugs me that every time I see a +1 in a normal conversation I find myself crawling back up the mail thread to check if I missed a vote call somewhere. I suspect it is common usus in apache land or maybe just an established habit, but I think it's a bad habit and potentially confusing as it's often not clear what the +1 refers to. Isn't it reasonable to expect that people use proper language like a simple 'Yes' or 'I agree' if they just want to express their support for a point or statement, and to reserve numerical expressions for formal vote threads? thanks, -Lukas (*sigh*, glad I got that off my chest...) ----- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Typo on http://maven.apache.org/general.html ?
The javadoc you specified clearly state though, that skipTests is recommended because maven.test.skip doesn't compile the testcases :) IMHO the FAQ should follow the recommended guidelines, so shouldn't it use skipTests instead of maven.test.skip? With kind regards, Geoffrey De Smet Olivier Lamy schreef: Hi, Both are supported but it's not the same effect :-) Read here : http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#skip . -- Olivier 2009/7/27 Geoffrey De Smet : The offical FAQ on http://maven.apache.org/general.html Still mentions this text: How do I skip the tests? Add the parameter -Dmaven.test.skip=true in the command line Hasn't that been changed to "-DskipTests"? -- With kind regards, Geoffrey De Smet - 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
Typo on http://maven.apache.org/general.html ?
The offical FAQ on http://maven.apache.org/general.html Still mentions this text: How do I skip the tests? Add the parameter -Dmaven.test.skip=true in the command line Hasn't that been changed to "-DskipTests"? -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Pre-Vote] release maven 2.0.9
The reporting section ignores pluginManagement, which is said to be a feature, but IMHO it violates the principle of least suprise and it's a bug. With kind regards, Geoffrey De Smet Jörg Schaible schreef: [EMAIL PROTECTED] wrote: nicolas, I won't speak for Brian, but I thought his intention was to lock down plug-ins that only affect the build cycle. Shouldn't the generated reports of a release also be reproducable? However, anone noticed that a plugin with a locked version in the pluginManagement is not locked if used without version in the report section? Bug or feature? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.8 Release
Thanks, One issue though: http://maven.apache.org/ notes: Get Maven 2.0.8 Released: 20 June 2007 That release date might be a bit off :) With kind regards, Geoffrey De Smet Brian Fox schreef: The Apache Maven team would like to announce the availability of Maven 2.0.8. We closed out 32 issues and no major issues upgrading are expected. There is one slight change to be aware of, the test-classes folder is now before the classes in the classpath to allow test resources to override runtime for testing purposes (http://jira.codehaus.org/browse/MNG-3118) You can find the binaries here: http://maven.apache.org/download.html You can find the release notes here: http://maven.apache.org/release-notes.html You can find the roadmap here: http://jira.codehaus.org/browse/MNG?report=com.atlassian.jira.plugin.system.project:roadmap-panel Thanks, The Apache Maven Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
[A] All plugin versions must be specified by the project or its parent hierarchy somewhere, at the cost of some verbosity (though we should look at ways to make this easier/smaller/etc per the current discussion) With kind regards, Geoffrey De Smet Brett Porter schreef: I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) All plugin versions must be specified by the project or its parent hierarchy somewhere, at the cost of some verbosity (though we should look at ways to make this easier/smaller/etc per the current discussion) [ ] (B) Retain the current behaviour, but make using the enforcer a best practice to do the above, or some other control mechanism such as having the repository manager handle the available plugins [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
Has anyone thought about "enforcing" the compiler-plugin source and target version also to be locked down? The default is also causing much grief. "mvn enforcer:make-maven-stable" could then call "mvn enforcer:lock-plugins enforcer:lock-compiler" With kind regards, Geoffrey De Smet Andrew Williams schreef: Oops, I just wrote something similar in the other vote thread. Agree entirely, but the enforcer is not the right place for it, perhaps a plugin-manager plugin or such. Andy On 2 Sep 2007, at 19:33, Arik Kfir wrote: Hi, As a heavy Maven **user**, what would be best for us is having some plugin (could be the enforcer, or another) automatically generate this configuration for us into the POM. Something along the lines of: mvn enforcer:lock-plugins This command will find the most appropriate version of relevant plugins and modify my POM(s) to explicitly specify them. Later on, I can either manually modify my POM when I want to upgrade a plugin, or run another command, e.g: mvn enforcer:update-all-plugins or: mvn enforcer:update-plugin -DgroupId=org.apache.maven.plugins-DartifactId=maven-jar-plugin -Dversion=latest/2.9.9.9 Current behavior should remain, if only not to upset the many non-enterprise users which use Maven more "lightly". HTH, Arik. On 9/2/07, Dan Tran <[EMAIL PROTECTED]> wrote: B Totally agree with Wayne here. -D On 9/2/07, Wayne Fay <[EMAIL PROTECTED]> wrote: [X] (B) Retain the current behaviour, but make using the enforcer a best practice to do the above, or some other control mechanism such as having the repository manager handle the available plugins I am thinking about the new user experience and winning more converts. As such, I think the current behavior is best. Once they get using Maven more seriously (and in corporate environments that know what they're doing), I think adding the Enforcer configuration and locking versions down will come naturally. But *requiring* it seems excessive -- unless we're doing that ourselves somewhere, with plugin packs or similar, then I feel better about it. Wayne - 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]
Re: [VOTE] Configure IDE plugins to download sources by default within Maven projects
Downloading the non-available sources should not be slow: Just cache in the repository (not in target which get cleaned) if the sources of an _available_ jar are available or not. Then lay down an extra repository law: "Do not deploy sources on a later date after the pom has been deployed" to me this sounds pretty much consistent like "do not change the pom after it has been deployed" PS: sources should be deployed by default with "mvn deploy", that's fixed in 2.1 IRC? With kind regards, Geoffrey De Smet Mark Hobson schreef: Okay, bit of a mixed bag for this vote: +1 javadoc: Brett, Dennis, Brian, Christian, Rahul -1 javadoc: Jochen, Stephane, Reinhard +1 sources: Mark, Dennis, Brian, Christian -1 sources: Brett, Jochen, Stephane, Reinhard, Rahul It seems there's a few prerequisites to this being widely accepted: - MECLIPSE-292: eclipse IT tests are sensitive to current users's settings.xml - MECLIPSE-292: Behaviour for sources and Javadoc attachement for dependencies should be consistent - Making the Idea plugin cache missing javadoc/source jars as per the Eclipse plugin Is anyone aware of an issue for the latter? If not, I'll raise one. We could raise an issue to revisit this that depends on the above issues. Cheers, Mark On 04/07/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Cabasson Denis wrote on Tuesday, July 03, 2007 4:57 PM: > About this link, why couldn't we have a consistent behaviour > for javadoc and sources jar? [snip] Because here it becomes IDE dependent. Eclipse displays Javadoc automatically if the sources are available. No need to download Javadocs separatly. However, I don't know how IDEA or NetBeans works, but it is clear that you are not able to unify the bahaviour from the Maven side. - Jörg - 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: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1 -> lock down of plugin versions
"they need to specify versions for all of their plugins in the POM" We can't do this in 2.0.x but it needs to be mandatory in 2.1. Good! :) In my experience with spring-richclient most of the problems of an instable build went away the day I locked down all versions. However you could do 2 things to make our lives easier: 1) Bundle a bunch of plugins together in a version so we can just specify that bundle. Say for example "we use plugin-bundle 2.0.6" (which means we use assembly 2.0, site 2.0-beta5, ...). Of course it should be possible to make an exception on a single plugin in that bundle to give it another version anyway. Plugin-bundles would allow you to test more thoroughly if all plugins work together nicely. 2) A site report (and maybe also a mvn cmd) to receive a list of all plugins which can be updated. (This would be very welcome for dependencies too btw.) With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[assembly 2.2-SNAPSHOT] self artifact not included anymore (regression?)
Using the latest assembly plugin from
http://people.apache.org/repo/m2-snapshot-repository/
I have 2 modules:
- myLib with packaging jar
- myApp with packaging jar
I also have an assembly configuration on myApp,
hooked into the package phase, which contains this:
${artifactId}-${baseVersion}.${extension}
/lib
runtime
When I run this, I get:
x/lib/myLib-x.jar
But the self artifact isn't there:
x/lib/myJar-x.jar
In assembly 2.1 that self artifact is there.
Is this a regression or an intentional change?
And how do I get it there (with a file with finalName hack I suppose?)?
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.5 - open bugs?
Is there any new info on the state of the m2.0.5 release? With kind regards, Geoffrey De Smet Brett Porter schreef: Can you try the build extension one with the latest snapshot from the branch? I think I already fixed it. - Brett On 26/01/2007, at 8:03 PM, Fabrice Bellingard wrote: Yes, I should have done that sooner. Here are the issues: - http://jira.codehaus.org/browse/MNG-2794 - http://jira.codehaus.org/browse/MNG-2795 Feel free to contact me if you have any questions. Fabrice. On 1/26/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: On 25 Jan 07, at 3:38 PM 25 Jan 07, Fabrice Bellingard wrote: > Jason, > > what about the issues I had when testing version 2.0.5, and for > which I sent > you a project that reproduces one of the bug? (transitive dependency > resolution problem and checkstyle plugin failure). Did you identify > them as > "real" issues and postponed them to 2.0.6? Or maybe found they > weren't real > problems? > Did you assign the issue to 2.0.5 in JIRA. I can't keep track of requests in mail. I'm going to roll a stage of 2.0.5 again tomorrow so push it into 2.0.5. JIRA is my memory. Jason. > Fabrice. > > On 1/25/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: >> >> There is one issue which Trygve raised which I thought he assigned to >> 2.0.5. >> >> It is the issue where Maven is trying to continually try to find >> snapshots instead of only checking daily. >> >> I am done with my crunch at a client this week so I'll call the vote >> tomorrow afternoon. >> >> Jason. >> >> On 25 Jan 07, at 4:36 AM 25 Jan 07, Federico Yankelevich wrote: >> >> > >> > Hi, >> > few days ago there was a lot of interest in a thread calling a vote >> > for >> > releasing maven 2.0.5 >> > (http://www.nabble.com/-VOTE--Release-Maven-2.0.5- >> > tf2966962s177.html) ... >> > most of the vote were +1 and I thought it was going to be released >> > soon. >> > Also in JIRA >> > (http://jira.codehaus.org/secure/IssueNavigator.jspa? >> > reset=true&pid=10500&fixfor=12294) >> > I don't see any open issue for Maven 2.0.5. >> > >> > What are you waiting to release maven 2.0.5?, have you found a >> > critical bug >> > that need to be fixed before release? if any, can you, please, list >> > the open >> > bugs in JIRA? >> > >> > Keep on doing the great work, >> > thanks, >> > Federico >> > -- >> > View this message in context: http://www.nabble.com/Maven-2.0.5--- >> > open-bugs--tf3100600s177.html#a8605883 >> > 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] >> >> - 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: cmd line property is ignored - bug? (and which jira component to file in?)
maven.test.skip=true doesn't work either
http://jira.codehaus.org/browse/MNG-2206
could be the issue, but it's rather vague.
With kind regards,
Geoffrey De Smet
Kenney Westerhof schreef:
Geoffrey De Smet wrote:
[based on the almost latest m2.0.5 branch]
I have this profile in my pom.xml:
development
true
true
${no.daisy.test}
So without my settings.xml "mvn install" doesn't run the tests.
But in my settings.xml I have a profile like this:
daisy_1_5
false
...
So now "mvn install" does run the tests.
However when I now try
mvn -Dmaven.test.skip install
Try -Dmaven.test.skip=true.
If that fails, then you hit a known bug (search jira).
-- Kenney
The tests are still run,
while I expected my cmd line variable to overwrite my pom.xml and
setting.xml properties.
Is this a known bug? or shall I file a jira (and in which component)?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cmd line property is ignored - bug? (and which jira component to file in?)
[based on the almost latest m2.0.5 branch]
I have this profile in my pom.xml:
development
true
true
${no.daisy.test}
So without my settings.xml "mvn install" doesn't run the tests.
But in my settings.xml I have a profile like this:
daisy_1_5
false
...
So now "mvn install" does run the tests.
However when I now try
mvn -Dmaven.test.skip install
The tests are still run,
while I expected my cmd line variable to overwrite my pom.xml and
setting.xml properties.
Is this a known bug? or shall I file a jira (and in which component)?
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5
+1: no problems here -- With kind regards, Geoffrey De Smet Jason van Zyl schreef: Hi, The entire release is staged here: http://people.apache.org/~jvanzyl/maven-2.0.5/ The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC That's about it. Play around with it, if there are things wrong and I'll fix stuff. We haven't released in so long there very well may be some problems. We should probably let it sit until Tuesday as most folks won't try it out over the weekend. +1 Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
timeframe 2.0.5 (use 2.0.5 in )
Maven 2.0.4 was released 2006-04-10 (according to JIRA), 9 months ago. We've been using a 2.0.5-SNAPSHOT for a while now, because of the bug (MNG-1797) and for us it seems stable. Sometimes it looks like many users are using the SNAPSHOT actually. According to jira 11 issues remain: http://jira.codehaus.org/browse/MNG?report=com.atlassian.jira.plugin.system.project:roadmap-panel I 'd like to introduce in our pom to enforce maven 2.0.5, so I was wondering if there is any timeframe for 2.0.5? :) Thanks a great product. -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
User vote (non-binding, on first sight): +1 for an RPM (because as a non-maven-developer I like it that there can only be one maven version installed). I am tired of telling people how to install maven and setting their JAVA_HOME etc. +1 for writing/stabilizing an RPM plugin that builds maven2's RPM (and also RPM's for my maven2ized projects :) -1 for maintaining the RPM's in a separate project instead of a cleanly configured RPM-plugin on the maven build -1 for factoring the maven2 directory - unless system links can solve this problem. -- With kind regards, Geoffrey De Smet Stephane Nicoll wrote, On 2006-12-07 9:12 AM: On 12/7/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Define nice? If it's an installation that is different then something standard that users typically get then it is a not a good thing. I can just see the threads now: "I put my global stuff in the /etc/maven/settings.xml and blah blah blah" "In /etc/maven/settings, mine is in $MAVEN_HOME/conf/settings.xml" "I don't have a $MAVEN_HOME/conf" "What version are you using?" "I'm just using what came with Redhat/BSD/Solaris" So instead of having our standard platform neutral single directory structure, we have each distro doing whatever they want. If it was a package that dropped stuff into the standard way we are doing things great. If not then I'm am so strongly -1 to any such work I can't be emphatic enough. It will fracture out user base completely. I frankly don't care about distros, I care about our users and their experience and their ability to communicate with other users regardless of what platform they are on. Having different setups because Redhat/Solaris/ BSD feel like doing things different is not a good thing. I am +1 on this one and I think it would really break the standardization that Maven uses but on the other hand, those RPMs have always done this for every product (anyone using jpackage?) The next step I see is rpm foo needs maven for some reasons and users *have* to install it the with the RPM. This would really be the mess. That said, I guess they know what they are doing and they certainly know better users' needs than us. Cheers, Stéphane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sync spring-richclient repo
Sorry, I hadn't read that part yet (it's new in the last couple of months I believe). I don't know if we're allowed to run such a script on the SF server and if it would be possible to deploy to the spring repository instead. I 'll make an issue for myself. Carlos Sanchez wrote, On 2006-11-07 5:19 PM: Take a look at the end of http://maven.apache.org/guides/mini/guide-ibiblio-upload.html We use rsync over ssh. On 11/7/06, Geoffrey De Smet <[EMAIL PROTECTED]> wrote: Carlos, When spring-richclient released 0.2.1 I tried to make an upload bundle, but there's an issue for that for multiprojects. So I was wondering if you can't just sync our repo? :) http://spring-rich-c.sourceforge.net/maven2repository/org/springframework/richclient/ -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sync spring-richclient repo
Carlos, When spring-richclient released 0.2.1 I tried to make an upload bundle, but there's an issue for that for multiprojects. So I was wondering if you can't just sync our repo? :) http://spring-rich-c.sourceforge.net/maven2repository/org/springframework/richclient/ -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing javadoc plugin
+1 because the aggregate issue will be released: http://jira.codehaus.org/browse/MJAVADOC-72 At spring-richclient we're waiting on a release which contains that, and I believe Wendy of Struts is also waiting for it. Carlos Sanchez wrote, On 2006-10-03 11:08 AM: There has been a lot of changes in the javadoc plugin, and last release was in march. Can we go for a new one? This is a question mostly for Vincent Siveton, which has done a lot of work in the plugin. -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
(user votes) +1 Starting with Continuum/MRM as it might trigger some issues which yield experience before doing Maven +1 On FAQ documentation on how to run maven in JDK 1.5 but compile with JDK 1.3/1.4 API's (not just -source). I would really like the ability to write tiger annotated maven plugins... but as I understand that the minimum JDK for plugins is the same as the minimum JDK for maven itself. That's probably a good thing, so: +1 for maven, in a few months. For NetBeans: would it be possible to say "Netbeans works on 1.4 but the netbeans maven plugin only works if you are using JDK 1.5"? To compare: "Acegi works on 1.4 but the acegi-tiger module only works if you are using JDK 1.5". Brett Porter wrote: Hi, I wanted to get thoughts on starting to require a Java 5 JVM to run stuff we build. We currently restrict to 1.4 across the board. Here's what I'm thinking: - MRM and Continuum should switch now. Stuff built there is rarely consumed elsewhere, and a Java 5 requirement outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bug?] 2 repo's, one repo returns 503, second repo is not check
Thanks :) Ignore my mail Kenney Westerhof wrote: On Thu, 6 Jul 2006, Geoffrey De Smet wrote: Hi Geoffrey, This issue is already fixed: http://jira.codehaus.org/browse/MNG-2282 -- Kenney I looked in JIRA, but couldn't find this bug. But I am not sure in which module it should belong, I presume "wagon"? If it's a not already reported bug, say so and I 'll file it in JIRA. Basically I have 2 repo's: - repo.domain.com (an internal one which is currently spitting out 502's error codes because it's broken) - repo1.maven.org (the default central) When I do "mvn install" it tells me that it can't find xstream 1.1.3 in neither repo's, while it's actually in repo1.maven.org. It shouldn't matter that repo.domain.com is currently broken. Here's the "mvn -X install": [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: xstream:xstream Reason: Error getting POM for 'xstream:xstream' from the repository: Error transferring file xstream:xstream:pom:1.1.3 from the specified remote repositories: central (http://repo1.maven.org/maven2), kahoslRepository (http://repo.domain.com/vakgroepit/maven2repository) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Unable to get dependency information: Unable to read the metadat a file for artifact 'xstream:xstream:jar': Error getting POM for 'xstream:xstream' from the repository: Error transferri ng file xstream:xstream:pom:1.1.3 from the specified remote repositories: central (http://repo1.maven.org/maven2), kahoslRepository (http://repo.domain.com/vakgroepit/maven2repository) xstream:xstream:jar:1.1.3 from the specified remote repositories: central (http://repo1.maven.org/maven2), kahoslRepository (http://repo.domain.com/vakgroepit/maven2repository) Path to dependency: 1) be.kahosl.thot:thot-persistenceimpl:jar:0.0.1-SNAPSHOT at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 5) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get dependency information: Unable to read the metadata file for artifact 'xstream:xstream:jar': Error getting POM for 'xstream:xstream' from the repositor y: Error transferring file xstream:xstream:pom:1.1.3 from the specified remote repositories: central (http://repo1.maven.org/maven2), kahoslRepository (http://repo.domain.com/vakgroepit/maven2repository) xstream:xstream:jar:1.1.3 from the specified remote repositories: central (http://repo1.maven.org/maven2), kahoslRepository (http://repo.domain.com/vakgroepit/maven2repository) Path to dependency: 1) be.kahosl.thot:thot-persistenceimpl:jar:0.0.1-SNAPSHOT at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:297) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:2 23) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resol
[Bug?] 2 repo's, one repo returns 503, second repo is not check
ava:1 82) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable to read the metadata file for a rtifact 'xstream:xstream:jar': Error getting POM for 'xstream:xstream' from the repository: Error transferring file xstream:xstream:pom:1.1.3 from the specified remote repositories: central (http://repo1.maven.org/maven2), kahoslRepository (http://repo.domain.com/vakgroepit/maven2repository) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:131) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:275) ... 23 more Caused by: org.apache.maven.project.ProjectBuildingException: Error getting POM for 'xstream:xstream' from the repositor y: Error transferring file xstream:xstream:pom:1.1.3 from the specified remote repositories: central (http://repo1.maven.org/maven2), kahoslRepository (http://repo.domain.com/vakgroepit/maven2repository) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:5 01) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) ... 24 more Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: Error transferring file xstream:xstream:pom:1.1.3 from the specified remote repositories: central (http://repo1.maven.org/maven2), kahoslRepository (http://repo.domain.com/vakgroepit/maven2repository) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:140) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:4 67) ... 26 more Caused by: org.apache.maven.wagon.TransferFailedException: Error transferring file at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:99) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:369) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:282) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:244) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:124) ... 28 more Caused by: java.io.IOException: Server returned HTTP response code: 502 for URL: http://repo.domain.com/vakgroepit/mav en2repository/xstream/xstream/1.1.3/xstream-1.1.3.pom at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1149) at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:85) ... 33 more -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] This Maven thing is killing us....
Brett Porter wrote:
Hi Ralph,
There are a couple of options for addressing this use case in Maven.
- include the JARs in SVN, and reference it as an additional repository
file://localhost/${basedir}/extra-jar-repo
When you declare such a repository in your parent pom, the child poms
don't use the parent's basedir, but their own basedir. Is there a
workaround for that problem?
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Documenting Maven
Humans aren't capable to read more then 9 entries. Many of the questions asked on the user list are actually in the guides. So why don't they find it? http://maven.apache.org/guides/index.html links to a lot of good guides, but the way it is structured is plain wrong imho: - When people want to learn something about for example site deployment and they get the choice from "Mini Guides", "Introductory Material", "Reference", ... they don't know what to choose. - When the pick "Mini Guides" they have to read 20+ entries, so 11+ to many. A refactor of that page, into a tree based structured on the functionality (not the format) will help a lot. The format (mini guide or introdcutory material) can be mentioned next to the entry. Brett Porter wrote: John Casey wrote: Hi everyone, I know we've talked about this quite a bit already. Actually, I'm having trouble finding the past threads on this topic in my email...can someone who knows please link them in? btw: http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] However, I'm reading through them and going to reincoporate any additional thoughts into the current discussions (as I should have done *ages* ago). - Brett -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: doxia-renderer alpha 8 not on mergere repo
Brett, My apologies, I must look first indeed and tell you about the real problem, instead of start geussing. It's just I had it today and yesterday on my work computer, saw users complaining on the user list and also got a mail from a couple people from spring-richclient. I cannot reproduce it on my home computer (did mvn -U site before codehaus was down). If I still have it tommorrow on my work computer, I 'll find out the cause and provide a decent report as I should have done in the first place. With kind regards, Geoffrey De Smet Brett Porter wrote: yes, it is: http://repo.mergere.com/maven2/org/apache/maven/doxia/doxia/1.0-alpha-8/ Please: a) look first b) look at the messages on the users list that indicate what the real problem was. - Brett Geoffrey De Smet wrote: Just noticed (before your answer) I talked about the wrong pom: It's doxia-1.0-alpha-8 that isn't there. Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/doxia/doxia/1.0- alpha-8/doxia-1.0-alpha-8.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:doxia-site-renderer:jar:1.0-alpha-8 Reason: Cannot find parent: org.apache.maven.doxia:doxia for project: null:doxia -site-renderer:jar:1.0-alpha-8 With kind regards, Geoffrey De Smet Brett Porter wrote: yes, it is: http://repo.mergere.com/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-8/ Geoffrey De Smet wrote: Just to double check if you guys are aware of this problem? mvn -U site = build-fails because doxia-renderer alpha 8 not on mergere repo (=stopgap for repo1.maven.org being out due to codehaus.org disk failure). If plugin versions are locked down this means every build fails. It was mentioned somewhere in the user list deep down already, but it's unclear if someone will be so kind to upload doxia-renderer alpha 8? 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: doxia-renderer alpha 8 not on mergere repo
Just noticed (before your answer) I talked about the wrong pom: It's doxia-1.0-alpha-8 that isn't there. Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/doxia/doxia/1.0- alpha-8/doxia-1.0-alpha-8.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:doxia-site-renderer:jar:1.0-alpha-8 Reason: Cannot find parent: org.apache.maven.doxia:doxia for project: null:doxia -site-renderer:jar:1.0-alpha-8 With kind regards, Geoffrey De Smet Brett Porter wrote: yes, it is: http://repo.mergere.com/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-8/ Geoffrey De Smet wrote: Just to double check if you guys are aware of this problem? mvn -U site = build-fails because doxia-renderer alpha 8 not on mergere repo (=stopgap for repo1.maven.org being out due to codehaus.org disk failure). If plugin versions are locked down this means every build fails. It was mentioned somewhere in the user list deep down already, but it's unclear if someone will be so kind to upload doxia-renderer alpha 8? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
doxia-renderer alpha 8 not on mergere repo
Just to double check if you guys are aware of this problem? mvn -U site = build-fails because doxia-renderer alpha 8 not on mergere repo (=stopgap for repo1.maven.org being out due to codehaus.org disk failure). If plugin versions are locked down this means every build fails. It was mentioned somewhere in the user list deep down already, but it's unclear if someone will be so kind to upload doxia-renderer alpha 8? Thanks. -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sun Jars Maven repository hosted by Sun is now available
Kohsuke asked on his former blog for automatic updating to Ibiblio (like codehauses etc) which would be great as new version are coming out each day. In his new blog he's speaking about maven 2. And also about m1 with GlassFish. http://weblogs.java.net/blog/kohsuke/archive/2006/05/maven_javanet_p_2.html If we can help them maven2ize glassfish and they set up a m2 repo that syncs with Ibiblio, all of Sun's jars would start appearing in Ibiblio too? Carlos Sanchez wrote: That repo is pretty messy still and has no m2 poms. I suggest everybody that if they want something from there open a upload request to move it over to ibiblio. On 5/11/06, Wayne Fay <[EMAIL PROTECTED]> wrote: Yes, its a M1 repo. This is not a big deal for M2, as you can access M1 repos from M2 using the legacy element. Wayne On 5/11/06, Brian Topping <[EMAIL PROTECTED]> wrote: > > On May 11, 2006, at 11:44 AM, Alex Karasulu wrote: > > > H this looks like a M1 repo to me. Am I mistaken? > > > > Looks like that to me too, and they are missing a fair number of jars. > > -b > > - > 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] -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nabble
Just like on gmane (newsgroups of mailing lists) there are 2 separate lists(forums on nabble): users and dev. User shouldn't ask user questions on the dev list. Brett Porter wrote: Emmanuel Venisse wrote: Why do you want to delete them? I just mean from my dev folder. users use Nabble forum functionality instead of sending directly a mail to our lists but the result is the same, all messages come in our lists. right - just the wrong list :) - Brett -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven Project Info Reports 2.0
+1 (user) Fabrizio Giustina wrote: +1 fabrizio On 5/10/06, Brett Porter <[EMAIL PROTECTED]> wrote: based on: maven-project-info-reports-plugin 2.0-beta-4-20060510.110344-4 (r405712) This also depends on a release of doxia. [ ] +1 [ ] +0 [ ] -1 -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Debugging Maven with Eclipse?
I created a "mvnd" script and there is an issue for it. After that it's just a matter of creating a remote debugger in eclipse. With kind regards, Geoffrey De Smet Jochen Kuhnle wrote: Hi, is there a guide/howto for this? Or even better, does anybody have a working .launch file? Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposed mailing lists names
FYI (so no one else does it) I 've requested those both lists on gmane.org to be separated from the dev list. With kind regards, Geoffrey De Smet Brett Porter wrote: I have some bandwidth so I'm doing this a bit earlier today. Going once, going twice - Brett Brett Porter wrote: Since we've voted to do this, I'm just going to give people 48 hours to object to these particular names. [see MPA-50] Our dev list traffic has gone nuts. Let's create: notifications@maven.apache.org * this will be for CI, error reports from the repository manager, and so on * depending on policy, this may not be archived (we won't archive it unless it's required - I don't think it's necessary, but there is no harm in it if it is) * this will be for all maven projects (ie, no continuum-notifications, etc). issues@maven.apache.org * this will be for JIRA issues. For now, just one will be created. If it is later determined to split one set off, we can create more. commits@maven.apache.org * for commits - we already have it (each subproject has its own) dev@maven.apache.org * for human discussion - we already have it Note that all subscribers to dev@maven.apache.org will be automatically subscribed to these lists at creation, but going forward you will need to subscribe to each individually. - Brett - 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: signing jar and webstart plugin
It was already there:
http://jira.codehaus.org/browse/MJAR-31
Note that my solutions are hacks as I don't have an idea of the overall
design or program flow.
Brett Porter wrote:
Can you please submit these to jira? There are already some there
(MJAR), so please check for existing ones first.
Geoffrey De Smet wrote:
For networktools.sf.net I used the webstart plugin,
which uses the jar plugin to sign jars.
I 've had a bunch of problems, most of wrong configuration on my part,
but some I believe lay in the jar plugin.
In the end I changed these few lines in the jar plugin to get it
working, even if it's a quick & dirty hack:
1) Nullpointer on org.apache.maven.plugin.jar.JarSignMojo, line 217
addArgIfNotEmpty( arguments, "-keypass", this.keypass );
+if (this.signedjar != null) {
addArgIfNotEmpty( arguments, "-signedjar",
this.signedjar.getPath() );
+}
addArgIfNotEmpty( arguments, "-storetype", this.type );
2) Nullpointer on org.apache.maven.plugin.jar.JarSignMojo, line 282
+if (project.getArtifact() != null) {
project.getArtifact().setFile( signedjar );
+}
Maybe this helps other people having the same issues.
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MJAR-31) [webstart] NPE when signing dependencies
[ http://jira.codehaus.org/browse/MJAR-31?page=comments#action_60208 ]
Geoffrey De Smet commented on MJAR-31:
--
for the record, point 2 is the following HACK:
2) Nullpointer on org.apache.maven.plugin.jar.JarSignMojo, line 282
+if (project.getArtifact() != null) {
project.getArtifact().setFile( signedjar );
+}
> [webstart] NPE when signing dependencies
>
>
> Key: MJAR-31
> URL: http://jira.codehaus.org/browse/MJAR-31
> Project: Maven 2.x Jar Plugin
> Type: Bug
> Environment: WinXP
> Maven 2.0.2
> Latest maven-jar-plugin from SVN
> Latest webstart checkout
> Reporter: Michael Böckling
> Priority: Critical
> Attachments: MOJO-295.diff
>
>
> In JarSignMojo, the call to this.signedjar.getPath() produces a NPE, because
> in JnlpMojo:863, signJar.setSignedJar() has been commented out.
> Stacktrace:
> [debug] jarsigner
> executable=[C:\Programme\Java\jdk1.5.0_06\jre\..\bin\jarsigner
> .exe]
> [INFO]
> -
> ---
> [ERROR] BUILD ERROR
> [INFO]
> -
> ---
> [INFO] Failure to run the plugin:
> [INFO]
> -
> ---
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Failure to run the
> plugi
> n:
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failure to run the
> pl
> ugin:
> at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:479)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:531)
> ... 16 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.jar.JarSignMojo.signJar(JarSignMojo.java:227)
> at
> org.apache.maven.plugin.jar.JarSignMojo.execute(JarSignMojo.java:185)
> at org.codehaus.mojo.webstart.JnlpMojo.signJars(JnlpMojo.java:865)
> at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:441)
> ... 18 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MJAR-31) [webstart] NPE when signing dependencies
[ http://jira.codehaus.org/browse/MJAR-31?page=comments#action_60207 ] Geoffrey De Smet commented on MJAR-31: -- This patch makes point 1 of http://mail-archives.apache.org/mod_mbox/maven-dev/200603.mbox/[EMAIL PROTECTED] obsolete, but not point 2, according to Tim Kettler on the mojo user list. > [webstart] NPE when signing dependencies > > > Key: MJAR-31 > URL: http://jira.codehaus.org/browse/MJAR-31 > Project: Maven 2.x Jar Plugin > Type: Bug > Environment: WinXP > Maven 2.0.2 > Latest maven-jar-plugin from SVN > Latest webstart checkout > Reporter: Michael Böckling > Priority: Critical > Attachments: MOJO-295.diff > > > In JarSignMojo, the call to this.signedjar.getPath() produces a NPE, because > in JnlpMojo:863, signJar.setSignedJar() has been commented out. > Stacktrace: > [debug] jarsigner > executable=[C:\Programme\Java\jdk1.5.0_06\jre\..\bin\jarsigner > .exe] > [INFO] > - > --- > [ERROR] BUILD ERROR > [INFO] > - > --- > [INFO] Failure to run the plugin: > [INFO] > - > --- > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failure to run the > plugi > n: > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi > fecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failure to run the > pl > ugin: > at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:479) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi > nManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:531) > ... 16 more > Caused by: java.lang.NullPointerException > at > org.apache.maven.plugin.jar.JarSignMojo.signJar(JarSignMojo.java:227) > at > org.apache.maven.plugin.jar.JarSignMojo.execute(JarSignMojo.java:185) > at org.codehaus.mojo.webstart.JnlpMojo.signJars(JnlpMojo.java:865) > at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:441) > ... 18 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
signing jar and webstart plugin
For networktools.sf.net I used the webstart plugin,
which uses the jar plugin to sign jars.
I 've had a bunch of problems, most of wrong configuration on my part,
but some I believe lay in the jar plugin.
In the end I changed these few lines in the jar plugin to get it
working, even if it's a quick & dirty hack:
1) Nullpointer on org.apache.maven.plugin.jar.JarSignMojo, line 217
addArgIfNotEmpty( arguments, "-keypass", this.keypass );
+if (this.signedjar != null) {
addArgIfNotEmpty( arguments, "-signedjar",
this.signedjar.getPath() );
+}
addArgIfNotEmpty( arguments, "-storetype", this.type );
2) Nullpointer on org.apache.maven.plugin.jar.JarSignMojo, line 282
+if (project.getArtifact() != null) {
project.getArtifact().setFile( signedjar );
+}
Maybe this helps other people having the same issues.
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Timestamp plugin
Resources could use a lot more then the current filtering:
- build timestamp
- pom information:
-- version
-- name, description, organization, ...
-- url
- svn revision
So all these things can be shown in the application and logs
The current resources filtering happens something like this now:
src/main
- resources: files
- filters: filters that change the resources files
That looks a bit dangerous to me, as its hard to predict how many files
your filters will affect. Something defaulted like this would look nice
IMHO (through configuration this is now also possible):
src/main
- resources: static resources
- filtered-resources
- filters
Being able to plug in dynamic filters (based on java classes or ant
scripts) that make the build timestamp etc, would be nice, for example:
property-file-based-filter
../myFilter.properties
ant-file-based-filter
...
...
pom-replaces-filter
${
}
Brett Porter wrote:
I'm not so sure about this. Do we really want to be swizzling resources?
So far what I've seen has been fairly limited needs - fields in the
manifest and a properties file of info for record keeping. I think a
specialised plugin (maybe even a velocity plugin) is better for this
than introducing velocity to normal resources.
- Brett
Jason van Zyl wrote:
Anders Hessellund Jensen wrote:
I would like to be able to substitute timestamps with the build time
into a resource file. As I understand it, there is currently no plugin
to to this, so I consider writing one.
Sorry for not responding to this earlier, and I know that you've started
working on this plugin and I'd like to harness the work you've done but
I think what you are doing should be an extension to the resources
plugin. We should figure out how to augment filtering of resources. I
think the easiest way to do this is to filter the resources using Velocity.
This way additional tools can be created for swizzling resources and
this can all happen in one pass through velocity instead of having N
plugins which need to make N passes over the resources to filter them.
So I don't want to discourage you at all. Work on the plugin and I will
try to integrate your code into the resources plugin when you are done.
The other advantage of using Velocity in the resources plugin will allow
you to use Velocity directives in your resources so you can do any sort
of conditional logic you may want to have instead of simple
substitution. So I think we would benefit in two ways using Velocity
here: scalable addition of tools that can be used to swizzle resources
(a timestamp tool is a perfect example) and conditional logic which can
sometimes be useful like looking at a property introduced by a profile
and behave a certain way for example.
The plugin should leverage the existing resource filtering mechanism
of M2. The plugin would take a configuration like this:
build.date
.MM.dd
Running the plugin with this configuration would define the M2
property build.date, and any filtered resource file would get
${build.date} substituted with 2006.02.28 or whatever the date at
build time is.
WDYT?
Best regards,
Anders
-
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]
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-719) New Plugin - buildinfo (buildnumber and buildclass)
[ http://jira.codehaus.org/browse/MNG-719?page=comments#action_59313 ] Geoffrey De Smet commented on MNG-719: -- It would be nice if it also includes the scm revision number (if the scm supports a revision number, like SVN, not CVS): http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/ does this (see user list topic "getting subversion revision number") > New Plugin - buildinfo (buildnumber and buildclass) > --- > > Key: MNG-719 > URL: http://jira.codehaus.org/browse/MNG-719 > Project: Maven 2 > Type: New Feature > Versions: 2.0-beta-1 > Environment: n/a > Reporter: Joakim Erdfelt > Priority: Minor > Attachments: maven-buildinfo-plugin.tar.gz > > > After discussion in #maven, it seemed that this plugin could be of use by the > general population. > It manages the buildnumber for a specific project, and even can produce an > (optional) buildclass. > example setup. > > org.apache.maven.plugins > maven-buildinfo-plugin > 1.0-alpha-1-SNAPSHOT > > .buildinfo > org.codehaus.modello.plugins.dom4j.BuildInfo > > > > > buildnumber > buildclass > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Debugging maven with breakpoints feed-back: --jdwp + docs
Brett Porter wrote: I've thought about this in the past, but have always opted to go for setting MAVEN_OPTS (which I have in a separate little script). I'd be fine with adding this argument, but parsing the command line arguments (especially in the .bat file) can be a bit of a pain. Would someone like to put it in JIRA? Done :) http://jira.codehaus.org/browse/MNG-2105 - Brett Brian E. Fox wrote: +1! -Original Message- From: Vincent Siveton [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 22, 2006 7:49 AM To: Maven Developers List Subject: Re: Debugging maven with breakpoints feed-back: --jdwp + docs Geoffrey, I like it! I prefer more --jdpa rather than --jpwd (Think about geronimo or tomcat) What do others think? Vincent 2006/2/22, Geoffrey De Smet <[EMAIL PROTECTED]>: I just used my first debug breakpoint in maven 2 to fix the jasperreports plugin: export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000" mvn Still, this is a bit unhandy and it took me quite a while to find out. So here's my 2 cents feed-back: 1) Some sort of mvn --jdwp (mvn --debug is already taken for debug logging). If it's already there, please document in "mvn --help". 2) Document how to do this with a short APT, for example in http://maven.apache.org/guides/development/guide-m2-development.html like so (APT): Debugging with breakpoints You can attach a remote debugger of your IDE to the maven process. This will allow you to set breakpoints (line, exception, ...). Start maven in debugger mode on port 8000: +-- mvn --jdwp +-- If you want to change any of the debugger settings, use MAVEN_OPTS instead. Then connect to it with a remote debugger in your IDE. -- With kind regards, Geoffrey De Smet - 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] -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2105) Enable remote debugging command line option (+ docs)
Enable remote debugging command line option (+ docs) Key: MNG-2105 URL: http://jira.codehaus.org/browse/MNG-2105 Project: Maven 2 Type: New Feature Components: Command Line Versions: 2.0.2 Reporter: Geoffrey De Smet Priority: Minor [dev list mailing reference: Debugging maven with breakpoints feed-back: --jdwp + docs] Problem: Currently its hard to enable remote debugging for a remote debugger of your IDE. Basically you need to set MAVEN_OPTS something like: export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000" mvn ... and unset it again. Solution: 1) Make it easier, choices: A) Provide a command line option to do this (--debug is already taken for debug logging), choices: a) mvn --jdpa b) mvn --jdwp B) Provide a different script: mvnDebug to avoid parsing command line arguments in bat and shell C) Find a generic way to give options on the command, like -mx etc to the java process, possibly by namespacing them? 2) Document it in mvn --help 3) Document it on http://maven.apache.org/guides/development/guide-m2-development.html like so (APT): Debugging with breakpoints You can attach a remote debugger of your IDE to the maven process. This will allow you to set breakpoints (line, exception, ...). Start maven in debugger mode on port 8000: +-- mvn ??? install +-- If you want to change any of the debugger settings, use MAVEN_OPTS instead. Then connect to the correct port with a remote debugger in your IDE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Debugging maven with breakpoints feed-back: --jdwp + docs
I just used my first debug breakpoint in maven 2 to fix the jasperreports plugin: export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000" mvn Still, this is a bit unhandy and it took me quite a while to find out. So here's my 2 cents feed-back: 1) Some sort of mvn --jdwp (mvn --debug is already taken for debug logging). If it's already there, please document in "mvn --help". 2) Document how to do this with a short APT, for example in http://maven.apache.org/guides/development/guide-m2-development.html like so (APT): Debugging with breakpoints You can attach a remote debugger of your IDE to the maven process. This will allow you to set breakpoints (line, exception, ...). Start maven in debugger mode on port 8000: +-- mvn --jdwp +-- If you want to change any of the debugger settings, use MAVEN_OPTS instead. Then connect to it with a remote debugger in your IDE. -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sending JIRA mail to commits@maven.apache.org
+1 (if I am allowed to vote :) To avoid having a full inbox, I use gmane.org: It turns mailing lists into newsgroups. So actually with this email, I am using the newsgroup gmane.comp.jakarta.turbine.maven.devel . I can't filter that, so it's very hard to follow the conversations. Having a different mailing list (and gmane newsgroup) would fix it. With kind regards, Geoffrey De Smet Emmanuel Venisse wrote: -0 for the same reason. Emmanuel John Casey a écrit : -0 I filter it all into a separate folder anyway, so I don't notice. I would tend to think that jira issues are much closer to the types of discussions which are meant to take place here...commits are more of the ground-level implementation details. I get it all anyway, so if you all have a strong consensus one way or the other, I'll go along. -john Brett Porter wrote: What do folks think of doing this to make the dev traffic a bit friendlier to the people just reading the messages? - Brett - 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]
Re: repository manager overview
Looks like a promising tool. I tried IndexSearcherCli, but found out it needs to make an index first and there isn't one available for ibiblio yet. Will the indexes be available on a public server (through a xfire/hessian/httpinvoker webservice) or will everyone need to make it's own index to be able to use the command line tool (or a Swing GUI)? Or will it only be available through google-like website? PS: Anyone else experiencing this problem? I checked out the source, but regularly got: ... Amaven-repository-discovery/src/main svn: Can't move 'maven-repository-discovery/src/main/.svn/tmp/entries' to 'maven-repository-discovery/src/main/.svn/entries': Permission denied It must be something with my local cygwin svn 1.2.3 client, because after a couple times svn update worked. Just wanted to note it, in case anyone else seeing this. jerome lacoste wrote: On 2/8/06, Brett Porter <[EMAIL PROTECTED]> wrote: Some folks seem interested, so I wanted to give a quick overview of the repository manager. It is an application that runs either standalone or as a webapp with the following functionality: - repository search - repository/artifact browsing and display of artifacts and their relationships - repository health reports (missing transitive dependencies, incorrect/missing checksums, incorrect/missing digital signatures, out of place artifacts, missing poms, etc) - maven-proxy like support - repository conversion It has the following modules: - discovery: walks a repository and finds all the artifacts in it so you can perform a certain action on each, or just the ones that are new/deleted since last walked. - indexer: used to add artifacts and metadata to the lucene index. Includes elements of the POM and checksums - converter: copy artifacts from one repository to the other, changing layout, converting metadata if required. - artifact-applet: applet to allow you to checksum a large artifact on your local machine and upload the checksum to the server to search - reports-standard: a bunch of reports on the status of an artifact in the repository - proxy: maven-proxy like functionality - utils: checksum, pathing, etc - webapp: webwork 2 and plexus based webapp for running it all Any questions? Just what I was looking for. Thanks for pointing it out on the user list. I guess this is the URL, right? http://svn.apache.org/viewcvs.cgi/maven/repository-manager/trunk/ J -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=comments#action_59036 ] Geoffrey De Smet commented on MDEPLOY-25: - (both in the documentation and in the logging output would be nice) > deploy:deploy-file installs the file in the local repository too (but it > should not do that) > > > Key: MDEPLOY-25 > URL: http://jira.codehaus.org/browse/MDEPLOY-25 > Project: Maven 2.x Deploy Plugin > Type: Bug > Versions: 2.1 > Reporter: Geoffrey De Smet > Assignee: John Casey > Priority: Minor > > > deploy:deploy-file installs a jar in a remote repository, but currently also > installs it in the local repository. > I believe this is a bug, because it makes you wrongly believe that the remote > repository is ok when you run local tests afterwards. > If this is the desired behaviour, please notify it on the command line and > the documentation of deploy:deploy-file > When I installed a simple hello.jar in my remote repository, I also found it > in my local repository (in my user dir) after this command: > $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello > -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi > toryId=springRichclientRepository > -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor > y > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [INFO] [deploy:deploy-file] > Uploading: > file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. > 7.jar > 6b uploaded > [INFO] Retrieving previous metadata from springRichclientRepository > [INFO] Uploading repository metadata for: 'artifact org.hello:hello' > [INFO] Retrieving previous metadata from springRichclientRepository > [INFO] Uploading project information for hello 0.7 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 > [INFO] Final Memory: 2M/4M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=comments#action_59035 ] Geoffrey De Smet commented on MDEPLOY-25: - fair enough, but could it deploy:deploy-file at least note that it's also installing it locally? > deploy:deploy-file installs the file in the local repository too (but it > should not do that) > > > Key: MDEPLOY-25 > URL: http://jira.codehaus.org/browse/MDEPLOY-25 > Project: Maven 2.x Deploy Plugin > Type: Bug > Versions: 2.1 > Reporter: Geoffrey De Smet > Assignee: John Casey > Priority: Minor > > > deploy:deploy-file installs a jar in a remote repository, but currently also > installs it in the local repository. > I believe this is a bug, because it makes you wrongly believe that the remote > repository is ok when you run local tests afterwards. > If this is the desired behaviour, please notify it on the command line and > the documentation of deploy:deploy-file > When I installed a simple hello.jar in my remote repository, I also found it > in my local repository (in my user dir) after this command: > $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello > -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi > toryId=springRichclientRepository > -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor > y > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [INFO] [deploy:deploy-file] > Uploading: > file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. > 7.jar > 6b uploaded > [INFO] Retrieving previous metadata from springRichclientRepository > [INFO] Uploading repository metadata for: 'artifact org.hello:hello' > [INFO] Retrieving previous metadata from springRichclientRepository > [INFO] Uploading project information for hello 0.7 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 > [INFO] Final Memory: 2M/4M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
deploy:deploy-file installs the file in the local repository too (but it should not do that) Key: MDEPLOY-25 URL: http://jira.codehaus.org/browse/MDEPLOY-25 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.1 Reporter: Geoffrey De Smet Priority: Minor deploy:deploy-file installs a jar in a remote repository, but currently also installs it in the local repository. I believe this is a bug, because it makes you wrongly believe that the remote repository is ok when you run local tests afterwards. If this is the desired behaviour, please notify it on the command line and the documentation of deploy:deploy-file When I installed a simple hello.jar in my remote repository, I also found it in my local repository (in my user dir) after this command: $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi toryId=springRichclientRepository -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor y [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. 7.jar 6b uploaded [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading repository metadata for: 'artifact org.hello:hello' [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading project information for hello 0.7 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 [INFO] Final Memory: 2M/4M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MASSEMBLY-64) jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars
[ http://jira.codehaus.org/browse/MASSEMBLY-64?page=comments#action_58707 ] Geoffrey De Smet commented on MASSEMBLY-64: --- Implementing the exclusing of the META-INF's shouldn't be to hard. If none of the Maven guys have the time, maybe we can provide a patch? I got some other things on my mind, but if it's isn't fixed in a few weeks, I 'll provide a fix according to the development guidelines. > jar-with-dependencies has a last-one-copies-wins policy which can fail signed > jars > -- > > Key: MASSEMBLY-64 > URL: http://jira.codehaus.org/browse/MASSEMBLY-64 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.0.1 > Reporter: Geoffrey De Smet > Fix For: 2.1 > > > I've configured the plugins like this: > > org.apache.maven.plugins > maven-jar-plugin > > > > ggg.GGGStandaloneApp > true > > > > > > maven-assembly-plugin > > jar-with-dependencies > > > ggg.GGGStandaloneApp > > > > > BTW: Please document the archive option in the assembly plugin on the > assembly site, it took me a while of trial and error to find it. > However the application doesn't work yet, because: > Exception in thread "main" java.lang.SecurityException: no manifiest section > for signature file entry javax/activation/D > ataContentHandlerFactory.class > at sun.security.util.SignatureFileVerifier.verifySection(Unknown > Source) > at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source) > at sun.security.util.SignatureFileVerifier.process(Unknown Source) > at java.util.jar.JarVerifier.processEntry(Unknown Source) > ... > It looks like it's because the everything in the META-INF directory have a > last-one-copied-wins policy. > Jar-jar would also solve this of course. > PS: I am also using acegisecurity, so I belive you can replicate this issue > by making an assembly of a HelloWorld dependend on acegi & activation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MASSEMBLY-64) jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars
[ http://jira.codehaus.org/browse/MASSEMBLY-64?page=comments#action_58626 ] Geoffrey De Smet commented on MASSEMBLY-64: --- Benjamin.Keil also contacted me for this problem. Currently I just remove them with winrar afterwards, I don't need the functionality often. > jar-with-dependencies has a last-one-copies-wins policy which can fail signed > jars > -- > > Key: MASSEMBLY-64 > URL: http://jira.codehaus.org/browse/MASSEMBLY-64 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.0.1 > Reporter: Geoffrey De Smet > Fix For: 2.1 > > > I've configured the plugins like this: > > org.apache.maven.plugins > maven-jar-plugin > > > > ggg.GGGStandaloneApp > true > > > > > > maven-assembly-plugin > > jar-with-dependencies > > > ggg.GGGStandaloneApp > > > > > BTW: Please document the archive option in the assembly plugin on the > assembly site, it took me a while of trial and error to find it. > However the application doesn't work yet, because: > Exception in thread "main" java.lang.SecurityException: no manifiest section > for signature file entry javax/activation/D > ataContentHandlerFactory.class > at sun.security.util.SignatureFileVerifier.verifySection(Unknown > Source) > at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source) > at sun.security.util.SignatureFileVerifier.process(Unknown Source) > at java.util.jar.JarVerifier.processEntry(Unknown Source) > ... > It looks like it's because the everything in the META-INF directory have a > last-one-copied-wins policy. > Jar-jar would also solve this of course. > PS: I am also using acegisecurity, so I belive you can replicate this issue > by making an assembly of a HelloWorld dependend on acegi & activation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-707) Glazedlists 1.5.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-707?page=all ] Geoffrey De Smet updated MAVENUPLOAD-707: - Attachment: pom.xml > Glazedlists 1.5.0 > - > > Key: MAVENUPLOAD-707 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-707 > Project: maven-upload-requests > Type: Task > Reporter: Geoffrey De Smet > Attachments: pom.xml > > > JTable with sorting & filtering, used in spring-rich and many Swing > applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-707) Glazedlists 1.5.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-707?page=comments#action_57237 ] Geoffrey De Smet commented on MAVENUPLOAD-707: -- Here's the full discussion on the mailing list: http://comments.gmane.org/gmane.comp.java.glazedlists.user/741 > Glazedlists 1.5.0 > - > > Key: MAVENUPLOAD-707 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-707 > Project: maven-upload-requests > Type: Task > Reporter: Geoffrey De Smet > > > JTable with sorting & filtering, used in spring-rich and many Swing > applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-707) Glazedlists 1.5.0
Glazedlists 1.5.0 - Key: MAVENUPLOAD-707 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-707 Project: maven-upload-requests Type: Task Reporter: Geoffrey De Smet JTable with sorting & filtering, used in spring-rich and many Swing applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MASSEMBLY-64) jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars
[ http://jira.codehaus.org/browse/MASSEMBLY-64?page=comments#action_56992 ] Geoffrey De Smet commented on MASSEMBLY-64: --- Found a fix: exclude /META-INF/*.RSA /META-INF/*.SF /META-INF/*.rsa /META-INF/*.sf Problem solved. Please note that the fact that acegi (and some of the sun jars) are signed also gives problems with the webstart plugin. > jar-with-dependencies has a last-one-copies-wins policy which can fail signed > jars > -- > > Key: MASSEMBLY-64 > URL: http://jira.codehaus.org/browse/MASSEMBLY-64 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.0.1 > Reporter: Geoffrey De Smet > Fix For: 2.1 > > > I've configured the plugins like this: > > org.apache.maven.plugins > maven-jar-plugin > > > > ggg.GGGStandaloneApp > true > > > > > > maven-assembly-plugin > > jar-with-dependencies > > > ggg.GGGStandaloneApp > > > > > BTW: Please document the archive option in the assembly plugin on the > assembly site, it took me a while of trial and error to find it. > However the application doesn't work yet, because: > Exception in thread "main" java.lang.SecurityException: no manifiest section > for signature file entry javax/activation/D > ataContentHandlerFactory.class > at sun.security.util.SignatureFileVerifier.verifySection(Unknown > Source) > at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source) > at sun.security.util.SignatureFileVerifier.process(Unknown Source) > at java.util.jar.JarVerifier.processEntry(Unknown Source) > ... > It looks like it's because the everything in the META-INF directory have a > last-one-copied-wins policy. > Jar-jar would also solve this of course. > PS: I am also using acegisecurity, so I belive you can replicate this issue > by making an assembly of a HelloWorld dependend on acegi & activation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MASSEMBLY-64) jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars
jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars -- Key: MASSEMBLY-64 URL: http://jira.codehaus.org/browse/MASSEMBLY-64 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.0.1 Reporter: Geoffrey De Smet Fix For: 2.1 I've configured the plugins like this: org.apache.maven.plugins maven-jar-plugin ggg.GGGStandaloneApp true maven-assembly-plugin jar-with-dependencies ggg.GGGStandaloneApp BTW: Please document the archive option in the assembly plugin on the assembly site, it took me a while of trial and error to find it. However the application doesn't work yet, because: Exception in thread "main" java.lang.SecurityException: no manifiest section for signature file entry javax/activation/D ataContentHandlerFactory.class at sun.security.util.SignatureFileVerifier.verifySection(Unknown Source) at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source) at sun.security.util.SignatureFileVerifier.process(Unknown Source) at java.util.jar.JarVerifier.processEntry(Unknown Source) ... It looks like it's because the everything in the META-INF directory have a last-one-copied-wins policy. Jar-jar would also solve this of course. PS: I am also using acegisecurity, so I belive you can replicate this issue by making an assembly of a HelloWorld dependend on acegi & activation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1997) document xsd support for pom and settings in guides
[ http://jira.codehaus.org/browse/MNG-1997?page=comments#action_56453 ] Geoffrey De Smet commented on MNG-1997: --- Just found out, settings should be: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd";> > document xsd support for pom and settings in guides > --- > > Key: MNG-1997 > URL: http://jira.codehaus.org/browse/MNG-1997 > Project: Maven 2 > Type: Improvement > Components: documentation - guides > Versions: 2.0.2 > Reporter: Geoffrey De Smet > Fix For: 2.0.3 > > > Your favorite IDE probably supports xsd schema's for pom.xml and settings.xml > editing. > Yet very few have the defined the xsd in those files because they don't know > about it. > The guides should note that pom.xml files best start with: > > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > Why isn't it http://maven.apache.org/xsd/maven-v4_0_0.xsd (notice the xsd > subdirectory) btw? > and the settings.xml starts with: > > http://maven.apache.org/???/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/???/4.0.0 > http://maven.apache.org/xsd/settings-1.0.0.xsd";> > Of course, replace the ??? with something (I did "settings" but I ahve no > idea if that's ok). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1997) document xsd support for pom and settings in guides
document xsd support for pom and settings in guides --- Key: MNG-1997 URL: http://jira.codehaus.org/browse/MNG-1997 Project: Maven 2 Type: Improvement Components: documentation - guides Versions: 2.0.2 Reporter: Geoffrey De Smet Fix For: 2.0.3 Your favorite IDE probably supports xsd schema's for pom.xml and settings.xml editing. Yet very few have the defined the xsd in those files because they don't know about it. The guides should note that pom.xml files best start with: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> Why isn't it http://maven.apache.org/xsd/maven-v4_0_0.xsd (notice the xsd subdirectory) btw? and the settings.xml starts with: http://maven.apache.org/???/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/???/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd";> Of course, replace the ??? with something (I did "settings" but I ahve no idea if that's ok). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
