[jira] Commented: (MAVENUPLOAD-1628) Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102026 ] Roberto Lo Giacco commented on MAVENUPLOAD-1628: Oh and there was another problem too: the maven-metadata wasn't updated and it still reports the 1.2.0 version only! > Upload Request > -- > > Key: MAVENUPLOAD-1628 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1628 > Project: maven-upload-requests > Issue Type: Task >Reporter: Roberto Lo Giacco >Assignee: Carlos Sanchez > > SmartWeb is a rapid web application development framework based on apache > struts and hibernate. This package is a JUnit extension to allow easy unit > test of framework based web applications. > Please upload! > P.S. > Whenever I need to upload a new release, should I reply to this issue or > create a new one? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-761) Ability to delete results
[ http://jira.codehaus.org/browse/CONTINUUM-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-761. -- Resolution: Fixed Applied. Thanks > Ability to delete results > - > > Key: CONTINUUM-761 > URL: http://jira.codehaus.org/browse/CONTINUUM-761 > Project: Continuum > Issue Type: New Feature > Components: Core system >Affects Versions: 1.0.3 >Reporter: Srinivas Pavani >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-1 > > Attachments: CONTINUUM-761-nramirez.patch > > > There needs to be a way to delete old results. Especially useful when doing > frequent builds and for cleaning up failed build results. -- 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-723) strange trouble on solaris
[ http://jira.codehaus.org/browse/CONTINUUM-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Kolsi updated CONTINUUM-723: - Attachment: build.xml Added very simple Ant test build file which when executed in Solaris 10 SPARC environment with Continuum 1.0.3 gives wrong system time (does not take into account timezones). Same test works correctly with Continuum 1.1 SNAPSHOT. > strange trouble on solaris > --- > > Key: CONTINUUM-723 > URL: http://jira.codehaus.org/browse/CONTINUUM-723 > Project: Continuum > Issue Type: Bug > Components: Environmental >Affects Versions: 1.0.3 > Environment: solaris >Reporter: Olivier Lamy >Priority: Critical > Fix For: 1.1-beta-1 > > Attachments: build.xml, CONTINUUM-723.tar.gz > > > Hi, > I have a junit test with contains the following code : > SimpleDateFormat simpleDateFormat = new SimpleDateFormat( "-MM-dd", > Locale.FRANCE ); > // harcoded date due to xmlunit comparaison > Date timeStamp = simpleDateFormat.parse( "2001-05-28" ); > return DateTools.setNoonHour( timeStamp ); > FastDateFormat.getInstance( "-MM-dd'T'HH:mm:ss.SSSZZ" > ).format(date); > On windows+cygwin : 2001-05-28T12:00:00.000+02:00 > On solaris with same user who start continuum exec junit with cli : > 2001-05-28T12:00:00.000+02:00 > The same junit with continuum says : 2001-05-28T12:00:00.000+00:00 > Error says : > Expected attribute value '2001-05-28T12:00:00.000+02:00' but was > '2001-05-28T12:00:00.000+00:00' - comparing at > /OTA_HotelAvailRS[1]/@TimeStamp to at /OTA_HotelAvailRS[1]/@TimeStamp > I start continuum with $CONTINUUM_HOME/bin/plexus.sh > /dev/null & > The .profile contains : > ... > LANG=en_US.ISO8859-15 > export LANG > ##opts maven > MAVEN_OPTS="-Xmx512m -Xms512m -Dfile.encoding=ISO-8859-1" > export MAVEN_OPTS > ... > I don't change anything on plexus.sh script. > Any ideas ?? > Thanks, > -- > Olivier -- 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: (MRM-426) Search does not work for snapshots because of different version values in index and database when the snapshot version is unique
[ http://jira.codehaus.org/browse/MRM-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102032 ] Maria Odea Ching commented on MRM-426: -- See thread in archiva dev list with subject "Suggestions/thoughts anyone? (MRM-426)" for the discussion about the fix. > Search does not work for snapshots because of different version values in > index and database when the snapshot version is unique > > > Key: MRM-426 > URL: http://jira.codehaus.org/browse/MRM-426 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > > When an artifact with unique snapshots is searched from Archiva, the search > result would contain different hits for that artifact which has the same > version but when you click the version to browse the artifact.. an > ObjectNotFound error is returned. Below is an example of this behavior. > The artifact to be searched is castor-anttasks. Let's say it has 3 SNAPSHOT > versions 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and > 1.1.2-20070506.163513-3 in the repository, and the path to this artifact is > [REPO]/org/codehaus/castor/castor-anttasks/1.1.2-SNAPSHOT. > The search results would then look like this: > Hits: 3 of 3 > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > When you click either of the versions to browse the artifact, what you would > get is this error: > 'Unable to find project model for > [org.codehaus.castor:castor-anttasks:1.1.2-SNAPSHOT]' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-103) Input encoding handling problem
[ http://jira.codehaus.org/browse/DOXIA-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-103: Priority: Trivial (was: Major) Fix Version/s: 1.0-alpha-9 > Input encoding handling problem > --- > > Key: DOXIA-103 > URL: http://jira.codehaus.org/browse/DOXIA-103 > Project: doxia > Issue Type: Bug > Components: Site Renderer > Environment: Linux, Java 5 >Reporter: Sergey N. Zaitsev >Priority: Trivial > Fix For: 1.0-alpha-9 > > Attachments: default-site-renderer.diff > > > Site Renderer ignores parameter and uses ISO-8859-1 encoding > when reading source 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] Commented: (DOXIA-50) Improve the AptParser class
[ http://jira.codehaus.org/browse/DOXIA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102037 ] Lukas Theussl commented on DOXIA-50: I think this should be closed won't fix. * aptconvert doesn't recognize a physical ^L as a pagebreak, so it shouldn't be allowed * the order where a table caption is emitted is irrelevant for the parser (as long as it's the same for all parsers), it's the corresponding sinks that have to put the caption in the right place. We need to think to install a testing mechanism to ensure that all parsers emit events in the same order. * there is still something fishy about apt table parsing, but the above patch doesn't solve that for me, I will open a separate issue. > Improve the AptParser class > --- > > Key: DOXIA-50 > URL: http://jira.codehaus.org/browse/DOXIA-50 > Project: doxia > Issue Type: Improvement > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Vincent Siveton > Attachments: AptParser.diff > > > This patch provides some improvements for the AptParser: > * support of the pagebreak, ie ^L > * support of tableHeaderCell() call > * improve the tableCaption() call -- 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-2716) pluginRepositories seems to be ignored when running a goal without pom.xml
[ http://jira.codehaus.org/browse/MNG-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102038 ] Volker Fuessler commented on MNG-2716: -- Hi, I just did run into this problem by creating an archetype. My own central repo, defined in the settings.xml was ignored. Then i added an arbitrary pom.xml and my defined central repo was used. > pluginRepositories seems to be ignored when running a goal without pom.xml > -- > > Key: MNG-2716 > URL: http://jira.codehaus.org/browse/MNG-2716 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 > Environment: Linux debian 2.6.16-2-686 >Reporter: Milos Volauf > Fix For: Reviewed Pending Version Assignment > > Attachments: settings.xml > > > I wanted to try the maven-eclipse-plugin, the goal make-artifacts. > mvn eclipse:make-artifacts > However, make-artifacts goal is not in eclipse plugin 2.2, only in > 2.3-SNAPSHOT. > So followed guides and added pluginRepositry section into my > ~/.m2/settings.xml (attached) > so that I can use an apache plugin snapshot repository. > Then I tried: > mvn org.apache.maven.plugins:maven-eclipse-plugin:2.3-SNAPSHOT:make-artifacts > -P apache > But maven did not try to load the snapshot plugin: > ... > [INFO] Failed to resolve artifact. > GroupId: org.apache.maven.plugins > ArtifactId: maven-eclipse-plugin > Version: 2.3-SNAPSHOT > Reason: Unable to download the artifact from any repository > org.apache.maven.plugins:eclipse:pom:2.3-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > We can see that maven did not try the pluginRep. specified in settings.xml. > The I found out that if I run the command above in the folder where pom.xml > exists, it works. > (I created an initial project by archetype plugin.) > So it seems to me that this is a (maybe small) bug. Usually, people run maven > in folder where pom.xml exists, most goals require it. > However, certain goals can run without pom.xml (such as > eclipse:make-artifacts) and here it seems to me that maven ignored my > settings (pluginRepositories). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-89) Doxia Macro syntax for xdoc sucks
[ http://jira.codehaus.org/browse/DOXIA-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-89. -- Assignee: Lukas Theussl Resolution: Won't Fix > Doxia Macro syntax for xdoc sucks > - > > Key: DOXIA-89 > URL: http://jira.codehaus.org/browse/DOXIA-89 > Project: doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Henning Schmiedehausen >Assignee: Lukas Theussl > Attachments: doxia-core.patch > > > In the xdoc parser, Doxia uses to reference the 'foo' > macro. This is an unfortunate choice because it allows each macro on each > xdoc page only once (id must be unique). > I'd suggest that this gets changed to e.g. macroName. > Also, some macros (most prominently the snippet macro) might require an 'id' > parameter, which not only clashes with the notation above but also leaves the > problem that this id might clash with another id and can not be used twice on > a page. > I'd suggest that in a possible Doxia manual, the usage of an 'id' parameter > is strongly discouraged. > For the snippet macro, I'd suggest changing 'id' to 'snippetId'. -- 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: (DOXIA-131) HtmlTools.encodeId makes id lower case
[ http://jira.codehaus.org/browse/DOXIA-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102045 ] Vincent Siveton commented on DOXIA-131: --- Seems to be a typo: the javadoc is clear! Feel free to correct it with a test case! Also, the actual test case [1] should be moved to o.a.m.d.util in the src/test dir [1] https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/module/HtmlToolsTest.java > HtmlTools.encodeId makes id lower case > -- > > Key: DOXIA-131 > URL: http://jira.codehaus.org/browse/DOXIA-131 > Project: doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl > Fix For: 1.0-beta-1 > > > HtmlTools.encodeId uses Character.toLowerCase to convert its argument to > lower case. I don't see the reason for that since upper case characters are > legal in id's (see http://www.w3.org/TR/html4/types.html#type-name ). In > particular, it's a problem with anchors/links in the xhtml sink (see DOXIA-47 > ), especially if we want to create anchors from section names, to maintain > backward compatibility with m1. Is there a special reason for the toLowerCase > or can we remove it? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-50) Improve the AptParser class
[ http://jira.codehaus.org/browse/DOXIA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed DOXIA-50. Assignee: Vincent Siveton Resolution: Won't Fix As described > Improve the AptParser class > --- > > Key: DOXIA-50 > URL: http://jira.codehaus.org/browse/DOXIA-50 > Project: doxia > Issue Type: Improvement > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Attachments: AptParser.diff > > > This patch provides some improvements for the AptParser: > * support of the pagebreak, ie ^L > * support of tableHeaderCell() call > * improve the tableCaption() call -- 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: (DOXIA-131) HtmlTools.encodeId makes id lower case
[
http://jira.codehaus.org/browse/DOXIA-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102049
]
Lukas Theussl commented on DOXIA-131:
-
Hmm, I have a doubt: the apt user guide cites the following example for
anchor/link usage:
{noformat}
{Anchor}. Link to {{anchor}}. Link to {{{anchor}showing alternate text}}.
{noformat}
This gets converted by aptconvert into the following html:
{code:xml}
Anchor. Link to Anchor.
Link to showing alternate text.
{code}
Note the anchor name and id have become lower case. Now I don't see that
documented anywhere in the aptconvert guide (it only states "The name of an
anchor/link is its text with all non alphanumeric characters stripped."), and
it doesn't seem consistent since id's are case sensitive.
So I'd say we stick to not making id's lower case, but we have to adjust the
documentation...
> HtmlTools.encodeId makes id lower case
> --
>
> Key: DOXIA-131
> URL: http://jira.codehaus.org/browse/DOXIA-131
> Project: doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0-alpha-8
>Reporter: Lukas Theussl
> Fix For: 1.0-beta-1
>
>
> HtmlTools.encodeId uses Character.toLowerCase to convert its argument to
> lower case. I don't see the reason for that since upper case characters are
> legal in id's (see http://www.w3.org/TR/html4/types.html#type-name ). In
> particular, it's a problem with anchors/links in the xhtml sink (see DOXIA-47
> ), especially if we want to create anchors from section names, to maintain
> backward compatibility with m1. Is there a special reason for the toLowerCase
> or can we remove it?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1094) Continuum does not build with Sun JDK 6
[
http://jira.codehaus.org/browse/CONTINUUM-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed CONTINUUM-1094.
---
Assignee: Emmanuel Venisse
Resolution: Fixed
Fix Version/s: (was: 1.1-beta-2)
1.1-beta-1
> Continuum does not build with Sun JDK 6
> ---
>
> Key: CONTINUUM-1094
> URL: http://jira.codehaus.org/browse/CONTINUUM-1094
> Project: Continuum
> Issue Type: Bug
> Components: Environmental
>Affects Versions: 1.1-alpha-1
> Environment: continuum trunk r490449
> linux 2.6.12
> Sun JDK 6 (build 1.6.0-b105)
>Reporter: Minto van der Sluis
>Assignee: Emmanuel Venisse
> Fix For: 1.1-beta-1
>
> Attachments:
> org.apache.maven.continuum.management.DataManagementToolTest.txt
>
>
> snippet of the build output (mvn clean install).
> ...
> [INFO]
>
> [INFO] Building Continuum Data Management API
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target
> [INFO] Deleting directory
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/classes
> [INFO] Deleting directory
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/test-classes
> [INFO] [plexus:descriptor {execution: generate}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> Compiling 2 source files to
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/classes
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> Compiling 1 source file to
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/test-classes
> [INFO] [surefire:test]
> [INFO] Surefire report directory:
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/surefire-reports
> ---
> T E S T S
> ---
> Running org.apache.maven.continuum.management.DataManagementToolTest
> Tests run: 3, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 8.348 sec <<<
> FAILURE!
> Results :
> Tests run: 3, Failures: 0, Errors: 2, Skipped: 0
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> Builds with JDK 5 runs just fine.
--
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: (DOXIA-132) test order of parsing events
test order of parsing events Key: DOXIA-132 URL: http://jira.codehaus.org/browse/DOXIA-132 Project: doxia Issue Type: Task Components: Core Reporter: Lukas Theussl Fix For: 1.0-beta-1 For some elements (especially tables and figures), it is essential that a parser emits events in a specified order. We could adapt the WellformednessCheckingSink to test that. -- 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-3101) External link to jetty plugin info now invalid
External link to jetty plugin info now invalid -- Key: MNG-3101 URL: http://jira.codehaus.org/browse/MNG-3101 Project: Maven 2 Issue Type: Bug Components: Sites & Reporting Affects Versions: Documentation Reporter: Gwyn Evans Priority: Minor On the http://maven.apache.org/plugins/index.html page, the "jetty" link is http://jetty.mortbay.org/maven-plugin/howto.html but that now gives 404 - It looks to me as if it should now point to http://jetty.mortbay.org/maven-plugin/index.html or http://jetty.mortbay.org/maven-plugin/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3101) External link to jetty plugin info now invalid
[ http://jira.codehaus.org/browse/MNG-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNG-3101. Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: Documentation Fixed in SVN r555610. > External link to jetty plugin info now invalid > -- > > Key: MNG-3101 > URL: http://jira.codehaus.org/browse/MNG-3101 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: Documentation >Reporter: Gwyn Evans >Assignee: Dennis Lundberg >Priority: Minor > Fix For: Documentation > > > On the http://maven.apache.org/plugins/index.html page, the "jetty" link is > http://jetty.mortbay.org/maven-plugin/howto.html but that now gives 404 - It > looks to me as if it should now point to > http://jetty.mortbay.org/maven-plugin/index.html or > http://jetty.mortbay.org/maven-plugin/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-242) remove plexus utils sources from site plugin sources since it is a dependency
[ http://jira.codehaus.org/browse/MSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSITE-242: Fix Version/s: 2.0-beta-6 > remove plexus utils sources from site plugin sources since it is a dependency > - > > Key: MSITE-242 > URL: http://jira.codehaus.org/browse/MSITE-242 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Herve Boutemy > Fix For: 2.0-beta-6 > > > the dependency has been uncommented, but the source code copy hasn't been > removed -- 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: (MSITE-242) remove plexus utils sources from site plugin sources since it is a dependency
remove plexus utils sources from site plugin sources since it is a dependency - Key: MSITE-242 URL: http://jira.codehaus.org/browse/MSITE-242 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Herve Boutemy Fix For: 2.0-beta-6 the dependency has been uncommented, but the source code copy hasn't been removed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-132) Using the src/main/javadoc directory for package.html files just doesn't work
[
http://jira.codehaus.org/browse/MJAVADOC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102059
]
Vincent Siveton commented on MJAVADOC-132:
--
I tried what you said and I think it is a normal way for the javadoc tool (not
the plugin)
Here is the structure of your application:
{noformat}
your-simple-java-aid
|-- src
|-- main
|-- java
|-- your
|-- simple
|-- java
|-- gid
`-- App.java
|-- javadoc
|-- your
`-- package.html (BTW echo doesnt provide a valid html file)
...
{noformat}
The package "your" has no class so it is ignored by the tool. If you move it to
src\main\javadoc\your\simple\java\gid, it is include in the report.
So I would close it as wont fix. WDYT?
> Using the src/main/javadoc directory for package.html files just doesn't work
> -
>
> Key: MJAVADOC-132
> URL: http://jira.codehaus.org/browse/MJAVADOC-132
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: jano
>
> Using the src/main/javadoc directory for package.html files just doesn't work.
> I can see from debug -X that javadocDirectory is passed with the correct
> setting.
> This is using either 2.2 or 2.3-SNAPSHOT, using JDK 1.5.0_12 and maven 2.0.6.
> Since i have exactly the same problem i just quoted
> http://mail-archives.apache.org/mod_mbox/maven-users/200706.mbox/[EMAIL
> PROTECTED]
> How to reproduce? create a new application, add a resource and run javadoc
> mvn archetype:create -DgroupId=your.simple.java.gid
> -DartifactId=your-simple-java-aid
> mkdir -p your-simple-java-aid/src/main/javadoc/your
> echo sample > your-simple-java-aid/src/main/javadoc/your/package.html
> mvn javadoc:javadoc
--
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-3102) Add a skip attribute to the plugin, similar to inherited to allow for a plugin to be skipped for a particular child project if that plugin is inherited
Add a skip attribute to the plugin, similar to inherited to allow for a plugin to be skipped for a particular child project if that plugin is inherited --- Key: MNG-3102 URL: http://jira.codehaus.org/browse/MNG-3102 Project: Maven 2 Issue Type: New Feature Components: Plugins and Lifecycle Reporter: Tomislav Stojcevich Priority: Minor There are times where it is convenient to define a plugin for all child projects except for a few. Adding a skip attribute at the plugin definition level (similar to inherited) would allow for the addition/configuration of a plugin in a parent pom that would be inherited to all children. For the few children where that plugin either doesn't make sense or causes needless executions or errors, this would allow for it to be skipped. There are a few plugins that already include skip as a configuration option. Adding it at the higher level, making it available to all plugins would allow any plugin to make use of it and not have to define it's own skip configuration parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-133) default XML encoding (UTF-8) or XML encoding set in XML files is ignored: inputEncoding is used instead
default XML encoding (UTF-8) or XML encoding set in XML files is ignored:
inputEncoding is used instead
---
Key: DOXIA-133
URL: http://jira.codehaus.org/browse/DOXIA-133
Project: doxia
Issue Type: Bug
Components: Site Renderer
Affects Versions: 1.0-alpha-8
Reporter: Herve Boutemy
Encoding can be specified per file, in the XML header: , or defaults to UTF-8
But DefaultSiteRenderer class always read files with inputEncoding: {{reader =
new InputStreamReader( new FileInputStream( fullPathDoc ),
context.getInputEncoding() );}}
When the source file is XML (xdoc, xhtml), should use XmlReader from
PLXUTILS-11 to detect the XML stream encoding instead.
Test case included in MSITE-239, site-plugin-test14
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1320) DefaultBuildController.makeAndStoreBuildResult cannot save build result due to maximum size of COMMAND_LINE
[ http://jira.codehaus.org/browse/CONTINUUM-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1320. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-beta-1 > DefaultBuildController.makeAndStoreBuildResult cannot save build result due > to maximum size of COMMAND_LINE > --- > > Key: CONTINUUM-1320 > URL: http://jira.codehaus.org/browse/CONTINUUM-1320 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-2 > Environment: Continuum with Perforce SCM >Reporter: Matthias Wurm >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-1 > > > Since the maven perforce scm provider creates temporary client specs with a > long name (see below), the checkout command gets quite long, too, and hence > cannot be save in the COMMAND_LINE column due to the maximum size of 256. > Here is the stack trace: > 2007-06-19 13:06:40,122 [Thread-6] ERROR TaskQueueExecutor:build-project - > Error executing task > edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: > javax.jdo.JDOFatalUserException: Attempt to store value "p4 -d > /home/continuum/local/continuum-1.1-alpha-2/apps/continuum/webapp/WEB-INF/working-directory/1 > -p perforce.mycompany.com:1666 > -cperforce-host.mycompany.com-MavenSCM-\home\continuum\local\continuum-1.1-alpha-2\apps\continuum\webapp\WEB-INF\working-directory\1 > sync" in column "COMMAND_LINE" that has maximum length of 256. Please > correct your data! > at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) > at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:128) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:165) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) > Caused by: javax.jdo.JDOFatalUserException: Attempt to store value "p4 -d > /home/continuum/local/continuum-1.1-alpha-2/apps/continuum/webapp/WEB-INF/working-directory/1 > -p perforce.mycompany.com:1666 > -cperforce-host.mycompany.com-MavenSCM-\home\continuum\local\continuum-1.1-alpha-2\apps\continuum\webapp\WEB-INF\working-directory\1 > sync" in column "COMMAND_LINE" that has maximum length of 256. Please > correct your data! > at > org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214) > at > org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203) > at > org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122) > at > org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2757) > at > org.apache.maven.continuum.model.scm.ScmResult.jdoProvideField(ScmResult.java) > at > org.apache.maven.continuum.model.scm.ScmResult.jdoProvideFields(ScmResult.java) > at > org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) > at > org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) > at > org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) > at > org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) > at > org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:450) > at > org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:144) > at > org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2771) > at > org.apache.maven.continuum.model.project.BuildResult.jdoProvideField(BuildResult.java) > at > org.apache.maven.continuum.model.project.BuildResult.jdoProvideFields(BuildResult.java) > at > org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManager
[jira] Updated: (MSITE-239) encoding declaration in site.xml is ignored
[ http://jira.codehaus.org/browse/MSITE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSITE-239: Attachment: (was: MSITE-239.diff) > encoding declaration in site.xml is ignored > --- > > Key: MSITE-239 > URL: http://jira.codehaus.org/browse/MSITE-239 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5 >Reporter: Herve Boutemy > Fix For: 2.0-beta-6 > > > when PLXUTILS-11 will be fixed, and XmlReader will be available, there won't > be any problem to fix this one -- 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: (MSITE-239) encoding declaration in site.xml is ignored
[ http://jira.codehaus.org/browse/MSITE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSITE-239: Attachment: MSITE-239.tgz MSITE-239.diff ok, here is a new patch, and a testcase The testcase is written in UTF-16, just to be sure nobody has the same platform default encoding. About xdoc files, I opened another Jira issue DOXIA-133, since the encoding is not detected file by file in each XML file, but the inputEncoding parameter from the maven-site-plugin is used > encoding declaration in site.xml is ignored > --- > > Key: MSITE-239 > URL: http://jira.codehaus.org/browse/MSITE-239 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5 >Reporter: Herve Boutemy > Fix For: 2.0-beta-6 > > Attachments: MSITE-239.diff, MSITE-239.tgz > > > when PLXUTILS-11 will be fixed, and XmlReader will be available, there won't > be any problem to fix this one -- 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-72) Support For Jboss Configuration to include module-order attribute
Support For Jboss Configuration to include module-order attribute - Key: MEAR-72 URL: http://jira.codehaus.org/browse/MEAR-72 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Sairam Rekapalli Priority: Blocker Currently module-order attribute for Jboss is not recognized by the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-266) plugin applies java facet to ear project
[ http://jira.codehaus.org/browse/MECLIPSE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102074 ] Srepfler Srgjan commented on MECLIPSE-266: -- Why would I add a dependency to anything if there is already a version tag in the ear plugin specification? Why all the heuristics on the j2ee implementation (that are limited as there are many implementations and some are having licence issues) if someone already declares things in the pom, is DRY no longer valid? > plugin applies java facet to ear project > > > Key: MECLIPSE-266 > URL: http://jira.codehaus.org/browse/MECLIPSE-266 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.3 > Environment: Windows XP >Reporter: Srepfler Srgjan > > In .settings/org.eclipse.wst.common.project.facet.core.xml of the EAR module > I'm getting this: > > > > > > > This is a wrong facet on a EAR module and I can't compile if I don't edit > this file manually (I can't do it from the project properties - facets dialog) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1119) Creating a Group with an existing id errors
[ http://jira.codehaus.org/browse/CONTINUUM-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1119. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-beta-1 > Creating a Group with an existing id errors > --- > > Key: CONTINUUM-1119 > URL: http://jira.codehaus.org/browse/CONTINUUM-1119 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1-alpha-1 > Environment: svn trunk, Tomcat 5.5 >Reporter: Henri Yandell >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-1 > > > If you create a new group with the same group id as another, you get: > Error Occurred > Show/hide Stack Trace > Clicking on the Show/hide doesn't show anything. A plexus user repeated the > issue and found this in the log: > ERROR Action:addProjectGroup- Error adding project group: Unable to > add the requested project group: groupId already exists. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1637) httpunit 1.6.2
httpunit 1.6.2 -- Key: MAVENUPLOAD-1637 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1637 Project: maven-upload-requests Issue Type: Task Reporter: fabrizio giustina httpunit 1.6.2 pom identical to the 1.6.1 version, plus url/license added and a few dipendences made optional (they are really optional!) -- 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-301) eclipse:clean doesn't respect packaging 'pom'
eclipse:clean doesn't respect packaging 'pom' - Key: MECLIPSE-301 URL: http://jira.codehaus.org/browse/MECLIPSE-301 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Roland Asmann When running 'eclipse:clean eclipse:eclipse' on my multi-module project, the root-project's .project file is deleted by 'eclipse:clean', but is not restored. If this happens outside of eclipse, the project is closed in eclipse and can't be opened anymore... If it happens inside eclipse (e.g. by using maven as an external tool), eclipse will prompt that the file is missing, but will ultimately generate a new .project file itself. I feel that 'eclipse:clean' should do the same thing as the 'eclipse:eclipse' does: DON'T do anything in projects that have packaging 'pom'. -- 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-72) Support For Jboss Configuration to include module-order attribute
[ http://jira.codehaus.org/browse/MEAR-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-72: Priority: Major (was: Blocker) man take it easy. I've never seen a blocker improvement so far. > Support For Jboss Configuration to include module-order attribute > - > > Key: MEAR-72 > URL: http://jira.codehaus.org/browse/MEAR-72 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Sairam Rekapalli > > Currently module-order attribute for Jboss is not recognized by the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1638) rhino-js-1.6R6-candidate2
rhino-js-1.6R6-candidate2 - Key: MAVENUPLOAD-1638 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1638 Project: maven-upload-requests Issue Type: Task Reporter: Manuel Molaschi Downloaded from ftp://ftp.mozilla.org/pub/mozilla.org/js/ New features in 1.6R6 can be found at http://developer.mozilla.org/en/docs/New_in_Rhino_1.6R6 -- 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: (DOXIA-133) default XML encoding (UTF-8) or XML encoding set in XML files is ignored: inputEncoding is used instead
[
http://jira.codehaus.org/browse/DOXIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated DOXIA-133:
Attachment: DOXIA-133_doxia-siterenderer.diff
DOXIA-133_doxia.diff
here are 2 patches to add XML encoding detection for contents that are defined
in XML: xdoc, xhtml, docbook, fml
> default XML encoding (UTF-8) or XML encoding set in XML files is ignored:
> inputEncoding is used instead
> ---
>
> Key: DOXIA-133
> URL: http://jira.codehaus.org/browse/DOXIA-133
> Project: doxia
> Issue Type: Bug
> Components: Site Renderer
>Affects Versions: 1.0-alpha-8
>Reporter: Herve Boutemy
> Attachments: DOXIA-133_doxia-siterenderer.diff, DOXIA-133_doxia.diff
>
>
> Encoding can be specified per file, in the XML header: encoding="xxx"?>, or defaults to UTF-8
> But DefaultSiteRenderer class always read files with inputEncoding: {{reader
> = new InputStreamReader( new FileInputStream( fullPathDoc ),
> context.getInputEncoding() );}}
> When the source file is XML (xdoc, xhtml), should use XmlReader from
> PLXUTILS-11 to detect the XML stream encoding instead.
> Test case included in MSITE-239, site-plugin-test14
--
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: (DOXIA-133) default XML encoding (UTF-8) or XML encoding set in XML files is ignored: inputEncoding is used instead
[
http://jira.codehaus.org/browse/DOXIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated DOXIA-133:
Component/s: Module - Xhtml
Module - Xdoc
Module - Fml
Module - Docbook Simple
Core
Patch Submitted: [Yes]
> default XML encoding (UTF-8) or XML encoding set in XML files is ignored:
> inputEncoding is used instead
> ---
>
> Key: DOXIA-133
> URL: http://jira.codehaus.org/browse/DOXIA-133
> Project: doxia
> Issue Type: Bug
> Components: Core, Module - Docbook Simple, Module - Fml, Module -
> Xdoc, Module - Xhtml, Site Renderer
>Affects Versions: 1.0-alpha-8
>Reporter: Herve Boutemy
> Attachments: DOXIA-133_doxia-siterenderer.diff, DOXIA-133_doxia.diff
>
>
> Encoding can be specified per file, in the XML header: encoding="xxx"?>, or defaults to UTF-8
> But DefaultSiteRenderer class always read files with inputEncoding: {{reader
> = new InputStreamReader( new FileInputStream( fullPathDoc ),
> context.getInputEncoding() );}}
> When the source file is XML (xdoc, xhtml), should use XmlReader from
> PLXUTILS-11 to detect the XML stream encoding instead.
> Test case included in MSITE-239, site-plugin-test14
--
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: (DOXIA-133) default XML encoding (UTF-8) or XML encoding set in XML files is ignored: inputEncoding is used instead
[
http://jira.codehaus.org/browse/DOXIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated DOXIA-133:
Fix Version/s: 1.0-alpha-9
> default XML encoding (UTF-8) or XML encoding set in XML files is ignored:
> inputEncoding is used instead
> ---
>
> Key: DOXIA-133
> URL: http://jira.codehaus.org/browse/DOXIA-133
> Project: doxia
> Issue Type: Bug
> Components: Core, Module - Docbook Simple, Module - Fml, Module -
> Xdoc, Module - Xhtml, Site Renderer
>Affects Versions: 1.0-alpha-8
>Reporter: Herve Boutemy
> Fix For: 1.0-alpha-9
>
> Attachments: DOXIA-133_doxia-siterenderer.diff, DOXIA-133_doxia.diff
>
>
> Encoding can be specified per file, in the XML header: encoding="xxx"?>, or defaults to UTF-8
> But DefaultSiteRenderer class always read files with inputEncoding: {{reader
> = new InputStreamReader( new FileInputStream( fullPathDoc ),
> context.getInputEncoding() );}}
> When the source file is XML (xdoc, xhtml), should use XmlReader from
> PLXUTILS-11 to detect the XML stream encoding instead.
> Test case included in MSITE-239, site-plugin-test14
--
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: (MANTTASKS-14) Ant Tasks do not work on the ZOS
[ http://jira.codehaus.org/browse/MANTTASKS-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-14: --- Attachment: MANTTASKS-14.diff here is a patch to support encoding in settings.xml for encoding in other internal XML files in plexus-container, the work is in PLX-343 > Ant Tasks do not work on the ZOS > > > Key: MANTTASKS-14 > URL: http://jira.codehaus.org/browse/MANTTASKS-14 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Environment: OS: Z/OS 1.4 > JDK 1.4.2 > Ant 1.6.5 >Reporter: Jeff Maxwell >Priority: Critical > Attachments: MANTTASKS-14.diff > > > The current distribution does not work on Z/OS without modification. > The issue stems from the XML parser. > The plexus MXParser (org.codehaus.plexus.util.xml.pull.MXParser) does not > handle xml encoding and different character sets properly. > Any xml files that are sent to the MXParser MUST be in the same character set > as the operating system default. > Three files in the distribution META-INF/plexus/components.xml, > org/apache/maven/project/pom-4.0.0.xml and > org/codehaus/plexus/plexus-bootstrap.xml must be converted to EBCDIC in order > for the ant tasks to function. > Also any poms must be in EBCDIC regardless of the xml encoding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1628) Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102089 ] Carlos Sanchez commented on MAVENUPLOAD-1628: - fixed the test artifact, for metadata you have to use a synced repo, we don't update the metadata for manual uploaded bundles > Upload Request > -- > > Key: MAVENUPLOAD-1628 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1628 > Project: maven-upload-requests > Issue Type: Task >Reporter: Roberto Lo Giacco >Assignee: Carlos Sanchez > > SmartWeb is a rapid web application development framework based on apache > struts and hibernate. This package is a JUnit extension to allow easy unit > test of framework based web applications. > Please upload! > P.S. > Whenever I need to upload a new release, should I reply to this issue or > create a new one? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1308) error moving projects to a new group
[ http://jira.codehaus.org/browse/CONTINUUM-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1308. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-beta-1 Fixed. > error moving projects to a new group > > > Key: CONTINUUM-1308 > URL: http://jira.codehaus.org/browse/CONTINUUM-1308 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1-alpha-2 >Reporter: Brett Porter >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-1 > > > javax.jdo.JDODetachedFieldAccessException: You have just attempted to > access field "projects" yet this field was not detached when you detached the > object. Either dont access this field, or detach the field when detaching the > object. > at > org.apache.maven.continuum.model.project.ProjectGroup.jdoGetprojects(ProjectGroup.java) > at > org.apache.maven.continuum.model.project.ProjectGroup.getProjects(ProjectGroup.java:237) > at > org.apache.maven.continuum.model.project.ProjectGroup.createProjectAssociation(ProjectGroup.java:141) > at > org.apache.maven.continuum.model.project.Project.setProjectGroup(Project.java:818) > at > org.apache.maven.continuum.web.action.ProjectGroupAction.save(ProjectGroupAction.java:316) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:73) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:103) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInt
[jira] Closed: (MAVENUPLOAD-1637) httpunit 1.6.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1637. --- Assignee: Carlos Sanchez Resolution: Fixed > httpunit 1.6.2 > -- > > Key: MAVENUPLOAD-1637 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1637 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina >Assignee: Carlos Sanchez > > httpunit 1.6.2 > pom identical to the 1.6.1 version, plus url/license added and a few > dipendences made optional (they are really optional!) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1638) rhino-js-1.6R6-candidate2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1638. --- Assignee: Carlos Sanchez Resolution: Fixed > rhino-js-1.6R6-candidate2 > - > > Key: MAVENUPLOAD-1638 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1638 > Project: maven-upload-requests > Issue Type: Task >Reporter: Manuel Molaschi >Assignee: Carlos Sanchez > > Downloaded from ftp://ftp.mozilla.org/pub/mozilla.org/js/ > New features in 1.6R6 can be found at > http://developer.mozilla.org/en/docs/New_in_Rhino_1.6R6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1636) Upload JIDE Common Layer 2.1.1 to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1636. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload JIDE Common Layer 2.1.1 to maven repository > -- > > Key: MAVENUPLOAD-1636 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1636 > Project: maven-upload-requests > Issue Type: Task >Reporter: David Qiao >Assignee: Carlos Sanchez > > JIDE Common Layer is Swing component library built on top of Java/Swing. It > is also the foundation of other component products from JIDE. This project > has over 30 Swing components and over 100k lines of code. It greatly enhanced > the default component set provided by Swing and allow developers to focus on > business logic layer instead of making components. > JIDE Common Layer was originally developed by JIDE Software developers as a > foundation in order to build other more advanced components. In April of > 2007, JIDE Software decided to open source this common layer so that more and > more developers can leverage them instead of wasting time building them > again. > For more information, please visit project home page on JIDE Software website > at http://www.jidesoft.com/products/oss.htm or on java.net at > https://jide-oss.dev.java.net. -- 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-1317) Builds hand when JUNIT assertion failure text > 8192 characters
[ http://jira.codehaus.org/browse/CONTINUUM-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1317: Priority: Critical (was: Blocker) > Builds hand when JUNIT assertion failure text > 8192 characters > --- > > Key: CONTINUUM-1317 > URL: http://jira.codehaus.org/browse/CONTINUUM-1317 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-2 >Reporter: Bryan Madsen >Priority: Critical > Fix For: 1.1-beta-2 > > > The output file for the build shows the project has completed building yet > the display in the project page show the project stuck in a building state. > Exception follows: > 2450900 [Thread-6] ERROR > org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - > Error executing task > edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: > javax.jdo.JDOFatalUserException: Attempt to store value > "org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error > executing action 'execute-builder' > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:145) > 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:595) > Caused by: javax.jdo.JDOFatalUserException: Attempt to store value > "junit.framework.AssertionFailedError: Line does not contain expected text > ... > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.assertTrue(Assert.java:20) > at > com.cerner.msvc.signatureline.SignatureLineManagerTest.test199535_AllSupportedElements(SignatureLineManagerTest.java:440) > " in column "EXCEPTIONSTRING" that has maximum length of 8192. Please correct > your data! > at > org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214) > at > org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203) > at > org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122) > at > org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2757) > at > org.apache.maven.continuum.model.scm.TestCaseFailure.jdoProvideField(TestCaseFailure.java) > at > org.apache.maven.continuum.model.scm.TestCaseFailure.jdoProvideFields(TestCaseFailure.java) > at > org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) > at > org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) > at > org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) > at > org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) > at > org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231) > at > org.jpox.store.rdbms.scostore.FKListStore.internalAdd(FKListStore.java:772) > at > org.jpox.store.rdbms.scostore.AbstractListStore.addAll(AbstractListStore.java:386) > at > org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:209) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:464) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) > at > org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) > at > org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:11
[jira] Commented: (MAVENUPLOAD-1635) Upload maven artifacts from repository.ops4j.org to the cetral maven repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102091 ] Carlos Sanchez commented on MAVENUPLOAD-1635: - please attach here the script as the other ones that are already > Upload maven artifacts from repository.ops4j.org to the cetral maven repo > - > > Key: MAVENUPLOAD-1635 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1635 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Peter Neubauer > > http://repository.ops4j.org/maven2/org/ops4j/ > http://www.ops4j.org > http://wiki.ops4j.org/confluence/display/[EMAIL PROTECTED]/Home > OPS4J is creating mainly OSGi related infrastructure and tools. > How do I provide the sync script info, do I attach it here? -- 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: (MANTTASKS-78) unable to download parent pom when it is a SNAPSHOT and multiple remoteRepositories are used
unable to download parent pom when it is a SNAPSHOT and multiple remoteRepositories are used Key: MANTTASKS-78 URL: http://jira.codehaus.org/browse/MANTTASKS-78 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: POM Integration Affects Versions: 2.0.7 Reporter: Herve Boutemy the conditions for this problem are very precise: but if the second remoteRepository is removed, or even the 2 repositories switched, there is no 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: (MANTTASKS-78) unable to download parent pom when it is a SNAPSHOT and multiple remoteRepositories are used
[ http://jira.codehaus.org/browse/MANTTASKS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-78: --- Attachment: MANTTASKS-78.diff > unable to download parent pom when it is a SNAPSHOT and multiple > remoteRepositories are used > > > Key: MANTTASKS-78 > URL: http://jira.codehaus.org/browse/MANTTASKS-78 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: POM Integration >Affects Versions: 2.0.7 >Reporter: Herve Boutemy > Attachments: MANTTASKS-78.diff > > > the conditions for this problem are very precise: > id="my.maven.project.SNAPSHOT"> > > > > > but if the second remoteRepository is removed, or even the 2 repositories > switched, there is no 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: (WAGONSSH-42) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGONSSH-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102098 ] Benjamin Bentmann commented on WAGONSSH-42: --- I ran into this problem today and would like to clarify the cause for it. Maven's SftpWagon tries to set the file permissions after file upload, i.e. it issues a chmod on the file (see your stack trace). However, changing file permissions is only allowed to the file owner. Users having full file access (777) may change the file contents but only the owner may change its permissions. For the moment, we simple use "scp" as the protocol rather than "sftp". The ScpWagen seems to successfully deploy regardless which user currently owns the file in the repo. Unfortunately, the ScpWagen seems to struggle with file permissions. It does not grant write permission to the group. I'm still invastigating why it does not honor the 664 element in the settings.xml. For now, we manully grant write permissions after an initial deploy. Later on, the ScpWagen seems not to change the permissions. > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGONSSH-42 > URL: http://jira.codehaus.org/browse/WAGONSSH-42 > Project: wagon-ssh > Issue Type: Bug >Affects Versions: 1.0-alpha-6 > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Priority: Critical > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- 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-266) plugin applies java facet to ear project
[ http://jira.codehaus.org/browse/MECLIPSE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102100 ] Thierry Levieux commented on MECLIPSE-266: -- "Why would I add a dependency to anything if there is already a version tag in the ear plugin specification?" I think maven has been designed so as the plugins are as agnostics as possible, to avoid cross plugins dependencies. By agnostic I mean they don't know about each other (maybe one exception is maven-compiler-plugin). Please correct me if I am wrong... Personally, I always start thinking of plugins as functionalities, so you can easily answer the former question: - I need to generate an eclipse project that represents an EAR. - who is responsible for generating the artifacts (.project .classpath .settings..) ? - ear plugin ? No, it is a packaging tool. - eclipse plugin ? Yes, it generates my eclipse artifacts. Now you can forget your ear/ant/tomcat/coffee... plugins ! If you have an issue with wtp, the responsibles are either the eclipse plugin itself (a bug), its configuration or the project attributes (i.e jar packaging instead of ear packaging, for instance)... By the way, have you succeed in generating your project ? Thierry > plugin applies java facet to ear project > > > Key: MECLIPSE-266 > URL: http://jira.codehaus.org/browse/MECLIPSE-266 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.3 > Environment: Windows XP >Reporter: Srepfler Srgjan > > In .settings/org.eclipse.wst.common.project.facet.core.xml of the EAR module > I'm getting this: > > > > > > > This is a wrong facet on a EAR module and I can't compile if I don't edit > this file manually (I can't do it from the project properties - facets dialog) -- 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-72) Support For Jboss Configuration to include module-order attribute
[ http://jira.codehaus.org/browse/MEAR-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sairam Rekapalli updated MEAR-72: - Attachment: maven-ear-plugin.patch Please apply the patch at your convenience. It adds the module-order element if specified in the POM to jboss-app.xml. > Support For Jboss Configuration to include module-order attribute > - > > Key: MEAR-72 > URL: http://jira.codehaus.org/browse/MEAR-72 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Sairam Rekapalli > Attachments: maven-ear-plugin.patch > > > Currently module-order attribute for Jboss is not recognized by the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGONSSH-44) directoryPermissions is not repected when I deploy a POM
[ http://jira.codehaus.org/browse/WAGONSSH-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102106 ] Benjamin Bentmann commented on WAGONSSH-44: --- I'm still experiencing the fact, that ScpWagon does neither properly honor the nor sets usable permissions (664) by default. The missing write permission for the group is especially quite frustrating when multiple developers work on a single project. We're using Maven 2.0.7 and currently have not found any solution that allows for smooth deployment via SSH. SFTP struggles with ownerships (http://jira.codehaus.org/browse/WAGONSSH-42) and SCP needs manual correction to the file permissions (fortunately, only after the initial deploy). It's getting a little off-topic right now, but I would appreciate any hints on how to replace the bundled versions of Wagon-Providers. From my testing I got the impression, that Maven currently ignores the element when specifying the for Wagon. It always seems to use the classes bundled in its maven-core-2.0.7-uber.jar. > directoryPermissions is not repected when I deploy a POM > > > Key: WAGONSSH-44 > URL: http://jira.codehaus.org/browse/WAGONSSH-44 > Project: wagon-ssh > Issue Type: Bug > Environment: Debian Linux unstable, Sun JDK 1.5.0_06 >Reporter: Trustin Lee >Assignee: Brett Porter > Attachments: wagon-permission-patch.diff > > > It seems like 'directoryPermissions' doesn't work at all though > 'filePermissions' do. I tried both scp and scpexe. Nothing worked. I also > changed my umask to 002, but it didn't help at all. > If you have committership in the Apache Directory Project (Brett? :), then > you can try it by yourself: > > svn co https://svn.apache.org/repos/asf/directory/trunks/ directory > cd directory > mvn --non-recursive deploy > > This is my ~/.m2/settings.xml > > > > > > apache.snapshots > trustin > /home/trustin/.ssh/id_rsa > 0775 > 0664 > > > > -- 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-302) resolveVersionRanges crashes on system.bundle
resolveVersionRanges crashes on system.bundle
-
Key: MECLIPSE-302
URL: http://jira.codehaus.org/browse/MECLIPSE-302
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.4
Reporter: Matthew Beermann
Fix For: 2.5
When running eclipse:make-artifacts with -DresolveVersionRanges=true, it dies
with the following error:
[INFO] Unable to resolve version range for dependency Dependency
{groupId=system.bundle, artifactId=system.bundle, version=[0,), type=jar} in
project org.apache.xml.org.apache.xml.resolver
It turns out that "system.bundle" is a keyword in OSGi that (broadly speaking)
refers to the JRE itself, and thus need not/should not be included in the POM
as a dependency. I've got a patch for this coming up in a moment.
--
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-302) resolveVersionRanges crashes on system.bundle
[
http://jira.codehaus.org/browse/MECLIPSE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Beermann updated MECLIPSE-302:
--
Attachment: MECLIPSE-302-maven-eclipse-plugin.patch
This did the trick for me.
> resolveVersionRanges crashes on system.bundle
> -
>
> Key: MECLIPSE-302
> URL: http://jira.codehaus.org/browse/MECLIPSE-302
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Matthew Beermann
> Fix For: 2.5
>
> Attachments: MECLIPSE-302-maven-eclipse-plugin.patch
>
>
> When running eclipse:make-artifacts with -DresolveVersionRanges=true, it dies
> with the following error:
> [INFO] Unable to resolve version range for dependency Dependency
> {groupId=system.bundle, artifactId=system.bundle, version=[0,), type=jar} in
> project org.apache.xml.org.apache.xml.resolver
> It turns out that "system.bundle" is a keyword in OSGi that (broadly
> speaking) refers to the JRE itself, and thus need not/should not be included
> in the POM as a dependency. I've got a patch for this coming up in a moment.
--
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] Work started: (MEAR-72) Support For Jboss Configuration to include module-order attribute
[ http://jira.codehaus.org/browse/MEAR-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MEAR-72 started by Stephane Nicoll. > Support For Jboss Configuration to include module-order attribute > - > > Key: MEAR-72 > URL: http://jira.codehaus.org/browse/MEAR-72 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Sairam Rekapalli >Assignee: Stephane Nicoll > Attachments: maven-ear-plugin.patch > > > Currently module-order attribute for Jboss is not recognized by the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSANDBOX-28) Added an scm alter and a general "alter" goal
Added an scm alter and a general "alter" goal - Key: MSANDBOX-28 URL: http://jira.codehaus.org/browse/MSANDBOX-28 Project: Maven 2.x Sandbox Issue Type: New Feature Reporter: Eric Redmond Priority: Minor Attachments: mavenpomplugin-alterscm.diff added a pom:scm-alter goal also added pom:alter - so you can change multiple items in a single configuration (parent, dependencies, properties currently) would like to make those actions components so as not to need to call mojos directly -- 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: (MINSTALL-21) The pom given to pomFile parameter should provide the groupId, artifactId, version and packaging values just like in deploy:deploy-file goal
[ http://jira.codehaus.org/browse/MINSTALL-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102109 ] Tom Nichols commented on MINSTALL-21: - Was this not fixed in 2.2? I don't see it in the change Log. > The pom given to pomFile parameter should provide the groupId, artifactId, > version and packaging values just like in deploy:deploy-file goal > > > Key: MINSTALL-21 > URL: http://jira.codehaus.org/browse/MINSTALL-21 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Allan Ramirez >Assignee: Allan Ramirez > > For the install:install-file goal > groupId, artifactId, version and packaging should not be required if pomFile > is given. It should retrieve the values in the pom. -- 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-266) plugin applies java facet to ear project
[ http://jira.codehaus.org/browse/MECLIPSE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102110 ] Srepfler Srgjan commented on MECLIPSE-266: -- You are right when you say that it's the concern of the eclipse plugin to generate eclipse project files. The eclipse always was able to generate a project configuration, what I'm reporting is a bug, when generating a project for a EAR artifact it's applying also a Java project facet which is incompatible with WTP. In WTP a EAR project must not have a Java facet. That said I think it's not a good choice to apply dependencies to a EAR because it's not a Java project. Again why is the plugin using these strange dependency analysis on the project if it's enough to either look at the ear configuration of the ear module or eventually the schema version for the application.xml file. > plugin applies java facet to ear project > > > Key: MECLIPSE-266 > URL: http://jira.codehaus.org/browse/MECLIPSE-266 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.3 > Environment: Windows XP >Reporter: Srepfler Srgjan > > In .settings/org.eclipse.wst.common.project.facet.core.xml of the EAR module > I'm getting this: > > > > > > > This is a wrong facet on a EAR module and I can't compile if I don't edit > this file manually (I can't do it from the project properties - facets dialog) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEAR-72) Support For Jboss Configuration to include module-order attribute
[ http://jira.codehaus.org/browse/MEAR-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-72. --- Resolution: Fixed Fix Version/s: 2.3.1 Applied, thaks Please note that this is available as from JBoss 4.2. I have added the 4.2 dtd to the EAR plugin to make sure the jboss-app is valid. I have updated the code and the test as well. > Support For Jboss Configuration to include module-order attribute > - > > Key: MEAR-72 > URL: http://jira.codehaus.org/browse/MEAR-72 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Sairam Rekapalli >Assignee: Stephane Nicoll > Fix For: 2.3.1 > > Attachments: maven-ear-plugin.patch > > > Currently module-order attribute for Jboss is not recognized by the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-70) loader-repository node for jboss configuration
[
http://jira.codehaus.org/browse/MEAR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102112
]
Stephane Nicoll commented on MEAR-70:
-
I told it ten thousands times. The current implementation supports a simple,
naive loader-repository config. See my comments in the related issue. Playing
with CDATA is not convenient, no plugin is designed that way.
> loader-repository node for jboss configuration
> --
>
> Key: MEAR-70
> URL: http://jira.codehaus.org/browse/MEAR-70
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
>Reporter: Mark Kettner
>
> I added the patch MEAR-50.patch to the 2.3 version of the maven-ear-plugin.
> However, after the patch I still couldn't generate a correct jboss-app.xml
> file when the pom.xml contained the following definition:
>
>
>
> org.apache.maven.plugins
> maven-ear-plugin
> 2.3.1
>
>
> 4
>
>nl.ictu.spg.bsn:loader=afslagbsn
>
> java2ParentDelegation=false
>
>
>
>
>
>
> This is because in the file AbstractEarMojo the
> final String loaderRepository = jboss.getChild(
> JbossConfiguration.LOADER_REPOSITORY ).getValue();
> is null when a subtag is added to the loaderRepository tag.
> This can be solved by changing the definition in the pom.xml file to the
> following:
>
>
>
> org.apache.maven.plugins
> maven-ear-plugin
> 2.3.1
>
>
> 4
>
>
>
>
>
>
>
> and change the "write" method in the JbossAppXmlWriter class to the following:
> // classloader repository
> if ( jbossConfiguration.getLoaderRepository() != null )
> {
> writer.startElement( JbossConfiguration.LOADER_REPOSITORY );
> writer.writeMarkup( jbossConfiguration.getLoaderRepository() );
> writer.endElement();
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSANDBOX-28) Added an scm alter and a general "alter" goal
[ http://jira.codehaus.org/browse/MSANDBOX-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell closed MSANDBOX-28. --- Resolution: Fixed applied, thanks! > Added an scm alter and a general "alter" goal > - > > Key: MSANDBOX-28 > URL: http://jira.codehaus.org/browse/MSANDBOX-28 > Project: Maven 2.x Sandbox > Issue Type: New Feature >Reporter: Eric Redmond >Assignee: Jesse McConnell >Priority: Minor > Attachments: mavenpomplugin-alterscm.diff > > > added a pom:scm-alter goal > also added pom:alter - so you can change multiple items in a single > configuration (parent, dependencies, properties currently) > would like to make those actions components so as not to need to call mojos > directly -- 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: (MANTTASKS-78) unable to download parent pom when it is a SNAPSHOT and multiple remoteRepositories are used
[
http://jira.codehaus.org/browse/MANTTASKS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102114
]
Herve Boutemy commented on MANTTASKS-78:
I made more tests: the problem is not related to the fact that it is a pom.
I have the exact same issue with dependencies task:
{code:xml}
{code}
> unable to download parent pom when it is a SNAPSHOT and multiple
> remoteRepositories are used
>
>
> Key: MANTTASKS-78
> URL: http://jira.codehaus.org/browse/MANTTASKS-78
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: POM Integration
>Affects Versions: 2.0.7
>Reporter: Herve Boutemy
> Attachments: MANTTASKS-78.diff
>
>
> the conditions for this problem are very precise:
> id="my.maven.project.SNAPSHOT">
>
>
>
>
> but if the second remoteRepository is removed, or even the 2 repositories
> switched, there is no 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: (MANTTASKS-78) unable to download a dependency when it is a SNAPSHOT and multiple remoteRepositories are used
[
http://jira.codehaus.org/browse/MANTTASKS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-78:
---
Description:
the conditions for this problem are very precise:
{code:xml}
{code}
but if the second remoteRepository is removed, or even the 2 repositories
switched, there is no problem...
was:
the conditions for this problem are very precise:
but if the second remoteRepository is removed, or even the 2 repositories
switched, there is no problem...
Component/s: dependencies task
Summary: unable to download a dependency when it is a SNAPSHOT and
multiple remoteRepositories are used (was: unable to download parent pom when
it is a SNAPSHOT and multiple remoteRepositories are used)
> unable to download a dependency when it is a SNAPSHOT and multiple
> remoteRepositories are used
> --
>
> Key: MANTTASKS-78
> URL: http://jira.codehaus.org/browse/MANTTASKS-78
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task, POM Integration
>Affects Versions: 2.0.7
>Reporter: Herve Boutemy
> Attachments: MANTTASKS-78.diff
>
>
> the conditions for this problem are very precise:
> {code:xml}
> id="my.maven.project.SNAPSHOT">
>
>
>
>
> {code}
> but if the second remoteRepository is removed, or even the 2 repositories
> switched, there is no 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: (MSANDBOX-28) Added an scm alter and a general "alter" goal
[ http://jira.codehaus.org/browse/MSANDBOX-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell updated MSANDBOX-28: Component/s: maven-pom-plugin > Added an scm alter and a general "alter" goal > - > > Key: MSANDBOX-28 > URL: http://jira.codehaus.org/browse/MSANDBOX-28 > Project: Maven 2.x Sandbox > Issue Type: New Feature > Components: maven-pom-plugin >Reporter: Eric Redmond >Assignee: Jesse McConnell >Priority: Minor > Attachments: mavenpomplugin-alterscm.diff > > > added a pom:scm-alter goal > also added pom:alter - so you can change multiple items in a single > configuration (parent, dependencies, properties currently) > would like to make those actions components so as not to need to call mojos > directly -- 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: (MANTLR-21) [antlr3] documentation update
[antlr3] documentation update - Key: MANTLR-21 URL: http://jira.codehaus.org/browse/MANTLR-21 Project: Maven 2.x Antlr Plugin Issue Type: Improvement Reporter: David Holroyd Attachments: doc-update-patch.diff Fixes example dependency information, and documents how to get generated Java files to appear in the correct folder. NB this is a patch for the maven-antlr3-plugin in the Maven sandbox. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSANDBOX-29) [antlr3] documentation update
[ http://jira.codehaus.org/browse/MSANDBOX-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MSANDBOX-29. --- Assignee: Vincent Siveton Resolution: Fixed Patch applied. Thanks! > [antlr3] documentation update > - > > Key: MSANDBOX-29 > URL: http://jira.codehaus.org/browse/MSANDBOX-29 > Project: Maven 2.x Sandbox > Issue Type: Improvement > Components: maven-antlr3-plugin >Reporter: David Holroyd >Assignee: Vincent Siveton > Attachments: doc-update-patch.diff > > > Fixes example dependency information, and documents how to get generated Java > files to appear in the correct folder. > NB this is a patch for the maven-antlr3-plugin in the Maven sandbox. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MSANDBOX-29) [antlr3] documentation update
[ http://jira.codehaus.org/browse/MSANDBOX-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton moved MANTLR-21 to MSANDBOX-29: --- Key: MSANDBOX-29 (was: MANTLR-21) Project: Maven 2.x Sandbox (was: Maven 2.x Antlr Plugin) > [antlr3] documentation update > - > > Key: MSANDBOX-29 > URL: http://jira.codehaus.org/browse/MSANDBOX-29 > Project: Maven 2.x Sandbox > Issue Type: Improvement > Components: maven-antlr3-plugin >Reporter: David Holroyd > Attachments: doc-update-patch.diff > > > Fixes example dependency information, and documents how to get generated Java > files to appear in the correct folder. > NB this is a patch for the maven-antlr3-plugin in the Maven sandbox. -- 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: (MSANDBOX-29) [antlr3] documentation update
[ http://jira.codehaus.org/browse/MSANDBOX-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MSANDBOX-29: Component/s: maven-antlr3-plugin > [antlr3] documentation update > - > > Key: MSANDBOX-29 > URL: http://jira.codehaus.org/browse/MSANDBOX-29 > Project: Maven 2.x Sandbox > Issue Type: Improvement > Components: maven-antlr3-plugin >Reporter: David Holroyd > Attachments: doc-update-patch.diff > > > Fixes example dependency information, and documents how to get generated Java > files to appear in the correct folder. > NB this is a patch for the maven-antlr3-plugin in the Maven sandbox. -- 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: (WAGONSSH-42) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGONSSH-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102123 ] Trustin Lee commented on WAGONSSH-42: - ScpWagon correctly specified the file permission but most OpenSSH servers doesn't seem to respect it. I'm not sure if it's an OpenSSH bug or ScpWagon is using some non-standard way to set permissions. This issue can be fixed by modifying ScpWagon to run chmod command explicitly, but it will make the deployment time much longer. Instead, this issue can be worked around by changing the default umask of the user. Please try to add 'umask 002' to your .shrc or .bashrc file. > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGONSSH-42 > URL: http://jira.codehaus.org/browse/WAGONSSH-42 > Project: wagon-ssh > Issue Type: Bug >Affects Versions: 1.0-alpha-6 > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Priority: Critical > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1639) Upload ZK 2.4.1 to the central repository
Upload ZK 2.4.1 to the central repository - Key: MAVENUPLOAD-1639 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1639 Project: maven-upload-requests Issue Type: Task Reporter: Tom M. Yeh http://www.zkoss.org/maven/bundles/2.4.1/zcommon-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zweb-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zk-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zul-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zhtml-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zkplus-2.4.1-bundle.jar http://www.zkoss.org http://sourceforge.net/users/tomyeh/ ZK is an open-source Ajax Web framework that enables rich user interface for Web applications with no JavaScript and little programming. -- 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-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue
[ http://jira.codehaus.org/browse/MNG-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102125 ] Brian Fox commented on MNG-2277: I debugged another problem caused by enforcer:enforce-once (aggregator and requiresDependencyResolution) and confirm this. The resolveTransitively doesn't consider artifacts in the reactor. > aggregating plugins in submodules of the reactor return all projects causing > a chicken/egg issue > > > Key: MNG-2277 > URL: http://jira.codehaus.org/browse/MNG-2277 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle, Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Brett Porter > Fix For: 2.1.x > > > eg, assembly:attached > when this is put in maven-core, and a build is run from the root project with > a clean repo, it fails, as the original project sorter doesn't consider the > dependencies, building plugin-tools after maven-core. > However, hitting the aggregator when building maven-core then tries to > resolve all of the projects as dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1640) Jackcess 1.1.9 release
Jackcess 1.1.9 release -- Key: MAVENUPLOAD-1640 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1640 Project: maven-upload-requests Issue Type: Task Reporter: james ahlborn Latest jar of the jackcess package. Jackcess ia a pure Java library for reading from and writing to MS Access databases. -- 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: (MENFORCER-11) enforce-once causes MNG-2277 to be expressed in reactor builds. Find a way to work around it.
enforce-once causes MNG-2277 to be expressed in reactor builds. Find a way to work around it. - Key: MENFORCER-11 URL: http://jira.codehaus.org/browse/MENFORCER-11 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Plugin Affects Versions: 1.0-alpha-3 Reporter: Brian Fox Assignee: Brian Fox In 1.0-alpha-3, the enforce goal now requires dependency resolution to support the new dependency rules (noSnapshots, noBannedDependencies). Because enforce-once extends and adds as an aggregator, this causes the maven bug to appear. The work around for now is to use enforce not the enforce-once goal (the aggregator part of enforce-once doesn't work anyway). The fix would be to resolve the dependencies manually in the plugin or to make a new mojo that requires dependency resolution and put enforce and enforce-once back the way they where. -- 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: (MENFORCER-11) enforce-once causes MNG-2277 to be expressed in reactor builds. Find a way to work around it.
[ http://jira.codehaus.org/browse/MENFORCER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MENFORCER-11: --- Description: In 1.0-alpha-3, the enforce goal now requires dependency resolution to support the new dependency rules (noSnapshots, noBannedDependencies). Because enforce-once extends and adds as an aggregator, this causes the maven bug MNG-2277 to appear. The work around for now is to use enforce not the enforce-once goal (the aggregator part of enforce-once doesn't work anyway). The fix would be to resolve the dependencies manually in the plugin or to make a new mojo that requires dependency resolution and put enforce and enforce-once back the way they where. was: In 1.0-alpha-3, the enforce goal now requires dependency resolution to support the new dependency rules (noSnapshots, noBannedDependencies). Because enforce-once extends and adds as an aggregator, this causes the maven bug to appear. The work around for now is to use enforce not the enforce-once goal (the aggregator part of enforce-once doesn't work anyway). The fix would be to resolve the dependencies manually in the plugin or to make a new mojo that requires dependency resolution and put enforce and enforce-once back the way they where. > enforce-once causes MNG-2277 to be expressed in reactor builds. Find a way to > work around it. > - > > Key: MENFORCER-11 > URL: http://jira.codehaus.org/browse/MENFORCER-11 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Plugin >Affects Versions: 1.0-alpha-3 >Reporter: Brian Fox >Assignee: Brian Fox > > In 1.0-alpha-3, the enforce goal now requires dependency resolution to > support the new dependency rules (noSnapshots, noBannedDependencies). Because > enforce-once extends and adds as an aggregator, this causes the maven bug > MNG-2277 to appear. The work around for now is to use enforce not the > enforce-once goal (the aggregator part of enforce-once doesn't work anyway). > The fix would be to resolve the dependencies manually in the plugin or to > make a new mojo that requires dependency resolution and put enforce and > enforce-once back the way they where. -- 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-1345) Create projects from metadata fails with Malformed URL if port is present (http://[EMAIL PROTECTED]/svn/...)
Create projects from metadata fails with Malformed URL if port is present (http://[EMAIL PROTECTED]/svn/...) Key: CONTINUUM-1345 URL: http://jira.codehaus.org/browse/CONTINUUM-1345 Project: Continuum Issue Type: Bug Affects Versions: 1.1-alpha-2 Environment: kubuntu feisty Reporter: Greg Johnson Failure when adding project via Url - MungedHttpsURL is missing ":" if svn url includes a port number. Add project POM Url of "http://www.xxx.com:44302/svn/***/trunk/***/pom.xml"; results in: INFO Action:create-projects-from-metadata - Malformed URL (MungedHttpsURL is not valid): http://user:[EMAIL PROTECTED]/svn/***/trunk/***/pom.xml Impact: Product cannot be used if repository URL contains a port number. -- 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: (MENFORCER-12) enforce-once still runs in each child pom
enforce-once still runs in each child pom - Key: MENFORCER-12 URL: http://jira.codehaus.org/browse/MENFORCER-12 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Plugin Affects Versions: 1.0-alpha-3 Reporter: Brian Fox Assignee: Brian Fox -- 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: (WAGONSSH-42) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGONSSH-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102132 ] Benjamin Bentmann commented on WAGONSSH-42: --- Thanks for your advice about using "umask", I will try this at the next occasion. As for the ScpWagon, I recently discovered the related discussion at http://jira.codehaus.org/browse/WAGONSSH-44. If the world of SSH server implementations is indeed so evil that there is no standard/reliable way of setting the file permissions, I would appreciate a configuration setting for the ScpWagon to enforce the (otherwise costly) usage of chmod. After all, a long but successful deploy is still better than a quick but improper deploy. > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGONSSH-42 > URL: http://jira.codehaus.org/browse/WAGONSSH-42 > Project: wagon-ssh > Issue Type: Bug >Affects Versions: 1.0-alpha-6 > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Priority: Critical > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1345) Create projects from metadata fails with Malformed URL if port is present (http://[EMAIL PROTECTED]/svn/...)
[ http://jira.codehaus.org/browse/CONTINUUM-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1345. --- Assignee: Emmanuel Venisse Resolution: Duplicate > Create projects from metadata fails with Malformed URL if port is present > (http://[EMAIL PROTECTED]/svn/...) > > > Key: CONTINUUM-1345 > URL: http://jira.codehaus.org/browse/CONTINUUM-1345 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-2 > Environment: kubuntu feisty >Reporter: Greg Johnson >Assignee: Emmanuel Venisse > > Failure when adding project via Url - MungedHttpsURL is missing ":" if svn > url includes a port number. > Add project POM Url of "http://www.xxx.com:44302/svn/***/trunk/***/pom.xml"; > results in: > INFO Action:create-projects-from-metadata - Malformed URL (MungedHttpsURL is > not valid): http://user:[EMAIL PROTECTED]/svn/***/trunk/***/pom.xml > Impact: Product cannot be used if repository URL contains a port number. -- 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
