Re: maven generate war
Hi Gloria, Maven use maven-war-plugin to generate war file. You can get more information from here: http://maven.apache.org/plugins/maven-war-plugin/ I think this question is better talked on user-list or you can send me email personally :-) On Aug 20, 2010, at 2:12 PM, 文娟 wrote: > Dear Developer, >I am a user of maven. During develop our project I encounter a problem. > Could you give me some suggestion about it. The problem is how maven generate > war. Could you tell me their work(maven generate war) flow chart.Thank you. >I am waiting for your reply. > > > Best Wishes > > >sincerely gloria -Weinan Li - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design & Best Practices
Issue Subscription
Filter: Design & Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites"
http://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-4713
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
http://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Filling in a few gaps with enforcer rules
On Thu, Aug 26, 2010 at 12:39 PM, Rex Hoffman wrote: > Baptiste: > > I work in a large organization, where there are differing degrees of > familiarity with maven. > Most devs shy away from the release plugin for several reasons. One > is the use of hudson and nexus. > I actually wrote those rules because we had a client that couldn't use the release plugin for various reasons, but we wanted to encapsulate the best practices contained in the plugin, so this is totally in line with that. > Brian: > > 1) The snapshot detection rules are similar rules, I'll look at them > fully to see what differences exist. I wanted the error messages > given to the user to be the path to each transitive dependency that > was a snapshot (if the artifact was building a release), rather than > suppling one. > Sure, maybe you can just patch the existing rule to your needs and we can apply it. > 2) One of my rules forces every module of a reactor build to have the > same version number as the parent. Rather than only demanding that is > a snapshot or not. > (http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html) > > 3) There is an extra rule coupled into the first (which it looks like > I should decouple incase the rest of the rule shouldn't make it in > because it is view as being too similar to > http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html) > which forces developers to resolve transitive dependency version > number conflicts at build rather than letting maven do it. > All transitive dependency conflicts are displayed when the rules > detects that it has been violated. > > Seems like 2 and 3 are unique enough to make it in as rules? > Yes - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Filling in a few gaps with enforcer rules
Baptiste: I work in a large organization, where there are differing degrees of familiarity with maven. Most devs shy away from the release plugin for several reasons. One is the use of hudson and nexus. Developers are not allowed to cut releases on their machines. Simply checking in updated version numbers into hudson will alter the behavior of the deploy step when hudson is run. The artifact will be pushed to the releases directory in our nexus instance, instead of the usual snapshot location, if the version number of the artifact being built is a release. We follow the apache versioning standard and have a branch structure that is built to mirror that standard. Bug fix releases, for instance are always cut off of a branch labeled 1.0.X, 1.1.X, etc... So often devs don't cut branches for bug fix releases, eliminating a lot of the usefulness of the release plugin. Brian: 1) The snapshot detection rules are similar rules, I'll look at them fully to see what differences exist. I wanted the error messages given to the user to be the path to each transitive dependency that was a snapshot (if the artifact was building a release), rather than suppling one. 2) One of my rules forces every module of a reactor build to have the same version number as the parent. Rather than only demanding that is a snapshot or not. (http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html) 3) There is an extra rule coupled into the first (which it looks like I should decouple incase the rest of the rule shouldn't make it in because it is view as being too similar to http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html) which forces developers to resolve transitive dependency version number conflicts at build rather than letting maven do it. All transitive dependency conflicts are displayed when the rules detects that it has been violated. Seems like 2 and 3 are unique enough to make it in as rules? Rex On Thu, Aug 26, 2010 at 12:52 AM, Baptiste MATHUS wrote: > 2010/8/25 Rex Hoffman > >> So I felt there are few gaps in the maven release process (and >> enforcing a project or a reactor project is releasable). >> >> Perceived gaps: >> >> 1) Maven should fail a build if it is building a release version >> number and any of it's dependencies (including transitive dependencies >> on plugins, or inherited, etc...) are snapshot dependencies. >> > > Not sure to understand. Normally, the maven release (via the release plugin) > already does it. You can release a version if you don't replace all > snapshots with release versions. What doesn't work for you? > > Cheers > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > nbsp;! > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [CANCEL] [VOTE] Release Apache Maven 3.0-beta-3
If there's any further information I can give let me know. I suspect there's something to do with the dependencies in the project, as some of our artifacts released fine, but 3-4 had this NPE. 1) We use version ranges for our internal dependecies, such as [2.0.0,3.0.0) 2) We're using nexus 1.5.x as our repo manager mark -- Pull me down under... On Thu, Aug 26, 2010 at 11:00 PM, Benjamin Bentmann wrote: > Mark Derricutt wrote: > > -1 - I'm getting NullPointerExceptions with the aether in todays current >> nightly build when doing releases. >> >> https://gist.github.com/8ac6e71ad49cf8928549 >> >> Raised as http://jira.codehaus.org/browse/MNG-4779 >> > > Thanks, I hereby cancel the vote to fix this first. > > > Benjamin > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[CANCEL] [VOTE] Release Apache Maven 3.0-beta-3
Mark Derricutt wrote: -1 - I'm getting NullPointerExceptions with the aether in todays current nightly build when doing releases. https://gist.github.com/8ac6e71ad49cf8928549 Raised as http://jira.codehaus.org/browse/MNG-4779 Thanks, I hereby cancel the vote to fix this first. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-beta-3
+1 (non-binding) 2010/8/26 Paul Merlin > > +1 > > /Paul > > Quoting Benjamin Bentmann : > > Hi, > > > > apart from another few regression fixes, this release includes Guice and > > Aether [0] and shall help to get some more community testing on these > > new components. Overall, we solved 16 issues: > > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16 > > 681 > > > > There are still a couple of issues left in JIRA: > > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&st > > atus=1 > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-146/ > > > > Staged source and binary distros: > > > https://repository.apache.org/content/repositories/maven-146/org/apache/mav > > en/apache-maven/3.0-beta-3/ > > > > Guide to testing staged releases: > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > +1 from me > > > > > > Benjamin > > > > > > [0] http://github.com/sonatype/sonatype-aether > > > > - > > 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 > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Filling in a few gaps with enforcer rules
2010/8/25 Rex Hoffman > So I felt there are few gaps in the maven release process (and > enforcing a project or a reactor project is releasable). > > Perceived gaps: > > 1) Maven should fail a build if it is building a release version > number and any of it's dependencies (including transitive dependencies > on plugins, or inherited, etc...) are snapshot dependencies. > Not sure to understand. Normally, the maven release (via the release plugin) already does it. You can release a version if you don't replace all snapshots with release versions. What doesn't work for you? Cheers -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!
Re: [VOTE] Release Apache Maven 3.0-beta-3
+1 /Paul Quoting Benjamin Bentmann : > Hi, > > apart from another few regression fixes, this release includes Guice and > Aether [0] and shall help to get some more community testing on these > new components. Overall, we solved 16 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16 > 681 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&st > atus=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-146/ > > Staged source and binary distros: > https://repository.apache.org/content/repositories/maven-146/org/apache/mav > en/apache-maven/3.0-beta-3/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > +1 from me > > > Benjamin > > > [0] http://github.com/sonatype/sonatype-aether > > - > 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
