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