On Tue, Sep 18, 2012 at 3:17 PM, Szczepan Faber < [email protected]> wrote:
> Hey guys, > > I just wanted to touch base on state of things with maven2Gradle (the > bootstrap plugin, converting from maven projects). I currently work on > improving the maven2Gradle so that it uses embedded maven (maven3 > classes) instead of forking off a maven process. > > 1. To use maven in an embedded way I needed to pull extra dependencies > in, it's about 20 extra jars to the distro, most of them needs to be > jarjarred. This is the diagram of maven3 classes btw: > http://maven.apache.org/ref/3.0.3 > > 2. I needed to resolve the problem with jarjar not updating the class > references in the resources. I wasn't sure what was the best strategy > solve the problem. Since I've already started looking at jarjar code, > I've made fix in jarjar: https://github.com/szczepiq/jarjar I've > released the jar into repo.gradle.org so that the build can consume > it. > > 3. I needed to add some hackery to fix the plexus configuration after > the jarjar runs: > > https://github.com/gradle/gradle/blob/master/subprojects/core-impl/core-impl.gradle#L52 > > 4. We now use 23 jars jar-jarred that are a compile dependency. It's > extra complexity and makes harder to browse source code because jarjar > doesn't do sources. So if someone needs debug into maven/plexus stuff > he needs sources on the side (or a separate dummy project with all > those dependencies, etc.). > > Stepping back a bit. We need to jarjar maven3 classes to avoid clash > with stuff that lives in maven-ant-tasks. Maven-ant-tasks has been a > compile dependency to Gradle since pretty much always. It would be > awesome if we did small steps towards removing the maven-ant-tasks. > One of the spots that uses maven-ant-tasks implementation atm is our > MavenPom / DefaultMavenPom. MavenPom is a public interface that gives > access to underlying maven implementation via MavenPom#getModel(); I > did a quick check on compatibility between the old model and the new > model and the results are not bad: 4 methods from the old model were > removed (full list down the bottom). > > With this email I wanted to share my findings. Please give feedback. > > checking: Model VS Model > checking: Parent VS Parent > checking: Organization VS Organization > checking: Contributor VS Contributor > checking: Developer VS Developer > checking: License VS License > checking: MailingList VS MailingList > checking: Profile VS Profile > checking: BuildBase VS BuildBase > checking: Resource VS Resource > checking: PluginManagement VS PluginManagement > checking: Plugin VS Plugin > checking: Dependency VS Dependency > checking: Exclusion VS Exclusion > checking: PluginExecution VS PluginExecution > checking: Activation VS Activation > checking: ActivationProperty VS ActivationProperty > checking: ActivationFile VS ActivationFile > checking: ActivationOS VS ActivationOS > checking: Repository VS Repository > checking: RepositoryPolicy VS RepositoryPolicy > checking: DependencyManagement VS DependencyManagement > checking: DistributionManagement VS DistributionManagement > checking: Relocation VS Relocation > checking: DeploymentRepository VS DeploymentRepository > checking: Site VS Site > checking: Reporting VS Reporting > checking: ReportPlugin VS ReportPlugin > checking: ReportSet VS ReportSet > only in class org.apache.maven.model.Reporting - isExcludeDefaultsValue > only in class org.apache.maven.model.Reporting - setExcludeDefaultsValue > only in class org.apache.maven.model.Reporting - setExcludeDefaultsValue > checking: Build VS Build > checking: Extension VS Extension > only in class org.apache.maven.model.Extension - getKey > checking: CiManagement VS CiManagement > checking: Notifier VS Notifier > checking: IssueManagement VS IssueManagement > checking: Prerequisites VS Prerequisites > checking: Scm VS Scm > Right now I'm not opposed to making this change during the 1.x timeline. We are upgrading to the Maven 3 way which is in the interest of most our users. Quite likely no one will be affected by the small delta above and if so there should be a very easy workaround. I guess it also opens up the door to solve problems like that we always do a maven install. The other question is how much this would affect our pom publishing, which is the more sensitive bit? Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleware CEO, Gradleware - Gradle Training, Support, Consulting http://www.gradleware.com > Cheers! > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
