Re: NSIS with maven and exe artifacts.

[Ken Liu]

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 wrote:

> 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 :
>
>
>
>libs
>provided
>
>xxx:*
>
>
> 
>
>libs
>
>:*
>
>
> 
>
>webapps
>
>
> ${artifact.artifactId}.${artifact.extension}
>runtime
>
> Julien Graglia
> NetCeler
>
>
>
> -
> 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.

[Ken Liu]

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  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 :
>>
>>
>>> 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 Maven Plugin

[Ken Liu]

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 wrote:

>
>
> 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.
> html
>
>
>
>

Re: [ANNOUNCE] Continuum 1.2 Released

[Ken Liu]

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. scope>import used
>* [CONTINUUM-1742] - Duplicate installations (environment
> variables) i

Re: Maven 'deploy' relationship to large-scale software deployment

[Ken Liu]

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 

Re: Maven 'deploy' relationship to large-scale software deployment

[Ken Liu]

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 (som

generate bat/cmd with classpath?

[Ken Liu]

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

[Ken Liu]

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?

[Ken Liu]

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:svn:http://my.svn.server/trunk


You could just write something like:
 
scm:svn:auto


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

maven2 jira plugin?

[Ken Liu]

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: scm plugin

[Ken Liu]

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]
>
>

Re: [POLL] Why are you not able to use the most recent maven release?

[Ken Liu]

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?

[Ken Liu]

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]
>
>

Re: SNAPSHOT checking plugin?

[Ken Liu]

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]
>
>

SNAPSHOT checking plugin?

[Ken Liu]

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

[Ken Liu]

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

[Ken Liu]

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  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]
>
>

Re: how to manually change a jar from SNAPSHOT to release?

[Ken Liu]

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?
> >
>

how to manually change a jar from SNAPSHOT to release?

[Ken Liu]

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?

[Ken Liu]

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
> > >
> > > -
>