[parent][commons-release-plugin] status?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[parent][commons-release-plugin] status?

garydgregory
Hi Rob and All:

What do we think about adding [commons-release-plugin] to [parent] and
releasing?

Should the sequence be:

- Release commons-release-plugin 1.1
- Add commons-release-plugin to parent and release parent.
- Try a Commons component release using the new parent?

Rob: As the creator of commons-release-plugin, would you be willing to
perform the above and update our release documentation?

Thank you,
Gary
Reply | Threaded
Open this post in threaded view
|

Re: [parent][commons-release-plugin] status?

Rob Tompkins


> On Feb 22, 2018, at 3:24 PM, Gary Gregory <[hidden email]> wrote:
>
> Hi Rob and All:
>
> What do we think about adding [commons-release-plugin] to [parent] and
> releasing?
>
> Should the sequence be:
>
> - Release commons-release-plugin 1.1
> - Add commons-release-plugin to parent and release parent.
> - Try a Commons component release using the new parent?
>
> Rob: As the creator of commons-release-plugin, would you be willing to
> perform the above and update our release documentation?
>

Yes. I’ll work towards that. I’m close to getting 1.1 up and out as is. I’ll lazy vote it i think.

-Rob

> Thank you,
> Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [parent][commons-release-plugin] status?

garydgregory
On Thu, Feb 22, 2018 at 2:25 PM, Rob Tompkins <[hidden email]> wrote:

>
>
> > On Feb 22, 2018, at 3:24 PM, Gary Gregory <[hidden email]>
> wrote:
> >
> > Hi Rob and All:
> >
> > What do we think about adding [commons-release-plugin] to [parent] and
> > releasing?
> >
> > Should the sequence be:
> >
> > - Release commons-release-plugin 1.1
> > - Add commons-release-plugin to parent and release parent.
> > - Try a Commons component release using the new parent?
> >
> > Rob: As the creator of commons-release-plugin, would you be willing to
> > perform the above and update our release documentation?
> >
>
> Yes. I’ll work towards that. I’m close to getting 1.1 up and out as is.
> I’ll lazy vote it i think.
>

That sounds good to me.

Gary


>
> -Rob
>
> > Thank you,
> > Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [parent][commons-release-plugin] status?

Rob Tompkins
I’m wondering how multi-module projects will do with the plugin in the parent pom. I say this because when I’ve declared the release plugin in the top-level pom.xml of a project, I’ve had issues, but after moving it down into the “dist” project of the multi-module build it worked. Basically, we don’t want the plugin to make its way down into the other sub-projects.

I suppose before publishing 1.1, I should get it working with the parent in a multi-module project. I’ll work on that next.

-Rob

> On Feb 22, 2018, at 4:39 PM, Gary Gregory <[hidden email]> wrote:
>
> On Thu, Feb 22, 2018 at 2:25 PM, Rob Tompkins <[hidden email]> wrote:
>
>>
>>
>>> On Feb 22, 2018, at 3:24 PM, Gary Gregory <[hidden email]>
>> wrote:
>>>
>>> Hi Rob and All:
>>>
>>> What do we think about adding [commons-release-plugin] to [parent] and
>>> releasing?
>>>
>>> Should the sequence be:
>>>
>>> - Release commons-release-plugin 1.1
>>> - Add commons-release-plugin to parent and release parent.
>>> - Try a Commons component release using the new parent?
>>>
>>> Rob: As the creator of commons-release-plugin, would you be willing to
>>> perform the above and update our release documentation?
>>>
>>
>> Yes. I’ll work towards that. I’m close to getting 1.1 up and out as is.
>> I’ll lazy vote it i think.
>>
>
> That sounds good to me.
>
> Gary
>
>
>>
>> -Rob
>>
>>> Thank you,
>>> Gary
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [parent][commons-release-plugin] status?

Gilles Sadowski
On Fri, 23 Feb 2018 07:07:27 -0500, Rob Tompkins wrote:

> I’m wondering how multi-module projects will do with the plugin in
> the parent pom. I say this because when I’ve declared the release
> plugin in the top-level pom.xml of a project, I’ve had issues, but
> after moving it down into the “dist” project of the multi-module
> build
> it worked. Basically, we don’t want the plugin to make its way down
> into the other sub-projects.
>
> I suppose before publishing 1.1, I should get it working with the
> parent in a multi-module project. I’ll work on that next.

If there will remain a "dist" module, I don't see the need to
"use" the plugin at the top-level; it can be declared in "dist"
only.
However, having "dist" is today's situation; I thought that one
of the aims was to be able to do without.
Preventing recursing into sub-modules sounds an "anti-maven"
way (IIUC).
Why can't an approach with a profile be used (similar to the
aggregation of, e.g., Jacoco outputs)?

Regards,
Gilles

>
> -Rob
>
>> On Feb 22, 2018, at 4:39 PM, Gary Gregory <[hidden email]>
>> wrote:
>>
>> On Thu, Feb 22, 2018 at 2:25 PM, Rob Tompkins <[hidden email]>
>> wrote:
>>
>>>
>>>
>>>> On Feb 22, 2018, at 3:24 PM, Gary Gregory <[hidden email]>
>>> wrote:
>>>>
>>>> Hi Rob and All:
>>>>
>>>> What do we think about adding [commons-release-plugin] to [parent]
>>>> and
>>>> releasing?
>>>>
>>>> Should the sequence be:
>>>>
>>>> - Release commons-release-plugin 1.1
>>>> - Add commons-release-plugin to parent and release parent.
>>>> - Try a Commons component release using the new parent?
>>>>
>>>> Rob: As the creator of commons-release-plugin, would you be
>>>> willing to
>>>> perform the above and update our release documentation?
>>>>
>>>
>>> Yes. I’ll work towards that. I’m close to getting 1.1 up and out as
>>> is.
>>> I’ll lazy vote it i think.
>>>
>>
>> That sounds good to me.
>>
>> Gary
>>
>>
>>>
>>> -Rob
>>>
>>>> Thank you,
>>>> Gary
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [parent][commons-release-plugin] status?

Rob Tompkins


> On Feb 23, 2018, at 7:23 AM, Gilles <[hidden email]> wrote:
>
> On Fri, 23 Feb 2018 07:07:27 -0500, Rob Tompkins wrote:
>> I’m wondering how multi-module projects will do with the plugin in
>> the parent pom. I say this because when I’ve declared the release
>> plugin in the top-level pom.xml of a project, I’ve had issues, but
>> after moving it down into the “dist” project of the multi-module build
>> it worked. Basically, we don’t want the plugin to make its way down
>> into the other sub-projects.
>>
>> I suppose before publishing 1.1, I should get it working with the
>> parent in a multi-module project. I’ll work on that next.
>
> If there will remain a "dist" module, I don't see the need to
> "use" the plugin at the top-level; it can be declared in "dist"
> only.
> However, having "dist" is today's situation; I thought that one
> of the aims was to be able to do without.
> Preventing recursing into sub-modules sounds an "anti-maven"
> way (IIUC).
> Why can't an approach with a profile be used (similar to the
> aggregation of, e.g., Jacoco outputs)?

I think these are good points, but the problem becomes that we only want the plugin to run in the location where the dists reside, regardless of location, still implying a one time run. So when we declare it in the parent pom, it descends into all of the projects and isn’t run in a single location only. I suppose, though, I could make it only actionable when there are dist files in the “attached” artifacts or in the staging directory. That could get me around the problem. But, that feels hacky.

-Rob

>
> Regards,
> Gilles
>
>>
>> -Rob
>>
>>> On Feb 22, 2018, at 4:39 PM, Gary Gregory <[hidden email]> wrote:
>>>
>>> On Thu, Feb 22, 2018 at 2:25 PM, Rob Tompkins <[hidden email]> wrote:
>>>
>>>>
>>>>
>>>>> On Feb 22, 2018, at 3:24 PM, Gary Gregory <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Hi Rob and All:
>>>>>
>>>>> What do we think about adding [commons-release-plugin] to [parent] and
>>>>> releasing?
>>>>>
>>>>> Should the sequence be:
>>>>>
>>>>> - Release commons-release-plugin 1.1
>>>>> - Add commons-release-plugin to parent and release parent.
>>>>> - Try a Commons component release using the new parent?
>>>>>
>>>>> Rob: As the creator of commons-release-plugin, would you be willing to
>>>>> perform the above and update our release documentation?
>>>>>
>>>>
>>>> Yes. I’ll work towards that. I’m close to getting 1.1 up and out as is.
>>>> I’ll lazy vote it i think.
>>>>
>>>
>>> That sounds good to me.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> -Rob
>>>>
>>>>> Thank you,
>>>>> Gary
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [parent][commons-release-plugin] status?

Gilles Sadowski
On Fri, 23 Feb 2018 07:29:54 -0500, Rob Tompkins wrote:

>> On Feb 23, 2018, at 7:23 AM, Gilles <[hidden email]>
>> wrote:
>>
>> On Fri, 23 Feb 2018 07:07:27 -0500, Rob Tompkins wrote:
>>> I’m wondering how multi-module projects will do with the plugin in
>>> the parent pom. I say this because when I’ve declared the release
>>> plugin in the top-level pom.xml of a project, I’ve had issues, but
>>> after moving it down into the “dist” project of the multi-module
>>> build
>>> it worked. Basically, we don’t want the plugin to make its way down
>>> into the other sub-projects.
>>>
>>> I suppose before publishing 1.1, I should get it working with the
>>> parent in a multi-module project. I’ll work on that next.
>>
>> If there will remain a "dist" module, I don't see the need to
>> "use" the plugin at the top-level; it can be declared in "dist"
>> only.
>> However, having "dist" is today's situation; I thought that one
>> of the aims was to be able to do without.
>> Preventing recursing into sub-modules sounds an "anti-maven"
>> way (IIUC).
>> Why can't an approach with a profile be used (similar to the
>> aggregation of, e.g., Jacoco outputs)?
>
> I think these are good points, but the problem becomes that we only
> want the plugin to run in the location where the dists reside,
> regardless of location, still implying a one time run. So when we
> declare it in the parent pom, it descends into all of the projects
> and
> isn’t run in a single location only. I suppose, though, I could make
> it only actionable when there are dist files in the “attached”
> artifacts or in the staging directory. That could get me around the
> problem. But, that feels hacky.

Hacky as it looks, using profile-triggering files seems the
de-facto accepted way to selectively enable some functionality.
We could have a "profile.dist.artefact" file that indicates to
the plugin to look for the JAR file.

Gilles

>
> -Rob
>
>>
>> Regards,
>> Gilles
>>
>>>
>>> -Rob
>>>
>>>> On Feb 22, 2018, at 4:39 PM, Gary Gregory <[hidden email]>
>>>> wrote:
>>>>
>>>> On Thu, Feb 22, 2018 at 2:25 PM, Rob Tompkins <[hidden email]>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>>> On Feb 22, 2018, at 3:24 PM, Gary Gregory
>>>>>> <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> Hi Rob and All:
>>>>>>
>>>>>> What do we think about adding [commons-release-plugin] to
>>>>>> [parent] and
>>>>>> releasing?
>>>>>>
>>>>>> Should the sequence be:
>>>>>>
>>>>>> - Release commons-release-plugin 1.1
>>>>>> - Add commons-release-plugin to parent and release parent.
>>>>>> - Try a Commons component release using the new parent?
>>>>>>
>>>>>> Rob: As the creator of commons-release-plugin, would you be
>>>>>> willing to
>>>>>> perform the above and update our release documentation?
>>>>>>
>>>>>
>>>>> Yes. I’ll work towards that. I’m close to getting 1.1 up and out
>>>>> as is.
>>>>> I’ll lazy vote it i think.
>>>>>
>>>>
>>>> That sounds good to me.
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> -Rob
>>>>>
>>>>>> Thank you,
>>>>>> Gary
>>>>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]