Gilles Dodinet wrote: > 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)
All these problems centre around ModelloCli not being found (I think the m2-bootstrap.bat shell script doesn't exit properly if something it calls has an error level - it should never have continued past the first failure). Unico fixed this problem by waiting for me to reupload some POMs I screwed in the repository, then removing the plexus and modello directories from his local repository. Can you try that? Sorry for the inconvenience... > > 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 ? correct - I was just explaining how to do it now, but the design documents do address doing it as you suggest. > > > 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. There are plenty of use cases for mapping a dependency to a setting (eg war context path within an ear). I think that the filename of the artifact inside Eclipse, assembly, WEB-INF/lib, etc are examples of that. I guess, in the new layout, it would be possible for dll types to have a different filename format (and keep the path name format), and just not be allowed into the m1 style repo. But I'd consider that a last resort as it is going to incur additional handling in the repository management tools as well, and I don't think it is ideal on the user end unless it is absolutely required. >> >> 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. Well, the lifecycle phases would not change - just the bindings. And that will be possible for a "dll" to do, so if packaging determines everything it is ok. Other plugins can be bound later by hand in the POM too. The compiler mojo needs to be enhanced to support multiple compilers and less Java specifics, but it is fine if you want to add a CSharpCompilerMojo with a new goal for now that we can merge back later. >> >> 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 ? Correct, that's why I was tossing up whether to go with different mojos for different compilers, or just push the compiler configuration as a whole element rather than having things like "source" on the compiler mojo itself. - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
