2010/3/12 Trojan, Krzysztof <[email protected]>
> 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 ?
>
Well, what you say is one of the foundation of maven. SNAPSHOT is designed
to change any time. So it's totally OK to develop with such version, and
that was designed for it. SNAPSHOT (or anything moving) is just forbidden
when releasing, which is thoroughly acceptable to me. We release a 25+
modules multi-modules project about once a month using the release-plugin.
We're always using a SNAPSHOT version to define dependency versions between
each others. When we release, all those SNAPSHOT must simply be removed and
be fixed (either manually if this is an externally managed project, or
automatically if the snapshot from a dependency which is in included in the
multi-module project).
So, no. Your example is not the right one. Because when a project has been
tagged, only release versions can be present in the pom.
Though I agree that flexibility is great, you can't have flexibility
everywhere. It always highers software complexity since you're basically
adding *if*s.
Making the build depend on external factor like changing version is just
something too important for maven opiniated design to allow, I guess.
Note I'm no maven developer, but I totally agree this is a good idea to
enforce this. I'm not saying this MUST not be flexible, but I think this is
not a use case where it should be.
> 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.
>
Not sure to understand precisely what you do. But it seems like what you do
is the kind of this handled gracefully by the maven-release-plugin. Did you
have a look at it? If yes, what doesn't correspond to your needs?
> > 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).
>
Well. I'm using hudson too to build our 25+ multimodules project, and also
build something like 15 multimodules projects (each containing between 5 and
15 modules I'd say). We never needed ant to checkout.
We also use hudson to trigger our release
>
> 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
>
>
Well, your release process seems very complicated. I suppose there are
reasons behind this complexity...
I'm also tagging quite often. But only use the release-plugin to do that.
And before using it, I released a lot of times without it. I always had
forgotten something (snapshot version left, scm tag not updated correctly,
sibling project version not-up-to-date, forgotten to go back to snapshot
version...).
> 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.
>
What would you do with such global profile when tagging? Are you sure your
need couldn't be achieved using a "corporate" pom? This way, you'd have a
clean way to know what the config was at a time, and so on.
IMO, the problem you're reporting has to do with the mantra of maven:
convention over configuration. Some find it too limiting, others like me
just finds it's kind of refreshing to not reinvent the wheel on each new
project.
Too much flexibility kills flexibility, I guess :-).
Cheers
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
