[jira] Commented: (MNG-2199) Version ranges not supported for parent artifacts
[
http://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208812#action_208812
]
Joost den Boer commented on MNG-2199:
-
Don't agree with Todor. Using relative path is not a solution since lots of
projects have a (company wide) parent pom but are not part of a multi-module
project.
As Sylvain said version ranges would be very handy when changing release
configuration, license, etc and those are exactly the kind of things you want
to configure globally for all company projects. All clients I have worked for
have their own main pom in which they define this kind of things. Now, when a
new version of that main pom is released, it's a nightmare to change all poms
that use it directly and indirectly.
So for me a +1 for this issue.
> Version ranges not supported for parent artifacts
> -
>
> Key: MNG-2199
> URL: http://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: 3.x (to be reviewed)
>
>
> It would be great if Maven supports version ranges when specifying parent
> artifacts in a multi-module build. Currently this does not work.
>
> artifactId
> groupId
> [2.0, 2.0.1]
>
> [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
>
> artifactId
> groupId
> [2.0, ${pom.version}]
>
> [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 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: (MSITE-222) -D command line options not recognised
[
http://jira.codehaus.org/browse/MSITE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=209128#action_209128
]
Joost den Boer commented on MSITE-222:
--
I run into the same problem when trying to use a Bamboo buildkey in a link in
site.xml. I want to define this globally and not for each project.
The maven goal I use for testing is: 'mvn clean site
-DbambooBuildKey=PROJ-MAIN'. When running on Bamboo I can change this to 'mvn
clean site -DbambooBuildKey=${bamboo.buildKey}' to dynamically have the Bamboo
buildkey available in the project.
When I use ${bambooBuildKey} in a link href in the site.xml, the link contains
'${bambooBuildKey}' and not the substituted value.
If I define a property in the pom
${bambooBuildKey} this value is correct when
running maven; projectBuildKey=PROJ-MAIN.
When using ${projectBuildKey} in the site.xml, the result contains
'${bambooBuildKey}' so 'projectBuildKey' value is substituted but not for the
correct value.
> -D command line options not recognised
> --
>
> Key: MSITE-222
> URL: http://jira.codehaus.org/browse/MSITE-222
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
> Environment: Windows XP, Java 1.5_06
>Reporter: Carl Husselbee
>
> It appears as if passing command line args to maven are not being ignored by
> the site plugin.
> I am passing arguments:
> mvn -P weblogic -DbootstrapProperty=/testbootstrap.properties
> -Dhelm.target=dev package site
> and the package is getting the bootstrapProperty property correctly, but when
> the site target is executed the
> property is unset.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-222) -D command line options not recognised
[
http://jira.codehaus.org/browse/MSITE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=209128#action_209128
]
Joost den Boer edited comment on MSITE-222 at 2/4/10 6:00 AM:
--
I run into the same problem when trying to use a Bamboo buildkey in a link in
site.xml. I want to define this globally and not for each project.
The maven goal I use for testing is: 'mvn clean site
-DbambooBuildKey=PROJ-MAIN'. When running on Bamboo I can change this to 'mvn
clean site -DbambooBuildKey=${bamboo.buildKey}' to dynamically have the Bamboo
buildkey available in the project.
When I use ${bambooBuildKey} in a link href in the site.xml, the link contains
'${bambooBuildKey}' and not the substituted value.
If I define a property in the pom
${bambooBuildKey} this value is correct when
running maven; projectBuildKey=PROJ-MAIN.
When using ${projectBuildKey} in the site.xml, the result contains
'${bambooBuildKey}' so 'projectBuildKey' value is substituted but not for the
correct value.
Problem occurs in version 2.0-beta7. Tried version 2.1 but got exception
because there are 2 versions of the Log class.
Env: XP with Maven 2.2.0 and Java 1.5.014.
was (Author: jdboer):
I run into the same problem when trying to use a Bamboo buildkey in a link
in site.xml. I want to define this globally and not for each project.
The maven goal I use for testing is: 'mvn clean site
-DbambooBuildKey=PROJ-MAIN'. When running on Bamboo I can change this to 'mvn
clean site -DbambooBuildKey=${bamboo.buildKey}' to dynamically have the Bamboo
buildkey available in the project.
When I use ${bambooBuildKey} in a link href in the site.xml, the link contains
'${bambooBuildKey}' and not the substituted value.
If I define a property in the pom
${bambooBuildKey} this value is correct when
running maven; projectBuildKey=PROJ-MAIN.
When using ${projectBuildKey} in the site.xml, the result contains
'${bambooBuildKey}' so 'projectBuildKey' value is substituted but not for the
correct value.
> -D command line options not recognised
> --
>
> Key: MSITE-222
> URL: http://jira.codehaus.org/browse/MSITE-222
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
> Environment: Windows XP, Java 1.5_06
>Reporter: Carl Husselbee
>
> It appears as if passing command line args to maven are not being ignored by
> the site plugin.
> I am passing arguments:
> mvn -P weblogic -DbootstrapProperty=/testbootstrap.properties
> -Dhelm.target=dev package site
> and the package is getting the bootstrapProperty property correctly, but when
> the site target is executed the
> property is unset.
--
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-2549) Plugin dependencies are not put in generated plugin.xml
Plugin dependencies are not put in generated plugin.xml --- Key: MNG-2549 URL: http://jira.codehaus.org/browse/MNG-2549 Project: Maven 2 Issue Type: Bug Components: Plugin Creation Tools Affects Versions: 2.0.4 Reporter: Joost den Boer In a plugin project, the dependencies of the project are not placed in the META-INF/maven/plugin.xml which is generated by Maven. In the documentation I can not find the feature or annotation to make this happen, so maybe it does not exist yet. -- 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-2550) ClassNotFoundException and NoClassDefFoundError when running plugin
ClassNotFoundException and NoClassDefFoundError when running plugin --- Key: MNG-2550 URL: http://jira.codehaus.org/browse/MNG-2550 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.4 Reporter: Joost den Boer I created a plugin which runs a small application which does some parsing, logging and serializing. When running the plugin I get ClassNotFoundExceptions and NoClassDefFoundErrors. The application used BeanUtils (1.7). Somewhere in that package a Log instance is created, but the classloader cannot find org.apache.log4j.Logger and an NoClassDefFoundError is thrown. The application serializes objects to a file using the ObjectOutputStream and ObjectInputStream. Serializing to a file works fine. Serializing from file to an Object throws a ClassNotFoundException because the base classloader does not know any object from any dependency. Both errors are caused by the classloader not knowing any of the dependend packages of the Maven project in which the plugin is used or on which the plugin depends. I tried several solutions: using my own URLClassLoader extention and using ClassWorld and creating a new ClassRealm. To both I added all project.RuntimeClasspathElements. These solutions fixed some problems but not all. In some cases the original classloader is still used (by included packages like org.apache.common.logging or by base java classes like java.io.ObjectInputStream) and that classloaded does not know my project classes and dependend packages. Can't maven itself not just include all dependend packages of the project (and plugin) on the classpath so you don't have to do that yourself inside the plugin ? I searched for similar bugs and found some but they are all fixed and closed in older maven version. Can someone please help me with this issue ? Here part of the stacktrace. As you can see, the ObjectInputStream uses Class.forName() which resolves to the RealmClassLoader, but not to my MyURLClassLoader instance. java.lang.ClassNotFoundException: nl.eid.aegon.rpf.parser.model.ClassDescription at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349) Here the stacktrace for the NoClassDefFoundError. It starts when I try to log something in the application using org.apache.common.logging. The only way I could solve this was to put the log4j package in the Maven lib directory, but this is not a prefered solution. The log4j.jar is a dependend package and should be included on the classpath by the classloader. [INFO] [INFO] Trace java.lang.ExceptionInInitializerError at nl.eid.replatforming_framework.parser.Parser.parse(Parser.java:45) at nl.eid.replatforming_framework.maven.RunAllMojo.runAll(RunAllMojo.java:404) at nl.eid.replatforming_framework.maven.RunAllMojo.execute(RunAllMojo.java:139) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(D
[jira] Commented: (MNG-2550) ClassNotFoundException and NoClassDefFoundError when running plugin
[ http://jira.codehaus.org/browse/MNG-2550?page=comments#action_74226 ] Joost den Boer commented on MNG-2550: - I don't agree the log4j config causes the problem. - If I run the same application as the plugin does from the command line or in Eclipse this problem does not occur. Without a configuration file, Log4j shows a warning or info message that you should add a config file, but it still works. - Secondly, an NoClassDefFoundError is thrown to indicate the log4j Logger class could not be found. If this would be a configuration problem an application exception should be thrown and not a NoClassDefFoundError which is a RuntimeException. > ClassNotFoundException and NoClassDefFoundError when running plugin > --- > > Key: MNG-2550 > URL: http://jira.codehaus.org/browse/MNG-2550 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.4 >Reporter: Joost den Boer > > I created a plugin which runs a small application which does some parsing, > logging and serializing. When running the plugin I get > ClassNotFoundExceptions and NoClassDefFoundErrors. > The application used BeanUtils (1.7). Somewhere in that package a Log > instance is created, but the classloader cannot find org.apache.log4j.Logger > and an NoClassDefFoundError is thrown. > The application serializes objects to a file using the ObjectOutputStream and > ObjectInputStream. Serializing to a file works fine. Serializing from file to > an Object throws a ClassNotFoundException because the base classloader does > not know any object from any dependency. > Both errors are caused by the classloader not knowing any of the dependend > packages of the Maven project in which the plugin is used or on which the > plugin depends. > I tried several solutions: using my own URLClassLoader extention and using > ClassWorld and creating a new ClassRealm. To both I added all > project.RuntimeClasspathElements. > These solutions fixed some problems but not all. In some cases the original > classloader is still used (by included packages like > org.apache.common.logging or by base java classes like > java.io.ObjectInputStream) and that classloaded does not know my project > classes and dependend packages. > Can't maven itself not just include all dependend packages of the project > (and plugin) on the classpath so you don't have to do that yourself inside > the plugin ? > I searched for similar bugs and found some but they are all fixed and closed > in older maven version. > Can someone please help me with this issue ? > Here part of the stacktrace. As you can see, the ObjectInputStream uses > Class.forName() which resolves to the RealmClassLoader, but not to my > MyURLClassLoader instance. > java.lang.ClassNotFoundException: > nl.eid.aegon.rpf.parser.model.ClassDescription > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at > org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) > at > org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:242) > at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584) > at > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543) > at > java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349) > Here the stacktrace for the NoClassDefFoundError. It starts when I try to log > something in the application using org.apache.common.logging. The only way I > could solve this was to put the log4j package in the Maven lib directory, but > this is not a prefered solution. The log4j.jar is a dependend package and > should be included on the classpath by the classloader. > [INFO] > --
[jira] Commented: (MNG-2550) ClassNotFoundException and NoClassDefFoundError when running plugin
[ http://jira.codehaus.org/browse/MNG-2550?page=comments#action_74458 ] Joost den Boer commented on MNG-2550: - ok, I overcame my doubts and tried it. And you're right, it works. However, this only solves half of the problem. There still is the problem that when deserializing an object, the class cannot be found. Any ideas how to solve this ? Only this I can think of is that Maven must place the dependend packages on the classpath. > ClassNotFoundException and NoClassDefFoundError when running plugin > --- > > Key: MNG-2550 > URL: http://jira.codehaus.org/browse/MNG-2550 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.4 >Reporter: Joost den Boer > > I created a plugin which runs a small application which does some parsing, > logging and serializing. When running the plugin I get > ClassNotFoundExceptions and NoClassDefFoundErrors. > The application used BeanUtils (1.7). Somewhere in that package a Log > instance is created, but the classloader cannot find org.apache.log4j.Logger > and an NoClassDefFoundError is thrown. > The application serializes objects to a file using the ObjectOutputStream and > ObjectInputStream. Serializing to a file works fine. Serializing from file to > an Object throws a ClassNotFoundException because the base classloader does > not know any object from any dependency. > Both errors are caused by the classloader not knowing any of the dependend > packages of the Maven project in which the plugin is used or on which the > plugin depends. > I tried several solutions: using my own URLClassLoader extention and using > ClassWorld and creating a new ClassRealm. To both I added all > project.RuntimeClasspathElements. > These solutions fixed some problems but not all. In some cases the original > classloader is still used (by included packages like > org.apache.common.logging or by base java classes like > java.io.ObjectInputStream) and that classloaded does not know my project > classes and dependend packages. > Can't maven itself not just include all dependend packages of the project > (and plugin) on the classpath so you don't have to do that yourself inside > the plugin ? > I searched for similar bugs and found some but they are all fixed and closed > in older maven version. > Can someone please help me with this issue ? > Here part of the stacktrace. As you can see, the ObjectInputStream uses > Class.forName() which resolves to the RealmClassLoader, but not to my > MyURLClassLoader instance. > java.lang.ClassNotFoundException: > nl.eid.aegon.rpf.parser.model.ClassDescription > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at > org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) > at > org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:242) > at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584) > at > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543) > at > java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349) > Here the stacktrace for the NoClassDefFoundError. It starts when I try to log > something in the application using org.apache.common.logging. The only way I > could solve this was to put the log4j package in the Maven lib directory, but > this is not a prefered solution. The log4j.jar is a dependend package and > should be included on the classpath by the classloader. > [INFO] > > [INFO] Trace > java.lang.ExceptionInInitializerError > at nl.eid.replatforming_framework.parser.Parser.parse(Parser.java:45) > at > nl.eid.replatforming_framework.maven.RunAllMojo.runAll(Ru
[jira] Commented: (MNG-2551) pom metadata file gets truncated during install into local repository
[ http://jira.codehaus.org/browse/MNG-2551?page=comments#action_74725 ] Joost den Boer commented on MNG-2551: - I have the exact same problem on a continuum buildserver on linux using Maven 2.0.4 and JDK 1.5_06. The problem occurs only on some project. Not on all. > pom metadata file gets truncated during install into local repository > - > > Key: MNG-2551 > URL: http://jira.codehaus.org/browse/MNG-2551 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Artifacts >Affects Versions: 2.0.4 > Environment: Win XP, JDK 1.4 >Reporter: Sharmarke Aden > Attachments: pom.xml, shared-1.9.0.pom > > > When I attempt to install my project artifact to my local repository it seems > that sometimes an incomplete/truncated ".pom" is deployed to my local > repository. It's kind of weird because sometimes it happens and sometimes it > doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and > the truncated pom meta data artifact deployed to my local repository. One > thing I found that's odd is that the size of the truncated pom generated is > consistently 4096 bytes. > p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- 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-2551) pom metadata file gets truncated during install into local repository
[ http://jira.codehaus.org/browse/MNG-2551?page=comments#action_74865 ] Joost den Boer commented on MNG-2551: - I went from version 0.3 to 0.4-SNAPSHOT yesterday and now this problem does not occur anymore for this project. > pom metadata file gets truncated during install into local repository > - > > Key: MNG-2551 > URL: http://jira.codehaus.org/browse/MNG-2551 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Artifacts >Affects Versions: 2.0.4 > Environment: Win XP, JDK 1.4 >Reporter: Sharmarke Aden > Attachments: pom.xml, shared-1.9.0.pom > > > When I attempt to install my project artifact to my local repository it seems > that sometimes an incomplete/truncated ".pom" is deployed to my local > repository. It's kind of weird because sometimes it happens and sometimes it > doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and > the truncated pom meta data artifact deployed to my local repository. One > thing I found that's odd is that the size of the truncated pom generated is > consistently 4096 bytes. > p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- 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-2551) pom metadata file gets truncated during install into local repository
[ http://jira.codehaus.org/browse/MNG-2551?page=comments#action_75046 ] Joost den Boer commented on MNG-2551: - Not sure what you mean. I had this problem with my project when it was on version 0.3. After the buildserver ran, the pom was trunkated after 4096 bytes. After I changed my project version to 0.4-SNAPSHOT, the problem did not occur anymore. I did not change a version of any dependend artifact. Still, I think this problem is worth looking at. I notices when following the build process by looking at the files created, that in the beginning of the build process, the pom.xml is put in the destination directory. At that point it is ok, has it's original site and is complete. After the build has finished and the .jar and .sha1, md5 files are present, the pom.xml is trunkated to 4096 bytes. So it must be caused by something at the end of the build process. Could it be related to creating the .sha1 and md5 files ? > pom metadata file gets truncated during install into local repository > - > > Key: MNG-2551 > URL: http://jira.codehaus.org/browse/MNG-2551 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Artifacts >Affects Versions: 2.0.4 > Environment: Win XP, JDK 1.4 >Reporter: Sharmarke Aden > Attachments: pom.xml, shared-1.9.0.pom > > > When I attempt to install my project artifact to my local repository it seems > that sometimes an incomplete/truncated ".pom" is deployed to my local > repository. It's kind of weird because sometimes it happens and sometimes it > doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and > the truncated pom meta data artifact deployed to my local repository. One > thing I found that's odd is that the size of the truncated pom generated is > consistently 4096 bytes. > p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- 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: (MECLIPSE-577) Project Dependencies list too intrusive while navigating projects.
[ http://jira.codehaus.org/browse/MECLIPSE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=181986#action_181986 ] Joost den Boer commented on MECLIPSE-577: - Isn't this exactly what m2eclipse does? Install the M2Eclipse plugin and generate the Eclipse config files with eclipse:m2eclipse. > Project Dependencies list too intrusive while navigating projects. > -- > > Key: MECLIPSE-577 > URL: http://jira.codehaus.org/browse/MECLIPSE-577 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Core : Multi-projects >Affects Versions: 2.6 > Environment: all >Reporter: Martin Jozef >Priority: Minor > Attachments: eclipse-maven-project.png > > > We have web applications that are growing very quickly having many inner > projects etc... The dependency list is becoming very large specially where a > lot of frameworks that we use like to split their project into many little > jars too. > I attached a screen shot to show of how it looks. > Can we direct the maven-eclipse-plugin to place all these jars under a group > like "Maven Dependencies" or something like that so the entire list is not > on the same level with src files. > As it stands it's hard to scroll between projects. -- 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: (MECLIPSE-252) Error trying to create an EAR project that contains one web module. It doesn't point to the local project, but only tries to find it in the local and remote repositori
[ http://jira.codehaus.org/browse/MECLIPSE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182921#action_182921 ] Joost den Boer commented on MECLIPSE-252: - Any progress on this issue? We're in the process of changing our project into a Maven structure. Not being able to generate the eclipse files without running 'mvn install' first is a BIG issue. ps. A project generated with maven-archetype-j2ee-simple archetype does not resolve the ear dependencies for me. > Error trying to create an EAR project that contains one web module. It > doesn't point to the local project, but only tries to find it in the local > and remote repositories. > -- > > Key: MECLIPSE-252 > URL: http://jira.codehaus.org/browse/MECLIPSE-252 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.3 >Reporter: Daniel Alheiros > > I have one structure that defines 3 projects: > project1-jar > project2-war > project3-ear > project2-war is just a WAR that contains the project1-jar as a library > (WEB-INF/lib) > project3-ear is an EAR that contains project2-war as its only web module. > When I run mvn package it works perfectly and creates the EAR containing the > proper WAR file and the application.xml, so it works fine, but when I run mvn > eclipse:eclipse to generate the projects, the ear project is not generated > properly as it tries to find the war in the local and remote repository as > the piece of logging show bellow: > [INFO] Building project3-ear > [INFO]task-segment: [eclipse:eclipse] > [INFO] > > [INFO] Preparing eclipse:eclipse > Downloading: > http://mycompany.central-repository/repo/com/mycompany/project2-war/1.0-SNAPSHOT/project2-war-1.0-SNAPSHOT.war > [WARNING] Unable to get resource > 'mycompanygroupid:project2-war:war:1.0-SNAPSHOT' from repository > mycompany.central-repository (http://mycompany.central-repository/repo) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) mycompanygroupid:project2-war:war:1.0-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=mycompanygroupid > -DartifactId=project2-war \ > -Dversion=1.0-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file > Path to dependency: > 1) mycompanygroupid:project3-ear:ear:1.0-SNAPSHOT > 2) mycompanygroupid:project2-war:war:1.0-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > mycompanygroupid:project3-ear:ear:1.0-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > mycompany.central-repository (http://mycompany.central-repository/repo) > If I follow this instructions and install my WAR file to my local repository, > it then works and makes my EAR project, but I believe it shouldn't be > necessary. -- 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-107) Cannot generate Eclipse file with eclipse:eclipse when dependent projects are not installed in repository
Cannot generate Eclipse file with eclipse:eclipse when dependent projects are not installed in repository - Key: MEAR-107 URL: http://jira.codehaus.org/browse/MEAR-107 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.3.2 Reporter: Joost den Boer In a multi module project, it is not possible to generate the Eclipse project files of an Ear project when dependent projects are not installed in the local repository. This is caused by the GenerateApplicationXmlMojo which requires all dependencies to be resolved before it is starten. The running of this mojo is part of the Maven core lifecycle. Because of this bug it is also impossible to build an ear package without installing all dependent projects in the local repository first. In our project we have a big multi module project. We chose not to checkin all Eclipse project files (.project etc) in subversion. When a developer checks out the project, he/she must be able to generate the Eclipse file without having to compile, package and install all modules first. It is very easy to reproduce this bug. Generate a new project using the simple j2ee archetype and run eclipse:eclipse in the new project directory. I created a patch for this bug. The solution is very easy. The @requiresDependenciesResolution tag is removed from the GenerateApplicationXmlMojo. In the AbstractEarMojo the dependencies are resolved in the Mojo before the Ear Execution Context is created. For dependency resolution I looked at how the Eclipse plugin and the Maven core (for @requiresDependenciesResolution tags) implemented this. First the dependencies are looked up in the local repository. The ear project should only contain wars/jars of other modules and/or 3rd party libraries which are used in those modules so it should not be necessary to download any dependencies here. With this patch, the Ear plugin should work as it does now. The new configuration property 'useProjectReferences' is default 'false'. When set to 'true' in the Ear configuration, missing dependencies are lookup in the reactor and added to the project artifacts list. With this fix it is possible to generate application xml and create and ear package without having to install the project modules . -- 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-107) Cannot generate Eclipse file with eclipse:eclipse when dependent projects are not installed in repository
[ http://jira.codehaus.org/browse/MEAR-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost den Boer updated MEAR-107: Attachment: MEAR-107-maven-ear-plugin-2.3.2.patch Patch for this issue > Cannot generate Eclipse file with eclipse:eclipse when dependent projects are > not installed in repository > - > > Key: MEAR-107 > URL: http://jira.codehaus.org/browse/MEAR-107 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3.2 >Reporter: Joost den Boer > Attachments: MEAR-107-maven-ear-plugin-2.3.2.patch > > > In a multi module project, it is not possible to generate the Eclipse project > files of an Ear project when dependent projects are not installed in the > local repository. > This is caused by the GenerateApplicationXmlMojo which requires all > dependencies to be resolved before it is starten. The running of this mojo is > part of the Maven core lifecycle. Because of this bug it is also impossible > to build an ear package without installing all dependent projects in the > local repository first. > In our project we have a big multi module project. We chose not to checkin > all Eclipse project files (.project etc) in subversion. When a developer > checks out the project, he/she must be able to generate the Eclipse file > without having to compile, package and install all modules first. > It is very easy to reproduce this bug. Generate a new project using the > simple j2ee archetype and run eclipse:eclipse in the new project directory. > I created a patch for this bug. The solution is very easy. The > @requiresDependenciesResolution tag is removed from the > GenerateApplicationXmlMojo. In the AbstractEarMojo the dependencies are > resolved in the Mojo before the Ear Execution Context is created. For > dependency resolution I looked at how the Eclipse plugin and the Maven core > (for @requiresDependenciesResolution tags) implemented this. First the > dependencies are looked up in the local repository. The ear project should > only contain wars/jars of other modules and/or 3rd party libraries which are > used in those modules so it should not be necessary to download any > dependencies here. With this patch, the Ear plugin should work as it does > now. The new configuration property 'useProjectReferences' is default > 'false'. When set to 'true' in the Ear configuration, missing dependencies > are lookup in the reactor and added to the project artifacts list. > With this fix it is possible to generate application xml and create and ear > package without having to install the project modules . -- 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: (MECLIPSE-584) No eclipse classpath entries generated for aspectj dependencies
[
http://jira.codehaus.org/browse/MECLIPSE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185468#action_185468
]
Joost den Boer commented on MECLIPSE-584:
-
This is caused by these lines in EclipseClasspathWriter:
{code:java}
// Skip aspectj libraries since they are in the container.
if ( ( config.getAjdtVersion() != 0 ) &&
dep.getArtifactId().toLowerCase().indexOf( "aspectj" ) >= 0 )
{
return;
}
{code}
It is very annoying it's not possible to add aspectj libraries to the
classpath. Somehow my JUnit-Spring tests work fine with Maven but in Rad they
don't run because the aspectj-weaver classes are not found. And these lines
prevent my from adding the required dependencies to the Eclipse classpath.
Any ideas how to workaround this? What do they mean by "Skip aspectj libraries
since they are in the container." ? In which container? We're using the
WebSphere JRE and WebSphere Application Service libraries for our projects, but
these don't have aspectj in them.
> No eclipse classpath entries generated for aspectj dependencies
> ---
>
> Key: MECLIPSE-584
> URL: http://jira.codehaus.org/browse/MECLIPSE-584
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
> Environment: Fedora 11
> Sun Java
>Reporter: Ole Ersoy
>Priority: Minor
>
> When I run eclipse:eclipse .classpath entries for the following elements
> don't get added:
>
> org.aspectj
> aspectjrt
> 1.5.4
>
>
>
> org.aspectj
> aspectjweaver
> 1.5.4
>
> The dependencies are in the repository and I can add them manually myself
> like this:
>path="M2_REPO/org/aspectj/aspectjrt/1.5.4/aspectjrt-1.5.4.jar"/>
>path="M2_REPO/org/aspectj/aspectjweaver/1.5.4/aspectjweaver-1.5.4.jar"/>
> I really thought this had to be a user error, so I tried taking some
> dependency declarations that work, and just changing the body values to
> correspond with the bodies of the aspectj dependency declarations. It still
> does not work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
