The user list is here [email protected] and you can subscribe to discuss
your issues using [email protected].
On Mar 10, 2010, at 5:45 AM, Trojan, Krzysztof wrote:
> Dear Sir,
>
> First of all I would like to apologize for writing to you directly. I have
> inadequate information about roles and responsibilities in the Maven project,
> so I write to You, as Maven PMC member and project founder, hoping you can
> distribute my email to the right people.
>
> I have been among Maven users for some time now. I am responsible for moving
> a really big banking solution build to Maven, that we hoped to solve a number
> of manageability problems we have had in the past. We have found Maven to
> suit our needs very well, but we are sometimes struggling with Maven ever
> changing behaviour and APIs. Having said that, Maven still is our tool of
> choice.
>
> However, we have found that Maven 3.0 is moving in a direction that we find a
> little bit dangerous for us. We have some arguments against proposed changes,
> and we kindly ask to open a discussion. In very short words, Maven 3.0 tries
> to restrict usage of expressions evaluated during build in some parts of the
> pom.xml (or a project descriptor, more generically speaking). We can see the
> warning saying something like “using an expression here is a BAD BAD thing,
> it will threaten stability of your build. We may stop supporting this one
> day”. While we can agree that build stability may be impacted, in the end it
> is MY (the developer) responsibility to avoid it. Build stability may be
> impacted by 10 other things you have no control over.
>
> Here is an extract:
> [WARNING] Some problems were encountered while building the effective model
> for com.fnis.crb:BigBankingProject:jar:${BigBankingProject.module.version}
> [WARNING] 'version' contains an expression but should be a constant. @
> com.fnis.crb:BigBankingProject:${BigBankingProject.module.version},
> C:\Workspaces\Corebank_Maven\BigBankingProject\pom.xml
>
> A little bit further down in the log there is
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
>
> If you want to warn me – fine, thank you, I have been warned. If you have the
> behaviour configurable (like being able to switch on some “relaxed” mode) –
> fine. But if the tool says: “you are stupid, but we have a cure, we will
> prevent you from doing those dangerous things …” it is a complete
> misunderstanding. The flexibility is ALWAYS a good thing, and the fact that
> there will be people who can screw things up badly just because they can,
> cannot be the justification to remove flexibility in favour of some “ONLY
> GOOD WAY”. And expressions are one of the ways of providing flexibility.
>
> I am unsure if the restriction the warning mention ('version' contains an
> expression but should be a constant) is only for the main artefact defined in
> pom.xml, or also applies to dependencies (can I have an expression in
> dependency version ? I know from the discussions documented in the Internet
> you were concerned with having a version not resolved to a concrete value –
> you also mentioned version ranges as potential threat).
>
> If you want to hear the exact use case, I can elaborate it, but it is way too
> complicated for an initial email.
>
> The main idea behind our solution is that we inject properties into the build
> specifying the versions of dependencies we want to use. Imagine modules A, B
> and C; A depends on B, and B depends on C. Now we have a feature branch that
> changes A and C … my way is to use A and C from branch, but B from trunk. I
> want to build A, it references B from trunk … but as B references C, I need a
> way to tell B to use C built from branch – here is where expression in the
> <version> is used, B knows to depend on C in “some version”
> (${C.module.version}), the actual value of ${C.module.version} is injected,
> so it gets resolved to correct version in the repository. I hope I have made
> it clear enough … There are several similar use cases possible, but only if
> such “deferred dependency binding” is possible. I kindly request not to
> forbid it, or at least add some switch that enables this.
>
> Maybe some special switch to Maven ? Or a property that is treated specially,
> like –Zmy.versionprop=XXX instead of –Dmy.version.property=XXX. If I use –Z
> (just an example, may be anything you want), just assume I know what I am
> doing, if it is found in the version … let it be. Of course this is all
> oversimplification, we would need to find a workable solution for embedded
> Maven, and to define this properties in profiles … but I hope you get the
> general idea.
>
> I just would like to open a discussion, that I hope will influence the
> direction Maven is going to.
>
> Kind regards,
> Krzysztof Trojan
> Senior Application Technician
> FIS Technology Services (Poland)
> Al. Jerozolimskie 81, 02-001 Warsaw, Poland
> [email protected]
> Tel: +48 601 98 96 96
> Fax: +48 22 695 05 51
> www.fisglobal.com
> <image001.jpg>
> This e-mail contains privileged and confidential information intended for the
> use of the addressees named above. If you are not the intended recipient of
> this e-mail, you are hereby notified that you must not disseminate it, copy
> it or take any action in respect of any information contained in it. If you
> have received this e-mail in error please notify the sender immediately by
> e-mail and destroy this e-mail and its attachments
>
>
> _____________
>
> The information contained in this message is proprietary and/or confidential.
> If you are not the intended recipient, please: (i) delete the message and all
> copies; (ii) do not disclose, distribute or use the message in any manner;
> and (iii) notify the sender immediately. In addition, please be aware that
> any message addressed to our domain is subject to archiving and review by
> persons other than the intended recipient. Thank you.
> _____________
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
