Hi,
> Well, if I read correctly what you said, you're putting the dependencies
> between project with external properties that defines versions. I guess you
> know one of the main objectives of maven is letting users be able to have an
> always reproducible build.
While a desire to have the build reproducible is OK, I am just questioning if a
tool should enforce it by removing flexibility. Going this way we will end up
forbidding dependencies on snapshots (cause somebody could have uploaded a
broken snapshot to the repo) ? Or force the snapshots to be uniquely identified
?
I am not externalizing dependencies to 3rd party stuff - only to siblings
projects. And this is my responsibility to keep versions of sibling projects
consistent. In the end, it is my CI process responsibility to check if the
project can be built, and the changes introduced in such "mixed" branches can
be built.
Actually, at the moment the only place such "dynamic deferred dependency
binding" is used, is in snapshot dependencies on sibling projects in
development branches (and trunk). So the build is unstable by definition
(depending on snapshot). When tagging I will anyway use a script to replace
<version>${some.version}<version> with <version>RELEASE-X.Y.Z<version> in all
the pom.xml's.
> I suppose you version the properties used to tag along the project itself? If
> not, then you're out of luck IMO.
Yes, the version related properties (and SCM paths inferred from them) are kept
in SCM. Actually, in profiles.xml next to the aggregator project pom.xml.
The properties in profiles.xml are used also in CI to checkout sources to
workspace from SCM (I have a Hudson SCM plugin that uses an (Ant) script to
implement checkout operation, and I think I will make it public soon).
When tagging there is no danger anyway - the sources are moved to /tags, so
whatever branch they were originally does not matter. The SCM path will be
changed to ..../tags/some_tag anyway, and the version properties will be set to
the release version ID the tag is connected to. This is why we are tagging,
don't you think? We do not rely on some file to keep information that we
released code based on revision @7890 - we just do svn copy
http://xxxxxx/svn/tr...@7890 http://xxxxxx/svn/tags/RELEASE-X.Y.Z
The problem is more generic anyway, cause for now I had problems to inject
version properties - the unchanged maven is not propagating properties set in
local profile when reading dependencies pom's from repository - so the
properties are not substituted anyway in transitive dependency designators. I
could pass them with -Dxxx=yyy but it is not the most convenient way (well,
there is nothing to prevent me to change the mvn.sh to read some pom.properties
and inject them to Maven, but then there is a question how to handle this in
embedded environments - like m2eclipse, without patching them all ).
In the long term I ask for introducing a notion of some kind of global
profiles, with a semantics that such global profile can define properties that
are used in every aspect of the process. I think it could be something as
simple as <global>true</global> in a profile definition, that would trigger
special behaviour (that the profile is injected to every pom.xml, say a
dependency pom read from repository). From my perspective the profile is OK to
hold only properties, not plugin config or dependencyManagement or anything
else, but it is an open question what should be allowed in such special
profile. We could also use a separate file for that (global_profile.xml ;), but
it is not necessarily best.
Such behaviour is not available anyway for now - so I have patched Maven to
treat profiles with some ID specially (inject them globally) (something like if
(profile.getId().contains("my_magic_string")) injectProfile(profile) - this is
oversimplification, of course, cause I need a way of propagating the "global"
profiles to other pom's, and current 2.2.x API actually do not pass
ProfileManager instance to every place I would like to use it in).
This would not break any existing build (cause no existing build would contain
<global> set to true ;). And will allow special cases (like mine). The
responsibility for the build belongs to build manager in the end, so I don't
think Maven team should go too far in restricting people from doing those
"evil" things. Forbidding an expression in version, or actually any other part
of the pom, is that one step too far.
Regards,
Krzysztof Trojan
----------------
From: [email protected] [mailto:[email protected]] On Behalf Of Baptiste MATHUS
Sent: 12 March 2010 14:22
To: Maven Users List
Cc: Trojan, Krzysztof
Subject: Re: Maven 3.0 Artefact/Dependency version discussion request
Answering putting Krzysztof in copy. But please, subscribe to the users maven
list, because not sure everybody will think about clicking on "reply all".
Well, if I read correctly what you said, you're putting the dependencies
between project with external properties that defines versions. I guess you
know one of the main objectives of maven is letting users be able to have an
always reproducible build.
When externalizing versions between dependencies, how can guaranty that if you
extract a version two years after an scm tag, you'll be able to build it?
I suppose you version the properties used to tag along the project itself? If
not, then you're out of luck IMO.
Can you explain a bit more what is your use case for proceeding this way?
Cheers
2010/3/10 Jason van Zyl <[email protected]>
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.acme:BigBankingProject:jar:${BigBankingProject.module.version}
> [WARNING] 'version' contains an expression but should be a constant. @
> com.acme.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
_____________
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.
_____________
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
