Bugzilla – Full Text Bug Listing
| Summary: | Building and testing Eclipse plug-ins with Maven2 | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | Peter Hagelund <phagelund> | ||||||||||||||||||||
| Component: | Articles | Assignee: | Wayne Beaton <wayne.beaton> | ||||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||||
| Priority: | P3 | CC: | Amgad.Mohamed, freter, hagelund, mguillemot, mike.haller, sebastien.arbogast, sumitg | ||||||||||||||||||||
| Version: | unspecified | ||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||
| Hardware: | All | ||||||||||||||||||||||
| OS: | All | ||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
|
Description
Peter Hagelund
Great! We're using Maven quite heavily at AndroMDA.org, but never have had the time to figure out how to build our Eclipse plug-ins with Maven inside our master build loop. Your approach not to change anythng for the ordinary developer sounds very promising. I volunteer to test drive the article against our plug-ins. +1 (In reply to comment #2) > +1 > Excellent! We'll get a draft put together over the next couple of weeks. Created attachment 51586 [details]
Draft one of the proposed article
As agreed, hereby the first draft. No screen shots yet; we'll do those last.
Great article! Hopefully you can solve the license questions soon. I'd like to integrate our Eclipse-related artifacts into our existing maven2 builds. Could you be more detailed while describing the Components configuration section? And another question for discussion: The artifactId can be mapped 1:1 to the pluginId or bundleId. However, the groupId is more like the featureId where a bundle is located. On the other hand, the multiple features can contain the same plugin. My question here is, what is best used for the groupId? My company? The vendor of the plugin? The featureId? A static string "eclipse"? Thanks Mike, And in short: I agree. I re-read the whole thing and we (as expected) have a few, shall we say, thin areas. We'll address those over the next couple of days or so and upload a draft 2. W.r.t. your specific questions around features, that is one thing we haven't thought about. We map the plugin's bundle id and version to the Maven2 artifact id and version, with whatever group id is appropriate for the project in question. We have not yet thought about what role, if any, features play in this. We also "scrape" a version of Eclipse for a given project; i.e. we don't put all of Callisto's plugins and jar in org.eclipse; rather we put it in com.princetonsoftech.foo.bar, so that the group of projects (plugins) in the foo.bar project(s) can depend upon that. We'll make sure this gets communicated more clearly in the next rev of the article. Thanks for your feed-back - stay tuned! /Peter (In reply to comment #5) > Great article! > > Hopefully you can solve the license questions soon. I'd like to integrate our > Eclipse-related artifacts into our existing maven2 builds. > > Could you be more detailed while describing the Components configuration > section? > > And another question for discussion: The artifactId can be mapped 1:1 to the > pluginId or bundleId. However, the groupId is more like the featureId where a > bundle is located. On the other hand, the multiple features can contain the > same plugin. My question here is, what is best used for the groupId? > My company? The vendor of the plugin? The featureId? A static string "eclipse"? > Created attachment 51971 [details]
Draft two of the proposed article
Hereby the second draft of the article. We've added screen shots of both code, POMs etc.
Created attachment 52953 [details]
Proposed article
Hereby the proposed article. Sorry about the delay on this, we had a few people do reviews since our brains by now read what they want to read ;)
Please look things over and let us know if this is OK or there are things you need us to tweak some more.
I read the article again and will forward them to my collegues, but as far as I can see, it's perfectly perfect. We're eager to get some free time here to try that out and integrate our eclipse plugins in our maven2 build process. Thanks Guys! Finally I found some time to read the article again. All in all, I like the idea of using Maven to build your Eclipse plug-ins very much. The article is already pretty good, but some things need to be tweaked :-) Here are some things to consider: - the maven guys talk about "Maven 2", not "Maven2" - I am a big fan of seeing the relevant code, but I'd suggest to not insert code as a screenshot but rather as a block of text - also, the screenshots of the manifest editor should be smaller - no use in seeing a void space. - You state that "If you would like to use convention over configuration (like any noble Maven2 user) install a Callisto release (the SDK) into your home directory". But why do I have to install it to my home directory? Is that your idea, or a maven requirement? Would be great if you could explain that in the article. - How about a flowchart depicting the whole process? You might want to consider breaking this article into two parts: one part explaining all the backgroudn stuff and how you wrote the mojos. The other part, being more of a user's guide should explain how to use the mojos. However, good work! I am really looking forward to getting the mojos so I can take it for a spin! Mike and Peter - thanks for so dilligently reviewing the article. All valid points and we'll remedy as suggested. The screen shots were used to break up the long flow of text - we figured that some shots would lighten things up; of course, you can't copy and paste from a png, so I see your point ;) Give us a day or two to tweak things and we'll upload again. If you don't mind, we'll also poke all of you again directly when it happens. Thanks again, /Peter Created attachment 53511 [details]
Proposed article - revision 1
All, hereby a somewhat revised proposed article. Specifically we've removed most of the screen shots and replaced them with actual text for the code examples. Also we've changed Maven2 to Maven 2 and added several clarifications etc. as per the suggestions. We were unable to come up with a good flowchart, so Peter - can you let us know in more detail what you had in mind?
Thanks,
/Peter
I haven't finished reading the article yet but one problem I noticed right away was that when I went to print it, some of the code examples were truncated on the right hand side. This especially happens in regular Portrait mode, but even when I tried using a small font in Landscape mode it still happens. So, if you could limit your line length so it can be printed and read off-line that would be a nice improvement. As a rule of thumb, I've found that a line length of around 67 characters works pretty well. There should also be a link to this bugzilla entry somewhere near the bottom. Thanks for this very timely article! Ed, very good points. I have made those modifications and am awaiting further feed-back before uploading again. Thanks, /Peter Peter, thanks for updating the article! Regarding the "flowchart": I see that the build process is something rather linear. Since many people (including myself) can understand things better if there are some supporting graphics, I'd suggest that you just draw a very simple flowchart depicting the relevant lifecycle, which indeed will be quite linear. I noticed you now have sections "Putting it all together" and "Using it all together", which is great. It might be a good idea to have a table of contents right at the beginning of the article so that readers can navigate to the point of interest. Regarding the acceptance of this article in the broad public, I really think that it is a must to have the code for the mojos you mention throughout the article. Although the article is very well written and all sounds good and vey compelling, I have to see it to believe it :-) Reviewing my questions from my former post, I noticed this one hasn't been answered yet: - You state that "If you would like to use convention over configuration (like any noble Maven2 user) install a Callisto release (the SDK) into your home directory". But why do I have to install it to my home directory? Is that your idea, or a maven requirement? Would be great if you could explain that in the article. Hey Peter - we can certainly add a simple flow chart to detail the build flow. As for your other question, we did actualy change that... I went back and checked the zip I uploaded; the paragraph now reads: quote If you follow the convention over configuration mantra, install a Callisto release into your home directory. I.e. on Windows your Eclipse directory would be C:\Documents and Settings\username\eclipse; on Unix/Linux/BSD it would be /home/username/eclipse and on Mac OS X it would be /Users/username/eclipse. The reason for this convention is not a Maven 2 one, but rather the need for supporting the Eclipse test framework on multiple platforms. Between Windows, Unix/Linux and Mac OS X the user's home directory is a simply a simple, convenient common denominator. end-quote If you see something different, let me know - and I'll re-upload. As for the Mojo source, we are putting as much pressure as we can on those who decide. Sometimes it's hard to explain to people who are not entrenched in the open source community, why donating IP is valuable. Let me stress that nobody has said "no"; if that was the case, we'd have changed the pertinent paragraph in the article. As developers, we'd love for e.g. Apache or Codehaus to be the home for this, but since this was all written on company dime, our hands are tied. If the community concensus is that this article won't fly without all the code, I suggest we "officially" put it on the back burner until we have a definitive answer one way or the other. The only guesstimate I have right now is some time in Q1 next year, due to scheduled vacations, year-end crunch and the holidays. Cheers, /Peter Hi Peter, thanks for pointing me to the paragraph regarding the home directory - I just overlooked it. With respect to the mojo source: if the article goes online without the mojo sources, people will have to write their own mojos. This breaks the DRY (don't repeat yourself) principle, as dozens of developes will re-invent the wheel. IMO, supplying the mojos is crucial for the success of this article. If you can supply the mojos, the article will be a hit :-) I fully understand the commercial reasons of the decission makers :-( I wouldn't hold up the article waiting on source that may never appear. You can always add that later, or somebody can rewrite it independently and post it. Minor issue: "Example 18. Eclipse plugin configuration" does use CamelCase for the classpathContainers, but not for projectnatures and buildcommands. Cool; we'll keep the pressure on. That's a pragmatic approach, Ed. I'd prefer not to see someone have to rewrite it all, but if that's what it takes, then I guess it'll happen. As you've probably seen from the code samples we did include, the Mojo's really aren't that hard to write; once we understood where Eclipse and Maven 2 locked horns, it was mostly "utility programming" to implement the overall plugin. That being said, it would be a shame for someone else to have to go through the same effort again. (In reply to comment #18) > I wouldn't hold up the article waiting on source that may never appear. You can > always add that later, or somebody can rewrite it independently and post it. > Mike, that's a good catch, but that's the confiugration for the Apache Maven Eclipse plugin (see http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html). We use that plugin to create PDE Eclipse projects, so we have no choice in configuration parameter naming. (In reply to comment #19) > Minor issue: "Example 18. Eclipse plugin configuration" does use CamelCase for > the classpathContainers, but not for projectnatures and buildcommands. > Created attachment 53636 [details]
Proposed article - revision 2
Hereby the proposed article revision 2. Flowchart added; source code formatted to fit on printer.
Since a TOC is not part of the standard Eclipse article template, we have *not* included a TOC. Let us know if it's OK in general to have one (we use docbook, so re-enabling should be relative easy).
/Peter
Can you provide me with the original DocBook source? Created attachment 54583 [details]
DocBook source for proposed article
DocBook source as per Wayne's request
TOC is fine. There is precedent. What is the status of this. Is the article ready for publishing? How about a few +1s? OK folks, we now finally have the official go-ahead to donate the Mojo source. In a separate E-mail thread w/ Wayne I asked if it was OK to use the Apache license, so that's what we'll do. I kindly ask the original reviewers of this proposal to give us the final thumbs up/down (+1/-1) as per Wayne's request after which we'll upload a slightly revised version of the article with the comment about the Mojo code being available ASAP replaced with an actual link to a zip with all the code. The code will have the usual Apache disclaimer at the top of each source file along with a hyperlink to the Apache license. Cheers, /Peter +1 Given the high level of interest and the positive feedback, I'm adding this article to the publishing schedule. Reassigning to me. Created attachment 58489 [details]
mylar/context/zip
Mylar context attached.
Wayne, do you want a ZIP archive of the Mojo sources that we can point to from the article proper? (In reply to comment #31) > Wayne, do you want a ZIP archive of the Mojo sources that we can point to from > the article proper? If you're releasing them under the EPL, then you can post a ZIP archive that we'll include with the article. Otherwise, it's best that we just refer to them where-ever they live. No problem, we'll host the zip off the company website until we find a permanent home for them. I'll forward you the URL when I have it. (In reply to comment #32) > (In reply to comment #31) > > Wayne, do you want a ZIP archive of the Mojo sources that we can point to from > > the article proper? > > If you're releasing them under the EPL, then you can post a ZIP archive that > we'll include with the article. Otherwise, it's best that we just refer to them > where-ever they live. > I've posted the article to the site. I'm using a new version of the stylesheet so the look is different. I did make one minor change to the DocBook source which I'll post as an attachment. http://local.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html I have to do a final editorial pass. However, I noticed a comment on one line: "(Issue: Maven 2 has to find Eclipse dependencies)". Is this intended to be part of the article? Created attachment 58596 [details]
Updated article.xml
Minor tweak. Moved list of software prerequisites into the note content.
Looks good, Wayne - thanks. The "issue" comment is not actually a comment; rather we're listing the issues the Mojos are trying to solve. (In reply to comment #34) > I've posted the article to the site. I'm using a new version of the stylesheet > so the look is different. I did make one minor change to the DocBook source > which I'll post as an attachment. > > http://local.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html > > I have to do a final editorial pass. However, I noticed a comment on one line: > "(Issue: Maven 2 has to find Eclipse dependencies)". Is this intended to be > part of the article? > Thanks - again, things look good with the new stylesheet. BTW, IT is working on an external FTP site for the Mojos as we speak. I'll post the URL to this bug when it's been activated. (In reply to comment #35) > Created an attachment (id=58596) [details] > Updated article.xml > > Minor tweak. Moved list of software prerequisites into the note content. > Wayne, We have published the Mojos in question at http://www.princetonsoftech.com/eclipse/mojos.zip. Should we change the article to include this URL in stead of the comment about making them available? Please let me know if you want us to do that or you want to do it yourself. Thanks, /Peter (In reply to comment #37) > Thanks - again, things look good with the new stylesheet. BTW, IT is working > on an external FTP site for the Mojos as we speak. I'll post the URL to this > bug when it's been activated. > > (In reply to comment #35) > > Created an attachment (id=58596) [details] [details] > > Updated article.xml > > > > Minor tweak. Moved list of software prerequisites into the note content. > > > (In reply to comment #38) > Please let me know if you want us to do that or you want to do it yourself. Please make the change and post your DocBook source. Created attachment 58856 [details]
Revised artcile.xml DocBook source with link to Mojos
Wayne, hereby the revised DocBook source containing the Mojo link as discussed.
/Peter
Updates have been applied. Note that I've added a comment to your appreciation statement for Chris and Lawrence indicating that the XSL has since been further updated. I will do my final grammar/spelling check and post the article later today/tomorrow. Thanks, Wayne - looks great. (In reply to comment #41) > Updates have been applied. Note that I've added a comment to your appreciation > statement for Chris and Lawrence indicating that the XSL has since been further > updated. I will do my final grammar/spelling check and post the article later > today/tomorrow. > I've published the article. I'm closing this bug as FIXED. Peter and Sumit, please let me know (by email - wayne@eclipse.org) your size, mailing address, and phone number, and I'll make sure that you get some Eclipse Swag for your efforts. Thanks. The article misses some information about how to configure source-plugin modules. Because when I try to build one of my source plugins, I get the following error message (and 10 others like it)
1) com.mycompany.eclipse:org.eclipse.ui.ide:pom:1.0
Path to dependency:
1) com.mycompany.eclipse:com.mycompany.framework.eclipse.rcp:source-pl
ugin:1.0-SNAPSHOT
2) com.mycompany.eclipse:org.eclipse.ui.ide:pom:1.0
In the beginning of the article, there is someting about a mojo that would scrape my Eclipse installation and deploy its plugins to my local Maven repository. But there's now information about how or when this mojo runs. And I don't understand why Maven is looking for org.eclipse.ui.ide in this group.
Could you provide more information?
This article is great and by combining it with the information available in http://www.buggybrain.com/2007/10/building-eclipse-plugins-with-maven-2.html I managed to compile all my bundles. But now I don't manage to create a working product configuration based on one of my source-plugins. Is there anything special to consider to make this work? (In reply to comment #45) I'm not entirely sure I understand your question fully. You should be able to create a .product file for your product and launch that from with Eclipse; as for packaging your product, that's a different question - and the answer depends on how you intend to do that. For example, we create a Maven assembly for a product which we use Maven to build and then feed the assembly into an installer. The assembly part is mostly straight Maven with a couple of minor adjustments - some of which will depend on what you're actually intending to ship. If you intend to ship plugins, you're almost done; if you intend to ship a complete ready-to-run installable product (either a .zip or a "real" installer) you need to add the core RCP/Workbench pieces to your assembly as well. Since the built plugins are "standard" jars, there isn't much special about an assembly and as long as you have a POM and an XML descriptor for the dependencies it's basically standard Maven assembly work. > This article is great and by combining it with the information available in > http://www.buggybrain.com/2007/10/building-eclipse-plugins-with-maven-2.html I > managed to compile all my bundles. > > But now I don't manage to create a working product configuration based on one > of my source-plugins. Is there anything special to consider to make this work? > |