Bugzilla – Full Text Bug Listing
| Summary: | Provide a Maven 2 build | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Mark Hobson <hello> | ||||||||
| Component: | Mylyn | Assignee: | Mylyn Inbox <mylyn-inbox> | ||||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P4 | CC: | dev, mbeerman | ||||||||
| Version: | unspecified | Keywords: | helpwanted | ||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Mark Hobson
For what you described all you need is Mylar's task API jars available from some Maven's repository (ibiblio, etc). At a minimum, yes, although Mik was suggesting it'd be best to build the JARs using Maven to ease future maintenance [1]. [1] http://mail-archives.apache.org/mod_mbox//maven-dev/200607.mbox/%3c002f01c6a1d3$00ac96c0$6700a8c0@beatmik%3e Is anyone interested in contributing these pom.xml files? I don't see a problem in taking them in as contribution, as long as we have some mechanism for knowing when they break since internally our build is PDE-based and not Maven based. Created attachment 70901 [details]
POMs for core components
I wanted to see this get done, so I went ahead and did it myself. :) I've attached POM files for each of the core components. They should produce identical endstates to the existing Ant-based builds. To verify, you can:
1) Drop the POM file into each project's respective root folder.
2) Install Maven, and run "mvn package" from the project root folder.
3) Examine the .jar file that was created in the /target folder.
Note that these POMs are all intended for the e_3_2 branch. For reasons too complex to get into here, Maven doesn't play very well with Eclipse's unreleased endstates (e.g. 3.3), if they're even available to Maven at all. So, I stuck with the latest stable endstates from Eclipse.
Er, just noticed one typo: those should probably all be <version>2.0-M3</version>, since it looks like you haven't actually released 2.0 yet. Thanks Matthew, that's a good start. I will need this patch to be made against head in order to apply it, since we take patches against HEAD. Also, the 3.2 branch still needs a ton of updates for the rename (bug 191406) and is in flux. When you make the patch, if possible it should be a patch file instead of a Zip. Also, it would be create if you could create POMs for each of the project and describe any overhead needed with maintaining them, since we do not have an internal driver that would ensure they are up-to-date. Also, please note that I will have to wait until next week in order to apply this patch due to the rename and our upcoming RC1. I won't be able to create POMs for the HEAD until after Europa is released and uploaded to Maven's central repository. However, that should be Real Soon Now, so feel free to hold off on this until then. Sounds good, that timing would work well on our end too. Created attachment 73469 [details]
Updated POM files
Okay, here they are again in patch form, updated so that they apply against the HEAD and the Europa release.
The overhead in maintaining them is that you must ensure they remain more or less in synch with the MANIFEST.MF file. The format of a POM is fairly self-explanatory; let me know if the contents don't make sense.
Matthew: could you please create a Unified/Workspace (Eclipse patch wizard settings) patch for these? I need a patch in order to apply this since that is Eclipse convention. Created attachment 73477 [details]
Third time's the charm?
Sure, no problem. I've never submitted a (multi-project) patch to Eclipse before, so I'm still getting the hang of this. :)
Patch applied, thanks Matthew. I've added this on an experimental basis because it is not yet clear how these pom's will be maintained since we have no internal drivers for them and no one explicitly committed to supporting them. But let's try this and see if it encourages community maintenance of them or if the project ends up depending on them internally. If not, we should consider removing them because they contain information that is redundant with Eclipse-based build descriptions (e.g. build.properties) and would be confusing to have stale versions of. Matthew: could you please add some of your instructions on how to use this to the wiki? http://wiki.eclipse.org/index.php/Mylyn_Contributor_Reference#Tips_and_Tricks Also, are you considering adding POMs for the othe rprojects or just interested in seeing them for the headless parts for now? We do not have resources for maintaining POMs since they are not used internally. If there is a real need for consumers using POMs straight out of Mylyn CVS there may be a way to integrate them into our upcoming build process automation (bug 108291) but I worry that they will be out of synch, and that some approach that automatically generated POMs from plug-ins would be more robust. |