commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [VOTE] Release Apache Commons Weaver 1.0 based on RC1
Date Wed, 19 Feb 2014 02:10:32 GMT
On Tue, Feb 18, 2014 at 7:28 PM, sebb <sebbaz@gmail.com> wrote:

> On 19 February 2014 00:29, Matt Benson <gudnabrsam@gmail.com> wrote:
> > On Thu, Feb 13, 2014 at 6:42 PM, sebb <sebbaz@gmail.com> wrote:
> >>
> >> On 14 February 2014 00:35, Matt Benson <gudnabrsam@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 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?


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


>
> 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 <sebbaz@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 <sebbaz@gmail.com> wrote:
> >> >> > On 12 February 2014 23:22, Matt Benson <gudnabrsam@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 <sebbaz@gmail.com>
wrote:
> >> >> >>
> >> >> >>> On 12 February 2014 02:20, Matt Benson <mbenson@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-unsubscribe@commons.apache.org
> >> >> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >> >>>
> >> >> >>>
> >> >
> >> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message