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
