Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] How to avoid "Bundle ch.qos.logback.slf4j_0.9.24.v20100831-0715 failed to resolve.:" ?

> Thanks for investigating.
Indeed. Very helpful.


 > But this means hacking the build
> scripts again and for every time a new fragment comes along.

I'm not sure this is exactly true. The suggested hack of providing a second host (as a "dummy" host, just for the build) wouldn't require a change in build scripts. But, does seem like a hack, would be confusing, and seems we shouldn't do that, unless we had a known need to do it.

This does sound like a case where the retention rules are trumped by practical reality. I'm assuming if someone really needed the old one, it'd still be there in previous R-build, right?  And, if not in an R-build yet, then doubt they have a strong need for a lower level one. If you do go this route, Gunnar, (which is what I'd recommend) I do think you should post a note to cross-project, to let people know only one fragment will be in active Orbit builds, and if this causes a problem for anyone, to open a bugzilla in Orbit. And, you might remind them they might need to file a new piggy-back CQ for new version (as Hugues Malphettes reminded us).

I think this is a good case where "committer judgement" is important in deciding what to retain ... which is the main reason I wanted to change that retention policy a few months ago.

Thanks,
 




From:        Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
To:        Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
Date:        02/25/2011 02:54 PM
Subject:        Re: [orbit-dev] How to avoid "Bundle ch.qos.logback.slf4j_0.9.24.v20100831-0715 failed to resolve.:" ?
Sent by:        orbit-dev-bounces@xxxxxxxxxxx




Hi Andrew,

Am 25.02.2011 20:15, schrieb Andrew Niefer:
> It is a more restriction is that two versions of the same fragment can
> not attach to the same host.   This came from
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201489
>  Dev mode does not relax this restriction, and we aren't sure if it
> should since it doesn't make for a good build time classpath for other
> bundles depending on the host.

Thanks for investigating. The behavior is expected and wanted at
runtime. I'm just not what that means for the fragment in Orbit. Should
we ship both fragment versions in the same p2 repo? If yes that we might
need to implement the workaround. But this means hacking the build
scripts again and for every time a new fragment comes along.

-Gunnar

--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev


Back to the top