You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Taub, Jonathan" <Jo...@umgtemp.com> on 2008/11/03 19:05:35 UTC
General Maven questions....
I’ve been using Maven for a year now and am pretty happy with it.
It has cons and pros.
Recently, I decided to introduce some changes into the build process and I was unable to figure out the following:
* I want to have the final artifact name (.jar, .war, etc) WITHOUT the version number. The application/libraries are not meant to be a third party and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have the same name each time regardless of the version. How do I accomplish this?
* Is it possible to instruct the build process NOT to put any Maven related files inside artifacts?
* How do I copy a file in Maven AFTER the build completed SUCCESSFULLY. I was able to do a simple file copy but it ended up copying the file regardless of whether the build was successful or not.
* Is it possible to have an EXTERNAL properties file? How?
RE: General Maven questions....
Posted by "Taub, Jonathan" <Jo...@umgtemp.com>.
Each person has his/her own experience.
I have had the unfortunate experience that builds cannot be reproduced,
when the entire build is performed automatically (bugs do exist elsewhere).
So this is not a myth. I even came across a scenario that on rare cases, creating a .jar file using the exact same compiler and JVM resulted in different file sizes for whatever reason.
I am considering it from a bitter, bitter experience.
At least having the knowledge that whatever the build you have cannot be reproduced for whatever reason, can be an important piece of information.
Automation of repeatable tasks is definitely the way to go in this case.
HOWEVER, I do want to have the assurance that at any given point of time, I can put my hands on the EXACT binary that was deployed to production X amount of time ago. The ONLY way to ensure that is to retain a copy of that binary.
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: Monday, November 03, 2008 12:29
To: Maven Users List
Subject: Re: General Maven questions....
Taub, Jonathan wrote:
> I understand your concern.
> However, the application itself is self contained and is not meant to be a third party
> application/library. Each release is tagged in Subversion, proper
release notes are
> maintained, and the application will contain a web page specifying
the current
> build/version.
It makes no difference - when you have a problem, your troubleshooter
will hold in their hands the deployed binary. And while they might think
they are holding version X, but they're actually holding version Y
because someone "forgot" to update the docs, and they waste hours trying
to figure out where the confusion lies.
From bitter bitter experience, don't even consider it. Or, if you do,
don't be surprised if a troubleshooter chases you down with a rolling pin.
> Right now, changing multiple pom files each time before a release is a headache (and
> then changing it back to snapshot).
Which is why you don't do it, you use your computer and the
maven-release-plugin to do it for you.
The release plugin will let you release single jars at a time, or it
will happily let you release a multi pom project.
The release plugin will run your tests, check that your code is checked
in properly, change the version numbers to the released version, check
in the release version numbers, tag the new version, bump the released
version again back to snapshot, commit the new version numbers, check
out a pristine copy of your new release, build the release, build the
documentation for the release, upload the released code to your maven
repository, and upload the documentation to your documentation website,
and the commands to do all this are as follows:
mvn release:prepare release:perform
And that's it.
And if it bombs out half way through, just run the goals again and maven
will continue where it left off.
If you change your mind and want to rather roll back to how you started,
you do this:
mvn release:rollback
Masochist (n): person who releases code manually without the release plugin.
> Regardless of how one sets an identifier of some sort for a release
> number, it is going to be manual (unless one goes only by build number).
>
> I have done my share of deployments and tracking versions and find this
> way to be the best. I also believe in checking final binary into a
> versioning control system as the ONLY %100 sure way of knowing whether
> a build can be reproduced is by checking the final product of the build
> (one of the reasons I want to strip Maven files from artifacts).
This is a myth.
If you check your binary in, what do you have? A binary. Where did it
come from? No way to tell.
Did someone make a mistake and check the binary into the wrong place? No
way to tell without explicitly picking apart evidence.
If you want repeatability, remove the human being from the equation
entirely.
Make sure the version number is tagged on to absolutely everything, and
smack any human who tries to manually fiddle with the version number
with a rolled up newspaper.
Computers are repeatable, humans are not.
Regards,
Graham
--
Re: General Maven questions....
Posted by Graham Leggett <mi...@sharp.fm>.
Taub, Jonathan wrote:
> I understand your concern.
> However, the application itself is self contained and is not meant to be a third party
> application/library. Each release is tagged in Subversion, proper
release notes are
> maintained, and the application will contain a web page specifying
the current
> build/version.
It makes no difference - when you have a problem, your troubleshooter
will hold in their hands the deployed binary. And while they might think
they are holding version X, but they're actually holding version Y
because someone "forgot" to update the docs, and they waste hours trying
to figure out where the confusion lies.
From bitter bitter experience, don't even consider it. Or, if you do,
don't be surprised if a troubleshooter chases you down with a rolling pin.
> Right now, changing multiple pom files each time before a release is a headache (and
> then changing it back to snapshot).
Which is why you don't do it, you use your computer and the
maven-release-plugin to do it for you.
The release plugin will let you release single jars at a time, or it
will happily let you release a multi pom project.
The release plugin will run your tests, check that your code is checked
in properly, change the version numbers to the released version, check
in the release version numbers, tag the new version, bump the released
version again back to snapshot, commit the new version numbers, check
out a pristine copy of your new release, build the release, build the
documentation for the release, upload the released code to your maven
repository, and upload the documentation to your documentation website,
and the commands to do all this are as follows:
mvn release:prepare release:perform
And that's it.
And if it bombs out half way through, just run the goals again and maven
will continue where it left off.
If you change your mind and want to rather roll back to how you started,
you do this:
mvn release:rollback
Masochist (n): person who releases code manually without the release plugin.
> Regardless of how one sets an identifier of some sort for a release
> number, it is going to be manual (unless one goes only by build number).
>
> I have done my share of deployments and tracking versions and find this
> way to be the best. I also believe in checking final binary into a
> versioning control system as the ONLY %100 sure way of knowing whether
> a build can be reproduced is by checking the final product of the build
> (one of the reasons I want to strip Maven files from artifacts).
This is a myth.
If you check your binary in, what do you have? A binary. Where did it
come from? No way to tell.
Did someone make a mistake and check the binary into the wrong place? No
way to tell without explicitly picking apart evidence.
If you want repeatability, remove the human being from the equation
entirely.
Make sure the version number is tagged on to absolutely everything, and
smack any human who tries to manually fiddle with the version number
with a rolled up newspaper.
Computers are repeatable, humans are not.
Regards,
Graham
--
RE: General Maven questions....
Posted by "Taub, Jonathan" <Jo...@umgtemp.com>.
Again, I appreciate the feedback. All that has been said is already known to me. Builds should always be automated - did not ask this to be different.
I have had the pleasure of working on a project where there was actually too much documentation. Improper documentation resulted in having it introduced in JavaDoc where necessary and having to perform another build. Tests/documentation was part of the release cycle.
3am is also not the time to find out that you want to get your hands on a build and find out that you can't reproduce it and wished you had the binary somewhere.
But 'nough said. All this discussion should be in another thread and has little to do with low level action items.
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: Monday, November 03, 2008 14:44
To: Maven Users List
Subject: Re: General Maven questions....
Taub, Jonathan wrote:
> I am well aware that some of the things I want to do go against Maven.
> However, all is based on personal experience and I don't consider Maven to be
> a magic pill. My experience has shown me that too many people rely on
> technology and automation to solve everything rather than to add some
> proper engineering discipline, process, ability to think out of the box,
> and sometime, manual steps.
Discipline is the key word, however in order to properly understand
discipline, you need to understand people.
People will always choose the easiest path *for them*.
People will build the binary from their arbitrarily modified and
unrepeatable working copy, because it is the easiest thing for them to do.
Given the choice between "update the documentation to reflect the new
release" and "do nothing", the people will choose "do nothing".
Maven has, in the release plugin, come up with a path that it easier to
do correctly than it is to do incorrectly. All you need to do is to
ensure the pom.xml file is correctly configured. Your release manager
then just runs "mvn release:prepare release:perform", and it just works.
Adding manual steps does not demonstrate discipline, instead it
demonstrates reasons where your build can go wrong.
Remember the end result of all of this: it is 3am, your troubleshooter
has a production problem, they need to reproduce the problem in their
development environment.
3am is not the time to discover that you have "application.jar" and
don't know where the source code is. 3am is not the time to discover
that the version in source control, wasn't actually the version used to
build the binary, and the version in source control doesn't build.
Your entire process should revolve around making your troubleshooter's
lives easier, and that happens when you make disciplined development the
path of least resistance.
Regards,
Graham
--
Re: General Maven questions....
Posted by Graham Leggett <mi...@sharp.fm>.
Taub, Jonathan wrote:
> I am well aware that some of the things I want to do go against Maven.
> However, all is based on personal experience and I don't consider Maven to be
> a magic pill. My experience has shown me that too many people rely on
> technology and automation to solve everything rather than to add some
> proper engineering discipline, process, ability to think out of the box,
> and sometime, manual steps.
Discipline is the key word, however in order to properly understand
discipline, you need to understand people.
People will always choose the easiest path *for them*.
People will build the binary from their arbitrarily modified and
unrepeatable working copy, because it is the easiest thing for them to do.
Given the choice between "update the documentation to reflect the new
release" and "do nothing", the people will choose "do nothing".
Maven has, in the release plugin, come up with a path that it easier to
do correctly than it is to do incorrectly. All you need to do is to
ensure the pom.xml file is correctly configured. Your release manager
then just runs "mvn release:prepare release:perform", and it just works.
Adding manual steps does not demonstrate discipline, instead it
demonstrates reasons where your build can go wrong.
Remember the end result of all of this: it is 3am, your troubleshooter
has a production problem, they need to reproduce the problem in their
development environment.
3am is not the time to discover that you have "application.jar" and
don't know where the source code is. 3am is not the time to discover
that the version in source control, wasn't actually the version used to
build the binary, and the version in source control doesn't build.
Your entire process should revolve around making your troubleshooter's
lives easier, and that happens when you make disciplined development the
path of least resistance.
Regards,
Graham
--
RE: General Maven questions....
Posted by "Taub, Jonathan" <Jo...@umgtemp.com>.
"That being said you should never need to.." - again, this is incorrect,
given personal experience. While bloating the size of the repository I agree, the file will reside outside of source code folder, naturally.
I appreciate people feedback on this.
However, please keep in mind that the topic is NOT best practices.
I am well aware that some of the things I want to do go against Maven.
However, all is based on personal experience and I don't consider Maven to be a magic pill. My experience has shown me that too many people rely on technology and automation to solve everything rather than to add some proper engineering discipline, process, ability to think out of the box, and sometime, manual steps.
-----Original Message-----
From: Jeudy, Guillaume [mailto:gjeudy@teksystems.com]
Sent: Monday, November 03, 2008 13:14
To: Maven Users List
Subject: RE: General Maven questions....
As for repositories hosted by 3rd parties, if you dont trust them why not setup your own maven2 intranet repository (which is quite easy to do by the way) and copy the dependencies you need there ?
Whenever you release artifacts using the maven release plugin it will automatically generate an MD5 checksum and store the checksum file along your artifact in the remote repository. Therefore in the best of worlds when artifacts are released properly in maven repositories you don't have to worry whether the version tagged is really matching the actual artifact binaries.
Storing a release binary with all dependencies will bloat your source control system and will not add any value aside from saving you a rebuild cycle if what you need is to rebuild a release. That being said you should never need to; if you use the maven release plugin (the release binary is automatically pushed to your repo configured in distributionManagement section). This is true on the assumption that you are never re-releasing using the same POM version.
As for your external properties file issue I don't see another way than putting your properties file inside a jar and publish it as a maven artifact, this way you can use the dependencies section to refer your shared jar in other projects and have your properties file available on the classpath.
Cheers,
Guillaume
________________________________
From: Taub, Jonathan [mailto:Jonathan.Taub@umgtemp.com]
Sent: Mon 03/11/2008 2:13 PM
To: Maven Users List
Subject: RE: General Maven questions....
Regardless of the versioning control system being used (CVS, Subversion, etc.), I agree, that generally, it should include source files only.
HOWEVER, depending on your build, you may have more than one repository. Each of the repositories is hosted by a 3rd party which has no obligation whatsoever, to retain that repository over time. And as we are all humans that can make mistakes, somebody may update a repository file without changing the version (mistakes do happen).
In short, the ONLY way to know that a build is reproducible is that the final build product is identical to whatever was deployed to production/staging. This can be accomplished by having MD5, checksum, or actual file comparison.
If one uses MD5/checksum, one can establish whether the build was reproduced successfully. However, in case it hasn't (for whatever reason), the ONLY way to actually have an identical build is to have the actual file which was built and deployed at the time. While this scenario may not happen so often, I did come across it.
As for external properties file, I don't need one in order to filter out resources. I just need to have multiple values shared across Maven projects and was hoping to centralize these in a single properties filed that can be referred from pom files.
-----Original Message-----
From: Jeudy, Guillaume [mailto:gjeudy@teksystems.com]
Sent: Monday, November 03, 2008 10:57
To: Maven Users List
Subject: RE: General Maven questions....
You can use maven release plugin to help alleviate the burden of updating the versions in the pom files.
Also isnt it the whole point of CVS tagging combined with maven build to reproduce exactly the same binaries ? I would strongly advise against checking any sorts of binaries in your source control. Source control is *well* meant for source files.
To answer your last question, yes it is possible to have an external properties file that you can use for filtering resources. Just supply it on the command line.
mvn install -Dmypropsfile=<filepath>
inside your pom:
<filters>
<filter>${mypropsfile}</filter>
</filters>
________________________________
From: Taub, Jonathan [mailto:Jonathan.Taub@umgtemp.com]
Sent: Mon 03/11/2008 1:35 PM
To: Maven Users List
Subject: RE: General Maven questions....
I understand your concern.
However, the application itself is self contained and is not meant to be a third party application/library. Each release is tagged in Subversion, proper release notes are maintained, and the application will contain a web page specifying the current build/version.
Right now, changing multiple pom files each time before a release is a headache (and then changing it back to snapshot).
Regardless of how one sets an identifier of some sort for a release number, it is going to be manual (unless one goes only by build number).
I have done my share of deployments and tracking versions and find this way to be the best. I also believe in checking final binary into a versioning control system as the ONLY %100 sure way of knowing whether a build can be reproduced is by checking the final product of the build (one of the reasons I want to strip Maven files from artifacts).
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: Monday, November 03, 2008 10:25
To: Maven Users List
Subject: Re: General Maven questions....
Taub, Jonathan wrote:
> Recently, I decided to introduce some changes into the build process and I was unable to figure out the following:
> * I want to have the final artifact name (.jar, .war, etc) WITHOUT the version number. The application/libraries are not meant to be a third party and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have the same name each time regardless of the version. How do I accomplish this?
I seriously and strongly recommend that you *don't* do this.
The price of doing this is that you no longer know what version of your
software you are looking at.
Production is giving problems, you need to check out the source code,
quick. Which tag do you check out? You have no idea.
I have watched people using tools like Beyond Compare to painstakingly
check whether one jar was the same as another one, just because the jar
had no identifying marks on it.
Save yourself the pain and the suffering: don't do it.
Regards,
Graham
--
____________________________________________________________________________________________________
This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
____________________________________________________________________________________________________
This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
RE: General Maven questions....
Posted by "Jeudy, Guillaume" <gj...@teksystems.com>.
As for repositories hosted by 3rd parties, if you dont trust them why not setup your own maven2 intranet repository (which is quite easy to do by the way) and copy the dependencies you need there ?
Whenever you release artifacts using the maven release plugin it will automatically generate an MD5 checksum and store the checksum file along your artifact in the remote repository. Therefore in the best of worlds when artifacts are released properly in maven repositories you don't have to worry whether the version tagged is really matching the actual artifact binaries.
Storing a release binary with all dependencies will bloat your source control system and will not add any value aside from saving you a rebuild cycle if what you need is to rebuild a release. That being said you should never need to; if you use the maven release plugin (the release binary is automatically pushed to your repo configured in distributionManagement section). This is true on the assumption that you are never re-releasing using the same POM version.
As for your external properties file issue I don't see another way than putting your properties file inside a jar and publish it as a maven artifact, this way you can use the dependencies section to refer your shared jar in other projects and have your properties file available on the classpath.
Cheers,
Guillaume
________________________________
From: Taub, Jonathan [mailto:Jonathan.Taub@umgtemp.com]
Sent: Mon 03/11/2008 2:13 PM
To: Maven Users List
Subject: RE: General Maven questions....
Regardless of the versioning control system being used (CVS, Subversion, etc.), I agree, that generally, it should include source files only.
HOWEVER, depending on your build, you may have more than one repository. Each of the repositories is hosted by a 3rd party which has no obligation whatsoever, to retain that repository over time. And as we are all humans that can make mistakes, somebody may update a repository file without changing the version (mistakes do happen).
In short, the ONLY way to know that a build is reproducible is that the final build product is identical to whatever was deployed to production/staging. This can be accomplished by having MD5, checksum, or actual file comparison.
If one uses MD5/checksum, one can establish whether the build was reproduced successfully. However, in case it hasn't (for whatever reason), the ONLY way to actually have an identical build is to have the actual file which was built and deployed at the time. While this scenario may not happen so often, I did come across it.
As for external properties file, I don't need one in order to filter out resources. I just need to have multiple values shared across Maven projects and was hoping to centralize these in a single properties filed that can be referred from pom files.
-----Original Message-----
From: Jeudy, Guillaume [mailto:gjeudy@teksystems.com]
Sent: Monday, November 03, 2008 10:57
To: Maven Users List
Subject: RE: General Maven questions....
You can use maven release plugin to help alleviate the burden of updating the versions in the pom files.
Also isnt it the whole point of CVS tagging combined with maven build to reproduce exactly the same binaries ? I would strongly advise against checking any sorts of binaries in your source control. Source control is *well* meant for source files.
To answer your last question, yes it is possible to have an external properties file that you can use for filtering resources. Just supply it on the command line.
mvn install -Dmypropsfile=<filepath>
inside your pom:
<filters>
<filter>${mypropsfile}</filter>
</filters>
________________________________
From: Taub, Jonathan [mailto:Jonathan.Taub@umgtemp.com]
Sent: Mon 03/11/2008 1:35 PM
To: Maven Users List
Subject: RE: General Maven questions....
I understand your concern.
However, the application itself is self contained and is not meant to be a third party application/library. Each release is tagged in Subversion, proper release notes are maintained, and the application will contain a web page specifying the current build/version.
Right now, changing multiple pom files each time before a release is a headache (and then changing it back to snapshot).
Regardless of how one sets an identifier of some sort for a release number, it is going to be manual (unless one goes only by build number).
I have done my share of deployments and tracking versions and find this way to be the best. I also believe in checking final binary into a versioning control system as the ONLY %100 sure way of knowing whether a build can be reproduced is by checking the final product of the build (one of the reasons I want to strip Maven files from artifacts).
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: Monday, November 03, 2008 10:25
To: Maven Users List
Subject: Re: General Maven questions....
Taub, Jonathan wrote:
> Recently, I decided to introduce some changes into the build process and I was unable to figure out the following:
> * I want to have the final artifact name (.jar, .war, etc) WITHOUT the version number. The application/libraries are not meant to be a third party and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have the same name each time regardless of the version. How do I accomplish this?
I seriously and strongly recommend that you *don't* do this.
The price of doing this is that you no longer know what version of your
software you are looking at.
Production is giving problems, you need to check out the source code,
quick. Which tag do you check out? You have no idea.
I have watched people using tools like Beyond Compare to painstakingly
check whether one jar was the same as another one, just because the jar
had no identifying marks on it.
Save yourself the pain and the suffering: don't do it.
Regards,
Graham
--
____________________________________________________________________________________________________
This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
____________________________________________________________________________________________________
This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
RE: General Maven questions....
Posted by "Taub, Jonathan" <Jo...@umgtemp.com>.
Regardless of the versioning control system being used (CVS, Subversion, etc.), I agree, that generally, it should include source files only.
HOWEVER, depending on your build, you may have more than one repository. Each of the repositories is hosted by a 3rd party which has no obligation whatsoever, to retain that repository over time. And as we are all humans that can make mistakes, somebody may update a repository file without changing the version (mistakes do happen).
In short, the ONLY way to know that a build is reproducible is that the final build product is identical to whatever was deployed to production/staging. This can be accomplished by having MD5, checksum, or actual file comparison.
If one uses MD5/checksum, one can establish whether the build was reproduced successfully. However, in case it hasn't (for whatever reason), the ONLY way to actually have an identical build is to have the actual file which was built and deployed at the time. While this scenario may not happen so often, I did come across it.
As for external properties file, I don't need one in order to filter out resources. I just need to have multiple values shared across Maven projects and was hoping to centralize these in a single properties filed that can be referred from pom files.
-----Original Message-----
From: Jeudy, Guillaume [mailto:gjeudy@teksystems.com]
Sent: Monday, November 03, 2008 10:57
To: Maven Users List
Subject: RE: General Maven questions....
You can use maven release plugin to help alleviate the burden of updating the versions in the pom files.
Also isnt it the whole point of CVS tagging combined with maven build to reproduce exactly the same binaries ? I would strongly advise against checking any sorts of binaries in your source control. Source control is *well* meant for source files.
To answer your last question, yes it is possible to have an external properties file that you can use for filtering resources. Just supply it on the command line.
mvn install -Dmypropsfile=<filepath>
inside your pom:
<filters>
<filter>${mypropsfile}</filter>
</filters>
________________________________
From: Taub, Jonathan [mailto:Jonathan.Taub@umgtemp.com]
Sent: Mon 03/11/2008 1:35 PM
To: Maven Users List
Subject: RE: General Maven questions....
I understand your concern.
However, the application itself is self contained and is not meant to be a third party application/library. Each release is tagged in Subversion, proper release notes are maintained, and the application will contain a web page specifying the current build/version.
Right now, changing multiple pom files each time before a release is a headache (and then changing it back to snapshot).
Regardless of how one sets an identifier of some sort for a release number, it is going to be manual (unless one goes only by build number).
I have done my share of deployments and tracking versions and find this way to be the best. I also believe in checking final binary into a versioning control system as the ONLY %100 sure way of knowing whether a build can be reproduced is by checking the final product of the build (one of the reasons I want to strip Maven files from artifacts).
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: Monday, November 03, 2008 10:25
To: Maven Users List
Subject: Re: General Maven questions....
Taub, Jonathan wrote:
> Recently, I decided to introduce some changes into the build process and I was unable to figure out the following:
> * I want to have the final artifact name (.jar, .war, etc) WITHOUT the version number. The application/libraries are not meant to be a third party and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have the same name each time regardless of the version. How do I accomplish this?
I seriously and strongly recommend that you *don't* do this.
The price of doing this is that you no longer know what version of your
software you are looking at.
Production is giving problems, you need to check out the source code,
quick. Which tag do you check out? You have no idea.
I have watched people using tools like Beyond Compare to painstakingly
check whether one jar was the same as another one, just because the jar
had no identifying marks on it.
Save yourself the pain and the suffering: don't do it.
Regards,
Graham
--
____________________________________________________________________________________________________
This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
RE: General Maven questions....
Posted by "Jeudy, Guillaume" <gj...@teksystems.com>.
You can use maven release plugin to help alleviate the burden of updating the versions in the pom files.
Also isnt it the whole point of CVS tagging combined with maven build to reproduce exactly the same binaries ? I would strongly advise against checking any sorts of binaries in your source control. Source control is *well* meant for source files.
To answer your last question, yes it is possible to have an external properties file that you can use for filtering resources. Just supply it on the command line.
mvn install -Dmypropsfile=<filepath>
inside your pom:
<filters>
<filter>${mypropsfile}</filter>
</filters>
________________________________
From: Taub, Jonathan [mailto:Jonathan.Taub@umgtemp.com]
Sent: Mon 03/11/2008 1:35 PM
To: Maven Users List
Subject: RE: General Maven questions....
I understand your concern.
However, the application itself is self contained and is not meant to be a third party application/library. Each release is tagged in Subversion, proper release notes are maintained, and the application will contain a web page specifying the current build/version.
Right now, changing multiple pom files each time before a release is a headache (and then changing it back to snapshot).
Regardless of how one sets an identifier of some sort for a release number, it is going to be manual (unless one goes only by build number).
I have done my share of deployments and tracking versions and find this way to be the best. I also believe in checking final binary into a versioning control system as the ONLY %100 sure way of knowing whether a build can be reproduced is by checking the final product of the build (one of the reasons I want to strip Maven files from artifacts).
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: Monday, November 03, 2008 10:25
To: Maven Users List
Subject: Re: General Maven questions....
Taub, Jonathan wrote:
> Recently, I decided to introduce some changes into the build process and I was unable to figure out the following:
> * I want to have the final artifact name (.jar, .war, etc) WITHOUT the version number. The application/libraries are not meant to be a third party and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have the same name each time regardless of the version. How do I accomplish this?
I seriously and strongly recommend that you *don't* do this.
The price of doing this is that you no longer know what version of your
software you are looking at.
Production is giving problems, you need to check out the source code,
quick. Which tag do you check out? You have no idea.
I have watched people using tools like Beyond Compare to painstakingly
check whether one jar was the same as another one, just because the jar
had no identifying marks on it.
Save yourself the pain and the suffering: don't do it.
Regards,
Graham
--
____________________________________________________________________________________________________
This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
RE: General Maven questions....
Posted by "Taub, Jonathan" <Jo...@umgtemp.com>.
I understand your concern.
However, the application itself is self contained and is not meant to be a third party application/library. Each release is tagged in Subversion, proper release notes are maintained, and the application will contain a web page specifying the current build/version.
Right now, changing multiple pom files each time before a release is a headache (and then changing it back to snapshot).
Regardless of how one sets an identifier of some sort for a release number, it is going to be manual (unless one goes only by build number).
I have done my share of deployments and tracking versions and find this way to be the best. I also believe in checking final binary into a versioning control system as the ONLY %100 sure way of knowing whether a build can be reproduced is by checking the final product of the build (one of the reasons I want to strip Maven files from artifacts).
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: Monday, November 03, 2008 10:25
To: Maven Users List
Subject: Re: General Maven questions....
Taub, Jonathan wrote:
> Recently, I decided to introduce some changes into the build process and I was unable to figure out the following:
> * I want to have the final artifact name (.jar, .war, etc) WITHOUT the version number. The application/libraries are not meant to be a third party and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have the same name each time regardless of the version. How do I accomplish this?
I seriously and strongly recommend that you *don't* do this.
The price of doing this is that you no longer know what version of your
software you are looking at.
Production is giving problems, you need to check out the source code,
quick. Which tag do you check out? You have no idea.
I have watched people using tools like Beyond Compare to painstakingly
check whether one jar was the same as another one, just because the jar
had no identifying marks on it.
Save yourself the pain and the suffering: don't do it.
Regards,
Graham
--
Re: General Maven questions....
Posted by Graham Leggett <mi...@sharp.fm>.
Taub, Jonathan wrote:
> Recently, I decided to introduce some changes into the build process and I was unable to figure out the following:
> * I want to have the final artifact name (.jar, .war, etc) WITHOUT the version number. The application/libraries are not meant to be a third party and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have the same name each time regardless of the version. How do I accomplish this?
I seriously and strongly recommend that you *don't* do this.
The price of doing this is that you no longer know what version of your
software you are looking at.
Production is giving problems, you need to check out the source code,
quick. Which tag do you check out? You have no idea.
I have watched people using tools like Beyond Compare to painstakingly
check whether one jar was the same as another one, just because the jar
had no identifying marks on it.
Save yourself the pain and the suffering: don't do it.
Regards,
Graham
--
Re: General Maven questions....
Posted by Dennis Lundberg <de...@apache.org>.
Taub, Jonathan wrote:
> I’ve been using Maven for a year now and am pretty happy with it.
> It has cons and pros.
>
> Recently, I decided to introduce some changes into the build process and I was unable to figure out the following:
> * I want to have the final artifact name (.jar, .war, etc) WITHOUT the version number. The application/libraries are not meant to be a third party and version numbers (XXX-snapshot, XXX-1.5) are not needed and I want to have the same name each time regardless of the version. How do I accomplish this?
> * Is it possible to instruct the build process NOT to put any Maven related files inside artifacts?
Yes, have a look at the docs for the Maven Archiver shared component.
This component is used by several plugins, including the Jar Plugin.
http://maven.apache.org/shared/maven-archiver/#class_archive
Adding this configuration should do the trick:
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
> * How do I copy a file in Maven AFTER the build completed SUCCESSFULLY. I was able to do a simple file copy but it ended up copying the file regardless of whether the build was successful or not.
> * Is it possible to have an EXTERNAL properties file? How?
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org