You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Martin Cooper <ma...@apache.org> on 2004/02/27 20:19:00 UTC
[OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build available)
"Joe Germuska" <Jo...@Germuska.com> wrote in message
news:a06020409bc653226ae85@[192.168.2.81]...
> >Given that Maven still hasn't reached an official 1.0 release in almost 3
> >years of development.....
>
> hey, now... Struts 1.1 took a darn long time! I bet they're in the
> same boat. Plenty of people who don't really track version numbers
> are using it happily, so the urge to actually cut a release is not
> too strong.
I'm not claiming we're angels, but we're doing a lot better than Maven is.
;-) From Struts 1.0.2 Final to Struts 1.1 Final took 1 year, 4 months.
During that time, people still had a Final release to work with. Maven has
been in development for almost *3* years, with *no* Final release to work
with...
>
> >That said, there are some intrepid Maven fans who are working on getting
the
> >Maven build for Struts to the same point as the Ant build system
>
> My enthusiasm for Maven is all about lowering the barrier to entry.
I used to share that enthusiasm. It has faded over time, however, as it
became apparent to me that, once you get past the easy part, writing preGoal
and postGoal scripts isn't much different from writing Ant scripts. Oh, and
Maven changing the way it does things didn't help either. ;-)
> I think long-time Ant/Struts builders forget how tedious it is to set
> up the build.properties file. And that's just to compile; if you use
> an IDE you have another headache getting a Struts project set up.
That is certainly true. One of the things Maven does for you, to ease the
build process, is decide where the dependencies are going to come from. If
we did that in the Ant build files, it would make it almost as simple as
Mave, but then, because they're Ant build files, people would complain that
they were not sufficiently flexible. That makes it hard to win. ;-)
(When it comes to IDEs, though, most of them know about Ant, but don't yet
know about Maven at all, so there's not so much of a case for Maven there,
IMHO.)
--
Martin Cooper
>
> Anyway, no need to proselytize...
>
> Joe
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Imagine if every Thursday your shoes exploded if you tied them
> the usual way. This happens to us all the time with computers, and
> nobody thinks of complaining."
> -- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build available)
Posted by Tim Chen <tc...@tampabay.rr.com>.
There's another way to handle these as well.
Following the properties processing rule that Joe had quoted. You will
notice that everything goes through you build.properties
So if you define a version in your build.properties you can access it in
your dependencies.
For example:
//build.properties
java.style.version=2.9.9
// for each project that you use jrefactory/javastyle in simply define
the dependency as:
<!-- pretty task -->
<dependency>
<groupId>jrefactory</groupId>
<artifactId>JavaStyle</artifactId>
<version>${java.style.version}</version>
</dependency>
You can also define an xml file with your dependencies section and
include that with each project using standard xml inclusion.
This is much less typing and very similar to how all your ant files have
that line.. well now all your project.properties file with have a xml
include line.
You can also create a base project.xml with all your dependencies and
their correct versions and use <extend> from your subproject's in order
to bring those dependencies in.
There are more options (including the @FOO_VERSION@ syntax that alot of
people seem to like to use) but I've only used the ones above.
A cool feature being worked on by the maven group is the inclusion of
dependencies from a POM (your project.xml is basically a POM.. when you
upload your artifact to a repository it will create a poms folder with
your project.xml renamed to project.pom). This will allow people to get
all the dependencies of a particular project directly into their project.
Hope that helps,
-Tim :)
Joe Germuska wrote:
>> that lets me define the individual versions of *all* dependencies for
>> *all*
>> projects so that I can say, for example, use *this* version of
>> commons-beanutils and *that* version of commons-digester to build
>> ***all*** of
>> the components that are going in to my overall exectable. I am *so* not
>> interested in dealing with runtime exceptions because different
>> dependent
>> packages were compiled against different versions of the dependent
>> libraries.
>>
>> Can someone please help me understand how to do this with Maven?
>> Without it,
>> I'm not planning to switch any of my personal or internal-to-Sun
>> projects (even
>> if the Struts committers decide to switch Struts development itself).
>
>
> This is actually pretty easy, if I understand you correctly. If you
> define the Maven property "maven.jar.override" to the value "on", then
> when resolving dependencies, Maven will check each against a possibly
> defined override.
>
> For example, the version of Cactus that everyone else in Struts uses
> doesn't work on Mac OS X. The Cactus CVS head has the patch that
> works, so in my Struts/maven environment, I have this defined:
>
> maven.jar.override=on
> # patched version of cactus related to Mac OS X:
> # http://issues.apache.org/bugzilla/show_bug.cgi?id=25266i
> maven.jar.cactus-ant=1.6dev-2003-12-07
> maven.jar.jakarta-cactus-framework=13-1.6dev
>
> You can use full paths to JARs as well as version numbers. This is
> detailed here:
> http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies
>
>
> Properties are defined like so:
> (http://maven.apache.org/reference/user-guide.html#Properties_Processing):
>
>
>> The properties files in Maven are processed in the following order:
>>
>> * ${project.home}/project.properties
>> * ${project.home}/build.properties
>> * ${user.home}/build.properties
>>
>> Where the last definition wins. So, Maven moves through this
>> sequence of properties files overridding any previously defined
>> properties with newer definitions. In this sequence your
>> ${user.home}/build.properties has the final say in the list of
>> properties files processed. We will call the list of properties
>> files that Maven processes the standard properties file set.
>>
>> In addition, System properties are processed after the above chain
>> of properties files are processed. So, a property specified on the
>> CLI using the -Dproperty=value convention will override any previous
>> definition of that property.
>
>
> So if you wanted to have it universally, you'd define this in
> "${user.home}/build.properties" but if it were just for a specific
> project, you'd define it in ${project.home}/build.properties
>
> Did I answer the right question?
>
> Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build
available)
Posted by Joe Germuska <Jo...@Germuska.com>.
>that lets me define the individual versions of *all* dependencies for *all*
>projects so that I can say, for example, use *this* version of
>commons-beanutils and *that* version of commons-digester to build ***all*** of
>the components that are going in to my overall exectable. I am *so* not
>interested in dealing with runtime exceptions because different dependent
>packages were compiled against different versions of the dependent libraries.
>
>Can someone please help me understand how to do this with Maven? Without it,
>I'm not planning to switch any of my personal or internal-to-Sun
>projects (even
>if the Struts committers decide to switch Struts development itself).
This is actually pretty easy, if I understand you correctly. If you
define the Maven property "maven.jar.override" to the value "on",
then when resolving dependencies, Maven will check each against a
possibly defined override.
For example, the version of Cactus that everyone else in Struts uses
doesn't work on Mac OS X. The Cactus CVS head has the patch that
works, so in my Struts/maven environment, I have this defined:
maven.jar.override=on
# patched version of cactus related to Mac OS X:
# http://issues.apache.org/bugzilla/show_bug.cgi?id=25266i
maven.jar.cactus-ant=1.6dev-2003-12-07
maven.jar.jakarta-cactus-framework=13-1.6dev
You can use full paths to JARs as well as version numbers. This is
detailed here:
http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies
Properties are defined like so:
(http://maven.apache.org/reference/user-guide.html#Properties_Processing):
> The properties files in Maven are processed in the following order:
>
> * ${project.home}/project.properties
> * ${project.home}/build.properties
> * ${user.home}/build.properties
>
> Where the last definition wins. So, Maven moves through this
>sequence of properties files overridding any previously defined
>properties with newer definitions. In this sequence your
>${user.home}/build.properties has the final say in the list of
>properties files processed. We will call the list of properties
>files that Maven processes the standard properties file set.
>
> In addition, System properties are processed after the above chain
>of properties files are processed. So, a property specified on the
>CLI using the -Dproperty=value convention will override any
>previous definition of that property.
So if you wanted to have it universally, you'd define this in
"${user.home}/build.properties" but if it were just for a specific
project, you'd define it in ${project.home}/build.properties
Did I answer the right question?
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
Re: [OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build
available)
Posted by Joe Germuska <Jo...@Germuska.com>.
>that lets me define the individual versions of *all* dependencies for *all*
>projects so that I can say, for example, use *this* version of
>commons-beanutils and *that* version of commons-digester to build ***all*** of
>the components that are going in to my overall exectable. I am *so* not
>interested in dealing with runtime exceptions because different dependent
>packages were compiled against different versions of the dependent libraries.
>
>Can someone please help me understand how to do this with Maven? Without it,
>I'm not planning to switch any of my personal or internal-to-Sun
>projects (even
>if the Struts committers decide to switch Struts development itself).
This is actually pretty easy, if I understand you correctly. If you
define the Maven property "maven.jar.override" to the value "on",
then when resolving dependencies, Maven will check each against a
possibly defined override.
For example, the version of Cactus that everyone else in Struts uses
doesn't work on Mac OS X. The Cactus CVS head has the patch that
works, so in my Struts/maven environment, I have this defined:
maven.jar.override=on
# patched version of cactus related to Mac OS X:
# http://issues.apache.org/bugzilla/show_bug.cgi?id=25266i
maven.jar.cactus-ant=1.6dev-2003-12-07
maven.jar.jakarta-cactus-framework=13-1.6dev
You can use full paths to JARs as well as version numbers. This is
detailed here:
http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies
Properties are defined like so:
(http://maven.apache.org/reference/user-guide.html#Properties_Processing):
> The properties files in Maven are processed in the following order:
>
> * ${project.home}/project.properties
> * ${project.home}/build.properties
> * ${user.home}/build.properties
>
> Where the last definition wins. So, Maven moves through this
>sequence of properties files overridding any previously defined
>properties with newer definitions. In this sequence your
>${user.home}/build.properties has the final say in the list of
>properties files processed. We will call the list of properties
>files that Maven processes the standard properties file set.
>
> In addition, System properties are processed after the above chain
>of properties files are processed. So, a property specified on the
>CLI using the -Dproperty=value convention will override any
>previous definition of that property.
So if you wanted to have it universally, you'd define this in
"${user.home}/build.properties" but if it were just for a specific
project, you'd define it in ${project.home}/build.properties
Did I answer the right question?
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
Re: [OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build available)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Joe Germuska <Jo...@Germuska.com>:
> Oh yeah, also I can't go back from having versioned JAR in my lib
> directories. I suspect that's a matter of taste too, but I'll take
> the overhead of pruning old JARs when new versions are deployed over
> the mystery of knowing which versions your apps depend on any day...
>
Interestingly, this touches on my single biggest frustration with Maven.
Professionally, I live in a world where there are some fairly large projects,
which integrate *lots* of open source projects (a very large number of
jakarta.apache.org and xml.apache.org subprojects are included). Many of these
open source projects have overlapping dependencies on several Jakarta Commons
packages -- not a surprise, those packages were *designed* for reuse. But
Maven (like many other build environments) encourages you to define the
specific version dependencies for each package you build independently. That's
not good enough for enterprise development.
All of the Ant build.xml files I care about include a line like this:
<property file="${user.home}/build.properties"/>
that lets me define the individual versions of *all* dependencies for *all*
projects so that I can say, for example, use *this* version of
commons-beanutils and *that* version of commons-digester to build ***all*** of
the components that are going in to my overall exectable. I am *so* not
interested in dealing with runtime exceptions because different dependent
packages were compiled against different versions of the dependent libraries.
Can someone please help me understand how to do this with Maven? Without it,
I'm not planning to switch any of my personal or internal-to-Sun projects (even
if the Struts committers decide to switch Struts development itself).
> Joe
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build available)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Joe Germuska <Jo...@Germuska.com>:
> Oh yeah, also I can't go back from having versioned JAR in my lib
> directories. I suspect that's a matter of taste too, but I'll take
> the overhead of pruning old JARs when new versions are deployed over
> the mystery of knowing which versions your apps depend on any day...
>
Interestingly, this touches on my single biggest frustration with Maven.
Professionally, I live in a world where there are some fairly large projects,
which integrate *lots* of open source projects (a very large number of
jakarta.apache.org and xml.apache.org subprojects are included). Many of these
open source projects have overlapping dependencies on several Jakarta Commons
packages -- not a surprise, those packages were *designed* for reuse. But
Maven (like many other build environments) encourages you to define the
specific version dependencies for each package you build independently. That's
not good enough for enterprise development.
All of the Ant build.xml files I care about include a line like this:
<property file="${user.home}/build.properties"/>
that lets me define the individual versions of *all* dependencies for *all*
projects so that I can say, for example, use *this* version of
commons-beanutils and *that* version of commons-digester to build ***all*** of
the components that are going in to my overall exectable. I am *so* not
interested in dealing with runtime exceptions because different dependent
packages were compiled against different versions of the dependent libraries.
Can someone please help me understand how to do this with Maven? Without it,
I'm not planning to switch any of my personal or internal-to-Sun projects (even
if the Struts committers decide to switch Struts development itself).
> Joe
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build
available)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:19 AM -0800 2/27/04, Martin Cooper wrote:
>(When it comes to IDEs, though, most of them know about Ant, but don't yet
>know about Maven at all, so there's not so much of a case for Maven there,
>IMHO.)
Since you added the OT to the subject line, I feel ok about dragging
this on... the beauty of Maven and IDEs is that Maven generates the
project for you, for JBuilder, Eclipse, or IDEA. Let's see your Ant
do that! :-)
Just kidding. Ant is great, and actually, I think the fact that
extending Maven is basically like writing Ant is a feature, not a bug.
Oh yeah, also I can't go back from having versioned JAR in my lib
directories. I suspect that's a matter of taste too, but I'll take
the overhead of pruning old JARs when new versions are deployed over
the mystery of knowing which versions your apps depend on any day...
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org