On 18/09/2012, at 11:32 PM, Hans Dockter wrote: > > > 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?
We'd probably just flip the maven-3 and the maven-ant-tasks around, so that we jarjar the ant tasks and not the maven-3 classes. The publishing would continue to use the ant tasks. The pom generation would use whichever of the two is easier to make work. Once this is stable, we'll start replacing the maven-ant-tasks for publishing, probably with aether on top of our resource transports. If we can't make the ant tasks work in jarjared form, we'll have to live with the existing solution until we can move away from the ant tasks. I don't really want to replace everything in one go. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
