Re: pdb files

I think what really needs to happen is proper support for multiple  
compilation settings (Think release and debug builds.).  I believe  
there is already a JIRA issue for this.  I haven't really thought this  
out, but I think the compiler plugin should be configurable to create  
multiple compilation artifacts with different option values and an  
associated classifier for each.   Secondary artifacts like PDB files  
would of course just be attached artifacts with an appropriate  
classifier.

It is worth nothing, that PDB files can apparently be configured to  
have more or less information.  So called "private" PDB files have a  
lot more details than "public" PDB files.  Public PDB files contain a  
subset of the information in a private PDB.  The information in a  
private PDB is apparently sufficiently detailed to make reverse  
engineering/decompiling code much easier.  When a company releases a  
closed source library they will often release public PDB files along  
with the library, but will keep private PDB files for internal use.  
To further complicate things, I believe I read one can configure  
private PDB files to have less information than a typical PDB file but  
more than a public PDB file.  Each of these would likely need to  
correlate with their own classifier.

None of the above is really all that tricky.  The really tricky part  
will be how to deal with dependencies when compiling, running unit  
tests, running the assembly plugin, etc.  It seems dependencies should  
have an implicit classifier based on context.  When a release assembly/
dll is being built, maven should probably use release versions of the  
dependencies (implicit release classifier).  When a debug assembly is  
being built, maven should probably use debug versions of the project's  
dependencies.  This is to say, the implicit classifier of the  
dependencies should correspond to the classifier associated with the  
compiler plugin configuration being built.  By using the appropriate  
command line options it should be possible to concurrently build as  
many of these different assembly types as desired.  (Would this just  
be different compiler plugin execution configurations?)

I think nmaven is already using its own dependency resolver, so  
everything should be quite tractable, but it may be a bit tricky to  
sort out.  If I was to attack it I would probably just have to evolve  
the code until it smelled right.  I don't think I would be able to see  
all the way to the end solution when I started.

When building Java code maven doesn't really have to deal with any of  
this sticky mess.  It might be instructive to see how other non-Java (C
++?) related plugins are handling this.

On Oct 15, 2008, at 4:21 PM, Wendy Smoak wrote:

Sincerely,
James Carpenter
cell: 832-677-7247
email: jcarpenter621@...