Team

I have made the changes described previous to the directory structure.  It
should make the release process a little more straight forward.  The
separation of the maven plugins to their own world should also provide a
nice landing spot for archetypes.  Bryan Bende has made what appears to be
a really awesome archetype for stubbing out a nar bundle so perhaps that
will work its way there sometime.

We will still need to iterate on the RTC discussion some more.  It feels
perfect for the 80% case.  For the 20% i think we'll need to be pretty
clear about what falls in that bucket.  This is a good thing to put into a
contributors guide.  That particular document feels less critical (in my
mind anyway) than a developer guide.

Benson: Please note I added the @{project.artifactId} in the tag naming
just so we could have it in the 'maven-plugins' parent area.  If this was
useless or counterproductive please advise.  One thing if you have a moment
to explain - what is the 'platform/pom.xml' line in the configuration of
the release plugin for?  My googling-fu let me down on figuring that out.

Thanks
Joe

On Thu, Jan 15, 2015 at 5:00 PM, Joe Witt <[email protected]> wrote:

> Agreed.  Pending no clear disagreement on this path I'll make those
> adjustments tonight.  If it doesn't work out then all we did was make the
> next logical step (going to a new git repo for maven stuff) easier.
>
> Thanks
> Joe
>
> On Thu, Jan 15, 2015 at 4:58 PM, Benson Margulies <[email protected]>
> wrote:
>
>> The structure you propose would be less confusing that what we have.
>> Since I'm still too dense to follow what you wrote would go wrong if
>> we released from the current structure, I don't see any problem with
>> the new structure, either :-)  I probably need to reread your email.
>> But don't wait on me -- if no one else dislikes your proposal, do it.
>> On the RTC/CTR front, I really think that a discussion here of
>> something like this _is_ an 'R', but that's just me.
>>
>>
>> On Thu, Jan 15, 2015 at 4:44 PM, Joe Witt <[email protected]> wrote:
>> > Benson,
>> >
>> > I too would like to march forward without having to bother infra for
>> > another git repo.
>> >
>> > What if we just move the directory structure a bit such that at the root
>> > level of our git repo we have something like:
>> >
>> > - nifi [directory]
>> > - maven-plugins [directory]
>> > - README
>> > - NOTICE
>> > - DISCLAIMER
>> > - LICENSE
>> > - KEYS
>> >
>> > nifi then will contain all the stuff we have in Git today minus the
>> > nar-maven-plugin subfolder.
>> >
>> > maven-plugins will contain a single subdirectory right now which would
>> be
>> > the 'nar-maven-plugin' but we'd soon add some archetypes there too.
>> >
>> > So then we release the project and artifacts of 'maven-plugins' and then
>> > once all good we release 'nifi'.
>> >
>> > We can tag these releases and merge them to master.  Since they'd be
>> > 'parallel' to eachother in hierarchy I'm thinking there'd be no problem.
>> >
>> > Is this reasonable?  If not then I'm inclined to put in an infra request
>> > tonight.
>> >
>> > Thanks
>> > Joe
>> >
>> > On Thu, Jan 15, 2015 at 4:34 PM, Benson Margulies <
>> [email protected]>
>> > wrote:
>> >
>> >> I think I see a way to proceed that leaves people room to keep
>> discussing.
>> >>
>> >> Here's my proposed procedure:
>> >>
>> >> git checkout -b nar-maven-plugin-0.0.1-release
>> >> mvn release:prepare
>> >>  # when it prompts, enter: 0.0.1-incubating
>> >> mvn release:perform
>> >> git checkout develop
>> >> git merge nar-maven-plugin-0.0.1-release
>> >> git push
>> >> git push --tags
>> >>
>> >> git checkout master
>> >> git merge-with-some-fancy-commands-that-insist-that-the-result-is...
>> >> the-tag-for-the-release
>> >> git push
>> >>
>> >> This procedure will: (a) avoid the RTC/CTR discussion. (b) avoid the
>> >> bother of another git repo. (c) seemingly end up with all the chickens
>> >> in the correct coops.
>> >>
>> >> However, if other think that it would be less confusing to move the
>> >> plugin to a repo, by all means ask infra for the repo and we'll go
>> >> from there.
>> >>
>>
>
>

Reply via email to