[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version

[Tuomas Kiviaho (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606050#comment-17606050
 ] 

Tuomas Kiviaho commented on MRESOLVER-224:
--

Thanks for the clarification. 

My workaround was to switch from {{invoker:install}} to premature installing at 
{{pre-integration-test}} phase. If I recall correctly I stopped poking around 
when I saw that invoker did use shared metadata creation but had it's own 
rather crude implementation for it. Install plugin on the other hand didn't  
"corrupt" the local repo with such partial (this is the model 1.0.0 I presume) 
metadata and thus I was able to continue without too much of a fuzz.

I'd close the issue by knowing now that the limitation had left it's 
marks/scars to the codebase. 

PS. IMO {{invoker:install}} might be worth looking at with pair of eyes that 
know more about  the subtleties involved with metadata generation and resolving.

> DefaultVersionResolver is inflicting ArtifactNotFoundException for 
> classifiers with SNAPSHOT version
> 
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a 
> Maven Invoker Plugin project. The project that calls the invoker has the 
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus 
> downloading of the dependency artifact.When invoker is called the artifact is 
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of 
> the SNAPSHOT:jar artifact that is now being resolved with the 
> already downloaded SNAPSHOT key. Since the local version is newer than the 
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to 
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there 
> are no remote report left to try the DefaultArtifactResolver fails ultimately 
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact 
> .:jar::-SNAPSHOT from 
> []{code}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version

[Tuomas Kiviaho (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445842#comment-17445842
 ] 

Tuomas Kiviaho commented on MRESOLVER-224:
--

I found a reference to this oddity via blame. MNG-4955 states that this is a 
remnant from fixing the early days of metadata files (MNG-4452).  It's still 
unclear to me what this exactly fixed even though there is a clear explanation 
for it. 

I can't fathom why it wouldn't have without this fix. Maybe if the metadata for 
{{SNAPSHOT:jar}} was missing all-together then falling back to 
whatever repo with the latest {{SNAPSHOT}} key would function as a fallback, 
but that's not the described use case.



> DefaultVersionResolver is inflicting ArtifactNotFoundException for 
> classifiers with SNAPSHOT version
> 
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
>
> I use classifier artifact along with the artifact itself as a dependency in a 
> Maven Invoker Plugin project. The project that calls the invoker has the 
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus 
> downloading of the dependency artifact.When invoker is called the artifact is 
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of 
> the SNAPSHOT:jar artifact that is now being resolved with the 
> already downloaded SNAPSHOT key. Since the local version is newer than the 
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to 
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there 
> are no remote report left to try the DefaultArtifactResolver fails ultimately 
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact 
> .:jar::-SNAPSHOT from 
> []{code}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version

[Tuomas Kiviaho (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445771#comment-17445771
 ] 

Tuomas Kiviaho commented on MRESOLVER-224:
--

Here are the metadatas to give a clearer picture of the local repo state just 
prior to invoker:integration-test goal execution. It seems that invoker:install 
goal generates (partial???) {{maven-metadata-local.xml}} that I may have 
mistaken as the actual local repository while debugging since they both point 
to the same location in my settings. And for sure that one is missing 
references to pom and other artifacts.

But still it's the weird aftermath that 
{{DefaultVersionResolver::resolveVersion}} applies when the metadataresults 
have been already merged together successfully. It can't be just an 
optimization to see if the metadata of the local repo is newer than the remote 
since that's done already so have no idea what the code snippet in my first 
comment is all about. 

This logic is ultimately causing the failure and invoker is just a contributor 
to the cause.

As a work-a-round I need to start finding an alternative/patch for 
invoker:install for the time being, but it would be nice to get clarification 
on what is going on with the version resolver post processing the snapshot 
classifiers repo in such way.

{code:xml|title=maven-metadata-local.xml}

  mygroupid
  myartifactid
  x.y.z-SNAPSHOT
  

  true

2027135742
  

{code}

{code:xml|title=maven-metadata-repo.xml}


  mygroupid
  myartifactid
  x.y.z-SNAPSHOT
  

  2022.112753
  2

2022112753

  
jar
x.y.z-2022.112753-2
2022112753
  
  
pom
x.y.z-2022.112753-2
2022112753
  
  
myclassifier
jar
x.y.z-2022.112753-2
2022112753
  
  
sources
jar
x.y.z-2022.112753-2
2022112753
  

  

{code}


> DefaultVersionResolver is inflicting ArtifactNotFoundException for 
> classifiers with SNAPSHOT version
> 
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
>
> I use classifier artifact along with the artifact itself as a dependency in a 
> Maven Invoker Plugin project. The project that calls the invoker has the 
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus 
> downloading of the dependency artifact.When invoker is called the artifact is 
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of 
> the SNAPSHOT:jar artifact that is now being resolved with the 
> already downloaded SNAPSHOT key. Since the local version is newer than the 
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to 
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there 
> are no remote report left to try the DefaultArtifactResolver fails ultimately 
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact 
> .:jar::-SNAPSHOT from 
> []{code}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version

[Tuomas Kiviaho (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445639#comment-17445639
 ] 

Tuomas Kiviaho commented on MRESOLVER-224:
--

> Are you certain that this is done by Resolver and not Maven? Maven updates 
> metadata sometimes as well.

I'm not sure if I see the relevancy in this case the metadata is ok to begin 
with and Maven just hands over the task to repository system and it's done in 
one sweep. Technically parts of the resolver seem to be spread to the middle 
ground in form of the maven-resolver provider if this question is about where 
the issue should have been opened.

> DefaultVersionResolver is inflicting ArtifactNotFoundException for 
> classifiers with SNAPSHOT version
> 
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
>
> I use classifier artifact along with the artifact itself as a dependency in a 
> Maven Invoker Plugin project. The project that calls the invoker has the 
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus 
> downloading of the dependency artifact.When invoker is called the artifact is 
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of 
> the SNAPSHOT:jar artifact that is now being resolved with the 
> already downloaded SNAPSHOT key. Since the local version is newer than the 
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to 
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there 
> are no remote report left to try the DefaultArtifactResolver fails ultimately 
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact 
> .:jar::-SNAPSHOT from 
> []{code}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version

[Tuomas Kiviaho (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445308#comment-17445308
 ] 

Tuomas Kiviaho commented on MRESOLVER-224:
--

The problem is that even though metadata's {{}} is checked the 
existence of corresponding {{}} of 
{{SNAPSHOT:}} is not assured to exist in the repo that 
{{SNAPSHOT}} points to.

{code:java|title=DefaultVersionResolver}
String key = SNAPSHOT + getKey( artifact.getClassifier(), 
artifact.getExtension() );
merge( infos, SNAPSHOT, key );
if ( !resolve( result, infos, key ) )
{
result.setVersion( version );
}
{code}
 


> DefaultVersionResolver is inflicting ArtifactNotFoundException for 
> classifiers with SNAPSHOT version
> 
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
>
> I use classifier artifact along with the artifact itself as a dependency in a 
> Maven Invoker Plugin project. The project that calls the invoker has the 
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus 
> downloading of the dependency artifact.When invoker is called the artifact is 
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of 
> the SNAPSHOT:jar artifact that is now being resolved with the 
> already downloaded SNAPSHOT key. Since the local version is newer than the 
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to 
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there 
> are no remote report left to try the DefaultArtifactResolver fails ultimately 
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact 
> .:jar::-SNAPSHOT from 
> []{code}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (MRESOLVER-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version

[Tuomas Kiviaho (Jira)]

Tuomas Kiviaho created MRESOLVER-224:


 Summary: DefaultVersionResolver is inflicting 
ArtifactNotFoundException for classifiers with SNAPSHOT version
 Key: MRESOLVER-224
 URL: https://issues.apache.org/jira/browse/MRESOLVER-224
 Project: Maven Resolver
  Issue Type: Bug
  Components: Resolver
Affects Versions: 1.6.3
Reporter: Tuomas Kiviaho


I use classifier artifact along with the artifact itself as a dependency in a 
Maven Invoker Plugin project. The project that calls the invoker has the 
artifact itself as a dependency, but no reference to the classifier.

This causes resolving of the maven-metadata.xml for the project itself plus 
downloading of the dependency artifact.When invoker is called the artifact is 
already downloaded to the local repo and cached with SNAPSHOT key.

This causes the DefaultVersionResolver to merge the version information of the 
SNAPSHOT:jar artifact that is now being resolved with the already 
downloaded SNAPSHOT key. Since the local version is newer than the repo version 
the DefaultVersionResolver thinks SNAPSHOT:jar to be outdated 
thus overriding it with local repo.



Since the SNAPSHOT:jar doesn't exist in the local repo there are 
no remote report left to try the DefaultArtifactResolver fails ultimately to 
ArtifactNotFoundException since there was no download task.
{code:java}
[INFO] [DEBUG] Resolving artifact 
.:jar::-SNAPSHOT from 
[]{code}
 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (MINVOKER-289) Support for shared invoker's Update-Snapshots Flag

[Tuomas Kiviaho (Jira)]

Tuomas Kiviaho created MINVOKER-289:
---

 Summary: Support for shared invoker's Update-Snapshots Flag
 Key: MINVOKER-289
 URL: https://issues.apache.org/jira/browse/MINVOKER-289
 Project: Maven Invoker Plugin
  Issue Type: Wish
Affects Versions: 3.2.2
Reporter: Tuomas Kiviaho


The dependencies might contain such snapshots that are not up-to-date in local 
repo. My first invoker goal is \{{versions:resolve-ranges}} with 
\{{allowSnapshots}} enabled (depending on external properties) and my invoker 
project pom will be resolved with some SNAPSHOT previously unknown to the local 
repository.

There won't be any attempt to load these unless there is a way to set 
\{{setUpdateSnapshots}} request param to true.

Would it be possible to add this as configuration parameter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5384) Declarative artifacts

[Tuomas Kiviaho (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408684#comment-17408684
 ] 

Tuomas Kiviaho commented on MNG-5384:
-

bq. Maven 2 had this hack embedded inside of it, but with Maven 3 the project 
attachments list doesn't contain test-jar until it is actually added to the 
project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior 
packaging phase and remove it at prepare-package so that the actual attachment 
could be added to the project.

Maven 3.8.2 seems to have finally fixed [Adding serval times the same artifact 
via MavenProjectHelper (attachArtifact) keep adding to the List duplicate 
artifacts|https://issues.apache.org/jira/browse/MNG-5868] which was apparently 
raised due to the same problem that I mentioned above even though my use case 
would have been solved by having either the mentioned declarative artifacts or 
having capability to detach artifacts.

The fix for my use case clearly still a hack that is needed even without the 
detaching part since test-jar would be otherwise missing, but at least for now 
everything seems to be working.

[~olamy] The commit  
[5f048234ff44dbf70fcad9f17834c64866f452e1|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=5f048234ff44dbf70fcad9f17834c64866f452e1]
 made the list un-modifiable thus broke my MBUILDHELPER-41 patch in the process 
but the benefit of that is that the use case above can now be fixed without the 
Mojo patch since I do not have to worry about any duplicates being present at 
later phases.

Would the detaching of an attached artifact via a dedicated public method make 
any sense now that the direct modification of participating artifacts was made 
impossible? 

> Declarative artifacts
> -
>
> Key: MNG-5384
> URL: https://issues.apache.org/jira/browse/MNG-5384
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories, POM, Reactor and Workspace
>Affects Versions: 3.0.4
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> Currently there's no way to know which attachments a project is going to have 
> beforehand. Lack of this feature is currently patched inside Aether where 
> test-jar for instance has a special treatment prior packaging phase so that 
> we can get a file pointer to ${project.target.testOutputDirectory}. 
> Maven 2 had this hack embedded inside of it, but with Maven 3 the project 
> attachments list doesn't contain test-jar until it is actually added to the 
> project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior 
> packaging phase and remove it at prepare-package so that the actual 
> attachment could be added to the project.
> I propose that POM could have a section similar to {{build.finalName}} where 
> you'd list the attacments that the project is going to introduce. For 
> backwards compatibility this of course would not be required. Plugins such as 
> jar, sources and javadoc could kick in automatically when pom contains the 
> respective declarations (race conditions would arise between 
> maven-bundle-plugin and jar for instance).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7049) Version range resolution downloads all poms, not just the highest version

[Tuomas Kiviaho (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407344#comment-17407344
 ] 

Tuomas Kiviaho commented on MNG-7049:
-

{quote}I am so certain that I have seen a similiar request for this, but I 
can't remember whether it was with Maven Core or Maven Resolver. Will keep 
looking{quote}

[~michael-o] Here's a link to  
[MRESOLVER-133|https://issues.apache.org/jira/browse/MRESOLVER-133] that you 
probably were looking for. A CI worker without pre-populated local repository 
would indeed benefit from this. 

> Version range resolution downloads all poms, not just the highest version
> -
>
> Key: MNG-7049
> URL: https://issues.apache.org/jira/browse/MNG-7049
> Project: Maven
>  Issue Type: Improvement
>  Components: Core
>Reporter: Moti Nisenson-Ken
>Priority: Major
>
> When specifying a version range for a dependency, maven will download and try 
> to resolve all poms in that range which satisfy the range. The usage however 
> is only to use the highestVersion. This causes two issues:
>  # Performance - it's downloading numerous poms that aren't needed.
>  # Fragility - if the version range covers any "bad" poms, then the build 
> will fail. For example, consider that for a specific version, the parent of a 
> pom is not present in the repository. This is enough to fail any build with a 
> version range covering that specific version, as the range resolution stage 
> will not complete. This is particularly harmful when that version would not 
> be selected as the highest, anyway.
> Recommend to have a system property to control the desired behavior - it 
> should be possible to short-circuit loading all the versions and to just to 
> load the highest version.
> For another user report of this see: 
> [https://stackoverflow.com/questions/25047859/restrict-maven-to-not-download-all-poms]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MASSEMBLY-870) Regression: Repository downloads all dependencies remotely into _tmp folders

[Tuomas Kiviaho (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923097#comment-16923097
 ] 

Tuomas Kiviaho commented on MASSEMBLY-870:
--

And on top of that the artifacts that I had installed to local repo are not 
taken into account

> Regression: Repository downloads all dependencies remotely into _tmp folders
> 
>
> Key: MASSEMBLY-870
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-870
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Tuomas Kiviaho
>Priority: Major
>
> Repository {{_tmp}} folders under {{achive-tmp}} are filled with dependency 
> artifacts (.jar files and all) from pom which are not met by the filtering. I 
> noticed this when shifting from 2.6 to 3.1.0 and it is quite critical because 
> these dependencies do not come from local repo, but instead they are always 
> downloaded remotely. 
> I do have {{dependency:copy}} also before this plugin which doesn't do this 
> so I bet it has something to do with how the Aether is setup in 
> {{DefaultRepositoryAssembler}}. By removing the {{}} section 
> the assembly stopped this.
> The end result is now that everything that I've got in my pom is being filled 
> into {{runner/tmp/repo_tmp}}.
> {code}
>   
>   provided
>   false
>   
>   
> org.mortbay.jetty.alpn:alpn-boot
>   
>   runner/tmp/repo
>   
>   
> {code}
> Once the assembly is complete the _tmp folder gets deleted and the end result 
> contains just that one jar file.
> This is kind of a blocker, because I bet people have got used over the years 
> to cleaning the target folder so that they can get a nice assembly each time 
> a dependency is being upgraded despite the efforts of incremental builds. Due 
> to the cleaning there will always be repeated remote downloads because local 
> repository in settings is not utilized.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (MASSEMBLY-870) Regression: Repository downloads all dependencies remotely into _tmp folders

[Tuomas Kiviaho (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923089#comment-16923089
 ] 

Tuomas Kiviaho commented on MASSEMBLY-870:
--

I tried to upgrade from 2.6 to 3.1.1 and the problem still remains. Local 
repository is still not utilized and the build takes way too long.

> Regression: Repository downloads all dependencies remotely into _tmp folders
> 
>
> Key: MASSEMBLY-870
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-870
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Tuomas Kiviaho
>Priority: Major
>
> Repository {{_tmp}} folders under {{achive-tmp}} are filled with dependency 
> artifacts (.jar files and all) from pom which are not met by the filtering. I 
> noticed this when shifting from 2.6 to 3.1.0 and it is quite critical because 
> these dependencies do not come from local repo, but instead they are always 
> downloaded remotely. 
> I do have {{dependency:copy}} also before this plugin which doesn't do this 
> so I bet it has something to do with how the Aether is setup in 
> {{DefaultRepositoryAssembler}}. By removing the {{}} section 
> the assembly stopped this.
> The end result is now that everything that I've got in my pom is being filled 
> into {{runner/tmp/repo_tmp}}.
> {code}
>   
>   provided
>   false
>   
>   
> org.mortbay.jetty.alpn:alpn-boot
>   
>   runner/tmp/repo
>   
>   
> {code}
> Once the assembly is complete the _tmp folder gets deleted and the end result 
> contains just that one jar file.
> This is kind of a blocker, because I bet people have got used over the years 
> to cleaning the target folder so that they can get a nice assembly each time 
> a dependency is being upgraded despite the efforts of incremental builds. Due 
> to the cleaning there will always be repeated remote downloads because local 
> repository in settings is not utilized.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (MASSEMBLY-870) Regression: Repository downloads all dependencies remotely into _tmp folders

[Tuomas Kiviaho (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178108#comment-16178108
 ] 

Tuomas Kiviaho commented on MASSEMBLY-870:
--

This was quite educating discussion 
http://maven.40175.n5.nabble.com/API-to-resolve-a-version-range-artifact-td5889934.html
 because 
https://github.com/apache/maven-plugins/blob/55da60389e9e8326a022bf6b93484978fdb263ed/maven-assembly-plugin/src/main/java/org/apache/maven/plugins/assembly/repository/DefaultRepositoryAssembler.java
 uses the same approach.

[~rfscholte] I tested with my config that my invoker plugin still seems to be 
playing along nicely. I've been using the Fast Build Configuration 
https://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html 
and I think that kind of approach would solve this problem as well.

> Regression: Repository downloads all dependencies remotely into _tmp folders
> 
>
> Key: MASSEMBLY-870
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-870
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Tuomas Kiviaho
>
> Repository {{_tmp}} folders under {{achive-tmp}} are filled with dependency 
> artifacts (.jar files and all) from pom which are not met by the filtering. I 
> noticed this when shifting from 2.6 to 3.1.0 and it is quite critical because 
> these dependencies do not come from local repo, but instead they are always 
> downloaded remotely. 
> I do have {{dependency:copy}} also before this plugin which doesn't do this 
> so I bet it has something to do with how the Aether is setup in 
> {{DefaultRepositoryAssembler}}. By removing the {{}} section 
> the assembly stopped this.
> The end result is now that everything that I've got in my pom is being filled 
> into {{runner/tmp/repo_tmp}}.
> {code}
>   
>   provided
>   false
>   
>   
> org.mortbay.jetty.alpn:alpn-boot
>   
>   runner/tmp/repo
>   
>   
> {code}
> Once the assembly is complete the _tmp folder gets deleted and the end result 
> contains just that one jar file.
> This is kind of a blocker, because I bet people have got used over the years 
> to cleaning the target folder so that they can get a nice assembly each time 
> a dependency is being upgraded despite the efforts of incremental builds. Due 
> to the cleaning there will always be repeated remote downloads because local 
> repository in settings is not utilized.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MASSEMBLY-870) Regression: Repository downloads all dependencies remotely into _tmp folders

[Tuomas Kiviaho (JIRA)]

Tuomas Kiviaho created MASSEMBLY-870:


 Summary: Regression: Repository downloads all dependencies 
remotely into _tmp folders
 Key: MASSEMBLY-870
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-870
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Tuomas Kiviaho


Repository {{_tmp}} folders under {{achive-tmp}} are filled with dependency 
artifacts (.jar files and all) from pom which are not met by the filtering. I 
noticed this when shifting from 2.6 to 3.1.0 and it is quite critical because 
these dependencies do not come from local repo, but instead they are always 
downloaded remotely. 

I do have {{dependency:copy}} also before this plugin which doesn't do this so 
I bet it has something to do with how the Aether is setup in 
{{DefaultRepositoryAssembler}}. By removing the {{}} section the 
assembly stopped this.

The end result is now that everything that I've got in my pom is being filled 
into {{runner/tmp/repo_tmp}}.

{code}

provided
false


org.mortbay.jetty.alpn:alpn-boot

runner/tmp/repo


{code}

Once the assembly is complete the _tmp folder gets deleted and the end result 
contains just that one jar file.

This is kind of a blocker, because I bet people have got used over the years to 
cleaning the target folder so that they can get a nice assembly each time a 
dependency is being upgraded despite the efforts of incremental builds. Due to 
the cleaning there will always be repeated remote downloads because local 
repository in settings is not utilized.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] (MRELEASE-849) Release plugin replaces parent version with pom version when groupId/artifactId are identical

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=334090#comment-334090
 ] 

Tuomas Kiviaho commented on MRELEASE-849:
-

That was my biggest fear initially but I gave it a try since it is not 
ambiguous in same manner as are disparate version ranges on a dependency and 
surprisingly it worked. I was almost certain that this thing will bite me back 
after a while - apparently it did - but still there's a bit sisu left in me 
because the fix was basically a one liner. More natural solution would have be 
just merging between two branches but then I'd be missing all the fun.

 Release plugin replaces parent version with pom version when 
 groupId/artifactId are identical
 -

 Key: MRELEASE-849
 URL: https://jira.codehaus.org/browse/MRELEASE-849
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.4.1
Reporter: Tuomas Kiviaho
Priority: Blocker
 Attachments: AbstractRewritePomsPhase.patch


 POM rewriting for release phase doesn't handle well the following use case. 
 Parent version will be replaced which is not the intention here. 
 {code:xml|title=pom.xml}
 project
   modelVersion4.0.0/modelVersion
   parent
 groupIdfoo/groupId
 artifactIdbar/artifactId
 version1/version
   /parent
   groupIdfoo/groupId
   artifactIdbar/artifactId
   version2-SNAPSHOT/version
   packagingpom/packaging
 /project
 {code}
 I would assume this to be perfectly valid when introducing a new 
 non-backwards compatible feature to a parent pom. Probably I could replace 
 the inheritance with delegation by using 
 pluginManagement/dependencyManagement sections and import scope but I don't 
 think there's similar notation for profiles.

--
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

[jira] (MRELEASE-849) Release plugin replaces parent version with pom version when groupId/artifactId are identical

[Tuomas Kiviaho (JIRA)]

Tuomas Kiviaho created MRELEASE-849:
---

 Summary: Release plugin replaces parent version with pom version 
when groupId/artifactId are identical
 Key: MRELEASE-849
 URL: https://jira.codehaus.org/browse/MRELEASE-849
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.4.1
Reporter: Tuomas Kiviaho
Priority: Blocker


POM rewriting for release phase doesn't handle well the following use case. 
Parent version will be replaced which is not the intention here. 

{code:xml|title=pom.xml}
project
  modelVersion4.0.0/modelVersion
  parent
groupIdfoo/groupId
artifactIdbar/artifactId
version1/version
  /parent
  groupIdfoo/groupId
  artifactIdbar/artifactId
  version2-SNAPSHOT/version
  packagingpom/packaging
/project
{code}

I would assume this to be perfectly valid when introducing a new non-backwards 
compatible feature to a parent pom. Probably I could replace the inheritance 
with delegation by using pluginManagement/dependencyManagement sections and 
import scope but I don't think there's similar notation for profiles.

--
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

[jira] (MRELEASE-849) Release plugin replaces parent version with pom version when groupId/artifactId are identical

[Tuomas Kiviaho (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRELEASE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MRELEASE-849:


Attachment: AbstractRewritePomsPhase.patch

 Release plugin replaces parent version with pom version when 
 groupId/artifactId are identical
 -

 Key: MRELEASE-849
 URL: https://jira.codehaus.org/browse/MRELEASE-849
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.4.1
Reporter: Tuomas Kiviaho
Priority: Blocker
 Attachments: AbstractRewritePomsPhase.patch


 POM rewriting for release phase doesn't handle well the following use case. 
 Parent version will be replaced which is not the intention here. 
 {code:xml|title=pom.xml}
 project
   modelVersion4.0.0/modelVersion
   parent
 groupIdfoo/groupId
 artifactIdbar/artifactId
 version1/version
   /parent
   groupIdfoo/groupId
   artifactIdbar/artifactId
   version2-SNAPSHOT/version
   packagingpom/packaging
 /project
 {code}
 I would assume this to be perfectly valid when introducing a new 
 non-backwards compatible feature to a parent pom. Probably I could replace 
 the inheritance with delegation by using 
 pluginManagement/dependencyManagement sections and import scope but I don't 
 think there's similar notation for profiles.

--
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

[jira] (MRRESOURCES-68) Support bundling under different classifiers

[Tuomas Kiviaho (JIRA)]

Tuomas Kiviaho created MRRESOURCES-68:
-

 Summary: Support bundling under different classifiers
 Key: MRRESOURCES-68
 URL: https://jira.codehaus.org/browse/MRRESOURCES-68
 Project: Maven 2.x Remote Resources Plugin
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Tuomas Kiviaho


Currently it seems to possible to process classifier bundles (test jars for 
instance) as well, but bundling is only supported for main artifact. There is 
already an outputDirectory parameters but is has been marked as read-only. 

Would it possible remove the read-only flag from outputDirectory so that 
remote-resources bundling could be used for classified artifacts as well and 
not just for main artifact. 

--
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

[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322489#comment-322489
 ] 

Tuomas Kiviaho commented on MNG-3092:
-

@Scott Sosna - I'm using snapshot inclusion blocking approach which is already 
quite well covered by Sergey. For other purposes the less intruding pluggable 
[Dependency 
Selector|http://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution] 
approach as Jason suggested might be achievable even today by using javaagent 
and aspects. This would not require patching/forking nor tampering with current 
version range semantics.

@Sergei Ivanov/Kunalkumar Somani - For my purposes MNG-3328 would provide a way 
to combine the two separate settings.xml back to one using a system property or 
an environment variable (such as IS_M2RELEASEBUILD) so that proposed new CMD 
line options could be omitted.

PS. I don't mean any disrespect to anyone who has put effort - both in time 
and/or  patience - on to solving this matter. Comic served just as a reminder 
that every change breaks someones workflow.

 Version ranges with non-snapshot bounds can contain snapshot versions
 -

 Key: MNG-3092
 URL: https://jira.codehaus.org/browse/MNG-3092
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Reporter: Mark Hobson
Assignee: Jason van Zyl
 Fix For: 3.1.1

 Attachments: MNG-3092.patch


 Contrary to the 2.0 design docs:
 Resolution of dependency ranges should not resolve to a snapshot 
 (development version) unless it is included as an explicit boundary.
 -- from 
 http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
 The following is equates to true:
 VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new 
 DefaultArtifactVersion( 1.1-SNAPSHOT ) )
 The attached patch only allows snapshot versions to be contained in a range 
 if they are equal to one of the boundaries.  Note that this is a strict 
 equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

--
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

[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322489#comment-322489
 ] 

Tuomas Kiviaho edited comment on MNG-3092 at 3/23/13 4:36 AM:
--

@Scott Sosna - I'm using snapshot inclusion blocking approach which is already 
quite well covered by 
[Sergei|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=313516page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-313516].
 For other purposes the less intruding pluggable [Dependency 
Selector|http://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution] 
approach as Jason suggested might be achievable even today by using javaagent 
and aspects. This would not require patching/forking nor tampering with current 
version range semantics.

@Sergei Ivanov/Kunalkumar Somani - For my purposes MNG-3328 would provide a way 
to combine the two separate settings.xml back to one using a system property or 
an environment variable (such as IS_M2RELEASEBUILD) so that proposed new CMD 
line options could be omitted.

PS. I don't mean any disrespect to anyone who has put effort - both in time 
and/or  patience - on to solving this matter. Comic served just as a reminder 
that every change breaks someones workflow.

  was (Author: tuomas_kiviaho):
@Scott Sosna - I'm using snapshot inclusion blocking approach which is 
already quite well covered by Sergey. For other purposes the less intruding 
pluggable [Dependency 
Selector|http://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution] 
approach as Jason suggested might be achievable even today by using javaagent 
and aspects. This would not require patching/forking nor tampering with current 
version range semantics.

@Sergei Ivanov/Kunalkumar Somani - For my purposes MNG-3328 would provide a way 
to combine the two separate settings.xml back to one using a system property or 
an environment variable (such as IS_M2RELEASEBUILD) so that proposed new CMD 
line options could be omitted.

PS. I don't mean any disrespect to anyone who has put effort - both in time 
and/or  patience - on to solving this matter. Comic served just as a reminder 
that every change breaks someones workflow.
  
 Version ranges with non-snapshot bounds can contain snapshot versions
 -

 Key: MNG-3092
 URL: https://jira.codehaus.org/browse/MNG-3092
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Reporter: Mark Hobson
Assignee: Jason van Zyl
 Fix For: 3.1.1

 Attachments: MNG-3092.patch


 Contrary to the 2.0 design docs:
 Resolution of dependency ranges should not resolve to a snapshot 
 (development version) unless it is included as an explicit boundary.
 -- from 
 http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
 The following is equates to true:
 VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new 
 DefaultArtifactVersion( 1.1-SNAPSHOT ) )
 The attached patch only allows snapshot versions to be contained in a range 
 if they are equal to one of the boundaries.  Note that this is a strict 
 equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

--
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

[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322410#comment-322410
 ] 

Tuomas Kiviaho commented on MNG-3092:
-

@Kunalkumar What you suggested would break my [workflow|http://xkcd.com/1172/] 
which is to use separate settings.xml while releasing (no snapshot repos and 
separate local repo). This way release plugin never sees snapshots and ranges 
can be left untouched. It even encourages to release more often in order to see 
if something is broken. An identical CI instance that only sees the releases, 
installs to /dev/null and doesn't deploy anything would make this approach even 
more robust.

Release plugin would (or at least should) stop working for us with your 
suggestion because of SNAPSHOT ranges. SNAPSHOT range removal before releasing 
and resetting after releasing would be tedious and error prone even when using 
versions plugin.

 Version ranges with non-snapshot bounds can contain snapshot versions
 -

 Key: MNG-3092
 URL: https://jira.codehaus.org/browse/MNG-3092
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Reporter: Mark Hobson
Assignee: Jason van Zyl
 Fix For: 3.1.1

 Attachments: MNG-3092.patch


 Contrary to the 2.0 design docs:
 Resolution of dependency ranges should not resolve to a snapshot 
 (development version) unless it is included as an explicit boundary.
 -- from 
 http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
 The following is equates to true:
 VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new 
 DefaultArtifactVersion( 1.1-SNAPSHOT ) )
 The attached patch only allows snapshot versions to be contained in a range 
 if they are equal to one of the boundaries.  Note that this is a strict 
 equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

--
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

[jira] (MNG-5384) Declarative artifacts

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322128#comment-322128
 ] 

Tuomas Kiviaho edited comment on MNG-5384 at 3/19/13 6:16 AM:
--

This is how I'm currently circumventing the problem (MBUILDHELPER-41)

  was (Author: tuomas_kiviaho):
This is how I'm currently circumventing the problem
  
 Declarative artifacts
 -

 Key: MNG-5384
 URL: https://jira.codehaus.org/browse/MNG-5384
 Project: Maven 2  3
  Issue Type: New Feature
  Components: Artifacts and Repositories, POM, Reactor and workspace
Affects Versions: 3.0.4
Reporter: Tuomas Kiviaho

 Currently there's no way to know what attachments a project is going to have 
 beforehand. Lack of this feature is currently patched inside Aether where 
 test-jar for instance has a special treatment prior packaging phase so that 
 we can get a file pointer to ${project.target.testOutputDirectory}. 
 Maven 2 had this hack embedded inside of it, but with Maven 3 the project 
 attachments list doesn't contain test-jar until it is actually added to the 
 project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior 
 packaging phase and remove it at prepare-package so that the actual 
 attachment could be added to the project.
 I propose that POM could have a section similar to {{build.finalName}} where 
 you'd list the attacments that the project is going to introduce. For 
 backwards compatibility this of course would not be required. Plugins such as 
 jar, sources and javadoc could kick in automatically when pom contains the 
 respective declarations (race conditions would arise between 
 maven-bundle-plugin and jar for instance).

--
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

[jira] (MNG-5384) Declarative artifacts

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317148#comment-317148
 ] 

Tuomas Kiviaho commented on MNG-5384:
-

M2E workspace resolution would benefit from this by being able to pinpoint 
directly to {{testOutputDirectory}} when an artifact from 
MavenProject.getArtifacts is of type test-jar. Currently it points to the 
{{outputDirectory}} because Aether only fixes the location of test-jar artifact 
retrievable from MavenProject.getAttacheArtifacts.

 Declarative artifacts
 -

 Key: MNG-5384
 URL: https://jira.codehaus.org/browse/MNG-5384
 Project: Maven 2  3
  Issue Type: New Feature
  Components: Artifacts and Repositories, POM, Reactor and workspace
Affects Versions: 3.0.4
Reporter: Tuomas Kiviaho

 Currently there's no way to know what attachments a project is going to have 
 beforehand. Lack of this feature is currently patched inside Aether where 
 test-jar for instance has a special treatment prior packaging phase so that 
 we can get a file pointer to ${project.target.testOutputDirectory}. 
 Maven 2 had this hack embedded inside of it, but with Maven 3 the project 
 attachments list doesn't contain test-jar until it is actually added to the 
 project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior 
 packaging phase and remove it at prepare-package so that the actual 
 attachment could be added to the project.
 I propose that POM could have a section similar to {{build.finalName}} where 
 you'd list the attacments that the project is going to introduce. For 
 backwards compatibility this of course would not be required. Plugins such as 
 jar, sources and javadoc could kick in automatically when pom contains the 
 respective declarations (race conditions would arise between 
 maven-bundle-plugin and jar for instance).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5384) Declarative artifacts

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317148#comment-317148
 ] 

Tuomas Kiviaho edited comment on MNG-5384 at 1/11/13 5:04 AM:
--

M2E workspace resolution would benefit from this by being able to pinpoint 
directly to {{testOutputDirectory}} when an artifact from 
MavenProject.getArtifacts is of type test-jar. Currently it points to the 
{{outputDirectory}} because Aether only fixes the location of test-jar artifact 
retrievable from MavenProject.getAttacheArtifacts.

Since Maven 2.x the behavior of attached test-jar artifact has somewhat 
changed. It used to be so that project's test-jar attachment was already in 
place before actual artifact was attached. With Maven 3 this feature was 
removed (thus some the magic seems to have been shifted to Aether). It would be 
beneficial if the artifact file location would be dynamic, since static 
approach doesn't have such advantages as with as it does with {{properties}} 
section of the POM.

  was (Author: tuomas_kiviaho):
M2E workspace resolution would benefit from this by being able to pinpoint 
directly to {{testOutputDirectory}} when an artifact from 
MavenProject.getArtifacts is of type test-jar. Currently it points to the 
{{outputDirectory}} because Aether only fixes the location of test-jar artifact 
retrievable from MavenProject.getAttacheArtifacts.
  
 Declarative artifacts
 -

 Key: MNG-5384
 URL: https://jira.codehaus.org/browse/MNG-5384
 Project: Maven 2  3
  Issue Type: New Feature
  Components: Artifacts and Repositories, POM, Reactor and workspace
Affects Versions: 3.0.4
Reporter: Tuomas Kiviaho

 Currently there's no way to know what attachments a project is going to have 
 beforehand. Lack of this feature is currently patched inside Aether where 
 test-jar for instance has a special treatment prior packaging phase so that 
 we can get a file pointer to ${project.target.testOutputDirectory}. 
 Maven 2 had this hack embedded inside of it, but with Maven 3 the project 
 attachments list doesn't contain test-jar until it is actually added to the 
 project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior 
 packaging phase and remove it at prepare-package so that the actual 
 attachment could be added to the project.
 I propose that POM could have a section similar to {{build.finalName}} where 
 you'd list the attacments that the project is going to introduce. For 
 backwards compatibility this of course would not be required. Plugins such as 
 jar, sources and javadoc could kick in automatically when pom contains the 
 respective declarations (race conditions would arise between 
 maven-bundle-plugin and jar for instance).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5384) Declarative artifacts

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317148#comment-317148
 ] 

Tuomas Kiviaho edited comment on MNG-5384 at 1/11/13 5:17 AM:
--

M2E workspace resolution would benefit from this by being able to pinpoint 
directly to {{testOutputDirectory}} when an artifact from 
MavenProject.getArtifacts is of type test-jar. Currently it points to the 
{{outputDirectory}} because Aether only fixes the location of test-jar artifact 
retrievable from MavenProject.getAttacheArtifacts.

Since Maven 2.x the behavior of attached test-jar artifact has somewhat 
changed. It used to be so that project's test-jar attachment was already in 
place before actual artifact was attached. With Maven 3 this feature was 
removed (thus some the magic seems to have been shifted to Aether). It would be 
beneficial if the artifact file location would be dynamic, since static 
approach doesn't have such advantages as with as it does with {{properties}} 
section of the POM. I think that the plugins responsible of produced artifacts 
should state the file location of the artifact in declarative manner (perhaps 
an {{artifacts}} tag inside {{execution}} tag). 

  was (Author: tuomas_kiviaho):
M2E workspace resolution would benefit from this by being able to pinpoint 
directly to {{testOutputDirectory}} when an artifact from 
MavenProject.getArtifacts is of type test-jar. Currently it points to the 
{{outputDirectory}} because Aether only fixes the location of test-jar artifact 
retrievable from MavenProject.getAttacheArtifacts.

Since Maven 2.x the behavior of attached test-jar artifact has somewhat 
changed. It used to be so that project's test-jar attachment was already in 
place before actual artifact was attached. With Maven 3 this feature was 
removed (thus some the magic seems to have been shifted to Aether). It would be 
beneficial if the artifact file location would be dynamic, since static 
approach doesn't have such advantages as with as it does with {{properties}} 
section of the POM.
  
 Declarative artifacts
 -

 Key: MNG-5384
 URL: https://jira.codehaus.org/browse/MNG-5384
 Project: Maven 2  3
  Issue Type: New Feature
  Components: Artifacts and Repositories, POM, Reactor and workspace
Affects Versions: 3.0.4
Reporter: Tuomas Kiviaho

 Currently there's no way to know what attachments a project is going to have 
 beforehand. Lack of this feature is currently patched inside Aether where 
 test-jar for instance has a special treatment prior packaging phase so that 
 we can get a file pointer to ${project.target.testOutputDirectory}. 
 Maven 2 had this hack embedded inside of it, but with Maven 3 the project 
 attachments list doesn't contain test-jar until it is actually added to the 
 project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior 
 packaging phase and remove it at prepare-package so that the actual 
 attachment could be added to the project.
 I propose that POM could have a section similar to {{build.finalName}} where 
 you'd list the attacments that the project is going to introduce. For 
 backwards compatibility this of course would not be required. Plugins such as 
 jar, sources and javadoc could kick in automatically when pom contains the 
 respective declarations (race conditions would arise between 
 maven-bundle-plugin and jar for instance).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-811) remote-testing

[Tuomas Kiviaho (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated SUREFIRE-811:


Attachment: ConsoleOutputCapture.patch

I've been using the remoting approach by weawing an aspect ontop of 
ForkedBooter for a while now and the only thing that seems to be causing 
headache is capturing of the console output that is applied by surefire 
provider to both System out and err.

Currently there is no logic preventing it from functioning in such threads that 
have not been inherited from the thread that turned on the capturing. This 
would not be a problem in normal style forking where every thread originated 
from ForkedBooter and System out is isolated by the process.

In my case the ForkClient runs in same process and therefore uses the same 
System.out/err which are currently captured by surefire provider. Luckily this 
doesn't cause stack overflow, because ForkingRunListener - where the output 
ultimately ends up just - just encodes the output prior printing it out to the 
actual console.

Here's a simple patch that fixed this issue for me.

 remote-testing
 --

 Key: SUREFIRE-811
 URL: https://jira.codehaus.org/browse/SUREFIRE-811
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Maven Failsafe Plugin
Reporter: Henning Gross
 Attachments: ConsoleOutputCapture.patch


 Add the possibility to copy the target folder to remote machine and run 
 integration-tests there. Copy back the results and handle them as if they 
 would have been ran locally.
 I would volounteer to submit a patch for this feature if theres a chance it 
 would be accepted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5384) Declarative artifacts

[Tuomas Kiviaho (JIRA)]

Tuomas Kiviaho created MNG-5384:
---

 Summary: Declarative artifacts
 Key: MNG-5384
 URL: https://jira.codehaus.org/browse/MNG-5384
 Project: Maven 2  3
  Issue Type: New Feature
  Components: Artifacts and Repositories, POM, Reactor and workspace
Affects Versions: 3.0.4
Reporter: Tuomas Kiviaho


Currently there's no way to know what attachments a project is going to have 
beforehand. Lack of this feature is currently patched inside Aether where 
test-jar for instance has a special treatment prior packaging phase so that we 
can get a file pointer to ${project.target.testOutputDirectory}. 

Maven 2 had this hack embedded inside of it, but with Maven 3 the project 
attachments list doesn't contain test-jar until it is actually added to the 
project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior 
packaging phase and remove it at prepare-package so that the actual attachment 
could be added to the project.

I propose that POM could have a section similar to {{build.finalName}} where 
you'd list the attacments that the project is going to introduce. For backwards 
compatibility this of course would not be required. Plugins such as jar, 
sources and javadoc could kick in automatically when pom contains the 
respective declarations (race conditions would arise between 
maven-bundle-plugin and jar for instance).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-272) purge-local-repository does nothing if certain dependencies are included

[Tuomas Kiviaho (JIRA)]

 [ 
https://jira.codehaus.org/browse/MDEP-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MDEP-272:


Attachment: PurgeLocalRepositoryMojo.patch

Here's an updated version of the patch that avoids NPE caused by artifact files 
which aren't present in local repo.

 purge-local-repository does nothing if certain dependencies are included
 

 Key: MDEP-272
 URL: https://jira.codehaus.org/browse/MDEP-272
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: purge-local-repository
Affects Versions: 2.0
Reporter: Michele Lorenzini
Assignee: Brian Fox
 Attachments: pom.xml, PurgeLocalRepositoryMojo.patch, 
 PurgeLocalRepositoryMojo.patch


 I've noticed that the {{purge-local-repository}} goal does nothing if certain 
 dependencies are present in the dependency tree of the project.
 After some attempts I've found some of the dependencies that can show problem.
 See attached {{pom.xml}}: if I run {{mvn validate}} as is, maven purges the 
 local repository and the log4j jar is downloaded from the remote repository.
 Removing the comment around the jasperreports dependency and re-running {{mvn 
 validate}} gives the following result:
 {code}
 [INFO] [dependency:purge-local-repository {execution: default}]
 [INFO] Nothing to do for project: test-issue:test-issue:pom:1.0.0.0-SNAPSHOT
 {code}
 So it seems that something goes wrong while resolving the dependencies for 
 the project if the jasperreports jar is included, resulting in the 
 {{purge-local-repository}} to skip the clean of the local repository.
 I dont know if this happens only with jasperreports dependency or if it is 
 something more general.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-272) purge-local-repository does nothing if certain dependencies are included

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/MDEP-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=310743#comment-310743
 ] 

Tuomas Kiviaho commented on MDEP-272:
-

I think that this patch also takes care of MDEP-256 and MDEP-290

 purge-local-repository does nothing if certain dependencies are included
 

 Key: MDEP-272
 URL: https://jira.codehaus.org/browse/MDEP-272
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: purge-local-repository
Affects Versions: 2.0
Reporter: Michele Lorenzini
Assignee: Brian Fox
 Attachments: pom.xml, PurgeLocalRepositoryMojo.patch, 
 PurgeLocalRepositoryMojo.patch


 I've noticed that the {{purge-local-repository}} goal does nothing if certain 
 dependencies are present in the dependency tree of the project.
 After some attempts I've found some of the dependencies that can show problem.
 See attached {{pom.xml}}: if I run {{mvn validate}} as is, maven purges the 
 local repository and the log4j jar is downloaded from the remote repository.
 Removing the comment around the jasperreports dependency and re-running {{mvn 
 validate}} gives the following result:
 {code}
 [INFO] [dependency:purge-local-repository {execution: default}]
 [INFO] Nothing to do for project: test-issue:test-issue:pom:1.0.0.0-SNAPSHOT
 {code}
 So it seems that something goes wrong while resolving the dependencies for 
 the project if the jasperreports jar is included, resulting in the 
 {{purge-local-repository}} to skip the clean of the local repository.
 I dont know if this happens only with jasperreports dependency or if it is 
 something more general.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-272) purge-local-repository does nothing if certain dependencies are included

[Tuomas Kiviaho (JIRA)]

 [ 
https://jira.codehaus.org/browse/MDEP-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MDEP-272:


Attachment: PurgeLocalRepositoryMojo.patch

For me it failed with dependencies that had unresolvable parents or which used 
version ranges. Here's a fix that I'm using to get past this problem.

 purge-local-repository does nothing if certain dependencies are included
 

 Key: MDEP-272
 URL: https://jira.codehaus.org/browse/MDEP-272
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: purge-local-repository
Affects Versions: 2.0
Reporter: Michele Lorenzini
Assignee: Brian Fox
 Attachments: pom.xml, PurgeLocalRepositoryMojo.patch


 I've noticed that the {{purge-local-repository}} goal does nothing if certain 
 dependencies are present in the dependency tree of the project.
 After some attempts I've found some of the dependencies that can show problem.
 See attached {{pom.xml}}: if I run {{mvn validate}} as is, maven purges the 
 local repository and the log4j jar is downloaded from the remote repository.
 Removing the comment around the jasperreports dependency and re-running {{mvn 
 validate}} gives the following result:
 {code}
 [INFO] [dependency:purge-local-repository {execution: default}]
 [INFO] Nothing to do for project: test-issue:test-issue:pom:1.0.0.0-SNAPSHOT
 {code}
 So it seems that something goes wrong while resolving the dependencies for 
 the project if the jasperreports jar is included, resulting in the 
 {{purge-local-repository}} to skip the clean of the local repository.
 I dont know if this happens only with jasperreports dependency or if it is 
 something more general.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSHARED-235) Invalid artifact type with maven 3

[Tuomas Kiviaho (JIRA)]

Tuomas Kiviaho created MSHARED-235:
--

 Summary: Invalid artifact type with maven 3
 Key: MSHARED-235
 URL: https://jira.codehaus.org/browse/MSHARED-235
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-dependency-tree
Affects Versions: maven-dependency-tree-2.0
Reporter: Tuomas Kiviaho
Priority: Blocker
 Attachments: Maven3DependencyGraphBuilder.patch

Maven3DependencyGraphBuilder seems to anticipate that type is always the same 
as Aether artifact extension. This is not true for instance with 
maven-bundle-plugin that uses 'jar' as extension but type as 'bundle'. Included 
a small one-liner patch that fixes the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-811) remote-testing

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=297755#comment-297755
 ] 

Tuomas Kiviaho commented on SUREFIRE-811:
-

I've got quite similar requirements and for me it was sufficient to replace 
ForkedBooter with one that uses stub/skeleton pattern. Luckily I could use the 
local filesystem so it was only matter of using aspectj's weaver as java agent 
to avoid recompilation of surefire. I guess that this approach would have been 
sufficient because - if I understood the code correctly - there is an internal 
communication protocol that surefire uses to pass along test results and 
logging information.

I guess it would be enough if ForkedBooter could be re-configured with a plugin 
dependency so that knowledge of runtime weaving would not be required.

 remote-testing
 --

 Key: SUREFIRE-811
 URL: https://jira.codehaus.org/browse/SUREFIRE-811
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Maven Failsafe Plugin
Reporter: Henning Gross

 Add the possibility to copy the target folder to remote machine and run 
 integration-tests there. Copy back the results and handle them as if they 
 would have been ran locally.
 I would volounteer to submit a patch for this feature if theres a chance it 
 would be accepted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (ARCHETYPE-318) requiredProperty defaultValue not correctly filtered

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/ARCHETYPE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=276627#comment-276627
 ] 

Tuomas Kiviaho commented on ARCHETYPE-318:
--

This patch unifies interactive and batch mode behavior.
filtering is done only in part of the code that get's executed when interactive 
mode is used. Batch mode has completely separate handling. I merged these two 
execution paths together so that the only real difference is that required user 
input in interactive mode is replaced with default values in batch mode

Replacement of required properties now fails if transitive properties are not 
resolved.
code seems to call as property values containing references to other properties 
(like ${artifactId}.itest1) as 'transitive properties'. If property references 
can't be resolved the build fails.

There (is) also an oddity...
Codebase seems to treat groupId, artifactId, version (and package) a bit 
differently than other properties. Properties with same name can't be 
configured for instance as optional because what you'd only be generating 
duplicate properties with same name. This is just something that caught my eye.

There wasn't existing test cases to begin with so I only could test with my own 
code and while trying to keep the number of changed lines in minimum.


 requiredProperty defaultValue not correctly filtered
 

 Key: ARCHETYPE-318
 URL: https://jira.codehaus.org/browse/ARCHETYPE-318
 Project: Maven Archetype
  Issue Type: Bug
  Components: Generator
Affects Versions: 2.0-alpha-5
Reporter: Jochen Ehret
Priority: Minor
 Fix For: 2.x

 Attachments: DefaultArchetypeGenerationConfigurator.patch


 In our archetype-metadata.xml we´ve defined a requiredProperty with a 
 default value like this:
 {code:xml}requiredProperty key=subArtifactId
 defaultValue${artifactId}.itest1/defaultValue
 /requiredProperty{code}
 When we call archetype:generate and enter the parameters in interactive 
 mode everything works fine. But when we try to set the parameter 
 subArtifactId on the command line (mvn archetype:generate 
 -DsubArtifactId=xyz) or from an archetype.properties file, the value is 
 ignored. In the generated pom.xml the variable ${subArtifactId} is always 
 replaced with ${artifactId}.itest1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (ARCHETYPE-318) requiredProperty defaultValue not correctly filtered

[Tuomas Kiviaho (JIRA)]

[ 
https://jira.codehaus.org/browse/ARCHETYPE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=276630#comment-276630
 ] 

Tuomas Kiviaho commented on ARCHETYPE-318:
--

I see that there is a property-setting-cli that could be converted to batch 
mode test quite easily. The required property in the declaration is a good 
permutation to begin with and both cli and batch mode should contain also more 
deeply nested property referencing scenarios. (a=${b},b=${c},c=foobar). 

 requiredProperty defaultValue not correctly filtered
 

 Key: ARCHETYPE-318
 URL: https://jira.codehaus.org/browse/ARCHETYPE-318
 Project: Maven Archetype
  Issue Type: Bug
  Components: Generator
Affects Versions: 2.0-alpha-5
Reporter: Jochen Ehret
Priority: Minor
 Fix For: 2.x

 Attachments: DefaultArchetypeGenerationConfigurator.patch


 In our archetype-metadata.xml we´ve defined a requiredProperty with a 
 default value like this:
 {code:xml}requiredProperty key=subArtifactId
 defaultValue${artifactId}.itest1/defaultValue
 /requiredProperty{code}
 When we call archetype:generate and enter the parameters in interactive 
 mode everything works fine. But when we try to set the parameter 
 subArtifactId on the command line (mvn archetype:generate 
 -DsubArtifactId=xyz) or from an archetype.properties file, the value is 
 ignored. In the generated pom.xml the variable ${subArtifactId} is always 
 replaced with ${artifactId}.itest1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (ARCHETYPE-318) requiredProperty defaultValue not correctly filtered

[Tuomas Kiviaho (JIRA)]

 [ 
http://jira.codehaus.org/browse/ARCHETYPE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated ARCHETYPE-318:
-

Attachment: DefaultArchetypeGenerationConfigurator.patch

This patch unifies interactive and batch mode behavior. Replacement of required 
properties now fails if transitive properties are not resolved. I noticed in 
the code that in order for ${foobar} to be replaced with foobars actual value, 
foobar must be a required property, but that another story. There also an 
oddity with groupId, artifactId, version (and package). They are forced as 
required properties in the new configuration as well so declaring of artifactId 
for instance without requiring will only lead to two properties with the same 
name of which one is optional and the (forced) one is still required.

 requiredProperty defaultValue not correctly filtered
 

 Key: ARCHETYPE-318
 URL: http://jira.codehaus.org/browse/ARCHETYPE-318
 Project: Maven Archetype
  Issue Type: Bug
  Components: Generator
Affects Versions: 2.0-alpha-5
Reporter: Jochen Ehret
Priority: Minor
 Attachments: DefaultArchetypeGenerationConfigurator.patch


 In our archetype-metadata.xml we´ve defined a requiredProperty with a 
 default value like this:
 {code:xml}requiredProperty key=subArtifactId
 defaultValue${artifactId}.itest1/defaultValue
 /requiredProperty{code}
 When we call archetype:generate and enter the parameters in interactive 
 mode everything works fine. But when we try to set the parameter 
 subArtifactId on the command line (mvn archetype:generate 
 -DsubArtifactId=xyz) or from an archetype.properties file, the value is 
 ignored. In the generated pom.xml the variable ${subArtifactId} is always 
 replaced with ${artifactId}.itest1.

-- 
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

[jira] Created: (ARCHETYPE-364) DefaultPomManager.mergePoms ignores original file separator and indent

[Tuomas Kiviaho (JIRA)]

DefaultPomManager.mergePoms ignores original file separator and indent
--

 Key: ARCHETYPE-364
 URL: http://jira.codehaus.org/browse/ARCHETYPE-364
 Project: Maven Archetype
  Issue Type: Bug
  Components: Generator
Affects Versions: 2.0
Reporter: Tuomas Kiviaho
Priority: Minor


I have \r file separator in pom.xml template but generated template has \r\n 
that apparently comes from org.apache.maven.archetype.common.util.Format as 
default. Similar things happens to indentation.

-- 
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

[jira] Commented: (MDEP-266) Add parameter to configure copy-dependencies to also copy optional dependencies

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MDEP-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=252782#action_252782
 ] 

Tuomas Kiviaho commented on MDEP-266:
-

I draw hasty conclusions about this issue. Optional dependencies declared in 
project are included as per my personal tests but optional dependencies of 
project's transitive dependencies are not (unless they are re-declared in the 
project), if I'm correct this time around. This would be the standard procedure 
and I doubt that it would be trivial to include optional dependencies behind 
transitive dependencies since they are not available for the plugin when it 
starts the filtering

PS. I noticed that there's currently no way to exclude optional dependencies 
(and their transitive dependencies) of the project.
PPS. My problem with classpath seems to be reported already at MDEP-107

 Add parameter to configure copy-dependencies to also copy optional 
 dependencies
 ---

 Key: MDEP-266
 URL: http://jira.codehaus.org/browse/MDEP-266
 Project: Maven 2.x Dependency Plugin
  Issue Type: New Feature
  Components: copy-dependencies
Affects Versions: 2.1
Reporter: Andreas Sewe
Assignee: Brian Fox
Priority: Minor

 At the moment, copy-dependencies only copies non-optional dependencies. 
 However, one sometimes wants to copy *all* dependencies -- even the optional 
 ones.

-- 
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

[jira] Commented: (MDEP-107) Output the dependencies in a consistent and natural order

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MDEP-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=252784#action_252784
 ] 

Tuomas Kiviaho commented on MDEP-107:
-

To make things even worse this isn't just a human readability issue but 
actually a bug since build-classpath uses the same codebase and produces 
invalid output for big (over 32) dependency sets when hash algorithm that you 
anticipated kicks in and bollocks up the order.

 Output the dependencies in a consistent and natural order
 -

 Key: MDEP-107
 URL: http://jira.codehaus.org/browse/MDEP-107
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: tree
Affects Versions: 2.0
Reporter: William Ferguson
Assignee: Brian Fox

 As of 2.0-alpha-5-SNAPSHOT 31-AUG-2007 the dependencies when output are in 
 random order as I suspect they come straight form a Set.
 This makes it really difficult for a human to parse the dependencies.
 Ordering them using the natural artifact order before output would be a great 
 improvement.
 In particular dependency:tree is very hard to read when they are not ordered.
 But if each level were ordered using the natural artifact ordering it would 
 be much easier to read and to work out where the dep problems lay.
 [INFO] [dependency:tree]
 [INFO] com.yarris.consol:consol-web:war:1.0-SNAPSHOT
 [INFO]com.yarris:cielo:jar:1.5:compile
 [INFO]javax.j2ee:j2ee:jar:1.3.1:compile
 [INFO]commons-digester:commons-digester:jar:1.7:compile
 [INFO]opensymphony:sitemesh:jar:2.2.1:compile
 [INFO]commons-lang:commons-lang:jar:2.1:compile
 [INFO]com.yarris.consol:consol-ejb:ejb:1.0-SNAPSHOT:compile
 [INFO]   org.apache.axis:axis:jar:1.4:compile
 [INFO]   backport-util-concurrent:backport-util-concurrent:jar:3.0:compile
 [INFO]   commons-discovery:commons-discovery:jar:0.2:compile
 [INFO]   commons-httpclient:commons-httpclient:jar:3.0:compile
 [INFO]  commons-codec:commons-codec:jar:1.3:compile
 [INFO]   commons-javaflow:commons-javaflow:jar:20060411:compile
 [INFO]   commons-pool:commons-pool:jar:1.1:compile
 [INFO]  xerces:xercesImpl:jar:2.0.2:compile
 [INFO]   com.yarris:hubbub-mail:jar:2.1:compile
 [INFO]   jasperreports:jasperreports:jar:1.3.0:compile
 [INFO]  xml-apis:xml-apis:jar:1.0.b2:compile
 [INFO]  eclipse:jdtcore:jar:3.1.0:compile
 [INFO]   org.apache.axis:axis-jaxrpc:jar:1.4:compile
 [INFO]   eclipse:jdt-compiler:jar:3.1.1:compile
 [INFO]   net.sourceforge.jexcelapi:jxl:jar:2.6.3:compile
 [INFO]   com.yarris:kapri:jar:1.0.1:compile
 [INFO]   org.ostermiller:ostermiller-utils:jar:1.04.00:compile
 [INFO]   com.pd4ml:pd4ml:jar:1.2.4:compile
 [INFO]   poi:poi-2.5.1-final:jar:20040804:compile
 [INFO]   javax.xml.soap:saaj-api:jar:1.2:compile
 [INFO]   com.yarris:samurai:jar:1.19:compile
 [INFO]  com.yarris:hubbub-log4j:jar:1.8:compile
 [INFO]  org.acegisecurity:acegi-security:jar:1.0.3:compile
 [INFO] org.springframework:spring-remoting:jar:1.2.8:compile
 [INFO]org.springframework:spring-dao:jar:1.2.8:compile
 [INFO]   org.springframework:spring-context:jar:1.2.8:compile
 [INFO]  org.springframework:spring-aop:jar:1.2.8:compile
 [INFO]org.springframework:spring-webmvc:jar:1.2.8:compile
 [INFO]   org.springframework:spring-web:jar:1.2.8:compile
 [INFO] org.springframework:spring-jdbc:jar:1.2.8:compile
 [INFO]org.springframework:spring-beans:jar:1.2.8:compile
 [INFO]   org.springframework:spring-core:jar:1.2.8:compile
 [INFO] org.springframework:spring-support:jar:1.2.8:runtime
 [INFO]   org.apache.velocity:velocity:jar:1.5:compile
 [INFO]   axis:axis-wsdl4j:jar:1.3:compile
 [INFO]   org.apache.ws:wss4j:jar:1.5.0:compile
 [INFO]   com.yarris:yarris-jms:jar:1.0:compile
 [INFO]   commons-io:commons-io:jar:1.2:compile
 [INFO]   opensymphony:oscache:jar:2.0.2:compile
 [INFO]   com.yarris.consol:consol-interfaces:jar:1.1:compile
 [INFO]   xmlbeans:xbean:jar:2.2.0:compile
 [INFO]struts:struts-el:jar:1.1:compile
 [INFO]com.yarris:sopho:jar:1.6:compile
 [INFO]   jdom:jdom:jar:1.0:compile
 [INFO]   log4j:log4j:jar:1.2.14:compile
 [INFO]   velocity:velocity-dep:jar:1.4:compile
 [INFO]struts:struts:jar:1.1:compile
 [INFO]   struts:struts-legacy:jar:1.1:compile
 [INFO]   commons-validator:commons-validator:jar:1.0.2:compile
 [INFO]   oro:oro:jar:2.0.6:compile
 [INFO]   javax.sql:jdbc-stdext:jar:2.0:compile
 [INFO]com.yarris:hubbub-web:jar:1.3:compile
 [INFO]javax.servlet:jstl:jar:1.0.2:compile
 [INFO]

[jira] Updated: (MDEP-107) Output the dependencies in a consistent and natural order

[Tuomas Kiviaho (JIRA)]

 [ 
http://jira.codehaus.org/browse/MDEP-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MDEP-107:


Attachment: maven-dependency-plugin.patch
maven-common-artifact-filters.patch

Here are simple patches that preserve the natural order

 Output the dependencies in a consistent and natural order
 -

 Key: MDEP-107
 URL: http://jira.codehaus.org/browse/MDEP-107
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: tree
Affects Versions: 2.0
Reporter: William Ferguson
Assignee: Brian Fox
 Attachments: maven-common-artifact-filters.patch, 
 maven-dependency-plugin.patch


 As of 2.0-alpha-5-SNAPSHOT 31-AUG-2007 the dependencies when output are in 
 random order as I suspect they come straight form a Set.
 This makes it really difficult for a human to parse the dependencies.
 Ordering them using the natural artifact order before output would be a great 
 improvement.
 In particular dependency:tree is very hard to read when they are not ordered.
 But if each level were ordered using the natural artifact ordering it would 
 be much easier to read and to work out where the dep problems lay.
 [INFO] [dependency:tree]
 [INFO] com.yarris.consol:consol-web:war:1.0-SNAPSHOT
 [INFO]com.yarris:cielo:jar:1.5:compile
 [INFO]javax.j2ee:j2ee:jar:1.3.1:compile
 [INFO]commons-digester:commons-digester:jar:1.7:compile
 [INFO]opensymphony:sitemesh:jar:2.2.1:compile
 [INFO]commons-lang:commons-lang:jar:2.1:compile
 [INFO]com.yarris.consol:consol-ejb:ejb:1.0-SNAPSHOT:compile
 [INFO]   org.apache.axis:axis:jar:1.4:compile
 [INFO]   backport-util-concurrent:backport-util-concurrent:jar:3.0:compile
 [INFO]   commons-discovery:commons-discovery:jar:0.2:compile
 [INFO]   commons-httpclient:commons-httpclient:jar:3.0:compile
 [INFO]  commons-codec:commons-codec:jar:1.3:compile
 [INFO]   commons-javaflow:commons-javaflow:jar:20060411:compile
 [INFO]   commons-pool:commons-pool:jar:1.1:compile
 [INFO]  xerces:xercesImpl:jar:2.0.2:compile
 [INFO]   com.yarris:hubbub-mail:jar:2.1:compile
 [INFO]   jasperreports:jasperreports:jar:1.3.0:compile
 [INFO]  xml-apis:xml-apis:jar:1.0.b2:compile
 [INFO]  eclipse:jdtcore:jar:3.1.0:compile
 [INFO]   org.apache.axis:axis-jaxrpc:jar:1.4:compile
 [INFO]   eclipse:jdt-compiler:jar:3.1.1:compile
 [INFO]   net.sourceforge.jexcelapi:jxl:jar:2.6.3:compile
 [INFO]   com.yarris:kapri:jar:1.0.1:compile
 [INFO]   org.ostermiller:ostermiller-utils:jar:1.04.00:compile
 [INFO]   com.pd4ml:pd4ml:jar:1.2.4:compile
 [INFO]   poi:poi-2.5.1-final:jar:20040804:compile
 [INFO]   javax.xml.soap:saaj-api:jar:1.2:compile
 [INFO]   com.yarris:samurai:jar:1.19:compile
 [INFO]  com.yarris:hubbub-log4j:jar:1.8:compile
 [INFO]  org.acegisecurity:acegi-security:jar:1.0.3:compile
 [INFO] org.springframework:spring-remoting:jar:1.2.8:compile
 [INFO]org.springframework:spring-dao:jar:1.2.8:compile
 [INFO]   org.springframework:spring-context:jar:1.2.8:compile
 [INFO]  org.springframework:spring-aop:jar:1.2.8:compile
 [INFO]org.springframework:spring-webmvc:jar:1.2.8:compile
 [INFO]   org.springframework:spring-web:jar:1.2.8:compile
 [INFO] org.springframework:spring-jdbc:jar:1.2.8:compile
 [INFO]org.springframework:spring-beans:jar:1.2.8:compile
 [INFO]   org.springframework:spring-core:jar:1.2.8:compile
 [INFO] org.springframework:spring-support:jar:1.2.8:runtime
 [INFO]   org.apache.velocity:velocity:jar:1.5:compile
 [INFO]   axis:axis-wsdl4j:jar:1.3:compile
 [INFO]   org.apache.ws:wss4j:jar:1.5.0:compile
 [INFO]   com.yarris:yarris-jms:jar:1.0:compile
 [INFO]   commons-io:commons-io:jar:1.2:compile
 [INFO]   opensymphony:oscache:jar:2.0.2:compile
 [INFO]   com.yarris.consol:consol-interfaces:jar:1.1:compile
 [INFO]   xmlbeans:xbean:jar:2.2.0:compile
 [INFO]struts:struts-el:jar:1.1:compile
 [INFO]com.yarris:sopho:jar:1.6:compile
 [INFO]   jdom:jdom:jar:1.0:compile
 [INFO]   log4j:log4j:jar:1.2.14:compile
 [INFO]   velocity:velocity-dep:jar:1.4:compile
 [INFO]struts:struts:jar:1.1:compile
 [INFO]   struts:struts-legacy:jar:1.1:compile
 [INFO]   commons-validator:commons-validator:jar:1.0.2:compile
 [INFO]   oro:oro:jar:2.0.6:compile
 [INFO]   javax.sql:jdbc-stdext:jar:2.0:compile
 [INFO]com.yarris:hubbub-web:jar:1.3:compile
 [INFO]javax.servlet:jstl:jar:1.0.2:compile
 [INFO]commons-fileupload:commons-fileupload:jar:1.0:compile
 [INFO]jfree:jfreechart:jar:1.0.2:compile
 [INFO]   

[jira] Commented: (MDEP-266) Add parameter to configure copy-dependencies to also copy optional dependencies

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MDEP-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=252677#action_252677
 ] 

Tuomas Kiviaho commented on MDEP-266:
-

This affects build-classpath goal as well. I'm using assembly plugin that 
includes optional dependencies by default as well but I am unable to generate a 
proper classpath for them.

 Add parameter to configure copy-dependencies to also copy optional 
 dependencies
 ---

 Key: MDEP-266
 URL: http://jira.codehaus.org/browse/MDEP-266
 Project: Maven 2.x Dependency Plugin
  Issue Type: New Feature
  Components: copy-dependencies
Affects Versions: 2.1
Reporter: Andreas Sewe
Assignee: Brian Fox
Priority: Minor

 At the moment, copy-dependencies only copies non-optional dependencies. 
 However, one sometimes wants to copy *all* dependencies -- even the optional 
 ones.

-- 
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

[jira] Commented: (MASSEMBLY-324) DependencySet scope runtime includes jars that are scope provided

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=252327#action_252327
 ] 

Tuomas Kiviaho commented on MASSEMBLY-324:
--

I propose adding of an excludeScope element to dependencySet (with similar 
behavior as in maven-dependency-plugin:copy-dependencies)

 DependencySet scope runtime includes jars that are scope provided
 -

 Key: MASSEMBLY-324
 URL: http://jira.codehaus.org/browse/MASSEMBLY-324
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Michael Mattox

 I use some jars in provided scope:
   dependency
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.5/version
   scopeprovided/scope
   /dependency
 in my assembly, I specify scope as runtime:
   dependencySet
   outputDirectoryWEB-INF/lib/outputDirectory
   unpackfalse/unpack
   scoperuntime/scope
   /dependencySet
 Yet I still find the servlet-api-2.5.jar in my WAR.  SInce the servlet-api is 
 scope provided, it should be provided by the container and not included in 
 the WAR.

-- 
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

[jira] Commented: (WAGON-177) Allow use of both password and private key

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/WAGON-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243747#action_243747
 ] 

Tuomas Kiviaho commented on WAGON-177:
--

Logic is actually vice versa as states the following old chinese saying taken 
from AbstractSshWagon
// If user don't define a password, he want to use a private key

I'm transitioning from private key based scp connection to http protocol with 
encrypted password and it would have been great to maintains backwards 
compatibility (the password I'm using happens to be different between the two 
approaches).

 Allow use of both password and private key
 --

 Key: WAGON-177
 URL: http://jira.codehaus.org/browse/WAGON-177
 Project: Maven Wagon
  Issue Type: Improvement
  Components: wagon-ssh
Reporter: Kenney Westerhof
 Fix For: 1.x


 We have corporate m2 repository over http with Digest authentication.
 We specify the username and password for that repository so the 
 ArtifactManager can download
 artifacts.
 We also use scp to deploy artifacts to that same repository. We use the same 
 username, but
 a different password and/or a private key file.
 AbstractSshWagon's logic is that it only uses the private key file if there's 
 no password specified.
 It should first try the private key file, and optionally use the password to 
 decode it if it's password-protected,
 then try that private key authentication, and if that fails, try the 
 password/passphrase authentications.
 Ssh allows for multiple authentication methods to be tried before failure.
 Even better would be to allow different usernames for the same repository, 
 depending on if it's
 used for deployment or artifact resolution (but that's a maven-core issue).
 Right now we have to use two different repository id's and double 
 configuration for both normal and snapshot repositories, when in fact it's 
 the same repository with 2 different access methods.
 (most of this issue is more appropriately placed in maven-core somewhere, but 
 the password/privatekey
 issue solves part of the problem).

-- 
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

[jira] Commented: (MCHANGES-160) Support creating a plain text version of the report

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MCHANGES-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234113#action_234113
 ] 

Tuomas Kiviaho commented on MCHANGES-160:
-

Or use antrun to copy it to suitable location. 

tasks
  copy file=${project.build.directory}/target/announcement.vm 
tofile=${project.basedir}/appassembler/CHANGES.txt/
/tasks


 Support creating a plain text version of the report
 ---

 Key: MCHANGES-160
 URL: http://jira.codehaus.org/browse/MCHANGES-160
 Project: Maven 2.x Changes Plugin
  Issue Type: New Feature
Reporter: Trygve Laugstol

 Useful when the change log is to be included in a native package or in a WAR 
 as documentation.

-- 
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

[jira] Commented: (MNG-4060) Remove support for profiles.xml

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199718#action_199718
 ] 

Tuomas Kiviaho commented on MNG-4060:
-

I think that the feature has become obsolete because it can be replaced with 
mixins (http://markmail.org/thread/6qqccwkrry5up2un). I just don't know how to 
do this.

 Remove support for profiles.xml
 ---

 Key: MNG-4060
 URL: http://jira.codehaus.org/browse/MNG-4060
 Project: Maven 2
  Issue Type: Task
  Components: Profiles
Reporter: Benjamin Bentmann
Assignee: Shane Isbell
Priority: Minor
 Fix For: 3.0-alpha-3


 As per [r748226|http://svn.eu.apache.org/viewvc?view=revrevision=748226] 
 support for {{profiles.xml}} will be dropped. Tracking this here as a user 
 visible change for the release history.

-- 
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

[jira] Updated: (MJAR-117) addClasspath should choosing scope

[Tuomas Kiviaho (JIRA)]

 [ 
http://jira.codehaus.org/browse/MJAR-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MJAR-117:


Attachment: pom.xml

If I understood correctly you're having similar problem as I have. 

Dependencies are not included into manifest classpath when their scope is test. 
There is one dependency with transitivity in the attached IT pom that I 
expected to be included into manifest classpath of test-jar as

Class-Path: junit-dep-4.4.jar hamcrest-core-1.1.jar 

 addClasspath should choosing scope
 --

 Key: MJAR-117
 URL: http://jira.codehaus.org/browse/MJAR-117
 Project: Maven 2.x Jar Plugin
  Issue Type: Improvement
 Environment: mvn 2.0.9, 
Reporter: Kamil Demecki
 Attachments: pom.xml


 We have project to running tests for system. Running single test from mvn 
 test works. The problem is that sometimes part of this project is using 
 standalone from command line. So zip is builded from mvn assembly with 
 scope test but dependencies test are not added to jar Manifest  with 
 option addClasspath.
 Is possible to add additional argument addClasspathScope which should 
 resolve situation? 
 Other solution is to change scope for dependencies for this project, but it 
 not so simple, because our configuration looks:
 project-01
   main
   test
 project-02
   main
   test
 ...
 project-100
   main
   test
 project-integration-tests
   main
 Projects [01-100]  have scope test dependendencies and 
 project-integration-tests inherit this scope test dependendencies. To 
 choose solution (2), pom for project-integration-tests should override all 
 test dependendencies with scope compile.

-- 
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

[jira] Created: (MRELEASE-479) Option to handle plugins missing explicit version number

[Tuomas Kiviaho (JIRA)]

Option to handle plugins missing explicit version number


 Key: MRELEASE-479
 URL: http://jira.codehaus.org/browse/MRELEASE-479
 Project: Maven 2.x Release Plugin
  Issue Type: New Feature
  Components: prepare
Affects Versions: 2.0-beta-9
Reporter: Tuomas Kiviaho


A plugin declaration without version number is likely to turn 'bad' when using 
other version of maven (and super-pom). A switch that prompts version number 
providing version from super-pom as default would prevent maven upgrades from 
corrupting builds.

-- 
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

[jira] Commented: (MRELEASE-479) Option to handle plugins missing explicit version number

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MRELEASE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=189668#action_189668
 ] 

Tuomas Kiviaho commented on MRELEASE-479:
-

Using maven-eclipse-plugin type of plugin for released artifacts goes beyond my 
imagination :-) 

What about sticking to plugins that have explicit configuration in the pom at 
hand and leaving undeclared plugins as-is.

 Option to handle plugins missing explicit version number
 

 Key: MRELEASE-479
 URL: http://jira.codehaus.org/browse/MRELEASE-479
 Project: Maven 2.x Release Plugin
  Issue Type: New Feature
  Components: prepare
Affects Versions: 2.0-beta-9
Reporter: Tuomas Kiviaho

 A plugin declaration without version number is likely to turn 'bad' when 
 using other version of maven (and super-pom). A switch that prompts version 
 number providing version from super-pom as default would prevent maven 
 upgrades from corrupting builds.

-- 
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

[jira] Commented: (MDEP-211) Possibility to prepend groupId to dependencies

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MDEP-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179290#action_179290
 ] 

Tuomas Kiviaho commented on MDEP-211:
-

I'm struggling with similar problem between this plugin goal and assembly 
plugins output using outputFileNameMapping of a dependencySet. 

In my opinion the filename mapping capability is desirable because it gives 
total freedom and removes hassle with stripVersion, prefix, localRepoProperty, 
outputAbsoluteArtifactFilename (and prependGroupId). 

Backwards compatibility can be maintained if there would be a default 
outputFileNameMapping which changes as per scenario selected with above 
parameters and overtakes when explicitly defined. What assembly plugin also 
needs is a way to determine whether or not ${artifact.groupId} is in legacy or 
default repository mode.

 Possibility to prepend groupId to dependencies
 --

 Key: MDEP-211
 URL: http://jira.codehaus.org/browse/MDEP-211
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: build-classpath, copy-dependencies
Affects Versions: 2.2
Reporter: Oumar Aziz OUATTARA
Assignee: Brian Fox
 Attachments: add_parameter_prepend_groupId.patch


 Hi, 
 I would like to use the dependency plugin to copy dependencies including the 
 groupId in the destination filename. This is to be able afterward to classify 
 the plugins based on their groupId. 
 It can also avoid a scenario like two dependencies with different groupIds 
 and the same ArtifactId to collide when doing the copy.
 For this I propose a new configuration parameter prependGroupId.
 See attached patch for more details.

-- 
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

[jira] Issue Comment Edited: (MDEP-211) Possibility to prepend groupId to dependencies

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MDEP-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179290#action_179290
 ] 

Tuomas Kiviaho edited comment on MDEP-211 at 6/4/09 7:36 AM:
-

I'm struggling with similar problem between this plugin goal and assembly 
plugins output using outputFileNameMapping of a dependencySet. 

In my opinion the filename mapping capability is desirable because it gives 
total freedom and removes hassle with stripVersion, prefix, localRepoProperty, 
outputAbsoluteArtifactFilename, fileSeparator (and prependGroupId). 

Backwards compatibility can be maintained if there would be a default 
outputFileNameMapping which changes as per scenario selected with above 
parameters and overtakes when explicitly defined. What assembly plugin also 
needs is a way to determine whether or not ${artifact.groupId} is in legacy or 
default repository mode that would in turn use fileSeparator

  was (Author: tuomas_kiviaho):
I'm struggling with similar problem between this plugin goal and assembly 
plugins output using outputFileNameMapping of a dependencySet. 

In my opinion the filename mapping capability is desirable because it gives 
total freedom and removes hassle with stripVersion, prefix, localRepoProperty, 
outputAbsoluteArtifactFilename (and prependGroupId). 

Backwards compatibility can be maintained if there would be a default 
outputFileNameMapping which changes as per scenario selected with above 
parameters and overtakes when explicitly defined. What assembly plugin also 
needs is a way to determine whether or not ${artifact.groupId} is in legacy or 
default repository mode.
  
 Possibility to prepend groupId to dependencies
 --

 Key: MDEP-211
 URL: http://jira.codehaus.org/browse/MDEP-211
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: build-classpath, copy-dependencies
Affects Versions: 2.2
Reporter: Oumar Aziz OUATTARA
Assignee: Brian Fox
 Attachments: add_parameter_prepend_groupId.patch


 Hi, 
 I would like to use the dependency plugin to copy dependencies including the 
 groupId in the destination filename. This is to be able afterward to classify 
 the plugins based on their groupId. 
 It can also avoid a scenario like two dependencies with different groupIds 
 and the same ArtifactId to collide when doing the copy.
 For this I propose a new configuration parameter prependGroupId.
 See attached patch for more details.

-- 
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

[jira] Created: (MASSEMBLY-421) Maven repository layout like directory structure using dependencySet

[Tuomas Kiviaho (JIRA)]

Maven repository layout like directory structure using dependencySet


 Key: MASSEMBLY-421
 URL: http://jira.codehaus.org/browse/MASSEMBLY-421
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Reporter: Tuomas Kiviaho


I can't figure out a decent way how to produce maven repo layout with 
outputFileNameMapping (and outputDirectory). I can produce legacy layout but 
default seems to be currently impossible using ${artifact.groupId}.  I hope 
there is easier way of using some intermediate property that ${artifact.} or 
${artifact.handler.} provides, but I could not find one.

Therefore I propose a new parameter 'layout' with 'default' and 'legacy' values 
to control appearance of ${artifact.groupId}.

-- 
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

[jira] Commented: (MASSEMBLY-421) Maven repository layout like directory structure using dependencySet

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179346#action_179346
 ] 

Tuomas Kiviaho commented on MASSEMBLY-421:
--

Thanks for the pointer. Shame on me since it was properly documented as well. 
Works like a charm with dependency:build-process.

 Maven repository layout like directory structure using dependencySet
 

 Key: MASSEMBLY-421
 URL: http://jira.codehaus.org/browse/MASSEMBLY-421
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Reporter: Tuomas Kiviaho
Assignee: John Casey
 Fix For: 2.2-beta-4


 I can't figure out a decent way how to produce maven repo layout with 
 outputFileNameMapping (and outputDirectory). I can produce legacy layout but 
 default seems to be currently impossible using ${artifact.groupId}.  I hope 
 there is easier way of using some intermediate property that ${artifact.} 
 or ${artifact.handler.} provides, but I could not find one.
 Therefore I propose a new parameter 'layout' with 'default' and 'legacy' 
 values to control appearance of ${artifact.groupId}.

-- 
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

[jira] Issue Comment Edited: (MASSEMBLY-421) Maven repository layout like directory structure using dependencySet

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179346#action_179346
 ] 

Tuomas Kiviaho edited comment on MASSEMBLY-421 at 6/4/09 12:02 PM:
---

Thanks for the pointer. Shame on me since it was properly documented as well. 
Works like a charm with dependency:build-classpath.

  was (Author: tuomas_kiviaho):
Thanks for the pointer. Shame on me since it was properly documented as 
well. Works like a charm with dependency:build-process.
  
 Maven repository layout like directory structure using dependencySet
 

 Key: MASSEMBLY-421
 URL: http://jira.codehaus.org/browse/MASSEMBLY-421
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Reporter: Tuomas Kiviaho
Assignee: John Casey
 Fix For: 2.2-beta-4


 I can't figure out a decent way how to produce maven repo layout with 
 outputFileNameMapping (and outputDirectory). I can produce legacy layout but 
 default seems to be currently impossible using ${artifact.groupId}.  I hope 
 there is easier way of using some intermediate property that ${artifact.} 
 or ${artifact.handler.} provides, but I could not find one.
 Therefore I propose a new parameter 'layout' with 'default' and 'legacy' 
 values to control appearance of ${artifact.groupId}.

-- 
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

[jira] Commented: (MDEP-159) multipleScopes, classPathScripts, includeThisArtifact

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MDEP-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179380#action_179380
 ] 

Tuomas Kiviaho commented on MDEP-159:
-

includeThisArtifact gets my vote. I guess this has the same meaning as what 
assembly plugins useProjectAftifact of dependencySets.

 multipleScopes, classPathScripts, includeThisArtifact
 -

 Key: MDEP-159
 URL: http://jira.codehaus.org/browse/MDEP-159
 Project: Maven 2.x Dependency Plugin
  Issue Type: New Feature
Reporter: Francis Korning
Assignee: Brian Fox
 Attachments: MDEP-159-patch.zip


 the dependency plugin is used to analyze, validate, manage, package, and 
 report on maven dependencies.
 in our framework we are interested in two features provided by these goals:
 * copy-dependencies: package the project's complete transitive 
 compiletime/runtime dependencies
 * build-classpath: from this construct a classpath text file usable by 
 maven and command-line shells. 
 saddly the current plugin still an alpha snapshot (2.0-alpha-5-SNAPSHOT) 
 release and in any case does not have all of the features we need.
 specifically it is geared toward creating a one-line classpath path 
 statement, which doesn't really allow for shell usage and expansion, 
 especially in the windows dos/cmd environment where backtick isn't supported. 
 we can work around the backtick by using an stdin redirect with set /p, but 
 this prompt has a max buffer length, which opens up a whole can of worms.
 also, the dependency plugin doesn't add-in the current target artifact to the 
 dependency classpath, which is something we'd like to include in our runtiome 
 classpath.
 finally, the includeScope and excludeScope filters only allow to exlicitly 
 include/exclude a single scope at a time, instead of a comma-separated list 
 like the other filters.
 so what we need is a way to create multi-line classpath loading scripts.
 || parameter  || type || default  || description ||
 | includeScope| string| *all* | comma-separated 
 scopes to include, default is null=*all* |
 | excludeScope| string| *none*| comma-separated 
 scopes to exclude, default is null=*none* | 
 | usePathSeparator| boolean   | true  | exposed to toggle 
 pathSeparator, set to false for multi-line | 
 | useFileSeparator| boolean   | true  | exposed to toggle 
 fileSeparator, set to false for multi-line | 
 | useLineSeparator| boolean   | false | set to true for 
 multi-line | 
 | suffix  | string| null  | (unused) | 
 | lineSeparator   | string| null  | line separator, see special 
 tokens for escape codes below | 
 | includeThisArtifact | boolean   | false | include this 
 geenrated target jar artifact in the dependencies| 
 * in a separator, allowing the following special tokens: 
 {code}
   [CR]-  '\r'
   [LF]-  '\n'
   [CRLF]  -  '\r\n'
 {code}
 sample configuration
 {code}
   !-- maven-dependency-plugin: generate classpath --
   plugin
   groupIdsgcib.ged.plugins/groupId
   artifactIdmaven-dependency-plugin/artifactId
   version2.0-alpha-5-sg-SNAPSHOT/version
   executions
   execution
   idcopy-dependencies/id
   phasecompile/phase
   goals
   
 goalcopy-dependencies/goal
   /goals
   configuration
   
 outputDirectorytarget/dependency/outputDirectory
   
 overWriteIfNewertrue/overWriteIfNewer
   /configuration
   /execution
   execution
   
 idcopy-endorsed-dependencies/id
   phasepackage/phase
   goals
   
 goalcopy-dependencies/goal
   /goals
   configuration
   
 outputDirectorytarget/dependency/endorsed/outputDirectory 
   
   
 

[jira] Created: (MDEP-214) Accompany outputFilterFile with possibility of of definining used property name.

[Tuomas Kiviaho (JIRA)]

Accompany outputFilterFile with possibility of of definining used property name.


 Key: MDEP-214
 URL: http://jira.codehaus.org/browse/MDEP-214
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: build-classpath
Affects Versions: 2.1
Reporter: Tuomas Kiviaho
Assignee: Brian Fox
Priority: Minor


Currently filter format is hardcoded as 'classpath=x'. assembly plugin 
bundles files and filter together so each classpath property file 
(unix/windows/..) requires separate assembly plugin definition for each 
classpath variant. By exposing an 'outputFilterName' parameter, this extra step 
would be removed. Instead of above one could have classpath.unix=x, 
classpath.windows=y. One step further would be the possibility of appending 
these into same file, but only if that wouldn't require yet another parameter.

-- 
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

[jira] Commented: (MRELEASE-353) release:prepare failed after a refactoring

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MRELEASE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=166679#action_166679
 ] 

Tuomas Kiviaho commented on MRELEASE-353:
-

Provider seems to be responsible indeed (as the error log states). For me a 
simple cleanup of workspace recovered the problem in above sample. The plugin 
try to cleanup the workspace before preparation but it might not be always 
appropriate (unwanted side effects etc.). Provider API might also prevent the 
implementation.

 release:prepare failed after a refactoring
 --

 Key: MRELEASE-353
 URL: http://jira.codehaus.org/browse/MRELEASE-353
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.0-beta-7
 Environment: Windows XP Pro SP2, maven-2.0.9, svn-1.4.5, java-1.6.0_03
Reporter: Guillaume Boucherie

 The goal release:prepare failed if it is launched after a refactoring of a 
 project.
 By refactoring I mean change a package name or delete a directory.
 So after doing this kind of refactoring if you try do to a release:prepare 
 you got an error when the plugin try to create the tag in svn :
 [INFO] Tagging release with the label maven-header-plugin-1.1...
 [INFO] Executing: svn --non-interactive copy --file 
 C:\DOCUME~1\GUILLA~1.IDE\LOCALS~1\Temp\maven-scm-896035269.commit . 
 http://s-neptune/subversion2/sweetdev-forge/tags/maven-header-plugin-1.1
 [INFO] Working directory: 
 E:\projects\sweetdev-forge\trunk\maven-plugins\maven-header-plugin
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] Unable to tag SCM
 Provider message:
 The svn tag command failed.
 Command output:
 svn: Commit failed (details follow):
 svn: Directory 
 'E:\projects\sweetdev-forge\trunk\maven-plugins\maven-header-plugin\src\main\java\com\ideo\sweetdevria'
  is missing
 I must create a fresh checkout of my project for the release:prepare goal to 
 work.

-- 
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

[jira] Commented: (MRELEASE-353) release:prepare failed after a refactoring

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MRELEASE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=166221#action_166221
 ] 

Tuomas Kiviaho commented on MRELEASE-353:
-

Same here with Maven 2.0.10
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Directory 'src' is missing

Steps to reproduce. 
1. Checkout a project
2. Delete a direct sub folder already in svn and commit the change.
3. release:prepare -- FAIL
4. Re-checkout the same project in different location
5. release:prepare -- OK

 release:prepare failed after a refactoring
 --

 Key: MRELEASE-353
 URL: http://jira.codehaus.org/browse/MRELEASE-353
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.0-beta-7
 Environment: Windows XP Pro SP2, maven-2.0.9, svn-1.4.5, java-1.6.0_03
Reporter: Guillaume Boucherie

 The goal release:prepare failed if it is launched after a refactoring of a 
 project.
 By refactoring I mean change a package name or delete a directory.
 So after doing this kind of refactoring if you try do to a release:prepare 
 you got an error when the plugin try to create the tag in svn :
 [INFO] Tagging release with the label maven-header-plugin-1.1...
 [INFO] Executing: svn --non-interactive copy --file 
 C:\DOCUME~1\GUILLA~1.IDE\LOCALS~1\Temp\maven-scm-896035269.commit . 
 http://s-neptune/subversion2/sweetdev-forge/tags/maven-header-plugin-1.1
 [INFO] Working directory: 
 E:\projects\sweetdev-forge\trunk\maven-plugins\maven-header-plugin
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] Unable to tag SCM
 Provider message:
 The svn tag command failed.
 Command output:
 svn: Commit failed (details follow):
 svn: Directory 
 'E:\projects\sweetdev-forge\trunk\maven-plugins\maven-header-plugin\src\main\java\com\ideo\sweetdevria'
  is missing
 I must create a fresh checkout of my project for the release:prepare goal to 
 work.

-- 
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

[jira] Created: (MEAR-84) Ability to interpolate filenamemapping using regex.

[Tuomas Kiviaho (JIRA)]

Ability to interpolate filenamemapping using regex.
---

 Key: MEAR-84
 URL: http://jira.codehaus.org/browse/MEAR-84
 Project: Maven 2.x Ear Plugin
  Issue Type: Wish
Reporter: Tuomas Kiviaho
Priority: Minor


I was trying to have an impact how artifact files would be mapped based on 
previous knowledge about assembly plugin but noticed that  there's a 
fundamental difference in implementations. 

Both the 'stardard' and 'full' file name mapping of ear plugin could have been 
implemented using org.codehaus.plexus.util.interpolation.RegexBasedInterpolator 
quite identically to 
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.evaluateFileNameMapping
 used in assembly plugin. The class name based pluggability is only available 
at EAR side.

Regular expressions of the interpolator have a distinctive pattern separating 
them from classes and predefined mappings making it backwards compatible to 
extend the FileNameMappingFactory to match regular expressions.

-- 
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

[jira] Updated: (MEAR-84) Ability to interpolate filenamemapping using regex.

[Tuomas Kiviaho (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MEAR-84:
---

Attachment: regex.patch

regex.patch contains modified test cases from EAR file name mapping and a 
customized org.apache.maven.plugin.assembly.utils.AssemblyFormatUtilsTest. 
There are references to maven-assembly-plugin which need to be solved. 
Conversion from AssemblyFormatUtilsTest as RegexFileNameMappingTest is 
basically just removal of project and model features that do not apply to 
FileNameMapping since only the artifact is available. 

With this patch I was already able to pull a static regex file name mapping... 

${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}

...which distinguishes version from base version when snapshots are used 
because current implementations are based on ${artifact.file.name} and they 
both lose unique versions because file name is based on base version.



 Ability to interpolate filenamemapping using regex.
 ---

 Key: MEAR-84
 URL: http://jira.codehaus.org/browse/MEAR-84
 Project: Maven 2.x Ear Plugin
  Issue Type: Wish
Reporter: Tuomas Kiviaho
Priority: Minor
 Attachments: regex.patch


 I was trying to have an impact how artifact files would be mapped based on 
 previous knowledge about assembly plugin but noticed that  there's a 
 fundamental difference in implementations. 
 Both the 'stardard' and 'full' file name mapping of ear plugin could have 
 been implemented using 
 org.codehaus.plexus.util.interpolation.RegexBasedInterpolator quite 
 identically to 
 org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.evaluateFileNameMapping
  used in assembly plugin. The class name based pluggability is only available 
 at EAR side.
 Regular expressions of the interpolator have a distinctive pattern separating 
 them from classes and predefined mappings making it backwards compatible to 
 extend the FileNameMappingFactory to match regular expressions.

-- 
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

[jira] Created: (MASSEMBLY-263) Include component location information

[Tuomas Kiviaho (JIRA)]

Include component location information
--

 Key: MASSEMBLY-263
 URL: http://jira.codehaus.org/browse/MASSEMBLY-263
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2-beta-2
Reporter: Tuomas Kiviaho
Priority: Trivial


Debugger is needed to resolve the correct component.xml causing exceptions. 
Parsing exceptions could have the location simply included in the exception 
message seen in the attachment and an informational message such as:

[INFO] Reading assembly component descriptor: src/main/assembly/component.xml

would also cover other situations.

-- 
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

[jira] Updated: (MASSEMBLY-263) Include component location information

[Tuomas Kiviaho (JIRA)]

 [ 
http://jira.codehaus.org/browse/MASSEMBLY-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MASSEMBLY-263:
-

Attachment: stacktrace.txt

 Include component location information
 --

 Key: MASSEMBLY-263
 URL: http://jira.codehaus.org/browse/MASSEMBLY-263
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2-beta-2
Reporter: Tuomas Kiviaho
Priority: Trivial
 Attachments: stacktrace.txt


 Debugger is needed to resolve the correct component.xml causing exceptions. 
 Parsing exceptions could have the location simply included in the exception 
 message seen in the attachment and an informational message such as:
 [INFO] Reading assembly component descriptor: src/main/assembly/component.xml
 would also cover other situations.

-- 
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

[jira] Commented: (MASSEMBLY-151) Documentation for the assembly plugin is utterly confusing

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119565
 ] 

Tuomas Kiviaho commented on MASSEMBLY-151:
--

Interpolation precedence,

Current description of outputFileNameMapping did not give any clues that such 
prefixes as 'module.' 'artifact.' and 'pom.' existed. There aren't any examples 
of how to reference artifact at hand. outputDirectory has also similar extra 
features available, but they are not documented on site.

I just spent some time to discover the semantics from within source code where 
they were well documented 
(org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils) but for general 
documentation too technically oriented as-is. Following version removal example 
could be added to including-and-excluding-artifacts.apt

dependencySets
dependencySet
...
outputFileNameMapping

${artifact.artifactId}${dashClassifier?}.${artifact.extension}
/outputFileNameMapping
/dependencySet
..
/dependencySets

 Documentation for the assembly plugin is utterly confusing
 --

 Key: MASSEMBLY-151
 URL: http://jira.codehaus.org/browse/MASSEMBLY-151
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.1, 2.2
Reporter: Nigel Magnay
 Fix For: 2.2-beta-2


 This is going to come across as a whinge, I'm afraid, but the assembly plugin 
 is a fairly important vital component in M2; I find it very confusing and 
 I've been using it for a bit. I have observed it putting off other people 
 from using m2 at all, which is I think a shame.
 I'd document it myself, but I don't understand the differences between some 
 of the goals (and I don't understand why the fix in MASSEMBLY-97 is 
 neccessary).
 In the goals page,there's lots of options that seem to overlap or do the same 
 thing. There's no clue (other than trial and error) as to why some of them 
 will work some times, and some will not (e.g. in multiproject builds). What's 
 worse is some of the problems only appear in specific circumstances (E.g. 
 doing multiprojects in a 'clean' build'). 
 This either needs documenting, or (better), fixing in the code. We have (from 
 the site):
  assembly:assemblyAssemble an application bundle or distribution 
 from an assembly descriptor.
 Good, seems logical to me
 assembly:unpack   Unpack project dependencies. Currently supports 
 dependencies of type jar and zip.
 The reverse. Yep.
 assembly:attached Assemble an application bundle or distribution from an 
 assembly descriptor. Do not specify a phase, so make it usable in a reactor 
 environment where forking would create issues.
 Erk? How should a user read this? To me usable in a reactor environment 
 where forking would create issues reads to me as there's a bug in 
 assembly:assembly if used in a multiproject build. 
 - it assumes that the user knows a multi project build is a 'reactor' build
 - why can't assembly:assembly be fixed so it does work in multiproject 
 builds? Why can't it detect the environment, and do the 'right thing' (or at 
 the very least spit out a warning) ?
 This is just inviting the user to pick the wrong goal.
 assembly:directoryAssemble an application bundle or distribution.
 Without a descriptor? If I click the link to the goal parameters for this or 
 for assembly:assembly, I get identical pages of parameters. How is this 
 different?
 assembly:directory-inline Assemble an application bundle or distribution 
 from an assembly descriptor without launching a parallel lifecycle build.
 In what scenarios would I as a user need this? Is it for a bug workaround? 
 Would it not be better as a parameter to turn off/on parallel lifecycle 
 build ?
 assembly:single   Assemble an application bundle or distribution from an 
 assembly descriptor. Do not specify a phase, so make it usable in a reactor 
 environment where forking would create issues. Do not specify it as an 
 aggregator, so it is only for a single project. Both cases aid it in working 
 around issues with the Maven lifecycle that should be addressed in Maven 2.1.
 A whole heap of information that seems to boil down to there is a bug, and 
 a heap of confusing terminology (do not specify it as an aggregator).  
 When should this be used ? Every time you actually want assembly:assembly in 
 a multiproject build? How is it different to assembly:attached?
 It seems to me that the plugin does 2 things. (pack things, unpack things). 
 All these additional goals seem to be (I can't tell this) workarounds for 
 bugs. 
 Why can't we just have
 assembly:assembly
 and
 assembly:unpack
 and make the plugin work properly? If multiproject builds fail on fork, then 
 stop the plugin from forking 

[jira] Commented: (SUREFIRE-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/SUREFIRE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113488
 ] 

Tuomas Kiviaho commented on SUREFIRE-364:
-

For those who are wondering where the range comes and where it is matched 
here's a take from my local metadata:

maven-metadata-central.xml
  groupIdorg.codehaus.plexus/groupId
  artifactIdplexus-archiver/artifactId
  version1.0-alpha-7/version
  versioning
release1.0-alpha-8/release
versions
  version1.0-alpha-7/version
  version1.0-alpha-8/version
  version1.0-alpha-9/version
/versions
lastUpdated20070721012454/lastUpdated
  /versioning

maven-metadata-codehaus.snapshots.xml
  groupIdorg.codehaus.plexus/groupId
  artifactIdplexus-archiver/artifactId
  versioning
latest1.0-alpha-9/latest
release1.0-alpha-9/release
versions
  version1.0-alpha-3/version
  version1.0-alpha-4/version
  version1.0-alpha-6/version
  version1.0-alpha-7/version
  version1.0-alpha-8/version
  version1.0-alpha-9/version
  version1.0-alpha-10-SNAPSHOT/version
/versions
lastUpdated20071029092420/lastUpdated
  /versioning

The version range comes from central metadata and the actual location of the 
artifact is codehaus snapshots. When mutilating the central medata by adding 
the 1.0-alpha-10-SNAPSHOT to the range the default artifact collector 
(maven-artifact-2.0.8-SNAPSHOT) doesn't break the lifecycle. 

Here's the original stacktrace which I believe is the same as Matt's.

Caused by: 
org.apache.maven.artifact.versioning.OverConstrainedVersionException: Couldn't 
find a version in [1.0-alpha-7, 1.0-alpha-8, 1.0-alpha-9] to match range 
[1.0-alpha-10-SNAPSHOT,1.0-alpha-10-S
NAPSHOT]
  org.codehaus.plexus:plexus-archiver:jar:null

from the specified remote repositories: 
  ...
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ...
  apache.snapshots (http://people.apache.org/maven-snapshot-repository),
  central (http://repo1.maven.org/maven2)

at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:291)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
at 
org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:654)
at 
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:557)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more

 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
 ---

 Key: SUREFIRE-364
 URL: http://jira.codehaus.org/browse/SUREFIRE-364
 Project: Maven Surefire
  Issue Type: Bug
  Components: plugin
Affects Versions: 2.4
Reporter: Matt Read
Assignee: John Casey
Priority: Blocker
   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 Previously stable build now reports this:
 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact.
 27-Oct-2007 12:04:15
 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 
 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT]
 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null
 27-Oct-2007 12:04:15
 27-Oct-2007 12:04:15 from the specified remote repositories:
 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases 
 (http://maven.catlin.com/#8203;maven2-repo/#8203;releases),
 27-Oct-2007 12:04:15 Apache Snapshots 
 (http://people.apache.org/#8203;repo/#8203;m2-snapshot-repository),
 27-Oct-2007 12:04:15 stat-scm-sourceforge 
 (http://stat-scm.sourceforge.net/#8203;maven2),
 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots 
 (http://maven.catlin.com/#8203;maven2-repo/#8203;snapshots),
 27-Oct-2007 12:04:15 central (http://repo1.maven.org/#8203;maven2),
 27-Oct-2007 12:04:15 codehaus.snapshots 
 (http://snapshots.repository.codehaus.org),
 27-Oct-2007 12:04:15 apache.snapshots 
 (http://people.apache.org/#8203;repo/#8203;m2-snapshot-repository),
 27-Oct-2007 12:04:15 Codehaus Snapshots 
 (http://snapshots.repository.codehaus.org/#8203
 27-Oct-2007 12:04:15 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 

[jira] Created: (MNG-3261) Classified extensions

[Tuomas Kiviaho (JIRA)]

Classified extensions
-

 Key: MNG-3261
 URL: http://jira.codehaus.org/browse/MNG-3261
 Project: Maven 2
  Issue Type: Improvement
  Components: Plugins and Lifecycle, POM
Affects Versions: 2.0.7
Reporter: Tuomas Kiviaho
Priority: Minor


I planned to use checkstyle suppression filters though an extension mimicking 
the multimodule configuration but instead using classified extensions. During 
the process I realized that model version 4.0.0 doesn't allow defining a 
classifier (nor type) along with groupId, artifactId and version. Is there a 
compelling reason for this or could these elements be allowed to some future 
model version.

-- 
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

[jira] Commented: (SUREFIRE-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/SUREFIRE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111830
 ] 

Tuomas Kiviaho commented on SUREFIRE-364:
-

The key difference between previous snapshot is version range usage in the 
parent pom:

surefire-2.4-20070827.165719-19.pom
 dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-archiver/artifactId
version1.0-alpha-7/version
  /dependency

surefire-2.4-20071027.013951-20.pom
  dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-archiver/artifactId
version[1.0-alpha-10-SNAPSHOT]/version
  /dependency   

For me maven fails also to load the 1.0-alpha-10-SNAPSHOT to local repository.

 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
 ---

 Key: SUREFIRE-364
 URL: http://jira.codehaus.org/browse/SUREFIRE-364
 Project: Maven Surefire
  Issue Type: Bug
  Components: plugin
Affects Versions: 2.4
Reporter: Matt Read
Assignee: Olivier Lamy
Priority: Blocker

 Previously stable build now reports this:
 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact.
 27-Oct-2007 12:04:15
 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 
 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT]
 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null
 27-Oct-2007 12:04:15
 27-Oct-2007 12:04:15 from the specified remote repositories:
 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases 
 (http://maven.catlin.com/#8203;maven2-repo/#8203;releases),
 27-Oct-2007 12:04:15 Apache Snapshots 
 (http://people.apache.org/#8203;repo/#8203;m2-snapshot-repository),
 27-Oct-2007 12:04:15 stat-scm-sourceforge 
 (http://stat-scm.sourceforge.net/#8203;maven2),
 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots 
 (http://maven.catlin.com/#8203;maven2-repo/#8203;snapshots),
 27-Oct-2007 12:04:15 central (http://repo1.maven.org/#8203;maven2),
 27-Oct-2007 12:04:15 codehaus.snapshots 
 (http://snapshots.repository.codehaus.org),
 27-Oct-2007 12:04:15 apache.snapshots 
 (http://people.apache.org/#8203;repo/#8203;m2-snapshot-repository),
 27-Oct-2007 12:04:15 Codehaus Snapshots 
 (http://snapshots.repository.codehaus.org/#8203
 27-Oct-2007 12:04:15 

-- 
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

[jira] Commented: (MWAR-104) handle zip dependencies in war plugin

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MWAR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107022
 ] 

Tuomas Kiviaho commented on MWAR-104:
-

Thanks in advance,

I hope this clarifies the remark a bit. Zip overlays a.k.a zip dependencies as 
overlays could be disabled by default for backward compatibility, but enabling 
it isn't in my opinion ideal if there is a zipOverlays=true/false property. 
What about other overlays in the future (tar.gz etc. whatever ArchiveManager 
can handle). There is currently at least 
dependentWarIncludes/dependentWarExcludes configuration parameters suffering 
from similar tight coupling with the packaging in hand. Something like 
overlayTypes=The comma separated list of types to overlay in the WAR. Default 
is 'war'. could be generic enough and gives possibilities to tie 
ArchiveManager in to implementation making overlaying type agnostic.. For me 
choosing the most generic configuration approach in the big picture is more 
important than just having the patch applied, but having a working patch would 
be highly appreciated.

 handle zip dependencies in war plugin
 -

 Key: MWAR-104
 URL: http://jira.codehaus.org/browse/MWAR-104
 Project: Maven 2.x War Plugin
  Issue Type: Improvement
 Environment: all
Reporter: Olivier Lamy
Assignee: Stephane Nicoll
 Fix For: 2.1-alpha-1

 Attachments: foobar.zip, MWAR-104


 As MNG-1683 has been applied, the zip artifact must be handled in the war 
 plugin.

-- 
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

[jira] Commented: (MWAR-104) handle zip dependencies in war plugin

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MWAR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106048
 ] 

Tuomas Kiviaho commented on MWAR-104:
-

Codebase has changed quite dramatically and this patch doesn't apply well 
anymore.

 handle zip dependencies in war plugin
 -

 Key: MWAR-104
 URL: http://jira.codehaus.org/browse/MWAR-104
 Project: Maven 2.x War Plugin
  Issue Type: Improvement
 Environment: all
Reporter: Olivier Lamy
 Attachments: foobar.zip, MWAR-104


 As MNG-1683 has been applied, the zip artifact must be handled in the war 
 plugin.

-- 
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

[jira] Commented: (MWAR-104) handle zip dependencies in war plugin

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MWAR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106057
 ] 

Tuomas Kiviaho commented on MWAR-104:
-

I considered doing exactly the same to the patch myself, but the change was 
just too radical for me to fully comprehend at the moment (although I liked the 
improved quality). I'd be happy if you could provide at least patch for now to 
re-enable Olivier's zip support. 2.1-alpha-1 feels like being too far away. 
Enablement/disablement of zip overlays could be the answer, but that smells big 
time at least if done simply by a property.

 handle zip dependencies in war plugin
 -

 Key: MWAR-104
 URL: http://jira.codehaus.org/browse/MWAR-104
 Project: Maven 2.x War Plugin
  Issue Type: Improvement
 Environment: all
Reporter: Olivier Lamy
Assignee: Stephane Nicoll
 Fix For: 2.1-alpha-1

 Attachments: foobar.zip, MWAR-104


 As MNG-1683 has been applied, the zip artifact must be handled in the war 
 plugin.

-- 
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

[jira] Commented: (MRELEASE-124) Impossible to depend on a deployed snapshot

[Tuomas Kiviaho (JIRA)]

[ 
http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104908
 ] 

Tuomas Kiviaho commented on MRELEASE-124:
-

John Casey has written a plugin that could automate unique versioning 
http://www.commonjava.org/~jdcasey/maven-misc/plugins/snapshot-pin-maven-plugin.zip.
 Blog at http://blogs.sonatype.com/john/2007/08/14/1187117747444.html. Wether 
this plugin cover parent version of pom also along with dependencies is unknown 
to me.

 Impossible to depend on a deployed snapshot
 ---

 Key: MRELEASE-124
 URL: http://jira.codehaus.org/browse/MRELEASE-124
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Mike Perham
Priority: Critical
 Attachments: 
 maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, 
 maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, 
 releasePluginIgnoreSnapshot.patch, ReleaseUtils.rev552741.patch


 I have a SNAPSHOT of the war plugin that I built and deployed to fix a 
 blocker for us (MWAR-39) that has not been released.  In my POM, I refer to 
 it like this:
 build
   plugins
 plugin
   artifactIdmaven-war-plugin/artifactId
   version2.0.1-20060525.222101-1/version
 I did this specifically so the release plugin would not think it was a 
 SNAPSHOT so I could release the module.  But when I do try to release, I get 
 this error:
 [INFO] Can't release project due to non released dependencies :
 
 org.apache.maven.plugins:maven-war-plugin:maven-plugin:2.0.1-SNAPSHOT:runtime
 in project 'UDDI WAR' (com.webify.fabric:fabric-uddi-web:war:1.1.0-SNAPSHOT)
 This is because in ArtifactUtils.isSnapshot, it specifically disallows the 
 version pattern created by the deploy plugin.
 So consider my usecase: I'm Joe Corporate, a user who needs a war bug fix in 
 their build process ASAP.  I build and deploy the latest war plugin to my 
 internal repo and reference that explicit timestamp version in my build 
 process.  Now I can understand why you disallow this because if I try to 
 build outside of our corporate walls, it will not work.  But I can't use the 
 release plugin to release either because it requires me to check the modified 
 POMs into my SCM and the war plugin is in Apache's SCM and I can't check into 
 it.
 There's only two hack workarounds I can think of: 1) explicitly reversion the 
 jar to not include SNAPSHOT or the specific timestamp pattern. 2) Check the 
 war plugin into our own SCM and release from there, effectively forking the 
 code.
 Your thoughts?  How can we fix bugs in the build process locally and still 
 use the release plugin?

-- 
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

[jira] Created: (MDEPLOY-56) Parent version ignored when deploying file with existing pom

[Tuomas Kiviaho (JIRA)]

Parent version ignored when deploying file with existing pom


 Key: MDEPLOY-56
 URL: http://jira.codehaus.org/browse/MDEPLOY-56
 Project: Maven 2.x Deploy Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Tuomas Kiviaho
 Attachments: maven-deploy-plugin.rev553111.patch

Pom parent version is not used as source for version in deploy-file although 
deploy allows versionless deployment.

-- 
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

[jira] Updated: (MRELEASE-124) Impossible to depend on a deployed snapshot

[Tuomas Kiviaho (JIRA)]

 [ 
http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MRELEASE-124:


Attachment: maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch

Patched against revision 552741

 Impossible to depend on a deployed snapshot
 ---

 Key: MRELEASE-124
 URL: http://jira.codehaus.org/browse/MRELEASE-124
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Mike Perham
Priority: Critical
 Attachments: 
 maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, 
 maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, 
 releasePluginIgnoreSnapshot.patch


 I have a SNAPSHOT of the war plugin that I built and deployed to fix a 
 blocker for us (MWAR-39) that has not been released.  In my POM, I refer to 
 it like this:
 build
   plugins
 plugin
   artifactIdmaven-war-plugin/artifactId
   version2.0.1-20060525.222101-1/version
 I did this specifically so the release plugin would not think it was a 
 SNAPSHOT so I could release the module.  But when I do try to release, I get 
 this error:
 [INFO] Can't release project due to non released dependencies :
 
 org.apache.maven.plugins:maven-war-plugin:maven-plugin:2.0.1-SNAPSHOT:runtime
 in project 'UDDI WAR' (com.webify.fabric:fabric-uddi-web:war:1.1.0-SNAPSHOT)
 This is because in ArtifactUtils.isSnapshot, it specifically disallows the 
 version pattern created by the deploy plugin.
 So consider my usecase: I'm Joe Corporate, a user who needs a war bug fix in 
 their build process ASAP.  I build and deploy the latest war plugin to my 
 internal repo and reference that explicit timestamp version in my build 
 process.  Now I can understand why you disallow this because if I try to 
 build outside of our corporate walls, it will not work.  But I can't use the 
 release plugin to release either because it requires me to check the modified 
 POMs into my SCM and the war plugin is in Apache's SCM and I can't check into 
 it.
 There's only two hack workarounds I can think of: 1) explicitly reversion the 
 jar to not include SNAPSHOT or the specific timestamp pattern. 2) Check the 
 war plugin into our own SCM and release from there, effectively forking the 
 code.
 Your thoughts?  How can we fix bugs in the build process locally and still 
 use the release plugin?

-- 
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

[jira] Updated: (MRELEASE-124) Impossible to depend on a deployed snapshot

[Tuomas Kiviaho (JIRA)]

 [ 
http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MRELEASE-124:


Attachment: maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch

 Impossible to depend on a deployed snapshot
 ---

 Key: MRELEASE-124
 URL: http://jira.codehaus.org/browse/MRELEASE-124
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Mike Perham
Priority: Critical
 Attachments: 
 maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, 
 maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, 
 releasePluginIgnoreSnapshot.patch


 I have a SNAPSHOT of the war plugin that I built and deployed to fix a 
 blocker for us (MWAR-39) that has not been released.  In my POM, I refer to 
 it like this:
 build
   plugins
 plugin
   artifactIdmaven-war-plugin/artifactId
   version2.0.1-20060525.222101-1/version
 I did this specifically so the release plugin would not think it was a 
 SNAPSHOT so I could release the module.  But when I do try to release, I get 
 this error:
 [INFO] Can't release project due to non released dependencies :
 
 org.apache.maven.plugins:maven-war-plugin:maven-plugin:2.0.1-SNAPSHOT:runtime
 in project 'UDDI WAR' (com.webify.fabric:fabric-uddi-web:war:1.1.0-SNAPSHOT)
 This is because in ArtifactUtils.isSnapshot, it specifically disallows the 
 version pattern created by the deploy plugin.
 So consider my usecase: I'm Joe Corporate, a user who needs a war bug fix in 
 their build process ASAP.  I build and deploy the latest war plugin to my 
 internal repo and reference that explicit timestamp version in my build 
 process.  Now I can understand why you disallow this because if I try to 
 build outside of our corporate walls, it will not work.  But I can't use the 
 release plugin to release either because it requires me to check the modified 
 POMs into my SCM and the war plugin is in Apache's SCM and I can't check into 
 it.
 There's only two hack workarounds I can think of: 1) explicitly reversion the 
 jar to not include SNAPSHOT or the specific timestamp pattern. 2) Check the 
 war plugin into our own SCM and release from there, effectively forking the 
 code.
 Your thoughts?  How can we fix bugs in the build process locally and still 
 use the release plugin?

-- 
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

[jira] Updated: (MRELEASE-124) Impossible to depend on a deployed snapshot

[Tuomas Kiviaho (JIRA)]

 [ 
http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tuomas Kiviaho updated MRELEASE-124:


Attachment: ReleaseUtils.rev552741.patch

 Impossible to depend on a deployed snapshot
 ---

 Key: MRELEASE-124
 URL: http://jira.codehaus.org/browse/MRELEASE-124
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Mike Perham
Priority: Critical
 Attachments: 
 maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, 
 maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, 
 releasePluginIgnoreSnapshot.patch, ReleaseUtils.rev552741.patch


 I have a SNAPSHOT of the war plugin that I built and deployed to fix a 
 blocker for us (MWAR-39) that has not been released.  In my POM, I refer to 
 it like this:
 build
   plugins
 plugin
   artifactIdmaven-war-plugin/artifactId
   version2.0.1-20060525.222101-1/version
 I did this specifically so the release plugin would not think it was a 
 SNAPSHOT so I could release the module.  But when I do try to release, I get 
 this error:
 [INFO] Can't release project due to non released dependencies :
 
 org.apache.maven.plugins:maven-war-plugin:maven-plugin:2.0.1-SNAPSHOT:runtime
 in project 'UDDI WAR' (com.webify.fabric:fabric-uddi-web:war:1.1.0-SNAPSHOT)
 This is because in ArtifactUtils.isSnapshot, it specifically disallows the 
 version pattern created by the deploy plugin.
 So consider my usecase: I'm Joe Corporate, a user who needs a war bug fix in 
 their build process ASAP.  I build and deploy the latest war plugin to my 
 internal repo and reference that explicit timestamp version in my build 
 process.  Now I can understand why you disallow this because if I try to 
 build outside of our corporate walls, it will not work.  But I can't use the 
 release plugin to release either because it requires me to check the modified 
 POMs into my SCM and the war plugin is in Apache's SCM and I can't check into 
 it.
 There's only two hack workarounds I can think of: 1) explicitly reversion the 
 jar to not include SNAPSHOT or the specific timestamp pattern. 2) Check the 
 war plugin into our own SCM and release from there, effectively forking the 
 code.
 Your thoughts?  How can we fix bugs in the build process locally and still 
 use the release plugin?

-- 
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

[jira] Created: (MSUREFIRE-175) trimStackTrace=true trims caused by: sections complelely away

[Tuomas Kiviaho (JIRA)]

trimStackTrace=true trims caused by: sections complelely away
---

 Key: MSUREFIRE-175
 URL: http://jira.codehaus.org/browse/MSUREFIRE-175
 Project: Maven 2.x Surefire Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Tuomas Kiviaho
Priority: Minor


Description of the parameter 'trimStackTrace' states trim the stack trace in 
the reports to just the lines within the test which it does nicely on the 
stacktrace, but there may be additional information in the initial cause that 
doesn't fall to the category not within the test. Without trimming these 
caused by: lines of course show up, but so does the overly long test 
framework part of the stacktrace.

-- 
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

[jira] Created: (MNGECLIPSE-196) Dependency with ejb type doesn't appead in classpath container at all when dependent project is located at Eclipse workspace

[Tuomas Kiviaho (JIRA)]

Dependency with ejb type doesn't appead in classpath container at all when 
dependent project is located at Eclipse workspace


 Key: MNGECLIPSE-196
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-196
 Project: Maven 2.x Extension for Eclipse
  Issue Type: Bug
  Components: Dependency Resolver
Affects Versions: 0.0.10
Reporter: Tuomas Kiviaho


The user experience with typed dependencies differs from previous releases that 
didn't include workspace resolving. I've only verified that type ejb behaves as 
described below but I could imagine that other types and propably classified 
dependencies as well will behave similarly.

Console contains following line:
artifact:pom:version: resolved to Eclipse workspace - found at 
workspace\project\pom.xml
This leads to The import class cannot be resolved error on every single 
class reference pointing to dependent workspace project and these classes do 
not compile. The whole dependent project is missing from the classpath 
container. The previous version of the plugin did resolve the dependency from 
repository without any problems whatsoever.

When type specification is removed the result is:
artifact:jar:version: resolved to Eclipse workspace - found at 
workspace\project\pom.xml
Now references appear to be ok, but the pom.xml is of course not correct 
anymore. Claspath container contains the dependent project, but since the 
workspace projects do not fold open as the repository dependencies I can't tell 
wether or not the hack is really working 100%. It would be great if there is a 
way to make workspace project dependencies to fold open at least as far as 
seeing the source folders as we do  under Debug As... and on Sources panel.

-- 
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

[jira] Updated: (MNGECLIPSE-157) Runtime exceptions in embedder should be caught and logged by the plugin.

[Tuomas Kiviaho (JIRA)]

 [ http://jira.codehaus.org/browse/MNGECLIPSE-157?page=all ]

Tuomas Kiviaho updated MNGECLIPSE-157:
--

Attachment: NullPointerException.jpg

Eclipse Webtools Editor cranking up.

1.8.2006 11:15:47 EEST: [DEBUG] test:test:jar:0.0.1 (selected for null)
1.8.2006 11:15:47 EEST: [DEBUG]   jaxen:jaxen:jar:1.1-beta-9:compile (selected 
for compile)
1.8.2006 11:15:47 EEST: [DEBUG] jaxen:jaxen:jar:1.1-beta-6:compile (removed 
- causes a cycle in the graph)
1.8.2006 11:15:47 EEST: [DEBUG] dom4j:dom4j:jar:1.6.1:compile (selected for 
compile)
1.8.2006 11:15:47 EEST: [DEBUG] jaxen:jaxen:jar:1.0-FCS:compile (removed - 
causes a cycle in the graph)
1.8.2006 11:15:47 EEST: [DEBUG] jdom:jdom:jar:1.0:compile (selected for 
compile)
1.8.2006 11:15:47 EEST: [DEBUG] xom:xom:jar:1.0b3:compile (selected for 
compile)
1.8.2006 11:15:47 EEST: [DEBUG]   xerces:xercesImpl:jar:2.2.1:compile 
(applying version: 2.7.1;applying scope: system)
1.8.2006 11:15:47 EEST: [DEBUG]   xerces:xercesImpl:jar:2.7.1:system 
(selected for system)
1.8.2006 11:15:47 EEST: [DEBUG]   xalan:xalan:jar:2.6.0:compile (selected 
for compile)
1.8.2006 11:15:47 EEST: [DEBUG] While downloading xml-apis:xml-apis:2.0.2
  This artifact has been relocated to xml-apis:xml-apis:1.0.b2.


 Runtime exceptions in embedder should be caught and logged by the plugin.
 -

 Key: MNGECLIPSE-157
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-157
 Project: Maven 2.x Extension for Eclipse
  Issue Type: Wish
  Components: Dependency Resolver
Affects Versions: 0.0.9
Reporter: Tuomas Kiviaho
 Assigned To: Eugene Kuleshov
 Attachments: child.pom, NullPointerException.jpg, parent.pom


 When inserting a dependency (in my case jaxen) which has a dependency of it's 
 own (xercesImpl) to a project that has a parent which has the same dependency 
 (xercesImpl) already declared (scope was system) a NullPointerException 
 emerges to the WTP xml editors topmost row and classpath container doesn't 
 show anymore any of the dependencies. Workspace log file and console did not 
 show any anomalities. 
 With standalone maven everything work just fine, but with embedder I managed 
 to pull out a following stacktrace
 java.lang.NullPointerException
   at 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:82)
   at 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63)
   at 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:233)
   at 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211)
   at 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:192)
   at 
 org.apache.maven.project.DefaultMavenProjectBuilder.buildWithDependencies(DefaultMavenProjectBuilder.java:342)
   at 
 org.apache.maven.project.DefaultMavenProjectBuilder.buildWithDependencies(DefaultMavenProjectBuilder.java:289)
   at 
 org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies(MavenEmbedder.java:277)
   at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:53)
 This seemed very familiar and here's a link 
 http://jira.codehaus.org/browse/MPIR-2 to another project. This issue has 
 been around for quite a while and despite the status FIXED, I don't think 
 this actually is fixed but at least it has been patched couple of times. 
 Workaround: Add an exclusion clause to the new dependency if you have it's 
 dependencies already declared in parent.
 What is left for this project could be a more informative way to express 
 runtime exceptions/errors when embedder fails to do so. NullPointerException 
 in the xml editor gives a wrong expression where the problem actually 
 resides. I'd prefer m2 console over eclipse workspace log. 

-- 
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

[jira] Created: (MNGECLIPSE-100) M2 external tool workplace refreshing is not working

[Tuomas Kiviaho (JIRA)]

M2 external tool workplace refreshing is not working


 Key: MNGECLIPSE-100
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-100
 Project: Maven 2.x Extension for Eclipse
Type: Bug

  Components: Maven Launcher  
Reporter: Tuomas Kiviaho
 Assigned to: Eugene Kuleshov 
Priority: Minor


There seems to be a similar 'refresh resources upon completion' checkbox as 
with the general purpose external tool that is shipped with Eclipse. If I use 
command line maven though the general purpose external tool, the workplace 
subfolders get refreshed based on selected filters, but when using more 
sophisticated maven embedded nothing seems happen and resources will be left 
out of sync. This not a showstopper for me, but merely a really annoying lack 
of functionality.


-- 
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