[JBoss JIRA] (SHRINKRES-78) Build under JDK 7 fails
by Michal Matloka (JIRA)
Michal Matloka created SHRINKRES-78:
---------------------------------------
Summary: Build under JDK 7 fails
Key: SHRINKRES-78
URL: https://issues.jboss.org/browse/SHRINKRES-78
Project: ShrinkWrap Resolvers
Issue Type: Bug
Environment: jdk 7
Reporter: Michal Matloka
Assignee: Andrew Rubinger
{noformat}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project shrinkwrap-resolver-api: Compilation failure: Compilation failure:
[ERROR] \Dev\JBoss\shrinkwrap resolver\api\src\main\java\org\jboss\shrinkwrap\resolver\api\FormatStage.java:[67,18] error: name clash: as(Class<InputStream>) and as(Class<File>) have the same erasure
[ERROR] \Dev\JBoss\shrinkwrap resolver\api\src\main\java\org\jboss\shrinkwrap\resolver\api\FormatStage.java:[81,16] error: name clash: asSingle(Class<InputStream>) and asSingle(Class<File>) have the same erasure
{noformat}
This article describes cause of this problem: http://notatube.blogspot.com/2010/07/interesting-change-to-method-signatu...
Resoluion - API change?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (SHRINKRES-82) Create SPI Module
by Andrew Rubinger (JIRA)
Andrew Rubinger created SHRINKRES-82:
----------------------------------------
Summary: Create SPI Module
Key: SHRINKRES-82
URL: https://issues.jboss.org/browse/SHRINKRES-82
Project: ShrinkWrap Resolvers
Issue Type: Feature Request
Reporter: Andrew Rubinger
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 2.0.0-alpha-5
The registry approach for Formatters introduced in SHRINKRES-78 opens the requirement that we allow extensiblility without exposing the specifics of our extension points through the standard user API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (SHRINKRES-64) Fix cyclic dependency in PluginIntegrationTestCase.strictlyLoadTestDependencies
by Andrew Rubinger (JIRA)
Andrew Rubinger created SHRINKRES-64:
----------------------------------------
Summary: Fix cyclic dependency in PluginIntegrationTestCase.strictlyLoadTestDependencies
Key: SHRINKRES-64
URL: https://issues.jboss.org/browse/SHRINKRES-64
Project: ShrinkWrap Resolvers
Issue Type: Feature Request
Affects Versions: 2.0.0-alpha-2
Reporter: Andrew Rubinger
Assignee: Andrew Rubinger
This test will attempt to load *current* versions, which are not in place during a release:
{code}$ ls -l /home/alr/.m2/repository/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-api-maven/2.0.0-alpha-2/
total 12
-rw-rw-r-- 1 alr alr 164 2012-09-13 00:01 m2e-lastUpdated.properties
-rw-rw-r-- 1 alr alr 235 2012-09-13 00:01 shrinkwrap-resolver-api-maven-2.0.0-alpha-2.jar.lastUpdated
-rw-rw-r-- 1 alr alr 235 2012-09-13 00:01 shrinkwrap-resolver-api-maven-2.0.0-alpha-2.pom.lastUpdated{code}
For now the test will be @Ignore'd
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (SHRINKRES-83) Remove api-maven-archive
by Andrew Rubinger (JIRA)
Andrew Rubinger created SHRINKRES-83:
----------------------------------------
Summary: Remove api-maven-archive
Key: SHRINKRES-83
URL: https://issues.jboss.org/browse/SHRINKRES-83
Project: ShrinkWrap Resolvers
Issue Type: Feature Request
Reporter: Andrew Rubinger
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 2.0.0-alpha-5
With the FormatProcessor refactoring done in SHRINKRES-78, "ShrinkWrapMaven" and all related APIs (which served ONLY to carry through the generic context) may now be removed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (SHRINKRES-81) Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own
by Michal Matloka (JIRA)
Michal Matloka created SHRINKRES-81:
---------------------------------------
Summary: Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own
Key: SHRINKRES-81
URL: https://issues.jboss.org/browse/SHRINKRES-81
Project: ShrinkWrap Resolvers
Issue Type: Task
Reporter: Michal Matloka
Assignee: Michal Matloka
TODO located in MavenStrategyBaseImpl
// TODO Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own
// representation
and
MavenWorkingSession
// TODO We're not really encapsulating much here, as we expose out Aether and Maven classes. Refactor this class and
// usages to hide all implementation details of Maven and Aether *behind* this SPI facade
Some of this refactors has to be made for SHRINKRES-27
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (SHRINKRES-76) Version of the dependency is not found when <exclusion>s are defined
by Karel Piwko (JIRA)
Karel Piwko created SHRINKRES-76:
------------------------------------
Summary: Version of the dependency is not found when <exclusion>s are defined
Key: SHRINKRES-76
URL: https://issues.jboss.org/browse/SHRINKRES-76
Project: ShrinkWrap Resolvers
Issue Type: Bug
Components: impl-maven
Affects Versions: 2.0.0-alpha-4
Reporter: Karel Piwko
Assignee: Andrew Rubinger
equals(Object) method for Maven dependency is considering exclusions as well.
This effectively means that if you specify following in your pom.xml file:
{code:xml}
<dependency>
<groupId>com.google.appengine.orm</groupId>
<artifactId>datanucleus-appengine</artifactId>
<version>${version.org.datanucleus.gae}</version>
<exclusions>
<exclusion>
<!-- Force this just in case -->
<groupId>org.jboss.maven.plugins</groupId>
<artifactId>arquillian-transformer</artifactId>
</exclusion>
</exclusions>
</dependency>
{code}
then following code:
{code}
Maven.resolver().loadPomFromFile("/path/to/file").resolve("com.google.appengine.orm:datanucleus-appengine")
{code}
is not able to find the version managed in pom.xml, failing with:
Caused by: org.jboss.shrinkwrap.resolver.api.ResolutionException: Unable to get version for dependency specified by com.google.appengine.orm:datanucleus-appengine, it was not provided in <dependencyManagement> section.
at org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageBaseImpl.resolveVersion(PomEquippedResolveStageBaseImpl.java:194)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (SHRINKRES-27) Allow for full dependency info from MavenDependencyResolver::resolve
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-27?page=com.atlassian.jira.plug... ]
Michal Matloka edited comment on SHRINKRES-27 at 11/2/12 11:39 AM:
-------------------------------------------------------------------
Assuming that we're resolving the following structure of dependencies
* some pom
** parentA
*** childAA
*** childAB
** parentB
Currently executing as File/InputStream/ResolvedArtifactInfo results in list { parentA, childAA, childAB, parentB }.
Aether allows to read this not in form of such list but in form of graph (which may contain .pom's in its structure). So this complicates a little, becasue as(ResolvedArtifactInfo.class) can result in one element (pom) (one element list?) with getDependencies(); ({ parentA, parentB } and both them having their dependencies) instead of { parentA, childAA, childAB, parentB } (still used for File and InputStream) ?
Then inside our implementation we have to keep both types of representations (list and graph) and pass them to FORMATSTAGETYPE (instead of current Collection<Artifact> ).
was (Author: mmatloka):
Assuming that we're resolving the following structure of dependencies
* parentA
** childAA
** childAB
* parentB
Currently executing as File/InputStream/ResolvedArtifactInfo results in list { parentA, childAA, childAB, parentB }.
Aether allows to read this not in form of such list but in form of graph. So I assume as(ResolvedArtifactInfo.class) should result in list of { parentA, parentB } with getDependencies(); instead of { parentA, childAA, childAB, parentB } (still used for File and InputStream) ?
Then inside our implementation we have to keep both types of representations (list and graph) and pass them to FORMATSTAGETYPE (instead of current Collection<Artifact> ).
> Allow for full dependency info from MavenDependencyResolver::resolve
> --------------------------------------------------------------------
>
> Key: SHRINKRES-27
> URL: https://issues.jboss.org/browse/SHRINKRES-27
> Project: ShrinkWrap Resolvers
> Issue Type: Feature Request
> Components: api-maven, impl-maven
> Affects Versions: 2.0.0-alpha-2
> Reporter: Ales Justin
> Assignee: Michal Matloka
>
> It would be useful to be able to grab full dependency info, not just files.
> e.g. name, version, import type, etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (SHRINKRES-27) Allow for full dependency info from MavenDependencyResolver::resolve
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-27?page=com.atlassian.jira.plug... ]
Michal Matloka edited comment on SHRINKRES-27 at 11/2/12 8:59 AM:
------------------------------------------------------------------
Assuming that we're resolving the following structure of dependencies
* parentA
** childAA
** childAB
* parentB
Currently executing as File/InputStream/ResolvedArtifactInfo results in list { parentA, childAA, childAB, parentB }.
Aether allows to read this not in form of such list but in form of graph. So I assume as(ResolvedArtifactInfo.class) should result in list of { parentA, parentB } with getDependencies(); instead of { parentA, childAA, childAB, parentB } (still used for File and InputStream) ?
Then inside our implementation we have to keep both types of representations (list and graph) and pass them to FORMATSTAGETYPE (instead of current Collection<Artifact> ).
was (Author: mmatloka):
Assuming that we're resolving the following structure of dependencies
* parentA
- childAA
- childAB
* parentB
Currently executing as File/InputStream/ResolvedArtifactInfo results in list { parentA, childAA, childAB, parentB }.
Aether allows to read this not in form of such list but in form of graph. So I assume as(ResolvedArtifactInfo.class) should result in list of { parentA, parentB } with getDependencies(); instead of { parentA, childAA, childAB, parentB } (still used for File and InputStream) ?
Then inside our implementation we have to keep both types of representations (list and graph) and pass them to FORMATSTAGETYPE (instead of current Collection<Artifact> ).
> Allow for full dependency info from MavenDependencyResolver::resolve
> --------------------------------------------------------------------
>
> Key: SHRINKRES-27
> URL: https://issues.jboss.org/browse/SHRINKRES-27
> Project: ShrinkWrap Resolvers
> Issue Type: Feature Request
> Components: api-maven, impl-maven
> Affects Versions: 2.0.0-alpha-2
> Reporter: Ales Justin
> Assignee: Michal Matloka
>
> It would be useful to be able to grab full dependency info, not just files.
> e.g. name, version, import type, etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (SHRINKRES-27) Allow for full dependency info from MavenDependencyResolver::resolve
by Michal Matloka (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-27?page=com.atlassian.jira.plug... ]
Michal Matloka commented on SHRINKRES-27:
-----------------------------------------
Assuming that we're resolving the following structure of dependencies
* parentA
- childAA
- childAB
* parentB
Currently executing as File/InputStream/ResolvedArtifactInfo results in list { parentA, childAA, childAB, parentB }.
Aether allows to read this not in form of such list but in form of graph. So I assume as(ResolvedArtifactInfo.class) should result in list of { parentA, parentB } with getDependencies(); instead of { parentA, childAA, childAB, parentB } (still used for File and InputStream) ?
Then inside our implementation we have to keep both types of representations (list and graph) and pass them to FORMATSTAGETYPE (instead of current Collection<Artifact> ).
> Allow for full dependency info from MavenDependencyResolver::resolve
> --------------------------------------------------------------------
>
> Key: SHRINKRES-27
> URL: https://issues.jboss.org/browse/SHRINKRES-27
> Project: ShrinkWrap Resolvers
> Issue Type: Feature Request
> Components: api-maven, impl-maven
> Affects Versions: 2.0.0-alpha-2
> Reporter: Ales Justin
> Assignee: Michal Matloka
>
> It would be useful to be able to grab full dependency info, not just files.
> e.g. name, version, import type, etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months