[jira] Created: (MAVENUPLOAD-1491) Upload SNMP4J 1.1.1
Upload SNMP4J 1.1.1 --- Key: MAVENUPLOAD-1491 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1491 Project: maven-upload-requests Issue Type: Task Reporter: Felipe Leme I based the pom on snmp4j that is on Ibiblio http://mirrors.ibiblio.org/pub/mirrors/maven2/org/snmp4j/snmp4j/1.7.1/ Also, I got the jars from: http://www.snmp4j.org/html/download.html Finally, it depends on snmp4j-1.8.1, which was requested at MAVENUPLOAD-1490 -- Felipe -- 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: (MAVENUPLOAD-1491) Upload SNMP4J Agent 1.1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felipe Leme updated MAVENUPLOAD-1491: - Summary: Upload SNMP4J Agent 1.1.1 (was: Upload SNMP4J 1.1.1) > Upload SNMP4J Agent 1.1.1 > - > > Key: MAVENUPLOAD-1491 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1491 > Project: maven-upload-requests > Issue Type: Task >Reporter: Felipe Leme > > I based the pom on snmp4j that is on Ibiblio > http://mirrors.ibiblio.org/pub/mirrors/maven2/org/snmp4j/snmp4j/1.7.1/ > Also, I got the jars from: > http://www.snmp4j.org/html/download.html > Finally, it depends on snmp4j-1.8.1, which was requested at MAVENUPLOAD-1490 > -- Felipe -- 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-1490) Upload SNMP4J 1.8.1
Upload SNMP4J 1.8.1 --- Key: MAVENUPLOAD-1490 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1490 Project: maven-upload-requests Issue Type: Task Reporter: Felipe Leme I based the pom on the current version uploaded at ibiblio (1.7.1): http://mirrors.ibiblio.org/pub/mirrors/maven2/org/snmp4j/snmp4j/1.7.1/ Also, I got the jars from: http://www.snmp4j.org/html/download.html -- Felipe -- 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-1290) Upload DbUnit 2.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1290?page=comments#action_83500 ] Felipe Leme commented on MAVENUPLOAD-1290: -- Oops, forgot to add a description: This is a long-awaited new DbUnit official release, generated more than 2 years after DbUnit 2.1! Hope everything is fine in the bundle - it should be, as it was generated with the Maven 2 plugin. Anyway, Happy New Year everybody > Upload DbUnit 2.2 > - > > Key: MAVENUPLOAD-1290 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1290 > Project: maven-upload-requests > Issue Type: Task >Reporter: Felipe Leme > -- 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-1290) Upload DbUnit 2.2
Upload DbUnit 2.2 - Key: MAVENUPLOAD-1290 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1290 Project: maven-upload-requests Issue Type: Task Reporter: Felipe Leme -- 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-1250) Upload org.hibernate:hibernate:jar:3.2.1.ga to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1250?page=comments#action_81393 ] Felipe Leme commented on MAVENUPLOAD-1250: -- If you don't fix the POM, they won't upload it. > Upload org.hibernate:hibernate:jar:3.2.1.ga to ibiblio > -- > > Key: MAVENUPLOAD-1250 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1250 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/hibernate-3.2.1.ga-bundle.jar > http://www.hibernate.org/ > Hibernate is a powerful, high performance object/relational persistence and > query service. -- 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-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=comments#action_69130 ] Felipe Leme commented on MECLIPSE-94: - Hi Stephen, Yes, you're right, the original request was based on how the M2Book defined an integration-test scenario. And to be honest, I don't remember how exactly the use case was, as we had gave up that integration-test project (for lack of time). Anyway, by the time the issue was created, there wasn't yet a well-defined scenario for M2 integration tests; once such scenario is defined, this issue might be marked as won't fix (or not :-). -- Felipe > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Type: Improvement > Versions: 2.1 > Reporter: Felipe Leme > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-75) Document how to deploy javadoc jars
Document how to deploy javadoc jars --- Key: MJAVADOC-75 URL: http://jira.codehaus.org/browse/MJAVADOC-75 Project: Maven 2.x Javadoc Plugin Type: Improvement Reporter: Felipe Leme Priority: Trivial The plugin documenation should explaing how to deploy the javadoc jar using command line (i.e., mvn javadoc:jar deploy) or by setting the POM (lifecycles). -- 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-73) provide javadoc warnings
[ http://jira.codehaus.org/browse/MJAVADOC-73?page=comments#action_65731 ] Felipe Leme commented on MJAVADOC-73: - Maven 1 had a plugin that generate a report with such warnings - it would be nice to have that feature on M2 as well (more than that, the plugin could even fail the build according to the warnings threshold). > provide javadoc warnings > > > Key: MJAVADOC-73 > URL: http://jira.codehaus.org/browse/MJAVADOC-73 > Project: Maven 2.x Javadoc Plugin > Type: Improvement > Versions: 2.0 > Reporter: Jörg Prante > Priority: Minor > Attachments: javadoc-warnings.diff > > > The Maven javadoc plugin does not provide the warnings given by the javadoc > command. For convenience, it would be nice to save the output of the javadoc > command execution to a file for later examination. A patch for writing a file > "warnings.txt" is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSOURCES-5) Create documentation for the plugin
[ http://jira.codehaus.org/browse/MSOURCES-5?page=comments#action_65730 ] Felipe Leme commented on MSOURCES-5: Also, it would be nice to explain how to configure the POM to deploy the source jars. > Create documentation for the plugin > --- > > Key: MSOURCES-5 > URL: http://jira.codehaus.org/browse/MSOURCES-5 > Project: Maven 2.x Sources Plugin > Type: Task > Reporter: Maria Odea Ching > Assignee: Maria Odea Ching > > Original Estimate: 12 hours > Remaining: 12 hours > > Javadocs, introduction and how to/configuration -- 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-689) User settings permission
User settings permission Key: CONTINUUM-689 URL: http://jira.codehaus.org/browse/CONTINUUM-689 Project: Continuum Type: Improvement Components: Core system Versions: 1.0.3 Reporter: Felipe Leme There should be a permission that allows the user to change his information (like email and password) - right now either the user has no permission to do it or it has full access to user/group management. -- 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-2270) Support non-required dependencies
[ http://jira.codehaus.org/browse/MNG-2270?page=comments#action_64711 ]
Felipe Leme commented on MNG-2270:
--
Damn, I knew there should be already a way to achieve that - sorry for
polluting Jira with such a dumb question (next time I will ask on IRC first
:-).
Anyway, maybe that's an interesting tip to include in the FAQ...
> Support non-required dependencies
> -
>
> Key: MNG-2270
> URL: http://jira.codehaus.org/browse/MNG-2270
> Project: Maven 2
> Type: New Feature
> Components: Dependencies
> Versions: 2.0.4
> Reporter: Felipe Leme
> Assignee: Brett Porter
>
>
> One feature I miss on Maven is the possibility of setting a dependency as
> non-required. Let me explain an use case that would make it clearer: I'm
> migrating dbunit to use Maven 2 (it uses Maven 1 currently) and in order to
> compile it, either you use JDK 1.4+ or you add the javax.sql-jdbc-std-2.0
> dependency (dbunit requires JDK 1.3).
> In other words, there is currently no way to build dbunit out-of-the box -
> you have to either install the dependency manually (which is fine when
> cutting a release or on CI builds) or comment the dependency in the POM
> (which is not cool for occasional users of the framework - it goes against
> the 'just type mvn and wait' philosophy).
> So, what I think it would be nice is if I could declare that dependency as
> non-required (I would say 'optional', but that already has another meaning):
> if Maven cannot download that dependency, it would continue the build (of
> course, if Maven is ran using JDK 1.3, it would fail; but in most cases, it
> would suceed). It should be something like this:
>
> javax.sql
> jdbc-stdext
> 2.0
> false
>
> Or, even better, I could use a logic expression:
>
> javax.sql
> jdbc-stdext
> 2.0
> ${java.version == 1.3}
>
> Or in a more powerful way:
>
> javax.sql
> jdbc-stdext
> 2.0
> ${versionLessThan( java.version, '1.3' }
>
> Is that any plan to provide such a feature on Maven 2.1? I think the scenario
> makes sense and it appers to be easy to implement (at least the initial
> alternative that only accepts literals).
> -- Felipe
--
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-2270) Support non-required dependencies
Support non-required dependencies
-
Key: MNG-2270
URL: http://jira.codehaus.org/browse/MNG-2270
Project: Maven 2
Type: New Feature
Components: Dependencies
Versions: 2.0.4
Reporter: Felipe Leme
One feature I miss on Maven is the possibility of setting a dependency as
non-required. Let me explain an use case that would make it clearer: I'm
migrating dbunit to use Maven 2 (it uses Maven 1 currently) and in order to
compile it, either you use JDK 1.4+ or you add the javax.sql-jdbc-std-2.0
dependency (dbunit requires JDK 1.3).
In other words, there is currently no way to build dbunit out-of-the box - you
have to either install the dependency manually (which is fine when cutting a
release or on CI builds) or comment the dependency in the POM (which is not
cool for occasional users of the framework - it goes against the 'just type mvn
and wait' philosophy).
So, what I think it would be nice is if I could declare that dependency as
non-required (I would say 'optional', but that already has another meaning): if
Maven cannot download that dependency, it would continue the build (of course,
if Maven is ran using JDK 1.3, it would fail; but in most cases, it would
suceed). It should be something like this:
javax.sql
jdbc-stdext
2.0
false
Or, even better, I could use a logic expression:
javax.sql
jdbc-stdext
2.0
${java.version == 1.3}
Or in a more powerful way:
javax.sql
jdbc-stdext
2.0
${versionLessThan( java.version, '1.3' }
Is that any plan to provide such a feature on Maven 2.1? I think the scenario
makes sense and it appers to be easy to implement (at least the initial
alternative that only accepts literals).
-- Felipe
--
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-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=all ] Felipe Leme updated CONTINUUM-655: -- Attachment: chkconfig_install.sh > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > Attachments: CONTINUUM-655.patch, chkconfig_install.sh > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- 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-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=all ] Felipe Leme updated CONTINUUM-655: -- Attachment: (was: chkconfig_install.sh) > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > Attachments: CONTINUUM-655.patch > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- 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-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=all ] Felipe Leme updated CONTINUUM-655: -- Attachment: CONTINUUM-655.patch > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > Attachments: CONTINUUM-655.patch, chkconfig_install.sh > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- 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-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=all ] Felipe Leme updated CONTINUUM-655: -- Attachment: chkconfig_install.sh > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > Attachments: chkconfig_install.sh > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- 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-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=all ] Felipe Leme updated CONTINUUM-655: -- Attachment: (was: chkconfig_install.sh) > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- 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-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=all ] Felipe Leme updated CONTINUUM-655: -- Attachment: chkconfig_install.sh > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > Attachments: chkconfig_install.sh > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=comments#action_63402 ] Felipe Leme commented on CONTINUUM-655: --- Got the problem: my system didn't have JAVA_HOME properly set for the service scripts. So, the proposed change should be enough (I will try to fix my system to confirm though...) > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=comments#action_63397 ] Felipe Leme commented on CONTINUUM-655: --- Actually, it's not so simple; just now I realized it doesn't work :-( It does call the script, but the wrapper fails: STATUS | wrapper | 2006/04/12 12:36:25 | --> Wrapper Started as Daemon STATUS | wrapper | 2006/04/12 12:36:25 | Launching a JVM... ERROR | wrapper | 2006/04/12 12:36:25 | Unable to start JVM: No such file or directory (2)ERROR | wrapper | 2006/04/12 12:36:25 | Critical error: wait for JVM process failed (No child processes) ERROR | wrapper | 2006/04/12 12:36:25 | Unable to start a JVM STATUS | wrapper | 2006/04/12 12:36:25 | <-- Wrapper Stopped I will investigate why... > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=comments#action_63388 ] Felipe Leme commented on CONTINUUM-655: --- How "nice": Jira thinks # is a numbering system! Let me try again... Line 1: # chkconfig: 345 20 80 Line 2: # description: Maven Continuum server > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-655) Add chkconfig support to the starting script
[ http://jira.codehaus.org/browse/CONTINUUM-655?page=comments#action_63387 ] Felipe Leme commented on CONTINUUM-655: --- OBS: the 1. an 2. above are actually comments (#); I don't know why they were converted while generating this Jira. Anyway, let me try again: # chkconfig: 345 20 80 # description: Maven Continuum server > Add chkconfig support to the starting script > > > Key: CONTINUUM-655 > URL: http://jira.codehaus.org/browse/CONTINUUM-655 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Environment: Fedora Core & any RedHat-based system > Reporter: Felipe Leme > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'm using Fedora Core 4 and wanted to start Continuum on startup, so I > followed the instructions below: > http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html > FC (and any RH-based distro) doesn't have the update-rc.d script; instead, > they have chkconfig. So, I created the link on /etc/rc.d and tried to enable > continuum on chkconfig, but it failed: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > service continuum does not support chkconfig > Looking at the shell script, it's missing the chkconfig commentaries, so I > added them: > #! /bin/sh > # chkconfig: 345 20 80 > # description: Maven Continuum server > Now everything is fine: > [EMAIL PROTECTED] init.d]# chkconfig --add continuum > [EMAIL PROTECTED] init.d]# chkconfig continuum on > [EMAIL PROTECTED] init.d]# service continuum start > Starting continuum... > I could provide a patch, but I don't know how the script is generated. So, > long story short, this issue requires 2 changes: > - add the comment above in the run.sh script (or whatever generates it) > - update the documentation (URL above) -- 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-655) Add chkconfig support to the starting script
Add chkconfig support to the starting script Key: CONTINUUM-655 URL: http://jira.codehaus.org/browse/CONTINUUM-655 Project: Continuum Type: Improvement Components: Core system Versions: 1.0.2 Environment: Fedora Core & any RedHat-based system Reporter: Felipe Leme I'm using Fedora Core 4 and wanted to start Continuum on startup, so I followed the instructions below: http://maven.apache.org/continuum/guides/mini/guide-linux-boot.html FC (and any RH-based distro) doesn't have the update-rc.d script; instead, they have chkconfig. So, I created the link on /etc/rc.d and tried to enable continuum on chkconfig, but it failed: [EMAIL PROTECTED] init.d]# chkconfig --add continuum service continuum does not support chkconfig Looking at the shell script, it's missing the chkconfig commentaries, so I added them: #! /bin/sh # chkconfig: 345 20 80 # description: Maven Continuum server Now everything is fine: [EMAIL PROTECTED] init.d]# chkconfig --add continuum [EMAIL PROTECTED] init.d]# chkconfig continuum on [EMAIL PROTECTED] init.d]# service continuum start Starting continuum... I could provide a patch, but I don't know how the script is generated. So, long story short, this issue requires 2 changes: - add the comment above in the run.sh script (or whatever generates it) - update the documentation (URL above) -- 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-2097) adding a phase called prepare-package
[ http://jira.codehaus.org/browse/MNG-2097?page=comments#action_63375 ] Felipe Leme commented on MNG-2097: -- Olivier, I agree with you that such phase is necessary, but that might be situations where you need to use the same package on the integration-test phase and only change it right before install. So, it might be better to add 2 new phases, 'prepare-package' (or 'pre-package') as proposed and 'pre-install'. Also, it's necessary a tool (probably a plugin) to facilitate this preparation; something like a maven-package-tuner-plugin which takes as configuration the files to be included/excluded from the package. Something like: org.apache.maven.plugins maven-package-tuner-plugin /classes/**Mock*.class /test.jsp src/it/resources *.xml Of course, this is just an example - the real plugin should use a familiar includes/excludes syntax (like the Ant way). -- Felipe > adding a phase called prepare-package > - > > Key: MNG-2097 > URL: http://jira.codehaus.org/browse/MNG-2097 > Project: Maven 2 > Type: New Feature > Components: Plugins and Lifecycle > Versions: 2.0.2 > Environment: all > Reporter: Olivier Lamy > Attachments: MNG-2097.diff > > > Hi, > I have an artifact (packaging war). > I have some jobs to do (xdoclet-maven-plugin others internal plugin) which > are only needed for included materials in the war : > - web.xml > - automatic generated pages (about page etc..) > Actually I attached it tho the phase process-classes or test. > But when I just want to try a simple the simple : mvn -Dtest=something clean > test. > All of my .java are parsed by the plugin and all other jobs made whereas this > should be done in a phase just before packaging. > I really need a phase just before package to place all this jobs. > Probably this can be extends to phase deploy. > 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: (MWAR-29) includes/excludes should extend to generated stuff
[ http://jira.codehaus.org/browse/MWAR-29?page=comments#action_63376 ] Felipe Leme commented on MWAR-29: - Yes, it would, thanks... > includes/excludes should extend to generated stuff > -- > > Key: MWAR-29 > URL: http://jira.codehaus.org/browse/MWAR-29 > Project: Maven 2.x War Plugin > Type: Improvement > Reporter: Felipe Leme > > > I'm working on a war project where we decided to include some mock classes on > the source directory, so the developers can work on the Structs actions > without worrying with the backend. As such, these classes should not be > included in the 'official' war file (they are only used by the jetty6 plugin). > So, I tried to use the configuration to exclude then but failed to > do so. After struggling for a while with the -X option, google and jira, I > realized such configuration only excludes files from the warSource directory > (i.e, the stuff that goes in the web application root, like JSP pages). I've > seen some bug entries regarding filtering resources and the includes/excludes > not working a while ago, but I believe those are other issues... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-759) Glassfish persistence and transaction apis
[ http://jira.codehaus.org/browse/MAVENUPLOAD-759?page=all ] Felipe Leme reopened MAVENUPLOAD-759: - John/Wayne, The content of the transaction jar is wrong, it has the POM and not the .class files: [EMAIL PROTECTED] tmp]$ wget http://www.ibiblio.org/maven2/net/java/dev/glassfish/glassfish-transaction-api/b32g/glassfish-transaction-api-b32g.jar --11:47:49-- http://www.ibiblio.org/maven2/net/java/dev/glassfish/glassfish-transaction-api/b32g/glassfish-transaction-api-b32g.jar => `glassfish-transaction-api-b32g.jar' Resolving www.ibiblio.org... 152.2.210.80 Connecting to www.ibiblio.org[152.2.210.80]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2,231 [text/plain] 100%[>] 2,231 --.--K/s 11:47:50 (3.85 MB/s) - `glassfish-transaction-api-b32g.jar' saved [2,231/2,231] [EMAIL PROTECTED] tmp]$ unzip -t glassfish-transaction-api-b32g.jar Archive: glassfish-transaction-api-b32g.jar testing: META-INF/OK testing: META-INF/MANIFEST.MF OK testing: META-INF/maven/ OK testing: META-INF/maven/net.java.dev.glassfish/ OK testing: META-INF/maven/net.java.dev.glassfish/glassfish-transaction-api/ OK testing: META-INF/maven/net.java.dev.glassfish/glassfish-transaction-api/pom.xml OK testing: META-INF/maven/net.java.dev.glassfish/glassfish-transaction-api/pom.properties OK No errors detected in compressed data of glassfish-transaction-api-b32g.jar. -- Felipe > Glassfish persistence and transaction apis > -- > > Key: MAVENUPLOAD-759 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-759 > Project: maven-upload-requests > Type: Task > Reporter: Wayne Fay > Assignee: John Casey > Attachments: glassfish-persistence-api-b32g-bundle.jar, > glassfish-persistence-api-b32g-bundle.jar, > glassfish-persistence-api-b32g-bundle.jar, > glassfish-transaction-api-b32g-bundle.jar, > glassfish-transaction-api-b32g-bundle.jar, persistence-api-b32g-bundle.jar, > pom.xml, pom.xml > > > These Jars are created from Glassfish build 32g beta source code and pom.xml > files that I created. > These jars are being uploaded to facilitate continued discussion on dev@ list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-649) Failure to checkout M2 module from SVN
[ http://jira.codehaus.org/browse/CONTINUUM-649?page=comments#action_62991 ] Felipe Leme commented on CONTINUUM-649: --- Hi Emmanuel, I'm using Maven 2.0.3, but Continuum 1.0.2; running mvn help:effective-pom on the parent, I got the wrong URL for the sub-projects: scm:svn:http://svn.versiondude.net/xxx/yyy/trunk/mycompany-web instead of : scm:svn:http://svn.versiondude.net/xxx/yyy/trunk/webapp Running from the sub-project results the same, so looks like the problem was not fixed on Maven 2.0.3... Regarding the workaround, I've just renamed the directories - these names are temporary anyway, as we're still in the early days of development. > Failure to checkout M2 module from SVN > -- > > Key: CONTINUUM-649 > URL: http://jira.codehaus.org/browse/CONTINUUM-649 > Project: Continuum > Type: Bug > Versions: 1.0.2 > Reporter: Felipe Leme > > > I have a M2 project with many sub-projects; one of them is the web > application, whose directory is called webapp, the module on the parent's pom > is also webapp but the project's artifactId is mycompany-web. When I run 'mvn > install' from the parent on command line, it works fine; when I import the > parent's pom into continuum, it works fine also (i.e., it automatically set > the sub-projects). But continuum fails to build the webapp project with the > message: > Provider message: The svn command failed. > Command output: > --- > svn: URL 'http://svn.versiondude.net/mycompany/voxblue/trunk/mycompany-web' > doesn't exist > In other words, continuum created the wrong URL: it used the sub-project's > artifactId and not the name defined on the parent's POM (I'm not sure if > that's a bug on continuum or M2, but the fact is that either both should work > or both fail). -- 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-649) Failure to checkout M2 module from SVN
Failure to checkout M2 module from SVN -- Key: CONTINUUM-649 URL: http://jira.codehaus.org/browse/CONTINUUM-649 Project: Continuum Type: Bug Versions: 1.0.2 Reporter: Felipe Leme I have a M2 project with many sub-projects; one of them is the web application, whose directory is called webapp, the module on the parent's pom is also webapp but the project's artifactId is mycompany-web. When I run 'mvn install' from the parent on command line, it works fine; when I import the parent's pom into continuum, it works fine also (i.e., it automatically set the sub-projects). But continuum fails to build the webapp project with the message: Provider message: The svn command failed. Command output: --- svn: URL 'http://svn.versiondude.net/mycompany/voxblue/trunk/mycompany-web' doesn't exist In other words, continuum created the wrong URL: it used the sub-project's artifactId and not the name defined on the parent's POM (I'm not sure if that's a bug on continuum or M2, but the fact is that either both should work or both fail). -- 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-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=comments#action_62807 ] Felipe Leme commented on MECLIPSE-94: - Hi Stephen, Independently of being duplicated issues, I think your reasoning makes more sense, i.e, always generate a simple eclipse project for a pom-packaging M2 project - and if it's necessary to set it as java, use the natures property (although it might be necessary to change the isJavaProject assignment to reflect that nature - I don't have the code available right now to answer for sure). Regarding the -Declipse.workspace property, I guess that explain the eclipseProjectDir == null comparisson; anyway, I still think that's not enough, as it would require each developer to set a property in order to setup the project... -- Felipe > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Type: Improvement > Versions: 2.1 > Reporter: Felipe Leme > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- 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-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=comments#action_62734 ] Felipe Leme commented on MECLIPSE-94: - Sure, no problem, makes more sense. I just wanted to be sure you were notified about it (well, I could have sent you a message, sorry :-) > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Type: Improvement > Versions: 2.1 > Reporter: Felipe Leme > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- 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-94) Allow eclipse:eclipse to work on pom (and other) projects
Allow eclipse:eclipse to work on pom (and other) projects - Key: MECLIPSE-94 URL: http://jira.codehaus.org/browse/MECLIPSE-94 Project: Maven 2.x Eclipse Plugin Type: Improvement Versions: 2.1 Reporter: Felipe Leme Assigned to: Vincent Massol I'm creating a Java EE project based on the m2book (which I was reviewing; it's not available yet...) and one of the projects is a pom-packaging project used for integration tests. According to Vincent, currently this project must be a pom (in fact, I tried to set it as jar, but then the test phase would be run anyway, which would cause the tests to fail), as it doesn't produces a jar. But as it has java files (on the src/main/it/java directory), I tried to call eclipse:eclipse but it fails, saying that "Not running eclipse plugin goal for pom project". For these scenarios, I think a propery would be enough. At first I thought something about a 'force' or 'forceGeneration' property, would enough, which the code change being from: if ( "pom".equals( packaging ) && eclipseProjectDir == null ) to: if ( "pom".equals( packaging ) && eclipseProjectDir == null && !forceGeneration ) Then I realized there is other place where the pom nature is checked: if ( "pom".equals( packaging ) && eclipseProjectDir == null && !forceGeneration ) So, I think a better name for the property would be 'javaProject' and the change would be: final boolean isJavaProjectProperty = // read property; defaults to false... if ( "pom".equals( packaging ) && eclipseProjectDir == null && !isJavaProjectProperty ) isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && !"pom".equals( packaging ); If nobody objects and someone is willing to apply the changes, I can provide such patch (with the proper test cases). -- Felipe PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features already existed :-) -- 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: (MWAR-29) includes/excludes should extend to generated stuff
includes/excludes should extend to generated stuff -- Key: MWAR-29 URL: http://jira.codehaus.org/browse/MWAR-29 Project: Maven 2.x War Plugin Type: Improvement Reporter: Felipe Leme I'm working on a war project where we decided to include some mock classes on the source directory, so the developers can work on the Structs actions without worrying with the backend. As such, these classes should not be included in the 'official' war file (they are only used by the jetty6 plugin). So, I tried to use the configuration to exclude then but failed to do so. After struggling for a while with the -X option, google and jira, I realized such configuration only excludes files from the warSource directory (i.e, the stuff that goes in the web application root, like JSP pages). I've seen some bug entries regarding filtering resources and the includes/excludes not working a while ago, but I believe those are other issues... -- 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-2194) no downloading attempts of non-existing artifact
[ http://jira.codehaus.org/browse/MNG-2194?page=comments#action_62630 ] Felipe Leme commented on MNG-2194: -- I agree with the reporter; the delay is very annoying. For instance, I have a project that use the latest versions of Spring and Hibernate, and it takes many seconds to build due to warns such as: Downloading: http://ibiblio.lsu.edu/main/pub/packages/maven2//org/springframework/spring-context/2.0-m3/spring-context-2.0-m3.pom [WARNING] Unable to get resource from repository central (http://ibiblio.lsu.edu/main/pub/packages/maven2/) Downloading: http://ibiblio.lsu.edu/main/pub/packages/maven2//org/springframework/spring-web/2.0-m3/spring-web-2.0-m3.pom [WARNING] Unable to get resource from repository central (http://ibiblio.lsu.edu/main/pub/packages/maven2/) > no downloading attempts of non-existing artifact > > > Key: MNG-2194 > URL: http://jira.codehaus.org/browse/MNG-2194 > Project: Maven 2 > Type: Improvement > Components: Artifacts and Repositories > Versions: 2.0.2 > Environment: not dependent on environment > Reporter: John Franey > Priority: Minor > > > I'm converting a project to maven 2. Some dependencies do not exist in > ibiblio, so I've 'installed' these into my local repository. > I'm unhappy because every time I perform a run, there is a significant > delay (sometimes) when maven tries to download these non-existent > artifacts. I get these messages: > Downloading: http://repo1.maven.org/maven2/.../...pom > How can I prevent maven's attempt to download these non-existent > artifacts? I'm most interested in eliminating the delay. > I know I can run with the 'offline' option. This is OK as long as I'm > sure all existing artifacts that are already downloaded into my cache. > So I can do this until I build on a system with no local cache of add a > new dependency to my projects, at which time the delay is experienced > due to these non-existent artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MEV-255) Problem with junit-addons 1.4
[ http://jira.codehaus.org/browse/MEV-255?page=all ] Felipe Leme reopened MEV-255: - Hi Edwin, Actually, the POM hasn't been updated yet, even though you fixed it almost 1 week ago. Here is the current content (http://www.ibiblio.org/maven2/junit-addons/junit-addons/1.4/junit-addons-1.4.pom ) 4.0.0 junit-addons junit-addons 1.4 junit-addons junit-addons-runner 1.0-alpha1 jdom jdom 1.0 jaxen jaxen 1.0-FCS saxpath saxpath 1.0-FCS junit junit 3.8.1 xerces xercesImpl 2.6.2 xerces xmlParserAPIs 2.6.2 commons-logging commons-logging 1.0.4 -- Felipe > Problem with junit-addons 1.4 > - > > Key: MEV-255 > URL: http://jira.codehaus.org/browse/MEV-255 > Project: Maven Evangelism > Type: Task > Reporter: David Eric Pugh > Assignee: Edwin Punzalan > > > junit-addons's M2 pom: > http://www.ibiblio.org/maven2/junit-addons/junit-addons/1.4/junit-addons-1.4.pom > says taht it depends on junit-addons-runner-1.0-alpha1. However, this jar > doesn't exist on ibiblio or Maven2 repositories. Additionally, > www.ibiblio.org/maven/junit-addons/jars/ didn't have it either. -- 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
