Re: Parent vs BOM
Hey John, thanks for the clarification. I just was a little bit confused. :) In this case +1 for moving the bom up. I'm not sure if it will be used a lot by end users but it doesn't harm to have it and it will reduce the size of our parent pom. Christian 2014/1/6 John D. Ament > Christian, > > Sorry missed your reply! > > Yes, you're technically right, what's here is actually the BOM based > on standard def: > https://github.com/apache/deltaspike/blob/master/deltaspike/dist/pom.xml > so really what's in the bom folder right now isn't useful. > > So basically, restating what I said previously but pointing to this pom > file. > > John > > On Tue, Dec 24, 2013 at 3:50 AM, Christian Kaltepoth > wrote: > > Hey John, > > > > just to clear up the situation a bit. AFAIK the bom artifact > > (deltaspike/dist/bom/pom.xml) isn't actually a real bom as it defines all > > the modules as direct dependencies which is more a "depchain". The real > pom > > is the parent (deltaspike/dist/pom.xml) as it defines the versions of the > > modules in a section, correct? > > > > Christian > > > > > > > > 2013/12/23 John D. Ament > > > >> Romain, > >> > >> Right. My hope is that internally we can list the cross module > >> dependencies in one place. If we're going to prep docs on how a new > >> dev can bring deltaspike to their project, using a bom is a simple > >> tool. > >> > >> On Mon, Dec 23, 2013 at 1:06 AM, Romain Manni-Bucau > >> wrote: > >> > +-0 while deltaspike doesnt use itself the bom (they lead too often to > >> dep > >> > issues in practise) > >> > Le 23 déc. 2013 02:09, "John D. Ament" a > écrit > >> : > >> > > >> >> Hi all > >> >> > >> >> Recently for the binary distribution task, I added a bom. I added > >> >> this because the parent pom includes our dependencies, as well as our > >> >> developer list. For someone importing the project to build against, > I > >> >> figured this was a bad idea (we would show as developers in that > >> >> imported pom). However, this ended up adding some double entry. > >> >> > >> >> So I'd like to propose moving this bom up a few directories, and > leave > >> >> this up as the only place to have the modules listed. Importing this > >> >> one into our parent. > >> >> > >> >> WDYT? > >> >> > >> >> John > >> >> > >> > > > > > > > > -- > > Christian Kaltepoth > > Blog: http://blog.kaltepoth.de/ > > Twitter: http://twitter.com/chkal > > GitHub: https://github.com/chkal > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: Parent vs BOM
Christian, Sorry missed your reply! Yes, you're technically right, what's here is actually the BOM based on standard def: https://github.com/apache/deltaspike/blob/master/deltaspike/dist/pom.xml so really what's in the bom folder right now isn't useful. So basically, restating what I said previously but pointing to this pom file. John On Tue, Dec 24, 2013 at 3:50 AM, Christian Kaltepoth wrote: > Hey John, > > just to clear up the situation a bit. AFAIK the bom artifact > (deltaspike/dist/bom/pom.xml) isn't actually a real bom as it defines all > the modules as direct dependencies which is more a "depchain". The real pom > is the parent (deltaspike/dist/pom.xml) as it defines the versions of the > modules in a section, correct? > > Christian > > > > 2013/12/23 John D. Ament > >> Romain, >> >> Right. My hope is that internally we can list the cross module >> dependencies in one place. If we're going to prep docs on how a new >> dev can bring deltaspike to their project, using a bom is a simple >> tool. >> >> On Mon, Dec 23, 2013 at 1:06 AM, Romain Manni-Bucau >> wrote: >> > +-0 while deltaspike doesnt use itself the bom (they lead too often to >> dep >> > issues in practise) >> > Le 23 déc. 2013 02:09, "John D. Ament" a écrit >> : >> > >> >> Hi all >> >> >> >> Recently for the binary distribution task, I added a bom. I added >> >> this because the parent pom includes our dependencies, as well as our >> >> developer list. For someone importing the project to build against, I >> >> figured this was a bad idea (we would show as developers in that >> >> imported pom). However, this ended up adding some double entry. >> >> >> >> So I'd like to propose moving this bom up a few directories, and leave >> >> this up as the only place to have the modules listed. Importing this >> >> one into our parent. >> >> >> >> WDYT? >> >> >> >> John >> >> >> > > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal
Re: Parent vs BOM
Hey John, just to clear up the situation a bit. AFAIK the bom artifact (deltaspike/dist/bom/pom.xml) isn't actually a real bom as it defines all the modules as direct dependencies which is more a "depchain". The real pom is the parent (deltaspike/dist/pom.xml) as it defines the versions of the modules in a section, correct? Christian 2013/12/23 John D. Ament > Romain, > > Right. My hope is that internally we can list the cross module > dependencies in one place. If we're going to prep docs on how a new > dev can bring deltaspike to their project, using a bom is a simple > tool. > > On Mon, Dec 23, 2013 at 1:06 AM, Romain Manni-Bucau > wrote: > > +-0 while deltaspike doesnt use itself the bom (they lead too often to > dep > > issues in practise) > > Le 23 déc. 2013 02:09, "John D. Ament" a écrit > : > > > >> Hi all > >> > >> Recently for the binary distribution task, I added a bom. I added > >> this because the parent pom includes our dependencies, as well as our > >> developer list. For someone importing the project to build against, I > >> figured this was a bad idea (we would show as developers in that > >> imported pom). However, this ended up adding some double entry. > >> > >> So I'd like to propose moving this bom up a few directories, and leave > >> this up as the only place to have the modules listed. Importing this > >> one into our parent. > >> > >> WDYT? > >> > >> John > >> > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: Parent vs BOM
Romain, Right. My hope is that internally we can list the cross module dependencies in one place. If we're going to prep docs on how a new dev can bring deltaspike to their project, using a bom is a simple tool. On Mon, Dec 23, 2013 at 1:06 AM, Romain Manni-Bucau wrote: > +-0 while deltaspike doesnt use itself the bom (they lead too often to dep > issues in practise) > Le 23 déc. 2013 02:09, "John D. Ament" a écrit : > >> Hi all >> >> Recently for the binary distribution task, I added a bom. I added >> this because the parent pom includes our dependencies, as well as our >> developer list. For someone importing the project to build against, I >> figured this was a bad idea (we would show as developers in that >> imported pom). However, this ended up adding some double entry. >> >> So I'd like to propose moving this bom up a few directories, and leave >> this up as the only place to have the modules listed. Importing this >> one into our parent. >> >> WDYT? >> >> John >>
Re: Parent vs BOM
+-0 while deltaspike doesnt use itself the bom (they lead too often to dep issues in practise) Le 23 déc. 2013 02:09, "John D. Ament" a écrit : > Hi all > > Recently for the binary distribution task, I added a bom. I added > this because the parent pom includes our dependencies, as well as our > developer list. For someone importing the project to build against, I > figured this was a bad idea (we would show as developers in that > imported pom). However, this ended up adding some double entry. > > So I'd like to propose moving this bom up a few directories, and leave > this up as the only place to have the modules listed. Importing this > one into our parent. > > WDYT? > > John >
Parent vs BOM
Hi all Recently for the binary distribution task, I added a bom. I added this because the parent pom includes our dependencies, as well as our developer list. For someone importing the project to build against, I figured this was a bad idea (we would show as developers in that imported pom). However, this ended up adding some double entry. So I'd like to propose moving this bom up a few directories, and leave this up as the only place to have the modules listed. Importing this one into our parent. WDYT? John
