How to deploy Nexus plugins?

[Sascha Scholz]

Hi all,

following your blog posts, I'm going to create a Nexus plugin that  
provides a new repository type. Unfortunately, I'm already stuck with  
the plugin examples mentioned in the blog. I managed to build  
nexus-simple-repository-plugin, but I have no idea how it could be  
deployed to Nexus (1.4.0-SNAPSHOT). An API for the plugin manager is  
mentioned, but I couldn't find anything more concrete.

Any help is appreciated...

Thanks and regards,
Sascha



---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[Tamás Cservenák]

Hi Sascha,

Right now, the API is still in flux and mostly unimplemented (look for NexusPluginManager component).

To deploy it "fast and dirty" (again, this is true _now_, but who knows later):

cd ${nexus-work}/plugin-repository

cp yourPluginBundle.zip .

unzip yourPluginBundle.zip

That's all :)

So, in words: simply unzip the produced plugin ZIP bundle at root of the plugin-repository. Naturally, this needs Nexus restart. If you would do this from Nexus (ie. when "plugin install" API will be done), no restart will be needed.

~t~

On Tue, Jul 28, 2009 at 4:57 PM, Sascha Scholz <sascha@...> wrote:

Hi all,

following your blog posts, I'm going to create a Nexus plugin that provides a new repository type. Unfortunately, I'm already stuck with the plugin examples mentioned in the blog. I managed to build nexus-simple-repository-plugin, but I have no idea how it could be deployed to Nexus (1.4.0-SNAPSHOT). An API for the plugin manager is mentioned, but I couldn't find anything more concrete.

Any help is appreciated...

Thanks and regards,
Sascha



---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[Tamás Cservenák]

Also, please be aware, that Nexus Plugin Manager currently is not very robust (same plugin with multiple versions, dependency clashes), so installing and removing plugins may easily "trash" your nexus. But the remedy is simple: clean out the nexus-plugins repository and start over :)

~t~

2009/7/28 Tamás Cservenák <tamas@...>

Hi Sascha,

Right now, the API is still in flux and mostly unimplemented (look for NexusPluginManager component).

To deploy it "fast and dirty" (again, this is true _now_, but who knows later):

cd ${nexus-work}/plugin-repository

cp yourPluginBundle.zip .

unzip yourPluginBundle.zip

That's all :)

So, in words: simply unzip the produced plugin ZIP bundle at root of the plugin-repository. Naturally, this needs Nexus restart. If you would do this from Nexus (ie. when "plugin install" API will be done), no restart will be needed.

~t~

On Tue, Jul 28, 2009 at 4:57 PM, Sascha Scholz <sascha@...> wrote:

Hi all,

following your blog posts, I'm going to create a Nexus plugin that provides a new repository type. Unfortunately, I'm already stuck with the plugin examples mentioned in the blog. I managed to build nexus-simple-repository-plugin, but I have no idea how it could be deployed to Nexus (1.4.0-SNAPSHOT). An API for the plugin manager is mentioned, but I couldn't find anything more concrete.

Any help is appreciated...

Thanks and regards,
Sascha



---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[TomHuybrechts]

Are there any plans to develop something like Hudsons 'hpi:run' ? You
can just run this from a plugin directory and it launches an embedded
Jetty with Hudson and your plugin preloaded.

Tom


2009/7/28 Tamás Cservenák <tamas@...>:

> Also, please be aware, that Nexus Plugin Manager currently is not very
> robust (same plugin with multiple versions, dependency clashes), so
> installing and removing plugins may easily "trash" your nexus. But the
> remedy is simple: clean out the nexus-plugins repository and start over :)
> ~t~
>
> 2009/7/28 Tamás Cservenák <tamas@...>
>>
>> Hi Sascha,
>> Right now, the API is still in flux and mostly unimplemented (look for
>> NexusPluginManager component).
>> To deploy it "fast and dirty" (again, this is true _now_, but who knows
>> later):
>> cd ${nexus-work}/plugin-repository
>> cp yourPluginBundle.zip .
>> unzip yourPluginBundle.zip
>> That's all :)
>>
>> So, in words: simply unzip the produced plugin ZIP bundle at root of the plugin-repository.
>> Naturally, this needs Nexus restart. If you would do this from Nexus (ie.
>> when "plugin install" API will be done), no restart will be needed.
>> ~t~
>>
>> On Tue, Jul 28, 2009 at 4:57 PM, Sascha Scholz <sascha@...> wrote:
>>>
>>> Hi all,
>>>
>>> following your blog posts, I'm going to create a Nexus plugin that
>>> provides a new repository type. Unfortunately, I'm already stuck with the
>>> plugin examples mentioned in the blog. I managed to build
>>> nexus-simple-repository-plugin, but I have no idea how it could be deployed
>>> to Nexus (1.4.0-SNAPSHOT). An API for the plugin manager is mentioned, but I
>>> couldn't find anything more concrete.
>>>
>>> Any help is appreciated...
>>>
>>> Thanks and regards,
>>> Sascha
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: nexus-dev-unsubscribe@...
>>> For additional commands, e-mail: nexus-dev-help@...
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[Brian Fox]

I assume you mean for debugging? We plan to build support into m2e for
this. We had something working before but it will need to be updated
for the new style of plugins.

On Tue, Jul 28, 2009 at 3:58 PM, Tom Huybrechts<tom.huybrechts@...> wrote:

> Are there any plans to develop something like Hudsons 'hpi:run' ? You
> can just run this from a plugin directory and it launches an embedded
> Jetty with Hudson and your plugin preloaded.
>
> Tom
>
>
> 2009/7/28 Tamás Cservenák <tamas@...>:
>> Also, please be aware, that Nexus Plugin Manager currently is not very
>> robust (same plugin with multiple versions, dependency clashes), so
>> installing and removing plugins may easily "trash" your nexus. But the
>> remedy is simple: clean out the nexus-plugins repository and start over :)
>> ~t~
>>
>> 2009/7/28 Tamás Cservenák <tamas@...>
>>>
>>> Hi Sascha,
>>> Right now, the API is still in flux and mostly unimplemented (look for
>>> NexusPluginManager component).
>>> To deploy it "fast and dirty" (again, this is true _now_, but who knows
>>> later):
>>> cd ${nexus-work}/plugin-repository
>>> cp yourPluginBundle.zip .
>>> unzip yourPluginBundle.zip
>>> That's all :)
>>>
>>> So, in words: simply unzip the produced plugin ZIP bundle at root of the plugin-repository.
>>> Naturally, this needs Nexus restart. If you would do this from Nexus (ie.
>>> when "plugin install" API will be done), no restart will be needed.
>>> ~t~
>>>
>>> On Tue, Jul 28, 2009 at 4:57 PM, Sascha Scholz <sascha@...> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> following your blog posts, I'm going to create a Nexus plugin that
>>>> provides a new repository type. Unfortunately, I'm already stuck with the
>>>> plugin examples mentioned in the blog. I managed to build
>>>> nexus-simple-repository-plugin, but I have no idea how it could be deployed
>>>> to Nexus (1.4.0-SNAPSHOT). An API for the plugin manager is mentioned, but I
>>>> couldn't find anything more concrete.
>>>>
>>>> Any help is appreciated...
>>>>
>>>> Thanks and regards,
>>>> Sascha
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: nexus-dev-unsubscribe@...
>>>> For additional commands, e-mail: nexus-dev-help@...
>>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nexus-dev-unsubscribe@...
> For additional commands, e-mail: nexus-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[TomHuybrechts]

For quick deploy cycles during development -- automatic any time you
change the source. Just like jetty:run for wars...

On Tue, Jul 28, 2009 at 10:09 PM, Brian Fox<brianf@...> wrote:

> I assume you mean for debugging? We plan to build support into m2e for
> this. We had something working before but it will need to be updated
> for the new style of plugins.
>
> On Tue, Jul 28, 2009 at 3:58 PM, Tom Huybrechts<tom.huybrechts@...> wrote:
>> Are there any plans to develop something like Hudsons 'hpi:run' ? You
>> can just run this from a plugin directory and it launches an embedded
>> Jetty with Hudson and your plugin preloaded.
>>
>> Tom
>>
>>
>> 2009/7/28 Tamás Cservenák <tamas@...>:
>>> Also, please be aware, that Nexus Plugin Manager currently is not very
>>> robust (same plugin with multiple versions, dependency clashes), so
>>> installing and removing plugins may easily "trash" your nexus. But the
>>> remedy is simple: clean out the nexus-plugins repository and start over :)
>>> ~t~
>>>
>>> 2009/7/28 Tamás Cservenák <tamas@...>
>>>>
>>>> Hi Sascha,
>>>> Right now, the API is still in flux and mostly unimplemented (look for
>>>> NexusPluginManager component).
>>>> To deploy it "fast and dirty" (again, this is true _now_, but who knows
>>>> later):
>>>> cd ${nexus-work}/plugin-repository
>>>> cp yourPluginBundle.zip .
>>>> unzip yourPluginBundle.zip
>>>> That's all :)
>>>>
>>>> So, in words: simply unzip the produced plugin ZIP bundle at root of the plugin-repository.
>>>> Naturally, this needs Nexus restart. If you would do this from Nexus (ie.
>>>> when "plugin install" API will be done), no restart will be needed.
>>>> ~t~
>>>>
>>>> On Tue, Jul 28, 2009 at 4:57 PM, Sascha Scholz <sascha@...> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> following your blog posts, I'm going to create a Nexus plugin that
>>>>> provides a new repository type. Unfortunately, I'm already stuck with the
>>>>> plugin examples mentioned in the blog. I managed to build
>>>>> nexus-simple-repository-plugin, but I have no idea how it could be deployed
>>>>> to Nexus (1.4.0-SNAPSHOT). An API for the plugin manager is mentioned, but I
>>>>> couldn't find anything more concrete.
>>>>>
>>>>> Any help is appreciated...
>>>>>
>>>>> Thanks and regards,
>>>>> Sascha
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: nexus-dev-unsubscribe@...
>>>>> For additional commands, e-mail: nexus-dev-help@...
>>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: nexus-dev-unsubscribe@...
>> For additional commands, e-mail: nexus-dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nexus-dev-unsubscribe@...
> For additional commands, e-mail: nexus-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[Sascha Scholz]

Hi Tamás,

Tamás Cservenák wrote:
> So, in words: simply unzip the produced plugin ZIP bundle at root of
> the plugin-repository.
> Naturally, this needs Nexus restart. If you would do this from Nexus (ie.
> when "plugin install" API will be done), no restart will be needed.

That did it, thanks a lot. The sample plugin is activated at startup  
time. Naturally, the next question is how to create a repository of  
the sample type. In the UI nothing shows up, so I manually created an  
entry in conf/nexus.xml:

<repository>
   <id>test</id>
   <name>Test</name>
   <providerRole>
     org.sonatype.nexus.plugin.samples.samplerepo.SampleRepository
   </providerRole>
   <providerHint>sample</providerHint>
   ...
</repository>

This doesn't work, but produces an error at Nexus startup:

jvm 1    | Caused by:  
org.codehaus.plexus.component.repository.exception.ComponentLookupException:  
Component descriptor cannot be found in the component reposit
ory
jvm 1    |       role:  
org.sonatype.nexus.plugin.samples.samplerepo.SampleRepository
jvm 1    |   roleHint: sample
jvm 1    | classRealm: none specified
jvm 1    |      at  
org.codehaus.plexus.DefaultComponentRegistry.getComponentManager(DefaultComponentRegistry.java:408)
jvm 1    |      at  
org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:346)
jvm 1    |      at  
org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:178)
jvm 1    |      at  
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:378)
jvm 1    |      at  
org.sonatype.nexus.configuration.application.runtime.DefaultApplicationRuntimeConfigurationBuilder.createRepository(DefaultApplicationRuntime
ConfigurationBuilder.java:59)
jvm 1    |      ... 47 more

So, I assume it's not the correct way of adding the repo...

Regards,
Sascha

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[Tamás Cservenák]

Hi,
the "providerHint" is not "sample", it is
"org.sonatype.nexus.plugin.samples.samplerepo.
DefaultSampleRepository" (the implementing class FQN) since
@RepositoryType is "plural" component annotation, see here (line 802):

http://scm.sonatype.org/showfile.svn?path=/trunk/nexus/nexus-plugins/nexus-plugin-manager/src/main/java/org/sonatype/nexus/plugins/DefaultNexusPluginManager.java&revision=HEAD&name=Nexus

Hope helps,
~t~

On Wed, Jul 29, 2009 at 1:51 PM, Sascha Scholz <sascha@...> wrote:

>
> Hi Tamás,
>
> Tamás Cservenák wrote:
>>
>> So, in words: simply unzip the produced plugin ZIP bundle at root of
>> the plugin-repository.
>> Naturally, this needs Nexus restart. If you would do this from Nexus (ie.
>> when "plugin install" API will be done), no restart will be needed.
>
> That did it, thanks a lot. The sample plugin is activated at startup time. Naturally, the next question is how to create a repository of the sample type. In the UI nothing shows up, so I manually created an entry in conf/nexus.xml:
>
> <repository>
>  <id>test</id>
>  <name>Test</name>
>  <providerRole>
>    org.sonatype.nexus.plugin.samples.samplerepo.SampleRepository
>  </providerRole>
>  <providerHint>sample</providerHint>
>  ...
> </repository>
>
> This doesn't work, but produces an error at Nexus startup:
>
> jvm 1    | Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component reposit
> ory
> jvm 1    |       role: org.sonatype.nexus.plugin.samples.samplerepo.SampleRepository
> jvm 1    |   roleHint: sample
> jvm 1    | classRealm: none specified
> jvm 1    |      at org.codehaus.plexus.DefaultComponentRegistry.getComponentManager(DefaultComponentRegistry.java:408)
> jvm 1    |      at org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:346)
> jvm 1    |      at org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:178)
> jvm 1    |      at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:378)
> jvm 1    |      at org.sonatype.nexus.configuration.application.runtime.DefaultApplicationRuntimeConfigurationBuilder.createRepository(DefaultApplicationRuntime
> ConfigurationBuilder.java:59)
> jvm 1    |      ... 47 more
>
> So, I assume it's not the correct way of adding the repo...
>
> Regards,
> Sascha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nexus-dev-unsubscribe@...
> For additional commands, e-mail: nexus-dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[Tamás Cservenák]

And yes, currently this is the only way to add any "non core" repo to
Nexus (without digging to deep into UI from a plugin), since the UI
and current REST API is not flexible enough to manage these in generic
way. This is why are we planning REST API v2 ;)

~t~

On Wed, Jul 29, 2009 at 1:51 PM, Sascha Scholz<sascha@...> wrote:

> Hi Tamás,
>
> Tamás Cservenák wrote:
>>
>> So, in words: simply unzip the produced plugin ZIP bundle at root of
>> the plugin-repository.
>> Naturally, this needs Nexus restart. If you would do this from Nexus (ie.
>> when "plugin install" API will be done), no restart will be needed.
>
> That did it, thanks a lot. The sample plugin is activated at startup time.
> Naturally, the next question is how to create a repository of the sample
> type. In the UI nothing shows up, so I manually created an entry in
> conf/nexus.xml:
>
> <repository>
>  <id>test</id>
>  <name>Test</name>
>  <providerRole>
>    org.sonatype.nexus.plugin.samples.samplerepo.SampleRepository
>  </providerRole>
>  <providerHint>sample</providerHint>
>  ...
> </repository>
>
> This doesn't work, but produces an error at Nexus startup:
>
> jvm 1    | Caused by:
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> Component descriptor cannot be found in the component reposit
> ory
> jvm 1    |       role:
> org.sonatype.nexus.plugin.samples.samplerepo.SampleRepository
> jvm 1    |   roleHint: sample
> jvm 1    | classRealm: none specified
> jvm 1    |      at
> org.codehaus.plexus.DefaultComponentRegistry.getComponentManager(DefaultComponentRegistry.java:408)
> jvm 1    |      at
> org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:346)
> jvm 1    |      at
> org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:178)
> jvm 1    |      at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:378)
> jvm 1    |      at
> org.sonatype.nexus.configuration.application.runtime.DefaultApplicationRuntimeConfigurationBuilder.createRepository(DefaultApplicationRuntime
> ConfigurationBuilder.java:59)
> jvm 1    |      ... 47 more
>
> So, I assume it's not the correct way of adding the repo...
>
> Regards,
> Sascha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nexus-dev-unsubscribe@...
> For additional commands, e-mail: nexus-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[Sascha Scholz]

Hi Tamás et al.,

thanks to your help I finally got the sample plugin running. Still, I  
don't understand all the details of the implementation (e.g. how to  
use that repository color sample property), but at least something  
works.

Unfortunately, from just reading the sources I couldn't find out if  
I'm on the right track for the actual problem I'm working on. I'd  
appreciate if someone could give me some more advice:

We plan to make artifacts from a different (internal) build technology  
with an own project model visible to Maven projects. The artifacts are  
kept in a (proprietary) repository together with some meta information  
(like imported projects, i.e. dependencies). To map these to Maven we  
think about using a Maven wagon or a Nexus repository plugin. The  
actual tasks for the Nexus plugin would be:

- Generate POMs (first step, only GAV coordinates, later with  
dependencies) for requested artifacts
- Route requests sent to the virtual repository to the backend  
repository and deliver requested artifacts

I haven't yet looked into the details, but for me that sounds similar  
to what you're doing with the Maven1<->Maven2 virtual repositories  
(with the exception that the backend repository is not hosted inside  
Nexus).

Is it possible to write such a plugin with the current means provided  
in the plugin API? Is it the correct Nexus way at all? And, if yes,  
I'd really appreciate if you could give some hints/pointers where to  
start.

Thanks a lot and regards,
Sascha

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...

[Tamás Cservenák]

Yup,

you are on right path. Nexus is just meant for problems like these ;)

You can take multiple implementation paths for this, one of these would be:

* create a proxy repository type for your "custom" reposes (although, i don't know yet what makes it "custom", layout only or content, whatever)

* create a shadow repository that would convert the proxy repository "on the fly" to M2 repository (this is just like you said, how M1->M2 works. shadow reposes are able to convert layout on the fly without duplicating content. Nexus supports links, a la Linux symlink, and it is just a matter of laying out symlinks that links back to original artifact in custom repo).

But, POM generation is not covered by Shadow reposes (but they are able to do it). So, maybe some "hybrid" solution would be needed here.

It is possible with current API, and yes, it is the correct way.

Well, again, i can't give any pointers until i learn a little bit more about your "custom" repo type. Depending on it, the implementation may differ. Maybe it is better to go with custom-proxy + shadow, or some custom_proxy that generates poms too....

~t~

On Thu, Jul 30, 2009 at 3:07 PM, Sascha Scholz <sascha@...> wrote:

Hi Tamás et al.,

thanks to your help I finally got the sample plugin running. Still, I don't understand all the details of the implementation (e.g. how to use that repository color sample property), but at least something works.

Unfortunately, from just reading the sources I couldn't find out if I'm on the right track for the actual problem I'm working on. I'd appreciate if someone could give me some more advice:

We plan to make artifacts from a different (internal) build technology with an own project model visible to Maven projects. The artifacts are kept in a (proprietary) repository together with some meta information (like imported projects, i.e. dependencies). To map these to Maven we think about using a Maven wagon or a Nexus repository plugin. The actual tasks for the Nexus plugin would be:

- Generate POMs (first step, only GAV coordinates, later with dependencies) for requested artifacts
- Route requests sent to the virtual repository to the backend repository and deliver requested artifacts

I haven't yet looked into the details, but for me that sounds similar to what you're doing with the Maven1<->Maven2 virtual repositories (with the exception that the backend repository is not hosted inside Nexus).

Is it possible to write such a plugin with the current means provided in the plugin API? Is it the correct Nexus way at all? And, if yes, I'd really appreciate if you could give some hints/pointers where to start.

Thanks a lot and regards,

Sascha

---------------------------------------------------------------------
To unsubscribe, e-mail: nexus-dev-unsubscribe@...
For additional commands, e-mail: nexus-dev-help@...