You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Gilles Dodinet <rh...@free.fr> on 2005/05/16 14:37:45 UTC
[m2] artifact handlers
hi-
as part of a m2 csharp plugin i have some custom artifact handlers but
i'm not sure how i can register them. providing a components.xml file as
part of the plugin distribution doesn't seem to do the trick. thanks for
any help.
-- gd
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] artifact handlers
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] artifact handlers
Posted by Gilles Dodinet <rh...@free.fr>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] artifact handlers
Posted by Brett Porter <br...@apache.org>.
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).
>
> 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 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?
>
> 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.
> 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.
> 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.
That's fine to get started. I think a good goal is to get some of the
ant compiler code into commons-jci, without the ant
project/types/listener bindings if that's possible. I'm going to try and
kickstart that soon.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] artifact handlers
Posted by Gilles Dodinet <rh...@free.fr>.
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 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.
>
>
>
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.
thanks for any comment.
regards,
-- gd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] artifact handlers
Posted by Brett Porter <br...@apache.org>.
Hi Gilles,
Gilles Dodinet wrote:
> thanks i think i can wait for alpha-3 :) what i wanted to do was first
> create a simple csharp compiler, then when i am compfortable enough
> with m2 plugins development try to come with a csharp solution as far
> complete as possible (compiling, running nunit, building app, creating
> installers, etc. - perhaps also see if it is to update config with
> auto-update section and how useful that can be). i also need to
> interface with starteam.
This sounds really good. It's been on our wishlist for a while, so I'd
be interested to work with you to get this happening.
Is there any chance you'd build the plugin tracking the m2 trunk? 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.
> right now, as for the compilation step, seems i'm blocked here because
> i cannot add any references to the compiler (using ant CSharp task -
> 1.5.4 for that matters) - "no artifact handler for 'dll' type".
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.
WDYT?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] artifact handlers
Posted by Gilles Dodinet <rh...@free.fr>.
Brett Porter wrote:
>Hi Gilles,
>
>This isn't possible yet, targetting for alpha-3. Currently, it is
>hardcoded into maven-artifact.
>
>If you are ken on developing plugins on the cutting edge, I recommend
>you join dev@maven.apache.org and discuss what you are planning as
>well as issues you hit so we can make sure we are getting everything
>covered.
>
>
Brett,
thanks i think i can wait for alpha-3 :) what i wanted to do was first
create a simple csharp compiler, then when i am compfortable enough with
m2 plugins development try to come with a csharp solution as far
complete as possible (compiling, running nunit, building app, creating
installers, etc. - perhaps also see if it is to update config with
auto-update section and how useful that can be). i also need to
interface with starteam.
right now, as for the compilation step, seems i'm blocked here because i
cannot add any references to the compiler (using ant CSharp task - 1.5.4
for that matters) - "no artifact handler for 'dll' type".
regards,
-- gd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] artifact handlers
Posted by Brett Porter <br...@gmail.com>.
Hi Gilles,
This isn't possible yet, targetting for alpha-3. Currently, it is
hardcoded into maven-artifact.
If you are ken on developing plugins on the cutting edge, I recommend
you join dev@maven.apache.org and discuss what you are planning as
well as issues you hit so we can make sure we are getting everything
covered.
Cheers,
Brett
On 5/16/05, Gilles Dodinet <rh...@free.fr> wrote:
> hi-
>
> as part of a m2 csharp plugin i have some custom artifact handlers but
> i'm not sure how i can register them. providing a components.xml file as
> part of the plugin distribution doesn't seem to do the trick. thanks for
> any help.
>
> -- gd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org