On Wed, Feb 19, 2014 at 4:50 AM, sebb <seb...@gmail.com> wrote:
> 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?
>
We can ask around, certainly, but if the goal is running a Maven
multimodule build in which module A depends on its sibling plugin module B,
of the same version, without installing or even so much as packaging B, I
fail to see how we'd be barking up anything but the wrong tree. IMO the
current situation is not surprising.
Matt
>
> > 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
> >> >> >> >> >> >>>
> >> >> >> >> >> >>>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>
