[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [birt-dev] [dtp-dev] datatools org.apache.lucene dependency

[cc'ing WTP and David in -- trying to avoid spamming cross-platform if possible]

WTP,  have you seen any issues with the dependency below?

 
It is indeed a mystery on what got changed recently that would lead to the issue.  The related changes in DTP were done back in January.
So it seems that the Buckminster build step does not allow building with different versions of a bundle?
 

Yeah, I *think* it is something like that. Buckminster grabs everything that it thinks it needs, and in fact it actually correctly grabs both versions, but then it fails when it actually goes to build it. I'm hoping that Thomas can shed some light on this and what might be done about it.  

 
Which BIRT components do you need to pull in?  How about the other existing BIRT features, like o.e.birt.chart.osgi.runtime or o.e.birt.chart ? 

We actually only use 

      <import plugin="org.eclipse.birt.chart.engine"/>
      <import plugin="org.eclipse.birt.chart.device.extension"/>
      <import plugin="org.eclipse.birt.chart.device.swt"/>
      <import plugin="org.eclipse.birt.chart.engine.extension"/>
      <import plugin="org.eclipse.birt.chart.ui"/>
      <import plugin="org.eclipse.birt.chart.ui.extension"/>

Along with their dependencies, of course. What I think I'm going to try next is to change my build time dependencies so that rather than grab the entire birt feature I try to grab all of the plugin dependencies individually, but I'm not sure that's the most robust way to go about this.

Presuming I can get it to build, I'm trying to think of whether that will create any provisioning time issues, but I guess that worst case the aggregator build will let us know.

On Jun 6, 2011, at 7:57 PM, Linda Chan wrote:

Miles,
 
It is indeed a mystery on what got changed recently that would lead to the issue.  The related changes in DTP were done back in January.
So it seems that the Buckminster build step does not allow building with different versions of a bundle?
 
I'd verified that the o.e.datatools.sqldevtools.results.feature in DTP 1.9 RC4 (e.g. in http://www.eclipse.org/downloads/download.php?file=/datatools/downloads/drops/N_DTP_1.9/dtp-p2repo-1.9.0RC4-201106031406.zip)
does explicitly specify the 1.9.1.* version of org.apache.lucerne. 
 
The o.e.datatools.sqldevtools.results.feature is required by o.e.d.sqldevtools.sqlbuilder.feature,
which is in turn required by the o.e.birt feature.
 
Which BIRT components do you need to pull in?  How about the other existing BIRT features, like o.e.birt.chart.osgi.runtime or o.e.birt.chart ? 
 
I'm not sure about +n dependency on BIRT in Indigo.  BTW, WTP also has dependency on DTP.
 
Linda

From: dtp-dev-bounces@xxxxxxxxxxx [mailto:dtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Miles Parker
Sent: Monday, June 06, 2011 7:06 PM
To: For developers on the BIRT project
Cc: Thomas Hallgren; dtp-dev@xxxxxxxxxxx
Subject: Re: [dtp-dev] [birt-dev] datatools org.apache.lucene dependency


Hi Linda,

[Thomas, I'm cc'ing you in, hope you don't mind.]

Thanks for the link. And it makes more sense now since these changes are recent but OTOH I don't know why they took a couple of months to show up.  It's a mystery is why this showed up now as opposed to earlier in the RC cycle. This wasn't an issue until the build this week. The issues I am having are with the Buckminster build step. It appears that the initial resolution works properly but then it fails because the PDE resolver is unable to locate the bundle. Therefore we end up with this error:


INFO:  perform '--properties' '/opt/users/hudsonbuild/workspace/amp-nightly/buildroot/build.properties' '-Dbuckminster.reference.repository=https://hudson.eclipse.org/hudson/job/amp-nightly/lastSuccessfulBuild/artifact/amp.p2.repository/' 'org.eclipse.amp.build#build'
CSpec org.apache.lucene:osgi.bundle$2.9.1.v201101211721 has no  action, group, or local artifact named java.binaries

Please see this thread for more details on the specific issue:


This is a dilemma as obviously you have functionality dependent on this, but I can't build my components without this dependency. Unless there was a chart runtime or BIRT core feature somewhere. Again, I don't actually need any of the datatools stuff but it all gets brought in as part of the BIRT feature.

Are you aware of any other release train projects that have a +n dependency on BIRT?

thanks for your quick response and cheers,

Miles


On Jun 6, 2011, at 6:34 PM, Linda Chan wrote:

Miles,

The o.e.datatools.sqltools.results bundle intentionally uses the 1.9.1 version of org.apache.lucene.  That is why the 1.9.1 version is included in the DTP Indigo release distribution.  See comments in https://bugs.eclipse.org/bugs/show_bug.cgi?id=333514#c14 and onwards.

Is the 1.9.1 version of org.apache.lucene installed in your test environment?  What exactly is the issue that you encountered?

Linda

-----Original Message-----
From: birt-dev-bounces@xxxxxxxxxxx [mailto:birt-dev-bounces@xxxxxxxxxxx] On Behalf Of Miles Parker
Sent: Monday, June 06, 2011 6:20 PM
To: birt-dev@xxxxxxxxxxx
Subject: [birt-dev] datatools org.apache.lucene dependency

Hi folks,

There has been a dependency issue with DTP but naturally it only actually started failing today, two days before the release train. I'm not sure if the failure is something introduced by a build change, but I don't think it is.

Here's the problem:

o.e.datatools.sqltools.results specifies org.apache.lucene 1.9.1, but every other eclipse project using it uses 2.9.1

Normally that would be ok, but IIRC there *are* issues with whole number differences even for non-singleton plugins.

I'm wondering if you would be able to take a look at sqltools and see if 1.9.1 really *is* necessary and if not do a quick change, build and promote. In the meantime I'm trying to determine a work around. (I don't actually need all of this, but it is the only way to get it because IIRC there isn't a separate feature for the chart runtime.) I haven't filed a bug yet because it seems more appropriate to work out these dependency issues pair-wise and of course we're really under the gun here.

thanks,

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

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