On 19/10/2008, at 2:38 PM, James Carpenter wrote:
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.
Yep, it sounds about right to me.
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?)
Yes, I think it would be dangerous for nmaven to start to inventing
solutions to things that belong in maven proper - having been down
that road before and seen the problems it leads to.
Generally, Maven just builds one thing at a time (so there is a normal
build, then a release profile, and maybe some other profile for other
scenarios). In this case, it seems you might default to everything
off, but then some may enable a full debug PDB in the normal builds,
and in release turn that off and publish a public PDB instead.
If for any reason this requires multiple compilations you could add
extra executions, but that sounds odd - you should be able to get the
right set of options for your scenario and then package as
appropriate, and configure differently in different profiles for
different scenarios.
I believe this works out better for unit tests as well. Assembly
plugin generally takes what you tell it so should work in most
situations.
What you might want is to start flipping classifiers - debug info
builds add debug info for dependencies, and so on. This is a missing
capability in Maven right now (the corresponding Java use case is the
jdk14/15 builds that have jdk14/15 dependenceis). It's a limitation in
the classifier in that it does actually affect the metadata, though at
present it is considered not to.
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.
In trunk, nmaven uses the standard dependency resolver.
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.
There's a few different ways, but you're right - some of the problems
are similar.
Thanks!
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
