On 22 August 2012 13:06, Stephen Connolly <stephen.alan.conno...@gmail.com>wrote:
> You could add a second execution of the compiler, resources, etc plugins > with an alternative output directory... but that way madness lies. > > A far far better approach is to just build your jars with the debug info > present always. > > The use a separate tool to strip the debug info from the jars that you > release to end users. For example pack200 has the --strip-debug option, or > you could write your own debug info stripper using ASM ( > http://www.java2s.com/Open-Source/Java/Byte-Code/asm/org/objectweb/asm/optimizer/ClassOptimizer.java.htm > ) > > http://download.forge.objectweb.org/asm/asm4-guide.pdf page 22 Quite trivial! > Thus what you are doing is having one artifact that is definitive > throughout your development and test process and then by a verifiable final > step transforming it into the final released artifact. That will greatly > reduce the opportunity for human error and bugs escaping > > -Stephen > > > On 22 August 2012 12:25, Dimitar Gospodinov <maven...@hotmail.com> wrote: > >> >> >> Hi, >> >> Thank you for the advises. >> >> I am new to Maven and profiles was my first shot at the problem of >> generating release and debug versions of the code. >> By using classifiers, my expectation was, I will be able to tell what >> came from where and how was it built. >> >> I tried to generate release and debug versions in the same build, but it >> looked like that is not possible. >> I did not see a way to compile exact same sources (Java), with different >> compiler options. >> >> What I am trying to achieve is produce two versions of the exact same >> code, compiled with different parameters. If this can be done in the same >> build, it will actually be better. >> Other than using separate POM-s, I do not see any other way how this can >> be done (removing profiles completely). >> Is there a way? >> >> Thank you, >> >> Dimitar >> >> >> >> > Date: Tue, 21 Aug 2012 14:43:36 +0100 >> > Subject: Re: Classifier not added to artifact when building module >> > From: stephen.alan.conno...@gmail.com >> > To: users@maven.apache.org >> > >> > Rule #1. One consumable artifact per module >> > Rule #2. Active profiles should not affect the generated artifacts. >> > >> > You are breaking both rules. >> > >> > w.r.t. Rule #1 >> > >> > You generate an assembly and a .jar from the same module... Much pain >> will >> > ensue. >> > >> > There are some circumstances where this rule seems to be broken, for >> > example generating a javadocs artifact, a sources artifact, a src >> > distribution of the module (i.e. a complete buildable zip of the >> source)... >> > in these cases the attached artifacts are incidental to the build.... >> this >> > is why I added the word "consumable" to the way most people state rule >> 1. >> > The javadocs, etc are not consumed by any other modules... therefore >> they >> > do not get in the way. >> > >> > w.r.t. Rule #2 >> > >> > You generate different artifacts depending on which profile is active... >> > and I am going to take a wild stab in the dark and bet that the >> contents of >> > these different artifacts differs. >> > >> > Never mind what you think is supposed to happen when multiple profiles >> are >> > active! >> > >> > mvn -Prelease,debug >> > >> > That will do exactly what? >> > >> > If you insist on generating debug versions of the jars, etc... then your >> > build should *always* generate those artifacts in addition to the >> release >> > versions. >> > >> > The other side of Rule #2 is that the artifact contents should be >> identical >> > irrespective of the profiles activated (this is where lots of people >> abuse >> > profiles by changing the database that their webapp points to when the >> use >> > different profiles) >> > >> > Active profile information is not part of the record that gets deployed >> to >> > the maven repo (local or remote) so you loose all tracability of what >> > profiles were active when your artifact was built and deployed to the >> maven >> > repo... much fun ensues. >> > >> > Keep your life simple. Follow the rules. >> > >> > -Stephen >> > >> > On 17 August 2012 21:25, Dimitar Gospodinov <maven...@hotmail.com> >> wrote: >> > >> > > Hi, >> > > >> > > I have a project that consists of 3 modules: >> > > - P1 >> > > - sample >> > > - distribution >> > > >> > > 'P1' is built first, then 'sample' and finally 'distribution'. >> > > >> > > 'P1' has Jar packing and additional artifact of type ZIP. >> > > 'sample' also has Jar packing and an additional ZIP artifact. >> > > >> > > The purpose of the 'distribution' module is simply to create a ZIP >> > > containing the ZIP artifacts from 'P1' and 'sample'. >> > > 'distribution' has 'P1' and 'sample' as dependencies. >> > > >> > > The project uses 2 profiles - 'release' and 'debug', with 'release' >> being >> > > the default profile. >> > > Everything works Ok in the 'release' profile. >> > > >> > > When issuing 'mvn package -P debug' the build fails in the assembly >> > > plug-in with this error: >> > > >> > > [ERROR] Failed to execute goal on project distribution: Could not >> resolve >> > > dependencies for project com.test:distribution:jar:1.0.0-SNAPSHOT: >> Could >> > > not find arti >> > > fact com.test:sample:zip:debug:1.0.0-SNAPSHOT -> [Help 1] >> > > >> > > If line 31, "<classifier>${buildClassifier}</classifier>" in the file >> > > distribution/pom.xml is commented out, the build is successful. >> > > However if you examine the content of >> distribution-1.0.0-SNAPSHOT.zip, you >> > > will see that it contains sample-1.0.0-SNAPSHOT.zip and there is not >> such >> > > file anywhere in the file system. >> > > It looks like the attached artifact classifier was not added for some >> > > reason, when creating the dependency on the 'sample' project. >> > > If you examine the output for the 'sample' module (directory >> > > sample/target-debug/) you will see file >> sample-1.0.0-SNAPSHOT-debug.zip, >> > > which is correct. >> > > If you compare sample-1.0.0-SNAPSHOT-debug.zip and >> > > sample-1.0.0-SNAPSHOT.zip (from distribution-1.0.0-SNAPSHOT.zip), >> they have >> > > exact same content. >> > > >> > > Also note, that everything works Ok for the 'P1' module - >> 'distribution' >> > > has exact same type of dependency on 'P1' as on 'sample'. >> > > >> > > Does anybody know what the problem is here? >> > > >> > > Attached is the project in question - mvn-test.zip. >> > > log.txt is the output from invoking 'mvn package -P debug -X' where >> the >> > > above mentioned error is shown. >> > > >> > > Thank you, >> > > >> > > Dimitar >> > > >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > > For additional commands, e-mail: users-h...@maven.apache.org >> > > >> >> > >
