Doug,

Its very curious that the build could not find the maven plugin. I've just
made a clean checkout with the patch and the 'mvn verify' goal ran fine. Do
you have a copy of the plugin in your local repo?

Generating the sample project as part of the build references the
maven-plugin. I'm thinking that the archetype plugin must fork a new maven
build for the sample and its this build that needs the plugin installed.
Without the jar in the local repo neither the 'integration-test' or 'verify'
goals will succeed. The 'test' goal will pass because the sample project is
not generated or built and tying the generation to this phase will still
fail without the maven-plugin installed locally.

You should not have any issues running the install goal, its the default
goal I usually run for maven builds; are you experiencing problems? If you
prefer not to I can remove the the integration testing from the build. Let
me know.

regards,

Steve.

On Tue, Sep 20, 2011 at 10:26 PM, Doug Cutting (JIRA) <[EMAIL PROTECTED]>wrote:

>
>    [
> https://issues.apache.org/jira/browse/AVRO-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109004#comment-13109004]
>
> Doug Cutting commented on AVRO-890:
> -----------------------------------
>
> When I run 'mvn integration-test' it fails with:
>
> [ERROR] Plugin org.apache.avro:avro-maven-plugin:1.6.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.apache.avro:avro-maven-plugin:jar:1.6.0-SNAPSHOT -> [Help 1]
>
> But if I instead run 'mvn install' then it runs integration tests.  I
> generally don't run 'install' since I don't want to confuse myself by having
> working versions in my local maven repo.
>
> What can I do to get the archetype tests run without installing?  I
> generally run 'mvn clean test' before each commit, and that's what the
> Jenkins build server runs after each commit, so my preference would be for
> the archetype code to be tested then too.  Is there an alternative that I
> should use that does not install artifacts in my local repo?  I tried
> 'verify', but it also fails with the above message.  Could we somehow fix
> things so that 'verify' works?
>
> > Maven archetype for creating Avro service projects
> > ---------------------------------------------------
> >
> >                 Key: AVRO-890
> >                 URL: https://issues.apache.org/jira/browse/AVRO-890
> >             Project: Avro
> >          Issue Type: Improvement
> >          Components: java
> >    Affects Versions: 1.5.4
> >            Reporter: Stephen Gargan
> >            Assignee: Stephen Gargan
> >            Priority: Minor
> >              Labels: archetype, maven
> >             Fix For: 1.6.0
> >
> >         Attachments: archetypes.patch, archetypes.patch, archetypes.patch
> >
> >
> > I've put together the beginnings of an maven archetypes subproject in the
> java module to help folks kickstart avro projects. The first archetype
> creates a simple avro based ordering service using the netty transport and
> includes an integration test for the service. The service is very naive,
> though its really only the plumbing that is important and the example is
> illustrative enough to get people going.
> > Once built, it can be added to the local archetypes catalog via
> > mvn archetype:crawl
> > and then will be available via the generate plugin
> > mvn archetype:generate
> > or it can be invoked directly as follows
> > mvn archetype:generate -DarchetypeArtifactId=avro-service-archetype
> -DarchetypeGroupId=org.apache.avro -DgroupId=org.simple
> -DartifactId=simple-service -Dversion=1.0-SNAPSHOT
> > The parent pom contains common config for generating a pom for the
> archetype that references the current avro build version. This takes some
> slight of hand with maven resources to insert the version and will be
> reusable for other archetypes in the future.
> > I intend putting together a map-reduce archetype soon and am open to

On 09/20/2011 04:09 PM, Stephen Gargan wrote:
> Its very curious that the build could not find the maven plugin. I've just
> made a clean checkout with the patch and the 'mvn verify' goal ran fine. Do
> you have a copy of the plugin in your local repo?

No, I do not have a copy in my local repo.

> Generating the sample project as part of the build references the
> maven-plugin. I'm thinking that the archetype plugin must fork a new maven
> build for the sample and its this build that needs the plugin installed.
> Without the jar in the local repo neither the 'integration-test' or 'verify'
> goals will succeed. The 'test' goal will pass because the sample project is
> not generated or built and tying the generation to this phase will still
> fail without the maven-plugin installed locally.
>
> You should not have any issues running the install goal, its the default
> goal I usually run for maven builds; are you experiencing problems? If you
> prefer not to I can remove the the integration testing from the build. Let
> me know.

Install works fine, but I prefer not to use it when testing patches.

Doug

Understandable. If you're worried about polluting the repo with suspect
artifacts you can run mvn build-helper:remove-project-artifact to remove
them afterwards.  Just a suggestion.
On Wed, Sep 21, 2011 at 12:12 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:

> On 09/20/2011 04:09 PM, Stephen Gargan wrote:
> > Its very curious that the build could not find the maven plugin. I've
> just
> > made a clean checkout with the patch and the 'mvn verify' goal ran fine.
> Do
> > you have a copy of the plugin in your local repo?
>
> No, I do not have a copy in my local repo.
>
> > Generating the sample project as part of the build references the
> > maven-plugin. I'm thinking that the archetype plugin must fork a new
> maven
> > build for the sample and its this build that needs the plugin installed.
> > Without the jar in the local repo neither the 'integration-test' or
> 'verify'
> > goals will succeed. The 'test' goal will pass because the sample project
> is
> > not generated or built and tying the generation to this phase will still
> > fail without the maven-plugin installed locally.
> >
> > You should not have any issues running the install goal, its the default
> > goal I usually run for maven builds; are you experiencing problems? If
> you
> > prefer not to I can remove the the integration testing from the build.
> Let
> > me know.
>
> Install works fine, but I prefer not to use it when testing patches.
>
> Doug
>

The only issue with pointing it at a released plugin is that the generated
samples would not then reference the most recent build; projects generated
with the 1.6.0 archetype would generate a project referencing a 1.5.X
plugin. I completely agree that having a separate release cycle just for
this would be troublesome.

As a suggestion, I could try to veto the integration testing as part of the
normal build and separate it into a profile. The profile could be run during
development but otherwise be omitted from builds. It would remove the
independent verification you get from the continuous integration, but it
might be acceptable in this situation as the sample projects are pretty
static.

How do you feel about this?

On Wed, Sep 21, 2011 at 9:45 PM, Scott Carey (JIRA) <[EMAIL PROTECTED]> wrote:

>
>    [
> https://issues.apache.org/jira/browse/AVRO-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109861#comment-13109861]
>
> Scott Carey commented on AVRO-890:
> ----------------------------------
>
> For a released artifact, this is not a problem.  The archetype will work
> fine because it won't point to a SNAPSHOT.
>
> In the case of testing the archetype then, it either needs to point to a
> released version, or we must install avro-maven-plugin before the archetype
> plugin forks the build.
>
> Or we could release it and version the archetype separately from the main
> project, but that has many other serious drawbacks.
>
> > Maven archetype for creating Avro service projects
> > ---------------------------------------------------
> >
> >                 Key: AVRO-890
> >                 URL: https://issues.apache.org/jira/browse/AVRO-890
> >             Project: Avro
> >          Issue Type: Improvement
> >          Components: java
> >    Affects Versions: 1.5.4
> >            Reporter: Stephen Gargan
> >            Assignee: Stephen Gargan
> >            Priority: Minor
> >              Labels: archetype, maven
> >             Fix For: 1.6.0
> >
> >         Attachments: archetypes.patch, archetypes.patch, archetypes.patch
> >
> >
> > I've put together the beginnings of an maven archetypes subproject in the
> java module to help folks kickstart avro projects. The first archetype
> creates a simple avro based ordering service using the netty transport and
> includes an integration test for the service. The service is very naive,
> though its really only the plumbing that is important and the example is
> illustrative enough to get people going.
> > Once built, it can be added to the local archetypes catalog via
> > mvn archetype:crawl
> > and then will be available via the generate plugin
> > mvn archetype:generate
> > or it can be invoked directly as follows
> > mvn archetype:generate -DarchetypeArtifactId=avro-service-archetype
> -DarchetypeGroupId=org.apache.avro -DgroupId=org.simple
> -DartifactId=simple-service -Dversion=1.0-SNAPSHOT
> > The parent pom contains common config for generating a pom for the
> archetype that references the current avro build version. This takes some
> slight of hand with maven resources to insert the version and will be
> reusable for other archetypes in the future.
> > I intend putting together a map-reduce archetype soon and am open to
> suggestions for other archetypes that might be useful. Perhaps one that
> included the code from AVRO-883 to kick start a basic serialization project?
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>

On 09/21/2011 02:55 PM, Stephen Gargan wrote:
> As a suggestion, I could try to veto the integration testing as part of the
> normal build and separate it into a profile. The profile could be run during
> development but otherwise be omitted from builds. It would remove the
> independent verification you get from the continuous integration, but it
> might be acceptable in this situation as the sample projects are pretty
> static.

Could we change it so that this integration test is only run with 'mvn
install' and not with 'mvn verify'?

Doug

On 9/21/11 3:48 PM, "Doug Cutting" <[EMAIL PROTECTED]> wrote:

>On 09/21/2011 02:55 PM, Stephen Gargan wrote:
>> As a suggestion, I could try to veto the integration testing as part of
>>the
>> normal build and separate it into a profile. The profile could be run
>>during
>> development but otherwise be omitted from builds. It would remove the
>> independent verification you get from the continuous integration, but it
>> might be acceptable in this situation as the sample projects are pretty
>> static.
>
>Could we change it so that this integration test is only run with 'mvn
>install' and not with 'mvn verify'?

I think we can do that by binding the execution phase of the integration
test to install.  If that works, it would be the best option IMO -- we
won't catch problems with simple 'mvn test', but will surely before a
release.  These samples will rarely need to change anyway, and if so the
change should be minor.

>
>Doug

This sounds good, we'll need to veto the normal integration-testing but I
think removing the archetype build extension will take care of this. To
insure it runs before 'install' it might make sense to bind it to the
'verify' stage. I'll play around with it and see what can be done.
On Wed, Sep 21, 2011 at 11:54 PM, Scott Carey <[EMAIL PROTECTED]> wrote:

>
> On 9/21/11 3:48 PM, "Doug Cutting" <[EMAIL PROTECTED]> wrote:
>
> >On 09/21/2011 02:55 PM, Stephen Gargan wrote:
> >> As a suggestion, I could try to veto the integration testing as part of
> >>the
> >> normal build and separate it into a profile. The profile could be run
> >>during
> >> development but otherwise be omitted from builds. It would remove the
> >> independent verification you get from the continuous integration, but it
> >> might be acceptable in this situation as the sample projects are pretty
> >> static.
> >
> >Could we change it so that this integration test is only run with 'mvn
> >install' and not with 'mvn verify'?
>
> I think we can do that by binding the execution phase of the integration
> test to install.  If that works, it would be the best option IMO -- we
> won't catch problems with simple 'mvn test', but will surely before a
> release.  These samples will rarely need to change anyway, and if so the
> change should be minor.
>
> >
> >Doug
>
>
>

I think we can bind it to 'install' -- it will then run after all the
things it depends on have run 'install'.  It might end up running the test
after it packages and installs to the local repo and then fail, but that
is acceptable for the archetype IMO.  It won't 'deploy' without the test
completing however.

-Scott

On 9/21/11 4:29 PM, "Stephen Gargan" <[EMAIL PROTECTED]> wrote:

>This sounds good, we'll need to veto the normal integration-testing but I
>think removing the archetype build extension will take care of this. To
>insure it runs before 'install' it might make sense to bind it to the
>'verify' stage. I'll play around with it and see what can be done.
>
>
>On Wed, Sep 21, 2011 at 11:54 PM, Scott Carey <[EMAIL PROTECTED]>
>wrote:
>
>>
>> On 9/21/11 3:48 PM, "Doug Cutting" <[EMAIL PROTECTED]> wrote:
>>
>> >On 09/21/2011 02:55 PM, Stephen Gargan wrote:
>> >> As a suggestion, I could try to veto the integration testing as part
>>of
>> >>the
>> >> normal build and separate it into a profile. The profile could be run
>> >>during
>> >> development but otherwise be omitted from builds. It would remove the
>> >> independent verification you get from the continuous integration,
>>but it
>> >> might be acceptable in this situation as the sample projects are
>>pretty
>> >> static.
>> >
>> >Could we change it so that this integration test is only run with 'mvn
>> >install' and not with 'mvn verify'?
>>
>> I think we can do that by binding the execution phase of the integration
>> test to install.  If that works, it would be the best option IMO -- we
>> won't catch problems with simple 'mvn test', but will surely before a
>> release.  These samples will rarely need to change anyway, and if so the
>> change should be minor.
>>
>> >
>> >Doug
>>
>>
>>