[jira] Commented: (MCHANGELOG-91) mvn changelog:changelog svn --non-interactive fails under Mac OSX 10.5 (svn: PROPFIND authorization failed)
[
http://jira.codehaus.org/browse/MCHANGELOG-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174576#action_174576
]
Siarhei Dudzin commented on MCHANGELOG-91:
--
I've just tested with the latest snapshot from the trunk - it's fixed.
For it to work you need to use the new feature of the latest SCM which allows
overriding scm settings.
In particular, for Mac OS you need to have ~/.scm/svn-settings.xml where you
can disable -non-interactive flag for svn (which causes the problems under Mac
OS):
false
Exra info on the scm settings file is available at:
http://maven.apache.org/scm/subversion.html
> mvn changelog:changelog svn --non-interactive fails under Mac OSX 10.5 (svn:
> PROPFIND authorization failed)
> ---
>
> Key: MCHANGELOG-91
> URL: http://jira.codehaus.org/browse/MCHANGELOG-91
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
> Environment: OSX 10.5
>Reporter: Laurent Perez
>Priority: Critical
>
> hi
> mvn changelog:changelog svn --non-interactive fails under Mac OSX 10.5, stack
> below :
> [INFO] Executing: svn --non-interactive log -v -r "{2008-11-12 22:21:45
> +}:{2008-12-13 22:21:45 +}" http://xx/
> [INFO] Working directory: /Users/laurent/Desktop/x
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: PROPFIND request failed on '/'
> svn: PROPFIND of '/x': authorization failed (http://x)
> I believe this may be linked to http://jira.codehaus.org/browse/SCM-402 ,
> however, I am using maven-scm-plugin version 1.1 in my pom.xml, but perhaps
> the changelog plugin does not use this 1.1 version.
> Can anyone confirm ?
> thanks
> laurent
--
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: (MCHANGELOG-91) mvn changelog:changelog svn --non-interactive fails under Mac OSX 10.5 (svn: PROPFIND authorization failed)
[
http://jira.codehaus.org/browse/MCHANGELOG-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174355#action_174355
]
Siarhei Dudzin commented on MCHANGELOG-91:
--
yes, it apears changelog uses version 1.0 which doesn't have the fix...
> mvn changelog:changelog svn --non-interactive fails under Mac OSX 10.5 (svn:
> PROPFIND authorization failed)
> ---
>
> Key: MCHANGELOG-91
> URL: http://jira.codehaus.org/browse/MCHANGELOG-91
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
> Environment: OSX 10.5
>Reporter: Laurent Perez
>Priority: Critical
>
> hi
> mvn changelog:changelog svn --non-interactive fails under Mac OSX 10.5, stack
> below :
> [INFO] Executing: svn --non-interactive log -v -r "{2008-11-12 22:21:45
> +}:{2008-12-13 22:21:45 +}" http://xx/
> [INFO] Working directory: /Users/laurent/Desktop/x
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: PROPFIND request failed on '/'
> svn: PROPFIND of '/x': authorization failed (http://x)
> I believe this may be linked to http://jira.codehaus.org/browse/SCM-402 ,
> however, I am using maven-scm-plugin version 1.1 in my pom.xml, but perhaps
> the changelog plugin does not use this 1.1 version.
> Can anyone confirm ?
> thanks
> laurent
--
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: (MECLIPSE-466) application.xml generated incorrectly for 3rd party ejb modules
application.xml generated incorrectly for 3rd party ejb modules --- Key: MECLIPSE-466 URL: http://jira.codehaus.org/browse/MECLIPSE-466 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.5.1 Reporter: Siarhei Dudzin Attachments: test-project.tar.gz As you may know by default the project version is not added to the project name. In case I have 3rd party ejb modules from a maven repository (jboss seam for example) the version number for those modules is removed from the generated application.xml as well which breaks the WTP deployment: the server can't find the 3rd party ejb jar because it expects the jar also be without the version number. Looks like during generation of application.xml there is no distinction made between dependencies from projects and libraries. I included a test case. -- 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-388) Correct classpath ordering in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139669#action_139669
]
Siarhei Dudzin commented on MECLIPSE-388:
-
maven-dev mailing list seem appropriate
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: http://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Priority: Critical
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
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-388) Correct classpath ordering in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139563#action_139563
]
Siarhei Dudzin commented on MECLIPSE-388:
-
It appears that MNG-1412 uses LinkedHashSet instead of HashSet. If we could
determine which one is used we cold apply corresponding sorting algorithm (that
is alphabetic or as-is). No forcing to a maven version is necessary then and
yet the result would be reproducable for pre- and post-MNG-1412 versions of
maven.
What do you think?
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: http://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Priority: Critical
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
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-184) Ear utility-jar are put in WEB-INF/lib of the wtp ear
[ http://jira.codehaus.org/browse/MECLIPSE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124575 ] Siarhei Dudzin commented on MECLIPSE-184: - Jos, it appears you mean slightly different (but quite related) problem. The original issue is about having the directory layout. The problem with EAR module having libs in WEB-INF/lib does not exist anymore (the issue is dated Nov. 2006). Your problem is that org.eclipse.wst.common.component still has the wrong setting. Arnaud, does it make sense to create a separate issue for that and close this one (if everyone agrees of course)? This issue is 1.5 years old... I am getting lost now... Is this in fact a different issue? > Ear utility-jar are put in WEB-INF/lib of the wtp ear > - > > Key: MECLIPSE-184 > URL: http://jira.codehaus.org/browse/MECLIPSE-184 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: Tested on Windows XP and Linux Ubuntu Dapper Drake >Reporter: Elid OR >Assignee: Arnaud Heritier >Priority: Critical > > It seems that the maven eclipse plugin add ear jar dependencies in the > WEB-INF/lib directory. > I've used the following command : mvn eclipse:clean > eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot > version) > And when deploy the ear project through WTP in a J2EE Server I see the > following structure : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- WEB-INF/ > | lib > | dependency-1.jar > | dependency-2.jar > But I don't expect these dependencies to be here, I expect something like > this : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- dependency-1.jar > |- dependency-2.jar > So I've checked quickly the SVN repository and it seems that the directory in > which we put "ear utility jar" is hard coded as "WEB-INF/lib" (-> > AbstractWtpResourceWritter.addDependency() which is the same for the war and > the ear ... ) > Are you OK with this packaging ? It can be a good thing if we could configure > where wtp will > put these ear utility-jars and by default it would be in "/" or "lib". > Thanks In Advance > Elid OR -- 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-388) Correct classpath ordering in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124006
]
Siarhei Dudzin commented on MECLIPSE-388:
-
I agree, forcing to maven 2.0.9 would be a bit extreme... What about having an
option or something like that (a disadvantage is that too many options isn't
nice)? That about performing sorting based on maven version (also not very nice
but no extra complexity in configuration for the end user)?
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: http://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Priority: Critical
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
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-184) Ear utility-jar are put in WEB-INF/lib of the wtp ear
[ http://jira.codehaus.org/browse/MECLIPSE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123951 ] Siarhei Dudzin commented on MECLIPSE-184: - I had to drop it because it didn't support all the features of the pom I used for maven 2.0.x. And there was no major (if at all) release since... Which is unfortunate because now I have to use this: [http://maven.apache.org/guides/mini/guide-ide-eclipse.html#Maven%20as%20an%20external%20tool] > Ear utility-jar are put in WEB-INF/lib of the wtp ear > - > > Key: MECLIPSE-184 > URL: http://jira.codehaus.org/browse/MECLIPSE-184 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: Tested on Windows XP and Linux Ubuntu Dapper Drake >Reporter: Elid OR >Assignee: Arnaud Heritier >Priority: Critical > > It seems that the maven eclipse plugin add ear jar dependencies in the > WEB-INF/lib directory. > I've used the following command : mvn eclipse:clean > eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot > version) > And when deploy the ear project through WTP in a J2EE Server I see the > following structure : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- WEB-INF/ > | lib > | dependency-1.jar > | dependency-2.jar > But I don't expect these dependencies to be here, I expect something like > this : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- dependency-1.jar > |- dependency-2.jar > So I've checked quickly the SVN repository and it seems that the directory in > which we put "ear utility jar" is hard coded as "WEB-INF/lib" (-> > AbstractWtpResourceWritter.addDependency() which is the same for the war and > the ear ... ) > Are you OK with this packaging ? It can be a good thing if we could configure > where wtp will > put these ear utility-jars and by default it would be in "/" or "lib". > Thanks In Advance > Elid OR -- 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-184) Ear utility-jar are put in WEB-INF/lib of the wtp ear
[
http://jira.codehaus.org/browse/MECLIPSE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123940
]
Siarhei Dudzin commented on MECLIPSE-184:
-
Well I thought it does because I saw this (and in more places):
[http://docs.codehaus.org/display/M2ECLIPSE/Project+FAQ#ProjectFAQ-WhatMavenversionisusedbyplugin]
it says:
{quote}
"Plugin is not actually using Maven itself. It is using component that is part
of Maven called Maven Embedder. This component *is not available for Maven
2.0.x*. Embedder is used by the Maven command line interface (CLI) starting
from version 2.1, so the current version of Embedder *correspond to the Maven
2.1* code line that include number of improvements to allow to actually embed
Maven."
{quote}
I agree with you, Arnaud, on both those plugins - they are pretty far from full
wtp interop yet.
> Ear utility-jar are put in WEB-INF/lib of the wtp ear
> -
>
> Key: MECLIPSE-184
> URL: http://jira.codehaus.org/browse/MECLIPSE-184
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: WTP support
>Affects Versions: 2.3
> Environment: Tested on Windows XP and Linux Ubuntu Dapper Drake
>Reporter: Elid OR
>Assignee: Arnaud Heritier
>Priority: Critical
>
> It seems that the maven eclipse plugin add ear jar dependencies in the
> WEB-INF/lib directory.
> I've used the following command : mvn eclipse:clean
> eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot
> version)
> And when deploy the ear project through WTP in a J2EE Server I see the
> following structure :
> my-ear
> | my-ejb.jar
> | my-webapp.war
> | META-INF/
> | application.xml
> | MANIFEST.MF
> |
> |- WEB-INF/
> | lib
> | dependency-1.jar
> | dependency-2.jar
> But I don't expect these dependencies to be here, I expect something like
> this :
> my-ear
> | my-ejb.jar
> | my-webapp.war
> | META-INF/
> | application.xml
> | MANIFEST.MF
> |
> |- dependency-1.jar
> |- dependency-2.jar
> So I've checked quickly the SVN repository and it seems that the directory in
> which we put "ear utility jar" is hard coded as "WEB-INF/lib" (->
> AbstractWtpResourceWritter.addDependency() which is the same for the war and
> the ear ... )
> Are you OK with this packaging ? It can be a good thing if we could configure
> where wtp will
> put these ear utility-jars and by default it would be in "/" or "lib".
> Thanks In Advance
> Elid OR
--
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-184) Ear utility-jar are put in WEB-INF/lib of the wtp ear
[ http://jira.codehaus.org/browse/MECLIPSE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123623 ] Siarhei Dudzin commented on MECLIPSE-184: - Here: http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html You can find an example in one of bug report attachments I've ever created: http://jira.jboss.org/jira/secure/attachment/12316955/test-project-JBIDE-1322.zip And btw I had to drop usage of m2eclipse because it didn't support all configuration features I had in my pom's (I guess one of the reasons may be that it in fact uses maven 2.1 instead of user-installed maven 2.0.x). > Ear utility-jar are put in WEB-INF/lib of the wtp ear > - > > Key: MECLIPSE-184 > URL: http://jira.codehaus.org/browse/MECLIPSE-184 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: Tested on Windows XP and Linux Ubuntu Dapper Drake >Reporter: Elid OR >Assignee: Arnaud Heritier >Priority: Critical > > It seems that the maven eclipse plugin add ear jar dependencies in the > WEB-INF/lib directory. > I've used the following command : mvn eclipse:clean > eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot > version) > And when deploy the ear project through WTP in a J2EE Server I see the > following structure : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- WEB-INF/ > | lib > | dependency-1.jar > | dependency-2.jar > But I don't expect these dependencies to be here, I expect something like > this : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- dependency-1.jar > |- dependency-2.jar > So I've checked quickly the SVN repository and it seems that the directory in > which we put "ear utility jar" is hard coded as "WEB-INF/lib" (-> > AbstractWtpResourceWritter.addDependency() which is the same for the war and > the ear ... ) > Are you OK with this packaging ? It can be a good thing if we could configure > where wtp will > put these ear utility-jars and by default it would be in "/" or "lib". > Thanks In Advance > Elid OR -- 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: (MECLIPSE-388) Correct classpath ordering in .classpath
Correct classpath ordering in .classpath
Key: MECLIPSE-388
URL: http://jira.codehaus.org/browse/MECLIPSE-388
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Dependencies resolution and build path
Affects Versions: 2.4
Reporter: Siarhei Dudzin
Priority: Critical
Currently plugin sorts artifacts on its own (alphabetic order???) because the
order of dependencies that comes from maven is not reliable (random?). This
breaks tests that use JBoss Embedded which works under maven surefire plugin
because it still puts dependencies that came first at the beginning of the
classpath). Apparently not all classpath elements are put in random order. At
least I get the first ones listed in dependencies also first in the classpath
(can be seen as ${surefire.test.class.path} and in
target/surefire-reports/TEST-TestSuite.xml).
While there is not much we can do for maven eclipse plugin a solution is on the
way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can revert
back to the default classpath order.
Can we somehow schedule this?
Another question: is there anyway to put certain dependencies in the first
place except for renaming them so that alphabetic order does the job?
--
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-184) Ear utility-jar are put in WEB-INF/lib of the wtp ear
[ http://jira.codehaus.org/browse/MECLIPSE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122085 ] Siarhei Dudzin commented on MECLIPSE-184: - Arnaud, I don't think this issue is valid anymore. I configure location of utility jar's by specifying lib in the config of ear plugin and it deploys correctly by WTP+JBoss Tools combination (it does exploded deployment which works very well). So by using this setting I get the /lib in my ear where all the utility jar's are stored... > Ear utility-jar are put in WEB-INF/lib of the wtp ear > - > > Key: MECLIPSE-184 > URL: http://jira.codehaus.org/browse/MECLIPSE-184 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: Tested on Windows XP and Linux Ubuntu Dapper Drake >Reporter: Elid OR >Assignee: Arnaud Heritier >Priority: Critical > > It seems that the maven eclipse plugin add ear jar dependencies in the > WEB-INF/lib directory. > I've used the following command : mvn eclipse:clean > eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot > version) > And when deploy the ear project through WTP in a J2EE Server I see the > following structure : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- WEB-INF/ > | lib > | dependency-1.jar > | dependency-2.jar > But I don't expect these dependencies to be here, I expect something like > this : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- dependency-1.jar > |- dependency-2.jar > So I've checked quickly the SVN repository and it seems that the directory in > which we put "ear utility jar" is hard coded as "WEB-INF/lib" (-> > AbstractWtpResourceWritter.addDependency() which is the same for the war and > the ear ... ) > Are you OK with this packaging ? It can be a good thing if we could configure > where wtp will > put these ear utility-jars and by default it would be in "/" or "lib". > Thanks In Advance > Elid OR -- 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-378) Projects with customized warSourceDirectory still creates empty directories of the default path
[ http://jira.codehaus.org/browse/MECLIPSE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated MECLIPSE-378: Attachment: MECLIPE-378.patch The problem was in few more hardcoded locations of src/main/webapp, fixed now and attached patch with the test case and the fix. > Projects with customized warSourceDirectory still creates empty directories > of the default path > --- > > Key: MECLIPSE-378 > URL: http://jira.codehaus.org/browse/MECLIPSE-378 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPE-378.patch > > > Subj. Test case project-rad-7 uses custom path but src/main/webapp/WEB-INF is > still created. -- 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: (MECLIPSE-378) Projects with customized warSourceDirectory still creates empty directories of the default path
Projects with customized warSourceDirectory still creates empty directories of the default path --- Key: MECLIPSE-378 URL: http://jira.codehaus.org/browse/MECLIPSE-378 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.5 Reporter: Siarhei Dudzin Subj. Test case project-rad-7 uses custom path but src/main/webapp/WEB-INF is still created. -- 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: (CONTINUUM-1585) Can't connect to gtalk with jabber notifier via proxy
Can't connect to gtalk with jabber notifier via proxy - Key: CONTINUUM-1585 URL: http://jira.codehaus.org/browse/CONTINUUM-1585 Project: Continuum Issue Type: Bug Components: Notifier - Jabber Affects Versions: 1.1 Environment: Windows 2003 Server Reporter: Siarhei Dudzin Hi, I have sending notifications to GTalk via jabber notifier if I am behind proxy. I've configured notifier as specified in the FAQ: jabber host: talk.google.com jabber port: 5222 jabber login: Jabber Domain Name: gmail.com Is it a SSL Connection? false I am starting continuum as a service with local account (to be able to read settings.xml where we also have a proxy defined). I have defined proxy in wrapper.conf in the following way: wrapper.java.additional.9=-Dhttp.proxyHost="" wrapper.java.additional.9.stripquotes=TRUE wrapper.java.additional.10=-Dhttp.proxyPort="8080" wrapper.java.additional.10.stripquotes=TRUE wrapper.java.additional.11=-Dhttp.nonProxyHosts="*.mycompany.com|localhost|127.0.0.1" I tried host and port with and without quotes, tried to use proxy ip instead of the host name. No result, I get the following exception: 135043 [pool-1-thread-1] ERROR org.apache.maven.continuum.notification.ContinuumNotificationDispatcher:default - Error while trying to use the jabber notifier. org.codehaus.plexus.notification.NotificationException: Exception while sending message. at org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendMessage(JabberContinuumNotifier.java:240) at org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendNotification(JabberContinuumNotifier.java:138) at org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:199) at org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.sendNotification(DefaultContinuumNotificationDispatcher.java:159) at org.apache.maven.continuum.notification.DefaultContinuumNotificationDispatcher.buildComplete(DefaultContinuumNotificationDispatcher.java:103) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.endBuild(DefaultBuildController.java:221) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:175) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.codehaus.plexus.jabber.JabberClientException: Can't connect to talk.google.com:5222 at org.codehaus.plexus.jabber.DefaultJabberClient.connect(DefaultJabberClient.java:51) at org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendMessage(JabberContinuumNotifier.java:220) ... 13 more Caused by: Could not connect to talk.google.com:5222.: (504) -- caused by: java.net.UnknownHostException: talk.google.com at org.jivesoftware.smack.XMPPConnection.(XMPPConnection.java:168) at org.codehaus.plexus.jabber.DefaultJabberClient.connect(DefaultJabberClient.java:42) ... 14 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] Updated: (SCM-355) CVS provider with SSPI transport does not support port number in url
[ http://jira.codehaus.org/browse/SCM-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated SCM-355: --- Attachment: SCM-355-documentation.patch I've also created a patch for documentation (in case it helps) > CVS provider with SSPI transport does not support port number in url > > > Key: SCM-355 > URL: http://jira.codehaus.org/browse/SCM-355 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.0 > Environment: maven 2.0.7, CVSNT server configured non default port >Reporter: Siarhei Dudzin >Priority: Blocker > Attachments: SCM-355-documentation.patch, SCM-355.patch > > > Current implementation has checks on harcoded number of delimiters which is > for which doesn't allow to use port number in the url (which is happening > when the server is configured to use a different port number). Having port > number in the url tells SCM CVS that there are in fact 5 tokens which results > in an exception with the following message: > >mvn scm:checkout > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'scm'. > [INFO] > > [INFO] Building saar-main > [INFO]task-segment: [scm:checkout] (aggregator-style) > [INFO] > > [INFO] [scm:checkout] > [ERROR] The connection string contains an incorrect number of tokens (should > be four). > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Cannot run checkout command : > Embedded error: Can't load the scm provider. > The scm url is invalid. > The following format of developerConnection is used: > scm:cvs:sspi > If I remove the port number from the url it actually tries to checkout but > fails as there is no response on that port. If I try to use the same cvs > command maven is trying to issue (adding with the correct port number) - the > checkout works. -- 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: (SCM-355) CVS provider with SSPI transport does not support port number in url
[ http://jira.codehaus.org/browse/SCM-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated SCM-355: --- Attachment: SCM-355.patch Attaching a patch which allows using port in the URL in case of SSPI protocol (tested with cvsnt). I've noticed that be default a java client is used (it doesn't support sppi), so even now -Dmaven.scm.provider.cvs.implementation=cvs_native should be used in order sppi to work at all. > CVS provider with SSPI transport does not support port number in url > > > Key: SCM-355 > URL: http://jira.codehaus.org/browse/SCM-355 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.0 > Environment: maven 2.0.7, CVSNT server configured non default port >Reporter: Siarhei Dudzin >Priority: Blocker > Attachments: SCM-355.patch > > > Current implementation has checks on harcoded number of delimiters which is > for which doesn't allow to use port number in the url (which is happening > when the server is configured to use a different port number). Having port > number in the url tells SCM CVS that there are in fact 5 tokens which results > in an exception with the following message: > >mvn scm:checkout > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'scm'. > [INFO] > > [INFO] Building saar-main > [INFO]task-segment: [scm:checkout] (aggregator-style) > [INFO] > > [INFO] [scm:checkout] > [ERROR] The connection string contains an incorrect number of tokens (should > be four). > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Cannot run checkout command : > Embedded error: Can't load the scm provider. > The scm url is invalid. > The following format of developerConnection is used: > scm:cvs:sspi > If I remove the port number from the url it actually tries to checkout but > fails as there is no response on that port. If I try to use the same cvs > command maven is trying to issue (adding with the correct port number) - the > checkout works. -- 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-312) WebContent folder linked to webapp folder is not generated
[
http://jira.codehaus.org/browse/MECLIPSE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115297
]
Siarhei Dudzin commented on MECLIPSE-312:
-
Just did a quick check - WebContent is getting created correctly if it's
specified/overrridden via eclipse-war-plugin settings. No link is needed.
I think it can be closed.
> WebContent folder linked to webapp folder is not generated
> --
>
> Key: MECLIPSE-312
> URL: http://jira.codehaus.org/browse/MECLIPSE-312
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
> Environment: Maven 2, Linux & Windows
>Reporter: Cyril JOUI
> Attachments: EclipseProjectWriter.java, EclipseWtpComponentWriter.java
>
>
> When I generate a eclipse project with wtpsupport, maven plugin doesn't
> create a WebContent folder in web project.
> Configuration part in eclipse is:
> in org.eclipse.wst.common.component:
>
> and /WebContent is refered by:
>
> WebContent
> 2
>
> //rpf/dev/modules/rpf-gateway/src/main/webapp
>
> in .project file
> I made modification on EclipseProjectWriter:
> // if war project (add WebContent => webapp)
> if ("war".equals(config.getProject().getPackaging())) {
> addLink (writer, "WebContent",
> config.getProject().getBasedir() +
> "/src/main/webapp", LINK_TYPE_DIRECTORY);
> }
> And
> writer.startElement( ELT_WB_RESOURCE );
> writer.addAttribute( ATTR_DEPLOY_PATH, "/" ); //$NON-NLS-1$
> writer.addAttribute( ATTR_SOURCE_PATH, "/WebContent");
> /*
> writer.addAttribute( ATTR_SOURCE_PATH, IdeUtils
> .toRelativeAndFixSeparator(
> config.getEclipseProjectDirectory(), warSourceDirectory, false ) );
> */
> writer.endElement();
> in EclipseWtpComponentWriter
--
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-316) RadCleanMojo does not clean .war files
[ http://jira.codehaus.org/browse/MECLIPSE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated MECLIPSE-316: Attachment: MECLIPSE-316.patch Attaching a fix. Not sure why it's creating war's when running eclipse-rad goal from the ear module and not creating war's when running from parent module. Better cleanup is good anyway! > RadCleanMojo does not clean .war files > -- > > Key: MECLIPSE-316 > URL: http://jira.codehaus.org/browse/MECLIPSE-316 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: RAD support >Affects Versions: 2.4 >Reporter: Siarhei Dudzin > Attachments: MECLIPSE-316.patch > > > RadCleanMojo only cleans jars in deleteJarArtifactsInDirectory() while > RadLibCopier also copies .war files in RadLibCopier.copyArtifact( > IdeDependency[] deps, File destDir ). RadCleanMojo also needs to clean .war > files. -- 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: (SCM-355) CVS provider with SSPI transport does not support port number in url
CVS provider with SSPI transport does not support port number in url Key: SCM-355 URL: http://jira.codehaus.org/browse/SCM-355 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0 Environment: maven 2.0.7, CVSNT server configured non default port Reporter: Siarhei Dudzin Priority: Blocker Current implementation has checks on harcoded number of delimiters which is for which doesn't allow to use port number in the url (which is happening when the server is configured to use a different port number). Having port number in the url tells SCM CVS that there are in fact 5 tokens which results in an exception with the following message: >mvn scm:checkout [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'scm'. [INFO] [INFO] Building saar-main [INFO]task-segment: [scm:checkout] (aggregator-style) [INFO] [INFO] [scm:checkout] [ERROR] The connection string contains an incorrect number of tokens (should be four). [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot run checkout command : Embedded error: Can't load the scm provider. The scm url is invalid. The following format of developerConnection is used: scm:cvs:sspi If I remove the port number from the url it actually tries to checkout but fails as there is no response on that port. If I try to use the same cvs command maven is trying to issue (adding with the correct port number) - the checkout works. -- 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-3303) read some plugin settings from settings.xml
[ http://jira.codehaus.org/browse/MNG-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115108 ] Siarhei Dudzin commented on MNG-3303: - TBH, settings.xml would be probably the last place (unless other choices is not an option) where I would want to have this. It's much more controllable if you have it in a parent pom (even on the organization level) then you can easier roll out changes, while settings.xml is more difficult to automatically distribute. And if a quick startup project is needed a new archetype can be created. The idea behind the plugin (my understanding) is to have pom settings reflected on your eclipse project. By moving something out of the reproducible dependency/configuration tree may make the result of a project less reproducible. Even though I understand the motion behind this request I wouldn't want to have a developer in my team who is unable to generate his eclipse project correctly just because he has wrong version of settings.xml or forgotten to put something (may become a nightmare in bigger teams), - just my2 cents though. > read some plugin settings from settings.xml > --- > > Key: MNG-3303 > URL: http://jira.codehaus.org/browse/MNG-3303 > Project: Maven 2 > Issue Type: Improvement >Reporter: Paul Harrison > > It is not appropriate that all of the possible settings for the plug-in are > read from the pom, as they will be dependent on details of the user's > personal eclipse installation - it would be more appropriate if they were > picked up from the settings.xml file. > e.g. additionalProjectnatures propetry -- 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-222) read some plugin settings from settings.xml
[ http://jira.codehaus.org/browse/MECLIPSE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115065 ] Siarhei Dudzin commented on MECLIPSE-222: - That's why you can have parent pom's. If you want to have it on enterprise level you can have an enterprise pom in combination with enterprise repository. Book "Better builds with maven" describes this in more details. > read some plugin settings from settings.xml > --- > > Key: MECLIPSE-222 > URL: http://jira.codehaus.org/browse/MECLIPSE-222 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Reporter: Paul Harrison > > It is not appropriate that all of the possible settings for the plug-in are > read from the pom, as they will be dependent on details of the user's > personal eclipse installation - it would be more appropriate if they were > picked up from the settings.xml file. > e.g. additionalProjectnatures propetry -- 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: (SCM-336) Usage or custom port number results in incorrect cvsroot string in .cvspass file
[ http://jira.codehaus.org/browse/SCM-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115033 ] Siarhei Dudzin commented on SCM-336: Anyone? > Usage or custom port number results in incorrect cvsroot string in .cvspass > file > > > Key: SCM-336 > URL: http://jira.codehaus.org/browse/SCM-336 > Project: Maven SCM > Issue Type: Bug >Affects Versions: 1.0 > Environment: Continuum 1.1 beta-2 with java cvs client (default in > this version) >Reporter: Siarhei Dudzin >Priority: Blocker > > When a project SCM url contains custom port number the .cvspass is not > created properly - it has the custom port number appended to the default > (2401) one. > For example a URL scm:cvs:pserver:@:9280/CVS/ > would result in 24019280 as port number in .cvspass file which results in > inability to use SCM with customized port number when using java cvs client -- 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-357) RadManifestWriter uses hardcoded web application source directory
[ http://jira.codehaus.org/browse/MECLIPSE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated MECLIPSE-357: Attachment: MECLIPSE-357.patch Same story with cleaning the libs during rad-clean goal. Fixed it right there. Attached the fix and the test case. > RadManifestWriter uses hardcoded web application source directory > - > > Key: MECLIPSE-357 > URL: http://jira.codehaus.org/browse/MECLIPSE-357 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: RAD support >Affects Versions: 2.4 >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier >Priority: Critical > Attachments: MECLIPSE-357.patch > > > RadManifestWriter uses hardcoded web application source directory to write > manifest file instead of reading maven-war-plugin configuration for the > corresponding location (if present). > This is also easy to fix, I'll submit a patch shortly. -- 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: (MECLIPSE-357) RadManifestWriter uses hardcoded web application source directory
RadManifestWriter uses hardcoded web application source directory - Key: MECLIPSE-357 URL: http://jira.codehaus.org/browse/MECLIPSE-357 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: RAD support Affects Versions: 2.4 Reporter: Siarhei Dudzin Priority: Critical RadManifestWriter uses hardcoded web application source directory to write manifest file instead of reading maven-war-plugin configuration for the corresponding location (if present). This is also easy to fix, I'll submit a patch shortly. -- 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: (MECLIPSE-356) RadLibCopier does not respect warSourceDirectory setting of maven-war-plugin when copying dependencies
RadLibCopier does not respect warSourceDirectory setting of maven-war-plugin when copying dependencies -- Key: MECLIPSE-356 URL: http://jira.codehaus.org/browse/MECLIPSE-356 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: RAD support Affects Versions: 2.4 Reporter: Siarhei Dudzin Priority: Blocker Attachments: LibCopierPatch.patch RadLibCopier does not respect warSourceDirectory setting of maven-war-plugin when copying dependencies and uses hardcoded "src/main/webapp" instead. I've set priority on 'blocker' because this doesn't let us use webservices (RAD-6 requires hardcoded web source location on it's own). Attaching a fix and a test case. -- 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-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114839 ] Siarhei Dudzin commented on MECLIPSE-346: - Ok, I did some testing again and I think it's pure JBoss Tools issue (only exploded deployment doesn't work) - the 'standard' WTP-2 deployment works now (doesn't do exploded deployment but regular ear-packaging). I think this issue is really closed now. Thanks! > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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-315) RadWebSettingsWriter uses hardcoded webcontent path and ignores warSourceDirectory
[ http://jira.codehaus.org/browse/MECLIPSE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated MECLIPSE-315: Attachment: MECLIPSE-315-testcase.patch Attaching a test case. > RadWebSettingsWriter uses hardcoded webcontent path and ignores > warSourceDirectory > -- > > Key: MECLIPSE-315 > URL: http://jira.codehaus.org/browse/MECLIPSE-315 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Reporter: Siarhei Dudzin > Attachments: MECLIPSE-315-testcase.patch, MECLIPSE-315.patch > > > org.apache.maven.plugin.eclipse.writers.rad.RadWebSettingsWriter uses > hardcoded location of webcontent during writeModuleTypeFacetCore() (does > writer.writeText( "src/main/webapp" ); directly ) and ignores > warSourceDirectory which is used to customize the location of the webcontent > (besides RAD-6 uses different directory structure hence this problem). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-315) RadWebSettingsWriter uses hardcoded webcontent path and ignores warSourceDirectory
[ http://jira.codehaus.org/browse/MECLIPSE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated MECLIPSE-315: Attachment: MECLIPSE-315.patch Attaching a fix. Can this come in version 2.5? > RadWebSettingsWriter uses hardcoded webcontent path and ignores > warSourceDirectory > -- > > Key: MECLIPSE-315 > URL: http://jira.codehaus.org/browse/MECLIPSE-315 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Reporter: Siarhei Dudzin > Attachments: MECLIPSE-315.patch > > > org.apache.maven.plugin.eclipse.writers.rad.RadWebSettingsWriter uses > hardcoded location of webcontent during writeModuleTypeFacetCore() (does > writer.writeText( "src/main/webapp" ); directly ) and ignores > warSourceDirectory which is used to customize the location of the webcontent > (besides RAD-6 uses different directory structure hence this problem). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114781 ] Siarhei Dudzin commented on MECLIPSE-346: - This particular problem seems to be solved (correct facelets are generated). However I can't seem to deploy the project to JBoss anymore (using the latest JBoss tools plugins). I get "No META-INF/application.xml found" error because I don't have application.xml in my source folders (it's generated automatically). And I can't do the 'Generate Deployment Descriptor stub" functionality of WTP (seems to be WTP detect the generated application.xml under the target directory). Is there anything else changed that may cause this problem (it did work when I reported this issue and just manually changed the facet version)? Should I make another JIRA issue? Right now I can't deploy the project via WTP at all. > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114506 ] Siarhei Dudzin commented on MECLIPSE-346: - Well just as you suggested this is exactly what is used in the patch: MavenProject.getProjectReferences and MavenProject.getDependencies so I dont see the problem here (unless I misunderstood what you just meant). Anyway, what are your plans for this issue? I have pretty high need for this issue to be resolved. > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114483 ] Siarhei Dudzin commented on MECLIPSE-346: - What about my solution that looks into the referenced projects and then into their direct dependencies (the original patch attachment)? > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated MECLIPSE-346: Attachment: test-project-MECLIPSE-346.zip Attaching a test project that reproduces the issue > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin reopened MECLIPSE-346: - Not fixed. I am still getting instead of for an ear project. > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114204 ] Siarhei Dudzin commented on MECLIPSE-346: - Can you, please, let me know when it is published? I can't seem to find the new version on the maven snapshots repository. > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.5 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (MECLIPSE-346) WTP-2 support, wrong version of EAR facet is generated
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114104 ] Siarhei Dudzin edited comment on MECLIPSE-346 at 11/16/07 8:21 PM: --- Attached a patch with the fix. To detect the EAR version it has extra checking through referenced projects to detect whether there is a ejb-3 module in the dependencies (not all EAR modules have direct jee 5 dependency). It also has an extra artifact id (group 'javax.ejb' and id 'ejb-api') to check for better detection of ejb-3 modules (tested on JBoss and Seam 2). was: Patch with fix > WTP-2 support, wrong version of EAR facet is generated > -- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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-346) WTP-2 support, wrong version of EAR facet is generated
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated MECLIPSE-346: Attachment: MECLIPSE-346.patch Patch with fix > WTP-2 support, wrong version of EAR facet is generated > -- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- 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: (MECLIPSE-346) WTP-2 support, wrong version of EAR facet is generated
WTP-2 support, wrong version of EAR facet is generated -- Key: MECLIPSE-346 URL: http://jira.codehaus.org/browse/MECLIPSE-346 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied WTP-2.0 patch Reporter: Siarhei Dudzin Fix For: 2.5 After using parent pom settings from test project 34 or 35 ( Revision 595865: /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 ) I've generated the project. As a result I had an error "The deployment descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using jboss seam as an ejb module). After checking facets I've found that the the ear module had ear version 1.4 in org.eclipse.wst.common.project.facet.core.xml: instead of 5.0. After manually changing the facet version to and re-adding the project to the workspace the problem go resolved. -- 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: (CONTINUUM-1519) Continuum does not respect build order for flat projects
[ http://jira.codehaus.org/browse/CONTINUUM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110704 ] Siarhei Dudzin commented on CONTINUUM-1519: --- I've used file system in scm info, so you would need to modify it for all modules, for the rest it should work out of the box. > Continuum does not respect build order for flat projects > > > Key: CONTINUUM-1519 > URL: http://jira.codehaus.org/browse/CONTINUUM-1519 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 > Environment: Windows XP/2003 Server, Maven 2.0.7 >Reporter: Siarhei Dudzin >Priority: Blocker > Attachments: TEST-CONTINUUM-1519.zip > > > When adding maven 2 projects with flat project layout continuum sorts the > projects build sequence by alphabet thus braking builds. Previous version did > respect reactor build sequence and '--non-recursive' option allowed to build > flat projects independently but still in the right order. This is a very > blocking issue for us because we are forced atm to use flat project structure. -- 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: (CONTINUUM-1519) Continuum does not respect build order for flat projects
[ http://jira.codehaus.org/browse/CONTINUUM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated CONTINUUM-1519: -- Attachment: TEST-CONTINUUM-1519.zip Ok, attaching the example project. As you can see it adds the projects in alphabetic order. Another problem is that relative both paths and scm connection url for sub-projects are also not respected - I have to change scm urls in continuum for each project except project 'a' (the parent project). Project a is also the project I add (as parent ) to continuum. While reactor build order (log from maven): [INFO] Reactor build order: [INFO] a [INFO] e [INFO] d [INFO] c [INFO] b This is the order what I get in continuum: Project Name a b c d e Hope this helps. > Continuum does not respect build order for flat projects > > > Key: CONTINUUM-1519 > URL: http://jira.codehaus.org/browse/CONTINUUM-1519 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 > Environment: Windows XP/2003 Server, Maven 2.0.7 >Reporter: Siarhei Dudzin >Priority: Blocker > Attachments: TEST-CONTINUUM-1519.zip > > > When adding maven 2 projects with flat project layout continuum sorts the > projects build sequence by alphabet thus braking builds. Previous version did > respect reactor build sequence and '--non-recursive' option allowed to build > flat projects independently but still in the right order. This is a very > blocking issue for us because we are forced atm to use flat project structure. -- 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: (CONTINUUM-1519) Continuum does not respect build order for flat projects
[ http://jira.codehaus.org/browse/CONTINUUM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109750 ] Siarhei Dudzin commented on CONTINUUM-1519: --- Small correction, the reactor build order is specified as I have given in the example with sections (sorry was a bit misleading in the beginning). > Continuum does not respect build order for flat projects > > > Key: CONTINUUM-1519 > URL: http://jira.codehaus.org/browse/CONTINUUM-1519 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 > Environment: Windows XP/2003 Server, Maven 2.0.7 >Reporter: Siarhei Dudzin >Priority: Blocker > > When adding maven 2 projects with flat project layout continuum sorts the > projects build sequence by alphabet thus braking builds. Previous version did > respect reactor build sequence and '--non-recursive' option allowed to build > flat projects independently but still in the right order. This is a very > blocking issue for us because we are forced atm to use flat project structure. -- 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: (CONTINUUM-1519) Continuum does not respect build order for flat projects
[ http://jira.codehaus.org/browse/CONTINUUM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109748 ] Siarhei Dudzin commented on CONTINUUM-1519: --- We use default schedule, same happens if I just use "build all projects" in a group, it just builds from top to bottom (thus list order defines the build order). We have the following dependencies (all flat structure): A (parent), has modules listed in the following order: B, C, D, E B (ear), has dependencies on: C (war), D(ejb) C (war) has dependencies on D (type ejb, scope provided), E (type jar) D (ejb) has dependencies on E (jar) E (jar) has no other dependencies As you can see there are not circular dependencies (otherwise maven would not build I imagine). The parent project has modules listed like this: ../E ../D ../C ../B Each sub project has a relative path to the parent pom: ../A/pom.xml I have the same project working in beta 2 only because it sorted the modules in the right order (still if I add an extra module to the group it does not reorder them but adds at the end thus forcing me to delete the projects from continuum and re-add them). I have not figured another way to build flat projects in continuum. > Continuum does not respect build order for flat projects > > > Key: CONTINUUM-1519 > URL: http://jira.codehaus.org/browse/CONTINUUM-1519 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 > Environment: Windows XP/2003 Server, Maven 2.0.7 >Reporter: Siarhei Dudzin >Priority: Blocker > > When adding maven 2 projects with flat project layout continuum sorts the > projects build sequence by alphabet thus braking builds. Previous version did > respect reactor build sequence and '--non-recursive' option allowed to build > flat projects independently but still in the right order. This is a very > blocking issue for us because we are forced atm to use flat project structure. -- 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: (CONTINUUM-1519) Continuum does not respect build order for flat projects
Continuum does not respect build order for flat projects Key: CONTINUUM-1519 URL: http://jira.codehaus.org/browse/CONTINUUM-1519 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-3 Environment: Windows XP/2003 Server, Maven 2.0.7 Reporter: Siarhei Dudzin Priority: Blocker When adding maven 2 projects with flat project layout continuum sorts the projects build sequence by alphabet thus braking builds. Previous version did respect reactor build sequence and '--non-recursive' option allowed to build flat projects independently but still in the right order. This is a very blocking issue for us because we are forced atm to use flat project structure. -- 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: (CONTINUUM-1408) CLONE -Problems running multi-module build with maven2
[ http://jira.codehaus.org/browse/CONTINUUM-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105447 ] Siarhei Dudzin commented on CONTINUUM-1408: --- The original issue was closed while the problem is still reproducable upto version 1.1-beta-2. > CLONE -Problems running multi-module build with maven2 > -- > > Key: CONTINUUM-1408 > URL: http://jira.codehaus.org/browse/CONTINUUM-1408 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.0.1 > Environment: linux debian >Reporter: Siarhei Dudzin > > Hello! > Maybe a similar problem has been posted, but i´ve got > problems running a multi-module maven2 build. > I´ve uploaded a small pom hirachy per URL as recommended, > the initialization of the sub modules in continuum has worked as wanted, > all poms defined in the modules element (below!) are located correctly. > The root pom has packaging type "pom" and a few modules are > included in the pom´s 'modules' element. > > > ../../signatur > ../library > ../weblib > ../portal > ../appserver/serverapp/Base > ../appserver/serverapp/UserManagement > ../appserver/serverapp/TemplateBeans > ../release/xml/infosets > ../release/xml/udFields > > > When i run the build, following exception occurs: > Reason: Could not find the model file > '/home/maven/tmp/continuum-1.0.1/apps/continuum/working-directory/37/../../signatur/pom.xml'. > > Since continuum creates a flat directory structure with automatically created > numbers as folder names, the corresponding > module can not be found at this location and the build stops. > My question is, if there is a way to determine the checkout folder, or have i > misunderstood anything? > I would be glad to establish continuum im my company, but i´m running out of > time. > Would be nice, if someone can give me an advice. > Greetings, > Wolfgang Klein -- 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: (CONTINUUM-1408) CLONE -Problems running multi-module build with maven2
CLONE -Problems running multi-module build with maven2 -- Key: CONTINUUM-1408 URL: http://jira.codehaus.org/browse/CONTINUUM-1408 Project: Continuum Issue Type: Task Components: Web interface Affects Versions: 1.0.1 Environment: linux debian Reporter: Siarhei Dudzin Hello! Maybe a similar problem has been posted, but i´ve got problems running a multi-module maven2 build. I´ve uploaded a small pom hirachy per URL as recommended, the initialization of the sub modules in continuum has worked as wanted, all poms defined in the modules element (below!) are located correctly. The root pom has packaging type "pom" and a few modules are included in the pom´s 'modules' element. ../../signatur ../library ../weblib ../portal ../appserver/serverapp/Base ../appserver/serverapp/UserManagement ../appserver/serverapp/TemplateBeans ../release/xml/infosets ../release/xml/udFields When i run the build, following exception occurs: Reason: Could not find the model file '/home/maven/tmp/continuum-1.0.1/apps/continuum/working-directory/37/../../signatur/pom.xml'. Since continuum creates a flat directory structure with automatically created numbers as folder names, the corresponding module can not be found at this location and the build stops. My question is, if there is a way to determine the checkout folder, or have i misunderstood anything? I would be glad to establish continuum im my company, but i´m running out of time. Would be nice, if someone can give me an advice. Greetings, Wolfgang Klein -- 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: (SCM-336) Usage or custom port number results in incorrect cvsroot string in .cvspass file
Usage or custom port number results in incorrect cvsroot string in .cvspass file Key: SCM-336 URL: http://jira.codehaus.org/browse/SCM-336 Project: Maven SCM Issue Type: Bug Affects Versions: 1.0 Environment: Continuum 1.1 beta-2 with java cvs client (default in this version) Reporter: Siarhei Dudzin Priority: Blocker When a project SCM url contains custom port number the .cvspass is not created properly - it has the custom port number appended to the default (2401) one. For example a URL scm:cvs:pserver:@:9280/CVS/ would result in 24019280 as port number in .cvspass file which results in inability to use SCM with customized port number when using java cvs client -- 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: (MECLIPSE-316) RadCleanMojo does not clean .war files
RadCleanMojo does not clean .war files -- Key: MECLIPSE-316 URL: http://jira.codehaus.org/browse/MECLIPSE-316 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: RAD support Affects Versions: 2.4 Reporter: Siarhei Dudzin Fix For: 2.5 RadCleanMojo only cleans jars in deleteJarArtifactsInDirectory() while RadLibCopier also copies .war files in RadLibCopier.copyArtifact( IdeDependency[] deps, File destDir ). RadCleanMojo also needs to clean .war files. -- 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: (MECLIPSE-315) RadWebSettingsWriter uses hardcoded webcontent path and ignores warSourceDirectory
RadWebSettingsWriter uses hardcoded webcontent path and ignores warSourceDirectory -- Key: MECLIPSE-315 URL: http://jira.codehaus.org/browse/MECLIPSE-315 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Reporter: Siarhei Dudzin org.apache.maven.plugin.eclipse.writers.rad.RadWebSettingsWriter uses hardcoded location of webcontent during writeModuleTypeFacetCore() (does writer.writeText( "src/main/webapp" ); directly ) and ignores warSourceDirectory which is used to customize the location of the webcontent (besides RAD-6 uses different directory structure hence this problem). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
