On 19 February 2014 02:45, Matt Benson <gudnabr...@gmail.com> wrote: > On Tue, Feb 18, 2014 at 8:25 PM, sebb <seb...@gmail.com> wrote: >> >> 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 feel we may be talking past each other here, so I'm going to attempt to > go into great detail. Thanks for bearing with me; I imagine it's quite late > for you. >
[I'm an owl rather than a lark...] >> >> > 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. >> > Yes, apache-rat-plugin seems to be using maven-plugin-testing-harness to > test itself. But I feel we've lost each other here. The reason the "current > version" dependencies are truly causing issues is because the Maven plugin > is used to test the "weaver modules" i.e. privilizer and normalizer. It > would seem that after a release this job could be handled by > commons-weaver-maven-plugin:1.0 . Then there would be nothing exercising the > plugin, however, and it would need dedicated tests at that point. These > would be created using maven-plugin-testing-harness. It would be best to do > something similar with the Antlib; presumably one would use dummy(ish) > implementations of the Weaver and Cleaner SPIs so that bulk of what is being > tested is the Maven plugin/Antlib itself. > >> AIUI it only needs to depend on the previous RAT version for running >> the RAT report. > > > This is analogous IMO; [weaver] would use an earlier version of the plugin > for invoking weaver modules under development. I'm not sure it is analagous. AFAICT it's only the RAT *report* that uses the previous version. There is no Weaver Report needed here. >> >> 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 guess you're still talking about rat here, but part of what you've said > applies to [weaver]: it would quite difficult to break the circularity > without a prior release to depend upon. > >> >> >> 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? >> > I agree, but when a weaver module rather than the plugin/Antlib is what's > being tested there is no such restriction (unless some new feature of these > becomes needed to test some future weaver module). > > Are we on the same page now wrt testing? To be 100% clear, I am proposing > that we document the necessity of `mvn clean install`, as you've suggested, > for v1.0, then update to remove the circular dependency upon > commons-weaver-maven-plugin:${project.version} and > commons-weaver-antlib:${project.version}, giving these dedicated tests of > their own once they will no longer be exercised in the course of testing > weaver modules. This problem must exist for all Maven plugins - if indeed it is a problem. I'm not sure it is. >> >> >> >> >> >> 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. >> > That sounds reasonable. > > Matt > >> >> >> >> >> >> >> 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