maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baptiste MATHUS ...@batmat.net>
Subject Re: Maven 3.0 Artefact/Dependency version discussion request
Date Fri, 12 Mar 2010 13:21:51 GMT
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 <jason@maven.org>

> The user list is here users@maven.apache.org and you can subscribe to
> discuss your issues using users-subscribe@maven.apache.org.
>
> 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
> > krzysztof.trojan@fnis.com
> > 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
> ----------------------------------------------------------
>
>


-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message