Hi, actually I was wrong, the fix is trivial. We have all the information to check whether the release is "displayed".
I created a pull request - https://github.com/hibernate/hibernate.org/pull/97 I would have pushed it already, but it seems there is a problem with the CI environment. I pushed to staging and the build failed due to a missing Ruby/Rake setup. Not sure whether this is related to the recent changes/ work on the CI servers. If someone who knows this stuff could have a look, it would be great. --Hardy > On Tue, Aug 25, 2015 at 01:33:46PM +0200, Emmanuel Bernard wrote: > > I'd like to keep them around > > :-) Funny, I thought I was the only one who wants to keep them around. > For me they are kind of part of the project history. > > > we could avoid the maven fetch dance for > > display=false releases. > > True. I actually looked quickly into this last week when I noticed > the problem as well as part of the Docker setup. The problem is that > the current helper does not parse the content of the file. It is purely > based on the file/directory structure. So, one would also need to parse > the file itself as YAML and extract the 'release' property. Probably not > hard. Maybe I can have another look. > > The other option is of course a different cache directory. The files are > already > cached and no download occurs if the pom can be found in the local cache. > The problem is the files are cached in the general awestruct _tmp directory > which we delete on 'clean'. By just changing this cache dir to a another > project > relative or even user specific location we would skip the problem as well. > On the down-side we might miss out on "true" clean which removes all temporary > data. This could become an issue, if for example a corrupted pom gets into > the cache.
pgp34iusHAyFc.pgp
Description: PGP signature
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
