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 <rmannibu...@gmail.com>: > 2014-10-16 14:40 GMT+02:00 sebb <seb...@gmail.com>: >> On 16 October 2014 13:02, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: >>> 2014-10-16 13:48 GMT+02:00 sebb <seb...@gmail.com>: >>>> On 16 October 2014 09:35, Thomas Vandahl <t...@apache.org> wrote: >>>>> On 16.10.14 02:06, sebb wrote: >>>>>> On 16 October 2014 00:47, Olivier Lamy <ol...@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-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
