The DependencyConvergence rule [1] we were discussing earlier on this
list can partly solve the present problem. DependencyConvergence simply
won't allow inconsistent set of deps. - I.e. it won't allow me to
upgrade Accounts in Inventory unless there is the same version of
Commons in both Accounts and Inventory. I say *partly* because
DependencyConvergence will not say anything if my consistent set of deps
is outdated.
I will introduce DependencyConvergence after all components are upgraded
to WF10.
I still think that speaking with one's upstream before releasing is the
most flexible and reliable way of solving the present problem.
Yes, but I think that a plugin as described should help also.
With DependencyConvergence we might have the commons versions correct but both components
in a wrong (but same) version of accounts (for example).
I think if we might mark the target versions and check that a module is using it (without
updating parent/bom) it can help.
Cons is that we need to create the plugin :-).
-- P
[1]
http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
[2]
http://stackoverflow.com/a/16239482
On 2015-12-16 00:37, Lucas Ponce wrote:
>>
>> I think this might be it:
>>
>>
http://www.mojohaus.org/versions-maven-plugin/display-property-updates-mo...
>>
>
>
> It is interesting. But perhaps we might need something ad-hoc, in the
> srcdeps spirit.
>
> For example, in the versions repo we can target the Alpha8 versions, i.e.
> accounts 1.1.4.Final, perhaps, accounts might have other upper releases
> 2.0.0.Final for WF10, but the plugin can warn me that I'm not using the
> 1.1.4.Final.
>
> Accounts would be responsible (or someone else) to put the right version on
> the "versions repo" (which can be just a properties file on github).
>
> So, we would work as today, but this non-intrusive plugin could help us to
> coordinate in some degree.
>
>
>
>
>
>> On Tuesday, December 15, 2015 17:50:59 Lucas Ponce wrote:
>>>> Actually, this does not imply circular workflow, just a painful one :)
>>>>
>>>> 1) I want to release a new version of inventory and decide what its
>>>> version
>>>> is
>>>> gonna be.
>>>>
>>>> 2) I update parent POM with the new inventory version and release the
>>>> parent POM. Note that at this point in time no one is using this
version
>>>> of parent and that inventory hasn't been released yet.
>>>>
>>>> 3) I update inventory with the new parent POM version and release it
>>>> with
>>>> the intended version.
>>>>
>>>> So to break the circle outlined by Peter, you have to basically
>>>> introduce
>>>> a
>>>> race condition and also double the number of releases we do.
>>>>
>>>> Note that the above workflow would work with a BOM, too.
>>>
>>> Out of curiosity, then how other projects works ? Can we adopt some best
>>> practice to reduce our complexity ?
>>>
>>> There are projects using bom and parent, and they have versions on both.
>>>
>>> If at the end of the story, there is a manual step of synchronization
>>> (i.e.
>>> I have to go to a place a look which version I need), I would like to see
>>> if we can get benefit in someway without adding circular dependencies or
>>> painful process.
>>>
>>> With the srcdeps plugin, we added an additional feature that helped in a
>>> sense.
>>>
>>> Is there a possibility to sync some property versions without entering on
>>> the circular dependency ?
>>>
>>> I am brainstorming, but what about a repo where we put these versions,
>>> and
>>> we can have just a plugin to warn if we are using correct ones ? (without
>>> having to place it on parent).
>>>
>>> I.e. In alerts I'm using a parent X and bus Y, and this plugin can
check
>>> from the repo that my versions are not updated.
>>>
>>> So, manual step is not avoid but we are warned that for alpha8 target
>>> versions are a,b,c.
>>>
>>> When I release a new alerts, I can update that in the repo.
>>>
>>> Thoughts ?
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev