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 ) 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 <[email protected]> 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: [email protected] > > To: [email protected] > > > > 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 <[email protected]> > 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > >
