On jeudi 22 janvier 2009 12:08:54 Daffin, Miles (IDEAS PRACTICE AREAS) wrote: > Nicolas, > > When I install Apache IvyDE and Apache Ivy features into eclipse 3.3 with > the old update manager I see a red X on the Apache Ivy feature in the > Product Configuration manager dialog (Help > Software Updates > Manage > Configuration) - although the plugins all seem to function OK. However, as > an experiment I killed my 3.3 install and edited the > org.apache.ivy_2.0.0.final MANIFEST, removing the timestamp from the > Bundle-Version. Guess what: the red X disappears from in the aforementioned > dialog... > > The Bundle-Version *must* be being used to identify things. If you add a > timestamp to it in the MANIFEST.MF/Bundle-Version then Eclipse 3.3 and 3.4 > get confused: the identifier 'org.apache.ivy_2.0.0.final_timestamp' is like > a null pointer. It is not just a matter of conventions. Like I said: this > is causing p2 metadata generation to fail for this feature. > > I understand your reasons for wanting to use a timestamp, I just think you > are putting it in the wrong place. How about another manifest attribute > (Created-On?). Either that or you need to use the time stamped version > everywhere, consistently.
The problem with putting it somewhere else is that then Eclipse won't be able to compare two different builds of the same targetted version. The problem it make the difference between a 2.0.0.final being actively developped and the 2.0.0.final officially released. The one released is clearly defined, only one exist. But the ones build before have to be understand by Eclipse as older than the officially released one. So here comes the timestamp in the bundle version. I don't see any other way to accomplish it. And Eclipse plugins are versionned exactly the same way. For instance in my eclipse install I have: org.eclipse.core.resources_3.4.1.R34x_v20080902.jar org.eclipse.core.resources.compatibility_3.4.0.v20080604-1400.jar org.eclipse.core.runtime_3.4.0.v20080512.jar org.eclipse.core.runtime.compatibility_3.2.0.v20071008.jar org.eclipse.core.runtime.compatibility.auth_3.2.100.v20070502.jar So maybe the issue is only about the file name. Did you try to rename the jar instead of removing the timestamp ? Nicolas > > Cheers, > > Miles Daffin > Morgan Stanley | IDEAS PRACTICE AREAS > 20 Cabot Square | Canary Wharf | Floor 01 > London, E14 4QW > Phone: +44 20 7677-5119 > Fax: +44 20 7056-4572 > [email protected] > > -----Original Message----- > From: Nicolas Lalevée [mailto:[email protected]] > Sent: 21 January 2009 09:51 > To: [email protected] > Subject: Re: Error in org.apache.ivy plugin MANIFEST? > > On mardi 20 janvier 2009 14:51:40 Daffin, Miles (IDEAS PRACTICE AREAS) wrote: > > Hi Folks, > > > > I was having some problems generating viable p2 metadata for an > > internal mirror of the IvyDE update site. I eventually tracked this > > down to what seems to be an error in the MANIFEST for plugin > > org.apache.ivy_2.0.0.cr2. The plugin version is 2.0.0.cr2 but the > > Bundle-Version in the MANIFEST is 2.0.0.cr2_20081028224207. When I > > removed the timestamp from this the p2 metadata generator > > application<http://wiki.eclipse.org/Equinox_p2_Metadata_Generator> > > generated viable metadata: I was able to install Apache IvyDE and > > Apache Ivy from the internal mirror. > > > > Can this timestamp be removed from the attribute? Is it there > > intentionally/for a reason? Please let us know. > > The timestamp is usefull for ordering the builds, make Eclipse understand > there are different versions and how to order them. It is also the case for > the JDT plugins too. > > But yeah there might be an issue here. The convention is to have the jar > file named $bundleSymbolicName_$bundleVersion.jar. But maybe it is more > than just a convention ? > > Nicolas > > > Thanks, > > > > Miles > > > > Miles Daffin > > Morgan Stanley | IDEAS PRACTICE AREAS > > 20 Cabot Square | Canary Wharf | Floor 01 London, E14 4QW > > Phone: +44 20 7677-5119 > > Fax: +44 20 7056-4572 > > [email protected]<mailto:[email protected]> > > -------------------------------------------------------- > > > > NOTICE: If received in error, please destroy and notify sender. Sender > > does not intend to waive confidentiality or privilege. Use of this > > email is prohibited when received in error. > > -------------------------------------------------------- > > NOTICE: If received in error, please destroy and notify sender. Sender does > not intend to waive confidentiality or privilege. Use of this email is > prohibited when received in error.
