On Fri, 17 Jul 2020 at 16:53, Dennis Lundberg <[email protected]> wrote:
> Hi, > > Given that I've been gone for some time from this list things might have > changed. If that's the case I'm sure someone will correct me :) > > But it used to be the way to do things when you have a chain of related > components, which is quite common in Maven. If we take > maven-resouces-plugin, which I'm working on right now, it has a dependency > on maven-filtering which contains all the code for filtering resources. > That in turn depends on maven-shared-util, which is specified as a SNAPSHOT > in maven-filtering. When the time comes to make a release, all these > SNAPSHOT dependencies will need to be addressed. So you have a "release > train" where you will start with the component furthest down the dependency > tree, release that and then continue on with the next one until you reach > the top. In my example the order will be maven-shared-util, maven-filtering > and finally maven-resources-plugin. > to make life easy we already did release bulk in such case (which is perfectly acceptable) > > Dennis Lundberg > > > Den tors 16 juli 2020 kl 17:04 skrev Elliotte Rusty Harold < > [email protected]>: > > > I happened to notice today that the maven-resources-plugin at HEAD in > > the repo (not the released version) depends on the latest SNAPSHOT of > > maven-filtering: > > > > https://github.com/apache/maven-resources-plugin/blob/master/pom.xml > > > > Is this generally OK? That is can we commit code to a repo that > > depends on an unreleased SNAPSHOT version of another plugin/library? > > If this is considered kosher, it would help unblock some work on the > > maven-dependency-plugin. > > > > > > -- > > Elliotte Rusty Harold > > [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
