On Tue, Feb 18, 2014 at 7:28 PM, sebb <seb...@gmail.com> wrote: > On 19 February 2014 00:29, Matt Benson <gudnabr...@gmail.com> wrote: > > On Thu, Feb 13, 2014 at 6:42 PM, sebb <seb...@gmail.com> wrote: > >> > >> On 14 February 2014 00:35, Matt Benson <gudnabr...@gmail.com> wrote: > >> > Seb, can you verify whether you can do `mvn install` from a fresh > >> > checkout? > >> > This is AFAIK typically required with multimodule Maven projects: as > one > >> > module is built, it is installed so that the next module can depend on > >> > it. > >> > >> I have checked the RAT multi-module build [1] and that is able to run > >> clean and compile quite happily. > >> > > > > As you note, Seb, the examples require the Maven plugin. At some point, > if > > we are to test the plugin, something has to depend on it, leading us to > the > > situation where one cannot run `mvn clean` on a fresh checkout. The > > difference in the Rat setup is that it depends on an earlier version of > its > > own plugin, breaking the cycle, but as weaver-maven-plugin has never yet > > been released, we don't have that option here. > > AIUI the RAT dependency on the previous version is only for running > RAT on the source, not for testing the RAT plugin. > The plugin is tested using standard Maven IT tests > > I see. This would be new ground for me; however, the existing structure serves multiple purposes: * the example module demonstrates that the maven plugin works and that the privilizer module works * the ant/test module demonstrates that the antlib works and that the privilizer module works * the modules/normalizer/example module demonstrates that the maven plugin works and that the normalizer module works
Using the maven plugin to test the modules is too convenient not to use, but I would be amenable to having these depend on v1.0 of the plugin once it has been released. Can we agree that the plugin will get standard maven-plugin integration tests after 1.0? > >> We should not force developers to have to run install. > >> There must be a way to get the weaver build working without such > >> restrictions. > >> > > It is possible to build everything without installing using `mvn package` > > which uses the Maven reactor to make the various module builds mutually > > available to one another. [1] links to [2], and [3] directs users to run > > `mvn clean install`, so if [weaver]'s build gives the option of running > `mvn > > clean install` or `mvn package` I think that will have to do. Restricting > > the plugin to run only in a specific profile, for example, doesn't help. > > If special instructions are needed to build the component, these ought > to be documented in a BUILDING or README file > There is a "building" document on the site (its source is at src/site/markdown). Would you want to see its content duplicated at the root of the project, or would this file satisfy you with a few additions? > > Also it's not just "mvn clean" that does not work > > Cannont run "mvn dependency:tree" either, and I'm sure there are other > utility plugins that won't work. > I did notice that the dependency plugin's goals also don't work in this context. I am happy to document the current requirement of an installation (I still suspect most Maven users working with multimodule projects are using `mvn clean install`). > > > Matt > > [1] http://maven.apache.org/guides/mini/guide-multiple-modules.html > > [2] http://books.sonatype.com/mvnex-book/reference/multimodule.html > > [3] > > > http://books.sonatype.com/mvnex-book/reference/multimodule-sect-building-multimodule.html > > > > > > > >> > >> [1] https://svn.apache.org/repos/asf/creadur/rat/trunk > >> > >> > Thanks, > >> > Matt > >> > > >> > > >> > On Wed, Feb 12, 2014 at 5:46 PM, sebb <seb...@gmail.com> wrote: > >> >> > >> >> BTW, I'm getting some odd errors on trunk. > >> >> > >> >> For example, just tried "mvn clean" and it fails with > >> >> > >> >> ============================= > >> >> > >> >> [ERROR] BUILD FAILURE > >> >> [INFO] > >> >> > >> >> > ------------------------------------------------------------------------ > >> >> [INFO] A required plugin was not found: Plugin could not be found - > >> >> check that the goal name is correct: Unable to download the artifact > >> >> from any repository > >> >> > >> >> Try downloading the file manually from the project website. > >> >> > >> >> Then, install it using the command: > >> >> mvn install:install-file -DgroupId=org.apache.commons > >> >> -DartifactId=commons-weaver-maven-plugin -Dversion=1.0.1-SNAPSHOT > >> >> -Dpackaging=maven-plugin -Dfile=/pat > >> >> h/to/file > >> >> > >> >> Alternatively, if you host your own repository you can deploy the > file > >> >> there: > >> >> mvn deploy:deploy-file -DgroupId=org.apache.commons > >> >> -DartifactId=commons-weaver-maven-plugin -Dversion=1.0.1-SNAPSHOT > >> >> -Dpackaging=maven-plugin -Dfile=/path/ > >> >> to/file -Durl=[url] -DrepositoryId=[id] > >> >> > >> >> > >> >> > >> >> > >> >> > org.apache.commons:commons-weaver-maven-plugin:maven-plugin:1.0.1-SNAPSHOT > >> >> > >> >> from the specified remote repositories: > >> >> central (http://repo1.maven.org/maven2) > >> >> > >> >> > >> >> > >> >> > >> >> > org.apache.commons:commons-weaver-maven-plugin:maven-plugin:1.0.1-SNAPSHOT > >> >> > >> >> from the specified remote repositories: > >> >> central (http://repo1.maven.org/maven2) > >> >> > >> >> ============================= > >> >> > >> >> I have yet to build weaver, so there is no plugin in the repo. > >> >> > >> >> It seems wrong that the plugin has to be built and installed before > >> >> one can run "mvn clean" but I don't know how to fix this. > >> >> > >> >> Also, it does not appear to be possible to run "mvn compile" from the > >> >> top-level > >> >> > >> >> Further, it looks as though the maven shade plugin may require M3.x > >> >> If so, the pom needs to require this. > >> >> > >> >> > >> >> On 12 February 2014 23:37, sebb <seb...@gmail.com> wrote: > >> >> > On 12 February 2014 23:22, Matt Benson <gudnabr...@gmail.com> > wrote: > >> >> >> The AL header is in > >> >> >> > >> >> >> > >> >> >> > https://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/src/changes/release-notes.vm > , > >> >> >> from which the release notes were generated. > >> >> > > >> >> > The header lines in the vm file are comments that are not supposed > to > >> >> > be copied to the generated output. > >> >> > Likewise the later lines prefixed with ## > >> >> > > >> >> > How did you generate the RN file? > >> >> > > >> >> >> Interestingly, m2eclipse defaults to the behavior that redundant > >> >> >> groupId/version are warning-worthy. Browsing > >> >> >> http://svn.apache.org/repos/asf/maven seems to show that Apache > >> >> >> Maven's > >> >> >> own > >> >> >> developers omit the duplicate elements. > >> >> > > >> >> > That does not mean it is best practise for non-plugin development. > >> >> > > >> >> >> Thanks for working on my line endings; apparently one or more of > my > >> >> >> machines wasn't/isn't configured properly in that regard. > >> >> > > >> >> > OK. > >> >> > > >> >> >> Matt > >> >> >> > >> >> >> > >> >> >> On Wed, Feb 12, 2014 at 4:49 PM, sebb <seb...@gmail.com> wrote: > >> >> >> > >> >> >>> On 12 February 2014 02:20, Matt Benson <mben...@apache.org> > wrote: > >> >> >>> > I would like to make the inaugural release of the [weaver] > >> >> >>> > component. > >> >> >>> > > >> >> >>> > Apache Commons Weaver 1.0 RC1 is available for review at: > >> >> >>> > https://dist.apache.org/repos/dist/dev/commons/weaver/(r4368). > >> >> >>> > > >> >> >>> > Maven artifacts are at: > >> >> >>> > > >> >> >>> > >> >> >>> > >> >> >>> > https://repository.apache.org/content/repositories/orgapachecommons-1007/. > >> >> >>> > > >> >> >>> > Tested with Oracle JDKs 6 and 7. > >> >> >>> > > >> >> >>> > The Subversion tag is: > >> >> >>> > > >> >> >>> > >> >> >>> > >> >> >>> > http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.0_RC1/(r1567477) > >> >> >>> . > >> >> >>> > > >> >> >>> > Site: > >> >> >>> > > >> >> >>> > > >> >> >>> > > http://people.apache.org/~mbenson/commons-weaver-1.0-rc1/index.html > >> >> >>> > > >> >> >>> > RAT Report: > >> >> >>> > > >> >> >>> > >> >> >>> > >> >> >>> > http://people.apache.org/~mbenson/commons-weaver-1.0-rc1/rat-report.html > >> >> >>> > > >> >> >>> > >> >> >>> I've never seen the AL header in release notes before. > >> >> >>> Not sure that's necessary (and it makes the notes harder to > read). > >> >> >>> > >> >> >>> The poms don't include any groupId definitions. > >> >> >>> Although this will default from the parent, I think it is better > to > >> >> >>> specify the group id. > >> >> >>> Otherwise it is not clear whether the omission is accidental or > >> >> >>> deliberate. > >> >> >>> Also if the parent group Id ever changes (or perhaps is removed) > >> >> >>> the > >> >> >>> component groupId will change unless the groupId is added at that > >> >> >>> point. > >> >> >>> > >> >> >>> > Keys: https://dist.apache.org/repos/dist/release/commons/KEYS > >> >> >>> > > >> >> >>> > Please review the release candidate and vote. > >> >> >>> > This vote will close no sooner that 72 hours from now, i.e. > >> >> >>> > after > >> >> >>> 0300UTC > >> >> >>> > 15-February 2014 > >> >> >>> > > >> >> >>> > [ ] +1 Release these artifacts > >> >> >>> > [ ] +0 OK, but... > >> >> >>> > [ ] -0 OK, but really should fix... > >> >> >>> > [ ] -1 I oppose this release because... > >> >> >>> > > >> >> >>> > Thanks! > >> >> >>> > >> >> >>> > >> >> >>> > --------------------------------------------------------------------- > >> >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >> >>> For additional commands, e-mail: dev-h...@commons.apache.org > >> >> >>> > >> >> >>> > >> > > >> > > > > > >
