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,
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 previo
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
mod
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
+-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
>
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). Ho
