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