dependency type based repositories

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

dependency type based repositories

Ishaaq Chandy
Hi all,
I have the following requirements:

1. A hosted repository only for Releases
2. A hosted repository only for Snapshots
3. A hosted repository only for 3rd party dependencies
4. Any number of proxy repositories for 3rd party build process dependencies (i.e. plugin and test dependencies).

I know Nexus can solve 1 & 2. The question is around 3 & 4 - is there a way to distinguish normal compile/runtime dependencies from dependencies used by the build process (i.e. plugin and test dependencies)?

The reason we need this is because while we need to lock down our 3rd party dependencies to avoid licensing violations (e.g. no GPL licensed dependencies allowed) we have no such license restrictions around dependencies used by the internal build process.

I imagine there are quite a few others out there with these kinds of requirements, hence I thought I'd ask.

Thanks,
Ishaaq
Reply | Threaded
Open this post in threaded view
|

RE: dependency type based repositories

Brian E. Fox

I’m not sure I understand the requirement…you can have as many separate repos as you want and put them into a logical group.

 

From: Ishaaq Chandy [mailto:[hidden email]]
Sent: Tuesday, June 24, 2008 11:44 PM
To: [hidden email]
Subject: [nexus-user] dependency type based repositories

 

Hi all,
I have the following requirements:

1. A hosted repository only for Releases
2. A hosted repository only for Snapshots
3. A hosted repository only for 3rd party dependencies
4. Any number of proxy repositories for 3rd party build process dependencies (i.e. plugin and test dependencies).

I know Nexus can solve 1 & 2. The question is around 3 & 4 - is there a way to distinguish normal compile/runtime dependencies from dependencies used by the build process (i.e. plugin and test dependencies)?

The reason we need this is because while we need to lock down our 3rd party dependencies to avoid licensing violations (e.g. no GPL licensed dependencies allowed) we have no such license restrictions around dependencies used by the internal build process.

I imagine there are quite a few others out there with these kinds of requirements, hence I thought I'd ask.

Thanks,
Ishaaq

Reply | Threaded
Open this post in threaded view
|

Re: dependency type based repositories

Ishaaq Chandy
Sorry, my fault, I did not explain enough.

So, say I add a proxy repo for my 3rd party plugin and test dependencies. How do I make sure that only plugin and test dependencies are proxied using this repository? For e.g., if I create a proxy to the main maven repo, it is ok to download something like JUnit or TestNG or any of the maven plugins from it, but it is not ok to download a compile time or runtime dependency (for e.g. hibernate) from it. The only repo I can use to download the latter is from the designated 3rd party repo which is hosted not proxied.

Hope that makes more sense.
Thanks,
Ishaaq

2008/6/25 Brian E. Fox <[hidden email]>:

I'm not sure I understand the requirement…you can have as many separate repos as you want and put them into a logical group.

 

From: Ishaaq Chandy [mailto:[hidden email]]
Sent: Tuesday, June 24, 2008 11:44 PM
To: [hidden email]
Subject: [nexus-user] dependency type based repositories

 

Hi all,
I have the following requirements:

1. A hosted repository only for Releases
2. A hosted repository only for Snapshots
3. A hosted repository only for 3rd party dependencies
4. Any number of proxy repositories for 3rd party build process dependencies (i.e. plugin and test dependencies).

I know Nexus can solve 1 & 2. The question is around 3 & 4 - is there a way to distinguish normal compile/runtime dependencies from dependencies used by the build process (i.e. plugin and test dependencies)?

The reason we need this is because while we need to lock down our 3rd party dependencies to avoid licensing violations (e.g. no GPL licensed dependencies allowed) we have no such license restrictions around dependencies used by the internal build process.

I imagine there are quite a few others out there with these kinds of requirements, hence I thought I'd ask.

Thanks,
Ishaaq


Reply | Threaded
Open this post in threaded view
|

Re: dependency type based repositories

Brian E. Fox
Re: [nexus-user] dependency type based repositories I see. This isn’t really possible to do from Nexus. Nexus only sees the http get requests that Maven issues and it has no way of knowing what scope a dependency has. Maven also doesn’t have the ability to segregate repositories by scope — only snapshot or release  or plugins.

You can add routing rules to Nexus if you know ahead of time what the paths (group id / artifact id ) will be.


On 6/25/08 12:22 AM, "Ishaaq Chandy" <ishaaq@...> wrote:

Sorry, my fault, I did not explain enough.

So, say I add a proxy repo for my 3rd party plugin and test dependencies. How do I make sure that only plugin and test dependencies are proxied using this repository? For e.g., if I create a proxy to the main maven repo, it is ok to download something like JUnit or TestNG or any of the maven plugins from it, but it is not ok to download a compile time or runtime dependency (for e.g. hibernate) from it. The only repo I can use to download the latter is from the designated 3rd party repo which is hosted not proxied.

Hope that makes more sense.
Thanks,
Ishaaq

2008/6/25 Brian E. Fox <brianf@...>:
I'm not sure I understand the requirement…you can have as many separate repos as you want and put them into a logical group.

 

From: Ishaaq Chandy [[hidden email]]
Sent: Tuesday, June 24, 2008 11:44 PM
To: nexus-user@...
Subject: [nexus-user] dependency type based repositories

 

Hi all,
I have the following requirements:

1. A hosted repository only for Releases
2. A hosted repository only for Snapshots
3. A hosted repository only for 3rd party dependencies
4. Any number of proxy repositories for 3rd party build process dependencies (i.e. plugin and test dependencies).

I know Nexus can solve 1 & 2. The question is around 3 & 4 - is there a way to distinguish normal compile/runtime dependencies from dependencies used by the build process (i.e. plugin and test dependencies)?

The reason we need this is because while we need to lock down our 3rd party dependencies to avoid licensing violations (e.g. no GPL licensed dependencies allowed) we have no such license restrictions around dependencies used by the internal build process.

I imagine there are quite a few others out there with these kinds of requirements, hence I thought I'd ask.

Thanks,
Ishaaq


Reply | Threaded
Open this post in threaded view
|

Re: dependency type based repositories

Brian Sanders

One of our applications also requires more fine-grained dependency resolution than Maven will provide.  Apache Ivy has proven to be a good solution for us; we can specify a number of different resolution scopes.
However, Apache Ivy is not a full-fledged build solution in and of itself.  It's purely a dependency management tool.  I'm not sure that it integrates well with Maven at all.  It does, however, work great with Nexus.  ;-)
All this comes with the caveat that I'm not a Maven expert.  There may well be a solution for this sort of thing within the Maven community.


Brian Sanders  |  Aon eSolutions
Software Architect
531 Roselane Street, NW, Suite 800, Marietta, GA 30060
P: 678.784.4614  F: 678.784.4714   

[hidden email]

 

This message is intended only for the named recipient and may contain confidential, proprietary or legally privileged information. Unauthorized individuals or entities are not permitted access to this information. Any dissemination, distribution, or copying of this information is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete this message and any attachments.

 


"Brian E. Fox" <[hidden email]>

06/25/2008 10:01 AM

Please respond to
[hidden email]

To
<[hidden email]>
cc
Subject
Re: [nexus-user] dependency type based repositories





I see. This isn’t really possible to do from Nexus. Nexus only sees the http get requests that Maven issues and it has no way of knowing what scope a dependency has. Maven also doesn’t have the ability to segregate repositories by scope — only snapshot or release  or plugins.

You can add routing rules to Nexus if you know ahead of time what the paths (group id / artifact id ) will be.


On 6/25/08 12:22 AM, "Ishaaq Chandy" <
ishaaq@...> wrote:

Sorry, my fault, I did not explain enough.

So, say I add a proxy repo for my 3rd party plugin and test dependencies. How do I make sure that only plugin and test dependencies are proxied using this repository? For e.g., if I create a proxy to the main maven repo, it is ok to download something like JUnit or TestNG or any of the maven plugins from it, but it is not ok to download a compile time or runtime dependency (for e.g. hibernate) from it. The only repo I can use to download the latter is from the designated 3rd party repo which is hosted not proxied.

Hope that makes more sense.
Thanks,
Ishaaq

2008/6/25 Brian E. Fox <
brianf@...>:
I'm not sure I understand the requirement…you can have as many separate repos as you want and put them into a logical group.



From:
Ishaaq Chandy [
mailto:ishaaq@...]
Sent:
Tuesday, June 24, 2008 11:44 PM
To:
nexus-user@...
Subject:
[nexus-user] dependency type based repositories




Hi all,
I have the following requirements:

1. A hosted repository only for Releases
2. A hosted repository only for Snapshots
3. A hosted repository only for 3rd party dependencies
4. Any number of proxy repositories for 3rd party build process dependencies (i.e. plugin and test dependencies).

I know Nexus can solve 1 & 2. The question is around 3 & 4 - is there a way to distinguish normal compile/runtime dependencies from dependencies used by the build process (i.e. plugin and test dependencies)?

The reason we need this is because while we need to lock down our 3rd party dependencies to avoid licensing violations (e.g. no GPL licensed dependencies allowed) we have no such license restrictions around dependencies used by the internal build process.

I imagine there are quite a few others out there with these kinds of requirements, hence I thought I'd ask.

Thanks,
Ishaaq