[jira] Commented: (MNG-1851) "Duplicate project ID found" message with maven-artifact-ant-2.0.1
[ http://jira.codehaus.org/browse/MNG-1851?page=comments#action_53942 ]
Tomislav Bodor commented on MNG-1851:
-
I *was* looking at trunk. I thought as a bug fix it would make it in there.
Anyway, I checked the maven-2.0.x branch now and I see the change.
Something is still not entirely clear, though: what is the 2.0.2-SNAPSHOT built
from - trunk or that branch (the snapshot I refer to is the one at
http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/maven-artifact-ant/2.0.2-SNAPSHOT/maven-artifact-ant-2.0.2-20051220.231658-1-dep.jar)?
I know this is unofficial, but thought it would be useful to test whether this
issue was resolved and to see if I run into any others (at the moment can't get
past the duplicate project ID, so can't tell what else might be broken). So, I
got it and it has the same bahaviour as 2.0.1. Hence the confusion...
> "Duplicate project ID found" message with maven-artifact-ant-2.0.1
> --
>
> Key: MNG-1851
> URL: http://jira.codehaus.org/browse/MNG-1851
> Project: Maven 2
> Type: Bug
> Components: Ant tasks
> Versions: 2.0.1
> Reporter: John Casey
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0.2
>
>
> from the original email:
> I tried upgrading my Maven 2 Ant Tasks' JAR tonight, and after doing
> so, I'm getting the following error:
> foxxy:~/dev/equinox mraible$ ant war
> Buildfile: build.xml
> init:
> [artifact:dependencies] An error has occurred while processing the
> Maven artifact tasks.
> [artifact:dependencies] Diagnosis:
> [artifact:dependencies]
> [artifact:dependencies] Unable to build project:
> /Users/mraible/Work/equinox/pom.xml
> [artifact:dependencies] Duplicate project ID found in
> /Users/mraible/Work/equinox/pom.xml
> BUILD FAILED
> /Users/mraible/Work/equinox/build.xml:27: Unable to build project:
> /Users/mraible/Work/equinox/pom.xml
> Total time: 2 seconds
> foxxy:~/dev/equinox mraible$
> I haven't been able to find the "duplicate project id" the error is
> referring to. The strange thing is if I run "mvn package" on my
> project, everything works fine with Maven 2.0.1. If I revert my
> maven-artifact-ant-2.0.1-dep.jar to maven-artifact-ant-2.0-dep.jar,
> everything works as expected.
> Here's how I declare the Maven Ant tasks in my build.xml:
>
> uri="urn:maven-artifact-ant">
>
> location="${basedir}/lib/maven-artifact-ant-2.0-dep.jar" />
>
>
>
> Here's line 27 of build.xml:
> filesetId="compile.fileset" useScope="compile">
>
>
> Thanks,
> Matt
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1851) "Duplicate project ID found" message with maven-artifact-ant-2.0.1
[ http://jira.codehaus.org/browse/MNG-1851?page=comments#action_53902 ]
Tomislav Bodor commented on MNG-1851:
-
I have looked at the current 2.0.2 snapshot (and svn trunk) and there doesn't
seem to be any difference in behaviour (or code). Is this fix committed?
> "Duplicate project ID found" message with maven-artifact-ant-2.0.1
> --
>
> Key: MNG-1851
> URL: http://jira.codehaus.org/browse/MNG-1851
> Project: Maven 2
> Type: Bug
> Components: Ant tasks
> Versions: 2.0.1
> Reporter: John Casey
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0.2
>
>
> from the original email:
> I tried upgrading my Maven 2 Ant Tasks' JAR tonight, and after doing
> so, I'm getting the following error:
> foxxy:~/dev/equinox mraible$ ant war
> Buildfile: build.xml
> init:
> [artifact:dependencies] An error has occurred while processing the
> Maven artifact tasks.
> [artifact:dependencies] Diagnosis:
> [artifact:dependencies]
> [artifact:dependencies] Unable to build project:
> /Users/mraible/Work/equinox/pom.xml
> [artifact:dependencies] Duplicate project ID found in
> /Users/mraible/Work/equinox/pom.xml
> BUILD FAILED
> /Users/mraible/Work/equinox/build.xml:27: Unable to build project:
> /Users/mraible/Work/equinox/pom.xml
> Total time: 2 seconds
> foxxy:~/dev/equinox mraible$
> I haven't been able to find the "duplicate project id" the error is
> referring to. The strange thing is if I run "mvn package" on my
> project, everything works fine with Maven 2.0.1. If I revert my
> maven-artifact-ant-2.0.1-dep.jar to maven-artifact-ant-2.0-dep.jar,
> everything works as expected.
> Here's how I declare the Maven Ant tasks in my build.xml:
>
> uri="urn:maven-artifact-ant">
>
> location="${basedir}/lib/maven-artifact-ant-2.0-dep.jar" />
>
>
>
> Here's line 27 of build.xml:
> filesetId="compile.fileset" useScope="compile">
>
>
> Thanks,
> Matt
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1542) type attribute of artifact:dependencies doesn't work for indirect dependencies
[ http://jira.codehaus.org/browse/MNG-1542?page=comments#action_51730 ] Tomislav Bodor commented on MNG-1542: - Attached a small example demonstrating the problem. The example is a war project for which it's impossible to get jar dependencies (even from within the project itself, not just from the outside). All trails start with the project itself (of type war) and so they are all heterogenenous, so any type filter will fail and return an empty fileset. > type attribute of artifact:dependencies doesn't work for indirect dependencies > -- > > Key: MNG-1542 > URL: http://jira.codehaus.org/browse/MNG-1542 > Project: Maven 2 > Type: Sub-task > Components: maven-artifact-ant > Versions: 2.0 > Reporter: Tomislav Bodor > Assignee: Brett Porter > Attachments: build.xml, pom.xml > > > It appears that the type filter doesn't work properly with indirect > dependencies. It doesn't look like an issue with the TypeArtifactFilter > itself, but somewhere deeper. However, it's related to this feature, so here > it is... > The problem manifests with transitive dependencies that are of different > type, e.g. a war artefact depends on a jar library. Whatever the type in that > case (jar or war), the dependency list returned by artifact:dependencies is > empty. > I've traced through it and here is some more information: > DefaultArtifactCollector applies the filter using ResolutionNode.filterTrail. > This iterates over the (dependency) node trail and applies the specified > filter to each dependency in turn. If all dependencies are of the same type > and the type matches the one specified in the filter, no problems. However, > I've got a dependency that is a war archive and that in turn has some jar > dependencies. If type is set to jar, filter fails when testing the first > dependency in the trail - the war in this case and never gets to the jar. The > result is that whatever the value of the type attribute, the dependency list > always ends up empty for trails that contain dependencies of different types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1542) type attribute of artifact:dependencies doesn't work for indirect dependencies
[ http://jira.codehaus.org/browse/MNG-1542?page=all ] Tomislav Bodor updated MNG-1542: Attachment: pom.xml > type attribute of artifact:dependencies doesn't work for indirect dependencies > -- > > Key: MNG-1542 > URL: http://jira.codehaus.org/browse/MNG-1542 > Project: Maven 2 > Type: Sub-task > Components: maven-artifact-ant > Versions: 2.0 > Reporter: Tomislav Bodor > Assignee: Brett Porter > Attachments: build.xml, pom.xml > > > It appears that the type filter doesn't work properly with indirect > dependencies. It doesn't look like an issue with the TypeArtifactFilter > itself, but somewhere deeper. However, it's related to this feature, so here > it is... > The problem manifests with transitive dependencies that are of different > type, e.g. a war artefact depends on a jar library. Whatever the type in that > case (jar or war), the dependency list returned by artifact:dependencies is > empty. > I've traced through it and here is some more information: > DefaultArtifactCollector applies the filter using ResolutionNode.filterTrail. > This iterates over the (dependency) node trail and applies the specified > filter to each dependency in turn. If all dependencies are of the same type > and the type matches the one specified in the filter, no problems. However, > I've got a dependency that is a war archive and that in turn has some jar > dependencies. If type is set to jar, filter fails when testing the first > dependency in the trail - the war in this case and never gets to the jar. The > result is that whatever the value of the type attribute, the dependency list > always ends up empty for trails that contain dependencies of different types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1542) type attribute of artifact:dependencies doesn't work for indirect dependencies
[ http://jira.codehaus.org/browse/MNG-1542?page=all ] Tomislav Bodor updated MNG-1542: Attachment: build.xml > type attribute of artifact:dependencies doesn't work for indirect dependencies > -- > > Key: MNG-1542 > URL: http://jira.codehaus.org/browse/MNG-1542 > Project: Maven 2 > Type: Sub-task > Components: maven-artifact-ant > Versions: 2.0 > Reporter: Tomislav Bodor > Assignee: Brett Porter > Attachments: build.xml, pom.xml > > > It appears that the type filter doesn't work properly with indirect > dependencies. It doesn't look like an issue with the TypeArtifactFilter > itself, but somewhere deeper. However, it's related to this feature, so here > it is... > The problem manifests with transitive dependencies that are of different > type, e.g. a war artefact depends on a jar library. Whatever the type in that > case (jar or war), the dependency list returned by artifact:dependencies is > empty. > I've traced through it and here is some more information: > DefaultArtifactCollector applies the filter using ResolutionNode.filterTrail. > This iterates over the (dependency) node trail and applies the specified > filter to each dependency in turn. If all dependencies are of the same type > and the type matches the one specified in the filter, no problems. However, > I've got a dependency that is a war archive and that in turn has some jar > dependencies. If type is set to jar, filter fails when testing the first > dependency in the trail - the war in this case and never gets to the jar. The > result is that whatever the value of the type attribute, the dependency list > always ends up empty for trails that contain dependencies of different types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1542) type attribute of artifact:dependencies doesn't work for indirect dependencies
[ http://jira.codehaus.org/browse/MNG-1542?page=comments#action_51703 ] Tomislav Bodor commented on MNG-1542: - The problem manifests itself whenever you have a dependency trail in which not all dependencies are of the same type. However, I am struggling to find a non-war example since there are not that many types that are in use... But there is nothing in the code that specifically checks for wars, so the correct behaviour for wars is a coincidence. And it's only correct for fat wars (I'll come to that in a minute). I still think the prolem is real, though, so I'll try to explain a bit better what I was trying to do. WAR dependencies as such are indeed not transitive, except in one case: when you want to build a slim war (that *doesn't* include its dependencies) and then you want to include all dependencies at the ear level. Filtering dependencies by type would allow pulling in all dependencies of type war and insert corresponding entries in the application.xml. Similarly, all jar dependencies translate to entries. Also, not quite applicable at the moment as you cannot yet handle attached artefacts, but another example would be when you have an EJB client jar that has some dependencies (of type jar). As far as I understand, EJB client jars are of type 'ejb-client' in maven, not jar, so again you have a heterogeneous trail and none of those dependencies will be included. I would expect the type filter to work on the final transitive closure of all dependencies and give me a subset that are of the specified type. Instead, it operates on dependency trails and has a side effect: not only does it apply to the dependency at the end of a trail (the one currently being considered), but it also (as a side effect) eliminates dependencies with heterogeneous trails. This feels wrong. But perhaps not... What was the original intention of supporting the type filter? Thanks for looking at this. > type attribute of artifact:dependencies doesn't work for indirect dependencies > -- > > Key: MNG-1542 > URL: http://jira.codehaus.org/browse/MNG-1542 > Project: Maven 2 > Type: Sub-task > Components: maven-artifact-ant > Versions: 2.0 > Reporter: Tomislav Bodor > Assignee: Brett Porter > > > It appears that the type filter doesn't work properly with indirect > dependencies. It doesn't look like an issue with the TypeArtifactFilter > itself, but somewhere deeper. However, it's related to this feature, so here > it is... > The problem manifests with transitive dependencies that are of different > type, e.g. a war artefact depends on a jar library. Whatever the type in that > case (jar or war), the dependency list returned by artifact:dependencies is > empty. > I've traced through it and here is some more information: > DefaultArtifactCollector applies the filter using ResolutionNode.filterTrail. > This iterates over the (dependency) node trail and applies the specified > filter to each dependency in turn. If all dependencies are of the same type > and the type matches the one specified in the filter, no problems. However, > I've got a dependency that is a war archive and that in turn has some jar > dependencies. If type is set to jar, filter fails when testing the first > dependency in the trail - the war in this case and never gets to the jar. The > result is that whatever the value of the type attribute, the dependency list > always ends up empty for trails that contain dependencies of different types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1544) Attached artefacts not handled
[ http://jira.codehaus.org/browse/MNG-1544?page=comments#action_50810 ]
Tomislav Bodor commented on MNG-1544:
-
Alternatively, a nested fileset could be added to install and deploy tasks...
Then the attachments would not be handled the 'maven way', but more the 'ant
way'. Since maven plugins cannot be executed in this mode anyway, perhaps there
is no need to support the proper attachments.
> Attached artefacts not handled
> --
>
> Key: MNG-1544
> URL: http://jira.codehaus.org/browse/MNG-1544
> Project: Maven 2
> Type: Bug
> Components: maven-artifact-ant
> Versions: 2.0
> Reporter: Tomislav Bodor
>
>
> The install and deploy tasks don't seem to be able to handle attached
> artefacts. There appear to be two sides to the problem: first, there seems to
> be no way to attach anything, and second, even if it were attached, the
> install and deploy tasks don't do anything with attachments.
> The latter could be solved by adding to the install (and similar to the
> deploy) task something along the lines of (similar to the InstallMojo in the
> install plugin):
> List attachedArtifacts =
> pom.getMavenProject().getAttachedArtifacts();
> for (Iterator i = attachedArtifacts.iterator(); i.hasNext(); ) {
> Artifact attached = (Artifact) i.next();
> installer.install(attached.getFile(), attached, localRepo);
> }
> For the former (how to attach anything), a new task could be added (say,
> 'attach', taking a type, classifier and file).
> This functionality is needed to handle source archives and EJB client jars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1544) Attached artefacts not handled
Attached artefacts not handled
--
Key: MNG-1544
URL: http://jira.codehaus.org/browse/MNG-1544
Project: Maven 2
Type: Bug
Components: maven-artifact-ant
Versions: 2.0
Reporter: Tomislav Bodor
The install and deploy tasks don't seem to be able to handle attached
artefacts. There appear to be two sides to the problem: first, there seems to
be no way to attach anything, and second, even if it were attached, the install
and deploy tasks don't do anything with attachments.
The latter could be solved by adding to the install (and similar to the deploy)
task something along the lines of (similar to the InstallMojo in the install
plugin):
List attachedArtifacts =
pom.getMavenProject().getAttachedArtifacts();
for (Iterator i = attachedArtifacts.iterator(); i.hasNext(); ) {
Artifact attached = (Artifact) i.next();
installer.install(attached.getFile(), attached, localRepo);
}
For the former (how to attach anything), a new task could be added (say,
'attach', taking a type, classifier and file).
This functionality is needed to handle source archives and EJB client jars.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1542) type attribute of artifact:dependencies doesn't work for indirect dependencies
type attribute of artifact:dependencies doesn't work for indirect dependencies -- Key: MNG-1542 URL: http://jira.codehaus.org/browse/MNG-1542 Project: Maven 2 Type: Sub-task Components: maven-artifact-ant Versions: 2.0 Reporter: Tomislav Bodor It appears that the type filter doesn't work properly with indirect dependencies. It doesn't look like an issue with the TypeArtifactFilter itself, but somewhere deeper. However, it's related to this feature, so here it is... The problem manifests with transitive dependencies that are of different type, e.g. a war artefact depends on a jar library. Whatever the type in that case (jar or war), the dependency list returned by artifact:dependencies is empty. I've traced through it and here is some more information: DefaultArtifactCollector applies the filter using ResolutionNode.filterTrail. This iterates over the (dependency) node trail and applies the specified filter to each dependency in turn. If all dependencies are of the same type and the type matches the one specified in the filter, no problems. However, I've got a dependency that is a war archive and that in turn has some jar dependencies. If type is set to jar, filter fails when testing the first dependency in the trail - the war in this case and never gets to the jar. The result is that whatever the value of the type attribute, the dependency list always ends up empty for trails that contain dependencies of different types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
