Re: NSIS with maven and exe artifacts.
I was using antrun before but realized that the maven-exec plugin is better because maven is executing nsis directly instead of via an ant build.xml. Ken On Mon, Sep 14, 2009 at 10:55 AM, James Russo j...@halo3.net wrote: Will check those out. Thanks Stephen. -jr Stephen Connolly wrote: try antrun to package and then build-helper to attach the generated artifact to the reactor 2009/9/14 James Russo j...@halo3.net: Hello, I have a module where I would like to take the artifacts producted by a few other modules and combine them into an .EXE using NSIS. I see that there is a nsis for maven 1.x, but I don't see anything for 2.x? Anyone done this before care to explain how they accomplished it? Basically would like to have everything I need for NSIS in this module (other files, readme, configuration, etc) and then have it grab dependencies from other modules include it in NSIS and generate EXE. Ultimately I'd like to deploy this .exe to archiva. thanks, -jr - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: NSIS with maven and exe artifacts.
Julien -
When you did this, did you encounter a problem where test dependencies (e.g.
Junit) were also copied?
Ken
On Tue, Sep 15, 2009 at 2:20 AM, Julien Graglia jgrag...@netceler.comwrote:
Le lundi 14 septembre 2009 à 16:17 -0400, James Russo a écrit :
Hello Julien,
In your ncsetup.nsi, how do you reference the artifacts to be
included with the .exe build?
My installer artifact is of type pom and depends of my war. Then I use
the assembly plugin to retrieve dependencies and output them in folders.
Ex :
dependencySets
!-- copy all deps in the libs subfolder. target only desps
markes as
provided in my war --
dependencySet
outputDirectorylibs/outputDirectory
scopeprovided/scope
excludes
excludexxx:*/exclude
/excludes
/dependencySet
!-- copy all std deps in the libs subfolder. target only desps markes
as provided in my war --
dependencySet
outputDirectorylibs/outputDirectory
excludes
exclude:*/exclude
/excludes
/dependencySet
!--retreive all wars --
dependencySet
outputDirectorywebapps/outputDirectory
outputFileNameMapping${artifact.artifactId}.${artifact.extension}/outputFileNameMapping
scoperuntime/scope
includes
!--
http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html--
include*:war:*/include
/includes
/dependencySet
...
Then I just have to tell NSIS to include thats folders and install them
Extract of nsis.script in src/main/nsis/
SetOutPath $INSTDIR\libs
; copy all jars retrieved from the assembly plugin
File /r ..\..\..\target\xxx-${VERSION}-base\libs\*
SetOutPath $INSTDIR\webapps
File /r ..\..\..\target\xxx-${VERSION}-base\webapps\*
et voilà!
thanks,
-jr
Julien Graglia wrote:
Le lundi 14 septembre 2009 à 10:03 -0400, James Russo a écrit :
Hello,
I have a module where I would like to take the artifacts producted
by a few other modules and combine them into an .EXE using NSIS. I see
that there is a nsis for maven 1.x, but I don't see anything for 2.x?
Anyone done this before care to explain how they accomplished it?
Basically would like to have everything I need for NSIS in this module
(other files, readme, configuration, etc) and then have it grab
dependencies from other modules include it in NSIS and generate EXE.
Ultimately I'd like to deploy this .exe to archiva.
Hi,
Funny..., this morning, a guy on the maven irc just told me that a nsis
plugin (1) exists for maven 2.
today I use :
assembly plugin to download dependencies
maven exec (2) to run NSIS with some properties during package
phase
and build-helper-maven-plugin to attach generated .deb to my
artifact
(so that I can donwload the install from archiva (5))
but all these plugins could be replaced by a single call to that nsis
plugin. (see extract from my pom in (4))
I will give it a try next week (well I will try to find some time...)
1 : http://mojo.codehaus.org/nsis-maven-plugin/
2 : http://mojo.codehaus.org/exec-maven-plugin/introduction.html
3 : http://mojo.codehaus.org/build-helper-maven-plugin/howto.html
4 : http://pastie.org/616361 ( but I told you, that nsis plugin could
replace the exec+buildhelper part with a single (may be 4:=) ) line(s))
5: BTW, If you use Archiva, don't forget to add .exe extension to the
list of artifacts scanned in the repositories)
--
Julien Graglia
NetCeler
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: NSIS Maven Plugin
I've been looking at the same plugin recently and I think you can use the maven dependency plugin to copy the jars to an output directory that will be picked up by nsis. Your nsis maven project will have to declare your wars as dependencies. This is basically how I do it now without the NSIS plugin; I am calling NSIS through maven-antrun (pretty convoluted). Ken On Wed, Aug 12, 2009 at 4:13 PM, Harper, Brad brad.har...@fiserv.comwrote: It isn't clear how, with this plugin, the installer project would 'pull these artifacts in' for inclusion in the installer payload. Has anyone yet attempted to use this plugin in a non-trivial way? Thanks. Brad [1] http://mojo.codehaus.org/nsis-maven-plugin/index.html [2] http://mojo.codehaus.org/nsis-maven-plugin/examples/sample-nsis-project. htmlhttp://mojo.codehaus.org/nsis-maven-plugin/examples/sample-nsis-project.%0Ahtml
Re: [ANNOUNCE] Continuum 1.2 Released
The date on the release page is wrong, it says November 23, 2007. Ken On Mon, Sep 22, 2008 at 3:37 PM, Olivier Lamy [EMAIL PROTECTED] wrote: The Apache Continuum team is pleased to announce Apache Continuum 1.2. The latest release is now available here: http://continuum.apache.org/download.html If you have any questions, please consult: - the web site: http://continuum.apache.org - the continuum-user mailing list: http://continuum.apache.org/mail-lists.html New in Continuum 1.2 * Using Spring Continuum now uses the Spring Framework as it's underlying container instead of Plexus. This results in a boost in performance and stability for the web application in particular. *Repository Purge It's now possible to add purges which will cleanup : - m2 repositories (now it's possible to configure a local m2 repository per project group) - build output directory * Maven plugin groupId and artifactId change Now the maven plugin has the new groupId:artifactId org.apache.continuum:continuum-maven-plugin * New SCMs support Now continuum have two new scm providers : git and accurev. Change Log in Continuum 1.2 === ** Bug * [CONTINUUM-860] - multiple email addresses delimited with commas causes AddressException * [CONTINUUM-1054] - IllegalStateException stack adding pom * [CONTINUUM-1200] - Password Characters Not Supported in SCM Checkout * [CONTINUUM-1322] - Attempt to store value with more than 256 chars * [CONTINUUM-1336] - upgrade quartz - we use a very old version * [CONTINUUM-1360] - Prepended semicolon in svn password does not work * [CONTINUUM-1371] - NullPointer when Releasing with Ant and Default Project Group * [CONTINUUM-1433] - Wrong path in descripton on how to allow the file protocol. * [CONTINUUM-1489] - replace use of MungedHttpsURL with apache httpclient (4.0-beta1) * [CONTINUUM-1515] - SCM Tag does not have a default value * [CONTINUUM-1521] - NullPointerException in StarTeam changelog command * [CONTINUUM-1525] - Can't release project with Continuum on Geronimo 2.0.1 * [CONTINUUM-1528] - Continuum gets slower over time and eventually crashes * [CONTINUUM-1549] - LDAP Authenticated Continuum - NullPointerException when trying to see Members of a project group * [CONTINUUM-1575] - Confusing behavior when continuum can't construct MavenProject from pom * [CONTINUUM-1589] - updateBuildDefinitionForProjectGroup remove the description of the build definition * [CONTINUUM-1590] - updateBuildDefinitionForProjectGroup leads to a StackOverflowError * [CONTINUUM-1593] - Requires Javamail 1.5? Should be 1.4? * [CONTINUUM-1596] - The release perform doesn't work when a scm password is required * [CONTINUUM-1601] - Email address with '+' is not accepted in mail notifier * [CONTINUUM-1610] - Deployment Repository Directory does not work at all * [CONTINUUM-1623] - Checkbox not displaying when validation error in add Instalaction-Tool form * [CONTINUUM-1630] - Error attempting to delete project group * [CONTINUUM-1643] - Perform release page results to a blank page after submitted * [CONTINUUM-1644] - Test failures occur in tagged sources * [CONTINUUM-1646] - Empty recipient is allowed in mail notifier * [CONTINUUM-1647] - Incorrect alt and title text for releaseproject_disabled.gif * [CONTINUUM-1649] - Move Build Definition Template guide to Administrator's Guides * [CONTINUUM-1651] - Unable to delete user-created build definitions * [CONTINUUM-1659] - project admin cannot assign project roles to users * [CONTINUUM-1660] - Download page does not have source archives * [CONTINUUM-1672] - continuum plugin doesn't fails to add maven two projects * [CONTINUUM-1676] - deleting a project or group should cancel any current or scheduled builds, and prevent any from being queued * [CONTINUUM-1679] - Adding Null values for Project's Build Definition directs to a blank page * [CONTINUUM-1688] - Maximum length for name column in object ChangeFile is too small * [CONTINUUM-1693] - Continuum fills our server disk with SNAPSHOTs. * [CONTINUUM-1701] - No field validation when adding Ant and Shell projects * [CONTINUUM-1713] - JDOFatalUserException '.-..column NAME that has maximum length of 255. Please correct your data!' * [CONTINUUM-1715] - no response when adding a project * [CONTINUUM-1725] - Using the Cancel Button without an selected project will produce NPE * [CONTINUUM-1734] - Loop in getProjects methode * [CONTINUUM-1738] - Add schedule page doesn't use its properties file * [CONTINUUM-1739] - Import of Maven2 project fails if 2.0.9 feature depMgm. scopeimport used * [CONTINUUM-1742] - Duplicate installations (environment variables) in Profile are accepted * [CONTINUUM-1746] - Duplicate Profile names are accepted * [CONTINUUM-1748] -
Re: Maven 'deploy' relationship to large-scale software deployment
The best practice is to externalize all environment specific configuration. A single ear should be deployable to any environment without rebuilding. This is not just to simplify configuration, it is also beneficial from a QA standpoint because a binary can be moved between different environments dev-qa-uat-prod without the possibility of introducing defects as a result of a bad build. In my workplace, we build a single EAR that can be deployed in one of many (half dozen) environments, and then the specific configurations for each environment are managed/packaged separately using assemblies. At deployment time, these assemblies are unzipped (we don't automatically deploy apps for various reasons), and the EAR is dropped into the app server deploy directory. We do have the problem you mentioned of copy/paste between configuration files. It's not enough of a problem for us to warrant a more sophisticated approach, but if we did need it, we would probably use filtering or some similar mechanism to generate the configuration/property files from a template. Ken On 7/31/08, EJ Ciramella [EMAIL PROTECTED] wrote: This only hints at solutions to #2 below: 2 - How does one deploy said generated application zip/tar file? There's nothing I can see supplied in any plugin to support large scale deployments (say, six app servers, four web servers, a db server, a utils server and another half dozen or so third party servers). We've been using ant and an internally written shell script. Yes, we drop maven once the build is headed anywhere other than the local machine - but even within this developer environment, how do you share properties/configuration/etc across different applications without massive copy/paste duplication? How does anyone build to support multiple environments? Are you really rebuilding the ear with a different configuration? Is your ear over say, 20 mb? Are people just NOT building this level of complexity within maven? Even if the configuration/profiles was pushed out into a corporate pom (something outside of the general project structure), if/when that changed, you'd have a million poms to update to point them to a new parent version. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 4:48 PM To: Maven Users List Subject: Re: Maven 'deploy' relationship to large-scale software deployment I think you'll find that Maven itself stops at the repository. So the best thing to do is to use tools that can take artifacts from the repository and deploy them. There are lots of other solutions around for doing this sort of thing beyond that point and they specialise in handling the new set of problems it brings. I've generally found those doing the deployment are very separate from the rest of the development team and often have their own chosen set of tooling. You could use Maven itself to do this - though I'm not aware of any plugins that focus on this. While Cargo is generally used for test setups, it could serve this purpose as well, but it's mostly a space for a new piece of work. Cheers, Brett 2008/8/1 EJ Ciramella [EMAIL PROTECTED]: No, I don't understand how to do it either. I just stepped out of a meeting where we were discussing how we can deploy the same set of applications (which _some_ share properties) across 10 - 15 different environments. Some environments have different configurations, some are carbon copies. There doesn't seem to be any maven solution to either/all of these problems: 1 - Where does a property go (say db connection string) that's shared between different applications such that there isn't duplication? No one wants to have to search/replace values in various profiles.xml or pom.xml files (I don't mind, but others in the organization have objected). Here, since there are so many applications pointed at the same db, that could be a dozen or so files that have the same db string. 2 - How does one deploy said generated application zip/tar file? There's nothing I can see supplied in any plugin to support large scale deployments (say, six app servers, four web servers, a db server, a utils server and another half dozen or so third party servers). We've been using ant and a internally written shell script. 3 - How do people configure these things? I've heard every answer from we generate a zipped/tarred up application file for every environment to we use installshield and don't have to worry and everything in between. We have in one environment alone, 6 jboss servers for ONE application. That ear that gets deployed there (and all it's supporting files) even compressed in a zip takes close to 200 mb. I'm not about to generate 1200 mb worth of ear files with each build (sometimes there's three or more built in a single day). I feel like either there are different terms to describe these things or
Re: Maven 'deploy' relationship to large-scale software deployment
Forgot to mention - I have a coworker who came from a company where they had a very complex deployment with clusters and many different applications sharing configuration. There they had a central configuration server where all the applications programmatically could look up configuration parameters. Something like this takes a lot of commitment across development teams, but maybe something like this would work for you. On 8/6/08, Ken Liu [EMAIL PROTECTED] wrote: The best practice is to externalize all environment specific configuration. A single ear should be deployable to any environment without rebuilding. This is not just to simplify configuration, it is also beneficial from a QA standpoint because a binary can be moved between different environments dev-qa-uat-prod without the possibility of introducing defects as a result of a bad build. In my workplace, we build a single EAR that can be deployed in one of many (half dozen) environments, and then the specific configurations for each environment are managed/packaged separately using assemblies. At deployment time, these assemblies are unzipped (we don't automatically deploy apps for various reasons), and the EAR is dropped into the app server deploy directory. We do have the problem you mentioned of copy/paste between configuration files. It's not enough of a problem for us to warrant a more sophisticated approach, but if we did need it, we would probably use filtering or some similar mechanism to generate the configuration/property files from a template. Ken On 7/31/08, EJ Ciramella [EMAIL PROTECTED] wrote: This only hints at solutions to #2 below: 2 - How does one deploy said generated application zip/tar file? There's nothing I can see supplied in any plugin to support large scale deployments (say, six app servers, four web servers, a db server, a utils server and another half dozen or so third party servers). We've been using ant and an internally written shell script. Yes, we drop maven once the build is headed anywhere other than the local machine - but even within this developer environment, how do you share properties/configuration/etc across different applications without massive copy/paste duplication? How does anyone build to support multiple environments? Are you really rebuilding the ear with a different configuration? Is your ear over say, 20 mb? Are people just NOT building this level of complexity within maven? Even if the configuration/profiles was pushed out into a corporate pom (something outside of the general project structure), if/when that changed, you'd have a million poms to update to point them to a new parent version. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 4:48 PM To: Maven Users List Subject: Re: Maven 'deploy' relationship to large-scale software deployment I think you'll find that Maven itself stops at the repository. So the best thing to do is to use tools that can take artifacts from the repository and deploy them. There are lots of other solutions around for doing this sort of thing beyond that point and they specialise in handling the new set of problems it brings. I've generally found those doing the deployment are very separate from the rest of the development team and often have their own chosen set of tooling. You could use Maven itself to do this - though I'm not aware of any plugins that focus on this. While Cargo is generally used for test setups, it could serve this purpose as well, but it's mostly a space for a new piece of work. Cheers, Brett 2008/8/1 EJ Ciramella [EMAIL PROTECTED]: No, I don't understand how to do it either. I just stepped out of a meeting where we were discussing how we can deploy the same set of applications (which _some_ share properties) across 10 - 15 different environments. Some environments have different configurations, some are carbon copies. There doesn't seem to be any maven solution to either/all of these problems: 1 - Where does a property go (say db connection string) that's shared between different applications such that there isn't duplication? No one wants to have to search/replace values in various profiles.xml or pom.xml files (I don't mind, but others in the organization have objected). Here, since there are so many applications pointed at the same db, that could be a dozen or so files that have the same db string. 2 - How does one deploy said generated application zip/tar file? There's nothing I can see supplied in any plugin to support large scale deployments (say, six app servers, four web servers, a db server, a utils server and another half dozen or so third party servers). We've been using ant and a internally written shell script. 3 - How do people configure these things? I've heard every answer from we generate a zipped/tarred up application file for every
generate bat/cmd with classpath?
Hi all - Is there any easy way to have maven generate a cmd or bat file with the java command line populated with the classpath from the maven dependencies? Ken
Re: How to better manage cascading releases
This is a great question...I have wondered the same thing myself. I am working on a complex project that involves simultaneously releasing 6 ears. The whole build consists of 25+ maven projects (not counting modules) that are built and released together (relax, many of them are purely assemblies). The dependency tree between all of these projects is at least 5 deep. The way we have solved the problem is to always declare SNAPSHOT dependencies (for internal dependencies). At release time, there is a script that tags the trunk, checks out the tag, updates the pom versions, updates the scm path, updates the dependency versions (changes the SNAPSHOTs to released numbers), then commits the changes and builds the release. This is basically the same as what the release-plugin does. The script does this once for each project in the correct dependency order. The script is driven by a yml file that is the metadata for the super build - it contains the list of projects, svn locations, and target version numbers, and dependencies between projects. The script is around 200 lines of ruby code. The script is run manually, which is ok since we do this official release only once every few weeks. (Each individual project is built in Continuum during normal development.) I justified the cost/time of developing these scripts to my manager by explaining that it took me around two days in the beginning to do the entire build, now it takes about two hours (some artifacts take a long time to run the unit tests) from start to finish. I spent a little bit of time before each release working on the script so now there is a net cost savings :) AFAIK, there is no easy way to do this. I suspect many organizations don't do anything so complex and others do not attempt to _simultaneously_ release so many projects, so the cost of releasing is spread out, and is not noticed. Ken On 5/31/08, Stephen Connolly [EMAIL PROTECTED] wrote: We have a four uber project set of releases. We use scripts to check out the latest released pom.xml for each from svn, pull out the version number, step back if it's a -SNAPSHOT, update our module's dependencies to this version, run maven with the integration tests and check in the updated pom.xml if the tests pass before doing mvn release:prepare release:perform -B This is set up as a number of release jobs in Hudson. Just kick off a build and you get the release when it's all done, or an email telling you what broke... I would like to do a bit more work and make it keep trying less new versions of the dependency until it falls back to the one it started with... but that's getting too fancy... the script is currently only 100 or so lines long -Stephen On Fri, May 30, 2008 at 9:12 AM, Bracewell, Robert [EMAIL PROTECTED] wrote: In our organization it depends on the project but I have projects that release twice a week internally. Other groups or projects that are reliant on such artifacts can then decide as and when they want to depend on the new artifacts that were deployed. -Original Message- From: Geoffrey Wiseman [mailto:[EMAIL PROTECTED] Sent: 30 May 2008 03:35 To: Maven Users List Subject: Re: How to better manage cascading releases On Thu, May 29, 2008 at 6:39 PM, Michael McCallum [EMAIL PROTECTED] wrote: release early release often... we don't use snapshot dependencies and release artifacts early. So if you are working on one of the 13 dependent libraries as soon as you - the dev - is happy the change is ready for use then you release it. why leave it as a snapshot? If the change would break anything useing it we bump the major version up so its not pulled in until downstream users are ready. if you use version ranges and manage codelines by major version then you can easily have the trunk of a project being actively developed and released without pulling it into a deliverable. Hmm, interesting perspective. I still find it takes an hour or two to pull off a release, between the dry-run, the actual prepare and the perform -- do you find that cost goes down if you release a lot, or have tricks for reducing the cost of releasing? - Geoffrey -- Geoffrey Wiseman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
read scm connection url using svn info?
Hi all - Is there any way that the scm connection URL can automatically be read using svn info instead of putting it into the pom? For example, instead of writing: scm connectionscm:svn:http://my.svn.server/trunk/connection /scm You could just write something like: scm connectionscm:svn:auto/connection /scm and then the maven svn impl could just execute svn info and extract the URL string from the output. This would be very handy because you would never have to worry about whether the scm url is correct in the POM, in case the POM file is moved or copied/tagged in the repo. Ken
Re: scm plugin
Maven scm does not implement the svn client software, it calls the command-line svn executable instead. You will need to install the command line client available at http://subversion.tigris.org, and have it available in the path. Ken On 3/11/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That error means that svn is not installed on your home machine. Of course, svn isn't installed on my pc - I just got a svn client - tortoise ( http://tortoisesvn.tigris.org/) to connect to a svn server. Isn't that what scm is used for?! Why would anyone install a svn server on a developer pc?! Thanks in advance, Stefanie -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven2 jira plugin?
Hi all - I am looking for a plugin that can query a jira repository and produce a report. I found an existing plugin, but that appears to be for maven 1. Anyone know of a plugin that is compatible with maven2? Ken
Re: [POLL] Why are you not able to use the most recent maven release?
I'm sort of in the same boat, but for different reasons. The maven version is considered to be part of the configuration for each project, so projects are tied to whatever version of Maven was used at release time. Upgrades are considered to be changes to the build environment, which are out of scope in certain projects (small patch releases, for example). We play it safe in these cases because changes to Maven versions can cause build-related regressions. We also use Continuum as our CI environment, and Continuum is tied to whatever Maven version the Continuum unix account uses, which means that we are forced to use the same Maven version for all projects in Continuum. Upgrading the maven that Continuum uses forces all projects to upgrade Maven versions. Until I can figure out a way to get Continuum to run with different Maven versions, we're stuck with the current one. Either that, or I get the entire development team to upgrade simultaneously to a new Maven version. (Which might not really be such a big deal, IMO.) We're currently stuck on 2.0.4 but are starting to plan to upgrade to 2.0.9. 2.1 is not even on the radar yet. Ken On 3/7/08, EJ Ciramella [EMAIL PROTECTED] wrote: We're currently stuck on 2.0.5 - the problem is getting an entire organization to upgrade. Aside from the, it works better response, typically, there needs to be a financial reason explaining why we are asking everyone to stop what they are doing and upgrade. -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2008 4:45 PM To: Maven Users List Subject: [POLL] Why are you not able to use the most recent maven release? I get the sense that lots of people are using older versions of Maven due to various regressions. As we get closer to 2.1 alpha, we need to ensure that we identify the regressions across the 2.0 line so that we can make sure they are fixed in 2.1 and so that users can upgrade to a recent 2.0.x before trying out 2.1. If this is the case for you, please reply and state the version you're using and why (preferably referring to a Jira). We will use this information to prioritize issues for 2.0.10 and beyond. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SNAPSHOT checking plugin?
This looks great, but I would prefer not to add additional configuration to my POMs just to do a check for SNAPSHOT versions. Is there any way to achieve this without adding stuff to POMs? (I would have to add configuration to all of my POMs, of which there are many). Thanks, Ken On 2/28/08, Jason Chaffee [EMAIL PROTECTED] wrote: maven-enforcer-plugin you might have to build the latest from source to get all the documented functionality as the current released one doesn't support everything on the Web site. -Original Message- From: Ken Liu [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 3:06 PM To: Maven Users List Subject: SNAPSHOT checking plugin? Hi all - I really like that the release-plugin checks the project for any SNAPSHOT dependencies, but I am not so crazy about the release-plugin itself. Is there any plugin available that will only do the check for SNAPSHOT dependencies, or is there any other way to do this? Thanks, Ken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SNAPSHOT checking plugin?
Ok. The problem is that I would like to do the check for the SNAPSHOT versions only at release-time, just like the release plugin does. Normally, the developers depend on SNAPSHOT dependencies during day to day development, but at release time, we update all the dependencies to depend on specific versions. Is there a way I can use profiles to add the configuration for the enforcer so that it only gets run when a special release profile is activated? Ken On 2/29/08, Brian E. Fox [EMAIL PROTECTED] wrote: This is the only way to do it. You should have a common pom that all your stuff shares and you would just put the config in that one place. -Original Message- From: Ken Liu [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 11:19 AM To: Maven Users List Subject: Re: SNAPSHOT checking plugin? This looks great, but I would prefer not to add additional configuration to my POMs just to do a check for SNAPSHOT versions. Is there any way to achieve this without adding stuff to POMs? (I would have to add configuration to all of my POMs, of which there are many). Thanks, Ken On 2/28/08, Jason Chaffee [EMAIL PROTECTED] wrote: maven-enforcer-plugin you might have to build the latest from source to get all the documented functionality as the current released one doesn't support everything on the Web site. -Original Message- From: Ken Liu [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 3:06 PM To: Maven Users List Subject: SNAPSHOT checking plugin? Hi all - I really like that the release-plugin checks the project for any SNAPSHOT dependencies, but I am not so crazy about the release-plugin itself. Is there any plugin available that will only do the check for SNAPSHOT dependencies, or is there any other way to do this? Thanks, Ken - 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]
SNAPSHOT checking plugin?
Hi all - I really like that the release-plugin checks the project for any SNAPSHOT dependencies, but I am not so crazy about the release-plugin itself. Is there any plugin available that will only do the check for SNAPSHOT dependencies, or is there any other way to do this? Thanks, Ken
Re: Surefire 2.4.1 classpath order
Dan - Do you know if that bug was introduced in 2.0.7 (or some other earlier release)? My team is using 2.0.4 and we encountered a problem with the classpath ordering recently that caused builds to that were previously working to suddenly start failing. Thanks, Ken On 2/15/08, Dan Fabulich [EMAIL PROTECTED] wrote: Ben Lidgey wrote: We are running tests using Surefire 2.4.1 and Maven 2.0.8. [...] Looking at the debug output shows: [DEBUG] Test Classpath : [DEBUG] C:\Documents and Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar [more jars] [DEBUG] c:\Development\Projects\MyProject\target\classes [DEBUG] c:\Development\Projects\MyProject\target\test-classes Which would explain it. Is there anyway to get the test-classes before classes in the classpath order? Setting childDelegation to true doesn't. I'm not 100% certain you're using the software you think you're using; here's some debugging/analysis tips. Take a look at http://jira.codehaus.org/browse/MNG-3118. That bug was fixed in Maven 2.0.8 and called out in the release announcement as a backwards compatibility risk: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00432.html As noted in MNG-3118, Surefire 2.3 had a bizarre classpath ordering bug that made the test classpath appear to be correct (test-classes first) under Maven 2.0.7 for some users with large classpaths: http://jira.codehaus.org/browse/SUREFIRE-61 SUREFIRE-61 was fixed in Surefire 2.3.1. Notably, it would make the Test Classpath output in -X look correct, while secretly under the hood it would munge the classpath incorrectly! As a result, for at least one project here at my work, we've seen: Maven 2.0.7 + Surefire 2.3: test-classes before classes Maven 2.0.8 + Surefire 2.3: classes before test-classes Maven 2.0.7 + Surefire 2.3.1 or higher: classes before test-classes Maven 2.0.8 + Surefire 2.3.1 or higher: test-classes before classes Benjamin checked in a classpath ordering test in the Surefire trunk that we now run with every release. It's currently passing for me with Surefire 2.4.1 (and 2.4.2-SNAPSHOT) and Maven 2.0.8, and failing with Maven 2.0.7. Finally, note that your real classpath is being output in your target/surefire-reports/*.xml files as the surefire.test.classpath property; that may be useful for debugging purposes. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency Order, src/test/resources not overriding src/main/resources
I experienced the same problem with Maven 2.0.4 and Surefire 2.3 and 2.4. I solved the problem by reverting the Surefire plugin version back to 2.2. I believe the latest version of Maven 2.0.8 and Surefire 2.3 and 2.4 do not have this problem. Ken On 1/29/08, Andrew Seales [EMAIL PROTECTED] wrote: Hi, I recently updated maven using mvn -U command and since yesterday projects which have properties files of the same name in src/test/resources and src/main/resources now no longer have the version in src/test/resources taking precedence over the ones in src/main/resources when running mvn test(for example database properties files). Is this an intentional change or is there a bug in a recent plugin version? Thank you, -- Andrew Seales EDINA tel: +44 (0) 131 650 3022 Edinburgh Universityfax: +44 (0) 131 650 3308 Causewayside House url: http://edina.ac.uk 160 Causewaysideemail: [EMAIL PROTECTED] Edinburgh EH9 1PR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
how to manually change a jar from SNAPSHOT to release?
Hi all - I am getting close to releasing a project and am trying to nail down all the SNAPSHOT dependencies. I have one plugin (jboss-sar), which was never released, and only has a 2.0-SNAPSHOT version available. I want to take this jar and assign a release number to it to be installed in our internal maven repo. Is there an official way to do this? I have been manually doing the following: 1) in the jar, editing plugin.xml and replacing the version 2.0-SNAPSHOT with 2.0-MINE 2) in the jar, editing pom.properties and changing the property 2.0-SNAPSHOT with 2.0-MINE 3) in the jar, editing pom.xml and replacing the version 2.0-SNAPSHOT with 2.0-MINE 4) renaming the jar from jboss-sar-maven-plugin-2.0-SNAPSHOT.jar to jboss-sar-maven-plugin-2.0-MINE.jar 5) using mvn install:install-file to add the jar to my internal repository Is this sufficient? Did I miss any steps? Is there an easier way to do this?
Re: how to manually change a jar from SNAPSHOT to release?
Hi Stephen - Thanks for your reply. Those euro-cents are worth a a lot more than my $.02. I'm leaning toward option #1. To clarify, I wasn't planning on rebuilding the jar from the source, just taking the SNAPSHOT jar from the public repo. In fact, I don't intend to ever have to do this again because the particular plugin is no longer under development (there was never an official, non SNAPSHOT release). But point taken, if we were using a different SNAPSHOT plugin, then we might want to version a newer SNAPSHOT. I plan on using the version 2.0-mycompany-1. Are the steps that I described sufficient for changing the version number in the jar, or is it really necessary to build from the source? I would rather not spend time/effort rebuilding something from the source when the artifact is already being used. Ken On 1/22/08, Stephen Connolly [EMAIL PROTECTED] wrote: There are two ways: 1. Give it a new version number (e.g. 2.0-yourcompany-1) because you may want to re-build it if/WHEN you find issues with your build, and if you don't attach a build/version to the version number you'll be in trouble. Also you should prefix the build/version with yourcompany so people know it's you as what did it. 2. Alternatively, change the groupId to com.yourcompany.yourproduct... now you can have any version number you like. For that kind of change I would strongly recommend importing the source code into your SCM, as in reality this is a fork For both 1 2 I would ensure that you have a snapshot of the source code in SCM, but with option 2, you really will need that snapshot. Also #2 is probably better suited to when you need to patch the source heavily in order to get it to build, whereas #1 is for when they just have not pushed a release as recently as you'd like. Just my €0.02 On Jan 22, 2008 7:54 PM, Ken Liu [EMAIL PROTECTED] wrote: Hi all - I am getting close to releasing a project and am trying to nail down all the SNAPSHOT dependencies. I have one plugin (jboss-sar), which was never released, and only has a 2.0-SNAPSHOT version available. I want to take this jar and assign a release number to it to be installed in our internal maven repo. Is there an official way to do this? I have been manually doing the following: 1) in the jar, editing plugin.xml and replacing the version 2.0-SNAPSHOT with 2.0-MINE 2) in the jar, editing pom.properties and changing the property 2.0-SNAPSHOT with 2.0-MINE 3) in the jar, editing pom.xml and replacing the version 2.0-SNAPSHOT with 2.0-MINE 4) renaming the jar from jboss-sar-maven-plugin-2.0-SNAPSHOT.jar to jboss-sar-maven-plugin-2.0-MINE.jar 5) using mvn install:install-file to add the jar to my internal repository Is this sufficient? Did I miss any steps? Is there an easier way to do this?
Re: Pre-release Testing Best Practices?
Eric, I agree with this procedure. I would not recommend handing over a SNAPSHOT build to a QA group as a release candidate. It is safer to build off of a branch and treat that branch as a release candidate if there is ongoing development work in the trunk. If developers are putting changes into the trunk at the same time that QA is testing your build, then the trunk is considered unstable and you could potentially introduce bad code into your build at any time. This is fine for a snapshot or CI build, but it's not something you would want to risk for a set of code that has already gone through a QA process. Ken On 12/13/07, Kalle Korhonen [EMAIL PROTECTED] wrote: In your situation, whenever you think you are ready for a release, I'd just run release:prepare to create the tag, but not run release:perform immediately. Then check out the tag, and run your manual regression etc. testing suites against it. If minor things - like configuration or versions are wrong, fix directly in the tag, otherwise just abandon the tag and never release that version, fix the build and and release:prepare a new one - you got unlimited number of versions at your disposal. Once you are confident the tag's good, only then release:perform or just deploy from the tag. Basically you always consider a tag a normally versioned release candidate until you publish it into your distribution repository. This is what we do in one projects and generally works well. After all, this is why the release is a two-step process. Kalle On 12/13/07, Eric Minick [EMAIL PROTECTED] wrote: Thanks Marco, I also tend to agree here as well and I think this would be a no-brainier if I was going to production quarterly. This particular project has minor updates going into production every week or three. That's border-line insane, but that matches the business needs. I've been at a number of organizations that work the same way. My concern is that branch explosion could be difficult to manage from a CI perspective as well as for developers. I again find myself asking for best practices without giving all the details. My apologies. Best practices always change a bit as you face different problems. -- Eric On 12/13/07, Beelen, M. - SPLXL [EMAIL PROTECTED] wrote: Eric, When I read your email I think it's more an issue for source code management and versioning, then that it should be for maven. If you start the process of releasing a module, you could create a branch for that version and then release some beta or milestones (M1, M2, M3, ., M10) from that branch and send it to QA. If QA approves a certain milestone, you could check it out and adjusted the version-number to remove the milestone identifier and release the actual version. Changes to mainline code should be performed on the trunk so they won't get in the way of you release and QA proces. Upon your release, you should merge the changes from the branch to the trunk and continue to work on the next release. With kind regards, Marco -Original Message- From: Eric Minick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 11:25 PM To: users@maven.apache.org Subject: Pre-release Testing Best Practices? I'm looking at doing some releases using the maven release plugin. Our environment is a set of pretty typical in house development projects for some web-apps. So we have things like dev, qa and production environments for deployment and frequent releases. We don't want to cut a release before doing QA on it. So an ideal scenario is to put a snapshot build into QA, and get it approved. Once approved, we would want to release that code, verify that dependency changes didn't break things with regression tests, then move on to staging and production. A natural concern here is that there are likely more changes to the mainline code base that come in during testing and we would not want to release those. Getting the code that went into the tested build out of source control at release time is not a problem though. I have two questions: 1) Are there common \ recommended strategies for dealing with this type of scenerio? 2) If I just pull the old code out and run a release, is the SVN label (copy) command a local copy (which would only include the files in my release space) or a remote copy (which would include my newly checked in pom as well as any changes committed since we went to QA)? Thanks, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** For information, services and offers, please visit our web site: http://www.klm.com.
