from:"Milos Kleint \(JIRA\)"

[jira] (MNG-5767) project-specific default jvm options and command line parameters

2015-02-25 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-5767:
---

how will it work for multi module projects where just a submodule is being 
build? will the options be only picked up on the root project build?

 project-specific default jvm options and command line parameters
 

 Key: MNG-5767
 URL: https://jira.codehaus.org/browse/MNG-5767
 Project: Maven
  Issue Type: Improvement
Reporter: Igor Fedorenko
Assignee: Igor Fedorenko
 Fix For: 3.2.6


 Some of the projects builds I work on require special jvm options, like 
 minimal -Xmx value, and specific command line parameters, like --builder. 
 Currently, I have to manually configure these every time run the build, which 
 is rather annoying and error prone. This manual configuration also makes it 
 harder for new or external developers to build the projects and many simply 
 give up trying after mvn package does not work from the first try.
 This enhancement request proposes to introduce two new optional configuration 
 files .mvn/jvm.config and .mvn/maven.config, located at the base directory of 
 project source tree. If present, these files will provide default jvm and 
 maven options. Because these files are part of the project source tree, they 
 will be present in all project checkouts and will be automatically used every 
 time the project is build.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSITE-640) Maven searches only central repository for imported dependencies

2014-12-11 Thread Milos Kleint (JIRA)


[ 
https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358912#comment-358912
 ] 

Milos Kleint commented on MSITE-640:


Can someone file an issue against MNG along with the suggested patch? I suspect 
the core developer don't look in MSITE too frequently.

 Maven searches only central repository for imported dependencies
 

 Key: MSITE-640
 URL: https://jira.codehaus.org/browse/MSITE-640
 Project: Maven Site Plugin
  Issue Type: Bug
  Components: Maven 3
Affects Versions: 3.0
 Environment: Windows 7
Reporter: Markus Tippmann
 Attachments: stacktrace.txt


 We are using dependencyManagement with import scope like described here:
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
 Problem occurs only at site generation, not at build time, where it works 
 perfectly. 
 The site plugin tries to find the imported artifacts, but searches only the 
 central repository and ignores the repositories in settings.xml 
 configuration. Mirror settings work, if central is mirrored, but 
 dependencies need to be resolved from two repositories, so one mirror does 
 not help here.
 I try to attach the relevant parts of the stacktrace. 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MENFORCER-213) big performance degradation after upgrade from 1.1 to 1.3.1

2014-12-07 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MENFORCER-213:
---

Attachment: enforcer-1.3.1.nps
enforcer-1.1.nps

I'm attaching the actual profiler snapshots that I somehow forgot to attach 
last time.

 big performance degradation after upgrade from 1.1 to 1.3.1
 ---

 Key: MENFORCER-213
 URL: https://jira.codehaus.org/browse/MENFORCER-213
 Project: Maven Enforcer Plugin
  Issue Type: Improvement
  Components: Plugin
Affects Versions: 1.3.1
 Environment: mvn 3.0.5, MacOsX yosemite, SSD disk
Reporter: Milos Kleint
 Attachments: 2014-11-13_0851.png, 2014-11-13_0852.png, 
 enforcer-1.1.nps, enforcer-1.3.1.nps


 mvn validate on our big codebase (142 modules) with 1.1 enforcer - 30.090s
 mvn validate with (1.3.1 enforcer) - 2:20.074s
 only enforcer plugin executions happen, bannedDependencies rules
 both times are on my laptop with profiler snapshot collection turned on.
 with the 1.3.1 it's obvious that the majority of time is indeed spent in the 
 dependency graph codebase that is missing from 1.1.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MENFORCER-213) big performance degradation after upgrade from 1.1 to 1.3.1

2014-12-07 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MENFORCER-213:
---

Attachment: enforcer-1.3.1.png
enforcer-1.1.png

and the 2 updated screenshots that show the same methods in 1.1 and 1.3.1. 
Please note that the atlassian specific rule is the same as  the regular ban 
snapshots rule but bans also milestones and release candidate dependencies.

But it should be obvious from the snapshots that no excessive time is spent in 
atlassian specific rule code, but in the shared 
AbstractBanDependencies.getDependenciesToCheck() call.

 big performance degradation after upgrade from 1.1 to 1.3.1
 ---

 Key: MENFORCER-213
 URL: https://jira.codehaus.org/browse/MENFORCER-213
 Project: Maven Enforcer Plugin
  Issue Type: Improvement
  Components: Plugin
Affects Versions: 1.3.1
 Environment: mvn 3.0.5, MacOsX yosemite, SSD disk
Reporter: Milos Kleint
 Attachments: 2014-11-13_0851.png, 2014-11-13_0852.png, 
 enforcer-1.1.nps, enforcer-1.1.png, enforcer-1.3.1.nps, enforcer-1.3.1.png


 mvn validate on our big codebase (142 modules) with 1.1 enforcer - 30.090s
 mvn validate with (1.3.1 enforcer) - 2:20.074s
 only enforcer plugin executions happen, bannedDependencies rules
 both times are on my laptop with profiler snapshot collection turned on.
 with the 1.3.1 it's obvious that the majority of time is indeed spent in the 
 dependency graph codebase that is missing from 1.1.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5568) ComparableVersion's breaks contract for Comparable, in some edgecases the comparisons are not transitive

2014-11-28 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-5568:
---

I'm not following the question. I have no idea how the issue is to be fixed. 
I've just created a testcase that demonstrates the problem. Once you fix it, 
the test case will pass.

 ComparableVersion's breaks contract for Comparable, in some edgecases the 
 comparisons are not transitive
 

 Key: MNG-5568
 URL: https://jira.codehaus.org/browse/MNG-5568
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 3.0.5
Reporter: Milos Kleint
Priority: Critical
 Attachments: ComparableVersion.patch


 if ComparableVersion A  B and B  C, then it's required that A  C. In the 
 attached test patch, I'm demonstrating a case where it's failing. Please note 
 that the situation is not that rare, please see issues 
 https://netbeans.org/bugzilla/show_bug.cgi?id=226100 and 
 https://netbeans.org/bugzilla/show_bug.cgi?id=240845 at netbeans.org and 
 https://jira.codehaus.org/browse/MPIR-247



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MENFORCER-213) big performance degradation after upgrade from 1.1 to 1.3.1

2014-11-12 Thread Milos Kleint (JIRA)

Milos Kleint created MENFORCER-213:
--

 Summary: big performance degradation after upgrade from 1.1 to 
1.3.1
 Key: MENFORCER-213
 URL: https://jira.codehaus.org/browse/MENFORCER-213
 Project: Maven Enforcer Plugin
  Issue Type: Bug
  Components: Plugin
Affects Versions: 1.3.1
 Environment: mvn 3.0.5, MacOsX yosemite, SSD disk
Reporter: Milos Kleint
 Attachments: 2014-11-13_0851.png, 2014-11-13_0852.png

mvn validate on our big codebase (142 modules) with 1.1 enforcer - 30.090s
mvn validate with (1.3.1 enforcer) - 2:20.074s
only enforcer plugin executions happen, bannedDependencies rules

both times are on my laptop with profiler snapshot collection turned on.
with the 1.3.1 it's obvious that the majority of time is indeed spent in the 
dependency graph codebase that is missing from 1.1.





--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5640) AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases

2014-05-30 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-5640:
---

related to MNG-5479?

 AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
 --

 Key: MNG-5640
 URL: https://jira.codehaus.org/browse/MNG-5640
 Project: Maven 2  3
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 3.2, 3.2.1
Reporter: Tamás Cservenák
 Attachments: aftersessionend.zip


 It seems that {{AbstractMavenLifecycleParticipant#afterSessionEnd}} is not 
 invoked in some cases, at least one case for sure: when the build fails.
 Reproduce case:
 1. unzip the attached project
 2. build it but skip tests {{mvn clean install -Dtest=void 
 -DfailIfNoTests=false}}
 3. install the resulting jar in /lib/ext of your Maven 3.2.1
 4. with JAR installed in Maven, build it again with skipped tests
 5. verify console output (both {{afterProjectsRead OK}} and {{afterSessionEnd 
 OK}} are printed on console)
 6. with JAR installed in Maven, build it again with tests (there is one UT 
 that always fails).
 6. console output contains only {{afterProjectsRead OK}}, but afterSessionEnd 
 method is NOT invoked.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MINDEXER-78) updating a local index from remote one fails after downloading properties file

2014-04-09 Thread Milos Kleint (JIRA)

Milos Kleint created MINDEXER-78:


 Summary: updating a local index from remote one fails after 
downloading properties file
 Key: MINDEXER-78
 URL: https://jira.codehaus.org/browse/MINDEXER-78
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 5.1.1
 Environment: netbeans IDE 7.4, 8.0, jdk 7
Reporter: Milos Kleint
 Attachments: client-nexus-maven-repository-index-updater.properties, 
server-nexus-maven-repository-index.properties.txt

please see:
https://netbeans.org/bugzilla/show_bug.cgi?id=241297

using maven indexer 5.1.1 within netbeans, when attempting to update the 
existing local index with the updated (new content) remote repository, the 
properties file appears to be downloaded but not the index diff itself.

see attached properties files



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4559) MAVEN_OPTS are incorrectly resolved in Unix

2014-03-13 Thread Milos Kleint (JIRA)


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

Milos Kleint reopened MNG-4559:
---


It appears to be still relevant in 3.0.5 at least. Please refer to this 
netbeans issue: https://netbeans.org/bugzilla/show_bug.cgi?id=242638

Steps to reproduce:
1. create a simple war project.
2. Download jrebel from http://zeroturnaround.com/software/jrebel/download/ and 
install it into a path with space
3. set MAVEN_OPTS environment variable to point the jrebel.jar.. eg.
MAVEN_OPTS=-javaagent:/Users/mkleint/space in path/jrebel/jrebel.jar
How to quote the value is open question here.
4. run mvn jetty:run and see in the output if the java agent got properly 
integrated.

 MAVEN_OPTS are incorrectly resolved in Unix
 ---

 Key: MNG-4559
 URL: https://jira.codehaus.org/browse/MNG-4559
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 2.2.1
 Environment: OS: Linux, 2.6.32-11-generic, amd64.
 Java: 1.6.0_17
Reporter: Maxim Podkolzine
 Fix For: Issues to be reviewed for 3.x


 I'm trying to pass a quoted parameter through MAVEN_OPTS, e.g.
 MAVEN_OPTS=-Dfoo='bar baz'
 As a result the quotes are not resolved, causing Java failure:
 Exception in thread main java.lang.NoClassDefFoundError: baz'
 ...
 I couldn't figure out a way to make it work.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4559) MAVEN_OPTS are incorrectly resolved in Unix

2014-03-13 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MNG-4559:
--

Environment: 
OS: Linux, 2.6.32-11-generic, amd64.
Java: 1.6.0_17
Also Operating System = Mac OS X version 10.9.2 running on x86_64
Java; VM; Vendor = 1.7.0_51

  was:
OS: Linux, 2.6.32-11-generic, amd64.
Java: 1.6.0_17


 MAVEN_OPTS are incorrectly resolved in Unix
 ---

 Key: MNG-4559
 URL: https://jira.codehaus.org/browse/MNG-4559
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 2.2.1, 3.0.5
 Environment: OS: Linux, 2.6.32-11-generic, amd64.
 Java: 1.6.0_17
 Also Operating System = Mac OS X version 10.9.2 running on x86_64
 Java; VM; Vendor = 1.7.0_51
Reporter: Maxim Podkolzine

 I'm trying to pass a quoted parameter through MAVEN_OPTS, e.g.
 MAVEN_OPTS=-Dfoo='bar baz'
 As a result the quotes are not resolved, causing Java failure:
 Exception in thread main java.lang.NoClassDefFoundError: baz'
 ...
 I couldn't figure out a way to make it work.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4559) MAVEN_OPTS are incorrectly resolved in Unix

2014-03-13 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MNG-4559:
--

Fix Version/s: (was: Issues to be reviewed for 3.x)

 MAVEN_OPTS are incorrectly resolved in Unix
 ---

 Key: MNG-4559
 URL: https://jira.codehaus.org/browse/MNG-4559
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 2.2.1, 3.0.5
 Environment: OS: Linux, 2.6.32-11-generic, amd64.
 Java: 1.6.0_17
Reporter: Maxim Podkolzine

 I'm trying to pass a quoted parameter through MAVEN_OPTS, e.g.
 MAVEN_OPTS=-Dfoo='bar baz'
 As a result the quotes are not resolved, causing Java failure:
 Exception in thread main java.lang.NoClassDefFoundError: baz'
 ...
 I couldn't figure out a way to make it work.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4559) MAVEN_OPTS are incorrectly resolved in Unix

2014-03-13 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MNG-4559:
--

Affects Version/s: 3.0.5

 MAVEN_OPTS are incorrectly resolved in Unix
 ---

 Key: MNG-4559
 URL: https://jira.codehaus.org/browse/MNG-4559
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 2.2.1, 3.0.5
 Environment: OS: Linux, 2.6.32-11-generic, amd64.
 Java: 1.6.0_17
Reporter: Maxim Podkolzine

 I'm trying to pass a quoted parameter through MAVEN_OPTS, e.g.
 MAVEN_OPTS=-Dfoo='bar baz'
 As a result the quotes are not resolved, causing Java failure:
 Exception in thread main java.lang.NoClassDefFoundError: baz'
 ...
 I couldn't figure out a way to make it work.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MINDEXER-77) Upgrade to Lucene 4.1

2014-02-18 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MINDEXER-77:
-

Patch Submitted: Yes

 Upgrade to Lucene 4.1
 -

 Key: MINDEXER-77
 URL: https://jira.codehaus.org/browse/MINDEXER-77
 Project: Maven Indexer
  Issue Type: Improvement
Reporter: Emmanuel Hugonnet

 Lucene has made a great effort in being quicker and smaller in the 4.x 
 versions.
 Moving to this new version would make maven indexer better



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (SUREFIRE-1061) wrong test output generation, prevents parsing of generated xml file

2014-02-11 Thread Milos Kleint (JIRA)

Milos Kleint created SUREFIRE-1061:
--

 Summary: wrong test output generation, prevents parsing of 
generated xml file
 Key: SUREFIRE-1061
 URL: https://jira.codehaus.org/browse/SUREFIRE-1061
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.16
Reporter: Milos Kleint
Priority: Blocker
 Attachments: testcase.zip

please see attached sample project demonstrating the problem. This is a 
regression introduced in 2.16, likely by SUREFIRE-1020. originally reported at 
https://netbeans.org/bugzilla/show_bug.cgi?id=241649

when the test contains the following code
{code:java}
@Test
public void testMain() {
  System.out.println(blabla ]]);
assertTrue(false);
}
{code}

I get following output with these surefire versions (if below not readable, 
it's included with the sample project):
{noformat}
2.16 system-out![CDATA[blabla ![CDATA[
]]/system-out

2.15 system-outblabla ]]gt;
/system-out

2.14 system-outblabla ]]
/system-out

2.13 system-outblabla ]]gt;
/system-out
{noformat}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5568) ComparableVersion's breaks contract for Comparable, in some edgecases the comparisons are not transitive

2014-01-23 Thread Milos Kleint (JIRA)

Milos Kleint created MNG-5568:
-

 Summary: ComparableVersion's breaks contract for Comparable, in 
some edgecases the comparisons are not transitive
 Key: MNG-5568
 URL: https://jira.codehaus.org/browse/MNG-5568
 Project: Maven 2  3
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 3.0.5
Reporter: Milos Kleint
Priority: Critical
 Attachments: ComparableVersion.patch

if ComparableVersion A  B and B  C, then it's required that A  C. In the 
attached test patch, I'm demonstrating a case where it's failing. Please note 
that the situation is not that rare, please see issues 
https://netbeans.org/bugzilla/show_bug.cgi?id=226100 and 
https://netbeans.org/bugzilla/show_bug.cgi?id=240845 at netbeans.org and 
https://jira.codehaus.org/browse/MPIR-247

--
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] (MPIR-247) Comparison method violates its general contract! while generating site

2014-01-23 Thread Milos Kleint (JIRA)


[ 
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339963#comment-339963
 ] 

Milos Kleint commented on MPIR-247:
---

I've filed https://jira.codehaus.org/browse/MNG-5568 with a reproducible 
testcase

 Comparison method violates its general contract! while generating site
 

 Key: MPIR-247
 URL: https://jira.codehaus.org/browse/MPIR-247
 Project: Maven Project Info Reports Plugin
  Issue Type: Bug
  Components: dependency-management
Affects Versions: 2.4
 Environment: java version 1.7.0_04
 Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
 Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
 maven 3.0.4
Reporter: Mirek Hankus

 While generating site, I'm getting exception as follows.
 {code}
 message : Failed to execute goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project 
 netpr-aggregator: Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method 
 violates its general contract!
 cause : Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method 
 violates its general contract!
 Stack trace : 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on 
 project netpr-aggregator: Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method 
 violates its general contract!
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
   at 
 org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:601)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
   at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
   at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
   at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
   at hudson.remoting.Request$2.run(Request.java:326)
   at 
 hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:722)
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site 
 failed: Comparison method violates its general contract!
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
   ... 27 more
 Caused by: java.lang.IllegalArgumentException: Comparison method violates its 
 general contract!
   at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
   at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:453)
   at java.util.ComparableTimSort.mergeCollapse(ComparableTimSort.java:376)
   at java.util.ComparableTimSort.sort(ComparableTimSort.java:182)
   at

[jira] (ARCHETYPE-447) Advanced mapping between Eclipse problem level and Sonar violation

2013-10-02 Thread Milos Kleint (JIRA)


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

Milos Kleint closed ARCHETYPE-447.
--

Resolution: Won't Fix

closing as invalid

 Advanced mapping between Eclipse problem level and Sonar violation
 --

 Key: ARCHETYPE-447
 URL: https://jira.codehaus.org/browse/ARCHETYPE-447
 Project: Maven Archetype
  Issue Type: Improvement
Reporter: Samuli Saarinen
Priority: Minor

 There should be ability to map Sonar violations to different eclipse problem 
 levels as now it is basically all or nothing. Eg. I would like to map Sonar 
 Info - Eclipse Info and Sonar critical and blocker - Eclipse Error and 
 other Sonar violations as Eclipse Warning. Maybe even the possibility to map 
 Sonar info to Eclipse Ignore ( = do not show any marker).

--
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] (MSHARED-295) Non reliable killing of processes by CommandLineUtils

2013-09-10 Thread Milos Kleint (JIRA)


[ 
https://jira.codehaus.org/browse/MSHARED-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332602#comment-332602
 ] 

Milos Kleint commented on MSHARED-295:
--

I'm sure jenkins is already doing something in this area?

 Non reliable killing of processes by CommandLineUtils
 -

 Key: MSHARED-295
 URL: https://jira.codehaus.org/browse/MSHARED-295
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-shared-utils
Reporter: Andrey Klochkov

 CommandLineUtils is used in Maven-Surefire to start forks which execute 
 tests. It is a well known issue that sometimes child processes are not killed 
 correctly. This is a known limitation of JVM, and the only reliable way to 
 implement it would be platform specific.
 Bug report in Surefire JIRA:
 http://jira.codehaus.org/browse/SUREFIRE-773
 JVM bug report. It's Windows specific, but the problem exists on Linux and 
 OSX as well.
 http://bugs.sun.com/view_bug.do?bug_id=4770092
 I'm proposing either 1) to implement several platform specific 
 implementations of ProcessHook or 2) to make the mechanism of killing 
 processes extendable for clients of the library.

--
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] (SUREFIRE-1025) TestSetRunListener.testSetCompleted() should write files first before reporting the completion on console.

2013-08-28 Thread Milos Kleint (JIRA)

Milos Kleint created SUREFIRE-1025:
--

 Summary: TestSetRunListener.testSetCompleted() should write files 
first before reporting the completion on console.
 Key: SUREFIRE-1025
 URL: https://jira.codehaus.org/browse/SUREFIRE-1025
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.15
Reporter: Milos Kleint


TestSetRunListener.testSetCompleted() currently prints out the output to the 
console first and only then writes the report xml file. That's causing problems 
in situations when other tools parse the output and want to access the report 
file at the same time.
see issue https://netbeans.org/bugzilla/show_bug.cgi?id=227541

This issue is created to suggest the output to console should be the last thing 
done.

--
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-5479) ExecutionEvent.Type.SessionEnded omited when runtime exception thrown

2013-05-17 Thread Milos Kleint (JIRA)

Milos Kleint created MNG-5479:
-

 Summary: ExecutionEvent.Type.SessionEnded omited when runtime 
exception thrown
 Key: MNG-5479
 URL: https://jira.codehaus.org/browse/MNG-5479
 Project: Maven 2  3
  Issue Type: Bug
  Components: Embedding, IDEs
Affects Versions: 3.0.5, 3.0.4
Reporter: Milos Kleint
 Attachments: maven.patch

in LifecycleStarter.java the ExecutionEvent.Type.SessionStarted is always 
fired, but ExecutionEvent.Type.SessionEnded appears only be fired when in some 
cases, omitted in case of RuntimeException thrown. IMHO the event should be 
fired in finally {} block. See attached patch.

--
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-5059) --also-make-phase

2013-03-19 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-5059:
---

in some situations, even getting the other projects linked in reactor is 
enough, no phase has to be executed:

eg. mvn -pl mainProject -Dexec.args=-cp %classpath Main exec:exec 
currently puts the library project's local repository jars on cp but in some 
situations it would be preferable to have the target/classes folders included. 
That seems to be happening when you run mvn -am -pl compile phase, all compiles 
nicely without local repository jars.
-amp validate would be a nice workaround when this issue is implemented, but 
maybe we could get away without executing any phases? 

 

 --also-make-phase
 -

 Key: MNG-5059
 URL: https://jira.codehaus.org/browse/MNG-5059
 Project: Maven 2  3
  Issue Type: Improvement
  Components: Command Line
Affects Versions: 3.0.3
Reporter: Jesse Glick
Assignee: Jason van Zyl

 Background: 
 http://mail-archives.apache.org/mod_mbox/maven-dev/201104.mbox/%3Cincnbn$4kl$1...@dough.gmane.org%3E
 {{--also-make}} (with {{--projects}}) is useful, but suffers from the problem 
 that dependent projects are always built to the same goal/phase as the 
 selected project(s). That is fine for e.g. {{compile}} or {{install}}, but 
 not for e.g. {{test}} where you would only want to build {{compile}} (or 
 {{test-compile}}) for dependencies, not actually test them.
 Suggest a variant form of this parameter (say {{--also-make-phase}} / 
 {{-amp}}) which would accept a goal or phase to run on dependencies in place 
 of the regular arguments. For example, to run a unit test after making sure 
 all its dependencies have been (re-)compiled:
 {noformat}
 mvn -amp test-compile -pl testedmod test -Dtest=OneTest
 {noformat}
 or to run an (unpacked) web application after (re-)compiling libraries it 
 uses:
 {noformat}
 mvn -amp compile -pl webapp jetty:run
 {noformat}
 You might want to pass a goal rather than a phase, so the name could be 
 misleading, but I think that would be a rarer use case. Ditto passing 
 multiple goals/phases for the upstream projects.

--
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] (SUREFIRE-973) add properties to classpathDependencyExcludes and additionalClasspathElements parameters

2013-03-18 Thread Milos Kleint (JIRA)

Milos Kleint created SUREFIRE-973:
-

 Summary: add properties to classpathDependencyExcludes and 
additionalClasspathElements parameters
 Key: SUREFIRE-973
 URL: https://jira.codehaus.org/browse/SUREFIRE-973
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.14
Reporter: Milos Kleint
 Attachments: surefire.patch

currently classpathDependencyExcludes and additionalClasspathElements 
parameters don't have properties defined to declare on cmd line. The attached 
patch includes them.

I would like to use these properties in Netbeans. With multiple projects 
enabling Compile on Save feature, I would need these properties to replace 
outside project's jar artifacts from local repository with their project's 
output directory dynamically.

--
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] (SUREFIRE-973) add properties to classpathDependencyExcludes and additionalClasspathElements parameters

2013-03-18 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on SUREFIRE-973:
---

sure, one thing I noticed already is that the property is not working on maven 
2.x, is that a problem?


 add properties to classpathDependencyExcludes and additionalClasspathElements 
 parameters
 

 Key: SUREFIRE-973
 URL: https://jira.codehaus.org/browse/SUREFIRE-973
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.14
Reporter: Milos Kleint
 Fix For: 2.15

 Attachments: surefire.patch


 currently classpathDependencyExcludes and additionalClasspathElements 
 parameters don't have properties defined to declare on cmd line. The attached 
 patch includes them.
 I would like to use these properties in Netbeans. With multiple projects 
 enabling Compile on Save feature, I would need these properties to replace 
 outside project's jar artifacts from local repository with their project's 
 output directory dynamically.

--
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] (SUREFIRE-973) add properties to classpathDependencyExcludes and additionalClasspathElements parameters

2013-03-18 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on SUREFIRE-973:
---

I'm also having problems running the ITs on maven 2.2.1, is that expected? they 
seem to pass on 3.0.4. is that expected? the surefire plugin's prerequisite 
appears to be maven2.0.9/maven

 add properties to classpathDependencyExcludes and additionalClasspathElements 
 parameters
 

 Key: SUREFIRE-973
 URL: https://jira.codehaus.org/browse/SUREFIRE-973
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.14
Reporter: Milos Kleint
 Fix For: 2.15

 Attachments: surefire.patch


 currently classpathDependencyExcludes and additionalClasspathElements 
 parameters don't have properties defined to declare on cmd line. The attached 
 patch includes them.
 I would like to use these properties in Netbeans. With multiple projects 
 enabling Compile on Save feature, I would need these properties to replace 
 outside project's jar artifacts from local repository with their project's 
 output directory dynamically.

--
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-5331) JavaFX should be added to compilation classpath

2013-03-13 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-5331:
---

I believe the problem mentioned by Konstantin is that the javafx.jar expects 
native libs at some hardcoded relative path (as in the JDK/JRE) and without it 
will fail at runtime AFAIK.

 JavaFX should be added to compilation classpath
 ---

 Key: MNG-5331
 URL: https://jira.codehaus.org/browse/MNG-5331
 Project: Maven 2  3
  Issue Type: Wish
Reporter: Konstantin Solomatov

 Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include 
 them into classpath automatically.

--
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] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency

2013-03-13 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on SUREFIRE-968:
---

 @Kristian: do you know of any major third party tools that parse that output 
 (on stdout or in the txt file)?

Netbeans does for example to populate the JUnit window output.

 Test summary line does not indicate what was being run when using concurrency
 -

 Key: SUREFIRE-968
 URL: https://jira.codehaus.org/browse/SUREFIRE-968
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.14
 Environment: Ubuntu, JDK 7
Reporter: Jesse Glick
Priority: Minor

 When running multiple test suites in parallel, Surefire prints summaries of 
 ongoing test counts, but it is not at all clear which results are being 
 summarized. E.g. with {{forkCount=1C}}:
 {code:none}
 Running CoreJellyTest
 Running org.jvnet.hudson.main.AppTest
 Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
 Running org.jvnet.hudson.test.MemoryAssertTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
 Running org.jvnet.hudson.test.MockFolderTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
 Running hudson.bugs.DateConversionTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
 Running hudson.bugs.LoginRedirectTest
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
 Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
 Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
 â¦
 {code}
 It is impossible to tell which results correspond to which test, since there 
 is no way to know which test will finish first. At best you can guess based 
 on the number of test case methods known to be in each class.
 The {{Tests run}} summary line should give the suite name.

--
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] (MPIR-247) Comparison method violates its general contract! while generating site

2013-02-22 Thread Milos Kleint (JIRA)


[ 
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=320276#comment-320276
 ] 

Milos Kleint commented on MPIR-247:
---

related is this netbeans issue: 
http://netbeans.org/bugzilla/show_bug.cgi?id=226100
we use maven's ComparableVersion for sorting the nexus indexer results. It 
keeps on popping here and there, only with jdk 1.7. It would be probably easier 
to dump the dependency info in DependencyManagementRenderer than our code (the 
result can contain thousands of items, dependency list will be shorter).

I've never got hold of a reproducible scenario.

 Comparison method violates its general contract! while generating site
 

 Key: MPIR-247
 URL: https://jira.codehaus.org/browse/MPIR-247
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
Affects Versions: 2.4
 Environment: java version 1.7.0_04
 Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
 Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
 maven 3.0.4
Reporter: Mirek Hankus

 While generating site, I'm getting exception as follows.
 {code}
 message : Failed to execute goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project 
 netpr-aggregator: Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method 
 violates its general contract!
 cause : Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method 
 violates its general contract!
 Stack trace : 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on 
 project netpr-aggregator: Execution default-site of goal 
 org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method 
 violates its general contract!
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
   at 
 org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:601)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
   at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
   at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
   at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
   at hudson.remoting.Request$2.run(Request.java:326)
   at 
 hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:722)
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site 
 failed: Comparison method violates its general contract!
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
   ... 27 more
 Caused by: java.lang.IllegalArgumentException: Comparison method violates its 
 general contract!
   at

[jira] (MINDEXER-63) NullPointerException at org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher

2012-11-17 Thread Milos Kleint (JIRA)


[ 
https://jira.codehaus.org/browse/MINDEXER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=313798#comment-313798
 ] 

Milos Kleint commented on MINDEXER-63:
--

I'm not so sure that our synchronisation is the fault here. We used to have 
synchronisation even before 5.0.0 upgrade, all access is a write mutex AFAIK, 
used to have read mutex for searches for a while I believe but with the 
previous versions it didn't work out, so we changed it all to write access. so 
always just one man (thread) accessing the whole thing (currently per context, 
used to be global)

there could some unrelated access to the files from the IDE, like native 
listeners getting hold of the file changes and the IDE processes them. AFAIK 
there's no listener watching over the cache folders with maven indexes though. 
According to the report at [1] there only 2 incidents reported, both probably 
coming from the same guy on the same same day. 

so let's call it a user setup error for now. but I believe my initial 
evaluation still stands, if something unexpected happens, the replace() method 
doesn't recover well.


[1] http://statistics.netbeans.org/exceptions/detail.do?id=193177

 NullPointerException at 
 org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
 --

 Key: MINDEXER-63
 URL: https://jira.codehaus.org/browse/MINDEXER-63
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 5.0.0
 Environment: netbeans 7.3 dev builds.
Reporter: Milos Kleint
Priority: Critical

 see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645
 for some reason (unknown to me yet) the index files cannot be deleted. The 
 codebase then gets into bad state.
 possibly wrong code in DefaultIndexingContext:
 {code:java}
 public synchronized void replace( Directory directory )
  throws IOException
  Â {
  Â  Â  Â  Â final Date ts = IndexUtils.getTimestamp( directory );
 closeReaders();
  Â   deleteIndexFiles( false );
  Â   IndexUtils.copyDirectory( directory, indexDirectory );
  Â   openAndWarmup();
  Â   // reclaim the index as mine
  Â   storeDescriptor();
  Â   updateTimestamp( true, ts );
  Â   optimize();
  }
 {code}
 when deleteIndexFiles(0 fails, openAndWarmup() is not called. also 
 closeReaders() ignores indexWriter..

--
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] (MINDEXER-52) reentrant locking in DefaultIndexingContent flawed

2012-11-16 Thread Milos Kleint (JIRA)


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

Milos Kleint closed MINDEXER-52.


   Resolution: Fixed
Fix Version/s: 5.0.0

yup, I believe so.

 reentrant locking in DefaultIndexingContent flawed
 --

 Key: MINDEXER-52
 URL: https://jira.codehaus.org/browse/MINDEXER-52
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 4.1.2
Reporter: Milos Kleint
Priority: Critical
 Fix For: 5.0.0


 DefaultIndexingContent.java contains the following pattern:
 {code:java}
 public IndexReader getIndexReader()
 throws IOException
 {
 lock();
 try
 {
 return indexReader;
 }
 finally
 {
 unlock();
 }
 }
 {code}
 together with installBottleWarmer() method that spawns a concurrent thread 
 that performs warmup operations, it makes it impossible to access the 
 indexReader instance safely. A correct approach would be to wrap the entire 
 operation with the indexreader in the mutex lock, not the the accessor method.
 please see http://netbeans.org/bugzilla/show_bug.cgi?id=204706  and 
 http://statistics.netbeans.org/exceptions/detail.do?id=180712 for examples 
 when this approach is failing. it's fairly rare but  keeps on reoccuring, all 
 access (searching, indexing) from netbeans is protected by a mutex and 
 happens exclusively. I'm assuming that the installBottleWarmer() thread is 
 the one iterfering with our access occasionally.

--
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] (MINDEXER-41) Allow to index several artifacts with no classifier

2012-11-14 Thread Milos Kleint (JIRA)


[ 
https://jira.codehaus.org/browse/MINDEXER-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=313575#comment-313575
 ] 

Milos Kleint commented on MINDEXER-41:
--

also true for netbeans module development where both .jar and .nbm files are 
created.
jglick's solution to the problem for our netbeans.org repository index was a 
custom cmd line indexer. 
https://bitbucket.org/jglick/nexus-for-netbeans/src/65478662cdd2/src/main/java/Main.java

 Allow to index several artifacts with no classifier
 ---

 Key: MINDEXER-41
 URL: https://jira.codehaus.org/browse/MINDEXER-41
 Project: Maven Indexer
  Issue Type: Improvement
Reporter: Julien HENRY

 See details in this thread: 
 http://maven.40175.n5.nabble.com/Search-with-several-artifacts-same-GAV-different-type-extension-td4902408.html
 The key used by indexer is GAVC (GAV + classifier where classifier can be 
 null).
 With current design the indexer will only index one artifact with no 
 classifier (= main artifact) + optionally additional secondary artifacts with 
 classifier.
 This is an issue for custom packaging types that publish several artifacts 
 with different extensions but no classifier.
 For example:
 {code}
 groupId
/artifactId
   /version
  /artifactId-version.pom
  /artifactId-version.jar
  /artifactId-version.tld
  /artifactId-version.config
 {code}
 It would be good to include the extension in the index key = GAVCE. This way 
 a search will return jar, tld and config artifacts.

--
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] (MINDEXER-63) NullPointerException at org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher

2012-10-19 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MINDEXER-63:
-

Description: 
see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645

for some reason (unknown to me yet) the index files cannot be deleted. The 
codebase then gets into bad state.

possibly wrong code in DefaultIndexingContext:

{code:java}
public synchronized void replace( Directory directory )
 ÃÂ  ÃÂ  ÃÂ  ÃÂ throws IOException
 ÃÂ  ÃÂ {
 ÃÂ  ÃÂ  ÃÂ  ÃÂ final Date ts = IndexUtils.getTimestamp( directory );
 ÃÂ  ÃÂ  ÃÂ  ÃÂ closeReaders();
 ÃÂ  ÃÂ  ÃÂ  ÃÂ deleteIndexFiles( false );
 ÃÂ  ÃÂ  ÃÂ  ÃÂ IndexUtils.copyDirectory( directory, indexDirectory );
 ÃÂ  ÃÂ  ÃÂ  ÃÂ openAndWarmup();
 ÃÂ  ÃÂ  ÃÂ  ÃÂ // reclaim the index as mine
 ÃÂ  ÃÂ  ÃÂ  ÃÂ storeDescriptor();
 ÃÂ  ÃÂ  ÃÂ  ÃÂ updateTimestamp( true, ts );
 ÃÂ  ÃÂ  ÃÂ  ÃÂ optimize();
 ÃÂ  ÃÂ }

{code}

when deleteIndexFiles(0 fails, openAndWarmup() is not called. also 
closeReaders() ignores indexWriter..

  was:
see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645

for some reason (unknown to me yet) the index files cannot be deleted. The 
codebase then gets into bad state.

possibly wrong code in DefaultIndexingContext:

public synchronized void replace( Directory directory )
 Â  Â  Â  Â throws IOException
 Â  Â {
 Â  Â  Â  Â final Date ts = IndexUtils.getTimestamp( directory );
 Â  Â  Â  Â closeReaders();
 Â  Â  Â  Â deleteIndexFiles( false );
 Â  Â  Â  Â IndexUtils.copyDirectory( directory, indexDirectory );
 Â  Â  Â  Â openAndWarmup();
 Â  Â  Â  Â // reclaim the index as mine
 Â  Â  Â  Â storeDescriptor();
 Â  Â  Â  Â updateTimestamp( true, ts );
 Â  Â  Â  Â optimize();
 Â  Â }

when deleteIndexFiles(0 fails, openAndWarmup() is not called. also 
closeReaders() ignores indexWriter..


 NullPointerException at 
 org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
 --

 Key: MINDEXER-63
 URL: https://jira.codehaus.org/browse/MINDEXER-63
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 5.0.0
 Environment: netbeans 7.3 dev builds.
Reporter: Milos Kleint
Priority: Critical

 see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645
 for some reason (unknown to me yet) the index files cannot be deleted. The 
 codebase then gets into bad state.
 possibly wrong code in DefaultIndexingContext:
 {code:java}
 public synchronized void replace( Directory directory )
  ÃÂ  ÃÂ  ÃÂ  ÃÂ throws IOException
  ÃÂ  ÃÂ {
  ÃÂ  ÃÂ  ÃÂ  ÃÂ final Date ts = IndexUtils.getTimestamp( directory );
  ÃÂ  ÃÂ  ÃÂ  ÃÂ closeReaders();
  ÃÂ  ÃÂ  ÃÂ  ÃÂ deleteIndexFiles( false );
  ÃÂ  ÃÂ  ÃÂ  ÃÂ IndexUtils.copyDirectory( directory, indexDirectory );
  ÃÂ  ÃÂ  ÃÂ  ÃÂ openAndWarmup();
  ÃÂ  ÃÂ  ÃÂ  ÃÂ // reclaim the index as mine
  ÃÂ  ÃÂ  ÃÂ  ÃÂ storeDescriptor();
  ÃÂ  ÃÂ  ÃÂ  ÃÂ updateTimestamp( true, ts );
  ÃÂ  ÃÂ  ÃÂ  ÃÂ optimize();
  ÃÂ  ÃÂ }
 {code}
 when deleteIndexFiles(0 fails, openAndWarmup() is not called. also 
 closeReaders() ignores indexWriter..

--
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] (MINDEXER-63) NullPointerException at org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher

2012-10-19 Thread Milos Kleint (JIRA)


[ 
https://jira.codehaus.org/browse/MINDEXER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311846#comment-311846
 ] 

Milos Kleint commented on MINDEXER-63:
--

http://netbeans.org/bugzilla/show_bug.cgi?id=219552 might also be related

 NullPointerException at 
 org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
 --

 Key: MINDEXER-63
 URL: https://jira.codehaus.org/browse/MINDEXER-63
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 5.0.0
 Environment: netbeans 7.3 dev builds.
Reporter: Milos Kleint
Priority: Critical

 see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645
 for some reason (unknown to me yet) the index files cannot be deleted. The 
 codebase then gets into bad state.
 possibly wrong code in DefaultIndexingContext:
 public synchronized void replace( Directory directory )
  Â  Â  Â  Â throws IOException
  Â  Â {
  Â  Â  Â  Â final Date ts = IndexUtils.getTimestamp( directory );
  Â  Â  Â  Â closeReaders();
  Â  Â  Â  Â deleteIndexFiles( false );
  Â  Â  Â  Â IndexUtils.copyDirectory( directory, indexDirectory );
  Â  Â  Â  Â openAndWarmup();
  Â  Â  Â  Â // reclaim the index as mine
  Â  Â  Â  Â storeDescriptor();
  Â  Â  Â  Â updateTimestamp( true, ts );
  Â  Â  Â  Â optimize();
  Â  Â }
 when deleteIndexFiles(0 fails, openAndWarmup() is not called. also 
 closeReaders() ignores indexWriter..

--
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] (MINDEXER-63) NullPointerException at org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher

2012-10-19 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MINDEXER-63:
-

Description: 
see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645

for some reason (unknown to me yet) the index files cannot be deleted. The 
codebase then gets into bad state.

possibly wrong code in DefaultIndexingContext:

{code:java}
public synchronized void replace( Directory directory )
 throws IOException
 Â {
 Â  Â  Â  Â final Date ts = IndexUtils.getTimestamp( directory );
closeReaders();
 Â   deleteIndexFiles( false );
 Â   IndexUtils.copyDirectory( directory, indexDirectory );
 Â   openAndWarmup();
 Â   // reclaim the index as mine
 Â   storeDescriptor();
 Â   updateTimestamp( true, ts );
 Â   optimize();
 }

{code}

when deleteIndexFiles(0 fails, openAndWarmup() is not called. also 
closeReaders() ignores indexWriter..

  was:
see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645

for some reason (unknown to me yet) the index files cannot be deleted. The 
codebase then gets into bad state.

possibly wrong code in DefaultIndexingContext:

{code:java}
public synchronized void replace( Directory directory )
 ÃÂ  ÃÂ  ÃÂ  ÃÂ throws IOException
 ÃÂ  ÃÂ {
 ÃÂ  ÃÂ  ÃÂ  ÃÂ final Date ts = IndexUtils.getTimestamp( directory );
 ÃÂ  ÃÂ  ÃÂ  ÃÂ closeReaders();
 ÃÂ  ÃÂ  ÃÂ  ÃÂ deleteIndexFiles( false );
 ÃÂ  ÃÂ  ÃÂ  ÃÂ IndexUtils.copyDirectory( directory, indexDirectory );
 ÃÂ  ÃÂ  ÃÂ  ÃÂ openAndWarmup();
 ÃÂ  ÃÂ  ÃÂ  ÃÂ // reclaim the index as mine
 ÃÂ  ÃÂ  ÃÂ  ÃÂ storeDescriptor();
 ÃÂ  ÃÂ  ÃÂ  ÃÂ updateTimestamp( true, ts );
 ÃÂ  ÃÂ  ÃÂ  ÃÂ optimize();
 ÃÂ  ÃÂ }

{code}

when deleteIndexFiles(0 fails, openAndWarmup() is not called. also 
closeReaders() ignores indexWriter..


 NullPointerException at 
 org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
 --

 Key: MINDEXER-63
 URL: https://jira.codehaus.org/browse/MINDEXER-63
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 5.0.0
 Environment: netbeans 7.3 dev builds.
Reporter: Milos Kleint
Priority: Critical

 see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645
 for some reason (unknown to me yet) the index files cannot be deleted. The 
 codebase then gets into bad state.
 possibly wrong code in DefaultIndexingContext:
 {code:java}
 public synchronized void replace( Directory directory )
  throws IOException
  Â {
  Â  Â  Â  Â final Date ts = IndexUtils.getTimestamp( directory );
 closeReaders();
  Â   deleteIndexFiles( false );
  Â   IndexUtils.copyDirectory( directory, indexDirectory );
  Â   openAndWarmup();
  Â   // reclaim the index as mine
  Â   storeDescriptor();
  Â   updateTimestamp( true, ts );
  Â   optimize();
  }
 {code}
 when deleteIndexFiles(0 fails, openAndWarmup() is not called. also 
 closeReaders() ignores indexWriter..

--
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] (MINDEXER-63) NullPointerException at org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher

2012-10-15 Thread Milos Kleint (JIRA)

Milos Kleint created MINDEXER-63:


 Summary: NullPointerException at 
org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
 Key: MINDEXER-63
 URL: https://jira.codehaus.org/browse/MINDEXER-63
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 5.0.0
 Environment: netbeans 7.3 dev builds.
Reporter: Milos Kleint
Priority: Critical


see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645

for some reason (unknown to me yet) the index files cannot be deleted. The 
codebase then gets into bad state.

possibly wrong code in DefaultIndexingContext:

public synchronized void replace( Directory directory )
 Â  Â  Â  Â throws IOException
 Â  Â {
 Â  Â  Â  Â final Date ts = IndexUtils.getTimestamp( directory );
 Â  Â  Â  Â closeReaders();
 Â  Â  Â  Â deleteIndexFiles( false );
 Â  Â  Â  Â IndexUtils.copyDirectory( directory, indexDirectory );
 Â  Â  Â  Â openAndWarmup();
 Â  Â  Â  Â // reclaim the index as mine
 Â  Â  Â  Â storeDescriptor();
 Â  Â  Â  Â updateTimestamp( true, ts );
 Â  Â  Â  Â optimize();
 Â  Â }

when deleteIndexFiles(0 fails, openAndWarmup() is not called. also 
closeReaders() ignores indexWriter..

--
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-5329) sisu-guava is deprecated, use upstream library

2012-08-15 Thread Milos Kleint (JIRA)

Milos Kleint created MNG-5329:
-

 Summary: sisu-guava is deprecated, use upstream library
 Key: MNG-5329
 URL: https://jira.codehaus.org/browse/MNG-5329
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies, General
Affects Versions: 3.0.4
Reporter: Milos Kleint
Priority: Critical


see https://github.com/sonatype/sisu-guava/tree/
the sisu guava lib has been deprecated, from what I could figure from the 
commit logs on original site and sisu-guava, the recently released 13.0 release 
should be ok to use.

--
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-5329) sisu-guava is deprecated, use upstream library

2012-08-15 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-5329:
---

sisu-guava is also used in aether.

 sisu-guava is deprecated, use upstream library
 --

 Key: MNG-5329
 URL: https://jira.codehaus.org/browse/MNG-5329
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies, General
Affects Versions: 3.0.4
Reporter: Milos Kleint
Priority: Critical

 see https://github.com/sonatype/sisu-guava/tree/
 the sisu guava lib has been deprecated, from what I could figure from the 
 commit logs on original site and sisu-guava, the recently released 13.0 
 release should be ok to use.

--
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] (MINDEXER-54) setting user agent should be more straightforward

2012-08-02 Thread Milos Kleint (JIRA)

Milos Kleint created MINDEXER-54:


 Summary: setting user agent should be more straightforward
 Key: MINDEXER-54
 URL: https://jira.codehaus.org/browse/MINDEXER-54
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 4.1.2
Reporter: Milos Kleint


setting user agent should be more straightforward especially since central 
started rejecting requests without a user agent.

please see https://hg.netbeans.org/core-main/rev/1aa01e27dd62 and 
http://netbeans.org/bugzilla/show_bug.cgi?id=215343 for details

--
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-5309) InputLocation missing for Xpp3Dom configuration elements

2012-07-26 Thread Milos Kleint (JIRA)

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

Milos Kleint reassigned MNG-5309:
-

Assignee: Milos Kleint

InputLocation missing for Xpp3Dom configuration elements

Key: MNG-5309
URL: https://jira.codehaus.org/browse/MNG-5309
Project: Maven 2 3
Issue Type: Bug
Components: Embedding, IDEs, Inheritance and Interpolation, POM
Affects Versions: 3.0.4
Reporter: Milos Kleint
Assignee: Milos Kleint
Attachments: 2012-07-06_1548.png, mng_configuration.patch

I'm trying to create a view over a pom.xml file that displays current
effective pom, along with showing which line came from which pom. Works more
or less ok, with the provided InputLocations with one significant exception.
configuration element in plugin. See screenshot.
The idea in the patch is to have the InputLocation tree mimic the tree of
Xpp3Dom objects. All the merges of Xpp3Dom then manipulate the tree of
InputLocations as well.
The patch included is not complete, just proof of concept, needs to have
proper InputLocation creating in Xpp3DomMavenReaderExt file (I've replaced
that by some quick post processing, changing modello plugins to generate
something else is error prone slow to to start with). Additionally the
default Xpp3Dom merging from plexus-utils is replaced by maven's own version
of merge code. Not sure there if it's possible/practical to move that code
down to the dependency.
also some additional tests are required to be written

--
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-5309) InputLocation missing for Xpp3Dom configuration elements

2012-07-26 Thread Milos Kleint (JIRA)

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

Milos Kleint commented on MNG-5309:
---

one stopper problem is that equals/hashcode on Xpp3DOM work with the values of
the entire subtree. Once we create the locations tree with Xpp3DOM as keys in
InputLocation, we arrive at a problem once ModelInterpolator is invoked on the
pom file. any expression in any value invalidates the entire locations subtree
because the hashcode/equals values changes and the maps in InputLocation keep
the old hash as reference for lookup of values.

InputLocation missing for Xpp3Dom configuration elements

[jira] (MNG-5312) MavenProject.getParent intolerably slow when import scope used heavily

2012-07-18 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MNG-5312:
--

Fix Version/s: 3.0.5

 MavenProject.getParent intolerably slow when import scope used heavily
 --

 Key: MNG-5312
 URL: https://jira.codehaus.org/browse/MNG-5312
 Project: Maven 2  3
  Issue Type: Bug
  Components: Embedding
Affects Versions: 3.0.4
 Environment: JDK 7, Ubuntu
Reporter: Jesse Glick
Assignee: Jason van Zyl
 Fix For: 3.0.5

 Attachments: DefaultProjectBuilder.diff


 For projects which make heavy use of {{scopeimport/scope}} including in 
 parent POMs, calling {{MavenProject.getParent}} (thus 
 {{DefaultProjectBuilder.build(Artifact, ...)}}) can be intolerably slow - 
 taking many minutes - even when loading the project (or its parent) via 
 {{DefaultProjectBuilder.build(ListFile, ...)}} takes less than a second.
 The discrepancy seems to be due to the fact that {{ReactorModelCache}} is 
 crucial for the performance of 
 {{DefaultModelBuilder.importDependencyManagement}}, yet only one 
 {{DefaultProjectBuilder.build}} overload defines a {{ModelCache}}. For 
 resolution of parents from a single POM, no model cache is likely to be 
 needed under normal circumstances, but if you are missing a cache when import 
 scope dependencies are processed for {{dependencyManagement}}, the builder 
 takes exponential time to find these imports.
 I do not have a minimal test case for this yet as the known test case 
 involves a large and complex proprietary source base. Patch (baseline is 
 3.0.4) successfully tested against these sources and shown to reduce 
 {{getParent}} times by orders of magnitude.
 https://issues.jenkins-ci.org/browse/JENKINS-11362 is the downstream issue 
 describing symptoms.

--
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-2199) Version ranges not supported for parent artifacts

2012-07-06 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-2199:
---

+ on on wontfix as well. Any non-determinism in parent coordinates makes 
repository content fluid which is a bad thing IMHO.

 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Bug
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
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-5309) InputLocation missing for Xpp3Dom configuration elements

2012-07-06 Thread Milos Kleint (JIRA)

Milos Kleint created MNG-5309:
-

 Summary: InputLocation missing for Xpp3Dom configuration elements
 Key: MNG-5309
 URL: https://jira.codehaus.org/browse/MNG-5309
 Project: Maven 2  3
  Issue Type: Bug
  Components: Embedding, IDEs, Inheritance and Interpolation, POM
Affects Versions: 3.0.4
Reporter: Milos Kleint
 Attachments: 2012-07-06_1548.png, mng_configuration.patch

I'm trying to create a view over a pom.xml file that displays current effective 
pom, along with showing which line came from which pom. Works more or less ok, 
with the provided InputLocations with one significant exception. 
configuration element in plugin. See screenshot.
The idea in the patch is to have the InputLocation tree mimic the tree of 
Xpp3Dom objects. All the merges of Xpp3Dom then manipulate the tree of 
InputLocations as well.

The patch included is not complete, just proof of concept, needs to have proper 
InputLocation creating in Xpp3DomMavenReaderExt file (I've replaced that by 
some quick post processing, changing modello plugins to generate something else 
is error prone slow to to start with). Additionally the default Xpp3Dom merging 
from plexus-utils is replaced by maven's own version of merge code. Not sure 
there if it's possible/practical to move that code down to the dependency.

also some additional tests are required to be written

--
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-5306) for IDE embedding have ways of collecting model problems without failing the process

2012-07-05 Thread Milos Kleint (JIRA)

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

Milos Kleint reassigned MNG-5306:
-

Assignee: Milos Kleint

for IDE embedding have ways of collecting model problems without failing the
process

Key: MNG-5306
URL: https://jira.codehaus.org/browse/MNG-5306
Project: Maven 2 3
Issue Type: New Feature
Components: Embedding, IDEs, POM
Affects Versions: 3.0.4
Reporter: Milos Kleint
Assignee: Milos Kleint
Priority: Critical

Currently the IDE integrations need to perform 2 steps:
1. load the POM with no validation in place. Having a MavenProject instance
in the most cases possible is important.
2. to display the warnings in pom editor and elsewhere one has to run at
least the projectbuilder/modelbuilder with proper validation level and
collect the results from either the result object or the exception thrown.
The proposed patch in https://github.com/mkleint/maven-3/commits/trunk makes
it possible to have both a MAvenproject instance under minimal validation
constraints and collect the validation problems for any higher validation
levels.
Additional benefit of the patch is that it logs since what version of Maven
is the problem valid. Which can be further used in both cmd line and IDE
error reporting.

[jira] (MNG-5306) for IDE embedding have ways of collecting model problems without failing the process

2012-07-05 Thread Milos Kleint (JIRA)

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

Milos Kleint closed MNG-5306.
-

Resolution: Fixed
Fix Version/s: 3.0.5

revision 1357589

for IDE embedding have ways of collecting model problems without failing the
process

[jira] (MNG-5306) for IDE embedding have ways of collecting model problems without failing the process

2012-06-29 Thread Milos Kleint (JIRA)

Milos Kleint created MNG-5306:
-

 Summary: for IDE embedding have ways of collecting model problems 
without failing the process
 Key: MNG-5306
 URL: https://jira.codehaus.org/browse/MNG-5306
 Project: Maven 2  3
  Issue Type: New Feature
  Components: Embedding, IDEs, POM
Affects Versions: 3.0.4
Reporter: Milos Kleint
Priority: Critical


Currently the IDE integrations need to perform 2 steps:
1. load the POM with no validation in place. Having a MavenProject instance in 
the most cases possible is important.
2. to display the warnings in pom editor and elsewhere one has to run at least 
the projectbuilder/modelbuilder with proper validation level and collect the 
results from either the result object or the exception thrown.

The proposed patch in https://github.com/mkleint/maven-3/commits/trunk makes it 
possible to have both a MAvenproject instance under minimal validation 
constraints and collect the validation problems for any higher validation 
levels.

Additional benefit of the patch is that it logs since what version of Maven is 
the problem valid. Which can be further used in both cmd line and IDE error 
reporting.

--
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-5306) for IDE embedding have ways of collecting model problems without failing the process

2012-06-29 Thread Milos Kleint (JIRA)

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

Milos Kleint commented on MNG-5306:
---

https://github.com/mkleint/maven-3/commit/0540107c332c7795226e95fb46bff722388ffae4
adds a Version field to ModelProblem which denotes since what validation
level/maven version, the problem applies.

https://github.com/mkleint/maven-3/commit/098f02010d4b5d19b90006e25087e992b73a5ded
moves the decision making about failing the model building from the collector
object to default model builder, in overridable protected method. The IDE
integration can replace the default implementation with a subclass that
performs a full 31 validation but fails the building only when base problems
are found.

for IDE embedding have ways of collecting model problems without failing the
process

[jira] (MINDEXER-44) NPE from DefaultSearchEngine.doSearchWithCeiling

2012-06-04 Thread Milos Kleint (JIRA)


[ 
https://jira.codehaus.org/browse/MINDEXER-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300289#comment-300289
 ] 

Milos Kleint commented on MINDEXER-44:
--

a similar issue occurred in http://netbeans.org/bugzilla/show_bug.cgi?id=213466

The initial problem in this case seems to be this stacktrace:
java.lang.NullPointerException
at org.apache.lucene.store.Directory.copy(Directory.java:200)
at
org.apache.maven.index.context.IndexUtils.copyDirectory(IndexUtils.java:51)
at
org.apache.maven.index.context.DefaultIndexingContext.replace(DefaultIndexingContext.java:832)
at
org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory(DefaultIndexUpdater.java:218)
at
org.apache.maven.index.updater.DefaultIndexUpdater.access$300(DefaultIndexUpdater.java:76)
at
org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile(DefaultIndexUpdater.java:642)
at
org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:879)
at
org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:157)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.indexLoadedRepo(NexusRepositoryIndexerImpl.java:498)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.loadIndexingContext(NexusRepositoryIndexerImpl.java:288)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.access$300(NexusRepositoryIndexerImpl.java:139)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl$2.run(NexusRepositoryIndexerImpl.java:540)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl$2.run(NexusRepositoryIndexerImpl.java:531)
at org.openide.util.Mutex.writeAccess(Mutex.java:397)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.indexRepo(NexusRepositoryIndexerImpl.java:531)
at
org.netbeans.modules.maven.indexer.api.RepositoryIndexer.indexRepo(RepositoryIndexer.java:62)
at
org.netbeans.modules.maven.ProjectOpenedHookImpl$1.run(ProjectOpenedHookImpl.java:202)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1411)
[catch] at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1991)



 NPE from DefaultSearchEngine.doSearchWithCeiling
 

 Key: MINDEXER-44
 URL: https://jira.codehaus.org/browse/MINDEXER-44
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 4.1.1
Reporter: Jesse Glick
Assignee: Olivier Lamy
Priority: Minor
 Fix For: 4.1.3


 http://netbeans.org/bugzilla/show_bug.cgi?id=202138 reports 
 http://statistics.netbeans.org/exceptions/messageslog?id=533660 which shows
 {code}
 java.lang.NullPointerException
   at 
 org.apache.maven.index.DefaultSearchEngine.doSearchWithCeiling(DefaultSearchEngine.java:316)
   at 
 org.apache.maven.index.DefaultSearchEngine.searchFlat(DefaultSearchEngine.java:169)
   at 
 org.apache.maven.index.DefaultSearchEngine.searchFlatPaged(DefaultSearchEngine.java:102)
   at 
 org.apache.maven.index.DefaultSearchEngine.searchFlatPaged(DefaultSearchEngine.java:77)
 {code}
 This comes after some index download problems like
 {code}
 java.io.FileNotFoundException: Resource nexus-maven-repository-index.gz does 
 not exist
   at 
 org.apache.maven.index.updater.WagonHelper$WagonFetcher.retrieve(WagonHelper.java:196)
   at 
 org.apache.maven.index.updater.WagonHelper$WagonFetcher.retrieve(WagonHelper.java:166)
   at 
 org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory(DefaultIndexUpdater.java:191)
   at 
 org.apache.maven.index.updater.DefaultIndexUpdater.access$300(DefaultIndexUpdater.java:76)
   at 
 org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile(DefaultIndexUpdater.java:642)
   at 
 org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:861)
   at 
 org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:157)
 {code}
 It seems that the {{DefaultIndexingContext.indexSearcher}} is null, for 
 whatever reason, and {{searchFlatPaged}} is not verifying that it has been 
 passed a valid context and does not attempt to fix an invalid context, 
 perhaps using {{openAndWarmupReaders}}.
 Probably the caller is at fault for attempting a search on a context with no 
 valid index, but this ought to be reported more clearly than with an NPE 
 several calls down the stack, and there should be some documented method for 
 checking that a context is somehow complete and ready for use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:

[jira] (MINDEXER-52) reentrant locking in DefaultIndexingContent flawed

2012-04-04 Thread Milos Kleint (JIRA)


[ 
https://jira.codehaus.org/browse/MINDEXER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=295749#comment-295749
 ] 

Milos Kleint commented on MINDEXER-52:
--

I'm not entirely clear on what the purpose of the installBottleWarmer() method 
is, but at least a workaround would be to let the client code to call it 
manually without spawning a new concurrent thread.

 reentrant locking in DefaultIndexingContent flawed
 --

 Key: MINDEXER-52
 URL: https://jira.codehaus.org/browse/MINDEXER-52
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 4.1.2
Reporter: Milos Kleint
Priority: Critical

 DefaultIndexingContent.java contains the following pattern:
 {code:java}
 public IndexReader getIndexReader()
 throws IOException
 {
 lock();
 try
 {
 return indexReader;
 }
 finally
 {
 unlock();
 }
 }
 {code}
 together with installBottleWarmer() method that spawns a concurrent thread 
 that performs warmup operations, it makes it impossible to access the 
 indexReader instance safely. A correct approach would be to wrap the entire 
 operation with the indexreader in the mutex lock, not the the accessor method.
 please see http://netbeans.org/bugzilla/show_bug.cgi?id=204706  and 
 http://statistics.netbeans.org/exceptions/detail.do?id=180712 for examples 
 when this approach is failing. it's fairly rare but  keeps on reoccuring, all 
 access (searching, indexing) from netbeans is protected by a mutex and 
 happens exclusively. I'm assuming that the installBottleWarmer() thread is 
 the one iterfering with our access occasionally.

--
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] (MINDEXER-52) reentrant locking in DefaultIndexingContent flawed

2012-03-19 Thread Milos Kleint (JIRA)

Milos Kleint created MINDEXER-52:


 Summary: reentrant locking in DefaultIndexingContent flawed
 Key: MINDEXER-52
 URL: https://jira.codehaus.org/browse/MINDEXER-52
 Project: Maven Indexer
  Issue Type: Bug
Affects Versions: 4.1.2
Reporter: Milos Kleint
Priority: Critical


DefaultIndexingContent.java contains the following pattern:

{code:java}
public IndexReader getIndexReader()
throws IOException
{
lock();

try
{
return indexReader;
}
finally
{
unlock();
}
}

{code}


together with installBottleWarmer() method that spawns a concurrent thread that 
performs warmup operations, it makes it impossible to access the indexReader 
instance safely. A correct approach would be to wrap the entire operation with 
the indexreader in the mutex lock, not the the accessor method.

please see http://netbeans.org/bugzilla/show_bug.cgi?id=204706  and 
http://statistics.netbeans.org/exceptions/detail.do?id=180712 for examples when 
this approach is failing. it's fairly rare but  keeps on reoccuring, all access 
(searching, indexing) from netbeans is protected by a mutex and happens 
exclusively. I'm assuming that the installBottleWarmer() thread is the one 
iterfering with our access occasionally.

--
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: (MCOMPILER-135) Passing multiple parameters to Java 6 annotation processors with javac does not work

2010-09-14 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MCOMPILER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235172#action_235172
 ] 

Milos Kleint commented on MCOMPILER-135:


from the usability point of view it's confusing to have both 
compilerArguments and compilerArgumentKeyValue as plugin parameters.. I 
would be inclined to define annotation processing specific parameter, than it's 
more clear which one to use in the given scenario..

 Passing multiple parameters to Java 6 annotation processors with javac does 
 not work
 

 Key: MCOMPILER-135
 URL: http://jira.codehaus.org/browse/MCOMPILER-135
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.3.1
 Environment: JDK 1.6, Maven 2.2.1, Maven-Compiler-Plugin 2.3.1, 
 Windows
Reporter: Sean Patrick Floyd
 Attachments: AbstractCompilerMojo.java.2.patch, 
 AbstractCompilerMojo.java.patch


 I have an annotation processor that supports multiple parameters and I have 
 found that there is no way to set more than one of them at any given time 
 from the Maven Compiler Plugin,
 Here's my setup.
 {code:xml} 
 plugin
 inheritedtrue/inherited
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 version2.3.1/version
 configuration
 source1.6/source
 target1.6/target
 compilerArgument-AaddResDir=src/main/webapp 
 -Averbose=true/compilerArgument
 /configuration
 /plugin
 {code} 
 Javac needs the parameters added as separate Strings
 {code}[ ... , -AaddResDir=src/main/webapp, -Averbose=true]{code}
 but the Compiler Plugin generates this code:
 {code}[ ... , -AaddResDir=src/main/webapp -Averbose=true]{code}
 which Javac will parse as
 {code}key:addResDir value=src/main/webapp -Averbose=true{code}
 The map version compilerArguments is of no help either, because this
 {code}Averbosetrue/Averbose
 AaddResDirsrc/main/webapp/AResDir{code}
 will generate the output
 {code}[... , -Averbose, true, -AaddResDir, src/main/webapp]{code}
 while this
 {code}Averbose=true /
 AaddResDir=src/main/webapp /{code}
 is not well-formed XML.
 Stepping through the compiler argument generation with the debugger I have 
 not found a way to post-process the arguments, so please add a way to support 
 multiple APT parameters because this is a major show-stopper.

-- 
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] Closed: (MARCHETYPES-35) Cleaner handling of javaee-endorsed-api dependency

2010-09-07 Thread Milos Kleint (JIRA)

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

Milos Kleint closed MARCHETYPES-35.
---

Resolution: Fixed

patch applied.

Please note that unlike the previous solution (as far as I remember) the
endorsed classpath wil only be correct for built project. When netbeans creates
new projects from archetypes, it only downloads dependencies which will not
have any effect on the endorsed classpath

Cleaner handling of javaee-endorsed-api dependency
--

Key: MARCHETYPES-35
URL: http://jira.codehaus.org/browse/MARCHETYPES-35
Project: Maven Archetype Bundles
Issue Type: Improvement
Components: Maven Webapp Archetype
Affects Versions: 1.1
Environment: Tested on Ubuntu w/ JDK 6 Maven 2.2.1; XP, JDK 6,
3.0-beta-2.
Reporter: Jesse Glick
Assignee: Milos Kleint
Attachments: mojo-archetypes-javaee6-endorsed-api.diff

The current archetypes for Java EE 6 WAR or EJB projects use the technique of
prepending to the bootclasspath in order to use newer EE APIs in place of
older SE APIs. There are two problems with this hack:
1. It relies on {{sun.boot.class.path}} and so must be activated only in a
profile for Sun JDKs.
2. The artifacts listed as dependencies (currently just one) must be written
twice (in order to force a download), risking inconsistency.
I have a patch that uses {{-endorseddirs}} in conjunction with
{{maven-dependency-plugin}}, which seems to be the preferred idiom judging by
internet search hits I have found for people struggling with endorsed
libraries in Maven, although MNG-4752 would be the preferred long-term
solution. Please consider applying for the 1.2 versions of the archetypes.
https://netbeans.org/bugzilla/show_bug.cgi?id=185139#c16 explains why
adjusting the Surefire execution environment accordingly is not possible.

--
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-4731) NPE from AttachedArtifact.getVersion rather than meaningful error

2010-07-15 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228684#action_228684
 ] 

Milos Kleint commented on MNG-4731:
---

Benjamin, unfortunately the MavenProjectHelper requires a MavenProject instance 
as parameter which I don't have for the artifact in this case so I just copied 
the code from MavenProjectHelper at some point in time.

 NPE from AttachedArtifact.getVersion rather than meaningful error
 -

 Key: MNG-4731
 URL: http://jira.codehaus.org/browse/MNG-4731
 Project: Maven 2  3
  Issue Type: Bug
  Components: Errors
Affects Versions: 2.2.1
 Environment: Ubuntu Lucid, JDK 6u21
Reporter: Jesse Glick
 Attachments: validateIdentity.diff


 I am working on a problem with {{nbm:populate-repository}} (from 
 {{org.codehaus.mojo:nbm-maven-plugin}}). Maven 2.2.1, when run under certain 
 circumstances, fails when running this goal with the following unhelpful 
 message:
 {noformat}
 ...
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] null
 [INFO] 
 
 [INFO] Trace
 java.lang.NullPointerException
   at 
 org.apache.maven.project.artifact.AttachedArtifact.getVersion(AttachedArtifact.java:122)
   at 
 org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:141)
   at 
 org.apache.maven.artifact.DefaultArtifact.init(DefaultArtifact.java:122)
   at 
 org.apache.maven.project.artifact.AttachedArtifact.init(AttachedArtifact.java:42)
   at 
 org.codehaus.mojo.nbm.PopulateRepositoryMojo.createAttachedArtifact(PopulateRepositoryMojo.java:617)
   at 
 org.codehaus.mojo.nbm.PopulateRepositoryMojo.execute(PopulateRepositoryMojo.java:424)
 ...
 {noformat}
 Inspection of the code reveals the immediate cause of the NPE: in 
 {{getVersion}}, the {{parent}} field is null. Even though this is a final 
 field set in the constructor to a non-null value, it has not yet been set 
 when the super constructor is called. This is because {{DefaultArtifact}} 
 uses the antipattern of calling an overridable method ({{getVersion}}) from 
 its constructor (indirectly via {{validateIdentity}}). The NPE then prevents 
 the details of the problem from being reported to the user.
 Ideally this antipattern would be solved, by making {{validateIdentity}} 
 public and requiring all creators of a {{DefaultArtifact}} to call it after 
 construction. Since this cannot now be done compatibly (e.g. 
 {{PopulateRepositoryMojo}} above would need to be modified), the next best 
 thing is to assume that {{AttachedArtifact}} is the only subclass, and ensure 
 that {{validateIdentity}} is called only once the object has been fully 
 constructed. With that change (patch against {{2.2.2-SNAPSHOT}} attached), 
 the error message is informative (specifics of this run have been elided) and 
 points toward possible problems in the plugin:
 {noformat}
 ...
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] An invalid artifact was detected.
 This artifact might be in your project's POM, or it might have been included 
 transitively
 during the resolution process. Here is the information we do have for this 
 artifact:
 o GroupID: ...
 o ArtifactID:  ...
 o Version: ...
 o Type: MISSING 
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
 {...:...:...:null}: The type cannot be empty.
   at 
 org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:141)
   at 
 org.apache.maven.project.artifact.AttachedArtifact.validateIdentity(AttachedArtifact.java:63)
   at 
 org.apache.maven.project.artifact.AttachedArtifact.init(AttachedArtifact.java:53)
   at 
 org.codehaus.mojo.nbm.PopulateRepositoryMojo.createAttachedArtifact(PopulateRepositoryMojo.java:617)
   at 
 org.codehaus.mojo.nbm.PopulateRepositoryMojo.execute(PopulateRepositoryMojo.java:424)
 ...
 {noformat}

-- 
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-620) Ability to access manifest resource while running unit tests

2010-05-27 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/SUREFIRE-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222826#action_222826
 ] 

Milos Kleint commented on SUREFIRE-620:
---

currently the only option is to have the manifest manually created or somehow 
generated (either the real manifest or a test mockup one) and pass it to the 
test classpath via a parameter of the surefire plugin

http://maven.apache.org/plugins/maven-surefire-plugin/examples/additional-classpath.html


 Ability to access manifest resource while running unit tests
 

 Key: SUREFIRE-620
 URL: http://jira.codehaus.org/browse/SUREFIRE-620
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Junit 4.x support, Maven Surefire Plugin
Affects Versions: 2.5
 Environment: n/a
Reporter: Ernst de Haan
Priority: Minor

 Use case:
 - my code calls getClass().getPackage().getImplementationVersion() to 
 determine the version specified in the manifest
 - I would like to test this code, for example making sure the returned string 
 is not null
 Currently, when I run mvn test it does not generate the JAR, nor does it 
 not make the META-INF/MANIFEST.MF file available in the classpath.
 First question is whether this is a *unit* test or an *integration* test. I 
 would say a unit test, because no other code bases are involved, this should 
 be within a single module, and not testing any dependencies.
 Secondly, is the test valid at all if it uses a resource. I would say yes, 
 because it is even standard functionality offered by J2SE and I consider this 
 a good approach to determining meta data from the codebase self.
 Thirdly, should the Surefire plugin depend on the JAR being created or should 
 it just generate the manifest (and copy/generate other resources?) and stick 
 them where the compiled classes go?

-- 
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: (MCOMPILER-6) improve documentation

2010-03-30 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MCOMPILER-6:
-

Fix Version/s: (was: 2.2)
   2.3

 improve documentation
 -

 Key: MCOMPILER-6
 URL: http://jira.codehaus.org/browse/MCOMPILER-6
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Reporter: Brett Porter
 Fix For: 2.3


 some aspects are unclear:
 - compilerVersion is only used when forking
 - fork should indicate that it uses the built in version when false, not an 
 executable.
 Also:
 - don't set parameters that only apply to forking when fork is false to make 
 the code more readable
 - specifiy which are specific to javac, or java in general (perhaps we should 
 be able to assign a @category to a plugin 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] Updated: (MCOMPILER-71) javac compilation error for package-info.java containing package annotation

2010-03-30 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MCOMPILER-71:
--

Fix Version/s: (was: 2.2)
   2.3

 javac compilation error for package-info.java containing package annotation
 ---

 Key: MCOMPILER-71
 URL: http://jira.codehaus.org/browse/MCOMPILER-71
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.0.2
 Environment: Windows XP SP2
 JDK 1.5.0_15
Reporter: Gabriel Forro
Assignee: John Casey
 Fix For: 2.3

 Attachments: compile_error_2.0.2.log


 The package-info.java files can not be compiled in Maven 2 if the 2.0.2 
 maven-compiler-plugin is used. package-info.java files can be compiled by 
 earlier versions of the maven-compiler-plugin (I have tried 2.0 and 2.0.1). 
 Newer snapshot versions does not work also and it fails in the same error (I 
 have tried version 2.1-snapshot).
 This problem can be caused by an unusual behavior of the javac from jdk 1.5. 
 This behavior is as follows:
 You can not use '/' file separator during compiling package-info.java (for 
 instance javac sk/forro/package-info.java). You must use '\' separator (for 
 instance javac sk\forro\package-info.java). If you use the '/' separator 
 you get the the compilation error reported by this bug (package annotations 
 should be in file package-info.java). This is javac 'feature' has been 
 removed in jdk 6 and in jdk 6 you can use either '/' or '\' - it does not 
 matter.
 It looks like the maven-compiler-plugin or one of its components (I mean 
 plexus-x artefacts used by maven-compiler-plugin) uses '/' instead of the '\' 
 in the MS Windows environment.
 I have attached a log file of an unsuccessful build (generated by mvn install 
 -X)
 A possible workaround to solve this problem temporarily:
 The compilation successes if I use either an older version of 
 maven-compiler-plugin or jdk 6 or do not use package-info.java files at all.

-- 
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: (MCOMPILER-75) Add apt support for Java 6

2010-03-29 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MCOMPILER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215894#action_215894
 ] 

Milos Kleint commented on MCOMPILER-75:
---

there is one trick I came up with when working with endorsed libs in j2ee space:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
!-- javaee6 contains upgrades of APIs contained 
within the JDK itself.
 As such these need to be placed on the 
bootclasspath, rather than classpath of the
 compiler.
 If you don't make use of these new updated 
API, you can delete the profile.
 On non-SUN jdk, you will need to create a 
similar profile for your jdk, with the similar property as sun.boot.class.path 
in Sun's JDK.--
compilerArguments

bootclasspath${settings.localRepository}/javax/javaee-endorsed-api/6.0/javaee-endorsed-api-6.0.jar${path.separator}${sun.boot.class.path}/bootclasspath
/compilerArguments
/configuration
dependencies
dependency
groupIdjavax/groupId
artifactIdjavaee-endorsed-api/artifactId
version6.0/version
/dependency
/dependencies
/plugin
{code}

 Add apt support for Java 6
 --

 Key: MCOMPILER-75
 URL: http://jira.codehaus.org/browse/MCOMPILER-75
 Project: Maven 2.x Compiler Plugin
  Issue Type: New Feature
Affects Versions: 2.0.2
Reporter: Mark Hobson
Assignee: Milos Kleint
 Fix For: 2.2


 Apt (Annotation Processing Tool) was merged into javac in Java 6.  The 
 compiler plugin should support this new functionality, which means supporting 
 the following new arguments:
 {noformat}
   -proc:{none,only}  Control whether annotation processing and/or 
 compilation is done.
   -processor class1[,class2,class3...]Names of the annotation 
 processors to run; bypasses default discovery process
   -processorpath path  Specify where to find annotation processors
   -s directory Specify where to place generated source files
   -implicit:{none,class} Specify whether or not to generate class files 
 for implicitly referenced files
   -Akey[=value]  Options to pass to annotation processors
 {noformat}
 Note that this should supersede the Apt Maven Plugin at Mojo by encompassing 
 all of its functionality:
 http://mojo.codehaus.org/apt-maven-plugin/index.html

-- 
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: (ARCHETYPE-57) Support empty directory creation

2010-03-29 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/ARCHETYPE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215961#action_215961
 ] 

Milos Kleint commented on ARCHETYPE-57:
---

yes, I think the org.codehaus.mojo.archetypes archetypes are making use of this.



 Support empty directory creation
 

 Key: ARCHETYPE-57
 URL: http://jira.codehaus.org/browse/ARCHETYPE-57
 Project: Maven Archetype
  Issue Type: Improvement
  Components: Creator
Affects Versions: 1.0-alpha-4
Reporter: Mark Hobson
 Fix For: 2.0-alpha-4

 Attachments: ARCHETYPE-57-patch


 archetype.xml currently provides no way of creating empty directories.

-- 
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: (MCOMPILER-32) compilation failure using source, target == 1.5 on mac os x

2010-03-28 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MCOMPILER-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215808#action_215808
 ] 

Milos Kleint commented on MCOMPILER-32:
---

I think I've seen something similar with app being run via shell and directly 
as .app via Finder. maybe the javac executed from maven build is forked but not 
wrapped in shell?

 compilation failure using source, target == 1.5 on mac os x
 ---

 Key: MCOMPILER-32
 URL: http://jira.codehaus.org/browse/MCOMPILER-32
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
 Environment: mac os x 10.4.6
 jdk 1.5.0_05
Reporter: Jesse McLaughlin

 Getting the following compilation failure when trying to compile 1.5 sources 
 on mac os x.  Default system jdk is 1.4.2 but shell is pointed to jdk 1.5.  
 Seems like forked compiler is reverting to 1.4 javac.
  mvn -e package
 + Error stacktraces are turned on.
 [INFO] Scanning for projects...
 [INFO] 
 
 [INFO] Building Test Project
 [INFO]task-segment: [package]
 [INFO] 
 
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 Compiling 3 source files to 
 /Users/jess/Devel/workspace/test-project/target/classes
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] Compilation failure
 Failure executing javac, but could not parse the error:
 javac: invalid target release: 1.5
 Usage: javac options source files
 where possible options include:
   -gGenerate all debugging info
   -g:none   Generate no debugging info
   -g:{lines,vars,source}Generate only some debugging info
   -nowarn   Generate no warnings
   -verbose  Output messages about what the compiler is doing
   -deprecation  Output source locations where deprecated APIs are 
 used
   -classpath path Specify where to find user class files
   -sourcepath pathSpecify where to find input source files
   -bootclasspath path Override location of bootstrap class files
   -extdirs dirs   Override location of installed extensions
   -d directorySpecify where to place generated class files
   -encoding encoding  Specify character encoding used by source files
   -source release Provide source compatibility with specified 
 release
   -target release Generate class files for specific VM version
   -help Print a synopsis of standard options
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.BuildFailureException: Compilation failure
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation 
 failure
 at 
 org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505)
 at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111)
 at

[jira] Closed: (MCOMPILER-75) Add apt support for Java 6

2010-03-28 Thread Milos Kleint (JIRA)

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

Milos Kleint closed MCOMPILER-75.
-

Resolution: Fixed
Fix Version/s: 2.2
Assignee: Milos Kleint

I've added the parameters for -proc, -processor and -s. -s has a default value
pointing to target/generated-sources/annotations. they all work only with 1.6+
jdk.

I'm unclear how -processorpath shall be added. -Akey=value params are probably
best to be added via the generic parameter.

let's consider this done for 2.2 and open specific issues for any missing
features.

Add apt support for Java 6
--

Key: MCOMPILER-75
URL: http://jira.codehaus.org/browse/MCOMPILER-75
Project: Maven 2.x Compiler Plugin
Issue Type: New Feature
Affects Versions: 2.0.2
Reporter: Mark Hobson
Assignee: Milos Kleint
Fix For: 2.2

Apt (Annotation Processing Tool) was merged into javac in Java 6. The
compiler plugin should support this new functionality, which means supporting
the following new arguments:
{noformat}
-proc:{none,only} Control whether annotation processing and/or
compilation is done.
-processor class1[,class2,class3...]Names of the annotation
processors to run; bypasses default discovery process
-processorpath path Specify where to find annotation processors
-s directory Specify where to place generated source files
-implicit:{none,class} Specify whether or not to generate class files
for implicitly referenced files
-Akey[=value] Options to pass to annotation processors
{noformat}
Note that this should supersede the Apt Maven Plugin at Mojo by encompassing
all of its functionality:
http://mojo.codehaus.org/apt-maven-plugin/index.html

[jira] Created: (MCOMPILER-122) -sourcepath shall include resources

2010-03-28 Thread Milos Kleint (JIRA)

-sourcepath shall include resources
---

 Key: MCOMPILER-122
 URL: http://jira.codehaus.org/browse/MCOMPILER-122
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Milos Kleint


annotation processors which load non-Java resources from the sourcepath, will 
currently get only the src/main/java folder.

Unfortunately just adding src/main/resources to -sourcepath does not suffice, 
due to a bug in javac:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929404

see MCOMPILER-98 for more




-- 
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] Closed: (MCOMPILER-98) -sourcepath not passed to javac

2010-03-28 Thread Milos Kleint (JIRA)


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

Milos Kleint closed MCOMPILER-98.
-

   Resolution: Fixed
Fix Version/s: 2.2

I've opened the MCOMPILER-122 for the resources usecase. closing this one as 
the generic -sourcepath case is fixed.

 -sourcepath not passed to javac
 ---

 Key: MCOMPILER-98
 URL: http://jira.codehaus.org/browse/MCOMPILER-98
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.0.2
 Environment: Ubuntu 8.10, JDK 6.
Reporter: Jesse Glick
Assignee: Milos Kleint
Priority: Critical
 Fix For: 2.2

 Attachments: maven-6647998-test.zip, MCOMPILER-98.diff


 JavacCompiler.java (actually in plexus-compiler-javac, but I cannot find the 
 source project for this anywhere) has
 List sourceLocations = config.getSourceLocations();
 if ( sourceLocations != null  !sourceLocations.isEmpty()  ( 
 sourceFiles.length == 0 ) )
 {
 args.add( -sourcepath );
 args.add( getPathString( sourceLocations ) );
 }
 The sourceFiles.length == 0 clause should be deleted. The problem is that 
 javac really does need to have -sourcepath even when you are passing an 
 explicit list of *.java files; it is necessary for 269-compliant annotation 
 processors:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6647998
 Following is a patch which
 1. Fixes diagnostics to print compiler arguments even for unforked mode. 
 (javac is still run with a command line when unforked, so there is no reason 
 to omit this valuable diagnostic info.)
 2. Hacks maven-compiler-plugin to work around the bug in 
 plexus-compiler-javac and pass -sourcepath. Obviously a fix to p-c-j would be 
 preferable.
 When applied to m-c-p 2.0.2 it allows the test case to build.

-- 
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: (MCOMPILER-6) improve documentation

2010-03-28 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MCOMPILER-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215820#action_215820
 ] 

Milos Kleint commented on MCOMPILER-6:
--

actually according to the sources, the target default value is 1.1 and the 
source default value is 1.3 for jdks 1.4+ and no source is set for older jdks.

 improve documentation
 -

 Key: MCOMPILER-6
 URL: http://jira.codehaus.org/browse/MCOMPILER-6
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Reporter: Brett Porter
 Fix For: 2.2


 some aspects are unclear:
 - compilerVersion is only used when forking
 - fork should indicate that it uses the built in version when false, not an 
 executable.
 Also:
 - don't set parameters that only apply to forking when fork is false to make 
 the code more readable
 - specifiy which are specific to javac, or java in general (perhaps we should 
 be able to assign a @category to a plugin 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] Closed: (MCOMPILER-8) Unable to set the compilerId

2010-03-17 Thread Milos Kleint (JIRA)


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

Milos Kleint closed MCOMPILER-8.


Resolution: Fixed

the correct way of defining alternate compilers also described here:
http://maven.apache.org/plugins/maven-compiler-plugin/non-javac-compilers.html

closing this issue as fixed

 Unable to set the compilerId
 

 Key: MCOMPILER-8
 URL: http://jira.codehaus.org/browse/MCOMPILER-8
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
 Environment: Maven version: 2.0
 java version 1.5.0_05
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
 Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)
 Linux notebook 2.6.12-suspend2-r6 #3 Tue Nov 1 09:16:10 CET 2005 i686 Mobile 
 Intel(R) Pentium(R) 4 CPU 3.06GHz GenuineIntel GNU/Linux
Reporter: Lars Trieloff

 according to the maven-compiler-plugin documentation I can set the
 compiler to be used by adding the compilerId element to my pom.xml.
 However my small example POM which includes following build
 configuration is unable to work with maven.
   build
 pluginManagement
   plugins
 plugin
   artifactIdmaven-compiler-plugin/artifactId
   configuration
 compilerIdeclipse/compilerId
   /configuration
   dependencies
 dependency
   groupIdorg.codehaus.plexus/groupId
   artifactIdplexus-compiler-eclipse/artifactId
   version1.5.1/version
 /dependency
   /dependencies
 /plugin
   /plugins
 /pluginManagement
   /build
 I tell the compiler-plugin to use the eclipse compiler and add it as
 dependency to the compiler-plugin. But when I run maven, it fails with:
 No such compiler 'eclipse'.. The debug output is:
 l...@notebook ~/Projects/Studies/IFIR $ mvn compile -U -e -X
 + Error stacktraces are turned on.
 [DEBUG] Building Maven user-level plugin registry from: 
 '/home/lars/.m2/plugin-registry.xml'
 [DEBUG] Building Maven global-level plugin registry from: 
 '/usr/share/maven2/conf/plugin-registry.xml'
 [INFO] Scanning for projects...
 [INFO] 
 
 [INFO] Building Goshaky Feed Filter
 [INFO]task-segment: [compile]
 [INFO] 
 
 [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for 
 updates from central
 [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository 
 central
 [DEBUG] Retrieving parent-POM from the repository for project: 
 null:maven-resources-plugin:maven-plugin:2.1
 [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for 
 updates from central
 [DEBUG] maven-compiler-plugin: resolved to version 2.0 from repository central
 [DEBUG] Retrieving parent-POM from the repository for project: 
 null:maven-compiler-plugin:maven-plugin:2.0
 [DEBUG] org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.1 
 (selected for runtime)
 [DEBUG] Retrieving parent-POM from the repository for project: 
 org.apache.maven:maven-model:jar:2.0
 [DEBUG]   org.apache.maven:maven-model:jar:2.0 (selected for runtime)
 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime)
 [DEBUG] Retrieving parent-POM from the repository for project: 
 null:maven-project:jar:2.0
 [DEBUG]   org.apache.maven:maven-project:jar:2.0 (selected for runtime)
 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime)
 [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8 
 (selected for runtime)
 [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for 
 runtime)
 [DEBUG]   classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
 [DEBUG]   junit:junit:jar:3.8.1 (selected for runtime)
 [DEBUG] Retrieving parent-POM from the repository for project: 
 org.apache.maven:maven-artifact:jar:2.0
 [DEBUG] org.apache.maven:maven-artifact:jar:2.0 (selected for runtime)
 [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for 
 runtime)
 [DEBUG] org.apache.maven:maven-model:jar:2.0 (selected for runtime)
 [DEBUG] Retrieving parent-POM from the repository for project: 
 org.apache.maven:maven-artifact-manager:jar:2.0
 [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0 (selected for 
 runtime)
 [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for 
 runtime)
 [DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8 
 (selected for runtime)
 [DEBUG]   org.apache.maven:maven-artifact:jar:2.0 (selected for runtime)
 [DEBUG] Retrieving parent-POM from the repository for project: 
 org.apache.maven:maven-repository-metadata:jar:2.0
 [DEBUG]

[jira] Commented: (MNG-4548) Thread.currentThread().getContextClassLoader().getResource doesn't find resource

2010-01-27 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-4548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=208330#action_208330
 ] 

Milos Kleint commented on MNG-4548:
---

context classloader usage can have unwanted sideeffects in embedded execution. 
Eg.  in netbeans module system it will see all modules content in the IDE.

 Thread.currentThread().getContextClassLoader().getResource doesn't find 
 resource 
 -

 Key: MNG-4548
 URL: http://jira.codehaus.org/browse/MNG-4548
 Project: Maven 2  3
  Issue Type: Bug
  Components: Class Loading
Affects Versions: 3.0-alpha-6
Reporter: Olivier Lamy

 Thread.currentThread().getContextClassLoader().getResource cannot find a 
 resource whereas getClass().getResource find it.
 Sample to test it :
 svn co 
 https://svn.codehaus.org/mojo/branches/sonar-maven-plugin-mvn-3.x/experimental/
 cd experimental
 mvn clean install -Prun-its -Dinvoker.streamLogs=true

-- 
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] Closed: (MCOMPILER-55) replace plexus-compiler with commons-jci

2010-01-25 Thread Milos Kleint (JIRA)


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

Milos Kleint closed MCOMPILER-55.
-

Resolution: Won't Fix

this appears to be long due.. closing as wontfix.

 replace plexus-compiler with commons-jci
 

 Key: MCOMPILER-55
 URL: http://jira.codehaus.org/browse/MCOMPILER-55
 Project: Maven 2.x Compiler Plugin
  Issue Type: Task
Reporter: Brett Porter

 I'd like to contribute out plexus-compiler code to jakarta commons-jci and 
 switch to that. This would consolidate the efforts and Torsten has agreed 
 with our discussed separation of api/compilers.

-- 
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: (MCOMPILER-75) Add apt support for Java 6

2010-01-19 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MCOMPILER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207432#action_207432
 ] 

Milos Kleint commented on MCOMPILER-75:
---

the open question with generated-sources/annotation-processing/ output folder 
setting is how do the xml (or other) files end up in the final binary then. 

For generated .java files, the current solution is to add them to the list of 
sourceRoots and they get compiled. For non-compilable resources we would have 
to add them to the list of resources to be processed (but most likely the 
resources processing phase has already passed by that time).

 Add apt support for Java 6
 --

 Key: MCOMPILER-75
 URL: http://jira.codehaus.org/browse/MCOMPILER-75
 Project: Maven 2.x Compiler Plugin
  Issue Type: New Feature
Affects Versions: 2.0.2
Reporter: Mark Hobson

 Apt (Annotation Processing Tool) was merged into javac in Java 6.  The 
 compiler plugin should support this new functionality, which means supporting 
 the following new arguments:
 {noformat}
   -proc:{none,only}  Control whether annotation processing and/or 
 compilation is done.
   -processor class1[,class2,class3...]Names of the annotation 
 processors to run; bypasses default discovery process
   -processorpath path  Specify where to find annotation processors
   -s directory Specify where to place generated source files
   -implicit:{none,class} Specify whether or not to generate class files 
 for implicitly referenced files
   -Akey[=value]  Options to pass to annotation processors
 {noformat}
 Note that this should supersede the Apt Maven Plugin at Mojo by encompassing 
 all of its functionality:
 http://mojo.codehaus.org/apt-maven-plugin/index.html

-- 
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: (MCOMPILER-98) -sourcepath not passed to javac

2010-01-19 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MCOMPILER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207436#action_207436
 ] 

Milos Kleint commented on MCOMPILER-98:
---

http://svn.apache.org/viewvc?rev=900690view=rev
http://fisheye.codehaus.org/changelog/plexus/?cs=8590

the compiler plugin's trunk still references the 1.6 version of the javac 
compiler plugin.

 -sourcepath not passed to javac
 ---

 Key: MCOMPILER-98
 URL: http://jira.codehaus.org/browse/MCOMPILER-98
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.0.2
 Environment: Ubuntu 8.10, JDK 6.
Reporter: Jesse Glick
Priority: Critical
 Attachments: maven-6647998-test.zip, MCOMPILER-98.diff


 JavacCompiler.java (actually in plexus-compiler-javac, but I cannot find the 
 source project for this anywhere) has
 List sourceLocations = config.getSourceLocations();
 if ( sourceLocations != null  !sourceLocations.isEmpty()  ( 
 sourceFiles.length == 0 ) )
 {
 args.add( -sourcepath );
 args.add( getPathString( sourceLocations ) );
 }
 The sourceFiles.length == 0 clause should be deleted. The problem is that 
 javac really does need to have -sourcepath even when you are passing an 
 explicit list of *.java files; it is necessary for 269-compliant annotation 
 processors:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6647998
 Following is a patch which
 1. Fixes diagnostics to print compiler arguments even for unforked mode. 
 (javac is still run with a command line when unforked, so there is no reason 
 to omit this valuable diagnostic info.)
 2. Hacks maven-compiler-plugin to work around the bug in 
 plexus-compiler-javac and pass -sourcepath. Obviously a fix to p-c-j would be 
 preferable.
 When applied to m-c-p 2.0.2 it allows the test case to build.

-- 
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: (MEAR-116) different build results from single module build and from reactor build

2010-01-11 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MEAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206162#action_206162
 ] 

Milos Kleint commented on MEAR-116:
---

I'm not entirely sure this is a ear plugin problem only, could be a general 
feat that just backfires here. The question is how to protect from it.


 different build results from single module build and from reactor build
 ---

 Key: MEAR-116
 URL: http://jira.codehaus.org/browse/MEAR-116
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.4
 Environment: maven 2.2.0
Reporter: Milos Kleint
Priority: Critical
 Attachments: ear116.zip


 attached is a sample application as generated by netbeans 6.8 (using 
 archetypes from org.codehaus.mojo.archetypes)
 a simple ear+ejb+war multiproject.
 when building everything together from the root pom, I get this output:
 [ear:ear]
 Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] 
 to[samplejavaee6-ejb.jar]
 Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] 
 to[samplejavaee6-web.war]
 and the war and ejb artifacts are included with names not including version.
 However if I later do a mvn clean install on the ear project, I get this 
 output:
 [ear:ear]
 Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] 
 to[samplejavaee6-ejb-1.0-SNAPSHOT.jar]
 Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] 
 to[samplejavaee6-web-1.0-SNAPSHOT.war]
 and the war/ejb artifacts get a version in the name.
 This sounds like it has to do with the finalname being resolved differently 
 in single module build and in reactor build.

-- 
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-116) different build results from single module build and from reactor build

2010-01-11 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MEAR-116:
--

Attachment: ear116.zip

here are the projects. 

 different build results from single module build and from reactor build
 ---

 Key: MEAR-116
 URL: http://jira.codehaus.org/browse/MEAR-116
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.4
 Environment: maven 2.2.0
Reporter: Milos Kleint
Priority: Critical
 Attachments: ear116.zip


 attached is a sample application as generated by netbeans 6.8 (using 
 archetypes from org.codehaus.mojo.archetypes)
 a simple ear+ejb+war multiproject.
 when building everything together from the root pom, I get this output:
 [ear:ear]
 Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] 
 to[samplejavaee6-ejb.jar]
 Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] 
 to[samplejavaee6-web.war]
 and the war and ejb artifacts are included with names not including version.
 However if I later do a mvn clean install on the ear project, I get this 
 output:
 [ear:ear]
 Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] 
 to[samplejavaee6-ejb-1.0-SNAPSHOT.jar]
 Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] 
 to[samplejavaee6-web-1.0-SNAPSHOT.war]
 and the war/ejb artifacts get a version in the name.
 This sounds like it has to do with the finalname being resolved differently 
 in single module build and in reactor build.

-- 
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: (MEAR-116) different build results from single module build and from reactor build

2010-01-11 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MEAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206195#action_206195
 ] 

Milos Kleint commented on MEAR-116:
---

the project is basically what we generate in netbeans when someone wants an ear 
maven project. It's backed by archetypes at mojo.codehaus.org.

 different build results from single module build and from reactor build
 ---

 Key: MEAR-116
 URL: http://jira.codehaus.org/browse/MEAR-116
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.4
 Environment: maven 2.2.0
Reporter: Milos Kleint
Priority: Critical
 Attachments: ear116.zip


 attached is a sample application as generated by netbeans 6.8 (using 
 archetypes from org.codehaus.mojo.archetypes)
 a simple ear+ejb+war multiproject.
 when building everything together from the root pom, I get this output:
 [ear:ear]
 Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] 
 to[samplejavaee6-ejb.jar]
 Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] 
 to[samplejavaee6-web.war]
 and the war and ejb artifacts are included with names not including version.
 However if I later do a mvn clean install on the ear project, I get this 
 output:
 [ear:ear]
 Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] 
 to[samplejavaee6-ejb-1.0-SNAPSHOT.jar]
 Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] 
 to[samplejavaee6-web-1.0-SNAPSHOT.war]
 and the war/ejb artifacts get a version in the name.
 This sounds like it has to do with the finalname being resolved differently 
 in single module build and in reactor build.

-- 
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: (MCOMPILER-80) Change default source level to 1.5

2009-12-22 Thread Milos Kleint (JIRA)

[
http://jira.codehaus.org/browse/MCOMPILER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203912#action_203912
]

Milos Kleint commented on MCOMPILER-80:
---

what old version of maven will actually be affected? meaning which one doesn't
set version numbers in super pom? 2.0.9 or older?

There is one big problem with the super-pom solution and that's embedding and
IDE usage. So we might end up with the IDE resolving the version differently
than the cmd maven being used later for building. Or the IDE somehow makes use
of the super-pom of the cmd-line maven being setup in the IDE. And then your
newly created quickstart archetype will be either 1.4 or 1.5 depending on what
cmd maven is on PATH?
In the case when we only change the default value in compiler plugin, the IDE
can figure the default value based on the version of the compiler plugin being
used.

Change default source level to 1.5
--

Key: MCOMPILER-80
URL: http://jira.codehaus.org/browse/MCOMPILER-80
Project: Maven 2.x Compiler Plugin
Issue Type: Improvement
Reporter: Grzegorz Borkowski
Priority: Minor

Deafult source level setting for Maven compiler plugin is 1.3, as far as I
remember. This makes no sense. 1.3 is used at this moment only in legacy
applications. Probability of porting such legacy application to Maven 2 is
very small. I was working with such applications - none of them used Maven.
In fact, I don't know any application using Maven, which requires level 1.3.
On the other hand, Maven is used exensively in new applications. Most of them
use Java 5 features (annotations, generics...). All new applications I create
use Maven 2 and Java 5. Every time I setup such application it makes me crazy
that I get errors on my generics and annoations, and I have to setup manually
the source level to 1.5. Come on, we have year 2008, not 2000! Java 5 is here
for several years already. So why Maven compiler plugin does not use the most
reasonable default approach, instead it still assumes we are in 2000 year? If
someone wants to use old java version, than he can change the source level.
By default should be 1.5.
The default setting can be changed in never wersion of maven compiler plugin.

[jira] Commented: (MCOMPILER-80) Change default source level to 1.5

2009-12-22 Thread Milos Kleint (JIRA)

[
http://jira.codehaus.org/browse/MCOMPILER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203913#action_203913
]

Milos Kleint commented on MCOMPILER-80:
---

BTW this is by far the most voted on issue in MCOMPILER.

Change default source level to 1.5
--

Key: MCOMPILER-80
URL: http://jira.codehaus.org/browse/MCOMPILER-80
Project: Maven 2.x Compiler Plugin
Issue Type: Improvement
Reporter: Grzegorz Borkowski
Priority: Minor

[jira] Commented: (MNG-4368) DefaultArtifactInstaller should only overwrite files if timestamp has changed

2009-12-09 Thread Milos Kleint (JIRA)

[
http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=201927#action_201927
]

Milos Kleint commented on MNG-4368:
---

why should I always change versions when creating a branch? or a clone of
git/hg? don't you get conflicts all over the place when you attempt to merge
it? or even worse you can apply the branches' version to the main trunk.
I can imagine doing so for a long time branch (like m2 vs m3) but not for the
short term will it work or not experiments. That can't be the Right Canonical
Way.

DefaultArtifactInstaller should only overwrite files if timestamp has changed
-

Key: MNG-4368
URL: http://jira.codehaus.org/browse/MNG-4368
Project: Maven 2
Issue Type: Improvement
Environment: Linux, JDK 1.5
Reporter: Johannes Martin
Fix For: 2.2.2, 3.0-alpha-3

install:install (from maven-install-plugin) by default uses
DefaultArtifactInstaller to install artifacts. DefaultArtifactInstaller in
turn uses FileUtils.copyFile(), thereby overwriting destination files even if
they are unchanged. It would be helpful if DefaultArtifactInstaller used
FileUtils.copyFileIfModified() instead, at least as an option, to speed up
the build process.

[jira] Commented: (MNG-4368) DefaultArtifactInstaller should only overwrite files if timestamp has changed

2009-12-09 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=201928#action_201928
 ] 

Milos Kleint commented on MNG-4368:
---

on the constructive side, can we associate the pom file's source stamp with the 
built main artifact? that way a clean build would replace the pom files 
correctly. With the exception of pom packaging I guess..

 DefaultArtifactInstaller should only overwrite files if timestamp has changed
 -

 Key: MNG-4368
 URL: http://jira.codehaus.org/browse/MNG-4368
 Project: Maven 2
  Issue Type: Improvement
 Environment: Linux, JDK 1.5
Reporter: Johannes Martin
 Fix For: 2.2.2, 3.0-alpha-3


 install:install (from maven-install-plugin) by default uses 
 DefaultArtifactInstaller to install artifacts. DefaultArtifactInstaller in 
 turn uses FileUtils.copyFile(), thereby overwriting destination files even if 
 they are unchanged. It would be helpful if DefaultArtifactInstaller used 
 FileUtils.copyFileIfModified() instead, at least as an option, to speed up 
 the build process.

-- 
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-116) different build results from single module build and from reactor build

2009-11-27 Thread Milos Kleint (JIRA)

different build results from single module build and from reactor build
---

 Key: MEAR-116
 URL: http://jira.codehaus.org/browse/MEAR-116
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.4
 Environment: maven 2.2.0
Reporter: Milos Kleint
Priority: Critical


attached is a sample application as generated by netbeans 6.8 (using archetypes 
from org.codehaus.mojo.archetypes)
a simple ear+ejb+war multiproject.

when building everything together from the root pom, I get this output:
[ear:ear]
Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] 
to[samplejavaee6-ejb.jar]
Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] 
to[samplejavaee6-web.war]

and the war and ejb artifacts are included with names not including version.

However if I later do a mvn clean install on the ear project, I get this output:

[ear:ear]
Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] 
to[samplejavaee6-ejb-1.0-SNAPSHOT.jar]
Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] 
to[samplejavaee6-web-1.0-SNAPSHOT.war]

and the war/ejb artifacts get a version in the name.

This sounds like it has to do with the finalname being resolved differently in 
single module build and in reactor build.




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

2009-11-27 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-4060:
---

this doesn't sound like a minor task to me. The only way to have per-project 
non-sharable settings has been removed. Now only global per project settings 
are available in settings.xml. 

It will cause me headaches in netbeans IDE integration eg. the deployment 
server TYPE is noted in the pom.xml as it's something that is usually shared 
across all developers, but the deployment server ID is stored in profiles.xml 
file because the ID token value is user installation based (can include path to 
the server installation)


 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] Commented: (MNG-4060) Remove support for profiles.xml

2009-11-27 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-4060:
---

the fact that mixins are mentioned to be placed in repository, doesn't make 
them a proper replacement of profiles.xml file for user-private settings..


 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] Commented: (MSOURCES-25) Allow additional source directories to be configured

2009-11-19 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MSOURCES-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198743#action_198743
 ] 

Milos Kleint commented on MSOURCES-25:
--

let's see, what about me adding an additionalSourceRoots/additionalSourceRoot 
configuration that would default to src/main/groovy+src/main/scala and if these 
folders exists (which are the default folders for the respective languages 
unfortunately no way to obtain the actual configuration in the given project) 
add the content to the sources jar?

 Allow additional source directories to be configured
 

 Key: MSOURCES-25
 URL: http://jira.codehaus.org/browse/MSOURCES-25
 Project: Maven 2.x Source Plugin
  Issue Type: New Feature
Affects Versions: 2.0.3
Reporter: Benjamin Bentmann
Assignee: Milos Kleint
Priority: Minor

 Currently, the plugin simply archives the compile source roots and resource 
 directories that are known to the POM. However, there may exist further files 
 which do not directly contribute to the build process but are nevertheless to 
 be considered as source files.
 For example, consider a project with the following directories:
 - src/main/java
 - src/main/javacc
 - src/main/jflex
 - src/main/uml
 The directories javacc and jflex provide grammar definitions for 
 generated java files while uml contains UML (or similar) models from which 
 MDA tools create java files. I would consider it useful to package these 
 pre-source files as well into the sources JAR.
 Surely, the assembly-plugin would do the job but since it requires quite a 
 complete build I consider this approach quite unattractive when I want to 
 package up files that are already hanging around in the file system.
 While adding more directory roots to the archive is in principle no big deal 
 for the source-plugin, the major question would be how to nicely configure 
 the plugin to do so. My spontaneous proposal would be an additional 
 configuration parameter sourceDirectories of type File[] with the following 
 semantic:
 If not specified (as would be the case for all currently existing 
 configurations), simply package compile source roots and resources from POM 
 like it does now. If I understand mojo configuration correctly, the mojo 
 parameter would be null in this case.
 Otherwise (i.e. if POM configuration contains sourceDirectories element), 
 ONLY those directories listed up here should be packaged. This would allow 
 precise control what the plugin packages. For example, if one does not want 
 to package resources, simply omit to list up their root directory. For my 
 formerly mentioned example, one would need to write:
 {code:xml}
 sourceDirectories
   sourceDirectorysrc/main/java/sourceDirectory
   sourceDirectorysrc/main/javacc/sourceDirectory
   sourceDirectorysrc/main/jflex/sourceDirectory
   sourceDirectorysrc/main/uml/sourceDirectory
 /sourceDirectories
 {code}
 (BTW, not sure whether Plexus can actually handle the non-standard plural 
 form ending with ies).
 Of course, things are not that simple... The above illustrated approach 
 conflicts with the current solution for MSOURCES-22. Furthermore, the plugin 
 is currently aware of includes/excludes for the resources being packaged. 
 This cannot be realized by a simple configuration parameter of type File[], 
 i.e. sourceDirectorysrc/main/resources/sourceDirectory would not be 
 equivalent to the default behavior, causing confusion. Therefore, one might 
 need something like a SourceDirectory bean that holds the directory path and 
 optional includes/excludes (similar to an Ant fileset).

-- 
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: (MSOURCES-25) Allow additional source directories to be configured

2009-11-19 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MSOURCES-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198754#action_198754
 ] 

Milos Kleint commented on MSOURCES-25:
--

the only problem seems to be aggregate goal which is not capable of retrieving 
the configuration from the reactor projects..

 Allow additional source directories to be configured
 

 Key: MSOURCES-25
 URL: http://jira.codehaus.org/browse/MSOURCES-25
 Project: Maven 2.x Source Plugin
  Issue Type: New Feature
Affects Versions: 2.0.3
Reporter: Benjamin Bentmann
Assignee: Milos Kleint
Priority: Minor

 Currently, the plugin simply archives the compile source roots and resource 
 directories that are known to the POM. However, there may exist further files 
 which do not directly contribute to the build process but are nevertheless to 
 be considered as source files.
 For example, consider a project with the following directories:
 - src/main/java
 - src/main/javacc
 - src/main/jflex
 - src/main/uml
 The directories javacc and jflex provide grammar definitions for 
 generated java files while uml contains UML (or similar) models from which 
 MDA tools create java files. I would consider it useful to package these 
 pre-source files as well into the sources JAR.
 Surely, the assembly-plugin would do the job but since it requires quite a 
 complete build I consider this approach quite unattractive when I want to 
 package up files that are already hanging around in the file system.
 While adding more directory roots to the archive is in principle no big deal 
 for the source-plugin, the major question would be how to nicely configure 
 the plugin to do so. My spontaneous proposal would be an additional 
 configuration parameter sourceDirectories of type File[] with the following 
 semantic:
 If not specified (as would be the case for all currently existing 
 configurations), simply package compile source roots and resources from POM 
 like it does now. If I understand mojo configuration correctly, the mojo 
 parameter would be null in this case.
 Otherwise (i.e. if POM configuration contains sourceDirectories element), 
 ONLY those directories listed up here should be packaged. This would allow 
 precise control what the plugin packages. For example, if one does not want 
 to package resources, simply omit to list up their root directory. For my 
 formerly mentioned example, one would need to write:
 {code:xml}
 sourceDirectories
   sourceDirectorysrc/main/java/sourceDirectory
   sourceDirectorysrc/main/javacc/sourceDirectory
   sourceDirectorysrc/main/jflex/sourceDirectory
   sourceDirectorysrc/main/uml/sourceDirectory
 /sourceDirectories
 {code}
 (BTW, not sure whether Plexus can actually handle the non-standard plural 
 form ending with ies).
 Of course, things are not that simple... The above illustrated approach 
 conflicts with the current solution for MSOURCES-22. Furthermore, the plugin 
 is currently aware of includes/excludes for the resources being packaged. 
 This cannot be realized by a simple configuration parameter of type File[], 
 i.e. sourceDirectorysrc/main/resources/sourceDirectory would not be 
 equivalent to the default behavior, causing confusion. Therefore, one might 
 need something like a SourceDirectory bean that holds the directory path and 
 optional includes/excludes (similar to an Ant fileset).

-- 
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: (MJAVADOC-268) performance problem in AbstractJavadocMojo.getModulesLinks()

2009-10-13 Thread Milos Kleint (JIRA)

performance problem in AbstractJavadocMojo.getModulesLinks()


 Key: MJAVADOC-268
 URL: http://jira.codehaus.org/browse/MJAVADOC-268
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.6
 Environment: Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
Java version: 1.6.0_13
Java home: /home/mkleint/javatools/jdk1.6.0_13/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 2.6.29.6-desktop-2mnb arch: i386 Family: unix
Reporter: Milos Kleint
Priority: Critical
 Attachments: javadoc.patch

The getModulesLinks() method is unacceptably slow under certain conditions:
1. project's url is defined
2. one or more projects in reactor do not have any java sources and are not of 
pom packaging.
For such projects the apidocs/ output folder is never created resulting in 
repeated invokation of a forked javadoc goal. It's more severe with high number 
of modules in reactor and high number of modules without any java sources.

as an example checkout hg clone https://hg.kenai.com/hg/forceten~src;

The immediate problem is in the apidocsFile.exists() condition that re-triggers 
the forked invokation. The attached patch fixes that. However it looks 
suspicitions that the method is being called repeatedly for each module at all. 
Maybe the aborting condition at the start of the method body is wrong (I was 
not able to decypher that)

workaround is to use 2.5 or not to specify the url in pom.xml or set the 
detectOfflineLinks parameter to false.

-- 
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: (MJAVADOC-268) performance problem in AbstractJavadocMojo.getModulesLinks()

2009-10-13 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MJAVADOC-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=194530#action_194530
 ] 

Milos Kleint commented on MJAVADOC-268:
---

originally reported at http://forums.netbeans.org/topic18558.html

 performance problem in AbstractJavadocMojo.getModulesLinks()
 

 Key: MJAVADOC-268
 URL: http://jira.codehaus.org/browse/MJAVADOC-268
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.6
 Environment: Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
 Java version: 1.6.0_13
 Java home: /home/mkleint/javatools/jdk1.6.0_13/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux version: 2.6.29.6-desktop-2mnb arch: i386 Family: unix
Reporter: Milos Kleint
Priority: Critical
 Attachments: javadoc.patch


 The getModulesLinks() method is unacceptably slow under certain conditions:
 1. project's url is defined
 2. one or more projects in reactor do not have any java sources and are not 
 of pom packaging.
 For such projects the apidocs/ output folder is never created resulting in 
 repeated invokation of a forked javadoc goal. It's more severe with high 
 number of modules in reactor and high number of modules without any java 
 sources.
 as an example checkout hg clone https://hg.kenai.com/hg/forceten~src;
 The immediate problem is in the apidocsFile.exists() condition that 
 re-triggers the forked invokation. The attached patch fixes that. However it 
 looks suspicitions that the method is being called repeatedly for each module 
 at all. Maybe the aborting condition at the start of the method body is wrong 
 (I was not able to decypher that)
 workaround is to use 2.5 or not to specify the url in pom.xml or set the 
 detectOfflineLinks parameter to false.

-- 
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: (MAVENUPLOAD-2560) Synchronizing the org.jvnet repository to central

2009-08-14 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187135#action_187135
 ] 

Milos Kleint commented on MAVENUPLOAD-2560:
---

the document 
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
says: 
After you are able to deploy to your remote repository make sure you only 
deploy releases. 

Unfortunately it's not tru of the java.net repository.

there are some snapshots there:
Eg. http://download.java.net/maven/2/org/jvnet/winp/winp/ or 
http://download.java.net/maven/2/org/jvnet/wagon-svn/wagon-svn/
(just randomly picked some)

does the rsync location filter out the snapshots?




 Synchronizing the org.jvnet repository to central
 -

 Key: MAVENUPLOAD-2560
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2560
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Kohsuke Kawaguchi

 The CSV entry for the sync:
 {noformat}
 org.jvnet,rsync://maven.hudson-ci.org/maven.org.jvnet,rsync,Kohsuke 
 Kawaguchi,k...@kohsuke.org,,
 {noformat}
 The proof of the ownership of the domain can be confirmed by verifying that 
 jvnet.org belongs to java.net (more specifically Sun Microsystems --- 
 http://www.whois.net/whois/jvnet.org). I couldn't find an authoritative 
 document saying that this belongs to java.net, but as a java.net community 
 leader, I can vouch for that. You can also see a number of existing java.net 
 projects that publish in this group ID ( http://maven.dyndns.org/2/org/jvnet/ 
 )
 I'm requesting this as an administrator of java.net Maven2 repository, and 
 you can find my ID (super_kohsuke) in https://maven2-repository.dev.java.net/
 I also wanted to mention that this groupId shadows MAVENUPLOAD-2515. I 
 currently set up my rsync daemon not to serve org.jvnet.hudson from 
 rsync://maven.hudson-ci.org/maven.org.jvnet , but if it's easier for you 
 guys, I'm happy to have org.jvnet.hudson sync removed, and sync it through 
 this channel instead.

-- 
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: (MEAR-112) support for java ee 6 missing

2009-08-13 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MEAR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=186928#action_186928
 ] 

Milos Kleint commented on MEAR-112:
---

Stephane, what is the current estimate for a new release of the 
maven-ear-plugin?  I'm using the snapshot of the plugin in the javaee6-ear 
archetype at mojo. And that archetype will be used in NetBeans 6.8 (which shall 
support java ee 6). So I would need a new release of the plugin in the coming 
month or so. Is that possible? I'm willing to go through the release process 
myself, but I'm missing the overall context..


 support for java ee 6 missing
 -

 Key: MEAR-112
 URL: http://jira.codehaus.org/browse/MEAR-112
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
Affects Versions: 2.3.2
Reporter: Milos Kleint
Assignee: Milos Kleint

 the version parameter only accepts 1.3, 1.4 and 5 as valid values. It needs 
 to be extended to allow also 6 as a valid 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] Closed: (MEAR-112) support for java ee 6 missing

2009-08-13 Thread Milos Kleint (JIRA)


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

Milos Kleint closed MEAR-112.
-

   Resolution: Fixed
Fix Version/s: 2.4

yes it's done as far as I know,
 
please review these two changesets:
http://svn.apache.org/viewvc?rev=802682view=rev
http://svn.apache.org/viewvc?view=revrevision=802756


 support for java ee 6 missing
 -

 Key: MEAR-112
 URL: http://jira.codehaus.org/browse/MEAR-112
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
Affects Versions: 2.3.2
Reporter: Milos Kleint
Assignee: Milos Kleint
 Fix For: 2.4


 the version parameter only accepts 1.3, 1.4 and 5 as valid values. It needs 
 to be extended to allow also 6 as a valid 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] Reopened: (MAVENUPLOAD-2518) netbeans ant tasks for creating netbeans modules (as shipped with netbeans 6.7)

2009-08-13 Thread Milos Kleint (JIRA)

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

Milos Kleint reopened MAVENUPLOAD-2518:
---

Sorry Carlos,
I've fucked up.
I copypasted the tasks pom from an earlier version which had dependency on
ant:ant:1.7.0. I changed the version only to 1.7.1 without double checking the
artifact actually exists. It seems even the 1.7.0 is only a relocation to
org.apache.ant:ant:1.7.0.

I see two possible solutions.
1. add relocation pom for ant:ant:1.7.1
2. update the groupID of the ant dependency in the tasks pom.

Sorry..

netbeans ant tasks for creating netbeans modules (as shipped with netbeans
6.7)
---

Key: MAVENUPLOAD-2518
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2518
Project: Maven Upload Requests
Issue Type: Wish
Reporter: Milos Kleint
Assignee: Carlos Sanchez
Attachments: tasks67.jar

netbeans ant tasks to create netbeans modules.
the jar is coming straight from the netbeans binary download of NetBeans 6.0
FCS. The jar is located at netbeans/harness/tasks.jar in the binary distro.
It's required by the nbm-maven-plugin from codehaus.org
released under dual license CDDL 1.0 + GPL 2.0 with classpath exception
I'm technically not a developer of the ant tasks, but I'm a Netbeans.org
contributor for 8 years , employed by Sun Microsystems.

[jira] Created: (MEAR-112) support for java ee 6 missing

2009-08-10 Thread Milos Kleint (JIRA)

support for java ee 6 missing
-

 Key: MEAR-112
 URL: http://jira.codehaus.org/browse/MEAR-112
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
Affects Versions: 2.3.2
Reporter: Milos Kleint


the version parameter only accepts 1.3, 1.4 and 5 as valid values. It needs to 
be extended to allow also 6 as a valid 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: (MEAR-112) support for java ee 6 missing

2009-08-10 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MEAR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=186527#action_186527
 ] 

Milos Kleint commented on MEAR-112:
---

basic work here, still needs some work - 
http://svn.apache.org/viewvc?rev=802682view=rev

 support for java ee 6 missing
 -

 Key: MEAR-112
 URL: http://jira.codehaus.org/browse/MEAR-112
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
Affects Versions: 2.3.2
Reporter: Milos Kleint
Assignee: Milos Kleint

 the version parameter only accepts 1.3, 1.4 and 5 as valid values. It needs 
 to be extended to allow also 6 as a valid 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] Created: (MAVENUPLOAD-2518) netbeans ant tasks for creating netbeans modules (as shipped with netbeans 6.7)

2009-07-14 Thread Milos Kleint (JIRA)

netbeans ant tasks for creating netbeans modules (as shipped with netbeans 6.7)
---

 Key: MAVENUPLOAD-2518
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2518
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Milos Kleint
 Attachments: tasks67.jar

netbeans ant tasks to create netbeans modules.
the jar is coming straight from the netbeans binary download of NetBeans 6.0 
FCS. The jar is located at netbeans/harness/tasks.jar in the binary distro.
It's required by the nbm-maven-plugin from codehaus.org

released under dual license CDDL 1.0 + GPL 2.0 with classpath exception

I'm technically not a developer of the ant tasks, but I'm a Netbeans.org 
contributor for 8 years , employed by Sun Microsystems.

-- 
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-4041) embedder returns stale maven project state

2009-06-09 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179738#action_179738
 ] 

Milos Kleint commented on MNG-4041:
---

Igor: allowing custom cache implementations in the container is more than 
enough, I never meant to suggest tat weak references shall be used by default..

 embedder returns stale maven project state
 --

 Key: MNG-4041
 URL: http://jira.codehaus.org/browse/MNG-4041
 Project: Maven 2
  Issue Type: Bug
  Components: Embedding
Affects Versions: 3.0-alpha-2
Reporter: Igor Fedorenko
 Fix For: 3.0-alpha-3

 Attachments: MNG-4041-c.diff, MNG-4041-c.diff, MNG-4041.diff, 
 staleproject.zip


 Embedder returns stale maven project state after project's pom.xml changed 
 and re-read. This is extremely common scenario when using embedder in IDE 
 like m2e. See attached sample project that demonstrates one of many possible 
 ways to trigger this problem.
 The problem appears to be related to static (!) MavenProject cache in 
 DefaultMavenProjectBuilder, which means that even recreating embedder 
 instance is not going to purge state cache entries.
 Also note that using artifact#getId does not provide enough context to 
 uniquely identify cached MavenProject instances. This is particularly true 
 for IDEs where the same embedder instance is likely to be used to process 
 unrelated projects. Cached MavenProject instances should be identified at 
 least by the following attributes
 * project artifact id
 * values of all properties
 * all active profiles
 * content of all pom.xml files directly and indirectly involved in 
 construction of maven project instance
 * IDE specific state, like m2e enable workspace dependency resolution
 * likely more...

-- 
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-4041) embedder returns stale maven project state

2009-06-05 Thread Milos Kleint (JIRA)

[
http://jira.codehaus.org/browse/MNG-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179385#action_179385
]

Milos Kleint commented on MNG-4041:
---

it would be nice to have an option to put a custom caching strategy in place.
With the old 2.1 snapshots, there was a Workspace*someting* component. it was
purged after each call to project resolution. Changing it to timed weak
references I was able to speed up the loading of multiple projects
significantly, while cleaning up in the long run..

embedder returns stale maven project state
--

Key: MNG-4041
URL: http://jira.codehaus.org/browse/MNG-4041
Project: Maven 2
Issue Type: Bug
Components: Embedding
Affects Versions: 3.0-alpha-2
Reporter: Igor Fedorenko
Fix For: 3.0-alpha-3

Attachments: MNG-4041.diff, staleproject.zip

Embedder returns stale maven project state after project's pom.xml changed
and re-read. This is extremely common scenario when using embedder in IDE
like m2e. See attached sample project that demonstrates one of many possible
ways to trigger this problem.
The problem appears to be related to static (!) MavenProject cache in
DefaultMavenProjectBuilder, which means that even recreating embedder
instance is not going to purge state cache entries.
Also note that using artifact#getId does not provide enough context to
uniquely identify cached MavenProject instances. This is particularly true
for IDEs where the same embedder instance is likely to be used to process
unrelated projects. Cached MavenProject instances should be identified at
least by the following attributes
* project artifact id
* values of all properties
* all active profiles
* content of all pom.xml files directly and indirectly involved in
construction of maven project instance
* IDE specific state, like m2e enable workspace dependency resolution
* likely more...

[jira] Commented: (MNG-4131) MavenXpp3Writer.write( writer, model ) does not write the groupId for plugin sections under pluginManagement when the groupId is org.apache.maven.plugins

2009-04-14 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=172873#action_172873
 ] 

Milos Kleint commented on MNG-4131:
---

afaik if anything has a default value defined in the model, then the xpp3 
writer will remove it. 
Additionally it doesn't respect previous formatting so it might not be the best 
pick for processing and writing poms.


 MavenXpp3Writer.write( writer, model ) does not write the groupId for 
 plugin sections under pluginManagement when the groupId is 
 org.apache.maven.plugins
 ---

 Key: MNG-4131
 URL: http://jira.codehaus.org/browse/MNG-4131
 Project: Maven 2
  Issue Type: Bug
  Components: Embedding
Affects Versions: 2.0.9, 3.0-alpha-1
Reporter: nambi sankaran

 I need to update the some sections of a super pom file for every release. 
 Instead of writing a script, I am using maven-model library to read the Model 
 of the pom.xml and update my stuff.
 then I am simply writing the file back into disk
 Following is the code.
   BufferedReader in = new BufferedReader( new 
 FileReader(pomFilePath) );
   
   MavenXpp3Reader reader = new MavenXpp3Reader();
   
   Model model = reader.read(in);
   
   in.close();
   
   DistributionManagement dMgmt = 
 model.getDistributionManagement();
   DeploymentRepository repository = dMgmt.getRepository();
   
   repository.setUrl(repositoryUrl);
   
   // write the pom file
   BufferedWriter out = new BufferedWriter(new FileWriter( 
 pomFilePath ));
   MavenXpp3Writer writer = new MavenXpp3Writer();
   
   writer.write(out, model);
 MavenXpp3Writer.write( writer, model ) does not write the groupId for 
 plugin sections under pluginManagement when the groupId is 
 org.apache.maven.plugins
 Following is the code that does  the work
 private void writePlugin(Plugin plugin, String tagName, XmlSerializer 
 serializer)
 throws java.io.IOException
 {
 if ( plugin != null )
 {
 serializer.startTag( NAMESPACE, tagName );
 if ( plugin.getGroupId() != null  !plugin.getGroupId().equals( 
 org.apache.maven.plugins ) )
 {
 serializer.startTag( NAMESPACE, groupId ).text( 
 plugin.getGroupId() ).endTag( NAMESPACE, groupId );
 }
 As you see, the writePlugin method does not write the groupId , when the 
 groupId is null or org.apache.maven.plugins
 Is this intended or a bug?

-- 
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: (MCOMPILER-66) Compiler swallows messages from annotation processors

2009-04-14 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MCOMPILER-66:
--

Affects Version/s: 2.1
   2.0.2

 Compiler swallows messages from annotation processors
 -

 Key: MCOMPILER-66
 URL: http://jira.codehaus.org/browse/MCOMPILER-66
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.0.2, 2.1
Reporter: Evan Cowden
 Attachments: AnnotationProcessorMessagerBug.zip


 When using the annotation processor API to print messages through the 
 javax.annotation.processing.Messager object, only messagesspecified by levels 
 javax.tools.Diagnostic.Kind.ERROR and 
 javax.tools.Diagnostic.Kind.MANDATORY_WARNING are displayed (and cause the 
 build to fail).  All other messages are swallowed.
 Note that while the attached JUnit test case is necessary to help expose the 
 problem, passing it will not imply that the bug is fixed.  The only way to 
 confirm the fix (that I know of) is to examine console output.

-- 
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: (MCOMPILER-66) Compiler swallows messages from annotation processors

2009-04-14 Thread Milos Kleint (JIRA)

[
http://jira.codehaus.org/browse/MCOMPILER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=172895#action_172895
]

Milos Kleint commented on MCOMPILER-66:
---

If the compiler plugin is configured to show warnings, all messages appear. The
build still fails.

@JesseGlick: The JavaCCompiler.java's message parsing fails and a generic
message including all output is printed. The code you mention is still weird
and would probably swallow the output for some more complicated (read
real-life) outputs.

Compiler swallows messages from annotation processors
-

Key: MCOMPILER-66
URL: http://jira.codehaus.org/browse/MCOMPILER-66
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.0.2, 2.1
Reporter: Evan Cowden
Attachments: AnnotationProcessorMessagerBug.zip

When using the annotation processor API to print messages through the
javax.annotation.processing.Messager object, only messagesspecified by levels
javax.tools.Diagnostic.Kind.ERROR and
javax.tools.Diagnostic.Kind.MANDATORY_WARNING are displayed (and cause the
build to fail). All other messages are swallowed.
Note that while the attached JUnit test case is necessary to help expose the
problem, passing it will not imply that the bug is fixed. The only way to
confirm the fix (that I know of) is to examine console output.

[jira] Moved: (MECLIPSE-535) java.lang.NoClassDefFoundError: org/maven/ide/eclipse/jdt/internal/MavenClasspathContainerSaveHelper

2009-03-23 Thread Milos Kleint (JIRA)


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

Milos Kleint moved MEVENIDE-681 to MECLIPSE-535:


Workflow: Maven New  (was: jira)
 Key: MECLIPSE-535  (was: MEVENIDE-681)
 Project: Maven 2.x Eclipse Plugin  (was: mevenide)

 java.lang.NoClassDefFoundError: 
 org/maven/ide/eclipse/jdt/internal/MavenClasspathContainerSaveHelper
 

 Key: MECLIPSE-535
 URL: http://jira.codehaus.org/browse/MECLIPSE-535
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
 Environment: mngeclipse 0.9.7, eclipse Version: 3.4.2
 Build id: M20090211-1700
Reporter: Tomasz Bartczak
Assignee: Milos Kleint

 when starting eclipse and when doing sth in the IDE - opening new file  - it 
 pops up.
 the class in one jar in plugins dir of eclipse

-- 
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: (MECLIPSE-535) java.lang.NoClassDefFoundError: org/maven/ide/eclipse/jdt/internal/MavenClasspathContainerSaveHelper

2009-03-23 Thread Milos Kleint (JIRA)


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

Milos Kleint updated MECLIPSE-535:
--

   Assignee: (was: Milos Kleint)
Component/s: M2Eclipse support

not sure if this is the right component, I could not find MNGECLIPSE in the 
list of possible projects to move to.

 java.lang.NoClassDefFoundError: 
 org/maven/ide/eclipse/jdt/internal/MavenClasspathContainerSaveHelper
 

 Key: MECLIPSE-535
 URL: http://jira.codehaus.org/browse/MECLIPSE-535
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
  Components: M2Eclipse support
 Environment: mngeclipse 0.9.7, eclipse Version: 3.4.2
 Build id: M20090211-1700
Reporter: Tomasz Bartczak

 when starting eclipse and when doing sth in the IDE - opening new file  - it 
 pops up.
 the class in one jar in plugins dir of eclipse

-- 
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: (MNG-4055) wrong error on mvn install in folder without pom.xml

2009-02-27 Thread Milos Kleint (JIRA)

wrong error on mvn install in folder without pom.xml 
-

 Key: MNG-4055
 URL: http://jira.codehaus.org/browse/MNG-4055
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 3.0-alpha-2
Reporter: Milos Kleint


a folder without maven's pom.xml file. running mvn install there-


[mkle...@localhost glassfish]$ ~/javatools/apache-maven-3.0-alpha-2/bin/mvn 
install
[INFO] Scanning for projects...
[INFO] 
[INFO] Building Maven Default Project
[INFO]
[INFO] Id: org.apache.maven:super-pom:jar:3.0-SNAPSHOT
[INFO] task-segment: [install]
[INFO] 
[ERROR]
Internal error in the plugin manager executing goal 
'org.apache.maven.plugins:maven-resources-plugin:2.2:resources': Cannot execute 
mojo: resources. It requires a project with an existing pom.xml, but the build 
is not using one.

While building project with id: org.apache.maven:super-pom:jar:3.0-SNAPSHOT



-- 
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: (MREACTOR-11) Can't pass a parameter with a comma to -Dmake.goals

2009-01-20 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MREACTOR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=161706#action_161706
 ] 

Milos Kleint commented on MREACTOR-11:
--

the invoker component seems to have special setters for profiles and 
properties. I'm wondering if we shall have special parameters for those in the 
reactor:make mojo as well..

 Can't pass a parameter with a comma to -Dmake.goals
 ---

 Key: MREACTOR-11
 URL: http://jira.codehaus.org/browse/MREACTOR-11
 Project: Maven 2.x Reactor Plugin
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Henri Tremblay
 Attachments: comma.patch


 If tried to do
 {{mvn reactor:make -Dmake.goals=install,-Pprofile1,profile2}}
 If fails because {{-Pprofile1,profile2}} is split in two parameters.
 My solution was to be able to escape a comma by doubling it. 
 Its implementation and the test case are in attachment.

-- 
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-468) ability to consistently apply a toolchain across plugins

2008-10-08 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=150278#action_150278
 ] 

Milos Kleint commented on MNG-468:
--

yes, I guess we can close it.

 ability to consistently apply a toolchain across plugins
 

 Key: MNG-468
 URL: http://jira.codehaus.org/browse/MNG-468
 Project: Maven 2
  Issue Type: New Feature
  Components: Settings
Reporter: Brett Porter
Assignee: Milos Kleint
Priority: Critical
 Fix For: 3.0

 Attachments: build.properties, project.properties


 for things like the JDK, it may be desirable to compile, jar etc. across the 
 board with a particular version of the toolchain, other than the one 
 currently executing. It would be good to be able to configure this location 
 in the settings.xml and have the plugins use it, forking the compiler, using 
 a particular runtime, and generating an appropriate manifest.
 This is likely to be relevant to other languages too.

-- 
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-3688) Not activating profiles correctly

2008-07-29 Thread Milos Kleint (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=143431#action_143431
 ] 

Milos Kleint commented on MNG-3688:
---

the netbeans integration is using 2.1-SNAPSHOT maven embedder. The version 
bundled with 3.1.3 is 20080522.



 Not activating profiles correctly
 -

 Key: MNG-3688
 URL: http://jira.codehaus.org/browse/MNG-3688
 Project: Maven 2
  Issue Type: Bug
  Components: Embedding, IDEs
Affects Versions: 2.1
Reporter: Magne Nordtveit
 Attachments: profilereprod.tar.gz


 Mevenide doesn't properly load profiles based on activation/. More 
 correctly, it doesn't properly not activate a profile when
 activation
 file
 missingsome.file/missing
 /file
 /activation
 is specified. The profile is activated regardless when running from netbeans.
 maven 2.0.9 console:
 Activated Profiles:
 test-active
 maven 2.1-SNAPSHOT console:
 Activated Profiles:
 test-active
 mevenide 3.1.3 (NB61FCS branch):
 Activated Profiles
 test-active
 test-not-active
 test-not-active should only be activated when pom.xml is missing.
 Test project attached.

-- 
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] Moved: (MNG-3688) Not activating profiles correctly

2008-07-29 Thread Milos Kleint (JIRA)


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

Milos Kleint moved MEVENIDE-652 to MNG-3688:


 Assignee: (was: Anuradha Gunasekara)
Affects Version/s: (was: NB_3.1)
   2.1
  Component/s: (was: mevenide2-netbeans)
   IDEs
   Embedding
   Complexity: Intermediate
 Workflow: Maven New  (was: jira)
  Key: MNG-3688  (was: MEVENIDE-652)
  Project: Maven 2  (was: mevenide)

 Not activating profiles correctly
 -

 Key: MNG-3688
 URL: http://jira.codehaus.org/browse/MNG-3688
 Project: Maven 2
  Issue Type: Bug
  Components: Embedding, IDEs
Affects Versions: 2.1
Reporter: Magne Nordtveit
 Attachments: profilereprod.tar.gz


 Mevenide doesn't properly load profiles based on activation/. More 
 correctly, it doesn't properly not activate a profile when
 activation
 file
 missingsome.file/missing
 /file
 /activation
 is specified. The profile is activated regardless when running from netbeans.
 maven 2.0.9 console:
 Activated Profiles:
 test-active
 maven 2.1-SNAPSHOT console:
 Activated Profiles:
 test-active
 mevenide 3.1.3 (NB61FCS branch):
 Activated Profiles
 test-active
 test-not-active
 test-not-active should only be activated when pom.xml is missing.
 Test project attached.

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

1 2 3 >

1 - 100 of 223 matches

Mail list logo