commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [JCS] release?
Date Wed, 22 Oct 2014 19:07:15 GMT
hi

since recently i get:

[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single
(source-release-assembly) on project commons-jcs: Error reading
assemblies: Error locating assembly descriptor:
src/main/assembly/src.xml
[INFO] [ERROR]
[INFO] [ERROR] [1] [INFO] Searching for file location:
/home/rmannibucau/dev/Apache/commons-jcs-trunk/src/main/assembly/src.xml
[INFO] [ERROR]
[INFO] [ERROR] [2] [INFO] File:
/home/rmannibucau/dev/Apache/commons-jcs-trunk/src/main/assembly/src.xml
does not exist.
[INFO] [ERROR]
[INFO] [ERROR] [3] [INFO] File:
/home/rmannibucau/dev/Apache/commons-jcs-trunk/src/main/assembly/src.xml
does not exist.
[INFO] [ERROR] -> [Help 1]
[INFO] [ERROR]

is it due to parent update?


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <rmannibucau@gmail.com>:
> 2014-10-16 14:40 GMT+02:00 sebb <sebbaz@gmail.com>:
>> On 16 October 2014 13:02, Romain Manni-Bucau <rmannibucau@gmail.com> wrote:
>>> 2014-10-16 13:48 GMT+02:00 sebb <sebbaz@gmail.com>:
>>>> On 16 October 2014 09:35, Thomas Vandahl <tv@apache.org> wrote:
>>>>> On 16.10.14 02:06, sebb wrote:
>>>>>> On 16 October 2014 00:47, Olivier Lamy <olamy@apache.org> wrote:
>>>>>>> Perso I don' get the point to use this version number at the
end of
>>>>>>> the artifactId
>>>>>>
>>>>>> The idea is that if the package name has to be changed again, i.e.
to
>>>>>> org.apache.commons.jcs2, then the artifactId would become commons-jcs2
>>>>>> so that they agree with each other.
>>>>>
>>>>> I consider this rule a bit strict, to be frank. I'd like to think that
>>>>> the problem of a broken API could be solved differently (by deliberately
>>>>> renaming API classes for example) but i can live with it for now.
>>>>
>>>> Renaming API classes will break compatibility unless one keeps the old
>>>> classes as well.
>>>>
>>>> Creating new classes and deprecating the old ones is a valid strategy,
>>>> but if one ever wants to get rid of the deprecated classes, it is
>>>> necessary to make a complete break.
>>>>
>>>> It is essential that a given class name only appears in a single Maven
>>>> (groupId,artifactId) pair, otherwise jar hell may result.
>>>
>>> + version + type, having twice the same artifact with different
>>> versions is not correct
>>
>> Not sure about type, but version is not involved here.
>>
>
> That's what I mean. You can't have 2 versions with the same
> gId:aId:type. So no need to change aId.
>
>> Maven ensures that only one version of a given (gId,aId) pair is
>> present on the classpath.
>> Once a class is added to a specific version, it must appear in all
>> later versions with the same pair.
>>
>>>> It is also essential that within a Maven pair, classes are not dropped
>>>> between versions (unless the class is not part of the public API)
>>>> otherwise there will be binary compatibility issues.
>>>>
>>>
>>> Main issue is it duplicates a bunch if binaries for free and most of
>>> users could use N+1 without being impacted.
>>
>> No idea what that means.
>
> In TomEE the stack uses [lang], then [lang3] was created and now TomEE
> needs [lang] + [lang3] where actually it only needs [lang] features,
> ie suppose package didn't change then we wouldn't have had any issue.
> So it means you tend to import multiple versions of the same lib just
> cause few parts were broken even if it doesn't affect you. That's a
> bit sad IMO.
>
>>
>>> it means this rule is too strict.
>>
>> Why?
>>
>>> Best is to externalize removed binaries in a -compatibility
>>> jar like did maven. It avoids the binary duplication and allow to go
>>> ahead on main stream (IMHO).
>>
>> The later version would not be a drop-in replacement.
>> Sounds like users that needed to use the removed classes would need to
>> add an extra dependency to the POM.
>>
>>>>> Bye, Thomas.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message