I would recommend changing your poms to avoid the situation where expansion on
install/deploy is required for things to work.
By containing variables I assume you mean expression expantion. So all the
properties should be expanded? I think that makes some sense but it affects
the ability to compose poms by inheritance.
For example I define the path for tags of my projects using ${pom.name} in the
parent pom so that my tag directory looks like this...
/tags/projectname/1.0
/tags/projectname/1.1
/tags/projectname/1.2
...
If that was resolved in the parent pom on deploy or install then everything
would end up tagged as
/tags/{parentname}/1.0
I notice that many people migrating projects over from ant tend to
parameterise their depedencies and IMO even worse use a parent to define the
versions of the depedencies. This leads to all sorts of problems in earlier
versions of maven < 2.0.7 esp when running on jdks < 5, not sure why the
sematics change on the different vms I think the default ordering of some
core collections changes.
I use some simple rules to keep consistent dependency hierachies
* dependecy ranges
* composition of dependencies
* don't deploy snapshots
* release early release often
* parent poms are not modules projects
and that works very well for a team of 10 with over 65 maven projects.
It helps to use webdav for deployment and http for repositories and set update
never for a proxy cached version of the main repos for improving the speed of
releases.
cheers
Michael
On Wednesday 22 August 2007 03:22, Brian E. Fox wrote:
> If this is done (not sure I'm convinced) I think this also needs to be
> handled in a way for Install also. Otherwise the pom in your local repo
> won't match what ultimately gets deployed. This could cause lots of
> headaches.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 21, 2007 4:12 AM
> To: [email protected]
> Subject: Idea of a new parameter for the DEPLOY plugin
>
> Hi All,
>
> When using Maven in my job, I'm encountering a problem of deployed POM
> which still contain variables. I would like to deploy POM whith the valued
> variables.
> I've looked at the deploy plugin source code, and I've understand that the
> deployed POM was the file POM on the disk.
> But, it could be interesting to introduce a new parameter (not mandatory)
> named deployValuedPom to the deploy plugin. This parameter will be a
> boolean flag to decide either to deploy the file POM on the disk
> (parameter=false, the default value), either the valued POM (explicit
> parameter=true). So the new feature won't have impact on existing projects.
>
> What do you think about this new feature?
>
> I could give a first version of the source code modification if the idea is
> correct.
>
> Thanks.
>
> Cyril
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
