You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason van Zyl <jv...@maven.org> on 2004/10/17 17:30:46 UTC
Using entities to manage dependency versions
Hi,
I noticed Bruce's blog entry about the use of entities and I just wanted
to suggest the approach that was intended for use. Entities started
being used because of some defects in the inheritance mechanism. The way
I have always used for integration across builds has been this way:
http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies
You guys use a parent POM for everything, and you might have tried this
but I think this might not be working for you because of the way you
pull in your global properties. I haven't look at your build lately but
I think you are using an ant task to pull in your global properties
which doesn't make its way into the inheritance mechanism.
You should be able to put everything in your global.properties file in
the project.properties file in your /etc directory and then the
inheritance mechanism will kick in. Currently there are three ways
people use for managing dependency versions:
o using the JAR override mechanism
o using properties files with stating versions and using interpolation
o using entities
I would definitely recommend using one of the first two. I want to
promote native mechanisms in Maven itself for dealing with these things.
There were problems with inheritance which is why people resorted to
using entities: I saw that blog entry on your use of entities and
cringed. That's definitely not something I want to promote as a best
practice. I am primarily working on m2 but I double checked with Brett
and he tells me the inheritance problems have been fixed.
I don't believe the first two methods would have worked for you because
of the use of the ant:property tag, but if you tried using the standard
form of inheritance I think you could actually use what's recommended.
If you have actually it without the ant:property task and it doesn't
work then it's a bug and needs to be fixed but people have been
reporting that inheritance generally works now in m1.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Using entities to manage dependency versions
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-10-17 at 13:26, David Jencks wrote:
> I am not an expert on this, but it might be worth checking again since
> only last week we moved from loading global.properties as ant
> properties to loading them as maven properties. If I understand
> Jason's post correctly this would be a prerequisite for his recommended
> methods working.
If you moved the properties into a project.properties file then using
the JAR override or properties should work.
This will be a question on a future survey, but one I'll ask now:
For managing dependency versions across an entire project what would you
like to see as the default mechanism?
I am obviously biased toward the JAR override as this is what I've been
using for a long while and initially implemented it to take care of a
large build like yours. One reason in particular I did it was so that I
could experiment with different versions of things in an isolated build
by turning of the JAR override but when doing reactored builds I would
turn it on and know exactly what version would be used across the board.
So this is really a question of how things would work in the future but
I would like to garner some feedback now if possible.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Using entities to manage dependency versions
Posted by David Jencks <da...@yahoo.com>.
I am not an expert on this, but it might be worth checking again since
only last week we moved from loading global.properties as ant
properties to loading them as maven properties. If I understand
Jason's post correctly this would be a prerequisite for his recommended
methods working.
david jencks
On Oct 17, 2004, at 10:13 AM, Dain Sundstrom wrote:
> We have two execution scenarios. The most common is from a reactor
> (multiproject) build, where we could use property inheritance. The
> second is directly from the module. The problem I found in the second
> scenario is it appears that the dependencies are verified (downloaded)
> before our maven code that loads the global properties file is
> executed. I have been thinking about this for a while, and think the
> easiest solution would be to have maven load a project.properties file
> from the directory of the parent project.xml file before verifying
> (downloading) dependencies. The reason we use entities is because it
> was the only thing that worked in both scenarios.
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
> On Oct 17, 2004, at 8:30 AM, Jason van Zyl wrote:
>
>> Hi,
>>
>> I noticed Bruce's blog entry about the use of entities and I just
>> wanted
>> to suggest the approach that was intended for use. Entities started
>> being used because of some defects in the inheritance mechanism. The
>> way
>> I have always used for integration across builds has been this way:
>>
>> http://maven.apache.org/reference/user-
>> guide.html#Overriding_Stated_Dependencies
>>
>> You guys use a parent POM for everything, and you might have tried
>> this
>> but I think this might not be working for you because of the way you
>> pull in your global properties. I haven't look at your build lately
>> but
>> I think you are using an ant task to pull in your global properties
>> which doesn't make its way into the inheritance mechanism.
>>
>> You should be able to put everything in your global.properties file in
>> the project.properties file in your /etc directory and then the
>> inheritance mechanism will kick in. Currently there are three ways
>> people use for managing dependency versions:
>>
>> o using the JAR override mechanism
>> o using properties files with stating versions and using interpolation
>> o using entities
>>
>> I would definitely recommend using one of the first two. I want to
>> promote native mechanisms in Maven itself for dealing with these
>> things.
>> There were problems with inheritance which is why people resorted to
>> using entities: I saw that blog entry on your use of entities and
>> cringed. That's definitely not something I want to promote as a best
>> practice. I am primarily working on m2 but I double checked with Brett
>> and he tells me the inheritance problems have been fixed.
>>
>> I don't believe the first two methods would have worked for you
>> because
>> of the use of the ant:property tag, but if you tried using the
>> standard
>> form of inheritance I think you could actually use what's recommended.
>>
>> If you have actually it without the ant:property task and it doesn't
>> work then it's a bug and needs to be fixed but people have been
>> reporting that inheritance generally works now in m1.
>>
>> --
>> jvz.
>>
>> Jason van Zyl
>> jason@maven.org
>> http://maven.apache.org
>>
>> happiness is like a butterfly: the more you chase it, the more it will
>> elude you, but if you turn your attention to other things, it will
>> come
>> and sit softly on your shoulder ...
>>
>> -- Thoreau
>
Re: Using entities to manage dependency versions
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-10-17 at 13:13, Dain Sundstrom wrote:
> We have two execution scenarios. The most common is from a reactor
> (multiproject) build, where we could use property inheritance. The
> second is directly from the module. The problem I found in the second
> scenario is it appears that the dependencies are verified (downloaded)
> before our maven code that loads the global properties file is
> executed.
Yah, but I think that is due to the loading of properties via the
ant:property task.
> I have been thinking about this for a while, and think the
> easiest solution would be to have maven load a project.properties file
> from the directory of the parent project.xml file before verifying
> (downloading) dependencies.
The JAR override should be taken into account before the dependencies
are processed. If they aren't that's a bug.
> The reason we use entities is because it
> was the only thing that worked in both scenarios.
Fair enough, but I would like to help to make it work with properties
and not entities.
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
> On Oct 17, 2004, at 8:30 AM, Jason van Zyl wrote:
>
> > Hi,
> >
> > I noticed Bruce's blog entry about the use of entities and I just
> > wanted
> > to suggest the approach that was intended for use. Entities started
> > being used because of some defects in the inheritance mechanism. The
> > way
> > I have always used for integration across builds has been this way:
> >
> > http://maven.apache.org/reference/user-
> > guide.html#Overriding_Stated_Dependencies
> >
> > You guys use a parent POM for everything, and you might have tried this
> > but I think this might not be working for you because of the way you
> > pull in your global properties. I haven't look at your build lately but
> > I think you are using an ant task to pull in your global properties
> > which doesn't make its way into the inheritance mechanism.
> >
> > You should be able to put everything in your global.properties file in
> > the project.properties file in your /etc directory and then the
> > inheritance mechanism will kick in. Currently there are three ways
> > people use for managing dependency versions:
> >
> > o using the JAR override mechanism
> > o using properties files with stating versions and using interpolation
> > o using entities
> >
> > I would definitely recommend using one of the first two. I want to
> > promote native mechanisms in Maven itself for dealing with these
> > things.
> > There were problems with inheritance which is why people resorted to
> > using entities: I saw that blog entry on your use of entities and
> > cringed. That's definitely not something I want to promote as a best
> > practice. I am primarily working on m2 but I double checked with Brett
> > and he tells me the inheritance problems have been fixed.
> >
> > I don't believe the first two methods would have worked for you because
> > of the use of the ant:property tag, but if you tried using the standard
> > form of inheritance I think you could actually use what's recommended.
> >
> > If you have actually it without the ant:property task and it doesn't
> > work then it's a bug and needs to be fixed but people have been
> > reporting that inheritance generally works now in m1.
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@maven.org
> > http://maven.apache.org
> >
> > happiness is like a butterfly: the more you chase it, the more it will
> > elude you, but if you turn your attention to other things, it will come
> > and sit softly on your shoulder ...
> >
> > -- Thoreau
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Using entities to manage dependency versions
Posted by Dain Sundstrom <ds...@gluecode.com>.
We have two execution scenarios. The most common is from a reactor
(multiproject) build, where we could use property inheritance. The
second is directly from the module. The problem I found in the second
scenario is it appears that the dependencies are verified (downloaded)
before our maven code that loads the global properties file is
executed. I have been thinking about this for a while, and think the
easiest solution would be to have maven load a project.properties file
from the directory of the parent project.xml file before verifying
(downloading) dependencies. The reason we use entities is because it
was the only thing that worked in both scenarios.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Oct 17, 2004, at 8:30 AM, Jason van Zyl wrote:
> Hi,
>
> I noticed Bruce's blog entry about the use of entities and I just
> wanted
> to suggest the approach that was intended for use. Entities started
> being used because of some defects in the inheritance mechanism. The
> way
> I have always used for integration across builds has been this way:
>
> http://maven.apache.org/reference/user-
> guide.html#Overriding_Stated_Dependencies
>
> You guys use a parent POM for everything, and you might have tried this
> but I think this might not be working for you because of the way you
> pull in your global properties. I haven't look at your build lately but
> I think you are using an ant task to pull in your global properties
> which doesn't make its way into the inheritance mechanism.
>
> You should be able to put everything in your global.properties file in
> the project.properties file in your /etc directory and then the
> inheritance mechanism will kick in. Currently there are three ways
> people use for managing dependency versions:
>
> o using the JAR override mechanism
> o using properties files with stating versions and using interpolation
> o using entities
>
> I would definitely recommend using one of the first two. I want to
> promote native mechanisms in Maven itself for dealing with these
> things.
> There were problems with inheritance which is why people resorted to
> using entities: I saw that blog entry on your use of entities and
> cringed. That's definitely not something I want to promote as a best
> practice. I am primarily working on m2 but I double checked with Brett
> and he tells me the inheritance problems have been fixed.
>
> I don't believe the first two methods would have worked for you because
> of the use of the ant:property tag, but if you tried using the standard
> form of inheritance I think you could actually use what's recommended.
>
> If you have actually it without the ant:property task and it doesn't
> work then it's a bug and needs to be fixed but people have been
> reporting that inheritance generally works now in m1.
>
> --
> jvz.
>
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
> -- Thoreau
Re: Using entities to manage dependency versions
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2004-10-17 at 12:00, Bruce Snyder wrote:
> Jason van Zyl wrote:
> The main reason I began using the entity solution was because I could
> not get the property inheritance working at all. However, upon further
> investigation by my friend Jeff Genender, it appears that all the
> properties I had specified when trying to get inheritance working
> contained a hyphen. Evidently Maven tries to do arithmetic on anything
> with a hyphen.
Yah, that's Jexl and there's not much that can be done about that in m1.
Jelly and Jexl went in the dust bin for m2. They are just too quirky and
generally unreliable, but gotta live with them in m1.
> If I replace the hyphen in the property names with an
> underscore, property inheritance works like it should. Unfortunately it
> took a *lot* of experimentation to figure this out. This *really,
> really* should be documented on the Maven site. This subtlty hung me up
> for quite a long while. Having had this documented in the Maven FAQ is a
> good start. Of course, I haven't looked at the Maven docs lately, maybe
> it's already there.
>
> BTW, I have used the maven.jar.override property in the past, but only
> to point to jars in a project's lib directory.
Yah, I've typically only used it for specifying dependency versions. But
I added the path pointer for the commons builds a long, long time ago.
> Thanks for chiming in on this, Jason.
No problem. Like I said before, I'm working pretty much entirely on m2
but I will help with this particular issue because I want native
mechanisms to be used and I don't believe entities are required at all
to do this sort of thing. It was required at one point but not any
longer.
> Bruce
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Using entities to manage dependency versions
Posted by Bruce Snyder <fe...@frii.com>.
Jason van Zyl wrote:
> I noticed Bruce's blog entry about the use of entities and I just wanted
> to suggest the approach that was intended for use. Entities started
> being used because of some defects in the inheritance mechanism. The way
> I have always used for integration across builds has been this way:
>
> http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies
>
> You guys use a parent POM for everything, and you might have tried this
> but I think this might not be working for you because of the way you
> pull in your global properties. I haven't look at your build lately but
> I think you are using an ant task to pull in your global properties
> which doesn't make its way into the inheritance mechanism.
>
> You should be able to put everything in your global.properties file in
> the project.properties file in your /etc directory and then the
> inheritance mechanism will kick in. Currently there are three ways
> people use for managing dependency versions:
>
> o using the JAR override mechanism
> o using properties files with stating versions and using interpolation
> o using entities
>
> I would definitely recommend using one of the first two. I want to
> promote native mechanisms in Maven itself for dealing with these things.
> There were problems with inheritance which is why people resorted to
> using entities: I saw that blog entry on your use of entities and
> cringed. That's definitely not something I want to promote as a best
> practice. I am primarily working on m2 but I double checked with Brett
> and he tells me the inheritance problems have been fixed.
>
> I don't believe the first two methods would have worked for you because
> of the use of the ant:property tag, but if you tried using the standard
> form of inheritance I think you could actually use what's recommended.
>
> If you have actually it without the ant:property task and it doesn't
> work then it's a bug and needs to be fixed but people have been
> reporting that inheritance generally works now in m1.
The main reason I began using the entity solution was because I could
not get the property inheritance working at all. However, upon further
investigation by my friend Jeff Genender, it appears that all the
properties I had specified when trying to get inheritance working
contained a hyphen. Evidently Maven tries to do arithmetic on anything
with a hyphen. If I replace the hyphen in the property names with an
underscore, property inheritance works like it should. Unfortunately it
took a *lot* of experimentation to figure this out. This *really,
really* should be documented on the Maven site. This subtlty hung me up
for quite a long while. Having had this documented in the Maven FAQ is a
good start. Of course, I haven't looked at the Maven docs lately, maybe
it's already there.
BTW, I have used the maven.jar.override property in the past, but only
to point to jars in a project's lib directory.
Thanks for chiming in on this, Jason.
Bruce
--
perl -e 'print
unpack("u30","<0G)U8V4\\@4VYY9&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html