You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stephen Gargan (JIRA)" <ji...@apache.org> on 2010/01/14 01:46:54 UTC
[jira] Created: (CASSANDRA-697) Mitigate unpublished dependencies
when using Cassandra with Maven
Mitigate unpublished dependencies when using Cassandra with Maven
-----------------------------------------------------------------
Key: CASSANDRA-697
URL: https://issues.apache.org/jira/browse/CASSANDRA-697
Project: Cassandra
Issue Type: Improvement
Components: Core, Tools
Affects Versions: 0.5
Reporter: Stephen Gargan
Priority: Minor
Fix For: 0.5
Attachments: dependency-patch.txt
So I have a suggestion to improve the maven build and help mitigate the fact that cassandra relies on unpublished dependencies. While the system dependency approach works fine for building cassandra alone, it breaks down somewhat if you include cassandra as a dependency in another project. The problem stems from the fac that system dependency paths must be absolute, but in the cassandra pom they are relative to the project root. When cassandra is then used as a dependency elsewhere, all the dependencies from the cassandra pom are ignored
[WARNING] POM for 'org.apache.cassandra:cassandra:pom:0.5:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.apache.cassandra:c
[DEBUG] Reason: Failed to validate POM for project org.apache.cassandra:cassandra at Artifact [org.apache.cassandra:cassandra:pom:0.5:compile]
[DEBUG]
Validation Errors:
[DEBUG] For dependency Dependency {groupId=high-scale-lib, artifactId=high-scale-lib, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
[DEBUG] For dependency Dependency {groupId=libthrift, artifactId=libthrift, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
[DEBUG] For dependency Dependency {groupId=reardencommerce, artifactId=reardencommerce, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
[DEBUG] For dependency Dependency {groupId=jsonsimple, artifactId=jsonsimple, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
[DEBUG] For dependency Dependency {groupId=com.reardencommerce, artifactId=clhm, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
There are a couple of ways to fix this. Ideally if the failing deps could get published to a public repo the problem goes away. As a stopgap (for this less than perfect world) it would nice if it were easy to install the respective jars from the ant build to a local or network maven repo, so I've created a pom to do this.
The pom, in the lib dir, specifies two profiles install and deploy; The 'install' profile is run via
mvn validate -Pinstall
and will install them in the local repo on your machine.
Just having install is a pain where you have more than one developer as it will require each to get the source and execute the profile, so to make them available for a whole team the 'deploy' profile can be used to deploy them to an enterprise repository such as nexus. This is done via
mvn -Pdeploy validate -DrepositoryId=thirdparty -DrepositoryUrl=http://mfdevrepo:8081/nexus/content/repositories/thirdparty
The pom now references the dependencies as normal from the local repo. The version was specified where it was obvious and where not 'cassandra-version' was used to avoid collisions and hint at the origin.
<dependency>
<groupId>high-scale-lib</groupId>
<artifactId>high-scale-lib</artifactId>
<version>cassandra-${version}</version>
</dependency>
<dependency>
<groupId>libthrift</groupId>
<artifactId>libthrift</artifactId>
<version>r894924</version>
</dependency>
<dependency>
<groupId>json-simple</groupId>
<artifactId>json-simple</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<groupId>com.reardencommerce</groupId>
<artifactId>clhm</artifactId>
<version>cassandra-${version}</version>
</dependency>
I took the liberty of adding SNAPSHOT to the pom version too as having a non SNAPSHOT version will cause maven to think the pom is released and cast in stone and subsequent updates will not be retrieved and problems related to this can be hard to track down.
I hope you can get some use from this. Thanks for the great project!
rgds,
ste
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-697) Mitigate unpublished dependencies
when using Cassandra with Maven
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans resolved CASSANDRA-697.
----------------------------------
Resolution: Won't Fix
> Mitigate unpublished dependencies when using Cassandra with Maven
> -----------------------------------------------------------------
>
> Key: CASSANDRA-697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-697
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
> Affects Versions: 0.5
> Reporter: Stephen Gargan
> Priority: Minor
> Fix For: 0.5
>
> Attachments: dependency-patch.txt
>
>
> So I have a suggestion to improve the maven build and help mitigate the fact that cassandra relies on unpublished dependencies. While the system dependency approach works fine for building cassandra alone, it breaks down somewhat if you include cassandra as a dependency in another project. The problem stems from the fac that system dependency paths must be absolute, but in the cassandra pom they are relative to the project root. When cassandra is then used as a dependency elsewhere, all the dependencies from the cassandra pom are ignored
> [WARNING] POM for 'org.apache.cassandra:cassandra:pom:0.5:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.apache.cassandra:c
> [DEBUG] Reason: Failed to validate POM for project org.apache.cassandra:cassandra at Artifact [org.apache.cassandra:cassandra:pom:0.5:compile]
> [DEBUG]
> Validation Errors:
> [DEBUG] For dependency Dependency {groupId=high-scale-lib, artifactId=high-scale-lib, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=libthrift, artifactId=libthrift, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=reardencommerce, artifactId=reardencommerce, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=jsonsimple, artifactId=jsonsimple, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=com.reardencommerce, artifactId=clhm, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> There are a couple of ways to fix this. Ideally if the failing deps could get published to a public repo the problem goes away. As a stopgap (for this less than perfect world) it would nice if it were easy to install the respective jars from the ant build to a local or network maven repo, so I've created a pom to do this.
> The pom, in the lib dir, specifies two profiles install and deploy; The 'install' profile is run via
> mvn validate -Pinstall
> and will install them in the local repo on your machine.
> Just having install is a pain where you have more than one developer as it will require each to get the source and execute the profile, so to make them available for a whole team the 'deploy' profile can be used to deploy them to an enterprise repository such as nexus. This is done via
> mvn -Pdeploy validate -DrepositoryId=thirdparty -DrepositoryUrl=http://mfdevrepo:8081/nexus/content/repositories/thirdparty
> The pom now references the dependencies as normal from the local repo. The version was specified where it was obvious and where not 'cassandra-version' was used to avoid collisions and hint at the origin.
> <dependency>
> <groupId>high-scale-lib</groupId>
> <artifactId>high-scale-lib</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> <dependency>
> <groupId>libthrift</groupId>
> <artifactId>libthrift</artifactId>
> <version>r894924</version>
> </dependency>
> <dependency>
> <groupId>json-simple</groupId>
> <artifactId>json-simple</artifactId>
> <version>1.1</version>
> </dependency>
> <dependency>
> <groupId>com.reardencommerce</groupId>
> <artifactId>clhm</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> I took the liberty of adding SNAPSHOT to the pom version too as having a non SNAPSHOT version will cause maven to think the pom is released and cast in stone and subsequent updates will not be retrieved and problems related to this can be hard to track down.
> I hope you can get some use from this. Thanks for the great project!
> rgds,
> ste
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-697) Mitigate unpublished dependencies
when using Cassandra with Maven
Posted by "Stephen Gargan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephen Gargan updated CASSANDRA-697:
-------------------------------------
Attachment: dependency-patch.txt
here is the patch...
> Mitigate unpublished dependencies when using Cassandra with Maven
> -----------------------------------------------------------------
>
> Key: CASSANDRA-697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-697
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
> Affects Versions: 0.5
> Reporter: Stephen Gargan
> Priority: Minor
> Fix For: 0.5
>
> Attachments: dependency-patch.txt
>
>
> So I have a suggestion to improve the maven build and help mitigate the fact that cassandra relies on unpublished dependencies. While the system dependency approach works fine for building cassandra alone, it breaks down somewhat if you include cassandra as a dependency in another project. The problem stems from the fac that system dependency paths must be absolute, but in the cassandra pom they are relative to the project root. When cassandra is then used as a dependency elsewhere, all the dependencies from the cassandra pom are ignored
> [WARNING] POM for 'org.apache.cassandra:cassandra:pom:0.5:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.apache.cassandra:c
> [DEBUG] Reason: Failed to validate POM for project org.apache.cassandra:cassandra at Artifact [org.apache.cassandra:cassandra:pom:0.5:compile]
> [DEBUG]
> Validation Errors:
> [DEBUG] For dependency Dependency {groupId=high-scale-lib, artifactId=high-scale-lib, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=libthrift, artifactId=libthrift, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=reardencommerce, artifactId=reardencommerce, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=jsonsimple, artifactId=jsonsimple, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=com.reardencommerce, artifactId=clhm, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> There are a couple of ways to fix this. Ideally if the failing deps could get published to a public repo the problem goes away. As a stopgap (for this less than perfect world) it would nice if it were easy to install the respective jars from the ant build to a local or network maven repo, so I've created a pom to do this.
> The pom, in the lib dir, specifies two profiles install and deploy; The 'install' profile is run via
> mvn validate -Pinstall
> and will install them in the local repo on your machine.
> Just having install is a pain where you have more than one developer as it will require each to get the source and execute the profile, so to make them available for a whole team the 'deploy' profile can be used to deploy them to an enterprise repository such as nexus. This is done via
> mvn -Pdeploy validate -DrepositoryId=thirdparty -DrepositoryUrl=http://mfdevrepo:8081/nexus/content/repositories/thirdparty
> The pom now references the dependencies as normal from the local repo. The version was specified where it was obvious and where not 'cassandra-version' was used to avoid collisions and hint at the origin.
> <dependency>
> <groupId>high-scale-lib</groupId>
> <artifactId>high-scale-lib</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> <dependency>
> <groupId>libthrift</groupId>
> <artifactId>libthrift</artifactId>
> <version>r894924</version>
> </dependency>
> <dependency>
> <groupId>json-simple</groupId>
> <artifactId>json-simple</artifactId>
> <version>1.1</version>
> </dependency>
> <dependency>
> <groupId>com.reardencommerce</groupId>
> <artifactId>clhm</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> I took the liberty of adding SNAPSHOT to the pom version too as having a non SNAPSHOT version will cause maven to think the pom is released and cast in stone and subsequent updates will not be retrieved and problems related to this can be hard to track down.
> I hope you can get some use from this. Thanks for the great project!
> rgds,
> ste
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-697) Mitigate unpublished dependencies
when using Cassandra with Maven
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800355#action_12800355 ]
Eric Evans commented on CASSANDRA-697:
--------------------------------------
So would this change require that folks do an install or deploy from lib/ before making use of the top-level pom.xml? Are other maveners going to be happy with that? Should that be documented some how?
Disclaimer: I have next to no interest in/knowledge of Maven, but I'm happy to commit changes that others deem worthwhile.
> Mitigate unpublished dependencies when using Cassandra with Maven
> -----------------------------------------------------------------
>
> Key: CASSANDRA-697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-697
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
> Affects Versions: 0.5
> Reporter: Stephen Gargan
> Priority: Minor
> Fix For: 0.5
>
> Attachments: dependency-patch.txt
>
>
> So I have a suggestion to improve the maven build and help mitigate the fact that cassandra relies on unpublished dependencies. While the system dependency approach works fine for building cassandra alone, it breaks down somewhat if you include cassandra as a dependency in another project. The problem stems from the fac that system dependency paths must be absolute, but in the cassandra pom they are relative to the project root. When cassandra is then used as a dependency elsewhere, all the dependencies from the cassandra pom are ignored
> [WARNING] POM for 'org.apache.cassandra:cassandra:pom:0.5:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.apache.cassandra:c
> [DEBUG] Reason: Failed to validate POM for project org.apache.cassandra:cassandra at Artifact [org.apache.cassandra:cassandra:pom:0.5:compile]
> [DEBUG]
> Validation Errors:
> [DEBUG] For dependency Dependency {groupId=high-scale-lib, artifactId=high-scale-lib, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=libthrift, artifactId=libthrift, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=reardencommerce, artifactId=reardencommerce, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=jsonsimple, artifactId=jsonsimple, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=com.reardencommerce, artifactId=clhm, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> There are a couple of ways to fix this. Ideally if the failing deps could get published to a public repo the problem goes away. As a stopgap (for this less than perfect world) it would nice if it were easy to install the respective jars from the ant build to a local or network maven repo, so I've created a pom to do this.
> The pom, in the lib dir, specifies two profiles install and deploy; The 'install' profile is run via
> mvn validate -Pinstall
> and will install them in the local repo on your machine.
> Just having install is a pain where you have more than one developer as it will require each to get the source and execute the profile, so to make them available for a whole team the 'deploy' profile can be used to deploy them to an enterprise repository such as nexus. This is done via
> mvn -Pdeploy validate -DrepositoryId=thirdparty -DrepositoryUrl=http://mfdevrepo:8081/nexus/content/repositories/thirdparty
> The pom now references the dependencies as normal from the local repo. The version was specified where it was obvious and where not 'cassandra-version' was used to avoid collisions and hint at the origin.
> <dependency>
> <groupId>high-scale-lib</groupId>
> <artifactId>high-scale-lib</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> <dependency>
> <groupId>libthrift</groupId>
> <artifactId>libthrift</artifactId>
> <version>r894924</version>
> </dependency>
> <dependency>
> <groupId>json-simple</groupId>
> <artifactId>json-simple</artifactId>
> <version>1.1</version>
> </dependency>
> <dependency>
> <groupId>com.reardencommerce</groupId>
> <artifactId>clhm</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> I took the liberty of adding SNAPSHOT to the pom version too as having a non SNAPSHOT version will cause maven to think the pom is released and cast in stone and subsequent updates will not be retrieved and problems related to this can be hard to track down.
> I hope you can get some use from this. Thanks for the great project!
> rgds,
> ste
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-697) Mitigate unpublished dependencies
when using Cassandra with Maven
Posted by "Stephen Gargan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800368#action_12800368 ]
Stephen Gargan commented on CASSANDRA-697:
------------------------------------------
Yes, you'd need to run the install or deploy first if you wanted the
libraries to be available. It would be best if it were documented e.g.
in a BUILDING.txt or the like. Again, as Ryan mentioned, it would be
best to have them properly published somewhere, but in lieu of that
happening this is not a bad way to go.
thanks,
ste
> Mitigate unpublished dependencies when using Cassandra with Maven
> -----------------------------------------------------------------
>
> Key: CASSANDRA-697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-697
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
> Affects Versions: 0.5
> Reporter: Stephen Gargan
> Priority: Minor
> Fix For: 0.5
>
> Attachments: dependency-patch.txt
>
>
> So I have a suggestion to improve the maven build and help mitigate the fact that cassandra relies on unpublished dependencies. While the system dependency approach works fine for building cassandra alone, it breaks down somewhat if you include cassandra as a dependency in another project. The problem stems from the fac that system dependency paths must be absolute, but in the cassandra pom they are relative to the project root. When cassandra is then used as a dependency elsewhere, all the dependencies from the cassandra pom are ignored
> [WARNING] POM for 'org.apache.cassandra:cassandra:pom:0.5:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.apache.cassandra:c
> [DEBUG] Reason: Failed to validate POM for project org.apache.cassandra:cassandra at Artifact [org.apache.cassandra:cassandra:pom:0.5:compile]
> [DEBUG]
> Validation Errors:
> [DEBUG] For dependency Dependency {groupId=high-scale-lib, artifactId=high-scale-lib, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=libthrift, artifactId=libthrift, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=reardencommerce, artifactId=reardencommerce, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=jsonsimple, artifactId=jsonsimple, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=com.reardencommerce, artifactId=clhm, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> There are a couple of ways to fix this. Ideally if the failing deps could get published to a public repo the problem goes away. As a stopgap (for this less than perfect world) it would nice if it were easy to install the respective jars from the ant build to a local or network maven repo, so I've created a pom to do this.
> The pom, in the lib dir, specifies two profiles install and deploy; The 'install' profile is run via
> mvn validate -Pinstall
> and will install them in the local repo on your machine.
> Just having install is a pain where you have more than one developer as it will require each to get the source and execute the profile, so to make them available for a whole team the 'deploy' profile can be used to deploy them to an enterprise repository such as nexus. This is done via
> mvn -Pdeploy validate -DrepositoryId=thirdparty -DrepositoryUrl=http://mfdevrepo:8081/nexus/content/repositories/thirdparty
> The pom now references the dependencies as normal from the local repo. The version was specified where it was obvious and where not 'cassandra-version' was used to avoid collisions and hint at the origin.
> <dependency>
> <groupId>high-scale-lib</groupId>
> <artifactId>high-scale-lib</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> <dependency>
> <groupId>libthrift</groupId>
> <artifactId>libthrift</artifactId>
> <version>r894924</version>
> </dependency>
> <dependency>
> <groupId>json-simple</groupId>
> <artifactId>json-simple</artifactId>
> <version>1.1</version>
> </dependency>
> <dependency>
> <groupId>com.reardencommerce</groupId>
> <artifactId>clhm</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> I took the liberty of adding SNAPSHOT to the pom version too as having a non SNAPSHOT version will cause maven to think the pom is released and cast in stone and subsequent updates will not be retrieved and problems related to this can be hard to track down.
> I hope you can get some use from this. Thanks for the great project!
> rgds,
> ste
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-697) Mitigate unpublished dependencies
when using Cassandra with Maven
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831723#action_12831723 ]
Eric Evans commented on CASSANDRA-697:
--------------------------------------
As I mentioned before, I don't really have a horse in this race but it would seem that this makes things more difficult for the majority of users in order to accommodate those using cassandra in other projects.
I'm going to close this for now as "won't fix". Feel free to reopen it and start a discussion on the mailing list. If there is consensus among maven users that this would be a Good Thing, I have no problems committing it.
> Mitigate unpublished dependencies when using Cassandra with Maven
> -----------------------------------------------------------------
>
> Key: CASSANDRA-697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-697
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
> Affects Versions: 0.5
> Reporter: Stephen Gargan
> Priority: Minor
> Fix For: 0.5
>
> Attachments: dependency-patch.txt
>
>
> So I have a suggestion to improve the maven build and help mitigate the fact that cassandra relies on unpublished dependencies. While the system dependency approach works fine for building cassandra alone, it breaks down somewhat if you include cassandra as a dependency in another project. The problem stems from the fac that system dependency paths must be absolute, but in the cassandra pom they are relative to the project root. When cassandra is then used as a dependency elsewhere, all the dependencies from the cassandra pom are ignored
> [WARNING] POM for 'org.apache.cassandra:cassandra:pom:0.5:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.apache.cassandra:c
> [DEBUG] Reason: Failed to validate POM for project org.apache.cassandra:cassandra at Artifact [org.apache.cassandra:cassandra:pom:0.5:compile]
> [DEBUG]
> Validation Errors:
> [DEBUG] For dependency Dependency {groupId=high-scale-lib, artifactId=high-scale-lib, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=libthrift, artifactId=libthrift, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=reardencommerce, artifactId=reardencommerce, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=jsonsimple, artifactId=jsonsimple, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=com.reardencommerce, artifactId=clhm, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> There are a couple of ways to fix this. Ideally if the failing deps could get published to a public repo the problem goes away. As a stopgap (for this less than perfect world) it would nice if it were easy to install the respective jars from the ant build to a local or network maven repo, so I've created a pom to do this.
> The pom, in the lib dir, specifies two profiles install and deploy; The 'install' profile is run via
> mvn validate -Pinstall
> and will install them in the local repo on your machine.
> Just having install is a pain where you have more than one developer as it will require each to get the source and execute the profile, so to make them available for a whole team the 'deploy' profile can be used to deploy them to an enterprise repository such as nexus. This is done via
> mvn -Pdeploy validate -DrepositoryId=thirdparty -DrepositoryUrl=http://mfdevrepo:8081/nexus/content/repositories/thirdparty
> The pom now references the dependencies as normal from the local repo. The version was specified where it was obvious and where not 'cassandra-version' was used to avoid collisions and hint at the origin.
> <dependency>
> <groupId>high-scale-lib</groupId>
> <artifactId>high-scale-lib</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> <dependency>
> <groupId>libthrift</groupId>
> <artifactId>libthrift</artifactId>
> <version>r894924</version>
> </dependency>
> <dependency>
> <groupId>json-simple</groupId>
> <artifactId>json-simple</artifactId>
> <version>1.1</version>
> </dependency>
> <dependency>
> <groupId>com.reardencommerce</groupId>
> <artifactId>clhm</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> I took the liberty of adding SNAPSHOT to the pom version too as having a non SNAPSHOT version will cause maven to think the pom is released and cast in stone and subsequent updates will not be retrieved and problems related to this can be hard to track down.
> I hope you can get some use from this. Thanks for the great project!
> rgds,
> ste
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-697) Mitigate unpublished dependencies
when using Cassandra with Maven
Posted by "Ryan Daum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800240#action_12800240 ]
Ryan Daum commented on CASSANDRA-697:
-------------------------------------
This seems like a reasonable approach in the short term but really pushes the burden onto the artifact user.
It would seem more ideal to get thrift, json-simple, clhm (see http://code.google.com/p/concurrentlinkedhashmap/issues/detail?id=3) and high-scale to get their artifacts into a public maven repo and solve this problem once and for all.
I guess the bigger question is whether Cassandra is truly used often as a library linked into an application. If it's not, it's not a huge issue to force the burden onto those few users who choose to use it this way.
I previously contributed patches for both 0.5 and trunk which dealt with the SNAPSHOT issue in a different way. IMHO, 0.5 should not have unless someone with committer privileges is committed to changing it to 0.5 once the release is complete, while trunk should have 0.9-SNAPSHOT as it is not in a release process.
> Mitigate unpublished dependencies when using Cassandra with Maven
> -----------------------------------------------------------------
>
> Key: CASSANDRA-697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-697
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
> Affects Versions: 0.5
> Reporter: Stephen Gargan
> Priority: Minor
> Fix For: 0.5
>
> Attachments: dependency-patch.txt
>
>
> So I have a suggestion to improve the maven build and help mitigate the fact that cassandra relies on unpublished dependencies. While the system dependency approach works fine for building cassandra alone, it breaks down somewhat if you include cassandra as a dependency in another project. The problem stems from the fac that system dependency paths must be absolute, but in the cassandra pom they are relative to the project root. When cassandra is then used as a dependency elsewhere, all the dependencies from the cassandra pom are ignored
> [WARNING] POM for 'org.apache.cassandra:cassandra:pom:0.5:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.apache.cassandra:c
> [DEBUG] Reason: Failed to validate POM for project org.apache.cassandra:cassandra at Artifact [org.apache.cassandra:cassandra:pom:0.5:compile]
> [DEBUG]
> Validation Errors:
> [DEBUG] For dependency Dependency {groupId=high-scale-lib, artifactId=high-scale-lib, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=libthrift, artifactId=libthrift, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=reardencommerce, artifactId=reardencommerce, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=jsonsimple, artifactId=jsonsimple, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=com.reardencommerce, artifactId=clhm, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> There are a couple of ways to fix this. Ideally if the failing deps could get published to a public repo the problem goes away. As a stopgap (for this less than perfect world) it would nice if it were easy to install the respective jars from the ant build to a local or network maven repo, so I've created a pom to do this.
> The pom, in the lib dir, specifies two profiles install and deploy; The 'install' profile is run via
> mvn validate -Pinstall
> and will install them in the local repo on your machine.
> Just having install is a pain where you have more than one developer as it will require each to get the source and execute the profile, so to make them available for a whole team the 'deploy' profile can be used to deploy them to an enterprise repository such as nexus. This is done via
> mvn -Pdeploy validate -DrepositoryId=thirdparty -DrepositoryUrl=http://mfdevrepo:8081/nexus/content/repositories/thirdparty
> The pom now references the dependencies as normal from the local repo. The version was specified where it was obvious and where not 'cassandra-version' was used to avoid collisions and hint at the origin.
> <dependency>
> <groupId>high-scale-lib</groupId>
> <artifactId>high-scale-lib</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> <dependency>
> <groupId>libthrift</groupId>
> <artifactId>libthrift</artifactId>
> <version>r894924</version>
> </dependency>
> <dependency>
> <groupId>json-simple</groupId>
> <artifactId>json-simple</artifactId>
> <version>1.1</version>
> </dependency>
> <dependency>
> <groupId>com.reardencommerce</groupId>
> <artifactId>clhm</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> I took the liberty of adding SNAPSHOT to the pom version too as having a non SNAPSHOT version will cause maven to think the pom is released and cast in stone and subsequent updates will not be retrieved and problems related to this can be hard to track down.
> I hope you can get some use from this. Thanks for the great project!
> rgds,
> ste
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-697) Mitigate unpublished
dependencies when using Cassandra with Maven
Posted by "Ryan Daum (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800240#action_12800240 ]
Ryan Daum edited comment on CASSANDRA-697 at 1/14/10 4:19 PM:
--------------------------------------------------------------
This seems like a reasonable approach in the short term but really pushes the burden onto the artifact user.
It would seem more ideal to get thrift, json-simple, clhm (see http://code.google.com/p/concurrentlinkedhashmap/issues/detail?id=3) and high-scale to get their artifacts into a public maven repo and solve this problem once and for all.
I guess the bigger question is whether Cassandra is truly used often as a library linked into an application. If it's not, it's not a huge issue to force the burden onto those few users who choose to use it this way.
I previously contributed patches for both 0.5 and trunk which dealt with the SNAPSHOT issue in a different way. IMHO, 0.5 should not have -SNAPSHOT unless someone with committer privileges is absolutely committed to changing it to 0.5 when release happens, while trunk should have 0.9-SNAPSHOT as it is not in a release process.
was (Author: ryandaum):
This seems like a reasonable approach in the short term but really pushes the burden onto the artifact user.
It would seem more ideal to get thrift, json-simple, clhm (see http://code.google.com/p/concurrentlinkedhashmap/issues/detail?id=3) and high-scale to get their artifacts into a public maven repo and solve this problem once and for all.
I guess the bigger question is whether Cassandra is truly used often as a library linked into an application. If it's not, it's not a huge issue to force the burden onto those few users who choose to use it this way.
I previously contributed patches for both 0.5 and trunk which dealt with the SNAPSHOT issue in a different way. IMHO, 0.5 should not have unless someone with committer privileges is committed to changing it to 0.5 once the release is complete, while trunk should have 0.9-SNAPSHOT as it is not in a release process.
> Mitigate unpublished dependencies when using Cassandra with Maven
> -----------------------------------------------------------------
>
> Key: CASSANDRA-697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-697
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
> Affects Versions: 0.5
> Reporter: Stephen Gargan
> Priority: Minor
> Fix For: 0.5
>
> Attachments: dependency-patch.txt
>
>
> So I have a suggestion to improve the maven build and help mitigate the fact that cassandra relies on unpublished dependencies. While the system dependency approach works fine for building cassandra alone, it breaks down somewhat if you include cassandra as a dependency in another project. The problem stems from the fac that system dependency paths must be absolute, but in the cassandra pom they are relative to the project root. When cassandra is then used as a dependency elsewhere, all the dependencies from the cassandra pom are ignored
> [WARNING] POM for 'org.apache.cassandra:cassandra:pom:0.5:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM for project org.apache.cassandra:c
> [DEBUG] Reason: Failed to validate POM for project org.apache.cassandra:cassandra at Artifact [org.apache.cassandra:cassandra:pom:0.5:compile]
> [DEBUG]
> Validation Errors:
> [DEBUG] For dependency Dependency {groupId=high-scale-lib, artifactId=high-scale-lib, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=libthrift, artifactId=libthrift, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=reardencommerce, artifactId=reardencommerce, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=jsonsimple, artifactId=jsonsimple, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> [DEBUG] For dependency Dependency {groupId=com.reardencommerce, artifactId=clhm, version=UNKNOWN, type=jar}: system-scoped dependency must specify an absolute path systemPath.
> There are a couple of ways to fix this. Ideally if the failing deps could get published to a public repo the problem goes away. As a stopgap (for this less than perfect world) it would nice if it were easy to install the respective jars from the ant build to a local or network maven repo, so I've created a pom to do this.
> The pom, in the lib dir, specifies two profiles install and deploy; The 'install' profile is run via
> mvn validate -Pinstall
> and will install them in the local repo on your machine.
> Just having install is a pain where you have more than one developer as it will require each to get the source and execute the profile, so to make them available for a whole team the 'deploy' profile can be used to deploy them to an enterprise repository such as nexus. This is done via
> mvn -Pdeploy validate -DrepositoryId=thirdparty -DrepositoryUrl=http://mfdevrepo:8081/nexus/content/repositories/thirdparty
> The pom now references the dependencies as normal from the local repo. The version was specified where it was obvious and where not 'cassandra-version' was used to avoid collisions and hint at the origin.
> <dependency>
> <groupId>high-scale-lib</groupId>
> <artifactId>high-scale-lib</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> <dependency>
> <groupId>libthrift</groupId>
> <artifactId>libthrift</artifactId>
> <version>r894924</version>
> </dependency>
> <dependency>
> <groupId>json-simple</groupId>
> <artifactId>json-simple</artifactId>
> <version>1.1</version>
> </dependency>
> <dependency>
> <groupId>com.reardencommerce</groupId>
> <artifactId>clhm</artifactId>
> <version>cassandra-${version}</version>
> </dependency>
> I took the liberty of adding SNAPSHOT to the pom version too as having a non SNAPSHOT version will cause maven to think the pom is released and cast in stone and subsequent updates will not be retrieved and problems related to this can be hard to track down.
> I hope you can get some use from this. Thanks for the great project!
> rgds,
> ste
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.