[jira] Commented: (MNG-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103841
]
William Ferguson commented on MNG-2290:
---
Sorry Jorge, you lost me.
The URL *is* inherited (if it is not specified in the child POM), but at
execution time (in the child) it becomes the inherited URL with the
${artifactId} specified in the child POM appended to it.
So deployment of the site for the parent POM is to an entirely different
location (the root of the projects website) than for any children.
Ie there is no consistent site deployment location available to the parent POM
and child projects.
IMHO it is not useful to attempt to inherit the SCM settings as the
release-plugin needs to rewrite them in the child POM during release in any
case. I think thats what you are referring to in your last 2 sentences. Correct
me if I'm wrong.
But the thing thats a real killer (for us) is that because ${artifactId} is
appended to the URLs we cannot craft an inheritable URL that includes the child
project's version.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin 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: (MAVENUPLOAD-1661) Add Parancoe synched repository
Add Parancoe synched repository Key: MAVENUPLOAD-1661 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1661 Project: maven-upload-requests Issue Type: Task Reporter: Lucio Benfante Attachments: org.parancoe.sh Can you please add the Parancoe repository to the synchronized ones? -- 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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103845
]
Joerg Schaible commented on MNG-2290:
-
I'm inclined to close this issue as invalid anyway. A lot of my initial
description does not really apply in the way I've described it - it was more or
less a fact of my incomplete knowledge of Maven. My complaints in the second
part of the description about artifacts with the same artifact id but different
packaging is bad practice, since some plugins will fail to handle such
artifacts.
For the SCM URLs we separate meanwhile between two cases:
1/ A POM inherits form a global POM: In this case the global POM's SCM URLs are
not related to the POM inheriting the global POM's settings (since they define
where the global POM's releases are managed) and the SCM section must be
defined always.
2/ A POM inherits from a direct parent POM: In our case this means that the
children also share the same release cycle i.e. from a Subversion SCM PoV the
"trunk" is above the location of the parent POM. This also means that the POMs
of the children do not have a SCM section at all, since they are never released
standalone. Note, that the release plugin will also not add such a section, it
only modifies the parent POM.
Both cases work well and none of my original description applies.
So there's only the project's URL and the distribution URL left. Honestly, I
did not play yet with the site plugin enough to make any real valid comment on
it. Our artifacts are too fine grained for a useful automated site generation
and we keep documentation differently.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin 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] Updated: (CONTINUUM-981) "Remove" button on group actions is ambiguous and should be renamed "Delete Group" or "Remove Group".
[ http://jira.codehaus.org/browse/CONTINUUM-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-981: --- Fix Version/s: (was: Future) 1.1-beta-2 > "Remove" button on group actions is ambiguous and should be renamed "Delete > Group" or "Remove Group". > - > > Key: CONTINUUM-981 > URL: http://jira.codehaus.org/browse/CONTINUUM-981 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Christian Gruber >Priority: Trivial > Fix For: 1.1-beta-2 > > > "Remove" button on group actions is ambiguous and should be renamed "Delete > Group" or "Remove Group". It currently reads as if it would remove some > group members. -- 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-1086) First form element should have focus
[ http://jira.codehaus.org/browse/CONTINUUM-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1086: Fix Version/s: (was: Future) 1.1-beta-2 > First form element should have focus > > > Key: CONTINUUM-1086 > URL: http://jira.codehaus.org/browse/CONTINUUM-1086 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-alpha-1 >Reporter: Wendy Smoak >Priority: Trivial > Fix For: 1.1-beta-2 > > > For example, the username field should have focus when the login form is > displayed. (Currently, it's #9 in the tab order.) > Same for the username field on the Registration form, the Pom URL field on > the Add m2 project form, etc. -- 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-982) "Project Group Actions" should be renamed "Group Actions" to avoid confusion.
[ http://jira.codehaus.org/browse/CONTINUUM-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-982: --- Fix Version/s: (was: Future) 1.1-beta-2 > "Project Group Actions" should be renamed "Group Actions" to avoid confusion. > - > > Key: CONTINUUM-982 > URL: http://jira.codehaus.org/browse/CONTINUUM-982 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Christian Gruber >Priority: Trivial > Fix For: 1.1-beta-2 > > > Summary says it all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1233) Reduce number of clicks to add a project
[ http://jira.codehaus.org/browse/CONTINUUM-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1233: Fix Version/s: (was: Future) 1.1-beta-2 > Reduce number of clicks to add a project > > > Key: CONTINUUM-1233 > URL: http://jira.codehaus.org/browse/CONTINUUM-1233 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-alpha-1 >Reporter: Wendy Smoak > Fix For: 1.1-beta-2 > > > With the addition of the project group roles, adding a Maven 2 project > changed from one click (Add M2 Project button) to three clicks-- focus on > the Add New Project drop-down, select a type, click the Add button. > If we made the default for the select list configurable somewhere, or even > made it "remember" the last choice used during that session, then adding > multiple projects would be much more pleasant. > In addition, adding a project returns you to the Project Groups page, so that > you have to click to get back to the group summary page to add the next > project. (Similar to CONTINUUM-1115) -- 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-1232) Continuum should not steal window focus on page load
[ http://jira.codehaus.org/browse/CONTINUUM-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1232: Fix Version/s: (was: Future) 1.1-beta-2 Need to be tested but seems to be a IE issue > Continuum should not steal window focus on page load > > > Key: CONTINUUM-1232 > URL: http://jira.codehaus.org/browse/CONTINUUM-1232 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-alpha-1 >Reporter: Wendy Smoak >Priority: Minor > Fix For: 1.1-beta-2 > > > Continuum has a habit of stealing window focus on page load events. For > example, if you click "Build" and then minimize the window to do something > else, the browser window will pop back on top when the page is finished > loading. -- 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-1662) Upload request for jython 2.2-rc3
Upload request for jython 2.2-rc3 - Key: MAVENUPLOAD-1662 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1662 Project: maven-upload-requests Issue Type: Task Reporter: Charlie Groves -- 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-983) There should be real "Group Actions" that affect members of the group, and can affect subsets of group members based on selection.
[ http://jira.codehaus.org/browse/CONTINUUM-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-983: --- Fix Version/s: (was: Future) 1.1-beta-2 > There should be real "Group Actions" that affect members of the group, and > can affect subsets of group members based on selection. > -- > > Key: CONTINUUM-983 > URL: http://jira.codehaus.org/browse/CONTINUUM-983 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Christian Gruber > Fix For: 1.1-beta-2 > > > There should be real "Group Actions" that affect members of the group, and > can affect subsets of group members based on selection. > In particular, there should be check-boxes before each member, which can > allow such "group actions" to affect one or more members. Group actions I > envision would include "Build (with default build def)" and > "Remove project from group". Any selected groups would be built or removed. > The current "Remove" button would be moved elsewhere, as it is not about the > contents of the group, but deletes the whole group. Possibly simply making > an "X" remove button on the main list of groups, much the way individual > projects have the same would work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPMD-60) @SuppressWarnings causes maven PMD plugin to fail on building report
@SuppressWarnings causes maven PMD plugin to fail on building report
Key: MPMD-60
URL: http://jira.codehaus.org/browse/MPMD-60
Project: Maven 2.x PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 2.2
Environment: Windows XP, Java 6, Maven 2.0.6, PMD-3.9 plugin
Reporter: Pieter Iserbyt
When running mvn pmd:pmd, the plugin crashes at the time it tries to create the
report.
This seems to happen when violations are present that are suppressed by a
@SuppressWarnings("PMD") or @SuppressWarnings("PMD.a_warning_name") annotation.
Also, java keywords are not recognized by PMD, e.g. for
@SuppressWarnings("unused"), violations are logged anyway.
D:\trunk\quality>mvn pmd:check -e
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'pmd'.
[INFO] org.apache.maven.plugins: checking for updates from doc-artifactory
[INFO] org.codehaus.mojo: checking for updates from doc-artifactory
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'cc696ab05c9684342aa52c61bdcb7471a264b533'; remote =
'fd019ddf5b11fc51ce35ac7cf10c2ef5b387b0cf' - RETRYING
[INFO] artifact org.apache.maven.plugins:maven-pmd-plugin: checking for updates
from doc-artifactory
[INFO]
[INFO] Building Diamond Quality
[INFO]task-segment: [pmd:check]
[INFO]
[INFO] Preparing pmd:check
[INFO] [pmd:pmd]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An error has occurred in PMD Report report generation.
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred
in PMD Report report generation.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:903)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:510)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
occurred in PMD Report report generation.
at
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:79)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 19 more
Caused by: java.lang.NullPointerException
at
net.sourceforge.pmd.util.StringUtil.appendXmlEscaped(StringUtil.java:78)
at
net.sourceforge.pmd.util.StringUtil.appendXmlEscaped(StringUtil.java:65)
at net.sourceforge.pmd.renderers.XMLRenderer.render(XMLRenderer.java:88)
at
org.apache.maven.plugin.pmd.PmdReport.executeReport(PmdReport.java:260)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
at
org.apache.maven.reporting.AbstractMavenReport.execute(Abstr
[jira] Created: (MAVEN-1853) fetching dependencies fails (3 problems)
fetching dependencies fails (3 problems) Key: MAVEN-1853 URL: http://jira.codehaus.org/browse/MAVEN-1853 Project: Maven 1 Issue Type: Bug Components: core Affects Versions: 1.1 Environment: win xp pro Reporter: Axel G Attachments: jpox-1.2.0-beta-3.jar I'm having 3 problems related to fetching dependencies: i just tried to fetch a single dependency and ran into problems 1) maven 1.1 doesnt seem to pick up neither project.properties nor my build.properties in the directory i start maven (it picks up project.xml and maven.xml without a problem from there) I needed that for setting the remote repository; could fix it by supplying a cli arg -Dmaven.repo.remote=http://www.jpox.org/downloads/maven/ Anyway its not supposed to be that way 2) the default repository seems to have a problem with rather fetching/using a xml (xhtml?) file than a checksum ~file (see snippet later on) 3) following 2), instead of the wanted jar jpox-1.2.0-beta-3.jar, i have now a apache xhtml file with that name in my local repository (attached it). As thus, maven wont try to refetch the dependency until I delete that file. Maybe a short check, if the downloaded file is a non-corrupted jar would be good for detecting problems early. __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1 Trying to get missing dependencies (and updated snapshots) required by JPOX-Maven: - Attempting to download jpox:jpox:1.2.0-beta-3:jar from http://www.apache.org/dyn/closer.cgi/java-repository/maven/ 3K downloaded *** CHECKSUM FAILED - Checksum failed on download: local = '46304cf35acafaaf53e042c8704865d7'; remote = ' i'm surprised that i couldnt find anybody else having this problem neither on the maillinglist nor the jira. anyway, i hope this contributes sth. thanks for the good work, axel -- 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: (MAVEN-1853) fetching dependencies fails (3 problems)
[ http://jira.codehaus.org/browse/MAVEN-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Axel G updated MAVEN-1853: -- Attachment: maven1_prob.txt dont know jira-syntax, so here is the snippet as a text file > fetching dependencies fails (3 problems) > > > Key: MAVEN-1853 > URL: http://jira.codehaus.org/browse/MAVEN-1853 > Project: Maven 1 > Issue Type: Bug > Components: core >Affects Versions: 1.1 > Environment: win xp pro >Reporter: Axel G > Attachments: jpox-1.2.0-beta-3.jar, maven1_prob.txt > > > I'm having 3 problems related to fetching dependencies: > i just tried to fetch a single dependency and ran into problems > 1) maven 1.1 doesnt seem to pick up neither project.properties nor my > build.properties in the directory i start maven (it picks up project.xml and > maven.xml without a problem from there) > I needed that for setting the remote repository; could fix it by supplying a > cli arg -Dmaven.repo.remote=http://www.jpox.org/downloads/maven/ > Anyway its not supposed to be that way > 2) the default repository seems to have a problem with rather fetching/using > a xml (xhtml?) file than a checksum ~file (see snippet later on) > 3) following 2), instead of the wanted jar jpox-1.2.0-beta-3.jar, i have now > a apache xhtml file with that name in my local repository (attached it). > As thus, maven wont try to refetch the dependency until I delete that file. > Maybe a short check, if the downloaded file is a non-corrupted jar would be > good for detecting problems early. > > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1 > Trying to get missing dependencies (and updated snapshots) required by > JPOX-Maven: > - Attempting to download jpox:jpox:1.2.0-beta-3:jar from > http://www.apache.org/dyn/closer.cgi/java-repository/maven/ > 3K downloaded > *** CHECKSUM FAILED - Checksum failed on download: local = > '46304cf35acafaaf53e042c8704865d7'; remote = ' > i'm surprised that i couldnt find anybody else having this problem neither on > the maillinglist nor the jira. anyway, i hope this contributes sth. > thanks for the good work, > axel -- 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: (MRELEASE-273) Regression: NullPointerException at end of standalone "release:perform"
Regression: NullPointerException at end of standalone "release:perform"
---
Key: MRELEASE-273
URL: http://jira.codehaus.org/browse/MRELEASE-273
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-6
Environment: Maven 2.0.7, maven-release-plugin 2.0-alpha-6
Reporter: Max Bowsher
Priority: Blocker
I executed "mvn release:perform -DconnectionUrl=scm:svn:..". The actual
performing succeeded, but then the plugin failed with a NullPointerException -
it seems that the plugin attempts to unconditionally run code analogous to "mvn
release:clean", but this is inappropriate because release:perform is not
supposed to require a project to be able to run.
Output:
{noformat}
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 28 seconds
[INFO] Finished at: Thu Aug 02 12:53:49 BST 2007
[INFO] Final Memory: 13M/23M
[INFO]
[INFO] Cleaning up after release...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[DEBUG] Trace
java.lang.NullPointerException
at
org.apache.maven.shared.release.util.ReleaseUtil.getReleasePom(ReleaseUtil.java:73)
at
org.apache.maven.shared.release.util.ReleaseUtil.getStandardPom(ReleaseUtil.java:61)
at
org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.getPomBackup(AbstractBackupPomsPhase.java:37)
at
org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.deletePomBackup(AbstractBackupPomsPhase.java:51)
at
org.apache.maven.shared.release.phase.CreateBackupPomsPhase.clean(CreateBackupPomsPhase.java:70)
at
org.apache.maven.shared.release.DefaultReleaseManager.clean(DefaultReleaseManager.java:427)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:324)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:267)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:260)
at
org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:102)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 39 seconds
[INFO] Finished at: Thu Aug 02 12:53:49 BST 2007
[INFO] Final Memory: 4M/8M
[INFO]
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1651) junit 4.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103858 ] Andreas Schildbach commented on MAVENUPLOAD-1651: - Mauro: Can you explain what's the advantage of having those hamcrest classes in the junit bundle? > junit 4.4 > - > > Key: MAVENUPLOAD-1651 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1651 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Tomislav Stojcevich >Assignee: Mauro Talevi > Attachments: junit-4.4-bundle.jar, junit-4.4-bundle.jar > > > Upload new version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-246) path of site.xml not possible to configure in tag
path of site.xml not possible to configure in tag - Key: MSITE-246 URL: http://jira.codehaus.org/browse/MSITE-246 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: maven 2.0.7 Reporter: Xavier Marc Priority: Blocker i configure the maven-site-plugin like that : org.apache.maven.plugins maven-site-plugin 2.0-beta-5 D:\omegabox\WEB-INF\src and my file site.xml is in directory : D:\omegabox\WEB-INF\src\site.xml But when i execute a maven command (mvn site) maven don't find the file site.xml. -- 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-3131) Error message is misleading if a missing plugin parameter is of a type like List
Error message is misleading if a missing plugin parameter is of a type like List
Key: MNG-3131
URL: http://jira.codehaus.org/browse/MNG-3131
Project: Maven 2
Issue Type: Bug
Reporter: Dennis Lundberg
Here is a sample output I got when I was working on the changes-plugin:
{code}
[INFO] One or more required plugin parameters are invalid/missing for
'changes:announcement-mail'
[0] inside the definition for plugin: 'maven-changes-plugin'specify the
following:
...
VALUE
.
[1] inside the definition for plugin: 'maven-changes-plugin'specify the
following:
...
VALUE
.
{code}
Notice the second parameter toAdresses. It is of the type List, so the correct
configuration would be something like this
{code}
...
VALUE
.
{code}
I haven't found where in the code base the handling of List/Map/Array
parameters is. That code could probably be borrowed/reused in
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterException.java
which is the class responsible for formating the above messages.
--
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: (MEV-536) Broken checksums and signature for maven-2.0.7.pom
[ http://jira.codehaus.org/browse/MEV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103861 ] Max Bowsher commented on MEV-536: - Is there any problem preventing this from being fixed? AFAICS, it is just a simple job of regenerating the .md5 and .sha1 files correctly, and deleting the .asc file. Any investigation into why the checksums are broken should not require that the checksums remain broken in the live repository, surely? > Broken checksums and signature for maven-2.0.7.pom > -- > > Key: MEV-536 > URL: http://jira.codehaus.org/browse/MEV-536 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher >Assignee: Jason van Zyl > > http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.7/maven-2.0.7.pom > .md5 and .sha1 are broken due to being in incorrect format (generated by BSD > checksum tools?) > .asc is bad signature. -- 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: (MEV-530) Broken checksum for org/apache/maven/maven/2.0.6/maven-2.0.6.pom
[ http://jira.codehaus.org/browse/MEV-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103860 ] Max Bowsher commented on MEV-530: - Is there any problem preventing this from being fixed? AFAICS, it is just a simple job of regenerating the .md5 and .sha1 files correctly, and deleting the .asc file. Any investigation into why the checksums are broken should not require that the checksums remain broken in the live repository, surely? > Broken checksum for org/apache/maven/maven/2.0.6/maven-2.0.6.pom > > > Key: MEV-530 > URL: http://jira.codehaus.org/browse/MEV-530 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher >Assignee: Jason van Zyl > > org/apache/maven/maven/2.0.6/maven-2.0.6.pom has bad md5 and sha1 -- 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-1359) Installations removed from a profile when "Save" is clicked.
Installations removed from a profile when "Save" is clicked. Key: CONTINUUM-1359 URL: http://jira.codehaus.org/browse/CONTINUUM-1359 Project: Continuum Issue Type: Bug Components: Web - UI Affects Versions: 1.1-beta-1 Reporter: Eric Miles If I go into a Profile and add installations then click the "Save" button near the name of the profile, the installations I have added are then removed. It's a little misleading to click "Save" and to have installations 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: (MENFORCER-14) Enforcer Plugin Messes Up Dependencies
[ http://jira.codehaus.org/browse/MENFORCER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103863 ] James Carman commented on MENFORCER-14: --- I would disagree that changing "enforce-once" to "enforce" is a "fix". That is at best a work-around. As Andrew Perepelytsya said on the related duplicate issue, this will slow down the build, so it's not even really a great work-around. At this point, we're just not going to use the plugin (we were only enforcing java version and maven version, so it's not a big loss anyway). > Enforcer Plugin Messes Up Dependencies > -- > > Key: MENFORCER-14 > URL: http://jira.codehaus.org/browse/MENFORCER-14 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug >Reporter: James Carman >Assignee: Brian Fox > Attachments: toplevel.zip > > > When using the enforcer plugin, it somehow messes up the dependencies in a > reactor-based build. The attached zip file exhibits the problem. Our project > structure is a bit weird. We have one top-level project which contains a > bunch of modules. One of the modules is a pom-based "tempalte" project which > sets up all of our build settings (src/target for the compiler, turns on the > aspectj compiler, etc.). All of the other modules extend the "template" > project and they themselves have multiple sub-project. -- 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: (MCHANGES-71) need add template encoding to announcement-generate
[
http://jira.codehaus.org/browse/MCHANGES-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103867
]
Dennis Lundberg commented on MCHANGES-71:
-
Do you want to be able to specify the input and output encodings in the
configuration element for this plugin in your pom, like this?
{code}
UTF-8
UTF-8
{code}
Then those parameters should be forwarded to the velocity context as the
properties "input.encoding" and output.encoding"?
> need add template encoding to announcement-generate
> ---
>
> Key: MCHANGES-71
> URL: http://jira.codehaus.org/browse/MCHANGES-71
> Project: Maven 2.x Changes Plugin
> Issue Type: Improvement
> Components: announcement
>Reporter: Yao Yong
>
> I need to generate a Chinese announcement, would you please add the following
> velocity property into parameters
> input.encoding
> output.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] Closed: (MCHANGES-79) Allow for overriding the announcement email from address
[
http://jira.codehaus.org/browse/MCHANGES-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGES-79.
---
Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.0-beta-3
Patch applied, with modifications.
Thanks!
> Allow for overriding the announcement email from address
>
>
> Key: MCHANGES-79
> URL: http://jira.codehaus.org/browse/MCHANGES-79
> Project: Maven 2.x Changes Plugin
> Issue Type: New Feature
> Components: announcement
>Reporter: Alexander Schwartz
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-3
>
> Attachments: MCHANGES-79-patch.txt
>
>
> Currently the goal {{changes:announcement-mail}} uses the email address of
> the first developer found in the pom as the from address of the announcement
> email. Very often a project is released by a developer that is not the first
> on in the list of developers in the pom -- which results is an announcement
> email with awron, confusing from address. (Of course one can change the list
> of developers for each release, or add a dummy developer "buildmaster" as the
> first one in the developer list, but this is not my preferred option).
> The maven1 announcement plugin has a parameter {{from}} which allows to
> specify a different from address.
> I suggest to add an optional parameter {{fromAdress}} to the goal
> {{changes:announcement-mail}} of the {{maven-changes-plugin}} such that one
> can specify the sender as follows:
> {noformat}
>
> ...
>
>
>
> org.apache.maven.plugins
> maven-changes-plugin
>
>
> [EMAIL PROTECTED]
>
>
>
>
>
> ...
>
> {noformat}
> If the paremter {{fromAdress}} is given its content is taken as the the
> sender address of the announcement mail. If the option is not specified, the
> fallback is the email address of the first developer 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] Issue Comment Edited: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98117
]
Wendy Smoak edited comment on ARCHETYPE-39 at 8/2/07 10:22 AM:
---
To get ${artifactId} in the output, use $ \ { artifactId } (with no spaces) in
the template.
was:
To get ${artifactId} in the output, use $\{artifactId} in the template.
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity 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] Commented: (MAVENUPLOAD-1651) junit 4.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103868 ] Mauro Talevi commented on MAVENUPLOAD-1651: --- I'm actually advocating the exact opposite: for me bundling dependency classes in the junit jar is a very bad decision. IMO it motivated primarily by the perceived "simplicity" of having a single jar rather than two or more. In fact, it is a recipe for a classloader quagmire when hamcrest jars are also present in the classpath. I've argued this on the junit list and I've had no reply.So - respectful of other projects decisions, even when not in agreement with them - I think the least common denominator is to upload *both* a junit artifact - as released by the project - and a junit-dep which has the hamcrest 1.1 dependency as a transitive dependency. Then people will be free to choose what they want to use. > junit 4.4 > - > > Key: MAVENUPLOAD-1651 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1651 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Tomislav Stojcevich >Assignee: Mauro Talevi > Attachments: junit-4.4-bundle.jar, junit-4.4-bundle.jar > > > Upload new version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103869
]
Wendy Smoak commented on ARCHETYPE-39:
--
I also edited the earlier comment, which wasn't displaying correctly. I
haven't tested it with the latest releases, but in early June, this worked:
To get ${artifactId} in the output, use $ \ { artifactId } (with no spaces) in
the template.
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity 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] 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_103870 ] Dennis Lundberg commented on DOXIA-131: --- I have checked the different standards and have not found any evidence that ids need to be lower case. So I added a test case and changed encodeId() to not change case anymore. I also added tons of JavaDoc. Is that enough or did you have any other documentation in mind, Lukas? > HtmlTools.encodeId makes id lower case > -- > > Key: DOXIA-131 > URL: http://jira.codehaus.org/browse/DOXIA-131 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl >Assignee: Dennis Lundberg > 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] Created: (MWAR-111) Transitive dependencies of optional dependencies are included in WEB-INF/lib
Transitive dependencies of optional dependencies are included in WEB-INF/lib Key: MWAR-111 URL: http://jira.codehaus.org/browse/MWAR-111 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Maven 2.0.7, JDK 1.6.0_01-b06, JavaEE 5 Reporter: Chris Lance Attachments: TestProject.zip I have an EAR project (TestEAR) which contains two modules: 1. A JAR module (TestJAR) which has one dependency: commons-lang 2.3 2. A WAR module (TestWAR) which uses [these instructions|http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html] to declare a dependency on TestJAR so that TestJAR is included in TestWAR's manifest classpath, but not copied into WEB-INF/lib (i.e. declares the dependency optional). This works fine for TestJAR itself, but its transitive dependency (commons-lang 2.3) is still copied into WEB-INF/lib. I don't believe this is the correct behavior since all dependencies of a JAR packaged in the EAR must also be packaged in the EAR. So, all a WAR should have to do is put the transitive dependencies in its manifest classpath to inherit them. Basically: in a WAR, transitive dependencies of "optional" dependencies should inherit the "optional" flag. I have included a simple test project as an example. Unzip, cd TestProject, and mvn install. Look in TestEAR's target dir and you will see that commons-lang is included in the EAR. Then look in TestWAR's target dir and you will see that commons-lang is also included in both the manifest classpath and the WEB-INF/lib dir. -- 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: (MRM-442) Unable to disable Scannable on a Local Repository.
Unable to disable Scannable on a Local Repository. -- Key: MRM-442 URL: http://jira.codehaus.org/browse/MRM-442 Project: Archiva Issue Type: Bug Components: documentation Affects Versions: 1.0-alpha-2 Reporter: Joakim Erdfelt As reported in archiva-users mailing list Barrie Treloar wrote: > I'm using Archiva 1.0 Alpha 2, > > When I edit a repository definition and disable "Scannable" and save > my changes, the changes appear to be ignored on the Repositories > screen. -- 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-1663) Upload org.hibernate:hibernate:jar:3.2.5.ga to ibiblio
Upload org.hibernate:hibernate:jar:3.2.5.ga to ibiblio -- Key: MAVENUPLOAD-1663 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1663 Project: maven-upload-requests Issue Type: Task Reporter: Craig Condit http://randomcoder.com/repos/public/maven-uploads/hibernate-3.2.5.ga-bundle.jar http://www.hibernate.org/ Relational Persistence for Java -- 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: (MWAR-111) Transitive dependencies of optional dependencies are included in WEB-INF/lib
[ http://jira.codehaus.org/browse/MWAR-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lance updated MWAR-111: - Attachment: AbstractWarMojo.java This is a quick patch I put together against the trunk for this issue. Forgive my ignorance if there was an easier way to code it :-) > Transitive dependencies of optional dependencies are included in WEB-INF/lib > > > Key: MWAR-111 > URL: http://jira.codehaus.org/browse/MWAR-111 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Maven 2.0.7, JDK 1.6.0_01-b06, JavaEE 5 >Reporter: Chris Lance > Attachments: AbstractWarMojo.java, TestProject.zip > > > I have an EAR project (TestEAR) which contains two modules: > 1. A JAR module (TestJAR) which has one dependency: commons-lang 2.3 > 2. A WAR module (TestWAR) which uses [these > instructions|http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html] > to declare a dependency on TestJAR so that TestJAR is included in TestWAR's > manifest classpath, but not copied into WEB-INF/lib (i.e. declares the > dependency optional). > This works fine for TestJAR itself, but its transitive dependency > (commons-lang 2.3) is still copied into WEB-INF/lib. I don't believe this is > the correct behavior since all dependencies of a JAR packaged in the EAR must > also be packaged in the EAR. So, all a WAR should have to do is put the > transitive dependencies in its manifest classpath to inherit them. Basically: > in a WAR, transitive dependencies of "optional" dependencies should inherit > the "optional" flag. > I have included a simple test project as an example. Unzip, cd TestProject, > and mvn install. Look in TestEAR's target dir and you will see that > commons-lang is included in the EAR. Then look in TestWAR's target dir and > you will see that commons-lang is also included in both the manifest > classpath and the WEB-INF/lib dir. -- 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: (MCHANGES-83) changes report generates invalid anchor name
[ http://jira.codehaus.org/browse/MCHANGES-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-83. --- Resolution: Duplicate > changes report generates invalid anchor name > > > Key: MCHANGES-83 > URL: http://jira.codehaus.org/browse/MCHANGES-83 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-2 >Reporter: Cliffano Subagio >Priority: Trivial > Attachments: changesreportinvalidhtml-patch.txt > > > Changes report generates two invalid anchor names "Changes Report" and > "Release History" which cause this error on W3 validator tool: > 'value of attribute "name" must be a single token' > The attached patch fixes the problem by adding anchor properties with valid > anchor names. > Another option is to remove whitespaces from "Changes Report" and "Release > History", but I think making the anchor names configurable is a better way to > go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1651) junit 4.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103881 ] Andreas Schildbach commented on MAVENUPLOAD-1651: - I think an "all-in-one" jar should not be uploaded to ibiblio. You will only safely avoid classloader hell with all-in-one JARs if you completely manage dependencies yourself, i.e. stick them into a "lib" directory the old-fashioned way. People who go this route can simply download junit 4.4 from the website, they won't use ibiblio anyway. > junit 4.4 > - > > Key: MAVENUPLOAD-1651 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1651 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Tomislav Stojcevich >Assignee: Mauro Talevi > Attachments: junit-4.4-bundle.jar, junit-4.4-bundle.jar > > > Upload new version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHANGES-57) How does the plugin know what issues were fixed in this version?
[
http://jira.codehaus.org/browse/MCHANGES-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGES-57.
---
Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.0-beta-3
The plugin gets all issues from JIRA as an xml file. Then it finds suitable
fixVersions in the xml file, that matches the current ${project.version},
excluding any SNAPSHOT suffix.
> How does the plugin know what issues were fixed in this version?
>
>
> Key: MCHANGES-57
> URL: http://jira.codehaus.org/browse/MCHANGES-57
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira-report
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-3
>
> Attachments: MCHANGES-57.patch
>
>
> From the user-list:
> I was able to configure the maven-changes plugin for JIRA, but how to
> generate a report.
> My basic question is: how does maven/svn know what issues got fixes as part
> of checkin? Does the developer need to mention this data in some xml file.
> I have read somewhere that if you configure JIRA as the issue
> management tool, it should pull automatically... I don't get that. Any
> clues?
--
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: (MCHANGES-50) Handle JIRA authentication failure
[ http://jira.codehaus.org/browse/MCHANGES-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-50. --- Resolution: Fixed Fix Version/s: 2.0-beta-3 It turns out that my test project was busted in other respects. After fixing that I now get a pretty "empty" report that says that an error occurred and directing to the console for more info. > Handle JIRA authentication failure > -- > > Key: MCHANGES-50 > URL: http://jira.codehaus.org/browse/MCHANGES-50 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira-report >Affects Versions: 2.0-beta-2 >Reporter: Mike Perham >Assignee: Dennis Lundberg > Fix For: 2.0-beta-3 > > Attachments: MCHANGES-50.tar.gz > > > Private instances of JIRA require authentication. If the changes report > queries this server, the server returns a HTML 500 error page, rather than > the expected XML content and the changes plugin throws an exception. This > case should be handled and a warning printed to the screen (maybe with a hint > as to the parameter(s) they need to set) so the site generation can continue. > See http://jira.webifysolutions.com for instance. You can use this URL for > one-off testing of this fix. -- 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-329) The Reports link gives an HTTP 500
[ http://jira.codehaus.org/browse/MRM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103887 ] Joakim Erdfelt commented on MRM-329: Patches look good. Great work Teody! Patches applied in revision 562233. > The Reports link gives an HTTP 500 > -- > > Key: MRM-329 > URL: http://jira.codehaus.org/browse/MRM-329 > Project: Archiva > Issue Type: Bug > Components: reporting >Affects Versions: 1.0-alpha-1 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Teodoro Cue Jr. >Priority: Blocker > Fix For: 1.0-beta-1 > > Attachments: MRM-329-archiva-database-20070725.patch, > MRM-329-archiva-database-20070801.patch, > MRM-329-archiva-model-20070727.patch, MRM-329-archiva-model-20070801.patch, > MRM-329-archiva-webapp-20070725.patch, MRM-329-archiva-webapp-20070801.patch > > > Clicking the Reports link in the side navigation menu displays the following > (edited/snipped stacktrace): > HTTP ERROR: 500 > RequestURI=/admin/reports.action > Caused by: javax.el.PropertyNotFoundException: The class > 'org.apache.maven.archiva.reporting.artifact.OldArtifactReport' does not have > the property 'groupId'. > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) > at javax.el.BeanELResolver.getValue(BeanELResolver.java:280) > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) > at com.sun.el.parser.AstValue.getValue(AstValue.java:118) > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192) > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:974) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspx_meth_c_forEach_0(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:143) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspService(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:85) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) -- 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: (MCHANGES-82) Issue Management URL not ending in a '/' result in an incorrect issue link on the change report.
[ http://jira.codehaus.org/browse/MCHANGES-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-82. --- Assignee: Dennis Lundberg Resolution: Won't Fix I have updated the documentation to explain how this works. The example at the pom page has also been updated with a trailing slash. > Issue Management URL not ending in a '/' result in an incorrect issue link on > the change report. > > > Key: MCHANGES-82 > URL: http://jira.codehaus.org/browse/MCHANGES-82 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Affects Versions: 2.0-beta-2 >Reporter: Paul Spencer >Assignee: Dennis Lundberg > > Issue Management URL not ending in a '/' result in an incorrect issue link on > the change report. If the Url is "http://issues.foo.com";, then the link to > issue 1 is "http://ViewIssue.jspa?key=1";. This problem is made worse by the > issue management example in http://maven.apache.org/pom.html. In that > example the url is http://127.0.0.1/bugzilla. > I believe the source of the problem is in > ChangesReportGenerator.parseIssueLink(). This method assumes the URL will > end in a "/", instead of checking for an ending "/" >String url = this.url.substring( 0, this.url.lastIndexOf( "/" ) ); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-59) Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V
[ http://jira.codehaus.org/browse/SUREFIRE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103893 ] hanasaki commented on SUREFIRE-59: -- Rolled back to testng 5.0 in netbeans 6.x nightly builds and this appears to be a workaround. Escalate resolution please? > Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: > org.testng.xml.XmlSuite.setParallel(Z)V > - > > Key: SUREFIRE-59 > URL: http://jira.codehaus.org/browse/SUREFIRE-59 > Project: Maven Surefire > Issue Type: Improvement > Components: TestNG support > Environment: > maven-surefire-plugin > 2.2 > > > org.testng > testng > 5.2 > jdk15 > test > >Reporter: Damian Golda > Fix For: 2.4 > > > I have project with dependency to testng and surefire plugin as in > Environment. > I run tests and get exception: > org.apache.maven.surefire.booter.SurefireExecutionException: > org.testng.xml.XmlSuite.setParallel(Z)V; nested exception i > s java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:135) > at org.apache.maven.surefire.Surefire.run(Surefire.java:129) > 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 > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) > Please, correct surefire to be compatible with new testng. -- 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: (MDEPLOY-59) deploy:deploy-file deletes the original file on error
deploy:deploy-file deletes the original file on error - Key: MDEPLOY-59 URL: http://jira.codehaus.org/browse/MDEPLOY-59 Project: Maven 2.x Deploy Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Windows XP Reporter: Tim Reilly While trying to test deploy:deploy-file the local copy of the pom gets deleted and an error message (can not find the pom that it just deleted is error logged.) Setup: Maven2 jaxb-1 plugin is in my local repository. I have a test repository on my local machine as well / also. In order to test the command needed for our administrator to deploy the file into our repository I test with the following command: C:\Work\Maven\maven-mmfg-loadthirdparty-plugin>mvn deploy:deploy-file -Dfile=C:/DOCUME~1/CP65214/.m2/repository/org/jvnet/ jaxb1/maven2/maven-jaxb1-plugin/1.0-rc10\maven-jaxb1-plugin-1.0-rc10.jar -Durl=file://C:/Work/Maven/maven-mmfg-loadthirdpa rty-plugin/src/it/maven-mmfg-loadthirdparty-test/target\thirdparty/repo -DpomFile=C:\DOCUME~1\CP65214\.m2\repository\org\j vnet\jaxb1\maven2\maven-jaxb1-plugin\1.0-rc10\maven-jaxb1-plugin-1.0-rc10.pom The result of the command is: [INFO] Scanning for projects... [INFO] snapshot com.mm.infrastructure.build.plugins:maven-mmfg-plugins:1.0-SNAPSHOT: checking for updates from mmfg-thirdp arty-snapshot [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] com.mm.infrastructure: checking for updates from mmfg-thirdparty-plugin-release [INFO] org.apache.maven.plugins: checking for updates from mmfg-thirdparty-plugin-release [INFO] org.codehaus.mojo: checking for updates from mmfg-thirdparty-plugin-release [INFO] artifact org.apache.maven.plugins:maven-deploy-plugin: checking for updates from mmfg-thirdparty-plugin-release [INFO] [INFO] Building Unnamed - com.mm.infrastructure.build.plugins:maven-mmfg-loadthirdparty-plugin:maven-plugin:1.0-SNAPSHOT [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: file://C:/Work/Maven/maven-mmfg-loadthirdparty-plugin/src/it/maven-mmfg-loadthirdparty-test/target\thirdparty/r epo/org/jvnet/jaxb1/maven2/maven-jaxb1-plugin/1.0-rc10/maven-jaxb1-plugin-1.0-rc10.jar 0b uploaded [INFO] Retrieving previous metadata from remote-repository [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact's metadata: Error installing metadata: Error copying POM to the local repository. File C:\DOCUME~1\CP65214\.m2\repository\org\jvnet\jaxb1\maven2\maven-jaxb1-plugin\1.0-rc10\maven-jaxb1-plugin-1.0-rc10.pom does not exist [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Aug 02 17:11:55 EDT 2007 [INFO] Final Memory: 3M/11M [INFO] So as I am entering this issue I decide to replay everything and my plugin must have the willies... b/c this time around it doesn't delete the pom file... It turns both the pom and the jar into 0 byte files: Steps for this one: 1) I delete the jaxb plugin from the my repository08/02/2007 05:40 PM 2) I run verify on my jaxb project so that it grabs it from java.net's repository... and the jar is about 22K and the pom is about 9K 08/02/2007 05:40 PM .. 08/02/2007 05:39 PM22,124 maven-jaxb1-plugin-1.0-rc10.jar 08/02/2007 05:39 PM40 maven-jaxb1-plugin-1.0-rc10.jar.sha1 08/02/2007 05:39 PM 9,156 maven-jaxb1-plugin-1.0-rc10.pom 08/02/2007 05:39 PM40 maven-jaxb1-plugin-1.0-rc10.pom.sha1 3) Run the command againX:\>mvn deploy:deploy-file -Dfile=C:/DOCUME~1/CP65214/.m2/repository/org/jvnet/jaxb1/maven2/maven-jaxb1-plugin/1.0-rc10\ma ven-jaxb1-plugin-1.0-rc10.jar -Durl=file://C:/Work/Maven/maven-mmfg-loadthirdparty-plugin/src/it/maven-mmfg-loadthirdparty -test/target\thirdparty/repo -DpomFile=C:\DOCUME~1\CP65214\.m2\repository\org\jvnet\jaxb1\maven2\maven-jaxb1-plugin\1.0-rc 10\maven-jaxb1-plugin-1.0-rc10.pom [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file]
[jira] Closed: (MECLIPSE-292) Behaviour for sources and Javadoc attachement for dependencies should be consistent
[ http://jira.codehaus.org/browse/MECLIPSE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MECLIPSE-292. -- Resolution: Fixed Fix Version/s: (was: 2.4) 2.5 > Behaviour for sources and Javadoc attachement for dependencies should be > consistent > --- > > Key: MECLIPSE-292 > URL: http://jira.codehaus.org/browse/MECLIPSE-292 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: dependency resolution >Affects Versions: 2.4 > Environment: Windows XP, Maven 2.0.6, maven-eclipse-plugin > 2.4-20070628.215652-24 >Reporter: Denis Cabasson >Assignee: Brian Fox >Priority: Minor > Fix For: 2.5 > > Attachments: MECLIPSE-292-fixbug.patch, MECLIPSE-292-updated.patch, > MECLIPSE-292.patch > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Why couldn't we have a consistent behaviour for javadoc and sources jar > attachment? > Why not adding a downloadJavadoc property, which, when set to true, would > download and attach the javadoc to the dependency. > I don't really see why javadoc should be a fallback if sources are not > available. > Some developpers might prefer to have javadoc linked, some sources linked and > some both. Shouldn't the eclipse plugin allow for all the possiblities > instead of stating that the preferred option is always to get the sources > instead of the 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] Commented: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103900
]
William Ferguson commented on WAGON-73:
---
OK, our workaround to this bug (overriding the central repository in
settings.xml instead of creating a mirror for it). Ie
central
Overrride of Central (not
mirror)
http://zosma.oz.hubbub.com.au:8080/proximity/repository/release
true
false
central
Override of Central
http://zosma.oz.hubbub.com.au:8080/proximity/repository/release
true
false
appears to work for all maven components except when there is a dependency on
the maven-archetype-plugin.
For some reason 'mvn archetype:create ..' causes all Maven artifacts to be
retrieved from the *real* central and not the one we have overridden in
settings.xml. Whereas 'mvn clean compile' retrieves the Maven components from
the overridden location.
We are currently stuck in a situation, where either
a) 'mvn archetype:create' works
b) Eclipse can download Maven dependencies
But not both.
So can we please get the patch applied?
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Assignee: Joakim Erdfelt
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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: (MECLIPSE-292) Behaviour for sources and Javadoc attachement for dependencies should be consistent
[ http://jira.codehaus.org/browse/MECLIPSE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MECLIPSE-292 started by Brian Fox. > Behaviour for sources and Javadoc attachement for dependencies should be > consistent > --- > > Key: MECLIPSE-292 > URL: http://jira.codehaus.org/browse/MECLIPSE-292 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: dependency resolution >Affects Versions: 2.4 > Environment: Windows XP, Maven 2.0.6, maven-eclipse-plugin > 2.4-20070628.215652-24 >Reporter: Denis Cabasson >Assignee: Brian Fox >Priority: Minor > Fix For: 2.4 > > Attachments: MECLIPSE-292-fixbug.patch, MECLIPSE-292-updated.patch, > MECLIPSE-292.patch > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Why couldn't we have a consistent behaviour for javadoc and sources jar > attachment? > Why not adding a downloadJavadoc property, which, when set to true, would > download and attach the javadoc to the dependency. > I don't really see why javadoc should be a fallback if sources are not > available. > Some developpers might prefer to have javadoc linked, some sources linked and > some both. Shouldn't the eclipse plugin allow for all the possiblities > instead of stating that the preferred option is always to get the sources > instead of the 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] Commented: (MENFORCER-14) Enforcer Plugin Messes Up Dependencies
[ http://jira.codehaus.org/browse/MENFORCER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103899 ] Brian Fox commented on MENFORCER-14: You're right, it's not a fix but a workaround. However, the enforce-once has always been broken and executes on each project anyway. Therefore, there is no speed/performance difference between the two. > Enforcer Plugin Messes Up Dependencies > -- > > Key: MENFORCER-14 > URL: http://jira.codehaus.org/browse/MENFORCER-14 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug >Reporter: James Carman >Assignee: Brian Fox > Attachments: toplevel.zip > > > When using the enforcer plugin, it somehow messes up the dependencies in a > reactor-based build. The attached zip file exhibits the problem. Our project > structure is a bit weird. We have one top-level project which contains a > bunch of modules. One of the modules is a pom-based "tempalte" project which > sets up all of our build settings (src/target for the compiler, turns on the > aspectj compiler, etc.). All of the other modules extend the "template" > project and they themselves have multiple sub-project. -- 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: (MDEP-98) The source must not be a directory
[ http://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103901 ] Brian Fox commented on MDEP-98: --- i can reproduce this with the IT now. This only happens on multi project builds where the artifact is in the same reactor and the compile phase is used. Normally you will want to do install for multimodule builds to work. The best I can do is detect I've been given a folder and copy the contents of that folder instead of unpacking it. It's not clear what to do on copy since you would normally expect the jar not the classes themselves. > The source must not be a directory > -- > > Key: MDEP-98 > URL: http://jira.codehaus.org/browse/MDEP-98 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack-dependencies >Affects Versions: 2.0-alpha-4 > Environment: Windows XP Professional SP2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) > Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing) >Reporter: Pablo Muñiz >Assignee: Brian Fox > Fix For: 2.0-alpha-5 > > > Using maven-dependency-plugin in a multimodule project inside a module wich > has a dependency with another module in the same project the next error > ocurrs : > org.codehaus.plexus.archiver.ArchiverException: The source must not be a > directory. > at > org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98) > at > org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84) > at > org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232) > at > org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error unpacking file: > c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to: > c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes > org.codehaus.plexus.archiver.ArchiverException: The source must not be a > directory. > Project structure is as follows: > plataforma > - platform-core > - platform-bundle > - platform-bundle-jar > - platform-bundle-src > and the error happens on executing any goal from parent pom. > maven-dependency-plugin seems to receive a reference to target/classes > directory for platform-core dependency instead of the URL to my local > repository where platform-core is located. -- 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-1664) Please upload jlynx to maven central repo
Please upload jlynx to maven central repo - Key: MAVENUPLOAD-1664 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1664 Project: maven-upload-requests Issue Type: Wish Reporter: Greg Ritchie Attachments: net.sf.jlynx.sh jLynx is a simple, lite, hi-performance layer over the JDBC API. Persist and retrieve POJO and Map objects directly. Designed for developer productivity. Simpler, easy to learn compared to Hibernate, JPA, etc. -- 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-1656) Netty2 1.9.2 Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103903 ] Trustin Lee commented on MAVENUPLOAD-1656: -- Is there any ETA for this artifact to be uploaded? It's almost a week from the creation date now... > Netty2 1.9.2 Upload Request > --- > > Key: MAVENUPLOAD-1656 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1656 > Project: maven-upload-requests > Issue Type: Task >Reporter: Trustin Lee > Attachments: netty2-1.9.2-bundle.jar > > > Netty2 is an event-driven NIO framework and the ancestor of Apache MINA. > Apache MINA provides a few utility classes for smooth migration from Netty2 > to Apache MINA, and therefore one of the MINA submodules depends of Netty2. > And there are some people out there who uses Netty2 for historical reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103904
]
William Ferguson commented on ARCHETYPE-39:
---
Thanks Wendy, though I think you meant
\ ${artifactId}
(without the spaces), ie backslash before the $ and not after.
Though in the end I found using ${dollar} to be clearer in the template.
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity 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] Commented: (MNG-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103905
]
William Ferguson commented on MNG-2290:
---
Well if you do, I'll have to create another issue with the same title and copy
all of my comments (and some of yours) over there.
The auto append of ${artifactId} in child POMs is a *real* problem for url and
site#url.
But if you do close I suppose I can probably represent the problem again in a
much clearer form.
Its up to you.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin 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] Closed: (CONTINUUM-1086) First form element should have focus
[ http://jira.codehaus.org/browse/CONTINUUM-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1086. --- Assignee: Emmanuel Venisse Resolution: Fixed > First form element should have focus > > > Key: CONTINUUM-1086 > URL: http://jira.codehaus.org/browse/CONTINUUM-1086 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-alpha-1 >Reporter: Wendy Smoak >Assignee: Emmanuel Venisse >Priority: Trivial > Fix For: 1.1-beta-2 > > > For example, the username field should have focus when the login form is > displayed. (Currently, it's #9 in the tab order.) > Same for the username field on the Registration form, the Pom URL field on > the Add m2 project form, etc. -- 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-1232) Continuum should not steal window focus on page load
[ http://jira.codehaus.org/browse/CONTINUUM-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1232. --- Assignee: Emmanuel Venisse Resolution: Fixed > Continuum should not steal window focus on page load > > > Key: CONTINUUM-1232 > URL: http://jira.codehaus.org/browse/CONTINUUM-1232 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-alpha-1 >Reporter: Wendy Smoak >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1-beta-2 > > > Continuum has a habit of stealing window focus on page load events. For > example, if you click "Build" and then minimize the window to do something > else, the browser window will pop back on top when the page is finished > loading. -- 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: (MRM-412) Add support for maven1 (legacy) request to access a maven2 (default layout) repo
[ http://jira.codehaus.org/browse/MRM-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-412. Assignee: Brett Porter Resolution: Fixed applied, thanks! Please watch the formatting in future patches though, please :) > Add support for maven1 (legacy) request to access a maven2 (default layout) > repo > > > Key: MRM-412 > URL: http://jira.codehaus.org/browse/MRM-412 > Project: Archiva > Issue Type: Improvement > Components: WebDAV interface >Affects Versions: 1.0-alpha-2 >Reporter: nicolas de loof >Assignee: Brett Porter >Priority: Minor > Fix For: 1.0-beta-1 > > Attachments: archiva-1.0-alpha-2.patch > > > archiva 1.0-alpha-1 doesn't support converting legacy-layout request to > default layout. This behaviour is usefull to allow maven1 to access a maven2 > repository, and avoid having multiple managed repo as proxies to central. > The attached patch add this support : > - it adds to BidirectionalRepositoryLayout the new method boolean > isValidPath( String path ) > - it adds to BidirectionalRepositoryLayoutFactory the new method > BidirectionalRepositoryLayout getLayoutForPath( String path ) > - it use them to detect the layout used by incoming request and build the > ArchivaArtifact object used to proxy the request. It aslo overrides the > pathInfo to make the request point to the real-file path in the managed > repository > BidirectionalRepositoryLayoutFactoryTest also updated -- 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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103907
]
Arnaud Heritier commented on WAGON-73:
--
The problem in archetype is related to another bug : MNG-3099
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Assignee: Joakim Erdfelt
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-59) Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V
[ http://jira.codehaus.org/browse/SUREFIRE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103906 ] Marat Radchenko commented on SUREFIRE-59: - Workaround: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-surefire-plugin/2.4-collab-SNAPSHOT/ This version works without errors. > Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: > org.testng.xml.XmlSuite.setParallel(Z)V > - > > Key: SUREFIRE-59 > URL: http://jira.codehaus.org/browse/SUREFIRE-59 > Project: Maven Surefire > Issue Type: Improvement > Components: TestNG support > Environment: > maven-surefire-plugin > 2.2 > > > org.testng > testng > 5.2 > jdk15 > test > >Reporter: Damian Golda > Fix For: 2.4 > > > I have project with dependency to testng and surefire plugin as in > Environment. > I run tests and get exception: > org.apache.maven.surefire.booter.SurefireExecutionException: > org.testng.xml.XmlSuite.setParallel(Z)V; nested exception i > s java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:135) > at org.apache.maven.surefire.Surefire.run(Surefire.java:129) > 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 > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) > Please, correct surefire to be compatible with new testng. -- 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: (MRM-443) it'd be nice to have a wizard interface to set up some common settings
it'd be nice to have a wizard interface to set up some common settings -- Key: MRM-443 URL: http://jira.codehaus.org/browse/MRM-443 Project: Archiva Issue Type: Improvement Components: web application Affects Versions: 1.0-alpha-2 Reporter: Brett Porter for example - setting up guest access to all repositories could be a simple yes/no instead of having to go in and do configuration on a new set up. -- 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
