Brett Porter wrote:
Is there any chance you'd build the plugin tracking the m2 trunk?ive tried to build from trunk but encountered some problems with bootstrap : i had to build core-it-verifier by hand (using alpha-2), but then all it-tests failed because of file not found (however the files were actually present). i remember having encountered such issue a while back when bootstrapping (as far as i can recall that was a basedir issue). i havent investigated this very far and downloaded the last snapshot instead.
That
way you could add in a new artifact handler now, and be an additional
guinea pig for configurable handlers and the full lifecycle <-> type
mapping for which we don't have a test for yet.
but yet im still not sure how to register an artifact handler. i also wonder how i can specify non defualt artifact name mapping. indeed even though it is to handle assembly name like any other artifact, assemblies generally don't include version in the name (no judgement nor appreciation here). on the other hand m2 default repository layout has a folder per version so i guess it should be possible to locate a dependency even if its name doesn't make the version explicit, not ? (although i understand this make it not backward compatible)
concerning the lifecycle i'm not sure how to map it to a specific packaging type. it's tempting though to use the artifact handler for this. but handlers seem to only define packageGoal(). so how to instruct m2 that a project that has a 'foo' packaging type should be compiled with foo-compiler. i'm not sure either to understand the directory() method. is this method present to support m1 repository-style ?
what i have so far is pretty simplistic as you can see at http://codehaus.org/~gdodinet/csharp.png. i kinda mimic the java compiler and register several (non exhaustive) options through the Compiler config. seems more or less enough, however concerning references i suppose something more general than classpathElements could be nice - very java centric indeed. concerning the ant task i would have been happier without it (not mentionning that it needs an ant project - however i use 1.5.4, perhaps that changed in 1.6+) but for now i didn't wnat to rewrite something similar.What we have for compilers is in plexus-compilers. It is a generic API which was developed from a similar base as something at Apache, and I am actually going to fold that back in to Jakarta Commons JCI for the next release of the compiler plugin. So we could provide a VS.Net CSharp implementation and a Mono implementation that people could configure locally. The goal should remain compiler:compile - though we might need to look at a better way of configuring the compilers as currently it is quite java specific.
thanks for any comment.
regards,
-- gd
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
