Community
Participate
Working Groups
To promote maintainability of the Eclipse-RPM core, I suggest that we do a bit of refactoring in org.eclipse.cdt.rpm.core for the 3.0 release. I will attach a brief UML diagram that outlines my proposal.
Created attachment 16929 [details] UML diagram representing refactored org.eclipse.cdt.rpm.core I think that the design represented by this UML diagram further simplifies the RPM core by removing inheritance relationships and replacing them with composition. In addition to this diagram, a new package org.eclipse.cdt.rpm.utils will be created in the core plug-in to host command classes for rpm, rpmbuild, chmod, diff, etc. This design is similar in concept to org.eclipse.cdt.utils, which could be used as a reference implementation.
Targeting for 3.0.
As discussed in the weekly meeting -- all enhancements requests that had a target milestone of 3.0 but were assigned to an inbox owner (which is an invalid combination), have been moved to Target Milestone "--".
Created attachment 21390 [details] Patch for org.eclipse.cdt.rpm-feature
Created attachment 21391 [details] Patch for org.eclipse.cdt.rpm.core
Created attachment 21392 [details] Patch for org.eclipse.cdt.rpm.core.tests
Created attachment 21393 [details] Patch for org.eclipse.cdt.rpm.ui
I've checked in the newly-attached patches - I've been back hacking on RPM stuff lately and completed the rpm.core refactor. No new functionality has been added with this change, but we now have a defined API for future expansion. Some notable issues: - The new API does not allow you to export S/RPMs from projects that have not been previously imported into. This area of the old rpm.core was a bit flakey, and until we have a more advanced spec file model better parsing support for spec files, its use is quite limited anyway. - The new API does not rename source tarballs if the user changes the version number. I believe this behavior aligns better with the RPM workflow mantra of keeping pristine source artifacts. - The new API adds a special RPM nature to projects on source RPM import. - The default RPM directories (for RPMS, SRPMS, BUILD, SPECS, and SOURCES) are now created in the project itself (as derived resources) instead of being held externally. This allows us to use the Eclipse Platform APIs for resource manipulation and removes the need to use platform-dependent utilities for operations like copying resources. Also, I think it is better from a user point of view to have all RPM resources right in the project itself. - The RPM property page implementation has been removed from the RPM feature temporarily. I will address this in bug #82196.
I've set the iplog flag to + on all these attachments from Jeremy since he committed them. Somehow in the shuffle from CDT to Linux Tools his committer rights got lost so it's best to have his contributions noted in our IP Log than sitting in limbo.
