On 19 February 2014 02:10, Matt Benson <gudnabr...@gmail.com> wrote: > 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?
AFAIK, Creadur RAT already handles such things. AIUI it only needs to depend on the previous RAT version for running the RAT report. That would presumably be much too hard to make work with the current version (and anyway it is not necessary to use the latest for the site report). I don't think it makes sense for the plugin tests to depend on anything but the current version. Surely one wants to test the current version? >> >> >> 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? It's important the user who download the source can easily build it. So having a text file in the root is best. However this could just point to another file if that clearly explains how to build the code. Or there could be basic build instructions in the root file with a link to further details elsewhere. >> >> >> 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 >> >> >> >>> >> >> >> >>> >> >> > >> >> > >> > >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
