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:
I'm sorry to hear that -- I hope you'll stick around for discussions
even if you decide you can't use it right now.
Can add this feature request to JIRA? Adding options to an existing
plugin shouldn't be too hard, and that would give you the additional
command line arguments.
Thanks,
--
Wendy
On Tue, Oct 14, 2008 at 4:21 PM, James Carpenter
<[EMAIL PROTECTED]> wrote:
While running a simple nmaven build in the debugger I came to
realize
org
.apache
.maven.dotnet.extensions.compiler.CShaprClassCompiler#getCommands()
doesn't do anything with the /pdb or /debug options of csc.
Furthermore I didn't see any ability to pass in additional compiler
arguments.
I have therefore concluded that the 0.16-SNAPSHOT version of nmaven
simply doesn't currently support creation of pdb files.
Unfortunately, I don't currently have the time to dedicate to
solving this and a what appears to be a multitude of other nmaven
issues. From a review of the JIRA issues it seems even the 0.14-
SNAPSHOT code is extremely buggy. Sadly, I think I'm going to have
to punt and look into an ant/nant/msbuild/ivy solution until nmaven
matures a bit more.
--- On Tue, 10/14/08, James Carpenter <[EMAIL PROTECTED]>
wrote:
From: James Carpenter <[EMAIL PROTECTED]>
Subject: pdb files
To: [email protected]
Date: Tuesday, October 14, 2008, 11:57 AM
How do I configure a module being built by the nmaven trunk
version of nmaven to produce pdb files?
On a related note, will they be considered as attached
artifacts or will I need to use build-helper:attach-artifact
to do that?
Sincerely,
James Carpenter
cell: 832-677-7247
email: [EMAIL PROTECTED]
