Brett Porter wrote:
Gilles Dodinet wrote:
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.
This is a bit weird. I'd like to work this through with you if possible
(as you can see, our clean build is working on the integration machine -
so I'd need to see what in your environment is causing it).
after several attempts on different machines, still got the same result:
* i have to build core-it-verifier by hand (using an already installed
m2 instance)
* once done i encounter the same issue than Unico -
ClassNotFoundException : ModelloCli. (note that i checked modello-core
and it's not corrupted and ModelloCli is there)
* also it-20 doesnot pass (beanshell cannot be downloaded)
building after having deleted the local repo makes no difference. i
built against yesterday checkout.
no success either with "m2 install".
please find the build log here: http://rafb.net/paste/results/flC2Ol80.html
but yet im still not sure how to register an artifact handler.
maven-artifact/src/main/resources/META-INF/plexus/components.xml lists them
i was hoping for a more transparent mechanism (f.i. providing my own
components.xml as part of the plugin) so that i could bypass my building
issues and use a SNAPSHOT instead. i guess it's just not implemented yet ?
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)
In the repository, the naming format is quite strict - the handler only
has control over the extension used (And the subdirectory in the old
style repo). I don't quite understand the use case - you can bundle/save
without versions locally, but the repository artifacts should still have
a version. Can you explain more about this?
in my (short) experience renaming a dll can lead to various problems -
but here i perhaps made something wrong . however i find it a bit
troubling your proposal to bundle/save locally without versions but then
deploy with explicit versions set. it would also require additional
logic and add complexity to the process to convert a just-downloaded
artifact to a not-versionned one. on the other hand the rationale behind
artifact name control is more general. f.i. eclipse plugin and features
bundle names follow this pattern : <artifactId>_<version>.jar. not quite
different but still need to alter default naming. so for the pde plugin
i'd like to declare
<dependency>
...
<type>pde</type>
</dependency>
and have m2 resolves the dependent plugin without having anything to do
other than provide a naming strategy for pde artifacts. same for
assembly references.
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.
This would be the responsibility of the compiler mojo. However, you may
need to alter the lifecycle more - there has been a thread of discussion
about how to do this recently, but is not yet implemented.
being able to completly alter the lifecycle seems to me the way to go
because although the semantic remains the same, java and c# won't share
much. also not sur to see how the compiler mojo as it exists now will
know which compiler to use.
i'm not sure either to understand the directory() method. is this
method present to support m1 repository-style ?
correct.
what i have so far is pretty simplistic as you can see at
http://codehaus.org/~gdodinet/csharp.png.
ok, I was thinking that you should be able to use the same compiler
mojo, and have an alternate configuration element for csharp (and we
could possibly put the java compiler options into a separate nested
element too). I'm not sure about this - maybe it is better to have a
separate mojo. How much do they differ?
I agree we could rename classpath elements to dependencyFiles, however.
they're not so much different but java compiler mojo hardcodes some java
specific options. also if the compiler resolution is the responsibility
of the compiler mojo then shouldn't the mojo have no knowledge of the
underlying compiler ?
regards,
-- gd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
