I want to un-retire then Eclipse EMF package so we can get webtools and datatools and other nice goodies into Fedora. It's effectively a new package though since the eclipse-emf directory in CVS is empty and it hasn't been in the last few releases of Fedora. Spec URL: http://mbooth.fedorapeople.org/reviews/eclipse-emf.spec SRPM URL: http://mbooth.fedorapeople.org/reviews/eclipse-emf-2.4.1-2.fc10.src.rpm Description: The Eclipse Modeling Framework (EMF) allows developers to build tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Notes: - Because of changes to Eclipse between F9 and F10, this package will probably only build on F10+. - AOT compilation is disabled due to bug #477707. - The patches included in this package are to get it to build in our environment (mostly to do with javadoc generation), no actual code has been changed from upstream. - It's probably also worth discussing the fact that the SDO sub-packages will disappear in the next major release, which will be for the Eclipse 3.5 coordinated release. I thought about maybe bundling SDO into the main EMF packages so that no-one ends up depending on a package that will be retired next year. (Or perhaps not packaging it at all for this release.) I'd be grateful for thoughts and opinions on this. Thanks for your time.
+1. I might be able to help w/ this. Andrew Overholt's already spoken to me about helping out on this, as I'm an EMF committer and newly minted JBoss employee. Note that getting EMF, XSD, WebTools (and optionally, BIRT, DTP and TPTP) into Fedora would also enable JBoss Tools' deployment via .rpm in Fedora.
I would appreciate your input. I will also be working on webtools and datatools packages, hopefully very soon.
Hi Mat, If you start working on webtools, would you mind creating a list of all the dependencies and their state in Fedora? A wiki page would be nice. This will allow others interested (like me) to help with a package or two.
One quick way to see what depends on what (minimums) is to pick a feature to install and let Eclipse 3.4.1 install it. When it's done, you'll see that feature, its included subfeatures and plugins, and any dependent features/plugins required for it to run. Creating the visual tree of dependencies can be done (for plugins only, anyway) using something like this: http://www.eclipse.org/pde/incubator/dependency-visualization/index.php
Alex, have you and Mat spoken about rpmstubby?
FWIW it's probably safe to remove the gcj AOT bits since the Eclipse platform doesn't contain these bits.
Also (and sorry for the multiple comments), you'll probably want to check out: http://cvs.fedoraproject.org/viewvc/rpms/eclipse-emf/F-7/eclipse-emf.spec?revision=1.7&view=markup to verify you've properly Obsolete'd and Provide'd.
(In reply to comment #6) > FWIW it's probably safe to remove the gcj AOT bits since the Eclipse platform > doesn't contain these bits. Fair enough. AOT doesn't work for this package anyway. (In reply to comment #7) > Also (and sorry for the multiple comments), you'll probably want to check out: > > http://cvs.fedoraproject.org/viewvc/rpms/eclipse-emf/F-7/eclipse-emf.spec?revision=1.7&view=markup > > to verify you've properly Obsolete'd and Provide'd. Aha, thanks. I see I have some work to do here.
Spec URL: http://mbooth.fedorapeople.org/reviews/eclipse-emf.spec SRPM URL: http://mbooth.fedorapeople.org/reviews/eclipse-emf-2.4.1-3.fc10.src.rpm What I did was make the package names the same as what they used to be, with the exception of the standalone package, which I obsoleted because upstream removed support for it in EMF 2.3. (See http://wiki.eclipse.org/EMF/EMF_2.3/Standalone_Zip_Removal)
Re: comment #9 (spec URL) Your spec file has: Name: eclipse-emf but then later %package sdo-sdk Should the %packages also have the "eclipse-" prefix so that they can be easily found with `yum search eclipse`? (Forgive this newb question.) BTW, SDO is deprecated in the current release of EMF 2.5 (under development, due June 2009), so for Fedora 12, you might want to build a package for the Apache Tuscany SDO project as a replacement. http://wiki.apache.org/ws/Tuscany/TuscanyJava/SDO_Java_Overview
(In reply to comment #10) > Re: comment #9 (spec URL) > > Your spec file has: > > Name: eclipse-emf > > but then later > > %package sdo-sdk > > Should the %packages also have the "eclipse-" prefix so that they can be easily > found with `yum search eclipse`? (Forgive this newb question.) > They are given the "eclipse-" prefix by default. :-) (To specify otherwise, you have to use %package with the -n flag.) > BTW, SDO is deprecated in the current release of EMF 2.5 (under development, > due June 2009), so for Fedora 12, you might want to build a package for the > Apache Tuscany SDO project as a replacement. > > http://wiki.apache.org/ws/Tuscany/TuscanyJava/SDO_Java_Overview I don't really use SDO (and I'm not aware of anything in Fedora that does). Is that a straight drop-in replacement? I was just planning on Obsoleting it when Andrew packages Eclipse 3.5 and just letting it die.
(In reply to comment #11) > I don't really use SDO (and I'm not aware of anything in Fedora that does). Is > that a straight drop-in replacement? I was just planning on Obsoleting it when > Andrew packages Eclipse 3.5 and just letting it die. That's an even better solution. :) I haven't used Tuscany, but I've heard some less than favourable reviews. It's not a direct drop-in replacement; I believe it implements an updated version of the SDO spec. I just figured if you needed something to replace it, this would be the best option. But really, I suppose it depends on the community's interest and request. Let it die, and if no one complains, then I guess no one wants or needs it.
I'll take this review. Everything looks good to me. I have a few questions: - does this comment mean we have reduced functionality? "... these files aren't needed for source plugins; they are only needed "so the example-installer plugins can create full projects in your workspace)" - could we match upstream's qualifier instead of that of the build? I worry this will give multilib conflicts since the builds on x86_64 and x86 will happen on different machines without the same hour and minute. If we can't match upstream's qualifier (in the case they're all different), just set it to something sane so all arches end up the same. - why not use separate dropins directories for the sub-packages? This gives a much cleaner %files section Thanks.
As for the FIX rpmlint shows no warnings The only one is this: eclipse-emf.noarch: W: obsolete-not-provided eclipse-emf-standalone I think we need a Provide there as well (see http://fedoraproject.org/wiki/PackagingDrafts/ProvidesObsoletes) OK package named correctly OK spec file named correctly OK meets the Packaging Guidelines (except for above) OK license is correct, approved and in %doc OK license field in the package spec file matches the actual license OK shell script for fetching sources is included OK package MUST successfully compile and build into binary rpms on at least one primary architecture (I tested x86_64 but it's noarch ...) OK md5sum of my fetched tarball doesn't match yours but that's just timestamps; diff -r gives no output OK owns all directories OK doesn't contain any duplicate files OK permissions are correctly set OK clean section present OK uses macros consistently OK package contains code OK no large documentation files OK if a package includes something as %doc, it must not affect the runtime of the application. OK packages must not own files or directories already owned by other packages. OK %install MUST run rm -rf %{buildroot} OK all filenames must be valid UTF-8
Hi Andrew, thanks for taking the time. (In reply to comment #13) > I'll take this review. > > Everything looks good to me. I have a few questions: > > - does this comment mean we have reduced functionality? > > "... these files aren't needed for source plugins; they are only needed > "so the example-installer plugins can create full projects in your > workspace)" > No, nothing is lost. I will change that comment to be clearer. The files are still included such that they are present when you create the sample plugin projects in your workspace. (They are merely omitted from the associated source plugins of the sample plugins in the same way they are omitted from the associated source plugins of all other regular plugins.) If that makes any sense. To see what I mean just try creating some of the EMF sample plugins projects through the new example wizard and making sure the .project/.classpath files get created. > - could we match upstream's qualifier instead of that of the build? I worry > this will give multilib conflicts since the builds on x86_64 and x86 will > happen on different machines without the same hour and minute. If we can't > match upstream's qualifier (in the case they're all different), just set it to > something sane so all arches end up the same. I'm not sure I understand the multilib concern; this is a noarch package. It's no bother to change the qualifier though. Does it have any significance above being just the time it was built? > - why not use separate dropins directories for the sub-packages? This gives a > much cleaner %files section > No real reason beyond keeping the directory structure the build process gave me. (The resulting zip expands neatly into a single dropin directory during %install.) I can change it if you'd prefer. (In reply to comment #14) > As for the > > FIX rpmlint shows no warnings > > The only one is this: > > eclipse-emf.noarch: W: obsolete-not-provided eclipse-emf-standalone > > I think we need a Provide there as well (see > http://fedoraproject.org/wiki/PackagingDrafts/ProvidesObsoletes) > Erm, yeah. It was after reading that link that I decided that we *don't* need a Provides there because we no longer provide the files that the obsoleted package provided in a compatible way. From that article: "if a package supersedes/replaces an existing package without being a compatible enough replacement as defined in above, use only the Obsoletes". That way of using EMF is genuinely obsolete and no longer supported upstream (and I don't believe there are any packages in Fedora that depend on it anyway). Is it really necessary to Provides it?
(In reply to comment #15) > (In reply to comment #13) > > I'll take this review. > > > > Everything looks good to me. I have a few questions: > > > > - does this comment mean we have reduced functionality? > > > > "... these files aren't needed for source plugins; they are only needed > > "so the example-installer plugins can create full projects in your > > workspace)" > > > > No, nothing is lost. I will change that comment to be clearer. The files are > still included such that they are present when you create the sample plugin > projects in your workspace. (They are merely omitted from the associated source > plugins of the sample plugins in the same way they are omitted from the > associated source plugins of all other regular plugins.) > > If that makes any sense. > > To see what I mean just try creating some of the EMF sample plugins projects > through the new example wizard and making sure the .project/.classpath files > get created. > Oh my gods, there's a reason I'm not a technical writer. What I mean is, the patch (rightly) excludes those hidden files from the build process that creates source plugins. They are still present however, when the sample plugins are bundled to become the sample workspace projects available from the new->examples wizard within eclipse. I think that's marginally clearer...
Hi Mat, :) I understand now about removing the . files - I generally like to match the qualifier of upstream as sometimes plugins have hard-coded full major.minor.micro.qualifier numbers of their dependencies. Ignore my silly multilib statement :) - as for the dropins structure, if you think you can keep the %dir and various sub-directories/files straight in the %files sections, feel free to keep it as it is. I just personally find it easier to deal with single lines in each %files section. Since you get one zip from the build, what you have is fine. - I think you're right about the Provides as well. I genuinely wasn't sure. This package is APPROVED. Thanks very much, Mat! This package is incredibly popular and will enable us to get many other packages in.
Thanks Andrew. I will change the qualifier, but I don't think I will change the %files section at this time since I know it works right now and is unlikely to have to change before the next coordinated release. I will revisit it then.
Package Change Request ====================== Package Name: eclipse-emf New Branches: F-10 Updated Summary: Eclipse Modeling Framework (EMF) Eclipse plugin Updated Description: The Eclipse Modeling Framework (EMF) allows developers to build tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. This package was previously dead, so please could you also check that the devel branch is set up correctly.
cvs done. If this package was blocked, you may need to file a rel-eng ticket to unblock it.
Built successfully for all requested branches, closing.