Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-dev] Reproducible version qualifier without Git-based timestamp

Early dependency resolution is a long standing tycho design bug and
bugzilla 353889 [1] covers the work to address it. I believe proper
solution will require new dependency resolution hooks in maven core, but
I have not had time to look at this in any details.

My recommendation is to postpone any further work on the new reproduce
build qualifier until dependency resolution rework has been complete.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=353889

--
Regards,
Igor

On 2013-09-20 11:46 AM, Mickael Istria wrote:
On 09/19/2013 01:22 AM, Igor Fedorenko wrote:
Iteration #2: Make it useful without breaking anything
* Implement a compatible-version-with-same-content strategy, comparing
content of bundles with same x.y.z (ignoring qualifier) and replace by
baseline when there is no change worth producing a new bundle.
At the end of this iteration, we should be able to consume "compatible"
bundles from baseline just by setting
baselineStrategy="compatible-version-with-same-content"

Now thinking about this, what you want may require massive changes to
how dependency resolution works and it may be a good idea to wait until
we fix move dependency resolution to proper build phase.

Currently all build fully qualified versions are determined and all
dependencies are resolved before the actual build starts. If later
during the build project artifacts are replaced with baseline and get
different fully qualified version, I this there is currently no
mechanism to propagate the new version of other projects that depend on
this one.

As you foresaw, I'm facing this issue.
Changing the qualifier breaks dependency management since it introduces
new p2 artifacts that are not the same as computed earlier. Early
dependency resolution seems necessary to decide the order in which one
modules should be built, but the concrete resolution of the p2 IU for
reactor modules could probably happen later. We could think of
introducing "lazy dependencies" in early-computed target platform which
are good enough to resolve build order but for which one concrete
artifact/qualifier is meant to be computed while starting to build the
module depending on them.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>


_______________________________________________
tycho-dev mailing list
tycho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-dev



Back to the top