On 19 February 2014 05:52, Matt Benson <gudnabr...@gmail.com> wrote:
> On Tue, Feb 18, 2014 at 8:59 PM, sebb <seb...@gmail.com> wrote:
>>
>> 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.
>>
> But the primary function of rat is reporting. The primary function of
> [weaver] is weaving. Thus when I think of one of [weaver]'s other (Maven)
> submodules using weaver-maven-plugin to weave a sample codebase (in the
> interest of testing a "weaver module") this seems to me analogous to using
> (an earlier version of) rat to report any licensing issues found in its own
> codebase.
Yes, I understand the function analogy.
But my argument is that RAT has to use the previous version only
because it is used by the report part of the build.
If the RAT report were dropped, AFAICT there would be no need to refer
to the earlier version.
It is only the reporting phase that cannot use the current version of RAT.
Weaver is not used in the report phase.
>> >>
>> >> 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.
>>
> Here we have a set of artifacts, one of which is a Maven plugin, and others
> of which can be conveniently tested/demonstrated using said plugin. It may
> not be all that often that such a situation comes up. In any case, I don't
> hear you telling me you can't live with my proposal.
I'm not convinced that the poms are correctly set up at present.
It's quite difficult for people to use them.
Unfortunately I don't know enough about Maven IT testing to know what
the solution is.
Perhaps there are some other devs on this list who have got the
necessary experience to help fix this?
> Regards,
> Matt
>
>> >>
>> >> >>
>> >> >> >> 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
