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.
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. 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 > >> >>> > >> >>> > > > > >
