Cool, thanks Wenfeng and Martin.
I'm sure there aren't any backward compatibility issues with BIRT -- I've never run into one yet, which is exactly why it would be silly to lose backward compatibility with Helios. Sensible users often try out the latest and greatest of one tool or another but want to stay with the stable versions of other tools, and it's good for us to think about ways to enable that. I think the idea of using a version range is a good one -- I was being lazy and just leaving it totally unspecified which prob. isn't a good idea either. I still can't figure out where the version requirement crept in at all in fact. That was the last minute arghh moment for me tonight. :) "Why does my P2 site suddenly think it needs 2.6.1.blahblah when I never specified that?" Perhaps I just missed something somewhere, but its got me puzzled.
I was more curious about where the BIRT build itself occurs. It's been extremely helpful for me to look at other project's build configurations. As far as consuming goes, I've been able to finally get to the stage where all of my dependencies are supplied by P2 which is really nice. :)
On Dec 15, 2010, at 10:42 PM, Wenfeng Li wrote: Hi, Miles BIRT 4.0.x will try to maintain API compatibility with BIRT 2.6.x. If you run into any API incompatibility, please log a bug for us. And thanks for pointing out it is difficult to find the latest BIRT Indigo build. We will add a section in BIRT's main download page for latest M builds.
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin [Martin.Oberhuber@xxxxxxxxxxxxx]
Sent: Wednesday, December 15, 2010 10:18 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Non indigo dependencies
Hi Miles, what about allowing a wider version range in your dependencies, when you know and test that it works on both "old" and "new" BIRT ? Eg Require-Bundle: birt[3.0.0,5,0.0) You could develop against the old BIRT in your workspaces, but build and test against the new BIRT. That way, you'll detect source compatibility issues for sure, and you'll find most binary compatibility issues. You'll run into trouble when any API you need changes in a non compatible way - but you'll detect and notice that case. Often, a major version bump only affects part of the API so the subset you need might still be compatible. Thanks, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River direct +43.662.457915.85 fax +43.662.457915.6
Thanks David,
Essentially I guess this means that we can't use earlier major version dependencies at all? That would mean that in turn our provisioned code won't be able to be used from pre-Indigo releases either..but I can certainly see the logic re: moving things forward. But there does seem to be a cost in backward compatibility as grabbing everything from Indigo means that you can't specify an older stable release for a dependency.
Anyway, it no knock on BIRT, it's our issue as we would have resolved it already if we'd hopped on earlier. BIRT simply has a tremendous number of dependencies so when they change, a lot of AMP build has to change. This was the point I was trying to get to with earlier posts re: Buckminster rmaps and p2 sites.. It is *not* enough to simply add a P2 update site for the distribution you want to use, you have to edit the locators for all of the dependencies as well. Or.. you could use the Indigo aggregator and ignore all of the project update sites..aha, the light dawns -- I see the wisdom in forcing people to get into the aggregator now!
Still, I'm concerned about how I'm going to provision for my Helios users as well as Indigo early adopters. I suppose I could maintain a "Helios"-based release build as well but that's a lot of extra maintenance.
cheers,
Miles
On Dec 15, 2010, at 9:37 PM, David M Williams wrote: Yes, indigo dependencies only.
Sounds like your "minimal feature" is the only option for you, for M4, and shortly after M4 you can start to get "caught up".
I'm not sure when BIRT changed to 4.0, but hopefully it wasn't just this last week. What most projects do is "build against" their pre-reqs directly from their pre-reqs downloads several weeks ahead of time as "warm up", so there is some time to adjust to version changes.
I'll confess, It took me longer than I thought it would to find BIRT's Indigo builds, but did after 3 or 4 minutes, looking at 3 or 5 sites. But did find some at
http://download.eclipse.org/birt/downloads/build_list.php
and does seem as though they were at "4.0" level for previous milestone (M3).
Good luck.
From: Miles Parker <milesparker@xxxxxxxxx>
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: 12/15/2010 11:49 PM
Subject: [cross-project-issues-dev] Non indigo dependencies
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
Is it the case that we can't rely on *any* dependencies outside of the Indigo site, including one's that are available under Helios? Everything works fine for a test install in Indigo M4 as long as Helios is available but otherwise it fails.. BIRT (+2?) has done a major version jump and when I try to install into an Indigo releases target based the install fails because no compatible (2.6.x) is available. These aren't my versionings, they come from the build. It doesn't look like the BIRT build is even on Hudson so I can't track that down right now, but there are a bunch of changed build time dependencies there including wtp, dtp, etc.. so it's going to be a big hair ball to untangle the rmap, etc.. So if I can't find a good location for earlier BIRT, my only other option is to get rid of my BIRT dependencies for M4 altogether and put out a minimal feature.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
