Bugzilla – Full Text Bug Listing
| Summary: | Create a Eclipse Parent POM | ||
|---|---|---|---|
| Product: | [Technology] Dash | Reporter: | Chris Aniszczyk <caniszczyk> |
| Component: | Maven | Assignee: | David Carver <d_a_carver> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | anders.g.hammar, davymeers, d_a_carver, hmalphettes, jan.sievers, jesse.mcconnell, joakim.erdfelt, mknauer, nboldt, pascal, pwebster, qualidafial, sbouchet, steffen.pingel, vincent.zurczak |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Chris Aniszczyk
Also, what eclipse.org project would contain the parent POM? Dash? (In reply to comment #1) > Also, what eclipse.org project would contain the parent POM? Dash? Yes, Dash should contain parent pom. Jesse McConnel and I are working on this. We probably want to move this bug to the Dash project. Moving to Dash project. First snapshot version of a parent-pom has been committed to dash, it has not been deployed yet. commit b0566f720c5a1618c9e5c2a23f340bdbc9d26311 Author: David Carver <d_a_carver@yahoo.com> Date: Thu May 26 19:55:28 2011 -0400 [339915] Create a Eclipse Parent POM. Created initial Parent POM. Includes the following. Profiles for findbugs, checkstyle, and duplicate code analysis. Findbugs and duplicate code analysis enabled, with the -Panalysis setting in a build. To enable checkstyle, -Pcheckstyle. Both can be enabled together. -Panalysis,checkstyle Includes standard license information, ciManagement, issueManagement, and organization information. Profiles for the various repositories, pointing back to maven.eclipse.org. http://git.eclipse.org/c/dash/org.eclipse.dash.maven.git/commit/?id=b0566f720c5a1618c9e5c2a23f340bdbc9d26311 Please review and let me know if we need anything else in particular. It'll be up to minerva. Slight update to remove hard coding of sourceDirectory. http://git.eclipse.org/c/dash/org.eclipse.dash.maven.git/commit/?id=45b9dfea7623e039b33e0615b28e55fac6eef5ba Some minor niggles about the profile definitions. The meaning of <activeByDefault> is that 1 profile is automatically selected, if no other profiles are active. I propose removing the <activeByDefault> activations entirely. The profile that has the eclipse-public repository definition needs an <id> element as well. As for the requirement to have <build><sourceDirectory>src</sourceDirectory></build> ... Please don't make the top level pom for all of eclipse use non-standard directories and project layouts. If we have legacy (I *really* dislike that word) builds that need it for tycho builds and whatnot, setup another parent pom that just adjust for those legacy projects. eclipse-parent <- eclipse-legacy-parent <- legacy-project Or let the legacy project itself redefine the <sourceDirectory> element. eclipse-parent <- foo-project-parent <- foo-module-bar (In reply to comment #6) > As for the requirement to have > <build><sourceDirectory>src</sourceDirectory></build> ... > > Please don't make the top level pom for all of eclipse use non-standard > directories and project layouts. Define non-standard? (In reply to comment #7) > (In reply to comment #6) > > As for the requirement to have > > <build><sourceDirectory>src</sourceDirectory></build> ... > > > > Please don't make the top level pom for all of eclipse use non-standard > > directories and project layouts. > > Define non-standard? By non-standard we mean non-Maven directory layouts. Many maven plugins expect to see: src/main/java src/main/resources src/test/java src/test/resources Eclipse projects typically use: src for the source directory. http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html (In reply to comment #6) > As for the requirement to have > <build><sourceDirectory>src</sourceDirectory></build> ... > +1 Let's not impose the location of the sources to everyone. If this is a pom for supporting eclipse projects that want to consume tycho, the plugin project standard is <project>/src. (In reply to comment #6) > eclipse-parent <- eclipse-legacy-parent <- legacy-project I'm OK with the above. A common "eclipse-plugin-parent" pom that the approximately 14000 (+/- 1000) plugin projects we currently have can consume. > > Or let the legacy project itself redefine the <sourceDirectory> element. > > eclipse-parent <- foo-project-parent <- foo-module-bar This, however, will mean that the "common" case at eclipse will be to add the same element over and over. That seems like unnecessary duplication. PW I'm pretty sure any eclipse.org project using Maven is going to use Tycho and keep the "standard" src location which is used by many eclipse projects. I'd also argue that Maven is finally useful that it can build OSGi artifacts, but we can save that for another discussion :) +1 for keeping the "src" directory as this will be the default for the majority of folks. To reiterate, I'm for having one parent pom, let's not make things more confusing than they need to be. (In reply to comment #12) > To reiterate, I'm for having one parent pom, let's not make things more > confusing than they need to be. Chris, actually, let's move the <build><sourceDirectory> info to Minerva, and have minerva's parent in herit from the eclipse-parent. I do think that the top level pom should be kept as generic as possible. Every project should have it's own parent that contains additional information, in particular those project level parents should contain information like: mailingLists scm licenses (i.e. in addition to the Eclipse Public License) plugins Management repositories (beyond the default repositories) We can create a wiki to keep things simple and guide people on how to use things. We want to make sure that we play well with the existing maven plugins out there, which means we should try and follow where it makes sense the maven standards as much as possible. (In reply to comment #12) > To reiterate, I'm for having one parent pom, let's not make things more > confusing than they need to be. Speaking as a member of rt-jetty, we are -1 to having <build><sourceDirectory> defined in the eclipse-parent. And looking around eclipse.org at various maven using projects (source google search), I see the following using the standard maven directory and project layouts. IAM m2eclipse project (proposed) Gemini Swordfish Virgo Higgens VTP JWT DSDP Tigerstripe Just food for thought. Not all projects under Eclipse are the same. Not all use OSGi as their core technology. Not all follow the release train. Some even have releases outside of the release train. Keep this in mind, as more and more projects are coming onboard that do not follow the traditional Eclipse cookie-cutter view of an Eclipse project. (In reply to comment #14) > And looking around eclipse.org at various maven using projects (source google > search), I see the following using the standard maven directory and project > layouts. > > Higgens Higgins (sorry, typo) I pushed the eclipse-parent without the Source directory configuration. Chris the source directory information may fit better at a Project level parent as I said. I tend to agree with Joakim that we need to keep the top level as generic as possible. If anybody wants to test out the eclipse-parent you can find it here: http://maven.eclipse.org/nexus/content/groups/public/org/eclipse/eclipse-parent/1.0.0.0-SNAPSHOT/ (In reply to comment #14) > Just food for thought. Not all projects under Eclipse are the same. > Not all use OSGi as their core technology. No, but the bulk of the source projects do fit these 2 categories (Platform, Equinox, JDT, PDE, CDT, Webtools, etc). As I said, I don't have a preference. If the expectation is that all standard plugin projects consume the Minerva pom as the parent to pick up this common configuration, that's acceptable too. But if the idea is to provide standard configuration for eclipse projects to consume, this case has to be taken into account ... PW The distribution repository urls indicate that those are for the Indigo simultaneous release. They would not be approriate for those not included in that and those this parent pom wouldn't be a perfect fit for them. May I suggest that the parent pom is kept generic enough that any project can/should use it. Then you could create an Indigo parent (or whatever release train) that inherits from that and adds extra stuff. Please understand that I'm mainly a Maven person and have limited Eclipse routines knowledge. My remark is from that perspective. (In reply to comment #18) > The distribution repository urls indicate that those are for the Indigo > simultaneous release. They would not be approriate for those not included in > that and those this parent pom wouldn't be a perfect fit for them. > May I suggest that the parent pom is kept generic enough that any project > can/should use it. Then you could create an Indigo parent (or whatever release > train) that inherits from that and adds extra stuff. > > Please understand that I'm mainly a Maven person and have limited Eclipse > routines knowledge. My remark is from that perspective. I'll be making an update to the distribution sections to add Juno ids shortly. For a list of the available repositories we have for deploying to, please see: http://maven.eclipse.org/nexus/index.html#view-repositories The distribution repositories that are included, are the starting points, a project can always add additional distribution repositories. (In reply to comment #19) > I'll be making an update to the distribution sections to add Juno ids shortly. > > For a list of the available repositories we have for deploying to, please see: > > http://maven.eclipse.org/nexus/index.html#view-repositories > > The distribution repositories that are included, are the starting points, a > project can always add additional distribution repositories. The thing is that you don't add additional distro repos, but only have one distro repo (per repo type). As you now start adding a distro repo for Juno you will see the problem with having release train specific distro repos in the general parent pom. (In reply to comment #20) > (In reply to comment #19) > > > I'll be making an update to the distribution sections to add Juno ids shortly. > > > > For a list of the available repositories we have for deploying to, please see: > > > > http://maven.eclipse.org/nexus/index.html#view-repositories > > > > The distribution repositories that are included, are the starting points, a > > project can always add additional distribution repositories. > > The thing is that you don't add additional distro repos, but only have one > distro repo (per repo type). As you now start adding a distro repo for Juno you > will see the problem with having release train specific distro repos in the > general parent pom. We do have one combined distro, which can be accessed via: http://maven.eclipse.org/nexus/content/groups/public/ What I have gone through and done, is moved the distribution management items to a profile. We need to keep the various release train items seperate, but you do bring up a point...what to do with those projects that aren't participating in a release train but are using maven for their build process. As of right now moving this to a profile seems to be the best compromise, and everything is still accessible through the public repository. Here is the commit id for the latest changes. http://git.eclipse.org/c/dash/org.eclipse.dash.maven.git/commit/?id=6539789dcb836a8a5c59d69f74d16b93e7775b74 In the tradition of eating our own dog food, I've setup the dash-maven-ci build on hudson, to use the checkstyle and analysis profiles. https://hudson.eclipse.org/hudson/job/dash-maven-ci/ It also makes use of a settings.xml file to pull items from maven.eclipse.org instead of directly from central. (In reply to comment #21) > We do have one combined distro, which can be accessed via: > > http://maven.eclipse.org/nexus/content/groups/public/ That's not a distribution repository - you cannot deploy to it! It's a Maven repo (group) that you can consume maven artifacts from. (In reply to comment #24) > (In reply to comment #21) > > We do have one combined distro, which can be accessed via: > > > > http://maven.eclipse.org/nexus/content/groups/public/ > > That's not a distribution repository - you cannot deploy to it! It's a Maven > repo (group) that you can consume maven artifacts from. Correct, but you can get things from them. There is another bug that discusses setting up maven.eclipse.org. bug 337068 is where this discussion is taking place. As it stands now, we are creating a nightly (snapshot) and milestone repositories for each of the release trains. These artifacts are then aggregrated under a public maven repository. If you feel strongly about a single maven repository to deploy to, please put the comments on bug 337068. Right now with eclipse parent, to deploy your build artifacts, you just need to enable the appropriate profile. I've deployed version 1.0.0 of the eclipse-parent pom out to maven.eclipse.org. I'll create a wiki for this and a blog entry later in the week. For those projects that want to start using it, you just need to add to your projects parent pom, that it inherits from the: <parent> <groupId>org.eclipse</groupId> <artifactId>eclipse-parent</artifactId> <version>1.0.0</version> </parent> Make sure you have a repository entry setup for maven.eclipse.org or are using the settings.xml file provided in the dash project. You will then have available the profiles for running FindBugs, CheckStyle, and PMD, as well as deployment profiles for indigo, and juno for any maven artifacts you need to deploy. |