[jira] (MEAR-71) please support outputFilename here, same as in war plugin
[ https://jira.codehaus.org/browse/MEAR-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll updated MEAR-71: Fix Version/s: (was: 2.8) > please support outputFilename here, same as in war plugin > - > > Key: MEAR-71 > URL: https://jira.codehaus.org/browse/MEAR-71 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Reporter: Joakim Verona >Assignee: Stéphane Nicoll > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-151) Allow empty library-directory element in application.xml
[
https://jira.codehaus.org/browse/MEAR-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéphane Nicoll closed MEAR-151.
Resolution: Fixed
MEAR-146 introduced a libraryDirectoryMode option that you can use the write an
empty library directory.
Just add something like:
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
2.8-SNAPSHOT
6
empty
{code}
> Allow empty library-directory element in application.xml
>
>
> Key: MEAR-151
> URL: https://jira.codehaus.org/browse/MEAR-151
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Peter H
>Assignee: Stéphane Nicoll
> Fix For: 2.8
>
>
> Currently it's only possible to add the library-directory element into the
> application.xml if it's supposed to contain some value.
> However it's allowed to use the empty element to disable the related
> functionality:
> http://java.sun.com/xml/ns/javaee/application_6.xsd
> The library-directory element specifies the pathname
> of a directory within the application package, relative
> to the top level of the application package. All files
> named "*.jar" in this directory must be made available
> in the class path of all components included in this
> application package. If this element isn't specified,
> the directory named "lib" is searched. *An* *empty* *element*
> *may* *be* *used* *to* *disable* *searching*.
> That's exactly what we need, so please allow the empty library-directory in
> application.xml, the simple form would be the preferred
> one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-151) Allow empty library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll reassigned MEAR-151: Assignee: Stéphane Nicoll > Allow empty library-directory element in application.xml > > > Key: MEAR-151 > URL: https://jira.codehaus.org/browse/MEAR-151 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Peter H >Assignee: Stéphane Nicoll > Fix For: 2.8 > > > Currently it's only possible to add the library-directory element into the > application.xml if it's supposed to contain some value. > However it's allowed to use the empty element to disable the related > functionality: > http://java.sun.com/xml/ns/javaee/application_6.xsd > The library-directory element specifies the pathname > of a directory within the application package, relative > to the top level of the application package. All files > named "*.jar" in this directory must be made available > in the class path of all components included in this > application package. If this element isn't specified, > the directory named "lib" is searched. *An* *empty* *element* > *may* *be* *used* *to* *disable* *searching*. > That's exactly what we need, so please allow the empty library-directory in > application.xml, the simple form would be the preferred > one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307206#comment-307206 ] Stéphane Nicoll commented on MEAR-146: -- Thanks for the patch Alex. I have changed it slightly to: # Use libraryDirectoryMode instead of libraryDirectory. I don't like the idea of mixing magic strings with the actual value for the library directory, # Rename the option to make them shorter and easier to read (DEFAULT_LIB_BUNDLE_DIR is not really easy to put in a pom file): the new values are now "DEFAULT", "EMPTY" and "NONE" (and the case does not matter so you can write this lower-case as well), # Move the parameter to the right mojo (the main mojo does not need this parameter). I also added the ITs for the 3 options. I just deployed a snapshot (2.8-20120827.200901-277). Can you try this out and let me know if that fixes your issue? Thanks a lot for your assistance, for the details and the patch. This really helped. > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Assignee: Stéphane Nicoll >Priority: Minor > Fix For: 2.8 > > Attachments: ear-general-librarydirectory.patch, > ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch, ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll closed MEAR-146. Resolution: Fixed > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Assignee: Stéphane Nicoll >Priority: Minor > Fix For: 2.8 > > Attachments: ear-general-librarydirectory.patch, > ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch, ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-511) release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-511.
---
Resolution: Fixed
Fix Version/s: 2.4
[r1377810|http://svn.apache.org/viewvc?rev=1377810&view=rev] contains a specifc
unit test.
@Ion Iovu: In general I don't we should trim prompt answers, so let's not do it
here either.
@Michal Minicki: please make a separate issue (improvement) for your request.
This requires refactoring the {{DefaultVersionInfo}}. So it is not fixed yet.
> release:prepare "Error parsing version, cannot determine next version: Unable
> to parse the version string" when running in batch mode.
> --
>
> Key: MRELEASE-511
> URL: https://jira.codehaus.org/browse/MRELEASE-511
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Win Xp Pro 64bit Java 1.6
>Reporter: David Cloutier
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 2.4
>
> Attachments: patch_release_version_patterns.txt
>
>
> When I try to run release:prepare in batch mode, I get the error below (can't
> parse version string) even though I supply the version number by argument. If
> I do the same thing with the same versions in interactive mode, it works fine.
> Here is the output:
> {noformat}
> C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX
> -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
> release:perform
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
> [INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
> [INFO]
>
> Downloading:
> http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
> Downloading:
> http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases-local
> (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository central (http://repo1.maven.org/maven2)
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -t -d
> :pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d"
> [INFO] Working directory: C:\workspaces\head\MyClient
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error parsing version, cannot determine next version: Unable to parse
> the version string: "MYB_200909-SNAPSHOT"
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
> version, cannot determine next version: Unable to parse the version string:
> "MYB_200909-SNAPSHOT"
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
>
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll reassigned MEAR-146: Assignee: Stéphane Nicoll > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Assignee: Stéphane Nicoll >Priority: Minor > Fix For: 2.8 > > Attachments: ear-general-librarydirectory.patch, > ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch, ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-371) useJvmChmod true by default
[ https://jira.codehaus.org/browse/MDEP-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MDEP-371. - Resolution: Fixed Fix Version/s: 2.6 > useJvmChmod true by default > --- > > Key: MDEP-371 > URL: https://jira.codehaus.org/browse/MDEP-371 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.6 > > > useJvmChmod is very more performant for 1.6+, so it's time to use it as > default. > NOTE: plexus-archiver revert automatically to forking a chmod cli if 1.6+ not > available. > To fix file permissions, plexus-archiver will support group level too for 1.7 > using PosixFilePermission. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANT-73) Wrong repositories in generated get-deps task and speed improvement
Jorge Gomez created MANT-73:
---
Summary: Wrong repositories in generated get-deps task and speed
improvement
Key: MANT-73
URL: https://jira.codehaus.org/browse/MANT-73
Project: Maven 2.x Ant Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: linux, jDK 1.6, maven 3.0.4
Reporter: Jorge Gomez
Priority: Blocker
Attachments: avoidsnapshots_and_skipexisting.diff
When one artifact existed in more than one repository, the first was selected
by default. This lead to undesirable behaviors when developing for sonatype
repository. In this case, I observed snapshots version were automatically
selected, but they did not exist. For instance, the following was generated for
Junit 4.8.1.
https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.8.1/junit-4.8.1.jar";
dest="${maven.repo.local}/junit/junit/4.8.1/junit-4.8.1.jar"
usetimestamp="false"
ignoreerrors="true"/>
https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.8.1/junit-4.8.1.jar
does not exist, by the way. This lead to important delays in compilation and
any other target depending on get-deps.
Making the AntBuildWriter select those repositories which are not snapshots,
solves the issues. With the attched patch, the previous task becomes into:
https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.8.1/junit-4.8.1.jar";
dest="${maven.repo.local}/junit/junit/4.8.1/junit-4.8.1.jar"
usetimestamp="false"
ignoreerrors="true"/>
Nevertheless, this still makes the get-deps slow. By increasing the minimum ant
version to 1.8.0, it is possible to use "skipexisting" attribute for ant task.
This, combined with "usetimestamp=true" makes compilation lightning fast once
everything is downloaded. Now the task looks like:
http://repo.maven.apache.org/maven2/junit/junit/4.8.1/junit-4.8.1.jar";
dest="${maven.repo.local}/junit/junit/4.8.1/junit-4.8.1.jar"
usetimestamp="true"
ignoreerrors="true"
skipexisting="true"/>
The attached patch was created against the 2.3 tag version of the repository,
though it is present as well in the head of the trunk. The pom.xml file was
modified only to include the 1.8.0 version of ant instead of the old 1.7.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-371) useJvmChmod true by default
[ https://jira.codehaus.org/browse/MDEP-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MDEP-371: - Assignee: Olivier Lamy > useJvmChmod true by default > --- > > Key: MDEP-371 > URL: https://jira.codehaus.org/browse/MDEP-371 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack >Reporter: Olivier Lamy >Assignee: Olivier Lamy > > useJvmChmod is very more performant for 1.6+, so it's time to use it as > default. > NOTE: plexus-archiver revert automatically to forking a chmod cli if 1.6+ not > available. > To fix file permissions, plexus-archiver will support group level too for 1.7 > using PosixFilePermission. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-371) useJvmChmod true by default
Olivier Lamy created MDEP-371: - Summary: useJvmChmod true by default Key: MDEP-371 URL: https://jira.codehaus.org/browse/MDEP-371 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack Reporter: Olivier Lamy useJvmChmod is very more performant for 1.6+, so it's time to use it as default. NOTE: plexus-archiver revert automatically to forking a chmod cli if 1.6+ not available. To fix file permissions, plexus-archiver will support group level too for 1.7 using PosixFilePermission. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-138) Rule to ban all transitive dependencies
[ https://jira.codehaus.org/browse/MENFORCER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307166#comment-307166 ] Jakub Senko commented on MENFORCER-138: --- I've started a pull request: https://github.com/apache/maven-enforcer/pull/2 > Rule to ban all transitive dependencies > --- > > Key: MENFORCER-138 > URL: https://jira.codehaus.org/browse/MENFORCER-138 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Paul Gier > > In some projects it's necessary (or at least desirable) to have all > dependencies specified in pom. It would be nice to have an enforcer rule > that would ban all transitive dependencies so that the user could either add > the transitive dependency directly to the pom (if it's actually needed), or > exclude the dependency. > The rule should also have an option to ignore certain transitive > dependencies, possibly using a similar syntax to other rules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-137) Maven 2.2.1 NullPointerException with mergeUserSettings parameter
redfish4ktc created MINVOKER-137:
Summary: Maven 2.2.1 NullPointerException with mergeUserSettings
parameter
Key: MINVOKER-137
URL: https://jira.codehaus.org/browse/MINVOKER-137
Project: Maven 2.x Invoker Plugin
Issue Type: Bug
Affects Versions: 1.7
Environment: maven 2.2.1
Sun/Oracle JDK 5, 6, 7
windows xp, ubuntu
Reporter: redfish4ktc
This is confirmed by running integration test (with or without user
settings.xml)
mvn clean verify -Dinvoker.test=settings-merge/pom.xml -P run-its
{code}
java.lang.NullPointerException
at org.apache.maven.settings.SettingsUtils.merge(SettingsUtils.java:77)
at
org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuilds(AbstractInvokerMojo.java:1035)
at
org.apache.maven.plugin.invoker.AbstractInvokerMojo.execute(AbstractInvokerMojo.java:670)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-159) guide-encryption.html: --encrypt-password sometimes requires to double-quote the specified password
Jappe van der Hel created MNGSITE-159: - Summary: guide-encryption.html: --encrypt-password sometimes requires to double-quote the specified password Key: MNGSITE-159 URL: https://jira.codehaus.org/browse/MNGSITE-159 Project: Maven Project Web Site Issue Type: Improvement Environment: windows (7) Reporter: Jappe van der Hel Priority: Minor http://maven.apache.org/guides/mini/guide-encryption.html Please add extra documentation for specifying password when using --encrypt-master-password and --encrypt-password in windows command line. When using special characters in your password, you have to use double-quotes when passing it as an argument. Doesn't work example: mvn.bat --encrypt-master-password a!$%^b Does work example: mvn.bat --encrypt-master-password "a!$%^b" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MCOMPILER-21: --- Attachment: MCOMPILER-21-v2.patch first version of an ugly hack to also get class inter-dependencies properly recompiled > compiler smarts > --- > > Key: MCOMPILER-21 > URL: https://jira.codehaus.org/browse/MCOMPILER-21 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Brett Porter >Assignee: Mark Struberg > Fix For: backlog > > Attachments: MCOMPILER-21.patch, MCOMPILER-21-v2.patch > > > there are probably other ways we can make the compiler stale check smarter. > List them out here if you think of them. > 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-66) sidebar and content class configurable
[ https://jira.codehaus.org/browse/MSKINS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSKINS-66. -- Resolution: Fixed > sidebar and content class configurable > -- > > Key: MSKINS-66 > URL: https://jira.codehaus.org/browse/MSKINS-66 > Project: Maven Skins > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: fluido-1.3.0 > > > sidebar use span3 and content span9. > We must make that configurable for users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307128#comment-307128
]
Myron commented on MPIR-251:
Thanks Hervé for looking into this.
What exactly does "has no file" mean?
It's a regular upload, with jar, javadooc, pom,
Just an addendum
With the uploaded ojdbc driver it complains about the following:
{quote}
[INFO] Generating "Dependencies" report---
maven-project-info-reports-plugin:2.4
[ERROR] Artifact: dom4j:dom4j:jar:1.6.1 has no file.
[ERROR] Artifact: javax.transaction:jta:jar:1.1 has no file.
[ERROR] Artifact: stax:stax-api:jar:1.0.1 has no file.
[ERROR] Artifact: xml-apis:xml-apis:jar:1.0.b2 has no file.
[WARNING] The repository url 'http://mycompany.com/nexus/content/groups/public'
is invalid - Repository 'nexus' will be blacklisted.
{quote}
Note that the ojdbc is NOT included?!?
Without the ojdbc, the errors are gone.
Could the temporary nexus-offline warning be a culprit?
Dunno why Maven sees this as offline; it works for everything else so far...
> Artifact ## has no file error regression.
> -
>
> Key: MPIR-251
> URL: https://jira.codehaus.org/browse/MPIR-251
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Ian Brandt
>Priority: Minor
> Attachments: pom.xml
>
>
> It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
> 2.5 with Maven 3.0.4:
> {noformat}
> [INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.5
> [ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
> [ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
> [ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
> [ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
> [ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
> [ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
> file.
> [ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
> [ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
> ...{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
